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.
- 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.
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?
- 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.
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).
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?
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.
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.
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.
- 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.)
Then I would just disable them.
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
