Hi Pascal, > On 20 Feb 2018, at 10:13, Pascal Thubert (pthubert) <[email protected]> > wrote: > > > Reviewer: Tim Chown > > Thanks a bunch Tim! > > I answered with a prefix > > > There are specific questions back to you down there. Please feel free to > remove all Q/As for which we found an agreement already. > > General comments: > -------------------------------------- > > The document could use a glossary of terms: LLN, 6LN, 6LBR, 6LR, BBR, etc. > >> Done in appendix > > > ******************* > > The introduction could talk of other new added features, like avoiding DAD > for link locals. > >> You'll note that it is not avoided. But it is scoped in the relationship >> between the 6LN and the 6LR. One 6LR may accept to talk to a 6LN LN_A seen >> as LLA Addr_A and then later another 6LR may refuse that same Addr_A because >> from its standpoint Addr_A duplicates a LLA used by another device that is >> also talking to. The draft does not change what a LLA can be used for in >> route over, that is one radio hop; mostly, it reduces the illusion that a >> link local address can be DAD'ed in a network that is not fully and >> permanently connected.
TC> OK, thanks for the clarification. >> Added: > " > <t> Simplify the registration flow for link-local addresses </t> > " > as a clarification instead of: > " > <t> Reduce requirement of registration for link-local addresses </t> > " TC> OK. > The document includes RFC 7217 in the references, but doesn't include > discussion of it in the main body of the text. Shouldn't RFC 7217 be > considered the norm here rather than address generation as per RFC 4862? > >> added: > > " > <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque > Interface Identifiers with IPv6 Stateless Address Autoconfiguration > (SLAAC)" > </xref> is the recommended method for generating Interface Identifiers to > be used in SLAAC at the time of this writing. > </t> > " > > > ********************** > > > > Related, RFC 8064 "recommends against embedding stable link-layer addresses in > IPv6 Interface Identifiers". The document is inconsistent - it talks of > using EUI64, then in Section 9 not using EUI64. > >> fact is, a typical IEEE802.15.4-based network will compress the IPv6 address >> based on the MAC address. But it does not have to be so, and it does not >> apply to all types of networks. > >> new updated proposed text: > > " > <t> The IPv6 address of the 6LN in the IPv6 header can be compressed > statelessly Interface Identifier in the IPv6 address can be derived from TC> Insert "where the" after statelessly? > the Lower Layer address. When it is not critical to benefit from that > compression, e.g. the address can be compressed statefully, or it is rarely > used and/or it is used only over one hop, then the best practice of forming > privacy addresses should be considered: > </t> > <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque > Interface Identifiers with IPv6 Stateless Address Autoconfiguration > (SLAAC)" > </xref> is the recommended method for generating Interface Identifiers to > be used in SLAAC at the time of this writing. > </t> TC> I'd be careful referring to privacy addresses and then implying RFC7217 gives a privacy address, given a node could have an RFC7217 address and a RFC4941 privacy address, or potentially just a privacy address. > " > this is followed by existing text: > " > <t> > <xref target="RFC8065"> > "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"</xref> > explains why privacy is important and how to form such addresses. All > implementations and deployment must consider the option of privacy > addresses in their own environment. Also future specifications > involving 6LoWPAN Neighbor Discovery should consult > <xref target="RFC8064"> > "Recommendation on Stable IPv6 Interface Identifiers"</xref> > for default interface identification. > </t> > " > > > > > ********************** > > > > > > Specific comments: > -------------------------------------- > > p.3 > Section 2, para 2 - should ND cache exhaustion attacks be included in the > list here? > >> If the method is used as a full replacement of reactive ND, then there can >> be some control. e.g. we'd be immune from NCE DOS attack from a remote >> party. But it's a touchy space. In the one hand, we never block from using >> both, IOW classical (reactive) ND in conjunction with the new (proactive) >> registration. Also a local node could still attack the cache by performing >> tons of registrations, forging MAC addresses as it goes if need be. It will >> take separate work to address all the security requirements (AP-ND >> https://tools.ietf.org/html/draft-ietf-6lo-ap-nd and more). TC> OK, so leave as is. > > ********************** > > > > p.4 > Section 3 - Add RFC 7217 to RFC 4862? It's recommended by RFC 8064. > >> This is a terminology section. Are there terms we need from RFC 7217? Note >> that this specification does not dictate how to form address, just manages >> them. Still it places recommendation to the protocol developers coming next >> (e.g. for a particular link layer) to consider privacy. Text related to RFC >> 7217 is added in section 9 per your other comment. TC> OK, leave as is then. > > > ********************** > > > > p.6 > Section 4 - for a node to prefer registering to a 6LR that supports the spec, > it would need to enumerate all available 6LRs; should the process for this be > described here, or is it included in sufficient detail in RFC 6775? > >> You are correct. There is no enumeration process; 6LRs are discovered as >> described in RFC 6775 sections 5.2 and 5.3. by sending out mcast RS. This >> document updates RFC 6775 but we avoided paraphrasing it as much as we >> could, considering that this doc is already quite thick. > Still I added the first line of the text below: > " > <t> Section 5 of <xref target="RFC6775"/> specifies how a 6LN bootstraps an > interface and locates available 6LRs; a Registering Node SHOULD prefer > registering to a 6LR that is found to support this specification, as > discussed in <xref target="dsc"/>, over a legacy one. > </t> TC> OK. > " > > > ********************** > > > > > p.7 > Section 4.1 - "not required to be a MAC address" - as per my general comment > above, with current IETF thinking, should this not be stronger, e.g. "SHOULD > NOT be a MAC address"? Section 9 says this? > >> I see where you're coming from and htat makes sense to me. But the WG never >> went that far. Note that this is not a subfield in an address; as it goes >> the message is not not supposed to leak outside. RFC 6775 forced the UID to >> be a MAC address in the EUI-64 form. This specification does not deprecate >> the legacy behavior and it allows for something else. But it recommends >> (section 8) to use a privacy technique such as AP-ND instead. Once AP-ND is >> standard, we can deprecate the legacy behavior if the WG finds it relevant, >> e.g. when we apply it to networks that are more sensitive to privacy. TC> OK, thanks for explaining it; that sounds reasonable. I suspect this point will come up again in IESG review though! > > > > ********************** > > > > > p.9 > Section 4.2, point 4 - I find this quite para quite hard to read. > >> Agreed, it is inlined from RFC 6550 as opposed to referenced per WG and >> shepherd decision. I simplified to: > " > If two sequence numbers are determined to be not comparable, > i.e. the results of the comparison are not defined, then a node > should give precedence to the sequence number that was most > recently > incremented. Failing this, the node should select the sequence number > in order to minimize the resulting changes to its own state. > > " TC> OK. > > > ********************** > > > > p.9 > Section 4.3, para 1 - again, is using EUI-64 desirable? Is the point to > allow header compression as per RFC4944? Discuss the tradeoff? Section 4.3 > para 2 - so a different type of identifier could be an RFC 7217 generated > identifier? > >> It could be many things but collisions should be avoided. It should not be >> an interface ID since this is to complement the DAD of the IID. AP-ND builds >> it on cryptography. Your point is excellent, unsure if this doc should be >> the vessel for it. At this stage, we never argued deprecation before, just >> extension. It will take WG work to define possible replacements and this doc >> may be too advanced for that I guess, but I'll ask. TC> OK. > > > > ********************** > > > > p.11 > Section 4.6 - in the case of two 6LRs with the same link-layer addresses, > does it matter which a 6LN chooses? Is the choice algorithmic? Section 4.6 - > the last para on p.11 seems to be repeated in the first para on p.12? > >> This specification (including RFC 6775) does not have a router preference >> (whether they have a same or different LLA) beyond RFC 4191. RPL does, based >> on Rank and the upcoming enrollment specification will also hint on that. >> And apparently yes to your other point, cleaning up. TC> OK. > > ********************** > > > > p.12 > Section 4.6 - again, is the recommendation to use an (expected to be) unique > LL address in keeping with RFC 8064? > >> There is a chicken and an egg problem with the first registration of the >> first LLA. It is better that it does not fail. RFC6775 stipulates that >> MAC-derived LLA do not need DAD. This message flies over one hop, between a >> node and its nearby router. The node may then form as many privacy LL and >> GUA as it likes. TC> OK. > > > ********************** > > > > p.13 > Para 4 - a Moved message SHOULD be used, yet elsewhere a node MUST clean up > its stale state? Consistent? What about MIPv6-like spoofing security issues? > You say "an alternate protocol" - isn't this a little hand-wavy; shouldn't a > single mechanism be defined rather than multiple (undefined) mechanisms? > >> Agreed. That single mechanism is DAR/DAC. I removed the "an alternate >> protocol"; what was meant is now separately drafted in >> draft-thubert-roll-unaware-leaves. This is where using RPL to proxy the >> registration is described. Unsure about which MIP attack you have in mind? TC> Never mind; I saw other AP-ND comments that clarified it. > > > ********************** > > > > > p.15 > OUI is a confusing choice of term, given OUIs in MAC addresses; I guess this > is now baked into RFC 6775 though. > >> Actually no. RFC 6775 uses EUI-64 throughout. We picked that term to >> generalize the EUI-64, so I guess we can still change that name. I changed >> it to Registration Unique ID (RUID) but that does not sound so right; would >> you have suggestions? >> I'll take that question to the WG separately. TC> I saw that, thanks. I don't have a specific suggestion, just that OUI has a very well known application elsewhere. > ********************** > > > > p.16 > I don't think codes 5 and 10 are explained/defined in any detail here? How > is the challenge made? > >> This is used in a freference spec. I clarified that by adding 3 lines at the >> end of the text in the RUID (ex OUID) section which now reads: > > " The Registration Unique ID in <xref target="RFC6775"/> > is a EUI-64 globally unique address configured at a Lower Layer, > under the assumption that duplicate EUI-64 addresses are avoided. > With this specification, the Registration Unique ID is allowed to be > extended to different types of identifier, as long as the type is clearly > indicated. For instance, the type can be a cryptographic string and > used to prove the ownership of the registration as discussed in > <xref target="I-D.ietf-6lo-ap-nd"> > "Address Protected Neighbor Discovery for Low-power and Lossy Networks" > </xref>. In order to support the flows related to the proof of > ownership, > this specification introduces new status codes "Validation Requested" and > "Validation Failed" in the EARO. TC> OK. > > > ********************** > > > > p.16 > The registration lifetime is in minutes; why not in seconds? > >> RFC 6775 is missing a way to express the time unit (RPL has one). > We used minutes because a typical LLN operates at a very slow pace, and a > typical device is like a three-toed sloth that would sleep more than a cat. > We even had a requirement to produce an 'infinite' lifetime for the likes of > light bulbs but never took it that slow. We could change the format but that > would not be backward compatible. >> I'll take that question to the WG separately TC> :) > ********************** > > > > p.18 > Section 6.3 - SHOULD set the E flag; why not a MUST? Why would you support > the spec, but not advertise that you do? In contrast, on the next page in > Section > 7.1.1 you say nodes MUST set it. > >> fixed, it was a MUST :) TC> OK. > ********************** > > > > p.19 > Section 7.1.2 para 2 - would a LL address generally be used here as source? > Should that be a SHOULD? Using a temporary address is probably not ideal. > >> RFC 6775 used the registered address (LL or GUA) as source and the target >> was not really important. With this specification, register the target of >> the NS, and there is no point remembering the source address of the >> registration NS after the NA was sent back. A 6LR can talk to the registered >> address using the registered address. TC> OK. > > ********************** > > > > p.20 > Section 7.3 para 4 - is this consistent with p.19 last para saying a 6LN MUST > use the updated spec once it knows it's supported? The last two paras here > are a bit vague/loose. > >> I turned the text into: > > " After detecting a legacy 6LR, an updated 6LN SHOULD attempt to find > an > alternate 6LR that is updated for a reasonable time that depends on > the > type of device and the expected deployment. > " TC> OK. > ********************** > > > > p.21 > Section 8, para 3 - recommends using privacy techniques, but uses EUI64? > >> RFC 6775 uses EUI. AP-ND uses a cryptographically generated token instead. >> This section effectively recommends AP-ND or whatever else cmes next that >> has privacy concerns. TC> OK. > > > ********************** > > > > p.22 > Limit the number of addresses? What about RFC 7934? > The type of algorithm described here might be better defined generically for > 6LoWPAN and 'real' IPv6? I don't think anything has been defined for ND > cache exhaustion attack mitigation - would a separate draft be beneficial? I > suspect current solutions are vendor specific? > >> We applied wisdom from RFC9734 and removed text that indicated that an >> administrator could be on the path of accepting an address or not. I know >> for having coded it that yes, (at least some) vendors provide a protection >> in the number of addresses that can be registered or snooped from a given >> device wen there is a limit for the overall resources to serve the network. >> A classical NCE is a cache but a 6LR NCE is really a hard state that the >> registrar guarantees to maintain for a given lifetime. The fact that a >> protection can be configured does not force a user in a particular >> deployment to use that protection. I agree that there is a need for NCE >> attack mitigation for both classical ND and 6LoWPAN ND. But till that spec >> exists, we cannot force the 6LR device to drop all protection against a >> misbehaving 6LN. A 6LR is an IOT device and it might easily be pushed beyond >> capacity. TC> OK. It might be something to raise in 6man, to see if there's interest in documenting algorithm(s). > ********************** > > > > p.22 > What trust model? > >> Should I add words? Those networks are always protected at Layer 2. But >> really, we'd like to see a draft that enables a 6LBR to prove it has that >> capacity and is entitled to play the role for the network. This is beyond >> the scope of this particular draft and should be done in a security related >> 6LoWPAN draft. TC> OK, perhaps just explicitly state the presence / assumption of L2 protection in the security section. > ********************** > > > > p.22 > Section 9 - EUI64, or not EUI64? Inconsistent. > Does anyone really use SeND? Especially in 6LoWPAN networks? > >> There are 2 uses of EUI that must be differentiated. The OUID (now RUID) is >> a unique ID for the device to correlate registrations for DAD between honest >> people. This section ere talks about IID in the IPv6 address. The text >> explains that no, SEND cannot be used in that space. This is why we do AP-ND >> instead. With AP-ND, the OUID is used to prove cryptographically the >> ownership of the registered address a bit like CGA does, but it is not part >> of the address. It is stored upon the first registration f an address and >> used later to validate that the new registration comes from the same guy. TC> Aaah, right, thanks. > ********************** > > > > p.24 > Section 10.3 - statuses 5 and 10 are not detailed in the draft? > >> Added text upon your point earlier TC> OK. > ********************** > > > > p.30 > The multicast issues text could cite the new mboned draft on this topic. > "Plague" is maybe strong! > >> done the ref. Added draft-perkins as well. replaced "plague" with "affect >> the operation of" TC> OK. > ********************** > > > > p.30 > Appendix B - can we have a table showing WHICH requirements have been met by > the draft? > >> added > > <t> > Note to RFC Editor: please replace "This" by the RFC number for this > specification once it is attributed. > <t> > > <texttable anchor="reqadd" title="Addressing requirements"> > <preamble>I-drafts/RFCs addressing requirements</preamble> > <ttcol align="left"> Requirement</ttcol> > <ttcol align="left"> Document </ttcol> > > <c>Req1.1</c> <c><xref > target="I-D.ietf-6lo-backbone-router"/></c> > <c>Req1.2</c> <c><xref target="RFC6775"/></c> > <c>Req1.3</c> <c><xref target="RFC6775"/></c> > <c>Req1.4</c> <c>This</c> > > <c>Req2.1</c> <c>This</c> > <c>Req2.2</c> <c>This</c> > <c>Req2.3</c> <c></c> > > <c>Req3.1</c> <c>Technology Dependant</c> > <c>Req3.2</c> <c>Technology Dependant</c> > <c>Req3.3</c> <c>Technology Dependant</c> > <c>Req3.4</c> <c>Technology Dependant</c> > > <c>Req4.1</c> <c>This</c> > <c>Req4.2</c> <c>This</c> > <c>Req4.3</c> <c><xref target="RFC6775"/></c> > > <c>Req5.1</c> <c></c> > <c>Req5.2</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c> > <c>Req5.3</c> <c></c> > <c>Req5.4</c> <c></c> > <c>Req5.5</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c> > <c>Req5.6</c> <c><xref > target="I-D.struik-lwip-curve-representations"/></c> > <c>Req5.7</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c> > <c>Req5.8</c> <c> </c> > <c>Req5.9</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c> > > <c>Req6.1</c> <c>This</c> > <c>Req6.2</c> <c>This</c> > > </texttable> <!-- end table "Addressing requirements" --> > > TC> OK. > ********************** > > > > Nits: > -------------------------------------- > > p.4 > Section 2 - "form and use multiple addresses" (add multiple) > >> done > > > ********************** > > > > p.4 > Section 2 last para - "their" rather than "his" > >> sorry I do not see this ? the "his" refers to the network admin. TC> In more politically correct British English, you'd say "their" as a gender neutral term, not "his". In the case "their" can be singular. > ********************** > > > > p.6 > "provides new" -> "provide new" > >> done > > ********************** > > > > p.10 > "route-over mesh" - add to definitions section > >> added reference to RFC 6606 in the terminology section > > > > ********************** > > > > p.12 > First line of last para needs rewriting - "If the registry in the 6LBR is be > saturated, in which case the LBR". > >> I had spoted that one too : ) fixed as > > " > If the registry in the 6LBR is saturated, the > LBR cannot guarantee that a new address is effectively not a duplicate. > " > > > ********************** > > > > p.13 > Could forward reference the summary of error codes in 6.1 or 10.3 here? > >> done > > ********************** > > > > p.14 > "removes silently" -> "silently removes" > "LLNs meshes" -> "LLN meshes" > >> done > > > ********************** > > > > p.15 > Code 3; change tense to past tense, e.g. "fails" to "failed" > >> done > > > ********************** > > > > p.19 > "capabilities" -> "capabilities is" > "such address" -> "such an address" > "in a" -> "in" > "6LB" -> "6LN" ? > >> done. > > > ********************** > > > > p.21 > "amlways" -> "always" > "to using" -> "using" > Missing close bracket for See Section 9. > > > > ********************** > > > > p.30 > Do you mean "sequence"? > "serves" -> "serves the" > >> changed to > " This specification extends 6LoWPAN ND to provide a sequence number to > the > registration and ... > " > > ********************** > > > > > p.31 > "timely" -> "in a timely fashion" ? > B.1 last req - reword this. > The BIER Architecture is now an RFC I think? > >> will fix the reference to RFC 8279 TC> All the nit comments / resolutions are fine. > Thanks a bunch again for your deep review Tim! TC> It was a good read, and very interesting. Best wishes, Tim > > Pascal > > > > -----Original Message----- > From: 6lo [mailto:[email protected]] On Behalf Of Tim Chown > Sent: vendredi 16 février 2018 20:03 > To: [email protected] > Cc: [email protected]; [email protected] > Subject: [6lo] Intdir early review of draft-ietf-6lo-rfc6775-update-11 > > Reviewer: Tim Chown > Review result: Almost Ready > > Hi, > > I have performed an early review of draft-ietf-6lo-rfc6775-update-11. > > This draft updates and enhances the mechanisms defined in RFC6775 to support > IPv6 operation over low power networks (6LoWPAN ND). > > Overall the draft is well-written and structured. > > General comments: > -------------------------------------- > > The document could use a glossary of terms: LLN, 6LN, 6LBR, 6LR, BBR, etc. > > The introduction could talk of other new added features, like avoiding DAD for > link locals. > > The document includes RFC 7217 in the references, but doesn't include > discussion of it in the main body of the text. Shouldn't RFC 7217 be > considered the norm here rather than address generation as per RFC 4862? > Related, RFC 8064 "recommends against embedding stable link-layer addresses in > IPv6 Interface Identifiers". The document is inconsistent - it talks of using > EUI64, then in Section 9 not using EUI64. > > Specific comments: > -------------------------------------- > > p.3 > Section 2, para 2 - should ND cache exhaustion attacks be included in the list > here? > > p.4 > Section 3 - Add RFC 7217 to RFC 4862? It's recommended by RFC 8064. > > p.6 > Section 4 - for a node to prefer registering to a 6LR that supports the spec, > it would need to enumerate all available 6LRs; should the process for this be > described here, or is it included in sufficient detail in RFC 6775? > > p.7 > Section 4.1 - "not required to be a MAC address" - as per my general comment > above, with current IETF thinking, should this not be stronger, e.g. "SHOULD > NOT be a MAC address"? Section 9 says this? > > p.9 > Section 4.2, point 4 - I find this quite para quite hard to read. > > p.9 > Section 4.3, para 1 - again, is using EUI-64 desirable? Is the point to allow > header compression as per RFC4944? Discuss the tradeoff? Section 4.3 para 2 - > so a different type of identifier could be an RFC 7217 generated identifier? > > p.11 > Section 4.6 - in the case of two 6LRs with the same link-layer addresses, does > it matter which a 6LN chooses? Is the choice algorithmic? Section 4.6 - the > last para on p.11 seems to be repeated in the first para on p.12? > > p.12 > Section 4.6 - again, is the recommendation to use an (expected to be) unique > LL > address in keeping with RFC 8064? > > p.13 > Para 4 - a Moved message SHOULD be used, yet elsewhere a node MUST clean up > its > stale state? Consistent? What about MIPv6-like spoofing security issues? You > say "an alternate protocol" - isn't this a little hand-wavy; shouldn't a > single > mechanism be defined rather than multiple (undefined) mechanisms? > > p.15 > OUI is a confusing choice of term, given OUIs in MAC addresses; I guess this > is > now baked into RFC 6775 though. > > p.16 > I don't think codes 5 and 10 are explained/defined in any detail here? How is > the challenge made? > > p.16 > The registration lifetime is in minutes; why not in seconds? > > p.18 > Section 6.3 - SHOULD set the E flag; why not a MUST? Why would you support > the > spec, but not advertise that you do? In contrast, on the next page in Section > 7.1.1 you say nodes MUST set it. > > p.19 > Section 7.1.2 para 2 - would a LL address generally be used here as source? > Should that be a SHOULD? Using a temporary address is probably not ideal. > > p.20 > Section 7.3 para 4 - is this consistent with p.19 last para saying a 6LN MUST > use the updated spec once it knows it's supported? The last two paras here are > a bit vague/loose. > > p.21 > Section 8, para 3 - recommends using privacy techniques, but uses EUI64? > > p.22 > Limit the number of addresses? What about RFC 7934? > The type of algorithm described here might be better defined generically for > 6LoWPAN and 'real' IPv6? I don't think anything has been defined for ND cache > exhaustion attack mitigation - would a separate draft be beneficial? I suspect > current solutions are vendor specific? > > p.22 > What trust model? > > p.22 > Section 9 - EUI64, or not EUI64? Inconsistent. > Does anyone really use SeND? Especially in 6LoWPAN networks? > > p.24 > Section 10.3 - statuses 5 and 10 are not detailed in the draft? > > p.30 > The multicast issues text could cite the new mboned draft on this topic. > "Plague" is maybe strong! > > p.30 > Appendix B - can we have a table showing WHICH requirements have been met by > the draft? > > Nits: > -------------------------------------- > > p.4 > Section 2 - "form and use multiple addresses" (add multiple) > > p.4 > Section 2 last para - "their" rather than "his" > > p.6 > "provides new" -> "provide new" > > p.10 > "route-over mesh" - add to definitions section > > p.12 > First line of last para needs rewriting - "If the registry in the 6LBR is be > saturated, in which case the LBR". > > p.13 > Could forward reference the summary of error codes in 6.1 or 10.3 here? > > p.14 > "removes silently" -> "silently removes" > "LLNs meshes" -> "LLN meshes" > > p.15 > Code 3; change tense to past tense, e.g. "fails" to "failed" > > p.19 > "capabilities" -> "capabilities is" > "such address" -> "such an address" > "in a" -> "in" > "6LB" -> "6LN" ? > > p.21 > "amlways" -> "always" > "to using" -> "using" > Missing close bracket for See Section 9. > > p.30 > Do you mean "sequence"? > "serves" -> "serves the" > > p.31 > "timely" -> "in a timely fashion" ? > B.1 last req - reword this. > The BIER Architecture is now an RFC I think? > > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > > _______________________________________________ > Int-dir mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-dir > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
