Subject: [Roll] NA to transport DAO

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 9 Oct 2009 15:14:18 +0200

Hi all,
 
I have concerns about the use of NA to transport DAOs for the following
reasons:
- NAs are not routing messages
- unsolicited NAs are not very frequent, hence using them for DAOs is
not really piggybacking. We do not gain a lot by using them
- NA are already pretty overloaded messages: they are used in 3
procedures, namely address resolution, NUD and DAD
- NA processing is implementation wise complex enough because of the
point above
- implementation wise, coupling RPL with ND makes code much more
complex.
- the target address field in the NA uses 16 bytes without bringing a
lot of value to RPL.
 
I think using a new ICMP message to carry DAOs would be much better.
 
What do people think?
Best,
Julien

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 09 Oct 2009 14:14:13 -0400

Julien,

   Date: Fri, 9 Oct 2009 15:14:18 +0200
   From: "Julien Abeille (jabeille)" <[email-masked]>

   What do people think?

I agree that the choice of NA for DAOs needs some
justification, at least.  Besides a new ICMP, UDP to a
well-known port is another option.

                            -Richard Kelsey

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Oct 2009 21:01:37 -0400

>>>>> "Richard" == Richard Kelsey <[email-masked]> writes:
    Richard> I agree that the choice of NA for DAOs needs some
    Richard> justification, at least.  Besides a new ICMP, UDP to a
    Richard> well-known port is another option.

Maybe a different ICMP, but a UDP is probably not a good idea.

I know that people have lots of bad experiences in v4 with things not
TCP or UDP (often due to some comodity operating systems making it very
hard to do anything different -- my history is IPsec, and multicast),
but this is a greenfield IPv6 situation.   We should not have to break
the architecture at this point.

I am curious about those who believe that processing the DAOs is going
to be hard.  Last week I put up some test code to determine how hard
this was going to be in a Linux kernel -- the Linux kernel processes RA
in the kernel directly (vs the *BSD kernels, where rtsold does the
work).

I have no idea what other systems do, but the following code was enough
for me to see all ND and RS/RA packets in userland, without any
modifications to the kernel.

main() 
{
	int s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
	char b[2048];
	int len, n;

	if(s < 0) {
		perror("socket");
		exit(10);
	}

	n=0;
	while((len = recv(s, b, 2048, 0)) >= 0) {
		printf("\nPacket(%u,%u):\n", n, len);
		hexdump(b, 0, len);
		n++;
	}
	perror("recv");
}

- -- 
]       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: Mon, 12 Oct 2009 08:23:48 +0200

Hi Julien,

When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our
options into those messages. 

They create a tighter coupling between the router and the node, which
appears beneficial to the NA DAO process.

In the meantime, we made the conscious decision to bind RPL onto ND
though we wish to be opened to other bindings.

The overloading you are discussing is truly there. 

In one hand it can be seen as adding complexity. In the other as a way
to save control messages.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Julien Abeille (jabeille)
Sent: vendredi 9 octobre 2009 15:14
To: IETF ROLL
Subject: [Roll] NA to transport DAO

Hi all,

What do people think?

Best,

Julien

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 12 Oct 2009 10:04:47 +0200

Hi Pascal, all,
 
as I said unsolicited NAs are not frequent if ever sent. Timing
constraints are very different and totally decoupled for a NA and a DAO,
hence the savings in terms of control messages will be pretty small. The
added complexity will be important. This is enough for me to disquilify
the use of NAs.
 
regarding 6lowpan, again (I think this has been said many times), RPL is
not a protocol for 802.15.4. 
 
Best,
Julien

________________________________

	From: Pascal Thubert (pthubert) 
	Sent: lundi 12 octobre 2009 08:24
	To: Julien Abeille (jabeille); IETF ROLL
	Subject: RE: [Roll] NA to transport DAO

	Hi Julien,

	When 6LoWPAN ND becomes a standard, I'm all in favor to adapting
our options into those messages. 

	They create a tighter coupling between the router and the node,
which appears beneficial to the NA DAO process.

	In the meantime, we made the conscious decision to bind RPL onto
ND though we wish to be opened to other bindings.

	In one hand it can be seen as adding complexity. In the other as
a way to save control messages.

	Pascal

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Abeille (jabeille)
	Sent: vendredi 9 octobre 2009 15:14
	To: IETF ROLL
	Subject: [Roll] NA to transport DAO

	Hi all,

	I have concerns about the use of NA to transport DAOs for the
following reasons:

	- unsolicited NAs are not very frequent, hence using them for
DAOs is not really piggybacking. We do not gain a lot by using them

	- NA processing is implementation wise complex enough because of
the point above

	- the target address field in the NA uses 16 bytes without
bringing a lot of value to RPL.

	I think using a new ICMP message to carry DAOs would be much
better.

	What do people think?

	Best,

	Julien

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 12 Oct 2009 10:10:16 +0200

Hi Michael, 

Thanks for your answer, comments inline.

> -----Original Message-----
> Behalf Of Michael Richardson
> Sent: dimanche 11 octobre 2009 03:02
> To: [email-masked]
> Subject: Re: [Roll] NA to transport DAO
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
Agreed 
> I know that people have lots of bad experiences in v4 with 
> things not TCP or UDP (often due to some comodity operating 
> systems making it very hard to do anything different -- my 
> history is IPsec, and multicast),
> I am curious about those who believe that processing the DAOs 
> is going to be hard.  Last week I put up some test code to 
> determine how hard this was going to be in a Linux kernel -- 
> the Linux kernel processes RA in the kernel directly (vs the 
> *BSD kernels, where rtsold does the work).
> 
> I have no idea what other systems do, but the following code 
> was enough for me to see all ND and RS/RA packets in 
> userland, without any modifications to the kernel.
> 
What having the code in userland with NAs does is that the NAs are
processed twice, once by the kernel for DAD, NUD, address resolution,
once in userland for RPL. Not sure we can conclude it is easy to build a
clean software architecture for RPL in Linux. Besides, Linux/BSD will
not be the OS on many smart objects. On standard smart objects OSes it
will be much more complex.

Best,
Julien
> ] [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. 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBStEuboCLcPvd0N1lAQKPQQf+LuWGVchwOu5yg127+5d2rz8+LiyZws+V
> o6tW1HXox1HarXnj+tJkLG9v5ibtymxxIBUxP4Y78ly92r2fqkYfM8mshol9Jnpq
> HXOD0sMDd1Tlvm1PILzqAhHiZmQkkYSJ7TupLQs/qs736TSjBIdvrVZuEmysbkzr
> 9QZlhBimYA6vAKZncq+pMple7zvXIuRe4atbHWTL84PLqtTYsCfHxVsLhanqTu/K
> G/DJsjj9zKrvUHXC33c1+wF0YTjWe/eFwS4RH4g4SMcF8noy6L7TaBdlvajjoI2F
> rq/THV9TkHOTo5koOrt5DtzDl4C9X1AcODVeeGc01g0xE1KklQnF7g==
> =CVIa
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Oct 2009 11:27:39 +0300

Hi,

On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote:

> constraints are very different and totally decoupled for a NA and a  
> DAO, hence the savings in terms of control messages will be pretty  
> small. The added complexity will be important. This is enough for me  
> to disquilify the use of NAs.

I understand the concern there for RFC4861.

> regarding 6lowpan, again (I think this has been said many times),  
> RPL is not a protocol for 802.15.4.

Huh? Apples and oranges. We are not talking about 802.15.4.

RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN  
IPv6 networks as well. An alternative binding to draft-ietf-6lowpan-nd  
messages should be defined of course as Pascal mentioned below. And  
here the advantages of this are even greater. In 6LoWPAN-ND we do have  
periodic NR/NC messages which are not overloaded.

This reminds me - in the next version of RPL we need a section to  
specifically discuss the use of RPL in LoWPANs. The current text  
assumes the LLN is a collection of normal IPv6 links and that RFC4861  
is used. In a LoWPAN we have a flat network (no prefix assignment to  
LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty confusing  
to read if someone new is trying to figure out how to apply this is a  
LoWPAN...

Zach

> When 6LoWPAN ND becomes a standard, I’m all in favor to adapting our  
> In one hand it can be seen as adding complexity. In the other as a  
> way to save control messages.
>
> Pascal
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Julien Abeille (jabeille)
> - unsolicited NAs are not very frequent, hence using them for DAOs  
> is not really piggybacking. We do not gain a lot by using them
> - the target address field in the NA uses 16 bytes without bringing  
> a lot of value to RPL.
>

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Oct 2009 12:06:44 +0200

Hi Zach

We are in perfect line. At the moment, RPL would impose NS/NA between
6LoWPAN routers to expose the host routes.

At some point in the future, considering that LoWPANs are an obvious
target for RPL, we should be able to define the binding over the LowPAN
ND. What we really need to move forward there is for ND to progress to
RFC quickly so we can refer to it. 

I think it would be good for this list that you update us on the
progress there. What would be the plan for last call?

Cheers,

Pascal

>From: Zach Shelby [mailto:[email-masked]]
>Sent: lundi 12 octobre 2009 10:28
>To: Julien Abeille (jabeille)
>Cc: Pascal Thubert (pthubert); IETF ROLL
>http://zachshelby.org - My blog "On the Internet of Things"
>Mobile: +358 40 7796297
>
>Zach Shelby
>Head of Research
>Sensinode Ltd.
>Kidekuja 2
>88610 Vuokatti, FINLAND
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Oct 2009 12:40:47 +0200

On Oct 12, 2009, at 12:06, Pascal Thubert (pthubert) wrote:

> What would be the plan for last call?

The most recent update, draft-ietf-6lowpan-nd-06.txt, was posted on  
2009-09-21.
This resolves all issues in the issue tracker; there are currently no  
outstanding issues in the tracker.

I believe we could go to WGLC now.
Issuing a WGLC may be a good way to trigger some additional review, in  
particular from outside the WG.
(Procedural note: As I'm a co-author, the other 6LoWPAN WG chair will  
have to issue the WGLC.)

Gruesse, Carsten

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 12 Oct 2009 13:32:06 +0200

Hi All,

I perfectly agree with Julien's arguments. Quoting from RFC 4861:

   "7.2.6.  Sending Unsolicited Neighbor Advertisements

   In some cases, a node may be able to determine that its link-layer
   address has changed (e.g., hot-swap of an interface card) and may
   wish to inform its neighbors of the new link-layer address quickly.
   In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT
   unsolicited Neighbor Advertisement messages to the all-nodes
   multicast address.  These advertisements MUST be separated by at
   least RetransTimer seconds..."

Do we really want to impose these constrains to the sending of DAO? I
don't think so...
The goal of NAs is to update neighbor caches and I don't see any logic
in wanting to reuse these messages for routing.

In addition, I don't think this group should care or make any
assumptions on the adaptation layer running below IPv6 as each of them
has it specificities and RPL should remain as generic as possible.

Best,
Mathilde 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: lundi, 12. octobre 2009 12:07
To: Zach Shelby; Julien Abeille (jabeille)
Cc: IETF ROLL
Subject: Re: [Roll] NA to transport DAO

Hi Zach

Cheers,

Pascal

>> regarding 6lowpan, again (I think this has been said many times), RPL

>> is not a protocol for 802.15.4.
>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Oct 2009 14:47:34 +0300

> has it specificities and RPL should remain as generic as possible.

You mean you would like to assign a /64 to every LoWPAN Router in the  
LLN... And then how about we bind DAOs to NAs in the LoWPAN as well  
(if RPL binds to ND)?

6LoWPAN is not just an adaptation layer, it does have network  
architectural aspects as well. The link model is different, and we run  
6LoWPAN-ND on that link.  RPL doesn't need technical changes to  
account for the adaptation layer. Just an applicability statement of  
how it can be used inside a LoWPAN is sufficient. Considering the  
majority of us will likely use RPL in LoWPANs - it would be insane not  
to mention it....

- Zach

> Of
>>> RPL
>>> which
>>> is
>>> bringing a

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Oct 2009 16:37:52 +0200

> to disquilify the use of NAs.

The argument makes sense.

WG, thoughts ?

> RPL is not a protocol for 802.15.4.

For sure.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 12 Oct 2009 16:56:25 +0200

> The argument makes sense.

My thought is completely different.

I believe we haven't explored enough the possibilities of running 
typical IP on a node, i.e. node send NAs.

The tradeoffs of node not sending NAs are not completely understood 
(delegate the NA sending to another entity?  what's the cost of doing 
this? other entity doing "NA storms"?).

I may be well behind the current thinking, but that's my thought.

Alex

>>     ------------------------------------------------------------------------
>>     *From:* Pascal Thubert (pthubert) 
>>     *Sent:* lundi 12 octobre 2009 08:24
>>     *To:* Julien Abeille (jabeille); IETF ROLL
>>     *Subject:* RE: [Roll] NA to transport DAO
>>
>>     Hi Julien,
>>      
>>     When 6LoWPAN ND becomes a standard, I’m all in favor to adapting
>>     *From:* [email-masked] <mailto:[email-masked]>
>>     [mailto:[email-masked]] *On Behalf Of *Julien Abeille
>>     (jabeille)
>>     *Sent:* vendredi 9 octobre 2009 15:14
>>     *To:* IETF ROLL
>>     *Subject:* [Roll] NA to transport DAO
>>      
>>     Hi all,
>>      
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 12 Oct 2009 17:30:39 +0200

Hi Alex,

I think there is a misunderstanding. We want to run IP on the nodes and hence use NA in address resolution, etc.
However, we believe that using NA for routing traffic is not appropriate. Or in other word NA should only be used to update the neighbor cache not the routing table...

Best,
Mathilde 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: lundi, 12. octobre 2009 16:56
To: JP Vasseur (jvasseur)
Cc: IETF ROLL
Subject: Re: [Roll] NA to transport DAO

I believe we haven't explored enough the possibilities of running typical IP on a node, i.e. node send NAs.

The tradeoffs of node not sending NAs are not completely understood (delegate the NA sending to another entity?  what's the cost of doing this? other entity doing "NA storms"?).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 12 Oct 2009 17:46:20 +0200

Mathilde Durvy (mdurvy) a écrit :
> Hi Alex,
> 
> I think there is a misunderstanding. We want to run IP on the nodes
> and hence use NA in address resolution, etc. However, we believe that
> using NA for routing traffic is not appropriate. Or in other word NA
> should only be used to update the neighbor cache not the routing
> table...

Hmm... in this sense I tend to agree with your oppinion, NA not to 
update the routing table.

Would RA be better appropriate to update the routing table?  In a 
certain context of a star-like topoology I consider, I consider RA is 
appropriate to update routing table entries.

(the previous mail discarding the use of NA based on timing constraints
  is not relevant IMHO, because NA timing can be tuned to one's like).

Alex

> 
> Best, Mathilde
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> lundi, 12. octobre 2009 16:56 To: JP Vasseur (jvasseur) Cc: IETF ROLL
>>> constraints are very different and totally decoupled for a NA and
>>> a DAO, hence the savings in terms of control messages will be
>>> pretty small. The added complexity will be important. This is
>>> enough for me to disquilify the use of NAs.
>>> 
>>> Best, Julien
>>>  *From:* Pascal Thubert (pthubert) *Sent:* lundi 12 octobre 2009
>>> 08:24 *To:* Julien Abeille (jabeille); IETF ROLL *Subject:* RE:
>>> [Roll] NA to transport DAO
>>> 
>>> Hi Julien,
>>> 
>>> our options into those messages. They create a tighter coupling
>>> between the router and the node, which appears beneficial to the
>>> NA DAO process.
>>> 
>>> ND though we wish to be opened to other bindings. The overloading
>>> you are discussing is truly there. In one hand it can be seen as
>>> adding complexity. In the other as a way to save control
>>> messages.
>>> 
>>> Pascal *From:* [email-masked]
>>> <mailto:[email-masked]> [mailto:[email-masked]] *On
>>> Behalf Of *Julien Abeille (jabeille) *Sent:* vendredi 9 octobre
>>> 2009 15:14 *To:* IETF ROLL *Subject:* [Roll] NA to transport DAO
>>> 
>>> Hi all,
>>> 
>>> following reasons: - NAs are not routing messages - unsolicited
>>> NAs are not very frequent, hence using them for DAOs is not
>>> really piggybacking. We do not gain a lot by using them - NA are
>>> already pretty overloaded messages: they are used in 3 
>>> procedures, namely address resolution, NUD and DAD - NA
>>> processing is implementation wise complex enough because of the
>>> point above - implementation wise, coupling RPL with ND makes
>>> code much more complex. - the target address field in the NA uses
>>> 16 bytes without bringing a lot of value to RPL.
>>> 
>>> What do people think? Best, Julien
>>> 
>>> _______________________________________________ Roll mailing list
>> _______________________________________________ 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: Alexandru Petrescu <[email-masked]>
Date: Mon, 12 Oct 2009 17:51:48 +0200

>  is not relevant IMHO, because NA timing can be tuned to one's like).

Sorry, following up my own post, I wanted _also_ to say that I have 
nothing against another routing protocol carrying the routing 
information, being that OSPF, BGP, RIP.  And if they aren't suitable for 
ROLL then another routing protocol, RPL.

If asked to distinguish between them my first criterion is re-usability.

Alex

>>>> options into those messages. They create a tighter coupling
>>>> though we wish to be opened to other bindings. The overloading
>>>> already pretty overloaded messages: they are used in 3 procedures, 
>>>> namely address resolution, NUD and DAD - NA

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Oct 2009 18:58:06 +0200

Hi Mathilde;

The binding is like a transport. We'll define a different binding but
it's still the same generic protocol. Like you can ping over UDP it's
still ping. 

And RPL does not do NA multicast for DAO, but for the specific case of
hosts that would participate to the game. Then again the LoWPAN model is
a better fit.

Pascal

>From: Mathilde Durvy (mdurvy)
>Sent: lundi 12 octobre 2009 13:32
>To: Pascal Thubert (pthubert); Zach Shelby; Julien Abeille (jabeille)
>Cc: IETF ROLL
don't think so...
>The goal of NAs is to update neighbor caches and I don't see any logic
in wanting to reuse these messages for
>routing.
assumptions on the adaptation layer running
>below IPv6 as each of them has it specificities and RPL should remain
as generic as possible.
>We are in perfect line. At the moment, RPL would impose NS/NA between
6LoWPAN routers to expose the host
>routes.
target for RPL, we should be able to
>define the binding over the LowPAN ND. What we really need to move
forward there is for ND to progress to RFC
>quickly so we can refer to it.
>
progress there. What would be the plan for
>last call?
RPL
which
is
>>> - the target address field in the NA uses 16 bytes without bringing
a

---

From: JP Vasseur <[email-masked]>
Date: Mon, 12 Oct 2009 20:16:04 +0200

On Oct 12, 2009, at 6:58 PM, Pascal Thubert (pthubert) wrote:

> hosts that would participate to the game.

it does Mcast NA for DOA ...

> Then again the LoWPAN model is
> a better fit.

RRR ... what do you mean by LoWPAN model ????

Cheers.

JP.

>> Behalf Of
>>>> the

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Oct 2009 16:39:45 -0400

>>>>> "JP" == JP Vasseur <[email-masked]> writes:

    JP> The argument makes sense.

    JP> WG, thoughts ?

Unless the DAO's eliminate the need to send NDs, then a node has to send
some-new-ICMPv6 with DAOs, and then also send NDs, I think. (or
6lowpan-nd, which I am ignorant about).

The argument that NAs are not frequent enough does not work for me.
If we need to send a DAO more often, then we need to send whatever they
are contained in more often, and NAs are not harmful.  Unless I'm crazy,
it's more expensive (powerwise, etc.) to send two kinds of packets than
it is to send one kind.

An argument that inserting DAOs into NAs is hard in some environment
(please specify which system), might work for me.

An argument that we do not need to otherwise send NAs in all RPL
environments would also convince me.

    >> I think using a new ICMP message to carry DAOs would be much

I do not object to this, but I want to do it for the right reason.

- --

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Oct 2009 16:45:33 -0400

>>>>> "Mathilde" == Mathilde Durvy <(mdurvy)" <[email-masked]>> writes:
    Mathilde> Hi Alex,

    Mathilde> I think there is a misunderstanding. We want to run IP on
    Mathilde> the nodes and hence use NA in address resolution, etc.
    Mathilde> However, we believe that using NA for routing traffic is
    Mathilde> not appropriate. Or in other word NA should only be used
    Mathilde> to update the neighbor cache not the routing table...

I believe that we want to send as few packets as possible.  It's okay if
they are a bit bigger, as that generally does not cost very much.

NA *is* a routing protocol.  

It tells you what route to use to reach neighbours.  Some OSs (4.4BSD+)
go so far as to have combined layer-2 and layer-3 reachability into a
single table. (Linux does something similar, but it's not as clear)

lox-[~] mcr 1047 %uname -a
NetBSD lox.sandelman.ottawa.on.ca 3.1 NetBSD 3.1 ...

lox-[~] mcr 1048 %netstat -rn -f inet6
Routing tables

Internet6:
Destination                        Gateway                        Flags     Refs     Use    Mtu  Interface
::/104                             ::1                            UGRS        0   876847      -  lo0 =>
::/96                              ::1                            UGRS        0        0      -  lo0 =>
default                            2001:4830:1217:3::1            UGS         1  8760603      -  ex0
::1                                ::1                            UH         14   592769  33192  lo0
2001:4830:1217:3::1                00:80:c8:ca:76:6c              UHL         1    32349      -  ex0
2001:4830:1217:3::178              00:c0:4f:96:43:0f              UHL         1      294      -  lo0
2607:f0b0:f:3::1                   00:80:c8:ca:76:6c              UHL         0     3428      -  ex0
2607:f0b0:f:3::178                 00:c0:4f:96:43:0f              UHL         1        0      -  lo0
2607:f0b0:f:3:2c0:4fff:fe96:430f   00:c0:4f:96:43:0f              UHL         0        0      -  lo0

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Oct 2009 16:52:35 -0400

>>>>> "Julien" == Julien Abeille <(jabeille)" <[email-masked]>> writes:
    >> I have no idea what other systems do, but the following code was
    >> enough for me to see all ND and RS/RA packets in userland,
    >> without any modifications to the kernel.

    Julien> What having the code in userland with NAs does is that the
    Julien> NAs are processed twice, once by the kernel for DAD, NUD,
    Julien> address resolution, once in userland for RPL. Not sure we

  It seems pretty trivial to me.
  The packet is processed by two components, yes.  
  Each piece processes a different part of the packet.  
  If anything, this may be a win if the processor has a big data cache,
but otherwise, I have no understanding of why it is an issue.

    Julien> can conclude it is easy to build a clean software
    Julien> architecture for RPL in Linux. Besides, Linux/BSD will not
    Julien> be the OS on many smart objects. On standard smart objects
    Julien> OSes it will be much more complex.

  Again, please tell me what the constraint is.

  Are you really telling me that you expect light switches to have
*MORE* code than my laptop or an Android-based phone?

  I would think that they will have *simpler* (operating) systems, where
essentially all processing is done in a single context.  

  The only situation I can see where adding RPL processing will be
difficult is if you have a very simple embedded operating system, which 
*does* have an IPv6 stack, and for which you do not have access to the
source code.  I will be surprised if, regardless of how DAOs are
transported if your IPv6 stack is sufficiently bug-free to enable you do
to RPL at all.

  Please educate me.

- --

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Oct 2009 17:13:53 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> We are in perfect line. At the moment, RPL would impose
    Pascal> NS/NA between 6LoWPAN routers to expose the host routes.

I have just read 6lowpan-nd-06.txt

Some things immediately jump out at me:
     1) small packets are much more common, so DAOs may not fit into ND.
     2) multicast is not assumed, so the Whiteboard is used.
     3) nodes that are sleepy, are not going to be useful as members of
	an RPL DAG, so really, it's about RPL between the Edge Routers.

It seems to me therefore that the only nodes in a 6lowpan that can
participate in a RPL DAG would be the edge router that runs a
Whiteboard.

I think you capture this in your above sentence.   I do not think that
the 6LoWPAN routers will be speaking NR/NC between themselves along
their "backbone", but I could be wrong.

I also think that some other people may be thinking that many more
6LoWPAN nodes will participate in RPL than just the edge routers.

- --

---

From: [email-masked]
Date: Mon, 12 Oct 2009 16:21:54 -0500

I guess I am one of those people that think that other 6LoWPAN nodes must 
participate in RPL.  Unless I am missing something RPL is the only game in 
town regarding meshing of wireless sensors.  If they are not in RPL is 
there another means that they can use to form mesh connectivity to get to 
the LBR?

Jerry

Michael Richardson <[email-masked]> 
Sent by: [email-masked]
10/12/2009 04:13 PM

To
IETF ROLL <[email-masked]>
cc

Subject
Re: [Roll] NA to transport DAO

                 an RPL DAG, so really, it's about RPL between the Edge 
Routers.

- -- 
]       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: JP Vasseur <[email-masked]>
Date: Tue, 13 Oct 2009 04:53:27 +0200

On Oct 12, 2009, at 11:21 PM, [email-masked] wrote:

>
> I guess I am one of those people that think that other 6LoWPAN nodes  
> must participate in RPL.  Unless I am missing something RPL is the  
> only game in town regarding meshing of wireless sensors.  If they  
> are not in RPL is there another means that they can use to form mesh  
> connectivity to get to the LBR?

You interpretation is of course correct.

JP.

> iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N
> j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX
> bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp
> GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo
> aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/
> iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw==
> =FpQB

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 13 Oct 2009 11:54:19 +0200

Needless to say I also consider myself one of those people...
 
As discussed in the interim meeting, p2p mesh support is actually
required in 50% of the requirement drafts forming the base of this
working group.
In IETF terms,
Nodes MUST be able to use (somewhat optimized) p2p to communicate
internally and MAY need to talk to an LBR.
 
- Anders

From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur
Sent: 13. oktober 2009 04:53
To: [email-masked]
Cc: [email-masked]; IETF ROLL
Subject: Re: [Roll] NA to transport DAO

	I guess I am one of those people that think that other 6LoWPAN
nodes must participate in RPL.  Unless I am missing something RPL is the
only game in town regarding meshing of wireless sensors.  If they are
not in RPL is there another means that they can use to form mesh
connectivity to get to the LBR? 

JP.

	Jerry 

	

10/12/2009 04:13 PM 

To
	
Subject

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA1

	>>>>> "Pascal" == Pascal Thubert <(pthubert)"
<[email-masked]>> writes:
	   Pascal> We are in perfect line. At the moment, RPL would
impose
	   Pascal> NS/NA between 6LoWPAN routers to expose the host
routes.

	Some things immediately jump out at me:
	    1) small packets are much more common, so DAOs may not fit
into ND.
	    2) multicast is not assumed, so the Whiteboard is used.
	    3) nodes that are sleepy, are not going to be useful as
members of
	                an RPL DAG, so really, it's about RPL between
the Edge Routers.
	
	It seems to me therefore that the only nodes in a 6lowpan that
can
	participate in a RPL DAG would be the edge router that runs a
	Whiteboard.
	
	I think you capture this in your above sentence.   I do not
think that
	the 6LoWPAN routers will be speaking NR/NC between themselves
along
	their "backbone", but I could be wrong.
	
	I also think that some other people may be thinking that many
more
	6LoWPAN nodes will participate in RPL than just the edge
routers.
	
	- -- 
	]       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: Tue, 13 Oct 2009 15:47:35 +0200

Hi Richard
>     1) small packets are much more common, so DAOs may not fit into
ND.

This is a non issue. IPv6 on any link requires an MTU of at least 1280. 
6LoWPAN provides a fragmentation mechanism for those link layers that
could hold the IPv6 MTU in a frame.
Above the IPv6 MTU, you can still fragment the ND packet using IPv6
fragmentation.
This is more common than you might think, as traditional ND packets can
get real big, for instance in the presence of SeND.

>     2) multicast is not assumed, so the Whiteboard is used.

The routers could still use NS/NA between them but that makes little
sense I agree. RPL routers use NA as unicast to their parent, a role
that 6LoWPAN NR can perfectly play

>	an RPL DAG, so really, it's about RPL between the Edge Routers.

In my mind the edge router is usually also the root for a RPL DAG.

I agree that a node that exposes itself as a router must be able to get
packets from nodes, and hold packets for next hops till they are awake
to get them. So obviously, being a router will cause additional drain. 

>From there, multiple strategies are possible, and I like the one whereby
the router role can roll - ;) The current draft does not provide means
to automate that strategy. It is also possible to deploy power-savvy
routers to provide a mesh coverage.

The protocol provides the means but how they are used is up to
deployment...

>participate in a RPL DAG would be the edge router that runs a

RPL is the prime protocol for a route-over 6LoWPAN network. So we must
make it work, and hopefully it does.

>their "backbone", but I could be wrong.

Any 6LoWPAN node joins and stays in the LoWPAN using NR/NC with at least
one router. If the node is itself a RPL router, it makes sense that it
joins via its selected parents. Guess what, now we have a perfectly
natural binding for our DAO. Hardly a surprise though seems there are a
number of people that participate to both WGs.

>6LoWPAN nodes will participate in RPL than just the edge routers.

Hopefully :)

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Oct 2009 15:47:29 +0200

Me too : )

The only thing that blocks us right now from allowing (6loWPAN ND) NR as
an alternate to (RFC4861) NA for the purpose of DAO is the draft status
of the draft, not even last call yet. But if that clarifies we can allow
either for the time being and see how things evolves. Or we could
replace NA with NR right away and reconsider if things do not work out
for the 6LoWPAN draft. This thread was started for that purpose after
all...

Advice?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Brandt
Sent: mardi 13 octobre 2009 11:54
To: JP Vasseur (jvasseur); [email-masked]
Cc: [email-masked]; IETF ROLL
Subject: Re: [Roll] NA to transport DAO

In IETF terms,

- Anders

I guess I am one of those people that think that other 6LoWPAN nodes
must participate in RPL.  Unless I am missing something RPL is the only
game in town regarding meshing of wireless sensors.  If they are not in
RPL is there another means that they can use to form mesh connectivity
to get to the LBR? 

JP.

Jerry 

10/12/2009 04:13 PM 

To

cc

Subject

		

- --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Oct 2009 16:16:03 +0200

Hi JP,

>RRR ... what do you mean by LoWPAN model ????

Oups, I meant 6LoWPAN ND model vs. the RFC 4861 model from which we
reuse NA. 

The NR/NC model is a better fit for transporting DAO than NA is, because
it creates a registration relationship that's fit for registering a
route as well. Like NEMO registers a prefix over MIPv6 if you wish.

Basically we can benefit from the fact that the state of the route can
be strongly coupled with the state of the registration.

We use NA because in traditional ND that's probably the best we have to
express the child to parent relationship.
But I certainly agree with Julien that it's far from perfect. 

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Oct 2009 12:41:43 -0400

(You'll want to edit your mailer to not reply to SMTP from addresses, as
you CC'ed [email-masked], which you certainly do not want to do)

>>>>> "Jerald" == Jerald P Martocci <[email-masked]> writes:
    Jerald> I guess I am one of those people that think that other
    Jerald> 6LoWPAN nodes must participate in RPL.  Unless I am missing
    Jerald> something RPL is the only game in town regarding meshing of
    Jerald> wireless sensors.  If they are not in RPL is there another
    Jerald> means that they can use to form mesh connectivity to get to
    Jerald> the LBR?

As far as I can tell 6LoWPAN-nd and RPL are somewhat complementary, and
somewhat overlapping.   

    >> Some things immediately jump out at me: 1) small packets are much
    >> more common, so DAOs may not fit into ND.

    Pascal> This is a non issue. IPv6 on any link requires an MTU of at
    Pascal> least 1280. 6LoWPAN provides a fragmentation mechanism for
    Pascal> those link layers that could hold the IPv6 MTU in a frame.
    Pascal> Above the IPv6 MTU, you can still fragment the ND packet
    Pascal> using IPv6 fragmentation.  This is more common than you
    Pascal> might think, as traditional ND packets can get real big, for
    Pascal> instance in the presence of SeND.

Uhm, the fact that 6LoWPAN provides a fragmentation mechanism is not
important.   What this means is that a single ND packet now takes
multiple packets.  One of the arguments against putting DAOs in the ND
is that they do not go often enough, and therefore we would have to send
more ND packets, which means more energy.

If in fact the ND will be fragmented by the layer-2 for delivery, then
we might well be better off to send the more frequent DAOs in their own
packet, ideally one which 6LoWPAN can carry without fragmentation.
That's a win because then the much larger ND packets (yes, I am very
familiar with SeND), can be sent less often.

    >> 2) multicast is not assumed, so the Whiteboard is used.

    Pascal> The routers could still use NS/NA between them but that
    Pascal> makes little sense I agree. RPL routers use NA as unicast to
    Pascal> their parent, a role that 6LoWPAN NR can perfectly play

Yes, we can certainly put DAOs on the NR/NC, once you know about the
parent.  

But, what's the point of running RPL on that node?  It can not talk to 
any other nodes unless they can also see the same whiteboard, which
means that the nodes can not have children.

    >> 3) nodes that are sleepy, are not going to be useful as members
    >> of an RPL DAG, so really, it's about RPL between the Edge
    >> Routers.

    Pascal> In my mind the edge router is usually also the root for a
    Pascal> RPL DAG.

I agree that this is reasonable.

What I do not understand is how/why you would run both RPL and 6LoWPAN
on the other nodes.  If they have connectivity to the edge router to be
able to send it updates for the Whiteboard, then you
have... well.. connectivity.  

(look at diagram on page 13 of nd-06.txt)

If you do not have connectivity to the Whiteboard/EdgeRouter, and you
are trying to use RPL to reach it (which I think a lot of people want to
do), then you need to broadcast/multicast a DAO somehow, such that you
can find a parent with a DAG to join.  

But, to do that, you need at least a link-scope address to use (which I
think you need to do DAD on, right? or does one skip that for link-scope
addresses...), and you need to be able to multicast/broadcast.  

6LoWPAN provided the whiteboard because multicast didn't work, so it
seems like you can not put RPL on nodes that aren't directly
connected to the whiteboard.  And if you have a node that can run RPL,
then it doesn't need 6LoWPAN either.

    >> can participate in a RPL DAG would be the edge router that runs a
    >> Whiteboard.

    Pascal> RPL is the prime protocol for a route-over 6LoWPAN
    Pascal> network. So we must make it work, and hopefully it does.

I agree that we all want it to work.  
I'm just not sure that we do not have an impedance mismatch here.

I'm not a 6LoWPAN expert (and none of my consulting customers wanted me
to be).  
new acronym: IANA6L.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 14 Oct 2009 12:33:07 +0200

Hi Michael

Thanks a lot for this discussion :)

>As far as I can tell 6LoWPAN-nd and RPL are somewhat complementary, and

6lowpan-ND was designed with route over in mind from day 1, that was
part of the Dublin vote.
And one of the objectives of the authors has always been to make those 2
work together.
You'll find that some of the authors are actually working on both drafts
in parallel.
Now we (and I assume my own responsibility there) might have missed
something on the way.

But I'm certainly interested in discussing and fixing anything that
might be an issue between the 2, and hear more about the overlap that
you found. It is high time since we will probably be asking for WGLC
very soon.

At the moment, the issues I'm aware of are:

- RPL does not mention NR/NC. There's a point where it should enable the
use of those messages as an alternate or a replacement to NA unicast
- ND does not impose that nodes should send NA multicast after NR/NC
flow though the new RPL P2P expects it?

Anything else we should concentrate on?

>more ND packets, which means more energy.

I'm sure you mean multiple frames for one ND packet. And yes, the frames
being small in 15.4, there's a point where you need multiple of them,
and there's overhead etc... This is a real issue certainly at L2 but
there's nothing IP can do about it, and whether you call the packet a NA
or something else will not make a difference there. 

My point was that L3 cannot and does not make a difference so from that
standpoint, it is a non issue. What we must clearly do for DAO as for
anything else is try to be concise in our protocol. After that, some
additional technology might be specifically put in place over certain
links for additional blocking or compression, like 6LoWPAN HC for
instance.

>means that the nodes cannot have children.
>

You right. In route-over, most of the nodes might need a DAG to reach
the white board.
IOW they are not in direct line of sight and attach to a router deep in
the DAG.
As you figure, the lucky ones that are will attach to the white board.

The brd/mlt cast is that of RA-DIO.

>then it doesn't need 6LoWPAN either.

Note: In route-over, the link local address is only used over one radio
hop but its uniqueness is checked on the whole subnet - the larger non
transitive link that might incorporate a backbone and multiple RPL DAGs,
e.g. the whole diagram on page 13 of nd-06.txt - by the whiteboard.

Here's how it could go if we bind RPL over NR/NC: 

1) As the DAG forms, a RPL router discovers its parents. If the ND
operation on the link is based on NR/NC then it makes sense for the OCP
to favor a parent that can reach a whiteboard so that a single NR can be
used for RPL DAOs and to maintain the registration of its own addresses
at the same time.

2) Then the router obtains a link local and a global address using the
whiteboard via its parent(s). The parent is already part of the DAG so
it can relay the registration. The DAOs for the router's prefixes if it
has any are included in the NR. So would be the fact that the node is a
router, so that parents disable address filtering upon acceptance by the
whiteboard.

3) Upon successful completion from the white board, the parent installs
a binding to the address, and a route to the prefix via the address. For
a global address it could do either way, my take is bind the link local
to the mac address for address resolution, and for anything (global
addresses, prefixes and mcast DAOs) install routes via the link local. 

4) The parent also sets up RPL as to add the router's prefix (and/or
address) information in its own DAOs.

5) The parent sends a successful completion to the router

6) The router now owns its address(es), the right to be a router, can
send its owns RA-DIOs indicating that it can reach the whiteboard, and
the process recurses

Note: Extending 6LoWPAN ND for RPL is relatively consequent piece of
work, similar in essence to what NEMO is to MIPv6.
This will require a new draft for sure. At the moment, what we really
need from 6LoWPAN ND is to enable this as we see it coming. 

Potentially, this could mean that we need to enable the capability to
bind additional stuff in a same NS and probably couple the global and
the link local binding in a single message. We also need to think of
adding a 'router' bit to change the source address validation.

That discussion belongs to the 6LoWPAN list...

>I'm not a 6LoWPAN expert (and none of my consulting customers wanted me

? sorry I missed that

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Oct 2009 13:07:43 -0400

{I am not on 6lowpan list}

(Pascal gives 6 step process of binding RPL over NR/NC.)

> used for RPL DAOs and to maintain the registration of its own addresses

What happens if there is no connectivity to the whiteboard?
I.e.  the DAG is not grounded?

I think the node/router in question has to talk to the whiteboard using
it's not-yet-known-to-be-unique link local address.  

I'm really unconfortable with the idea that the node/router has
participate on a network, and change routing state of upstream nodes,
using an address that is not yet unduplicated.  The attacks that I can
imagine are almost endless, such that I would very much want to consider
doing this only with SEND.

> send its owns RA-DIOs indicating that it can reach the whiteboard, and

How does it transmit he RA-DIOs?  They are multicast/broadcast on the
directly attached link, not I guess with the help of the whiteboard.
i.e. these are multicasts that have to bypass the 6lowpan multicast
system, I think?

I think this is important --- as it may mean that these DIOs can not be
extra payloads of the "ND" (NR/NC), which would normally got to the
whiteboard via unicast, right?

- --