Hi, On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote:
> Hi Pascal, > > I fully agree with you. > In my opinion anything spanning multiple IP hops should not be done by ND. That logic doesn't work anymore with route-over LoWPANs. As the prefixes are spanning the whole LoWPAN there is a natural need for ND to help with that. In the case of RPL, the WG may decide to disseminate some things such as prefix information between routers in a LoWPAN using the routing protocol. 6lowpan-nd-09 states clearly that you may do that, so nothing stopping RPL there. What is this argument about? You are complaining about something that is not a problem? Now RPL isn't the only routing protocol.... 6lowpan-nd-09 provides an optional mechanism of using RS/RA for disseminating prefix and context information between all routers in a LoWPAN that is routing protocol independent. Regardless of RPL, this will surely come in handy and some routing protocols may even specify to use this mechanism. Let me remind you of how RPL started by the way. In the beginning the idea was to piggyback RPL information on ND traffic as there were already similar flows. Eventually the WG decided to give RPL its own messages instead of piggybacking as ND options. Now it has gone to the extreme of RPL being the one and only protocol and everything must be carried on that.... Quite a change! Next we could piggyback DHCPv6 on RPL, use RPL for DAD, and what the heck, let's go for DNS too... Starts to sound like a shopping-TV ad for a super-vegetable-processing-miracle doesn't it? > > 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 actually letting the host and router know about each other (router discovery), their reachability (NUD) and their L2 addresses (address resolution). These are all standard features of ND. > 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? Better be, or you just broke an important model of IPv6. I would say it MUST be possible for hosts to attach to a LoWPAN running RPL (and stay blissfully ignorant of RPL). > - Should IPv6 hosts be part of a RPL topology (as leaf node) or should IPv6 > hosts use the 6lowpan-ND host-router spec? ND is clearly the standard host-router interface regardless of IPv6 or 6LoWPAN. Forcing hosts to know anything about RPL would be insane... Zach > > 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 > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
