On 10-Oct-21 10:04, Robert Raszuk wrote: > > Please kindly correct me if I am wrong, but where do you see that SRv6 is > mandated to use "IPv6 Interface IDs" ?
I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. This isn't just academic standards-oriented formalism. As others have pointed out, it has very significant deployment and operational implications, given that most products support IPv6, not SRV6. Brian > > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith <markzzzsm...@gmail.com > <mailto:markzzzsm...@gmail.com>> wrote: > > 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 > <mailto: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> <mailto:i...@ietf.org > <mailto:i...@ietf.org>> > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > <https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6>> > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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> > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
