Subject: [6lowpan] Some comments on draft-ietf-6lowpan-nd-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2009 19:49:53 +0100

Hello WG and authors of draft-ietf-6lowpan-nd-00.txt

I would like to provide some comments on this draft.

However, it is not very clear to me: is this ND going to be used over 
other links than 802.15.4?  For example over IEEE 802.3 or WiFi?

If yes, then I have several comments, some of which below.  Otherwise 
forget it...

> 4.2.  Router Advertisement Message
> 
>    The RA message for 6LoWPAN is based on the [RFC4861] RA message with
>    the addition of a new flag "E".  In addition new options are
>    identified.
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |     Code      |          Checksum             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Cur Hop Limit |M|O|x|x|x|x|E|x|         Router Lifetime       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                         Reachable Time                        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          Retrans Timer                        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Options ...
>      +-+-+-+-+-+-+-+-+-+-+-+

>      x: Bits currently reserved for existing RA flags as per [RFC5175].

Well no, rfc5175 names the allocated flags:
>     0 1 2 3 4 5 6 7
>    +-+-+-+-+-+-+-+-+
>    |M|O|H|Prf|P|R|R|
>    +-+-+-+-+-+-+-+-+

Meaning the rightmost two bits are not currently used (and reading your 
text implies the rightmost bit is currently used).

Why not using that RFC's Flags Expansion Option, instead of requesting 
allocation of the 'E' bit in the current Flags?

> 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?

> In addition [this document] specifies prefix and context 
> dissemination for use with router advertisements

I'm not sure about the dissemination part. Is it a simple advertising on
a link? The typical Router Advertisement? If yes, then advertising a
prefix on a link is nothing new, thus one may probably better say
"document specifies a relationship between HC context and prefix".

Dissemination sounds to me as if the network contained several IP hops
with decrementing HopLimit fields, whereas here there seems to be a
single subnet.

> LoWPAN Subnet
> 
> A subnet including a LoWPAN or Extended LoWPAN, together with the 
> backbone link sharing the same prefix.

The same prefix and same prefix length? Sharing is confusing to me. I
don't think you meant to say the backbone link and the LoWPAN link had
the same prefixes and prefix lengths, respectively.

> If a local or global prefix is included in the RA, the host may form
> an optimistic global unique address with stateless autoconfiguration.
> 
What's local or global prefix?

fe80::/10 is globally unique prefix yet local scope.

An IPv6 address self-formed on Ethernet is globally unique yet local scope.

ULA fc00 ?

I'm not sure what you mean.

> 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?

> 6LoWPAN Prefix Information Option:  This option includes information
> about the default subnet prefix for the LoWPAN along with other
> shared contexts for the subnet.

Same, default prefix.

> 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?

> A subnet is a collection of LoWPAN links interconnected by routers
> that may share one or more local or global prefixes.

Local or global prefix.

> 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 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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 11 Feb 2009 23:00:08 +0200

Alex,

Thanks for the comments. We are quite close to releasing -01 of this 
draft (next week). Many of your concerns are covered there. But you have 
many valid questions below - let's get back to them after -01 is out OK? 
We'll try to take them into account in -01 already where possible.

Regarding 802.3 and WiFi - they are definitely out of scope for 6lowpan, 
as are all links which run standard IPv6. This WG concentrates on 
low-power, low-bandwidth wireless ad-hoc radios such as 802.15.4, 
low-power ISM band etc.

Cheers,
Zach

Alexandru Petrescu wrote:
>> In addition [this document] specifies prefix and context dissemination 
>> for use with router advertisements
> 
>> prefix information has likely changed, and is then requested with an RS.
> 
>> This specification includes a method for requesting a unique stateless 
>> address from the Edge Router by setting the 'A' flag in an
>> assigned addresses in a homogeneous so that the unicast IPv6 addresses 
>> IID resolve directly to a corresponding link-layer address.
>> This specification includes a method for requesting a unique stateless 
>> address from the Edge Router by setting the 'A' flag in an
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

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.