Splitting off the host-router portion into its own WG document is a
good thing to do.
The question for me is what to do with the other half - specifically
the DAD portion.
First, I do believe that having a completely separate mechanism solely
for detecting duplicate addresses is unnecessary overhead in real
production deployments. In some cases, applications will accept the
extremely low probability that a duplicate address will exist in the
network. In other cases, networks will have other mechanisms in place
that can (and will) be used to assign unique identifiers (e.g. through
commissioning, strong security associations, DHCPv6, etc.) within the
proper scope which may be used to form unique IPv6 addresses. If the
identifiers are *assigned* in such a way to be unique, the added
benefit of *detecting* failures in the assignment mechanism is
marginal. For these reasons, I think there is consensus in this
working group that DAD should be optional at best.
Second, I'm not yet comfortable with the whiteboard mechanism, as
specified in nd-07, becoming a WG document. There is consensus in
this WG that the whiteboard mechanism does not work in all scenarios
and should be optional at best. Given that, I think this WG needs to
think more about the broader effects of specifying a particular way to
do DAD while making it optional. Having an option (or multiple
options) could cause interoperability issues and confusion down the
line.
Third, I'm not sure, frankly, that the whiteboard mechanism is
something of broad interest to members of the WG. Looking through the
mailing lists, I haven't found much (any?) support for the whiteboard
outside of the authors. In fact, I have found more comments of
concern. I also don't think we've even polled the WG about whether
the whiteboard mechanism should be taken up in a WG document.
--
Jonathan Hui
On Nov 11, 2009, at 6:50 PM, Carsten Bormann wrote:
After the 6LoWPAN meeting, there have been some hallway conversations
on the need for DAD vs. the expense of DAD. Clearly, the 4861 way of
involving potentially all hosts in that process is not applicable in
most interesting 6LoWPAN configurations. More generally speaking,
whatever we do here, it should not involve the hosts.
The remaining discussions essentially were about how the "fabric"
(please excuse me using that term, which I'll use for the set of nodes
that are not just hosts) might achieve proper address allocation
and/or validation (DAD). The right answer seems to depend on the
specific areas of application, network configurations, and
characteristics of that fabric. For some cases, the centralized
approach with one or more edge routers is the right way to do this;
for others, the additional messages needed for a distributed approach
may be justified by the increased flexibility possible with that.
But the important point is that whatever the fabric does here, the
hosts do not care. They want to register their addresses with the
fabric (not just for allocation/DAD, but foremost to get routed to),
and couldn't care less how that oracle comes up with "yes" or "no", or
how it derives any allocations requested. 6LoWPAN-ND differs from
4861 in that the host-router interface is fully node-initiated, which
is the only appropriate way to do this with potentially sleeping
nodes.
Keeping that host-router interface simple and interoperable is the
most important concern: There will be billions of these 6LoWPAN host
nodes, and their interface to the network should be based on a stable
specification and isolated from the specifics of the intra-fabric
algorithms.
So the (in hindsight very obvious) way forward is:
-- split off the host-router interface part of 6LoWPAN-ND into one
document of its own. This document will contain the router
discovery and node registration protocol components of
draft-ietf-6lowpan-nd-07.txt (NR/NC with code != 1, the RA
parameters/options). Based on the input from 6man, the ADs and the
IAB, this will also now make use of the terminology in
draft-ietf-autoconf-adhoc-addr-model-00.txt that is quickly
becoming the new consensus for this kind of network. This part of
the split is the document that will update RFC 4944 in the way
envisioned by RFC 4861 section 1.
-- rename the rest of draft-ietf-6lowpan-nd-07.txt, i.e. the
fabric-side part (relayed NR/NC, Edge Router operation, OIIO) into
"6LoWPAN Edge Router backend", as a draft separate from the
above common router discovery/node registration protocol.
-- go ahead and define other backends for those cases that merit it.
Three types of backends beyond the existing Edge-Router based backend
have been mulled over in various hallways so far:
-- a multicast-based backend where all 6LoWPAN routers announce and
defend their client hosts' addresses between themselves (without
involving the hosts). A degenerate case is the simple star
network, where the single hub node can do all this all by itself.
-- a routing-system based backend, where the management of addresses
is integrated into the routing protocol (e.g., in RPL by adding
information to DAO type messages and processing rules).
-- a DHCP-based backend (which could use either of the above for DAD).
This is not saying that we want to actually standardize all three of
these backends. But we should at least do proof-of-concept ("napkin")
versions of all three to ensure the host-router interface works well
with either of them.
Many thanks to Geoff Mulligan and Thomas Clausen for their help in
identifying this approach, and to Ralph Droms, Jari Arkko, and Dave
Thaler for supplying the missing links.
Geoff Mulligan, who is acting as the chair for this document (because
I'm a co-author), has requested me to announce this and ask the
working group for consensus on this approach. Please reply by
November 18, 24:00 UTC
with your concerns, comments, or just plain support that this is
indeed the way forward.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
