It's stated twice in section 2.5 of RFC4291. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.
All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1 <https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1>. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. Please also see RFC7421, Analysis of the 64-bit Boundary in IPv6 Addressing. On Sun, 10 Oct 2021, 07:27 Robert Raszuk, <rob...@raszuk.net> wrote: > > Hi Brian, >> > >> >> Which means: 64 bits. >> > >> > Sorry but what is so magic about /64 here ? >> >> It is mandated by the current IPv6 addressing architecture. > > > Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 > reference. > > Moreover sections 2.4 and 2.5 are very clear that there is no magic /64 > hard defined. > > The text actually goes even further and says: > > Except for the knowledge of the subnet boundary discussed in the > previous paragraphs, nodes should not make any assumptions about the > structure of an IPv6 address. > > > Thx, > > R. > > > > > >> Despite many discussions, there has never been consensus to change it. So >> if /64 is not the boundary between the routeable part and the host-specific >> part, it's not IPv6. >> >> Brian >> >> > >> > Is this coming from the longest routable IPv6 prefix ? Sort of analogy >> to /24 in the IPv4 world ? Or something else ? >> > >> > I think LPM and CIDR techniques are pretty well established. >> > >> > Any fixed length of the address block with the meaning - do not use >> those bits inter or intra domain for anything useful even if your >> prefix+node can happily fit in /32 seems just dead wrong to me. And that is >> irrespective of any SRv6 discussion. >> > >> > In my books if I get allocated say /48 or /40 from RIR what I do with >> the remaining bits is my own business. >> > >> > Best, >> > R. >> > >> > >> > >> > > Sorry, but it is a little bit late – RFC 8986 is already >> published. >> > >> > "Locators are assigned consistent with IPv6 infrastructure >> allocation." >> > >> > Which means: 64 bits. >> > >> > I have no time to study compressed SIDs, but if they trample on the >> LOC they are not IPv6 addresses. >> > >> > Brian >> > >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > i...@ietf.org <mailto:i...@ietf.org> >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> <https://www.ietf.org/mailman/listinfo/ipv6> >> > -------------------------------------------------------------------- >> > >> >> -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
