Subject: Re: [6lowpan] [Roll] how does a node get an IP address

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Apr 2010 09:01:15 +0200

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-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Tuesday, April 27, 2010 10:36 PM
> To: Richard Kelsey
> Cc: [email-masked]
> 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-masked]>
> >> Date: Tue, 27 Apr 2010 10:38:47 -0400
> >>
> >> >>>>> "Richard" == Richard Kelsey <[email-masked]>
writes:
> >>     >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: "Pascal Thubert
> >>     >> (pthubert)" <[email-masked]>
> >>     >>
> >>     >> 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-masked]
> > https://www.ietf.org/mailman/listinfo/roll
> >
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 29 Apr 2010 09:11:34 +0200

> It seems that we have a reasonable consensus in this thread 
> to do exactly that in RPL anyway...
> 
> Pascal

OK,
So could someone with the full overview outline explain to me
how many mechanisms a RPL node running over 6lowPan will have
to implement to be compatible with all other nodes claiming
to be RPL compliant?

My guess:
* Classic RS/RA
* DHCPv6
* 6lowPAN ND
* RPL address assignment
* etc

Should we make a decision someday? (!)

Thanks,
  Anders

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: Thursday, April 29, 2010 09:01
> To: [email-masked]; Richard Kelsey
> Cc: [email-masked]; [email-masked]
> 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
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Apr 2010 11:22:32 +0200

> Should we make a decision someday? (!)

Anders,

that is indeed a very important point.
We need to get rid of as many of these options as possible.
At least for the baseline expectation.

In the 6LoWPAN context, we need to distinguish three kinds of nodes:

1 -- hosts, which should have absolutely minimal requirements imposed on them;
2 -- router nodes (6LR in ND-09 terminology), which need to be more complex to do routing, so they probably can also implement some additional complexity for other purposes such as bootstrapping;
3 -- edge routers (6LBR in ND-09 terminology), which have multiple interfaces and are more likely to be relatively powerful.

1) Hosts don't participate in RPL, so there cannot be any requirement from RPL on them.
Of course, 6LoWPAN-ND must do everything to enable a host node to participate, and to enable the router node(s) to represent the host in the network (6LoWPAN and/or RPL LLN).

2) Router nodes participate in a routing protocol.  Since RPL does not seem to address mixed networks, from an RPL point of view it can be assumed that they participate in RPL.  But they have only one interface, so that participation can still be governed by 6LoWPAN-based assumptions.

3) Edge routers have multiple interfaces, more than one of which might be engaged in RPL.  Full complexity, likely including DHCPv6 prefix delegation etc.

4) From the point of view of RPL, there is a fourth kind of node: One that has no 6LoWPAN interface.  If that is not using 6LoWPAN-ND, it needs other ways to achieve bootstrapping.  I would not be happy if RPL would grow features that are needed only for bootstrapping this fourth kind of node and still make them mandatory for type 2 nodes (or even try to browbeat type 1 nodes into using them!).

Gruesse, Carsten