Robert
Comments: page 5: "DAD of use multicast" - grammar? "from the same prefix can be used" - 'reached' instead of 'used'? page 7:"EUI-64s are globally unique" - What about the case of spoofed/cloned EUI-64s? What would be the effect using this ND? Would it be significant? My guess is probably not but it might be worth making this clear
page 8:"However, the Address Registration mechanism might be useful for other link layer technologies" - I would have thought all the mechanisms and modifications may apply to other link layer technologies
page 9:The process during which a LoWPAN node sends an Neighbor Solicitation message - Is "LoWPAN node" a specific term? If so, needs to be defined. I would also suggest it is called 6LoWPAN Node (6LN?) to be consistent
"that allows for sleeping nodes" - 6LoWPAN nodes? Check for this throughout the document
"initial set of default routers" - This might seem pedantic, but "Router" (with an uppercase R) is defined in this document and "router" (with a lowercase r) is defined in RFC4861 and they are subtly different. Maybe have this consistency across the document
page 10:"which in turn use normal Neighbor Discovery mechanisms to convey this information to the hosts" - I think this is questionable; there are some differences
"DAD is optional if DHCPv6 is used to assign addresses" - Or an alternative address assignment mechanism
page 12:"In this case, the Neighbor Solicitation and Advertisement messages will be forwarded between the 6LR and 6LBRs" - This is overloading the original use of NS/NA as defined in RFC4861 quite a lot and changing the rules. There seemed to be resistance to defining a new message but wouldn't that actually be better?
page 16:C: 1-bit context compression flag - I would add the proposed text at the end of the definition to make it clear what this flag is for: "This flag is used to manage the context lifecycle based on the recommendations in Section 7.2"
page 18:"and sent to the IPv6 All-Routers multicast address" - There is also a case for being able to send unicast as it is possible the host has discovered which router it wishes to join the network through by other means, e.g. 802.15.4 beacon request. This could potentially limit traffic. Section 5.8.2 also says it can be sent unicast.
page 19:"This includes the Context ID, the prefix" - Possibly some confusion between the context prefix and the prefix in the PIO. Maybe clarfication on the terminology is needed.
page 21:"or the appropriate IP-over-foo document" - Is this a well-known phrase in the IETF community? :-)
page 25:"then care should be taken to ensure that there isn't a flood of ARO-carrying messages **sent** to the 6LBR as each router hears an ARO from their neighboring routers" - Is this likely to happen with a unicast to 6LBR? (** typo 'send' -> 'sent' **)
page 28:"then the RA MUST be silently ignored" - "Silently ignored" is a tautology. Either "silently discarded" or simply "ignored"
page 29:"The routers periodically send Router Advertisements" - "may periodically send"? It is optional, isn't it? Also might be worth mentioning this information could be disseminated by other mechanisms.
page 30:8.2.1. Special Message Validation - This is a rather complex rule for NS/NA processing as the hop limit processing may well happen before payload processing. Could it be made simpler or more logical?
page 31:"It proceeds to look for the Registration Address in the DAD Table. If an entry is found and the recorded EUI-64 is different than the EUI-64 in the ARO, then it returns an NA with the ARO Status set to 1 ('Duplicate Address'). Otherwise it returns an NA with ARO Status set to zero." - It would be really nice if it could also return a 'suggested address'. This would complete address assignment without the host having to guess again.
page 33:Figure 3: Do you need the 'NS' and 'NA' component in the diagram? It makes it inconsistent with Figure 2.
Typos: The change is bracketed by <span class=hilite></span> page 7:Optimize Neighbor Discovery with <span class=hilite>mechanisms that are</span> minimal yet sufficient for the operation in both mesh-under and route-over configurations.
<span class=hilite>Provide s</span>upport for sleeping hosts.<span class=hilite>Provide an o</span>ptional duplicate address detection mechanism suitable for route-over LoWPANs
page 8:Note that nothing in this document precludes a node <span class=hilite>being</span> a router on some interfaces
page 9:In a mesh-under configuration only <span class=hilite>6LBRs</span> and hosts exist; there are no <span class=hilite>6LRs</span> in mesh-under topologies
The most important part of the <span class=hilite>optimizations</span> is the evolved host-to-router interaction that allows for sleeping
page 11: In an isolated <span class=hilite>LoWPAN,</span> a ULA page 19: The host SHOULD unicast <span class=hilite>a</span> Router SolicitationUnicast Neighbor Solicitation (NS) messages are <span class=hilite>sent</span> by hosts
page 21:Link-layer addresses for neighbors are stored in Neighbor Cache entries [<A href="http://tools.ietf.org/html/rfc4861"; title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</A><span class=hilite>]. </span>In order to achieve LoWPAN compression
page 23:in the Router Advertisement messages it sends.<span class=hilite> If</span> the 6LR has <span class=hilite>received RAs from different 6LBRs, with the same or different prefixes and context information, </span> then it will
page 24:Section 8.2</A> <span class=hilite>specifies</span> optional behavior for a 6LBR for other
If the NS contains a valid ARO, then the router inspects its Neighbor Cache on the arriving interface to see if it is a duplicate. <span class=hilite>If there is no Neighbor Cache entry for the IPv6 source address of the NS or if there is such a Neighbor Cache entry and the EUI-64 is the same, then it isn't a duplicate. Otherwise it is a duplicate address.</span>
page 25:When routers use ARO to register with each other and the optional DAD to the 6LBR <span class=hilite>is in use (<A href="http://tools.ietf.org/html/draft-ietf-6lowpan-nd-09#section-8.2";>Section 8.2</A>),</span> then care should be taken to ensure that there isn't a flood of ARO-carrying messages <span class=hilite>sent</span> to the 6LBR as each router
page 27:Optionally the Router Advertisement messages can be used to disseminate <span class=hilite>prefixes and contexts</span> to all
page 28:then the routers follow [<A href="http://tools.ietf.org/html/rfc4861"; title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</A>]<span class=hilite>, which</span> states that they merely do some
it sends the 'expiry time'<span class=hilite>, preventing accidentally moving</span> further into the future. For example, if a 6CO with a Valid lifetime of 10 minutes is <span class=hilite>received</span> at time T, and the router includes this in a RA it sends at time T+5 minutes
If multihop distribution is performed using RA messages, then the routers MUST ensure that the ABRO always <span class=hilite>stays</span> together
page 29:<span class=hilite>The routers</span> also respond to Router Solicitations by unicasting RA messages
page 30:Neighbor Cache. <span class=hilite>This conceptual data structure is called the DAD table.</span> It is indexed by
page 31:When a 6LBR that implements the optional multihop DAD receives an NS from a 6LR, <span class=hilite>which contains</span> an ARO with Length = 4, then it MUST NOT verify that the hop limit is 255 as specified above. <span class=hilite>It</span> proceeds to look for the Registration Address in the DAD Table
page 33:one might want to use <span class=hilite>Secure</span> Neighbor Discovery <span class=hilite>(SeND)</span>
-- Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
