Subject: Re: [6lowpan] Way forward for 6LoWPAN-ND, consensus call

From: "Reddy, Joseph" <[email-masked]>
Date: Fri, 20 Nov 2009 17:51:50 -0600

Hi Jonathan,

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.

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-masked]>
Subject: Re: [6lowpan] Way forward for 6LoWPAN-ND, consensus call
To: Zach Shelby <[email-masked]>
Cc: Carsten Bormann <[email-masked]>, 6lowpan <[email-masked]>
Message-ID: <[email-masked]>
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

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 20 Nov 2009 16:31:10 -0800

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
>
>
> 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.
>
> 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?
>
> 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.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 20 Nov 2009 18:06:10 -0700

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Nov 2009 11:38:10 +0100

>connectivity with the whiteboard is temporarily down.  This may occur

Half truth actually hurts. People can be mislead into false conclusions.

The white board is not more on the way of an established communication more than any other router that would be on the path of that communication. If it is not on the way then the communication may continue.

In mesh under it does not preclude the use of something like RFC 3122 for host to host discovery over mesh circuits if that makes sense in that particular mesh. What WB does is guarantee that an address is unique at a given point of time for all those connected at that time. Because there are intermittent failures in nodes and transmission, NA(O) may be repeated over time, and we have a process to determinate duplication vs. movement.

The protocol reestablishes broken pieces upon the loss of a link or a router, nothing weird or unusual there.

When the white board is down, the client can select an alternate if one exists or wait for the repair process to be complete.

- MIPv6 works is a very same way, and sorry you did not just uncover a hole there.

- ISA100 flows are very similar to the white board with the system manager acting as WB. Like we do, ISA100.11a uses the link local for the initial registration with the network via the first hop router, and then the global address that is obtained/validated during that flow called "join". I will certainly not buy your assertion that the White board defeats security considering how deep the security discussions were at ISA, with the participation of people such as René and others. 

When I try to make sense of your assertions I end up figuring that your issue might be that we can actually distribute the WB (vs. one centralized server). If that's so, then please make it clear so we can discuss the specific pro/cons and maybe enrich the draft with an applicability statement.

Cheers,

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hui
>Sent: samedi 21 novembre 2009 01:31
>To: Reddy, Joseph
>Cc: [email-masked]

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 23 Nov 2009 08:09:40 -0800

Hi Pascal,

[starting a new thread]

Here are a couple of my technical concerns:

1) If the node cannot register an address with a whiteboard, can it  
use that address?  If no, then the node cannot really use that address  
until it can communicate with the whiteboard again.  If yes, then  
there is no real uniqueness guarantee (a temporary path failure may  
lead a node to timeout and use a duplicate address).  As I've said  
before, lack of connectivity with the whiteboard may be due to  
failures or may be inherent to the application.

2) I still believe that in most cases, having a separate process to  
register an address with the whiteboard is unnecessary overhead.  I  
never said that the whiteboard compromises security, as you  
suggested.  What I did say is that if you have a network join protocol  
for security reasons, we should use that to assign an address and  
verify that the address is unique.

As I've mentioned before, I see many benefits of the whiteboard with  
mesh-under and do think that the benefits outweigh the overhead  
there.  But many of those benefits are lost with route-over and I'm  
having a hard time seeing what significant value the whiteboard adds  
in a route-over configuration.

--
Jonathan Hui

On Nov 23, 2009, at 2:38 AM, Pascal Thubert (pthubert) wrote:

> The white board is not more on the way of an established  
> communication more than any other router that would be on the path  
> of that communication. If it is not on the way then the  
> communication may continue.
>
> In mesh under it does not preclude the use of something like RFC  
> 3122 for host to host discovery over mesh circuits if that makes  
> sense in that particular mesh. What WB does is guarantee that an  
> address is unique at a given point of time for all those connected  
> at that time. Because there are intermittent failures in nodes and  
> transmission, NA(O) may be repeated over time, and we have a process  
> to determinate duplication vs. movement.
>
> The protocol reestablishes broken pieces upon the loss of a link or  
> a router, nothing weird or unusual there.
>
> When the white board is down, the client can select an alternate if  
> one exists or wait for the repair process to be complete.
>
> - ISA100 flows are very similar to the white board with the system  
> manager acting as WB. Like we do, ISA100.11a uses the link local for  
> the initial registration with the network via the first hop router,  
> and then the global address that is obtained/validated during that  
> flow called "join". I will certainly not buy your assertion that the  
> White board defeats security considering how deep the security  
> discussions were at ISA, with the participation of people such as  
> René and others.
>
> When I try to make sense of your assertions I end up figuring that  
> your issue might be that we can actually distribute the WB (vs. one  
> centralized server). If that's so, then please make it clear so we  
> can discuss the specific pro/cons and maybe enrich the draft with an  
> applicability statement.
>
> Cheers,
>
> Pascal
>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 30 Nov 2009 15:35:56 +0200

> 6lowpan working group - is DAD a requirement for ALL lowpans?

The conclusion I have come to is no. We should provide opt-out language for those special cases where duplicate detection is not needed.

Zach