Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

[james woodyatt <[e-mail]>]

On Jan 16, 2017, at 18:36, Erik Kline <[e-mail]> wrote:
> 
> Actually, I think the NEW text is pretty reasonable if we could
> restore the word "required" for the currently allocated unicast status
> quo:
> 
> From:
> 
>   ... For all currently
>   allocated unicast addresses, except those that start with the binary
>   value 000, that length is 64 bits.
> 
> To:
> 
>   ...  For all currently
>   allocated unicast addresses, except those that start with the binary
>   value 000, that length is required to be 64 bits.
> 
> We can always produce a document that updates 4291bis for 4::/3 or
> whatever we want, and the new text states so explicitly.
> 
> But I'm not convinced we should change to text that could be read to
> weaken the current situation.

I fully agree.

My apologies if I’m coming into the discussion with a point everyone has already dismissed, but it seems to me there is a procedural matter regarding the fact that RFC 4941 doesn’t actually describe how to generate temporary addresses with IID length other than 64 bits.

In the first paragraph of Section 1, RFC 4941 says "Note that an IPv6 identifier does not necessarily have to be 64 bits in length, but the algorithm specified in this document is targeted towards 64-bit interface identifiers.” And nothing else about it appears elsewhere in the text. It doesn’t seem like a host receiving a RA Message containing a PIO option with A=1 is permitted to generate temporary addresses by SLAAC unless the prefix length is 64 bits.

This seems important to me because the text Erik proposes here provides a guarantee to sub-IPv6 link protocol developers that RFC 4941 is an available as a standard for generating temporary addresses using SLAAC for every currently allocated globally-unique prefix. If that requirement disappears in RFC 4291bis, then those of us involved in the development of new sub-IPv6 link layers will not have that guarantee, which may force some of us to develop link-layer alternatives (possibly involving address translation) in order to provide comparable address privacy properties on subnets with globally-unique prefixes longer than 64 bits.

I don’t want to see 6MAN place this possible new requirement on link-layer developers by removing it from IPv6.


--james woodyatt <[e-mail] <mailto:[e-mail]>>