On Nov 18, 2009, at 21:52 , Jonathan Hui wrote:
>
> The question for me is what to do with the other half - specifically the DAD
> portion.
The right question to ask is - What should be the goal of the other half?
>
> 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.
I agree that uniqueness of addresses within a LoWPAN is necessary, and that can
be assured in many ways. There will be networks where the uniqueness of
addresses must be checked with some mechanism. The base 6lowpan-nd document
shouldn't tell how this uniqueness is determined. But checking for uniqueness
should use very strong wording in that document, with an opt-out if you are
sure addresses have been assigned properly. Note this must be an opt-out rather
than an opt-in.
>
> 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.
It would not make sense to use the nd-07 mechanisms exactly as specified now
after the split. Multiple options is not the problem - as you say above - there
will be a wide variety of ways to insure the uniqueness of addresses. The
problem I see is that just defining the whiteboard on its own only for DAD
doesn't make much sense, so there we can agree.
We should instead call the second document "Extended LoWPAN", and have it
define a mechanism only for enabling Extended LoWPANs. Extended LoWPANs require
a binding cache of some kind at each ER (called a whiteboard or whatever), as
in the original backbone router draft. As a side-effect of registering with the
Extended LoWPAN mechanism, you are also able to determine the uniqueness of an
address. So this would not be specified for use as DAD on its own.
>
> 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.
The 6lowpan-nd document was taken as a WG document already a year ago, and its
main mechanism was (also then) based on registration to a whiteboard. A cache
such as a whiteboard is a means to an end... are people using RFC4861 really
deeply interested in neighbor caches?
The goal of the second document should be the Extended LoWPAN feature and what
it enables. For me this is an important feature, and I have heard many
planning to take advantage of it.
Zach
>
> --
> 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
--
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
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
