On 11-Sep-20 01:24, Fernando Gont wrote: ... >> 2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2) is >> not useful to implementers, because all it says is that it is possible >> to implement a behaviour that for in all practical cases is forbidden by >> RFC 4291. > > Just double-checking: Are you arguing that this: > > " We note that [RFC4291] requires that the Interface IDs of all > unicast addresses (except those that start with the binary > value 000) be 64 bits long. However, the method discussed in > this document could be employed for generating Interface IDs > of any arbitrary length, albeit at the expense of reduced > entropy (when employing Interface IDs smaller than 64 bits) > and increased likelihood of collision. The privacy > implications of the IID length are discussed in [RFC7421]." > > should be removed? It emphatically should not be removed. 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.) So this is very important information for implementers. Brian -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
