I think DAD should only be made optional in very specific cases -
where the EUI-64 is used for address autoconfiguration or if DHCPv6
is used. While it is true that other non-standard mechanisms are
possible, but then they will not be interoperable. And while some
applications do not require multi-vendor interop, there is nothing
preventing an implementation from violating the standard anyway in
such cases
-Regards, Joseph
------------------------------
Message: 2
Date: Thu, 19 Nov 2009 16:01:03 -0800
From: Jonathan Hui <[email protected]>
Subject: Re: [6lowpan] Way forward for 6LoWPAN-ND, consensus call
To: Zach Shelby <[email protected]>
Cc: Carsten Bormann <[email protected]>, 6lowpan <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Nov 19, 2009, at 12:55 PM, Zach Shelby wrote:
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?
The goal will drive what to do.
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.
So we agree that it's optional.
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.
Options is a problem if not dealt with properly. For example, can a
node that does not implement the "whiteboard protocol" (for lack of
a better name) participate in a network that requires the use of
the "whiteboard protocol"? Specifying the "whiteboard protocol" (or
any other mechanism) now would almost make it required to be
implemented by all lowpan routers to ensure interoperability in
networks that depend on it. This is what concerns me and I admit
that I don't have a good solution to the problem.
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.
The call for consensus cited DAD as the primary reason for
separating the whiteboard mechanism. Pascal's individual submission
on whiteboards cited many additional (and good) benefits, but many
of those were dependent on having mesh-under and become lost with
route- over. When operating mesh-under, I see lots of value for the
whiteboard. But, I'm mostly interested in route-over networks, so
can you list what additional features the whiteboard mechanism
provides in addition to DAD?
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?
I tried looking for the call for consensus in the archives, but
could not find it. I also tried to see if there was a consensus
call on what we would put in the draft, but could not find it
either. What I did find were objections to having a whiteboard
mechanism. Correct me if I'm wrong, but if it's true then skipping
these steps was a mistake. Now that we are splitting the document,
we should at least do a call for consensus on creating these new WG
drafts. As far as I can tell, this call for consensus is pretty
close to that.
That said, the real issue for me is not that people are interested
in neighbor caches, the real issue is that there are people who see
little added value in the whiteboard mechanism for many of the
reasons I cited earlier.
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.
It would be good to hear from those who would like to actively work
on this whiteboard feature to speak up. There has been little
feedback on the whiteboard mechanism on the mailing list. As an
author, I can say that nearly all of the discussion on the mailing
list is among 4-5 authors. I feel uncomfortable with a WG document
that is not supported/reviewed/edited by a good number of WG members
outside the authors. So it would be certainly help to get more
input from other WG members about what to do with the whiteboard
mechanism.
--
Jonathan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
