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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
