[...] 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.
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).
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.)
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.
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.)
My summary of this discussion:
If we decide we don't need DAD, we can really simplify ND!
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
