Re: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard

[Fernando Gont <[e-mail]>]

Hi, Tatuya,

On 10/9/20 19:33, 神明達哉 wrote:
> At Fri, 11 Sep 2020 09:08:40 +1200,
> Brian E Carpenter <[e-mail]> wrote:
> 
>> [...] It's been a matter of principle
>> since the earliest work on IPv6 address allocation that the /64
>> boundary is treated like a parameter that could be changed, so
>> underlying code should treat it as a parameter and not as a constant.
>> (And RFC7421 discusses a lot more than just the privacy implications.)
> 
> I agree, but I think there's some subtlety here.  By referring to
> RFC4291 and specifically mentioning the magic number of 64 followed by
> the term "any arbitrary length", I see that the above text could read
> as part of attempting to loosen or remove the magic number from the
> address architecture. 

FWIW, at least the *intent* has been to clarified that this document is 
not tied to any specific length. In fact, I copied the relevant text 
verbatim from RFC7217.

And the text in RFC7217 was incoporated circa the same timeframe when 
people wondered where they /64 requirement came from.



[...]
>>From other responses from Fernando, I don't think that's the intent of
> the authors.

Indeed, I had no intention whatsoever to change, loose, confuse, [or 
whaever else] the /64 requirement. -- for instance, this document 
doesn't update RFC4291, and it would seem that such an update wouldn't 
have consensus in the foreseeable future :-)



   In that case, if we don't want to remove the above note
> because of the "lot more" in RFC7421, we might say something like
> this:
> 
>     2.  The Interface Identifier is obtained by taking as many bits from
>         the random number obtained in the previous step as necessary.
>         See Section 2 of [RFC4862] for the necessary number of bits,
>         that is, the length of the IID.  See also [RFC7421] about
>         privacy implications of the IID length.  Note: there are no
>         special bits in an Interface Identifier [RFC7136].

If we use this text, I'd probably move the "there are nos special 
bits.." prior to the other references. But mostly just a suggestion.



> The points of the new text are
> - Use [RFC4862] about the IID length, thus making rfc4941bis agnostic
>    about the "64 vs not 64" pitfall.
> - Referring to RFC4862 also implicitly means the IID length is a
>    parameter at least in theory, so we won't lose the "lot more" than
>    privacy implications.
> - On top of these, make the reference to RFC7421 focused on the
>    privacy implications.
> 
> BTW, RFC4941 limits the length of IID of temporary addresses to 64
> bits while noting the length is not a fixed constant:

FWIW, I think using the hard-coded "64" bits is mostly poor 
specification approach, since the IID length is described elsewhere. 
That kind of stuff should be specified in a single place, where 
appropriate, and an abstract reference should be made to that spec.

(if this was code, you'd do a #define in a single place, and just use 
that constant)

Note: I did both the Linux implementation of rfc4941bis, and a 
FreeBSD-kernel implementation (this later one not sure if it was 
committed). But of them only work with 64 bits.

So there's no "under the hoods" stuff going on...



> 
>     [...] 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.
> (I suspect "an IPv6 identifier" is a typo and should be "an interface
> identifier")
> 
> rfc4941bis now seems to remove this limitation, albeit maybe
> implicitly.  Independently from the discussion on Section 3.3.1, I
> guess this change should probably be noted in Section 5 ("Significant
> Changes from RFC4941").

RFC4291 notes that the IID length is specified in Link-specific RFCs, 
and refrains to specify the IID in the addressing architecture. THat's 
the same we do here. And is the same we do in RFC7217.

So, if you want to implement rfc4941bis on Ethernet, you need to look at 
RFC2464, where you find that the IID is 64-bit long. This document 
(rfc4941bis) does not change or attempt to change that at all.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492