Jonathan,
The discussion below is really useful. Aside from do we need to
perform DAD (yes, we do, but I'll get back to that later) - what I
hear you saying is that being able to perform functions like NUD and
AR within your local scope is useful? This really is local neighbor
discovery as it only gets you one hop. NS/NA doesn't help you with
neighborHOOD operations (across the whole LoWPAN).
If the link is providing a mechanism to deal with sleeping neighbors
(you can't always assume that though), then NS/NA would allow you to
check on those neighbors for NUD. Is NUD really useful just for nodes
within radio range (maybe a very small subset of the LoWPAN)?
Separately there needs to be a discussion if AR is needed at all and
over what scope.
Currently NS/NA is totally optional for nodes to implement. In the
last couple versions of the draft they had been unused.
Zach
On Oct 13, 2009, at 22:49 , Jonathan Hui wrote:
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
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
