In perfect agreement with you and Zach's answer. If I might comment on
>2) Using NR/NC exchanges to provide NUD. With the current draft, NR/ >NC exchanges only maintain reachability information for the link-local >address of the attachment router. However, NR/NC exchanges, as >defined, cannot provide reachability information for global >addresses. Additionally, NR/NC messages cannot be used to maintain >reachability information for neighboring hosts (not routers). This is a conscious decision. If we take an 802.11 ad hoc network as an example of a LoWPAN. In this network, RFC4861 is clearly broken but 6LoWPAN ND, complemented with a routing protocol such as RPL, would do a perfect job. Now, if you add an access point and use infra mode, then the nodes start registering to the AP and the AP relays the packets between 2 nodes. If you look at it, the router operation generalizes at L3 the L2 operation of infrastructure mode: * Nodes register to their router and use that router to forward to other nodes. * In route over mode, we have a routing protocol within the subnet that enables topologies that are way more complex and dynamic than a BSS or an ESS. * And Multicast can be supported though it is not needed for ND itself (too costly). * The registration via an edge router is akin to an association in that it defines a set of nodes. The edge router proxies ND in a way that reminds of the transparent bridge operation in an AP. Same causes, same effects, just larger and wider since we place the operation at L3. Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Hui >Sent: lundi 12 octobre 2009 22:01 >To: JP Vasseur (jvasseur) >Cc: 'Carsten Bormann'; '6lowpan' >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > >On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote: >> >> On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote: >> >>> Hello Adam, >>> >>>> Also, one specific question: how would an IPv6 host deal with an >>>> 802.15.4 network interface if the IPv6 adaptation layer would >>>> require >>>> changes to the core of the IPv6 stack to function properly? >>> >>> Having a router in between seems sensible to me. You can get uIPv6 >>> somewhere >>> small, so I don't see having a simple router as a big problem... >> >> I do not think that the issue is the code size itself but a change >> in the architecture, thus >> the reasonable question on whether we could find a simpler approach >> compatible with >> 4861 to handle the case of non transitive links that preserves the >> architecture. > >I do agree that we have to be very careful with the architectural >implications. For me, it's not about whether or not we require an >extra router in between or some extra code. It's more about making >sure we are OK with the proposed simplifications changing the >semantics of ND operations defined (explicitly or implicitly) by RFC >4861. Some examples that come to mind: > >1) Assuming that link-layer addresses can always be computed from >IIDs. While this assumption can remove the need for NS/NA for address >resolution, the implication is that the IIDs are limited to the link- >layer addresses in use. 802.15.4 radio hardware is typically limited >to one short and one extended address at a time and that limits the >number and structure of IIDs that can be assigned at any time. > >2) Using NR/NC exchanges to provide NUD. With the current draft, NR/ >NC exchanges only maintain reachability information for the link-local >address of the attachment router. However, NR/NC exchanges, as >defined, cannot provide reachability information for global >addresses. Additionally, NR/NC messages cannot be used to maintain >reachability information for neighboring hosts (not routers). > >I'm not convinced that these are the only examples that we need to be >aware of with the existing draft. I'm also not convinced that enough >people have weighed in on the examples above to say that such >implications are OK > >-- >Jonathan Hui > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
