Folks, It is much more simple than this.
According to RFC 8200, an IPv6 Destination Address is the “128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). See [RFC4291] and Section 4.4.” Therefore, if a packet does not contain a Routing header, its IPv6 Destination Address is the 128-bit address of its *ultimate recipient*. Therefore, a node MUST have billions of IPv6 addresses in order to consume a packet: - that does not have a Routing header - whose IPv6 destination address is a 128-bit carrier C-SID This is because billions of carrier CSIDs can be used to route the packet to that node. The vast majority of those addresses are not configured on the node. I am pretty sure that this is not what RFC 8200 had in mind. Ron Billions of unique 128-bit CSID containers can steer a packet to a particular node. Therefore, that node must have billions of addresses, the vast majority of which are not configured on the node!! Juniper Business Use Only -----Original Message----- From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Brian E Carpenter Sent: Saturday, October 9, 2021 4:02 PM To: Robert Raszuk <rob...@raszuk.net>; 6MAN <6...@ietf.org> Cc: SPRING WG <spring@ietf.org> Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] On 10-Oct-21 00:39, Robert Raszuk 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. 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$ > > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$ -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring