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 <brian.e.carpenter@xxxxxxxxx> 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,
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
