Hi Pascal, I fully agree with you. In my opinion anything spanning multiple IP hops should not be done by ND.
On a related topic.... 6lowpan network have the particularity that you cannot use on-link prefix due to the non-transitivity of the wireless links. This means we need to tell routers how to reach neighboring IPv6 hosts. So essentially 6lowpan-ND is using a registration mechanism to establish a "route" between the router and the host. It is not clear to me whether this is the role of ND or of the routing protocol. I think it could actually be both. Hence the questions: - Are IPv6 hosts possible in a 6lowpan network where the RPL protocol is used? - Should IPv6 hosts be part of a RPL topology (as leaf node) or should IPv6 hosts use the 6lowpan-ND host-router spec? Best, Mathilde -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pascal Thubert (pthubert) Sent: jeudi, 29. avril 2010 09:01 To: [email protected]; Richard Kelsey Cc: [email protected]; [email protected] Subject: Re: [Roll] how does a node get an IP address Hi Zach: I have yet to review the new ND-09 but my guts tell me that it is the wrong place to do the job. Router to router is usually routing protocol land and ND is definitely not a routing protocol. The main question is how long can a router advertise a prefix, and the answer is, as long as it is in the same subnet of an authoritative router that owns the prefix. Asserting the continuous reachability of the authoritative router is a routing protocol problem. Maintaining a subnet together is the job for a new form of Gateway Protocol, a Subnet Gateway Protocol RPL is just that. Let see: - Propagating the RA content is not an ND intrinsic problem, it only comes with route over. And route over comes with a routing protocol. - the route over protocol should be able to tie the route over subnetwork together so it is a SGP. So why can't we just say in 6LoWPAN ND that you for those who use it in route over we expect an SGP to tie the route over subnetwork together and that the SGP should transport the RA content, maintaining the validity with the reachability of the authoritative router? I can write that text if you wish. It seems that we have a reasonable consensus in this thread to do exactly that in RPL anyway... Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, April 27, 2010 10:36 PM > To: Richard Kelsey > Cc: [email protected] > Subject: Re: [Roll] how does a node get an IP address > > Hi Everyone, > > Let me jump into this thread - just to make things more interesting ;-) First, I > recommend everyone goes and reads 6lowpan-nd-09 which was submitted > today. When it comes to ND, you need to separate two interfaces. > > 1. The host-router interface > > Hosts know absolutely nothing about RPL (nor should they). Thus in this case > ND* does the job, and RS/RA is used for obtaining a prefix and initializing its > addresses. I think some people in the thread are referring to this. > > 2. The router-router interface > > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than hosts in > how they obtain prefix information (among other things). nd-09 does include > an optional technique for an authorative border router to disseminate PIOs > and CIOs (Context Information Options) between the border router and all > routers in the LoWPAN using RAs. It is actually a decent mechanism and > improved over early versions. The draft clearly states that it is optional as a > routing algorithm may already do this. So Pascal is correct in that respect. I > haven't followed the thread well enough to have an opinion if RPL should do > that. > > Routers will also find other features of 6lowpan-nd-09 useful, for example > during initial bootstrapping, to maintain their default router and neighbor > caches, avoid the need for address resolution, and to perform NUD. The > draft (tries to) clearly state when features are required or optional for a > router. > > Zach > > > >> From: Michael Richardson <[email protected]> > >> Date: Tue, 27 Apr 2010 10:38:47 -0400 > >> > >> >>>>> "Richard" == Richard Kelsey <[email protected]> writes: > >> >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert > >> >> (pthubert)" <[email protected]> > >> >> > >> >> The question here is that the authoritative routers need to > >> >> disseminate the PIO (and the RIO) to all routers in the subnet. > >> > >> Richard> How do other routing protocols (OSPF, IS-IS, AODV, OLSR) > >> > >> I can only speak for OSPF and ISIS. > >> Neither deal with multi-hop subnets or with any kind of address > >> assignment. > > > > Why should RPL be any different? Yes, it will be run on multi-hop > > subnets, but I still do not see how this affects the routing. > > > >> Both were written when multicast was very new. > > > > I am not sure how RPL's handling of multicast matters here. > > While RPL is required to route multi-hop multicasts, ND uses > > link-local multicasts, which do not require routing. > > > >> Richard> I understand that multi-hop subnets are a problem for ND, > >> Richard> but I don't see how the routing protocol is affected. > >> > >> RPL either requires 6lowpan, or it doesn't. > > > > RPL should work fine with ordinary ND. Why would it require 6lowpan? > > > >> If it doesn't, then it has to provide for ND to work, or for another > >> protocol to replace it. > > > > ND works fine, using link-local, one-hop multicasts. RPL need not be > > involved. > > > > If someone wants to run RPL on a node that uses neither ordinary ND or > > 6lowpan's version, then they will need some third variety of ND. I do > > not see why this is an issue for RPL to address. It seems quite out > > of scope. > > > > -Richard Kelsey > > _______________________________________________ > > Roll mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list [email protected] https://www.ietf.org/mailman/listinfo/roll
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
