Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-10

From: Zach Shelby <[email-masked]>
Date: Thu, 17 Jun 2010 18:41:24 +0300

We finished up all the open tickets and known issues around ND and posted a new version, bon appetit! Thanks to everyone for the helpful comments and ideas, we're getting there.

http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-10.txt

   Changes from -09 to -10:

      o Clarifications made to Section 8.2 (#66)

      o Explained behavior of Neighbor Cache (#67)

      o Clarified use of SLLAO in RS and NS messages (#68)

      o Added new term 6LN (#69)

      o Small clarification on 6CO flag (#70)

      o Defined host behavior on ARO failure better (#72)

      o Added bootstrapping example for a host (#73)

      o Added new Neighbor Cache Full ARO error (#74)

      o Added rule on the use of the M flag (#75)

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: June 17, 2010 6:15:47 PM GMT+03:00
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for draft-ietf-6lowpan-nd-10 
> 
> 
> A new version of I-D, draft-ietf-6lowpan-nd-10.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-ietf-6lowpan-nd
> Revision:	 10
> Title:		 Neighbor Discovery Optimization for Low-power and Lossy Networks
> Creation_date:	 2010-06-17
> WG ID:		 6lowpan
> Number_of_pages: 46
> 
> Abstract:
> The IETF 6LoWPAN working group defines IPv6 for low-power and lossy
> networks (LLNs) such as IEEE 802.15.4.  This and other similar link
> technologies have limited or no usage of multicast signaling due to
> energy conservation.  In addition, the wireless network may not
> strictly follow traditional concept of IP subnets and IP links.  IPv6
> Neighbor Discovery was not designed for non-transitive wireless
> links.  The traditional IPv6 link concept and heavy use of multicast
> make the protocol inefficient and sometimes impractical in a low
> power and lossy network.  This document describes simple
> optimizations to IPv6 Neighbor Discovery, addressing mechanisms and
> duplicate address detection for 6LoWPAN and similar networks.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 21 Jun 2010 09:44:15 +0100

In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR 
to retry if forwarding a special NS message to the 6LBR does not result 
in a corresponding NA.

I think it would be more efficient if the host were responsible for the 
retry.  The host will need to retry the special NS message anyway, to 
cover the case where the message is lost between the host and the 6LR or 
the forwarded NA is lost in the other direction.

If the 6LR didn't need to retry on behalf of the host, it wouldn't need 
a table of pending nodes. It could implement NS/NA forwarding in a 
stateless manner, much like a REST HTTP implementation.  This would not 
require any other change to the specification because the state 
information (the SLLAO of the host)  is already carried in the messages.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Jun 2010 13:59:16 +0300

On Jun 21, 2010, at 11:44 AM, Daniel Gavelle wrote:

> In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR to retry if forwarding a special NS message to the 6LBR does not result in a corresponding NA.
> 
> I think it would be more efficient if the host were responsible for the retry.  The host will need to retry the special NS message anyway, to cover the case where the message is lost between the host and the 6LR or the forwarded NA is lost in the other direction.
> 
> If the 6LR didn't need to retry on behalf of the host, it wouldn't need a table of pending nodes. It could implement NS/NA forwarding in a stateless manner, much like a REST HTTP implementation.  This would not require any other change to the specification because the state information (the SLLAO of the host)  is already carried in the messages.

WFM. What do others think? 

Zach

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 22 Jun 2010 18:49:01 -0700

> > In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR
to
> retry if forwarding a special NS message to the 6LBR does not result in a
> corresponding NA.
> >
cover
> the case where the message is lost between the host and the 6LR or the
> forwarded NA is lost in the other direction.
> >
a
> table of pending nodes. It could implement NS/NA forwarding in a stateless
> manner, much like a REST HTTP implementation.  This would not require any
[SC>] 

The DAD state in 6LR is needed for reliability even for successful case. If
6LRs did not keep  track of the address being registered at 6LBR(s), then
it'd not know if it received the NA from 6LBR for the requested IPv6
address, making the process unreliable for DAD.
The first time DAD is a synchronous DAD. As described in section 8.2:
"For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
   Cache entry for the address until it receives a successful ARO option
   from the 6LBRs.  Otherwise a duplicate could end up being registered
   in the 6LRs Neighbor Cache which would cause a registration from the
   original host with this 6LR to fail.  The system "remembers" the
   link-layer address of the host by carrying the host's SLLA option in
   the multihop DAD messages, and that is used to later deliver the NA
   with the ARO back to the host."

However, 6LR alternately could just remove the DAD entry and respond to host
with a NA with a failure status instead of retrying to 6LBR. This would
eliminate the responsibility of 6LR to act as proxy for all the hosts for
retrial in case the 6LBR is somehow unreachable or the path to 6LBR is
broken.  Implementations may choose to make the MAX_UNICAST_SOLICIT value
configurable to adjust the number of retransmits.

The downside of hosts being responsible for retrial is that they would have
to keep trying and spending more resource which might be an issue for
resource starved hosts.
If we assume that hosts are equally capable as 6LRs then it would be useful
for host to do the retrial - but even then 6LR would have to do an extra
processing of NS for every retrial from the hosts and spend energy. Thus we
chose 6LR to do the retrial as it has done half the processing already.
However, multihop-dad would require some work for scalability.

One thing I noticed in 8.2.6 is that it says that after the retrials, 6LR
responds to the host with ARO status zero. I'd think 6LR would respond with
ARO status code it received from 6LBR NA.

Thanks,
-Samita

> other change to the specification because the state information (the SLLAO
> of the host)  is already carried in the messages.
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 25 Jun 2010 09:35:04 -0700

On 06/22/10 03:59 AM, Zach Shelby wrote:
>> In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the
>> 6LR to retry if forwarding a special NS message to the 6LBR does
>> not result in a corresponding NA.
>>
>> I think it would be more efficient if the host were responsible for
>> the retry.  The host will need to retry the special NS message
>> anyway, to cover the case where the message is lost between the
>> host and the 6LR or the forwarded NA is lost in the other
>> direction.
>>
>> If the 6LR didn't need to retry on behalf of the host, it wouldn't
>> need a table of pending nodes. It could implement NS/NA forwarding
>> in a stateless manner, much like a REST HTTP implementation.  This
>> would not require any other change to the specification because the
>> state information (the SLLAO of the host)  is already carried in
>> the messages.
>

There is still a need to track pending AFAICT, because the 6LRs need to 
know which multihop DAD replies it should trust, and as a result add the 
SLLA to the neighbor cache.

But I agree that driving things from the host's retransmissions makes 
more sense than what is in 8.2.6.
Also, the last sentence in 8.2.6 to say "OK" after retransmissions fail 
seem quite dangerous if multihop DAD is used to claim and defend short 
addresses. It is better to have the host keep on retrying forever.

    Erik