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

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Mar 2009 10:17:33 +0100

Hi, thanks for this new version of the daft.

> Version -01 of ND for 6lowpan is now available.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-01.txt
> 
> This revision closes a long list of smaller and major tickets. Thanks
>  to all the feedback in Minneapolis and on the list. Here is a 
> summary of changes:
> 
> - Specified the duplicate owner interface identifier procedures. A 
> TID lollypop algorithm was sufficient (nonce unnecessary). - Defined 
> fault tolerance using secondary bindings. - Defined ad-hoc network 
> operation. - Removed the E flag from RA and the X flag from RR/RC. - 
> Completed message examples. - Lots of improvements in text quality 
> and consistency were made.
> 
> The draft is now quite stable, and includes all the functionality we 
> envision for IESG submission. I will submit -02 before the cutoff 
> March 10th, which will be presented in San Francisco. Looking forward
>  to reviews, and especially implementation feedback.

I don't have implementation feedback.

I did submit however some remarks earlier, and some were not reflected
in the new version, may I have feedback back about why not?

Let me bring back the issues, which aren't addressed in this new version.

> o A subnet covers all the LoWPANs and their backbone link with the 
> same IPv6 global or local prefix.

This is throughout the document: I'm not sure I understand 'local'
prefix.  Is it the globally reserved fe80::/10 link-local scope prefix?
  Is it fc00::/7 globally unique yet smaller than global scope?

> If the host moves to a different LoWPAN, with a different default 
> prefix, the bootstrapping process is initiated again.

Throughout the document I don't understand 'default' prefix. Are there
other alternative or preferred prefixes?

> 4.4.3.  Multihop Information Option
> 
> This option identifies the set of prefix information options by a 
> sequence number.  This allows for the full set of prefix information
>  options to be sent only periodically in unsolicited RAs.  If a host
>  detects a difference in the sequence number of this option, then the
>  prefix information has likely changed, and is then requested with an
>  RS.

I'm not sure the term Multihop is appropriate to name this option? There
is no decrementing of HopLimit, it's a single subnet, thus no multihop.

Or this Multihop means that it's multi-link-layer-hop? I'm not sure how
people call when my PC talks to a neighbor PC in the same subnet but
separated by 3 switches - is that Multihop?

> The node might also form Unique Local and Global Unicast addresses,

Is this Unique Local address an RFC4193 "Unique Local IPv6 Unicast
Addresses"? This could be clarified.

> This specification includes a method for requesting a unique 
> stateless address from the Edge Router by setting the 'A' flag in an
>  Address Option during registration.

Is this unique stateless address the same as the prior mentioned Unique
Local address, same as in rfc4193?

> To simplify address resolution it is assumed that LoWPAN nodes are 
> assigned addresses in a homogeneous so that the unicast IPv6 
> addresses IID resolve directly to a corresponding link-layer address.
>  Thus avoiding address resolution when possible.

I'm afraid this way of avoiding NS-NA address resolution means
effectively forbidding manually assigned addresses - is this ok?

> This specification includes a method for requesting a unique 
> stateless address from the Edge Router by setting the 'A' flag in an
>  Address Option during registration.

A new mechanism to assign addresses? Why wouldn't DHCP be sufficient?
Maybe Stateless DHCP RFC3736?

> then the ER aquires an appropriate, unique link-layer address for the
>  network either by generating it and performing DAD, or with some 
> other method.

A link-layer address or a link-local address? I suppose the latter.
Although sometimes the link-layer ids are also negotiated... but not
sure one would DAD the link-layer address.

Alex

Zach Shelby a écrit :
> Hi,
> 
> Version -01 of ND for 6lowpan is now available.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-01.txt
> 
> This revision closes a long list of smaller and major tickets. Thanks
>  to all the feedback in Minneapolis and on the list. Here is a 
> summary of changes:
> 
> - Specified the duplicate owner interface identifier procedures. A 
> TID lollypop algorithm was sufficient (nonce unnecessary). - Defined
>  fault tolerance using secondary bindings. - Defined ad-hoc network 
> operation. - Removed the E flag from RA and the X flag from RR/RC. -
>  Completed message examples. - Lots of improvements in text quality 
> and consistency were made.
> 
> The draft is now quite stable, and includes all the functionality we
>  envision for IESG submission. I will submit -02 before the cutoff 
> March 10th, which will be presented in San Francisco. Looking forward
>  to reviews, and especially implementation feedback.
> 
> Regards, Zach
> 
> -------- Original Message -------- Subject: New Version Notification
>  for draft-ietf-6lowpan-nd-01 Date: Mon, 23 Feb 2009 13:24:20 -0800 
> (PST) From: IETF I-D Submission Tool <[email-masked]> To: 
> [email-masked] CC: 
> [email-masked],[email-masked],[email-masked],[email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> A new version of I-D, draft-ietf-6lowpan-nd-01.txt has been 
> successfuly submitted by Zach Shelby and posted to the IETF 
> repository.
> 
> Filename:     draft-ietf-6lowpan-nd Revision:     01 Title: Neighbor 
> Discovery for 6LoWPAN Creation_date:     2009-02-23 WG ID: 6lowpan 
> Number_of_pages: 46
> 
> Abstract: This document specifies Neighbor Discovery optimized for 
> 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very 
> constrained wireless networks often making use of extended multihop 
> topologies. However, the use of standard IPv6 Neighbor Discovery over
>  6LoWPAN networks has several problems.  Standard Neighbor Discovery
>  was not designed for wireless links, and the standard IPv6 link 
> concept and heavy use of multicast makes it inefficient.  This 
> document spefies a new mechanism allowing efficient Duplicate Address
>  Detection over entire 6LoWPAN networks.  In addition it specifies 
> context dissemination for use with router advertisements, claim and 
> defend addressing, and the support of extended LoWPANs over backbone
>  links.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 09 Mar 2009 12:12:51 +0200

Alex,

Alexandru Petrescu wrote:
>>  to all the feedback in Minneapolis and on the list. Here is a summary 
>> of changes:
>>
>> - Specified the duplicate owner interface identifier procedures. A TID 
>> lollypop algorithm was sufficient (nonce unnecessary). - Defined fault 
>> tolerance using secondary bindings. - Defined ad-hoc network 
>> Completed message examples. - Lots of improvements in text quality and 
>> consistency were made.
>>

Thanks for coming back to this, good timing as I am editing -02 right 
now for submission today.

> Let me bring back the issues, which aren't addressed in this new version.

I took as many of your comments into account in -01 as possible, some 
were not relevant which I will explain below. A few slipped the editing, 
sorry about that!

>  Is it fc00::/7 globally unique yet smaller than global scope?

You are right, it would be better to simply say "IPv6 subnet prefix". In 
fact this could be a global subnet prefix, or a ULA (RFC 4193) which is 
used in ad-hoc LoWPANs (ULA use to be defined in nd-02 Section 9). I 
will fix that in -02. Of course fe80::/10 is never advertised in an RA...

Please note: ND for 6LoWPAN defines a multi-link subnet, thus link-local 
scope is limited to a single hop. However in route-over LoWPANs a LoWPAN 
subnet does consist of multiple hops. We have a special NBMA case here 
that we need to live with. Please see Section 5 about the LoWPAN Subnet, 
and discuss more on that with Pascal and Erik if you like.

> other alternative or preferred prefixes?

Thanks, I tried to remove the use of "default prefix" in -01 but missed 
a couple, this is a valid comment which I will fix in -02.

However, please note that in ND for 6LoWPAN we do have context 
identifiers associated with prefix information and we actually do have a 
default used by 6LoWPAN compression which is CID = 0. Please refer to 
Section 4.4.2. So we could use the term "default prefix" but let's not 
do that for simplicity.

> separated by 3 switches - is that Multihop?

Please see my note above regarding the LoWPAN Subnet, which is 
multi-link. We do have multihop in the subnet, and we are decrementing 
the hoplimit upon IP forwarding. This is known as route-over in a LoWPAN 
subnet.

> Addresses"? This could be clarified.

Thanks, this is one that was missed. It should just say a unicast 
address. This is standard SAA, and is not referring to RFC4193 here.

>> This specification includes a method for requesting a unique stateless 
>> address from the Edge Router by setting the 'A' flag in an

No. This is a unique address generated by the whiteboard for use by the 
requesting node. See the note on short-address assignments below.

>> assigned addresses in a homogeneous so that the unicast IPv6 addresses 
>> IID resolve directly to a corresponding link-layer address.

That is not true with IEEE 802.15.4 and similar MAC technologies. They 
almost universally have some kind of short MAC address support, e.g. 
16-bit MAC addresses in 802.15.4. These short addresses can be 
configured on a node on the fly in addition to its unique 64-bit EUI-64. 
Thus even with this mapping we can and do assign addresses, which is 
what the 'A' flag is used for.

>> This specification includes a method for requesting a unique stateless 
>> address from the Edge Router by setting the 'A' flag in an

We discussed this in the Minneapolis 6lowpan wg meeting. We are not 
assigning addresses as with DHCP. Instead the edge router is simply 
generating a unique short link-layer address on behalf of the node. From 
that point on the node uses that address in a claim and defend manner.

In fact this address could easily be generated by the node itself, and 
then during the router registration DAD is performed as with all 
addresses being registered. So you just keep trying until you find a 
unique one.. However by having the edge router generate it we save a few 
steps for efficiency as the edge router can perform DAD across the whole 
LoWPAN (in extended LoWPANs this may be a very large network).

> sure one would DAD the link-layer address.

It really is a link-layer address, because IEEE 802.15.4 and similar 
technologies support the configuration of assigned short link-layer 
addresses. This short link-layer address must be unique in a LoWPAN, and 
the edge router has the whiteboard and backbone link DAD mechanisms to 
ensure that it is unique on generation.

> Alex

Regards,
Zach

>>  to all the feedback in Minneapolis and on the list. Here is a summary 
>> of changes:
>>
>> - Specified the duplicate owner interface identifier procedures. A TID 
>> lollypop algorithm was sufficient (nonce unnecessary). - Defined
>> successfuly submitted by Zach Shelby and posted to the IETF repository.
>>

-- 
http://zachshelby.org - My blog “On the Internet of Things”
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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 09 Mar 2009 14:01:33 +0100

Sorry Zach, I've wrongly re-reviewed 00 instead of 01.

I'll wait for 02 then review later.

Alex