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,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
