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

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Apr 2010 09:59:41 -0400

There is something which I thought I knew, and upon further
consideration, I realized I was wrong.

This is specifically what prefix a node (whether leaf or internal)
(auto-)configures for itself.
In a normal network, this would be done with RS/RA.

I'm unclear if RS/RA is the right thing --- if it is, then every
internal node needs to send out RAs.  When RPL was operating as a ND
option, I could imagine also including it in the RA messages, reducing
the number of messages that need to be sent.

Then I thought that the destination prefix from the DODAG root indicated
the prefix that this DODAG should operate with, but that's wrong --- the
destination prefix indicates connectivity, not self.

So my question is: how does a node get a non-link-local address?
One presumes that it needs such a thing in order to communicate with the
outside for any of the P2MP applications.

(I realize that 6lowpan has some answers, but it has two modes, and I'm
pretty sure that it can provide RA/RS functionality only in one mode)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Apr 2010 20:13:35 +0200

Good question!

In fact we have the problem at 6LoWPAN, when wan a router safely
announce a prefix for autoconf.
An answer can be, as long as it is still tightly coupled with an
authoritative router that owns that prefix, the coupling insuring that
both routers are still in a same subnet.
Typically a RPL instance could tie together a subnet. We can really
easily extend the DAG Destination Prefix to mean either an external
prefix that is reachable through the root OR an internal prefix that the
root owns and that spreads over the DODAG. Here's proposed text for
this:

"

5.4.4.  Destination Prefix

   The Destination Prefix option format is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 3    |      option Length            |R|rsv|Prf| rsv |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Sequence    | Prefix Length |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |             Destination Prefix (Variable Length)              |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 13: DAG Destination Prefix

   The Destination Prefix option is used in DIO to indicate that
   connectivity to the specified destination prefix is available from
   the DODAG root.  A RA (R) flag indicates whether the DODAG is part of
   the subnet where the prefix is deployed and influences the way the
   prefix may be presented to the hosts by RPL routers in RA messages.
   This may be useful in cases where more than one LBR is operating
   within the LLN and offering connectivity to different administrative
   domains, e.g. a home network and a utility network.  In such cases,
   upon observing the Destination Prefixes offered by a particular
   DODAG, a node MAY decide to join multiple DODAGs in support of a
   particular application.

   The option Length is coded as the length of the option in octets,
   excluding the Type and Length fields.

   Prf is the Route Preference as in [RFC4191].  The reserved fields
   MUST be set to zero on transmission and MUST be ignored on receipt.

   If the R flag is set, then the DODAG is part of the subnet where the
   prefix is deployed.  The prefix may be advertised as not onlink in RA
   messages for the purpose address autoconfiguration.  If the R flag is
   reset, then the prefix is exterior to the DODAG yet may be reached
   via the root.  The prefix may be advertised in RA messages for
   communicating default router preferences and more-specific routes
   from routers to hosts as prescribed in [RFC4191] with the preference
   in the Prf field.

   The Prefix Lifetime is a 32-bit unsigned integer representing the
   length of time in seconds (relative to the time the packet is sent)
   that the Destination Prefix is valid for route determination.  The
   lifetime is initially set by the node that owns the prefix and
   denotes the valid lifetime for that prefix (similar to
   AdvValidLifetime [RFC4861]).  The value might be reduced by the
   originator and/or en-route nodes that will not provide connectivity
   for the whole valid lifetime.  A value of all one bits (0xFFFFFFFF)
   represents infinity.  A value of all zero bits (0x00000000) indicates
   a loss of reachability.

   The Prefix Length is an 8-bit unsigned integer that indicates the
   number of leading bits in the destination prefix.

   The Destination Prefix contains Prefix Length significant bits of the
   destination prefix.  The remaining bits of the Destination Prefix, as
   required to complete the trailing octet, are set to 0.

   In the event that a DIO message may need to specify connectivity to
   more than one destination, the Destination Prefix option may be
   repeated.

"

What do you think?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Michael Richardson
> Sent: Friday, April 23, 2010 4:00 PM
> To: IETF ROLL
> Subject: [Roll] how does a node get an IP address
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
consideration, I
> realized I was wrong.
(auto-
> )configures for itself.
internal node
> needs to send out RAs.  When RPL was operating as a ND option, I could
> imagine also including it in the RA messages, reducing the number of
> messages that need to be sent.
> 
>    Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBS9GnzICLcPvd0N1lAQKppggApEM4CxkSoBiHfVgCfyfRcSWlNoKK35
> sZ
> oSYmqLRX2eTucSD22/QqmwURXM+0Ygd6v8khCu/rNR+A+3h7dWO9v6b7Z+
> GDgWP0
> 9wZR8FrQn2tIvkEfnFGMHWxe8w7r1QbNRJBwj2GqdXtIDkvmO6vm5NRn6fglf
> n9a
> FW7o9lmyKNArMgdtR2yF0DSkallDpeEWXeq1URKrLBTYXHjseQzPujfktVGHJ9
> xD
> RDC45kfOEkdr6sGGPMgxcl+QkcA0ANrBz/1iY3GNTtSiobvRZoaJnM2L/rO4At08
> yWeh+vqW4Ujs63UJcur0eZBW/B3RTiEBl+pqMBW96fauM47UR5vzkg==
> =hQr6
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Apr 2010 20:37:37 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Good question!

    Pascal> In fact we have the problem at 6LoWPAN, when wan a router

s/wan/can/ ??

    Pascal> safely announce a prefix for autoconf.  An answer can be, as
    Pascal> long as it is still tightly coupled with an authoritative
    Pascal> router that owns that prefix, the coupling insuring that
    Pascal> both routers are still in a same subnet.  Typically a RPL
    Pascal> instance could tie together a subnet.

So, what I think you are saying is that having RPL nodes sending out RAs
themselves is frought with issues, and there are some situations where
it is in fact the right answer?

But, I think you are saying, in order to cover all situations more
clearly, we are going to overload the Destination Prefix option, and you
then provide a proposed format for it.

Before we discuss the solution, I'd like to get clear agreement from the
WG that I've properly understood the problem.

I do wonder if adding the (R) flag is better than having a new option.
It seems that there are really two distinct activities here:
   a) configuring a local address 
   b) announcing routability information out of the DODAG.

- --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Apr 2010 12:20:31 +0200

Hi Michael:

You're right. So back to basics:

- we have a problem providing Route Information Option (RIO defined in
RFC 4191) and Prefix Information Option (PIO defined in RFC 4861) in RAs
sent out by RPL routers.
- we can expect that there are authoritative routers in the RPL network
that already know what to do there. We could assert that they should be
roots since roots are providing such info already.
- we figure ripples and trickles are well fit to propagate the knowledge
of those prefixes and the right to use it.
- we have something like a RIO in RPL today called the Destination
Prefix subOption in the DIO message.

What can we do from there
- overload existing DPO like I proposed. That's the minimum change but
lacks some info present in PIO like lifetimes.
- Define a new option for use in DIO that looks more like a PIO
- Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.
- other?

What do you think?

Pascal

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 26, 2010 2:38 AM
> To: Pascal Thubert (pthubert)
> Cc: IETF ROLL; Erik Nordmark
> Subject: Re: [Roll] how does a node get an IP address
> 
> iQEVAwUBS9TgUICLcPvd0N1lAQJWZgf/W720qtYVfcAxTOZPhmhbjo6utJeLof1
> J
> ATQXq4b/vluxNfx/pJXG0/2BeC2Qj9ga2X1E9HZzl/RBXj5kDxyCY+KCR2GCxDVx
> oWcGeNP6zQTuwWlBbfIVoezjv8RyrKhSEUtudvX+srk+u/1GKpwUsacigkobbC
> RH
> hqlwzwBW3sxdWluUE98gS8NcxOyFbnDXmnMvPVwDbSOVQbwXy4X14k2E2
> VV+6L6J
> o7Cc4i0TxSra6PbosnGz0qc/S9tMiYDA3vKLPQdgRqKC53pd4aHmdgert9wYu8rE
> TolP9l9JiMt+m1PlaEB7vtdoJylpDRiWhgvW+aTQiSeQy8gHEJFFJA==
> =eFYy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Apr 2010 08:57:55 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Hi Michael:

    Pascal> You're right. So back to basics:

    Pascal> - we have a problem providing Route Information Option (RIO
    Pascal> defined in RFC 4191) and Prefix Information Option (PIO
    Pascal> defined in RFC 4861) in RAs sent out by RPL routers.

    Pascal> - we can expect that there are authoritative routers in the
    Pascal> RPL network that already know what to do there. We could
    Pascal> assert that they should be roots since roots are providing
    Pascal> such info already. 

    Pascal> - we figure ripples and trickles are well fit to propagate
    Pascal> the knowledge of those prefixes and the right to use it.

    Pascal> - we have something like a RIO in RPL today called the Destination
    Pascal> Prefix subOption in the DIO message.

    Pascal> What can we do from there
    Pascal> - overload existing DPO like I proposed. That's the minimum
    Pascal> change but lacks some info present in PIO like lifetimes.

    Pascal> - Define a new option for use in DIO that looks more like a PIO

I prefer this. The prefix lifetimes are important for renumbering.
Let's crib the entire PIO, pretty much as-is.

I'm agnostic about replacing the DestinationPrefix with a literal
RIO. It seems like a good symmetry though.

- --

---

From: Robert Cragie <[email-masked]>
Date: Mon, 26 Apr 2010 14:02:17 +0100

Hi Michael, Pascal,

Good to see this being discussed! My preference would be:

Allow DIO to transport existing PIO and RIO. Get rid of DPO  that's
obsoleted by RIO.

This then makes DIO more a general purpose message with controlled 
propagation based on DODAG. This then eliminates the need for some of 
the more complex parts of ND for 6LRs/6LBRs which use RPL.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

On 26/04/2010 11:20 AM, Pascal Thubert (pthubert) wrote:
>>>>>>> "Pascal" == Pascal Thubert<(pthubert)"<[email-masked]>>
>>>>>>>                
>> writes:
>>      Pascal>  Good question!
>>
>>      Pascal>  safely announce a prefix for autoconf.  An answer can be,
>>      
> as
>    
>> So, what I think you are saying is that having RPL nodes sending out
>>      
> RAs
>    
>> clearly, we are going to overload the Destination Prefix option, and
>>      
> you
>    
>> Before we discuss the solution, I'd like to get clear agreement from
>>      
> the
>    
>> ]       He who is tired of Weird Al is tired of life!           |
>>      
> firewalls  [
>

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 26 Apr 2010 15:17:48 +0200

Just to be sure I understand you guys:
 
Do you mean to mix up IP subnet/address assignment with the actual
routing protocol?
I would expect the IP address assignment should be agnostic whether mesh
under, RPL or RPLvX is the current routing engine?
 
Thanks,
  Anders

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Robert Cragie
	Sent: Monday, April 26, 2010 15:02
	To: [email-masked]
	Subject: Re: [Roll] how does a node get an IP address

	Hi Michael, Pascal,

	Allow DIO to transport existing PIO and RIO. Get rid of DPO
that's
	obsoleted by RIO.
	This then makes DIO more a general purpose message with
controlled propagation based on DODAG. This then eliminates the need for
some of the more complex parts of ND for 6LRs/6LBRs which use RPL.
	
	Robert

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

		Hi Michael:

		- we have a problem providing Route Information Option
(RIO defined in
		RFC 4191) and Prefix Information Option (PIO defined in
RFC 4861) in RAs
		sent out by RPL routers.
		- we can expect that there are authoritative routers in
the RPL network
		that already know what to do there. We could assert that
they should be
		roots since roots are providing such info already.
		- we figure ripples and trickles are well fit to
propagate the knowledge
		of those prefixes and the right to use it.
		- we have something like a RIO in RPL today called the
Destination
		Prefix subOption in the DIO message.
		
		What can we do from there
		- overload existing DPO like I proposed. That's the
minimum change but
		lacks some info present in PIO like lifetimes.
		- Define a new option for use in DIO that looks more
like a PIO
		- Allow DIO to transport existing PIO and RIO. Get rid
of DPO  that's
		obsoleted by RIO.
		- other?
		
		What do you think?
		
		Pascal

			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]]
			Sent: Monday, April 26, 2010 2:38 AM
			To: Pascal Thubert (pthubert)
			Cc: IETF ROLL; Erik Nordmark
			Subject: Re: [Roll] how does a node get an IP
address
			
			-----BEGIN PGP SIGNED MESSAGE-----
			Hash: SHA1

				"Pascal" == Pascal Thubert <(pthubert)"
<[email-masked]> <mailto:[email-masked]> >

			writes:
			    Pascal> Good question!
			
			    Pascal> In fact we have the problem at
6LoWPAN, when wan a router
			
			s/wan/can/ ??
			
			    Pascal> safely announce a prefix for
autoconf.  An answer can be,

		as

			    Pascal> long as it is still tightly coupled
with an authoritative
			    Pascal> router that owns that prefix, the
coupling insuring that
			    Pascal> both routers are still in a same
subnet.  Typically a RPL
			    Pascal> instance could tie together a
subnet.
			
			So, what I think you are saying is that having
RPL nodes sending out

		RAs

			themselves is frought with issues, and there are
some situations where
			it is in fact the right answer?
			
			But, I think you are saying, in order to cover
all situations more
			clearly, we are going to overload the
Destination Prefix option, and

		you

			Before we discuss the solution, I'd like to get
clear agreement from

		the

			I do wonder if adding the (R) flag is better
than having a new option.
			It seems that there are really two distinct
activities here:
			   a) configuring a local address
			   b) announcing routability information out of
the DODAG.
			
			- --
			]       He who is tired of Weird Al is tired of
life!           |

		firewalls  [

			]   Michael Richardson, Sandelman Software
Works, Ottawa, ON    |net
			architect[
			] [email-masked]
http://www.sandelman.ottawa.on.ca/
			|device driver[
			   Kyoto Plus: watch the video
			<http://www.youtube.com/watch?v=kzx1ycLXQSE>
<http://www.youtube.com/watch?v=kzx1ycLXQSE> 
				               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Apr 2010 09:43:15 -0400

>>>>> "Anders" == Anders Brandt <[email-masked]> writes:
    Anders> Just to be sure I understand you guys:

    Anders> Do you mean to mix up IP subnet/address assignment with the actual
    Anders> routing protocol?

Yes, because the ability to reach the authoritative RS depends upon the
routing protocol.  

Otherwise, we are left with using link-local addresses for everything,
as that may be all that is valid.

- --

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 26 Apr 2010 15:03:54 +0100

Isn't IP and subnet assignment replacing functionality that should be in 
ND?

The majority of ROLL implementations I know of at the moment are 
targeting 6LowPAN and there is a 6LowPAN ND draft in progress that 
covers subnet assignment and router discovery.

Daniel.

Michael Richardson wrote:
> iQEVAwUBS9WYcoCLcPvd0N1lAQIMgwf/dVQ4zDrERMFWIXmeMIgqcJPlA7c/d9it
> uNCh6VyGrG1m2VX/A6GtM+IBOIQk8en5oUO6tjPxMwpDiUZBu1Jnd3q+b4Oo85JM
> +fK/2zacoZFxHVFoBfHnVomJq5M4CHJKZz6I0HmbcruzaSfGlEWHTJPenq5ysxgm
> KBWsWhgxMOGoreVntgeISPEIgXZb9pEuZSrvBnPw6W84FT8DhedS+jbeCE303Vmt
> sE+suJ5hbqGjM4AvtXiujrulv1cy6GC4Pn8UUOcx9UWKRZ6jFcADi+Jg1+8nc9Zt
> yc3HkortQtctKVmDtJjcCgLfyEO4X0HvRLIAjY1IRPRl7h1wAfMNvQ==
> =r2ht

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: Robert Cragie <[email-masked]>
Date: Mon, 26 Apr 2010 15:11:51 +0100

Not mix up as such but provide the option for it to be carried by 
alternative means than RS/RA, which is (still) very 'on-link' centric. 
If the routing protocol provides the ability to naturally disseminate 
information, we should be able to use that.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 26/04/2010 2:17 PM, Anders Brandt wrote:
> I would expect the IP address assignment should be agnostic whether 
> mesh under, RPL or RPLvX is the current routing engine?
> Thanks,
>   Anders
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Robert Cragie
>     *Sent:* Monday, April 26, 2010 15:02
>     *To:* [email-masked]
>     *Subject:* Re: [Roll] how does a node get an IP address
>
>     Hi Michael, Pascal,
>
>     propagation based on DODAG. This then eliminates the need for some
>     of the more complex parts of ND for 6LRs/6LBRs which use RPL.
>
>     Robert
>
>>>     From:[email-masked]  [mailto:[email-masked]]
>>>     ][email-masked]  http://www.sandelman.ottawa.on.ca/
>>>     |device driver[

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Apr 2010 10:15:21 -0400

>>>>> "Daniel" == Daniel Gavelle <[email-masked]> writes:
    Daniel> Isn't IP and subnet assignment replacing functionality that
    Daniel> should be in ND? 

    Daniel> The majority of ROLL implementations I know of at the moment
    Daniel> are targeting 6LowPAN and there is a 6LowPAN ND draft in
    Daniel> progress that covers subnet 
    Daniel> assignment and router discovery.

I am not targetting 6lowpan, nor does RPL make that assumption.

If you have working ND, then great.  Last I read, one mode of 6lowpan
won't have working ND until RPL finishes, and as far as I can see,
configuring an IP address is an important part of joining a DODAG.

- --

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 26 Apr 2010 17:19:24 -0700

Hi Daniel/Anders and all,

ND?
> 
> The majority of ROLL implementations I know of at the moment are targeting
> 6LowPAN and there is a 6LowPAN ND draft in progress that covers subnet
> assignment and router discovery.
> 

[SC>] 

Yes.  The network address-assignment will be done either through ND
auto-configuration or DHCPv6 typically.
Roll runs on route-over topology - thus in this case 6lowpan-nd has a
mechanism for disseminating a unique Ipv6 prefix across the 6lowpan network.

Note, 6LRs are nothing but forwarding nodes in ROLL network. 6LBR is the
entity which is responsible for Ipv6-address deligation and making sure that
the address assignment is reliable. 6LBRs are also responsible for
forwarding packets from one LLN to another.

So the idea is that once the addresses are assigned and neighbors' addresses
are known, these information may be conveyed to the routing protocol. Thus
RPL should be able to find out from neighbor cache information about the
reachability of nexthop routers.

Thanks,
-Samita

> > Yes, because the ability to reach the authoritative RS depends upon
> > the routing protocol.
> >
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371
> Registered In England http://www.jennic.com

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 26 Apr 2010 17:49:21 -0700

Hi Robert,

As per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be
off-link and in that case, the packets are always forwarded to the
default-router  and direct delivery from host-to-host are not done.
6lowpan-nd auto-configuration always assumes that the nodes are off-link and
use the default-router to be the forwarder.

When RPL or a routing protocol is running, the default-router functionality
will be unlikely  needed  if all nodes are running RPL code. However, the
initial address assignment/dissemination among all nodes are still possible
using 6lowpan-nd simple mechanism for address dissemination and address
auto-configuration. But one can decide to choose some other mechanism as
well such as dhcpv6, static configuration etc.

-Samita

Not mix up as such but provide the option for it to be carried by
alternative means than RS/RA, which is (still) very 'on-link' centric. If
the routing protocol provides the ability to naturally disseminate
information, we should be able to use that.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Do you mean to mix up IP subnet/address assignment with the actual routing
protocol?

Thanks,

  Anders

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Cragie
Sent: Monday, April 26, 2010 15:02
To: [email-masked]
Subject: Re: [Roll] how does a node get an IP address

Hi Michael, Pascal,

This then makes DIO more a general purpose message with controlled
propagation based on DODAG. This then eliminates the need for some of the
more complex parts of ND for 6LRs/6LBRs which use RPL.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Michael:

 
 
What do you think?
 
Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address

"Pascal" == Pascal Thubert <(pthubert)"  <mailto:[email-masked]>
<[email-masked]>>

writes:
    Pascal> Good question!

s/wan/can/ ??

as

RAs

you

the

 
- --

firewalls  [

]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/
|device driver[
   Kyoto Plus: watch the video
 <http://www.youtube.com/watch?v=kzx1ycLXQSE>
<http://www.youtube.com/watch?v=kzx1ycLXQSE>
                      then sign the petition.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 27 Apr 2010 14:18:32 +0200

Hi Samita:

It does not appear that you're answering the right question. 

The question here is that the authoritative routers need to disseminate
the PIO (and the RIO) to all routers in the subnet.

Neither the 6loWPAN ND nor your ND simple has a good story for this.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Samita Chakrabarti
Sent: Tuesday, April 27, 2010 2:49 AM
To: [email-masked]; 'Anders Brandt'
Cc: [email-masked]
Subject: Re: [Roll] how does a node get an IP address

Hi Robert,

As per rfc4861, 4862, while RS/RA are on-link. RS , the prefix could be
off-link and in that case, the packets are always forwarded to the
default-router  and direct delivery from host-to-host are not done.
6lowpan-nd auto-configuration always assumes that the nodes are off-link
and use the default-router to be the forwarder.

When RPL or a routing protocol is running, the default-router
functionality will be unlikely  needed  if all nodes are running RPL
code. However, the initial address assignment/dissemination among all
nodes are still possible using 6lowpan-nd simple mechanism for address
dissemination and address auto-configuration. But one can decide to
choose some other mechanism as well such as dhcpv6, static configuration
etc.

-Samita

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Thanks,

  Anders

	Hi Michael, Pascal,

	
	Robert

	Gridmerge Ltd.
	89 Greenfield Crescent,
	Wakefield, WF4 4WA, UK
	+44 (0) 1924 910888

	Hi Michael:

	- we have a problem providing Route Information Option (RIO
defined in
	RFC 4191) and Prefix Information Option (PIO defined in RFC
4861) in RAs
	sent out by RPL routers.
	- we can expect that there are authoritative routers in the RPL
network
	that already know what to do there. We could assert that they
should be
	roots since roots are providing such info already.
	- we figure ripples and trickles are well fit to propagate the
knowledge
	of those prefixes and the right to use it.
	- we have something like a RIO in RPL today called the
Destination
	Prefix subOption in the DIO message.
	 
	What can we do from there
	- overload existing DPO like I proposed. That's the minimum
change but
	lacks some info present in PIO like lifetimes.
	- Define a new option for use in DIO that looks more like a PIO
	- Allow DIO to transport existing PIO and RIO. Get rid of DPO
that's
	obsoleted by RIO.
	- other?
	 
	What do you think?
	 
	Pascal

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]]
		Sent: Monday, April 26, 2010 2:38 AM
		To: Pascal Thubert (pthubert)
		Cc: IETF ROLL; Erik Nordmark
		Subject: Re: [Roll] how does a node get an IP address
		 
		-----BEGIN PGP SIGNED MESSAGE-----
		Hash: SHA1

		writes:
		    Pascal> Good question!
		 
		    Pascal> In fact we have the problem at 6LoWPAN, when
wan a router
		 
		s/wan/can/ ??
		 
		    Pascal> safely announce a prefix for autoconf.  An
answer can be,

	as

		    Pascal> long as it is still tightly coupled with an
authoritative
		    Pascal> router that owns that prefix, the coupling
insuring that
		    Pascal> both routers are still in a same subnet.
Typically a RPL
		    Pascal> instance could tie together a subnet.
		 
		So, what I think you are saying is that having RPL nodes
sending out

	RAs

		themselves is frought with issues, and there are some
situations where
		it is in fact the right answer?
		 
		But, I think you are saying, in order to cover all
situations more
		clearly, we are going to overload the Destination Prefix
option, and

	you

		Before we discuss the solution, I'd like to get clear
agreement from

	the

		I do wonder if adding the (R) flag is better than having
a new option.
		It seems that there are really two distinct activities
here:
		   a) configuring a local address
		   b) announcing routability information out of the
DODAG.
		 
		- --
		]       He who is tired of Weird Al is tired of life!
|

	firewalls  [

		]   Michael Richardson, Sandelman Software Works,
Ottawa, ON    |net
		architect[

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 27 Apr 2010 14:21:46 +0200

OK then, 

I'll add my vote to yours and Robert's to transport the RIO and PIO as
the exist and remove the DPsO that's obsoleted by the RIO.
Anybody else?

Pascal

> Sent: Monday, April 26, 2010 2:58 PM
> Cc: IETF ROLL; Erik Nordmark; Zach Shelby
> I'm agnostic about replacing the DestinationPrefix with a literal RIO.
It seems
> like a good symmetry though.
> 
> - --
firewalls  [
> iQEVAwUBS9WN0YCLcPvd0N1lAQJ0tgf/T3/AZRGc7tQ5RRj5O/iBFCy++BmON5
> to
> C6g5FxAYHwMpj2jKtRqQXV5NNYUZPE2RK3egv8rZT1/QKSYLeMcFAytJDh23o
> pNv
> 192lP8mkN8PFwYAWbcuJTpC5LZ/B5IdMpAmoOOp5xWaivo0j9BXvV4hXfEbO
> eAkQ
> BYe/Ot8s6jgdTr6FGGuOUtkA3Sizdm8RxuT4n7EvXlDluSKsTJh5ynSIYw2VIPqm
> Nt4GK34Q188G4CFXM6s+TPCrAxmCprFuOl7g3VhOCl+vW2x55v3TvuaTRrS8LZ
> a+
> wpi24AKyVlQ9DEYz1SC9ueDCLbaWPoYrk57Jo6QF7FmmZDHaS8RAEQ==
> =lklj

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Apr 2010 09:43:14 -0400

{I never saw Samita's email on the list, only in reply}

    Samita> Hi Robert,

    Samita> As per rfc4861, 4862, while RS/RA are on-link. RS , the
    Samita> prefix could be off-link and in that case, the packets are
    Samita> always forwarded to the default-router and direct delivery
    Samita> from host-to-host are not done.  6lowpan-nd
    Samita> auto-configuration always assumes that the nodes are
    Samita> off-link and use the default-router to be the forwarder.

    Samita> When RPL or a routing protocol is running, the
    Samita> default-router functionality will be unlikely needed if all
    Samita> nodes are running RPL code. However, the initial address
    Samita> assignment/dissemination among all nodes are still possible
    Samita> using 6lowpan-nd simple mechanism for address dissemination
    Samita> and address auto-configuration. But one can decide to choose
    Samita> some other mechanism as well such as dhcpv6, static
    Samita> configuration etc.

As Pascal said, you are answering the wrong question.
The question is, rephrased against above:
    a) where does the default router come from?
    b) or more to the point, where does the contents of the RA come
       from?

You can't do stateful or stateless dhcpv6 until you have seen the RA,
since dhcpv6 is essentially unicast.

As for static cofniguration, let's not talk about that.  If you can do
that, then you don't need RPL at all.

- --

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Apr 2010 09:47:17 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> I'll add my vote to yours and Robert's to transport the RIO
    Pascal> and PIO as the exist and remove the DPsO that's obsoleted by
    Pascal> the RIO.  Anybody else?

Does it reference the DIO/RIO by:
     value     -- copy & paste text + packet format?
     reference -- to a specific RFCxxxx (RFC4861)
     std ref   -- to a specific STDxxxx (alas, but RFC4861 isn't full standard yet)

The point is: as RIO/PIO is revised, does RPL automatically include
those updates?

My preference is (std) reference, and then copy&paste the current packet
format from RFC4861 as informative text.

- --

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 27 Apr 2010 09:54:40 -0400

> Date: Tue, 27 Apr 2010 14:18:32 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
>

How do other routing protocols (OSPF, IS-IS, AODV, OLSR)
handle this?  I understand that multi-hop subnets are a
problem for ND, but I don't see how the routing protocol is
affected.
                              -Richard Kelsey

---

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.  Both were written when multicast was very new.

My reading of AODV is that it does not deal with address assignment at
all.  It also does not promise in RFC3561 to deal with multicast. (Maybe
subsequent enhancements do?) 

    Richard> handle this?  I understand that multi-hop subnets are a
    Richard> problem for ND, but I don't see how the routing protocol is
    Richard> affected.  -Richard Kelsey

RPL either requires 6lowpan, or it doesn't.
If it doesn't, then it has to provide for ND to work, or for another
protocol to replace it.

- --

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 27 Apr 2010 11:27:18 -0400

> From: Michael Richardson <[email-masked]>
> Date: Tue, 27 Apr 2010 10:38:47 -0400
> 
> 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
> Richard> affected.

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

---

From: Joakim Eriksson <[email-masked]>
Date: Tue, 27 Apr 2010 17:54:54 +0200

Richard Kelsey skrev 2010-04-27 17:27:
>> From: Michael Richardson<[email-masked]>
>>>>>>> "Richard" == Richard Kelsey<[email-masked]>  writes:
>>      >>  (pthubert)"<[email-masked]>
>>      >>

If anyone would have a fairly "static" network with very few
sideways movements in the DAG it would be possible to do some
kind of prefix-based routing if RPL would assign the prefixes/
addresses. This would make it very light-weight when it comes
to routing tables, but very messy when nodes move between parents.
I am not sure that this is the case in any of the link-layers
that have been discussed for RPL so far (PLC, 802.15.4).

Best regards,
-- Joakim Eriksson, SICS

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Apr 2010 12:07:21 -0400

>> I can only speak for OSPF and ISIS.  Neither deal with multi-hop
    >> subnets or with any kind of address assignment.

    Richard> Why should RPL be any different?  Yes, it will be run on
    Richard> multi-hop subnets, but I still do not see how this affects
    Richard> the routing.

    >> Both were written when multicast was very new.

    Richard> I am not sure how RPL's handling of multicast matters here.
    Richard> While RPL is required to route multi-hop multicasts, ND
    Richard> uses link-local multicasts, which do not require routing.

Yes, that's true.

So, one answer is that all RPL intermediate nodes are required to
process RA/RS messages in order that all messages can be resolved as
one-hop multicast.

    Richard> If someone wants to run RPL on a node that uses neither
    Richard> ordinary ND or 6lowpan's version, then they will need some
    Richard> third variety of ND.  I do not see why this is an issue for
    Richard> RPL to address.  It seems quite out of scope.

"out of scope" is an acceptable answer.

- --

---

From: Robert Cragie <[email-masked]>
Date: Tue, 27 Apr 2010 19:45:27 +0100

See comment below

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

> uses link-local multicasts, which do not require routing.
<RCC>But that is one problem with ND as it stands. It is aimed at the 
general single border router with hosts all being one hop away, so a 
link-local multicast will reach all the hosts. A host (or another 
router) joining a 6lowpan or any network with the concept of routers 
with a single interface forwarding packets out on the same interface is 
not going to be able to see the border router which is in control of the 
prefix, therefore this information has to be 'multicast' to all the 
nodes. Considering a DIO in RPL, it is effectlvely multicast to all 
nodes in the network. It is also periodically broadcast. So if this 
mechanism is available, it is logical to use it to disseminate 
information throughout the network as opposed to trying to cobble 
together some alternative relay mechanism. In this way, a joining node 
could use unicast RS/RA as specified in 6lowpan ND and get the 
information it needs from its friendly neighborhood local router, as it 
will have already got it. Indeed, the dynamic bootstrapping of the 
network may itself propagate the information assuming the first node up 
is the border router, as the nodes will bootstrap forming a tree away 
from the border router. However, this can't be assumed.</RCC>

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 27 Apr 2010 14:58:46 -0700

> 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

[SC>] I agree with Richard's point. RPL should work independently on a IPv6
network with RFC4861.
If one wants to run 6lowpan-nd instead of rfc4861 for minimizing multicast
in the network and reducing number of signaling messages that IPv6-ND
requires, then RPL should run on top of it as well.

All other routing protocols run independently of the interface address
assignment and bootstrapping etc. - why would RPL be different ?

-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 27 Apr 2010 18:32:41 -0700

Hi Pascal,

[SC>]  Let's talk about the question and problem first  and our
understanding with respect to ND and ROLL.

Is the intention of this discussion is to do address assignment to all the
nodes in LLN?

Do you assume that there are multiple IPv6-subnets in that LLN ?  Can we
consider a LLN comprised of a single 6LoWPAN or multiple 6LoWPAN?

The question here is that the authoritative routers need to disseminate the
PIO (and the RIO) to all routers in the subnet.

[SC>] 6lowpan-nd-09 assumes that all nodes in a lowpan are configured with
the same set of prefixes in a route-over network. Thus the on-link concept
of nodes in a subnet is not there.

However, The authoritative router determines the prefix for the lowpan and
the same prefix is distributed through the intermediate routers across the
Lowpan. This ABRO option can exist with IPv6-ND PIO option. If the
authoritative routers(6LBRs) are to support RIO (rfc4191), this should also
co-exist with 6lowpan-nd.  But this RIO should not be propagated throughout
the route-over LLN - rather it could be sent by  intermediate routers at
each route-over hop.

In that case, each DoDag parent might be able to send the RIO type
information to its children. 

However, in RFC4191, the default-router preference seem to be done with
manual configuration in case of multi-homed hosts, but in case of ROLL
networks - this has to be done based on some algorithm for auto-conf.

Is this something needed in ROLL type LLN that you folks like to see as an
extension of 6lowpan-nd ? 

[SC>]  The scope of  base 6lowpan-nd is to distribute the same prefix across
Lowpan while it allows different default-routers at each route-over hop .

Adding Zach and Erik here as well.

Thanks,

-Samita

Hi Robert,

-Samita

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Thanks,

  Anders

  _____  

Hi Michael, Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Hi Michael:

 
 
What do you think?
 
Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 26, 2010 2:38 AM
To: Pascal Thubert (pthubert)
Cc: IETF ROLL; Erik Nordmark
Subject: Re: [Roll] how does a node get an IP address

writes:
    Pascal> Good question!

s/wan/can/ ??

as

RAs

you

the

 
- --

firewalls  [

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 27 Apr 2010 18:48:23 -0700

Hi Michael,

> As Pascal said, you are answering the wrong question.
[SC>] Please see my response to Pascal on this. Also please see below.

>     a) where does the default router come from?
[SC>] 
[SC>] The base 6lowpan-nd (aka nd-09)  assumes that same prefix(es) are
disseminated throughout the LowPAN by copying the PIO option originally sent
by  the 6LBR(s). However each 6LR(intermediate routers, in RPL, it could be
a DODAG parent) creates its own RA and send it to its requesting neighbor.
Thus if one wants to add default-router preference, it should be added to
6LRs. If multiple 6LBRs are present, then the preference bit should be added
there too for its immediate neighbors.

>     b) or more to the point, where does the contents of the RA come
[SC>]  See above. PIO, ABRO come from 6LBR(the authoritative router). Since
default-routers change at each route-over hop, a fresh RA is generated by
each responding 6LR which attaches the received PIO/ABRO from its
parent/default-router.

BTW, 6lowpan-nd-09 does not do periodic RAs, instead it waits for the RS
message and then sends unicast RA.
However, I don't see that passing destination route-information via RIO
option is in scope of basic 6lowpan-nd, but preference bit in RA header
makes sense to me.

Regards,
-Samita

---

From: [email-masked]
Date: Tue, 27 Apr 2010 23:36:19 +0300 (EEST)

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: "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

Of
> [email-masked]
> Sent: Tuesday, April 27, 2010 10:36 PM
> To: Richard Kelsey
> Cc: [email-masked]
> 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.
> 
> 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.
> 
> 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.
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.
> > 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.
> >
> > 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.
> >>
6lowpan?
> > 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

---

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

> 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
> 
> multi-hop 
> problem for ND, 
> ordinary ND
> or

---

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