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. Some people would think that's a good move,
while some others would consider it a very bad idea, but one clear
thing is that if we want to include this discussion in this draft it's
very unlikely to reach a consensus and the draft would hang in limbo,
if not die.
>From other responses from Fernando, I don't think that's the intent of
the authors. 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].
(and no "note after this)
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:
[...] 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").
--
JINMEI, Tatuya
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
