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

[Brian E Carpenter <[e-mail]>]

Just a detail:

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

Technically, I think it needs to be defined separately for each interface.
So defined in the driver source code, most likely. I have no idea whether
real implementations do that.

Apart from that: I agree with Jinmei-san's approach.

Regards
   Brian

On 11-Sep-20 11:18, Fernando Gont wrote:
> 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,
>