The question before the working group that needs to be answered and was
asked in Hiroshima is - Is DAD mandatory?
We said in Hiroshima we would ask the working group and others if DAD is
required?
For the moment we need to answer that.
Then we can deal with how to do address assignment. Will there be only a
single mechanism for lowpans?
6lowpan working group - is DAD a requirement for ALL lowpans?
geoff
On Fri, 2009-11-20 at 16:31 -0800, Jonathan Hui wrote:
> Hi Joseph,
>
> On Nov 20, 2009, at 3:51 PM, Reddy, Joseph wrote:
>
> > The whiteboard scheme is not ideal but it does solve the problem of
> > ensuring unique addresses within a lowpan ( especially when the ipv6
> > addresses are generated from 15.4 16-bit short address )
> > You mentioned some sceanrios where it does not work, can you
> > elaborate more on that ? If whiteboard is not used, then my
> > preference is that we specify some other mechanism to guarantee
> > unique ipv6 addresses generated from short addresses.
>
> The whiteboard doesn't work if you want nodes to communicate even when
> connectivity with the whiteboard is temporarily down. This may occur
> for a variety of reasons - whiteboard service is failing, network
> connectivity is failing, etc. Even if we assume our networks are
> perfect, some applications may not have connectivity with the
> whiteboard at all times.
>
> I think you are confusing address assignment and duplicate address
> detection. Specifically for short addresses, what's described in
> nd-07 today is a mechanism for *assigning* unique IP addresses and 16-
> bit short addresses simultaneously, not ensuring the uniqueness of an
> IP address generated from a 16-bit address by the client. If the goal
> is to develop a lightweight solution to *assigning* addresses, then
> that is how we should view it. The difference is that the service
> should not be required if address assignment is done through a
> different process.
>
> --
> Jonathan Hui
>
>
> > 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
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
