Subject: [6lo] Comments on draft-ietf-6lo-lowpanz-03

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Mar 2014 18:12:25 +0100

Hello to participants to 6lo WG, and authors of draft-ietf-6lo-lowpanz-03.

I have a few comments on some parts of the draft which relate mostly to 
the other existing IPv6-over-foo documents.  Note I have no experience 
with lowpanz G.9959 networks, so I really cant comment on the new 
features introduced by this draft, like HC or address registration.

draft-ietf-6lo-lowpanz-03 says:
> [RFC2460] specifies that IPv6 packets may be up to 1280 octets.

Hmm, I rather think rfc2460 reads that the _minimal_ MTU should be 1280, 
not up to 1280.
RFC2460:
> IPv6 requires that every link in the internet have an MTU of 1280
> octets or greater.
(true, some people me included sometimes say literally 'minimum MTU', 
which may confusely expand into 'minimal maximum transmission unit').

> Alternatively, IPv6 addresses may be assigned centrally via DHCP,
> leading to a "non-link-layer-derived IPv6 address".

In a sense yes, I agree.

However, I understand the link layer address is also provided centrally.
  Hence the invitation seems immediate that the same server which
provides the link layer address also forms an IP address out of it and
provides it via DHCP to the end node.  This is just a thought.

With respect to the DHCP use of this, one realizes that when both SLAAC
and DHCP are used, then there are a couple of messages too many for
constrained links, and two protocol implementations as well, no?

draft says:
> A NodeID is mapped into an IEEE EUI-64 identifier as follows:
>
> IID = 0000:00ff:fe00:YYXX

But later on it says:
> The IPv6 link-local address [RFC4291] for a G.9959 interface is
> formed [...] The "Universal/Local" (U/L) bit MUST be set to zero in
> keeping with the fact that this is not a globally unique value
> [EUI64].

Is it or is it not an IEEE EUI-64 identifier?  Maybe the first occurence
should not really say "EUI-64", no?

(and, one is aware of RFC7136:
>    Specifications of other forms of 64-bit IID MUST specify how all 64
>    bits are set, but a generic semantic meaning for the "u" and "g" bits
>    MUST NOT be defined.  However, the method of generating IIDs for
>    specific link types MAY define some local significance for certain
>    bits.)

Then,

> The IPv6 link-local address [RFC4291] for a G.9959 interface is
> formed by appending the IID defined above to the IPv6 link local
> prefix FE80::/64.

Just a detail, but I would be careful saying 'fe80::/64', and maybe 
consider saying 'fe80::/10'.  The IPv6-over-Ethernet RFC2464 says former 
whereas the IPv6 Addr Arch RFC says the latter.  This is of course a 
matter of small detail, both are clear enough.

draft says:
> 4.4.2.1. Prefix assignment considerations
>
>
>    As stated by [RFC6775], an ABR is responsible for managing
>    prefix(es).  Global routable prefixes may change over time.  It is
>    RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
>    facilitate stable site-local application associations based on IPv6
>    addresses.

Ok, but how to do this assignment?   Administrative (manual) assignment? 
  Maybe advertised in RA?  Maybe delegated with prefix delegation?  I 
see each of the 3 useful.

> 4.4.2.1. Prefix assignment considerations
>
>
>    As stated by [RFC6775], an ABR is responsible for managing
>    prefix(es).  Global routable prefixes may change over time.  It is
>    RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to
>    facilitate stable site-local application associations based on IPv6
>    addresses.  A node MAY support the M flag of the RA message.  If the
>    M flag is not supported, link-layer-derived addressing MUST be used.
>    If the M flag is supported, link-layer-derived addressing MUST be
>    used if the M flag is 0, while DHCPv6 address assignment MUST be used
>    if the M flag is 1.

This paragraph overall seems to read as if link-layer-derived addressing 
is the alternative to non link-layer-derived addressing.  I dont think 
that would be the case.

DHCP could provide addresses to end nodes that contain that 
link-layer-derived address, especially because it may be the same 
machine which provides it the link-layer address itself, no?

Or does this imply that if DHCP is assigning the addresses, then these 
addresses must not be link-layer-derived?

Or maybe I just plain dont understand the words 'link-layer-derived'... 
is it maybe 'link-address derived'?  Or is it 'address formed by the 
link layer and not by the networking layer'?

draft says:
>    [G.9959]   "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range,
>               narrow-band digital radiocommunication transceivers",
>               February 2012.

I think it should be stated that this document is available publicly, I 
just browsed it for free at:
http://www.itu.int/rec/T-REC-G.9959-201202-I/en

Is this the only ITU document worth mentioning?

Is there any ITU G.9959 document containing the word 'IPv6'?

Alex