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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Le 11/09/2020 à 01:18, Fernando Gont a écrit :
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:
[...]

FWIW, I think using the hard-coded "64" bits is mostly poor specification approach, since the IID length is described elsewhere.

I think one does not realize the magnitude of the importance of that 'elsewhere'. All IPv6-over-foo RFCs mandate that to be 64. That is the 'elsewhere'. Worse, all IPv6-over-foo RFCs in the making (aka I-Ds) mandate the same. Additionally, crypto-based addresses also do 64.

Where that limit is relaxed? some methods alluded to in some RFCs, and they are incompatible.

Implementations of forming IIDs of non-64 length? Each programmer does how s/he wishes, because there is no interop problem to solve. BAsically each programmer uses a rand function, but in so many different ways. Some careful will check whether it already exists, others no. There are other criteria to consider too.

Alex

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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux