Subject: Re: [6lowpan] Fwd: New Version Notification for

From: "Reddy, Joseph" <[email-masked]>
Date: Tue, 9 Mar 2010 18:58:57 -0600

Hi Erik, Samita,

A few questions on your nd-simple draft

1. In Section 5.1, you suggest to skip DaD is using EUI-64 style MAC addresses. What about IPv6 addresses constructed using the 16-bit short addresses ( that were assigned throgh DHCP ) ? Do you propose to skip DaD in that case as well ?

2. In your response to Zach, you said
"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. "

What about the fact that an unmodified RFC4861 router that attempts to perform NUD to the host will fail since the host is sleep state most of the time. Will this not cause the router to incorrectly remove the host from its neighbor cache ?

-Regards, Joseph

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:
> - Use of RFC4861 possible if appropriate (6lowpan-nd has stronger language requiring the optimized approach to ensure interoperability)

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?

> 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.

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 a stand-alone specification at some point for clarity.

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.)

> Here are some problems I found in the nd-simple draft:
>
> - 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

------------------------------

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

End of 6lowpan Digest, Vol 62, Issue 11
***************************************