On Oct 13, 2009, at 12:05 PM, Carsten Bormann wrote:
[...] does implement RFC 4861 in a route-over configuration and
passes the IPv6 Ready - Phase 2 tests.
Ah, that was an eye-opener about what people mean when they say
"4861 works" -- they get the checkmark!
SCNR.
For me, the discussion isn't whether or not RFC 4861 works - some of
the mechanisms it defines clearly does not work in the networks we
care about. The discussion is whether or not there are aspects of RFC
4861 that we should NOT be changing but are.
Another discussion point to raise is the properties of the "binding
table" vs. the "neighbor cache". A significant difference is that the
binding table is no longer a cache in the sense that the attachment
router MUST maintain state about any host currently attached to it.
If the binding table is full, a node cannot attach to it. Is this a
concern for some?
We have found NUD useful for determining reachability with any
neighboring node - not just parents in the routing DAG.
That is indeed a useful function.
Using ND as a neighborHOOD discovery protocol would argue for
implementing NS/NA, as is allowed (but not required) for 6lowpan-
ND. NeighborHOOD discovery typically is a routing function, though,
so it is hard to discuss this in general terms in the ND spec. It
certainly should not be REQUIRED if the routing protocol does not
use it (e.g., because it has a different neighborHOOD discovery
protocol, or only supports host-to-host after a redirect).
NeighborHOOD discovery would also include address resolution. While
the draft currently states that NS/NA are "not required", perhaps it
would be more correct to say that the implementation of processing NS/
NA messages is required as per RFC 4861, but that the transmission of
them is optional. Or did we really intend to make their
implementation optional as well?
We have found SLLAO useful for communicating both short and
extended versions of the link address.
6lowpan-ND does not change RA from 4861, so that is still there.
(Again, NS is optional in 6lowpan-ND.)
Understood.
Also, while the stack does perform DAD when assigning an address to
the interface, duplicates outside radio range will not be detected.
In fewer words, DAD does *not* work.
Exactly. DAD requires a different mechanism - but are we sure other
parts of the draft are simply optimizations to RFC 4861?
This has not a problem because we use lightweight form of DHCP to
assign unique addresses and have control over the
system deployment.
I don't think DHCPv6 can do duplicate detection on the EUI-64
(that's why it REQUIRES DAD), so your addresses are as unique as
your EUI-64s are.
(NR/NC is a rather simplified form of DHCP, but adds duplicate
detection.)
The server doesn't have to assign an address if it doesn't want to.
The address doesn't have to map to the node's EUI-64 (bad for
compression, but why people argue for address resolution). The node
may change it's EUI-64 (original reason why we thought we didn't need
address resolution). Philosophically, I'd prefer to avoid duplicates
rather than detect them.
My summary of this discussion:
If we decide we don't need DAD, we can really simplify ND!
My words would be: if we don't need DAD, then its really just the
applicable parts of RFC 4861.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
