Subject: [6lowpan] Fwd: New Version Notification for draft-chakrabarti-6lowpan-ipv6-nd-simple-00

From: Erik Nordmark <[email-masked]>
Date: Mon, 01 Mar 2010 05:16:53 -0800

Samita and I have tried to capture a minimal set of ND optimizations in 
this draft.

    Erik

-------- Original Message --------

A new version of I-D, draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt 
has been successfuly submitted by Erik Nordmark and posted to the IETF 
repository.

Filename:	 draft-chakrabarti-6lowpan-ipv6-nd-simple
Revision:	 00
Title:		 IPv6 LoWPAN Neighbor Discovery and Addressing Choices
Creation_date:	 2010-03-01
WG ID:		 Independent Submission
Number_of_pages: 16

Abstract:
IETF 6LoWPAN working group defines IPv6 over low-power personal area
network (IEEE 802.15.4).  IEEE 802.15.4 and other low-power wireless
networks have limited or no usage of broadcast or multicast signaling
due to energy conservation.  Besides the wireless nodes may not
strictly follow traditional concept of IP subnet and IP-links while
connecting nodes and routers.  This document describes simple
optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and
addressing mechanisms that are useful for small scale 6LoWPAN
networks in star and mesh topologies.

The optimizations include reducing the amount of Neighbor Discovery
multicast traffic and allowing for a single subnet to span multiple
routers in a "route-over" topology.

The IETF Secretariat.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 5 Mar 2010 15:56:57 +0200

Hi Erik, Samita,

I finally read through your draft in detail. First of all, thanks for taking the time to put your thoughts in a well-written draft. Currently I should be updating the 6lowpan-nd draft to -09 before the March 8th cutoff. There are comments from Richard Kelsey and Robert Cragie to take into account. However now with this new draft I will not update 6lowpan-nd yet. I think we need to discuss this on the list and over beer(s) in Anaheim first.

So far I'm not really sure what you (and Geoff?) have in mind with this draft. My first impression is that this is 90% identical to 6lowpan-nd-08, with differences mainly in the approach to explain it and the terminology. OK, this is a good thing as we're not really that far apart. The drafts are the same in these respects:

- Use of RFC4861 possible if appropriate (6lowpan-nd has stronger language requiring the optimized approach to ensure interoperability)
- Use of the autoconf-addr model
- Autoconfiguration is basically the same (optimized model)
- The registration model between a node and its default routers is basically the same.
- Sequence number used to ensure RA info freshness
- Terminology is basically equivalent
- The same address resolution optimization is used
- neighbor cache = binding table in this practice
- Both drafts avoid DAD for EUI-64s or when DHCPv6 is used
- Both drafts (optimized version) are incompatible with RFC4861-only IPv6 interfaces (adaptation needed).
 
Now let me summarize where I see the differences between what you are proposing here, and 6lowpan-nd-08:

- Your draft suggests the use of either RFC4861 or nd-simple. I see this as a big interop risk. In 6lowpan-nd we made sure on purpose that everyone MUST support the optimized technique.
- Your draft tries to do a diff on RFC4861. Which basically means reading all of RFC4861 plus this to figure out how to implement this. We used to do that in 6lowpan-nd but decided to instead make a stand-alone specification at some point for clarity.
- nd-simple changes NS/NA messages for the purpose of node-router registration. 6lowpan-nd uses an explicit message NR/NC for the same purpose. 
- nd-simple requires hosts to perform DHCPv6 themselves, whereas 6lowpan-nd currently suggests that the router does it on their behalf. 
- nd-simple requires nodes to support redirect messages. 6lowpan-nd optimizes them away.

Here are some problems I found in the nd-simple draft:

- No Context Information support, needed for HC
- Other fine-grained optimizations are needed wrt RFC4861 in addition to these. For example there are buffer memory requirements for all neighbors that need to be removed, too many caches (not all needed) and plenty of variables to be set for 6lowpan use.
- nd-simple talks about advertising multiple /64 prefixes into a LoWPAN. This is confusing and (in my opinion) broken. HC will only work when there is a single prefix (CID=0) advertised in the LoWPAN. All other prefixes (Contexts) need to be assigned CID > 0. Furthermore Section 1.3 refers to using multiple prefixes to deal with mobility in the LoWPAN with an autoconf-addr reference. That one really confused me. autoconf-addr does not require this in our case. This also wouldn't work.
- Section 7.4 #3 talks about hosts registering to their default routers. All nodes need to do the same, otherwise address resolution, NUD etc. won't work. Or do you assume routers act as hosts when they use a default router? 
- Redirect messages as described in Section 7.4 won't work in practice with wireless mesh networks. I think it is safer to disable redirect...
- Section 7.5 assumes a routing protocol will have global information (some do, but not all). This is basically the equivalent to a whiteboard by the way.

Zach

On Mar 1, 2010, at 15:16 , Erik Nordmark wrote:

> 
> Samita and I have tried to capture a minimal set of ND optimizations in this draft.
> 
>   Erik
> 
> 
> A new version of I-D, draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt has been successfuly submitted by Erik Nordmark and posted to the IETF repository.
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
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: Erik Nordmark <[email-masked]>
Date: Sat, 06 Mar 2010 10:05:54 -0800

On 03/ 5/10 05:56 AM, Zach Shelby wrote:
> Hi Erik, Samita,
>
> I finally read through your draft in detail. First of all, thanks for
> taking the time to put your thoughts in a well-written draft.
> Currently I should be updating the 6lowpan-nd draft to -09 before the
> March 8th cutoff. There are comments from Richard Kelsey and Robert
> Cragie to take into account. However now with this new draft I will
> not update 6lowpan-nd yet. I think we need to discuss this on the
> list and over beer(s) in Anaheim first.
>
> So far I'm not really sure what you (and Geoff?) have in mind with
> this draft.

I wasn't in Hiroshima but from what I understood there was push back 
from the WG about the complexity of the specification.
Hence Samita and I went back and tried to come of with a minimal set of 
things that would be needed. Part of the reason for doing that was that 
some of the push back seemed to be that RFC 4861 works just fine, which 
I don't think is the case for route-over networks where hosts should 
keep the same IP address even if the router they use becomes unreachable.

 > My first impression is that this is 90% identical to
 > 6lowpan-nd-08, with differences mainly in the approach to explain it
 > and the terminology. OK, this is a good thing as we're not really
 > that far apart. The drafts are the same in these respects:

That might be mostly a choice of language. I think a reasonable intent 
is that host support receiving and responding to all what is in RFC 
4861. That includes responding to multicast NS. Such a thing isn't 
useful when a host is sleeping 99% of the time (it wouldn't respond 
while it is asleep) but allows a host implementation to support both 
4861 and 6lowpan behavior without needing a configuration knob to select 
between two very different behaviors.

 > - Use of the autoconf-addr model - Autoconfiguration is basically the 
same (optimized model)

Yes.

> - The registration model between a node and its default routers is basically the same.

I think the registration is quite different in that in one case it is an 
acknowledged message and in the other it is not.

> - Sequence number used to ensure RA info freshness

That isn't the purpose of the sequence number in nd-simple. It is 
required to be able to get rid of prefixes as they expire.

> - Terminology is basically equivalent

Yes, more or less.

> - The same address resolution optimization is used - neighbor cache = binding table in this practice

I think nd-simple can allow for an L2 address that is not embedded in 
the IPv6 address. I don't know if nd-08 can do that.

> - Both drafts avoid DAD for EUI-64s or when DHCPv6 is used

Yes.

> - Both drafts (optimized version) are incompatible with RFC4861-only IPv6 interfaces (adaptation needed).

No, nd-simple isn't incompatible. A host can send a NS with a node 
lifetime option to an unmodified RFC 4861 router without any problems. 
And an unmodified host will just ignore the authoritative router option 
in an RA.
Where did you see any incompatibility?

> - Your draft suggests the use of either RFC4861 or nd-simple. I see
> this as a big interop risk. In 6lowpan-nd we made sure on purpose
> that everyone MUST support the optimized technique.

That statement is opposite to how I see things. In 6lowpan-nd a host 
must know up front whether to send a NR or not.

You can't make all existing IPv6 hosts "MUST support" 6lowpan-nd.

Perhaps the different view is based on an implicit assumption that 
6lowpan nodes will always be completely separate from regular IPv6 nodes.

I suspect we'll see implementations that need to operate in both a 
6lowpan environment and in a regular IPv6 environment. That will 
definitely be the case for routers from day one, but I wouldn't be 
surprised if there are benefits for host implementations to be able to 
live in both environments.

> - Your draft tries to do a diff on RFC4861. Which basically means reading all of RFC4861 plus this to figure out how to implement this. We used to do that in 6lowpan-nd but decided to instead make…

Yes, and I view that as a feature because I don't think 6lowpan is a 
different universe. It is merely a different L2.

> - nd-simple changes NS/NA messages for the purpose of node-router registration. 6lowpan-nd uses
> an explicit message NR/NC for the same purpose.

Yep.

> - nd-simple requires hosts to perform DHCPv6 themselves, whereas 6lowpan-nd currently suggests that the router does it on their behalf.

I had missed that the routers should do DHCPv6 on behalf of the hosts.

How does that handle the case when a router dies or becomes unreachable, 
yet the DHCPv6 lease needs to be renewed? Wouldn't all the routers in 
the 6lowpan need to share information about all the leases so that 
routerM has all the state needed to be able to carry on with a lease 
that routerN originally acquired?

> - nd-simple requires nodes to support redirect messages. 6lowpan-nd optimizes them away.

I wouldn't expect redirects to be used in 6lowpans. The draft outlines 
the constraints on sending them (necessary to handle the hidden terminal 
problem.)

> - No Context Information support, needed for HC

That can easily be added.

 > - Other fine-grained optimizations are needed wrt RFC4861 in addition 
to these. For example there are buffer memory requirements for all 
neighbors that  need to be removed, too many caches (not all needed) and 
plenty of variables to be set for 6lowpan use.

I thought part of the feedback from the WG as that folks wanted the spec 
to have less differences compared to 4861. Thus I think it is useful for 
the WG to consider the implications of these fine-grained optimizations 
one by one.

> - nd-simple talks about advertising multiple /64 prefixes into a LoWPAN. This is confusing
> and (in my opinion) broken. HC will only work when there is a single
> prefix (CID=0) advertised in the LoWPAN. All other prefixes
> (Contexts) need to be assigned CID  0.

The IPv6 architecture requires that multiple prefixes can be supported. 
Even if we think that all 6lowpans for the next 10 years will be 
deployed with a single prefix that must never change, it would be 
short-sighted to design the protocol so that multiple prefixes can't 
possibly be supported.

And I thought that HC could handle more than one prefix, but perhaps 
this has changed since last time I looked.

> Furthermore Section 1.3
> refers to using multiple prefixes to deal with mobility in the LoWPAN
> with an autoconf-addr reference. That one really confused me.
> autoconf-addr does not require this in our case. This also wouldn't
> work.

Why wouldn't it work?

> - Section 7.4 #3 talks about hosts registering to their default  routers. All nodes need to do the same, otherwise address resolution,
NUD etc. won't work. Or do you assume routers act as hosts when they use
a default router?

The assumption is that the routers run some routing protocol, and that 
that routing protocol means that routers keep track (proactively or 
reactively) which neighboring routers they can reach. As a result the 
routers don't need to register themselves.

> - Redirect messages as described in Section 7.4 won't work in
> practice with wireless mesh networks. I think it is safer to disable
> redirect...

Agreed.

> - Section 7.5 assumes a routing protocol will have global
> information (some do, but not all). This is basically the equivalent
> to a whiteboard by the way.

I think one section 7.5 should be rephrased. It says:
    A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created
    from the routing protocol.

But this goes into different ways folks might want to use a wired 
backbone. One way to use a wired backbone is to run the lowpan routing 
protocol over that wired backbone. That doesn't add any new requirements 
in this area. Another way is to terminate the lowpan routing protocol at 
the edge of the wired network and use some other routing protocol across 
the wire. In the latter case there is an assumption that the 6LBR can 
determine all the hosts IP addresses. Perhaps some lowpan routing 
protocols can provide that and others can not.
But this is far from the central issue in how to do ND on 6lowpans.

    Erik

---

From: Zach Shelby <[email-masked]>
Date: Thu, 11 Mar 2010 11:16:05 +0200

Hi,

Some comments below, but then I'm cut off from e-mail until Anaheim. See you there!

On Mar 6, 2010, at 20:05 , Erik Nordmark wrote:
> I wasn't in Hiroshima but from what I understood there was push back from the WG about the complexity of the specification.
> Hence Samita and I went back and tried to come of with a minimal set of things that would be needed. Part of the reason for doing that was that some of the push back seemed to be that RFC 4861 works just fine, which I don't think is the case for route-over networks where hosts should keep the same IP address even if the router they use becomes unreachable.

Correct, we both agree there.

> That might be mostly a choice of language. I think a reasonable intent is that host support receiving and responding to all what is in RFC 4861. That includes responding to multicast NS. Such a thing isn't useful when a host is sleeping 99% of the time (it wouldn't respond while it is asleep) but allows a host implementation to support both 4861 and 6lowpan behavior without needing a configuration knob to select between two very different behaviors.

It would be a mistake to try to mix RFC4861 and a highly optimized version using a registration model (nd-simple or 6lowpan-nd) on the same link. This is confusing for the implementations and will definitely break. As ND is a link protocol, how about we keep the assumption that all interfaces on the same LoWPAN run the same ND. 

Now the re-use of code, techniques and tools between RFC4861 and an optimized ND makes sense where possible. But this is a different issue.

> I think the registration is quite different in that in one case it is an acknowledged message and in the other it is not.

Got you. This is something that would probably need to be fixed for NS/NA. Not acknowledging this over lossy links could become problematic? What if there is some kind of error regarding the Node-Lifetime Option? In my opinion a registration works better if it is explicitly acknowledged. If doing it with a unicast NS that could be acknowledged with a unicast NA?

> That isn't the purpose of the sequence number in nd-simple. It is required to be able to get rid of prefixes as they expire.

6lowpan-nd uses it for that purpose too. 

> I think nd-simple can allow for an L2 address that is not embedded in the IPv6 address. I don't know if nd-08 can do that.

Yes, it can do that too in nd-08. As nodes may have multiple IPv6 addresses (link-local and global at least) the NR is able to hold multiple address options. In order for address-resolution to work the router needs to have entries for all IP addresses of nodes registered. How would this work in nd-simple? The current spec would only allow you to register one address at a time (the IPv6 source address). Do you just keep repeating multiple NSs and NAs? 

> No, nd-simple isn't incompatible. A host can send a NS with a node lifetime option to an unmodified RFC 4861 router without any problems. And an unmodified host will just ignore the authoritative router option in an RA.

Sleeping nodes mixed with non-sleeping nodes will cause plenty of problems for example. At the same time, unmodified routers would not include the authoritative router option, so it wouldn't work for route-over at least. Address resolution will fail for nd-simple hosts for unmodified routers etc. As I suggested above, let's not try to mix multiple flavors of ND in the same LoWPAN. If nothing else it is unnecessarily confusing. 

> That statement is opposite to how I see things. In 6lowpan-nd a host must know up front whether to send a NR or not.
> 

You don't need to.  You just perform some adaptation in the same place you do 6lowpan-IPv6 adaptation under an unmodified IPv6 stack (usually in the interface driver or wireless interface). Of course that adaptation should be minimized. There is a section about that in 6lowpan-nd. 

> 
> Perhaps the different view is based on an implicit assumption that 6lowpan nodes will always be completely separate from regular IPv6 nodes.
> 
> I suspect we'll see implementations that need to operate in both a 6lowpan environment and in a regular IPv6 environment. That will definitely be the case for routers from day one, but I wouldn't be surprised if there are benefits for host implementations to be able to live in both environments.

Sure, and the 6lowpan interface on an IPv6 router can deal with this. It should be totally transparent to the IPv6 stack of the router of course. This is how we do it today.

> Yes, and I view that as a feature because I don't think 6lowpan is a different universe. It is merely a different L2.

As ND is a link protocol, I don't see a problem with different links running slightly different ND specifications. See above.
> How does that handle the case when a router dies or becomes unreachable, yet the DHCPv6 lease needs to be renewed? Wouldn't all the routers in the 6lowpan need to share information about all the leases so that routerM has all the state needed to be able to carry on with a lease that routerN originally acquired?

Good point, probably the lease info would have to be returned to the host. This is just one option, the host is of course allowed do DHCPv6 itself as well.

> I wouldn't expect redirects to be used in 6lowpans. The draft outlines the constraints on sending them (necessary to handle the hidden terminal problem.)

Then I would just disable them.

> The IPv6 architecture requires that multiple prefixes can be supported. Even if we think that all 6lowpans for the next 10 years will be deployed with a single prefix that must never change, it would be short-sighted to design the protocol so that multiple prefixes can't possibly be supported.
> 
> And I thought that HC could handle more than one prefix, but perhaps this has changed since last time I looked.

Here we have to be careful. You may have only one valid default prefix in a LoWPAN (CID=0), otherwise you would have no clue what the compressed prefix means. You may have up to 15 more prefixes (even up to /128) in addition to this, but those must be marked with CID > 0 and are used for compressing addresses, not for autoconfiguration. 

You may have multiple logical LoWPANs (each with its own default prefix) overlapping, so in that way it fulfills the IPv6 architecture requirement. However a LoWPAN router must only advertise the RA information originating from one edge router (you hint at this in nd-simple). Thus the set of edge routers and lowpan routers advertising the same default prefix (and the hosts attached to them) make up a logical LoWPAN. Hosts can participate in more than one LoWPAN at a time (keeping track of that state) but routers can not.
> The assumption is that the routers run some routing protocol, and that that routing protocol means that routers keep track (proactively or reactively) which neighboring routers they can reach. As a result the routers don't need to register themselves.

You are assuming that a routing protocol replaces ND between LoWPAN routers? I wouldn't do that. Routers still need to perform resolve addresses somehow between themselves. A LoWPAN also needs to bootstrap before starting up its routing protocol. In 6lowpan-nd routers still register with their own default routers, but that can optionally be refreshed using routing traffic. 

> But this goes into different ways folks might want to use a wired backbone. One way to use a wired backbone is to run the lowpan routing protocol over that wired backbone. That doesn't add any new requirements in this area. Another way is to terminate the lowpan routing protocol at the edge of the wired network and use some other routing protocol across the wire. In the latter case there is an assumption that the 6LBR can determine all the hosts IP addresses. Perhaps some lowpan routing protocols can provide that and others can not.

Yep. This is why we agreed to now specify a base ND protocol, and this kind of Extended LoWPAN behavior will be discussed in a different draft.

Zach

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Mar 2010 07:40:41 -0800

On 03/11/10 01:16 AM, Zach Shelby wrote:

>> That might be mostly a choice of language. I think a reasonable
>> intent is that host support receiving and responding to all what is
>> in RFC 4861. That includes responding to multicast NS. Such a thing
>> isn't useful when a host is sleeping 99% of the time (it wouldn't
>> respond while it is asleep) but allows a host implementation to
>> support both 4861 and 6lowpan behavior without needing a
>> configuration knob to select between two very different behaviors.
>
> It would be a mistake to try to mix RFC4861 and a highly optimized
> version using a registration model (nd-simple or 6lowpan-nd) on the
> same link. This is confusing for the implementations and will
> definitely break. As ND is a link protocol, how about we keep the
> assumption that all interfaces on the same LoWPAN run the same ND.

I don't see what would break if the nodes are liberal in what they 
except (such as multicast NS) and conservative in what they send (avoid 
sending multicasts, send registrations). That is what I'm advocating.

Can you specify the details of what you think would break?

>> I think the registration is quite different in that in one case it
>> is an acknowledged message and in the other it is not.
>
> Got you. This is something that would probably need to be fixed for
> NS/NA. Not acknowledging this over lossy links could become
> problematic? What if there is some kind of error regarding the
> Node-Lifetime Option? In my opinion a registration works better if it
> is explicitly acknowledged. If doing it with a unicast NS that could
> be acknowledged with a unicast NA?

The NS itself is acknowleged by a unicast/solicited NA.
My point is that the registration (the Node Lifetime option) is *not* 
acknowleged. There isn't any need for that, since there isn't any need 
for DAD.

> 6lowpan-nd uses it for that purpose too.

I just re-read nd-08 and I don't find any description of a procedure 
that specifies this. Which section are you thinking of?
And nd-08 doesn't specify how there can be multiple ERs originating the 
same prefixes - wouldn't they have to coordinate the sequence numbers 
they use?

>> I think nd-simple can allow for an L2 address that is not embedded
>> in the IPv6 address. I don't know if nd-08 can do that.
>
> Yes, it can do that too in nd-08. As nodes may have multiple IPv6
> addresses (link-local and global at least) the NR is able to hold
> multiple address options. In order for address-resolution to work the
> router needs to have entries for all IP addresses of nodes
> registered. How would this work in nd-simple? The current spec would
> only allow you to register one address at a time (the IPv6 source
> address). Do you just keep repeating multiple NSs and NAs?

In nd-simple-00 there would have to be a NS with a Node Lifetime option 
for each IP address that a host needs to register. I don't know if there 
is much to gain by including a list of addresses, since typically a host 
would have only one address (in addition to the link-local address, but 
I don't think there is any need to register it.)

>>
>>> - Both drafts (optimized version) are incompatible with
>>> RFC4861-only IPv6 interfaces (adaptation needed).
>>
>> lifetime option to an unmodified RFC 4861 router without any
>> problems. And an unmodified host will just ignore the authoritative
>> router option in an RA. Where did you see any incompatibility?
>
> Sleeping nodes mixed with non-sleeping nodes will cause plenty of
> problems for example. At the same time, unmodified routers would not
> include the authoritative router option, so it wouldn't work for
> route-over at least. Address resolution will fail for nd-simple hosts
> for unmodified routers etc. As I suggested above, let's not try to
> mix multiple flavors of ND in the same LoWPAN. If nothing else it is
> unnecessarily confusing.

Perhaps you have a different model for sleeping; I'm assuming hosts can 
sleep whenever they want but that routers are on all the time.
We worked through examples where hosts where sleeping and the 
host-initiated mode in nd-simple seems to handle that well. For 
instance, a host sends a RS when it needs an RA with no unsolicated RAs.

nd-08 seems to have routers send unsolicited RAs, which will either have 
to wake up the sleeping hosts, or will not be seen by the sleeping hosts.

>>> - Your draft suggests the use of either RFC4861 or nd-simple. I
>>> see this as a big interop risk. In 6lowpan-nd we made sure on
>>> purpose that everyone MUST support the optimized technique.
>>
>> That statement is opposite to how I see things. In 6lowpan-nd a
>> host must know up front whether to send a NR or not.
>>
> You don't need to.  You just perform some adaptation in the same
> place you do 6lowpan-IPv6 adaptation under an unmodified IPv6 stack
> (usually in the interface driver or wireless interface). Of course
> that adaptation should be minimized. There is a section about that in
> 6lowpan-nd.

I saw that suggested hack in the draft. Doesn't belong in a standards 
track protocol IMHO.

>> Yes, and I view that as a feature because I don't think 6lowpan is
>> a different universe. It is merely a different L2.
>
> As ND is a link protocol, I don't see a problem with different links
> running slightly different ND specifications. See above.

I do see a problem with that.

I don't see a problem with having different sets of options (or even 
different sets of messages) that are used based on the properties of an 
L2 and the address configuration. But it needs to remain one cohesive 
protocol.

>> How does that handle the case when a router dies or becomes
>> unreachable, yet the DHCPv6 lease needs to be renewed? Wouldn't all
>> the routers in the 6lowpan need to share information about all the
>> leases so that routerM has all the state needed to be able to carry
>> on with a lease that routerN originally acquired?
>
> Good point, probably the lease info would have to be returned to the
> host. This is just one option, the host is of course allowed do
> DHCPv6 itself as well.

If the lease information needs to be returned to the host so that the 
host can pass that lease information to another router (to ask that 
router to run a DHCP client on its behalf) could work. Seems to be a lot 
more complex than just having the client running a DHCP client itself.

>> I wouldn't expect redirects to be used in 6lowpans. The draft
>> outlines the constraints on sending them (necessary to handle the
>> hidden terminal problem.)
>

In the specification?
I think the specification should explain the issue; it might than 
conclude that redirects SHOULD NOT be used. But nd-08 is utterly silent 
on redirects hence the reader can't tell whether they are allowed, 
forbidden, have issues, etc ...

Keep in mind that we are writing a specification that will, if 
successful, have a lifetime that exceeds the lifetime of the products 
folks are building today.

>> The IPv6 architecture requires that multiple prefixes can be
>> supported. Even if we think that all 6lowpans for the next 10 years
>> will be deployed with a single prefix that must never change, it
>> would be short-sighted to design the protocol so that multiple
>> prefixes can't possibly be supported.
>>
>> And I thought that HC could handle more than one prefix, but
>> perhaps this has changed since last time I looked.
>
> Here we have to be careful. You may have only one valid default
> prefix in a LoWPAN (CID=0), otherwise you would have no clue what the
> compressed prefix means. You may have up to 15 more prefixes (even up
> to /128) in addition to this, but those must be marked with CID>  0
> and are used for compressing addresses, not for autoconfiguration.

That isn't what nd-08 says. It doesn't restrict the setting of the A-bit 
on the prefixes that have C set and CID !=0. Thus AFAICT there can be an 
unbounded set of prefixes for the lowpan, and up to 16 of them (which 
includes local and remote prefixes) can be compressed.

If I'm mistaken then please point out the paragraph in nd-08 that says 
that CID=0 is special.

> You may have multiple logical LoWPANs (each with its own default
> prefix) overlapping, so in that way it fulfills the IPv6 architecture
> requirement. However a LoWPAN router must only advertise the RA
> information originating from one edge router (you hint at this in
> nd-simple).

That isn't what nd-simple says. It says that if a 6LR receives RAs with 
different Autoritative Routers (i.e., information originated from 
different  6LBRs), then the 6LR can not collapse that information into a 
single RA but must send separate RAs. (Otherwise we'd loose the 
association between authoritative router and the prefixes.)

 > Thus the set of edge routers and lowpan routers
> advertising the same default prefix (and the hosts attached to them)
> make up a logical LoWPAN. Hosts can participate in more than one
> LoWPAN at a time (keeping track of that state) but routers can not.

I don't see why such restrictions are needed.
A simpler protocol seems to have less constraints ;-)

>> The assumption is that the routers run some routing protocol, and
>> that that routing protocol means that routers keep track
>> (proactively or reactively) which neighboring routers they can
>> reach. As a result the routers don't need to register themselves.
>
> You are assuming that a routing protocol replaces ND between LoWPAN
> routers? I wouldn't do that. Routers still need to perform resolve
> addresses somehow between themselves. A LoWPAN also needs to
> bootstrap before starting up its routing protocol. In 6lowpan-nd
> routers still register with their own default routers, but that can
> optionally be refreshed using routing traffic.

And with nd-simple a 6LR would send RS messages (with SLLAO) to get an 
RA from a 6LBR, or from a 6LR which has already found a 6LBR.
That is sufficient to get the routers finding each other.

There isn't anything preventing routers from using NR/NS (for Node 
Lifetime, NUD, or both) between each other, but it doesn't sound useful 
given that a routing protocol would probably do that as part of the 
normal operation of the routing protocol.

BTW: I thought the plan was to remove DAD support from 6lowpan-nd, yet 
there is lots of test around duplicate handling (including duplicate 
IID) and optimistic DAD. That isn't necessary if we assume the EUI-64 
are unique.

    Erik

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 22 Mar 2010 18:45:14 +0100

Hi Erik, Samita,

Thanks for your draft. This proposal is much closer to what I had in mind
myself and I feel this is a great step forward!

I have a few questions / comments:
- Assumptions: why do you assume that 6LR use RA to configure their global
addresses while host are allowed to use DHCPv6? In IPv6, routers are
typically ignoring received RAs... It is not very clear whether your
proposal allows the case where all addresses (host and 6LR) are assigned
using DHCPv6. It might also be that in a route-over situation the routing
protocol itself would take care of distributing well chosen
prefixes/addresses to allow prefix aggregation in routing tables or routing
messages.
- Is there any relation between the concept of 'node lifetime' and
'reachable time'? Couldn't you achieve the same effect by setting high
values for the reachable time?
- Section 7.3: I feel like you are underestimating the role that the routing
protocol might play. If you take the example of what RPL is defining, an
IPv6 host could very well be a RPL leaf node, in which case it might
discover its default router by listening to DIO messages, and send DAO to
'register'. In addition, if the 6LR are RPL routers that use DHCPv6 or
another scheme for address allocation, RS/RA might be completely disabled.
What do you think?
- Section 7.3: Reading your description, is it correct to say that hosts
perform NUD and address resolution for their default router? (of course the
number of messages is reduced by the heavy use of the SLLA option). Do you
also use NS/NA to perform NUD and address resolution between 6LR? 
- Section 7.3: ND uses already upper-layer protocol feedback. Would you
consider to extend it to include lower layer feedback?

To summarize my comments, I would like to understand a bit better how you
envision the operation of nd-simple when a routing protocol such as RPL is
used on top of it.

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Erik Nordmark
Sent: lundi, 1. mars 2010 05:17
To: 6lowpan
Subject: [6lowpan] Fwd: New Version Notification
fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00

Samita and I have tried to capture a minimal set of ND optimizations in this
draft.

    Erik

-------- Original Message --------

Abstract:
IETF 6LoWPAN working group defines IPv6 over low-power personal area network
(IEEE 802.15.4).  IEEE 802.15.4 and other low-power wireless networks have
limited or no usage of broadcast or multicast signaling due to energy
conservation.  Besides the wireless nodes may not strictly follow
traditional concept of IP subnet and IP-links while connecting nodes and
routers.  This document describes simple optimizations to IPv6 Neighbor
Discovery protocol(RFC4861), and addressing mechanisms that are useful for
small scale 6LoWPAN networks in star and mesh topologies.

The optimizations include reducing the amount of Neighbor Discovery
multicast traffic and allowing for a single subnet to span multiple routers
in a "route-over" topology.

The IETF Secretariat.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Mar 2010 00:05:16 +0100

> IPv6 host could very well be a RPL leaf node, in which case it might
discover
> its default router by listening to DIO messages, and send DAO to
'register'. In
> addition, if the 6LR are RPL routers that use DHCPv6 or another scheme
for
> address allocation, RS/RA might be completely disabled.

[Pascal] 

The classical way is that the routing protocol operates between routers.
ND provides the abstraction for a host to locate and interact with its
router. This is why in the current WG doc, the registration also belongs
to ND. Based on the registration, it is up to the router to redistribute
the information in the route-over protocol, whether that is RPL or
something else. If we lose the ND registration capability, we end up
forcing every host attached to a RPL network  to support RPL. Don't you
feel that's wrong?

Pascal

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 23 Mar 2010 15:41:39 +0100

Hi Pascal,

Thanks for your answer.

> - Section 7.3: I feel like you are underestimating the role that the 
> routing protocol might play. If you take the example of what RPL is 
> defining, an
> discover its default router by listening to DIO messages, and send DAO 
> to 'register'. In addition, if the 6LR are RPL routers that use DHCPv6 
> or another scheme for address allocation, RS/RA might be completely
disabled.
[Pascal] 
The classical way is that the routing protocol operates between routers. ND
provides the abstraction for a host to locate and interact with its router.
This is why in the current WG doc, the registration also belongs to ND. 
[Mathilde]
What you are saying makes sense. Although in 4861 the host is not really
registering with the router it is just discovering it. Hence, it is a host
-> router relationship but the opposite is not quite true, the router does
not use ND to route to the host (at least for off-link prefixes)... 

[Pascal]
Based on the registration, it is up to the router to redistribute the
information in the route-over protocol, whether that is RPL or something
else. If we lose the ND registration capability, we end up forcing every
host attached to a RPL network  to support RPL. Don't you feel that's wrong?
[Mathilde]
At this stage I don't know if this is right or wrong, but I would like to
understand what RPL is assuming? It's not so clear in the draft... Maybe it
relates to the questions that were asked on the role of leaf nodes during
the WG meeting yesterday.

Best,
Mathilde

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Mar 2010 14:12:38 -0700

> prefixes/addresses to allow prefix aggregation in routing tables or routing

We just borrowed this from draft-ietf-6lowpan-nd-08.

As I said during the presentation yesterday, I think the key thing to 
standardize around ND is the host-router interaction. This router-border 
interaction is, as you point out, something that can be done in 
different ways.

I think it makes sense to provide an optional way to perform the 
router-border interaction as part of the ND work, while making it clear 
that there are other ways to do those pieces such as the routing protocol.

But I don't think DHCPv6 can be used to assign the same prefix to all 
the routers in the 6lowpan (DHCP prefix delegation would give them all 
different prefixes which is not what we want.)

> values for the reachable time?

The reachable time in RFC 4861 is a per-link property advertised by the 
routers, that affects how quickly NUD can detect unreachable nodes.

The node lifetime (aka registration lifetime) needs to be tied to how 
each host sleeps, and that is likely to be different for different hosts.

Hence the flow of the two lifetimes are in opposite directions.

> another scheme for address allocation, RS/RA might be completely disabled.

The assumption for the ND work is that there is something called a 
"host" which does not participate in the routing protocol.
If all the nodes in the network participate in the routing protocol, 
whether it is an enterprise network running OSPF or a lowpan running 
RPL, there is little or no need for Neighbor Discovery.

> number of messages is reduced by the heavy use of the SLLA option).

The address resolution for the router comes from the host sending a RS 
and receiving one (or more) RAs in response, where the RA contains the 
SLLA option.

> Do you

While it isn't forbidden to use NUD and other parts of RFC 4861 
router-to-router, I don't think this is common in the case of RIP, OSPF, 
or IS-IS, and I don't expect it to be common for the routing protocols 
that would be used for lowpan networks.

> consider to extend it to include lower layer feedback?

One can use lower-layer negative feedback (packet didn't make it; link 
lost) as an indication and hint, but in general lower-layer positive 
feedback isn't an indication that the packet made it to the IP 
destination. (That observation was made by Steve Deering a long time 
ago, as was the basis for the NUD design.)

> envision the operation of nd-simple when a routing protocol such as RPL is

The key for nd-simple is the host-to-router interaction, with protocols 
like RPL handling the router-to-router (including edge/border routers).

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Mar 2010 22:15:33 +0100

Hi Mathilde:

That's a great question that we need to bring to ROLL to be refined. In
short, RPL expects at least that the host is capable to notify its
router that it has an address that should be injected in the subnet
routing. RPL also expects that the host can tag a packet in such a
fashion that this can be interpreted by the router as an instanceID. The
details of how those things are done is not specified so far.

I would not favor a method that makes the host to router interface
specific to RPL if we can avoid that.

Best wishes for the interop!

Pascal

> From: Mathilde Durvy (mdurvy)
> Sent: Tuesday, March 23, 2010 7:42 AM
> To: Pascal Thubert (pthubert); 'Erik Nordmark'; '6lowpan'
> Subject: RE: [6lowpan] Fwd: New Version
Notificationfordraft-chakrabarti-
> 6lowpan-ipv6-nd-simple-00
> 
> Hi Pascal,
> 
> Thanks for your answer.
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 23 Mar 2010 14:44:14 -0700

Hi Erik,

On Mar 23, 2010, at 2:12 PM, Erik Nordmark wrote:

> As I said during the presentation yesterday, I think the key thing  
> to standardize around ND is the host-router interaction. This router- 
> border interaction is, as you point out, something that can be done  
> in different ways.
>
> router-border interaction as part of the ND work, while making it  
> clear that there are other ways to do those pieces such as the  
> routing protocol.
>
> But I don't think DHCPv6 can be used to assign the same prefix to  
> all the routers in the 6lowpan (DHCP prefix delegation would give  
> them all different prefixes which is not what we want.)

I think Mathilde was referring to using DHCPv6 to assign only IPv6  
addresses (not prefixes) and that the only router-border interaction  
is through the use of DHCPv6 relay agents.  I agree that DHCPv6 prefix  
delegation in 6LoWPAN networks doesn't make much sense in most  
situations.

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 24 Mar 2010 18:10:24 -0700

Hi Mathilde,

Thanks for your comments.  Here are some more  responses in addition
to Erik's and Pascal's.
Please see in-line.

> myself and I feel this is a great step forward!

Great to hear that from you!

> prefixes/addresses to allow prefix aggregation in routing tables or routing

6LRs are assumed to be dual personalities. In most cases they are
acting as a routers. But indeed they are special as they form global
addresses from prefixes through autoconfiguration and they can also
send RS to their neighbors as they come up.

As for DHCPv6-pd, nd-simple does not do DHCP prefix delegation. It
simply relays the prefixes to neighbors since the 6lowpan contains
same prefix throughut. Multiple prefixes are possible - but they are
same throughout the 6lowpan.

This draft however does not discuss DHCPv6 address assignment and it
is left to a separate draft. nd-simple only discusses address
autoconfiguration.

If DHCPv6 relay/server is used then all addresses could be assigned by
the DHCP server when the DHCP-server would know that it has to use the
same prefix for all addresses over a 6lowpan.  It is not written in
the draft and we think the DHCP-related draft would cover that.

> another scheme for address allocation, RS/RA might be completely disabled.

The same logic applies to regular IPv6 network. IPv6 ND cannot and
should not depend on a particular routing protocol behavior that is
running on the nodes.

Note that the concept of 6LoWPAN link(route-over) is a bit different
than regular IPv6-link.  Not all 6lowPAN networks will run RPL or
routing protocols and yet they need to communicate without static
configuration.

> envision the operation of nd-simple when a routing protocol such as RPL is

I'd think RPL will do p2mp, mp2p or p2p routing within a 6LoWPAN .
6LRs may act as hosts as well, as they have aquired their global
prefixes. 6LRs will also know how to forward packets to 6LBRs when the
destination addresses are not resolved by RPL'ed routes.

Thanks,
-Samita

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 30 Mar 2010 20:12:19 +0200

Hi Samita, Erik, 

Thanks a lot for you answers, it helps! I think these are the kind of things
you might want to include in the next version although I think the current
text is already very good.

I agree we should keed ND independent from the routing protocol. I guess my
comment was only that if the routing protocol happens to duplicate some of
the functionalities provided by ND maybe these should become optional to
avoid wasted resources...

Best,
Mathilde 

-----Original Message-----
From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: mercredi, 24. mars 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: Erik Nordmark; 6lowpan
Subject: Re: [6lowpan] Fwd: New Version Notification

Hi Mathilde,

Thanks for your comments.  Here are some more  responses in addition to
Erik's and Pascal's.
Please see in-line.

On Mon, Mar 22, 2010 at 10:45 AM, Mathilde Durvy (mdurvy) <[email-masked]>
wrote:
> Hi Erik, Samita,
>
> Thanks for your draft. This proposal is much closer to what I had in 
> mind myself and I feel this is a great step forward!
>

> - Assumptions: why do you assume that 6LR use RA to configure their 
> global addresses while host are allowed to use DHCPv6? In IPv6, 
> routers are typically ignoring received RAs... It is not very clear 
> whether your proposal allows the case where all addresses (host and 
> 6LR) are assigned using DHCPv6. It might also be that in a route-over 
> situation the routing protocol itself would take care of distributing 
> well chosen prefixes/addresses to allow prefix aggregation in routing 
> tables or routing messages.

6LRs are assumed to be dual personalities. In most cases they are acting as
a routers. But indeed they are special as they form global addresses from
prefixes through autoconfiguration and they can also send RS to their
neighbors as they come up.

As for DHCPv6-pd, nd-simple does not do DHCP prefix delegation. It simply
relays the prefixes to neighbors since the 6lowpan contains same prefix
throughut. Multiple prefixes are possible - but they are same throughout the
6lowpan.

This draft however does not discuss DHCPv6 address assignment and it is left
to a separate draft. nd-simple only discusses address autoconfiguration.

If DHCPv6 relay/server is used then all addresses could be assigned by the
DHCP server when the DHCP-server would know that it has to use the same
prefix for all addresses over a 6lowpan.  It is not written in the draft and
we think the DHCP-related draft would cover that.

>> routing
disabled.
> What do you think?

The same logic applies to regular IPv6 network. IPv6 ND cannot and should
not depend on a particular routing protocol behavior that is running on the
nodes.

Note that the concept of 6LoWPAN link(route-over) is a bit different than
regular IPv6-link.  Not all 6lowPAN networks will run RPL or routing
protocols and yet they need to communicate without static configuration.

> - Section 7.3: Reading your description, is it correct to say that 
> hosts perform NUD and address resolution for their default router? (of 
> course the number of messages is reduced by the heavy use of the SLLA 
> option). Do you also use NS/NA to perform NUD and address resolution
between 6LR?
> - Section 7.3: ND uses already upper-layer protocol feedback. Would 
> you consider to extend it to include lower layer feedback?
>
> To summarize my comments, I would like to understand a bit better how 
> you envision the operation of nd-simple when a routing protocol such 
> as RPL is used on top of it.
>

I'd think RPL will do p2mp, mp2p or p2p routing within a 6LoWPAN .
6LRs may act as hosts as well, as they have aquired their global prefixes.
6LRs will also know how to forward packets to 6LBRs when the destination
addresses are not resolved by RPL'ed routes.

Thanks,
-Samita

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Erik Nordmark
> addressing mechanisms that are useful for small scale 6LoWPAN networks in
star and mesh topologies.