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 <[email protected]> On Behalf Of Brian E Carpenter
Sent: Saturday, October 9, 2021 4:02 PM
To: Robert Raszuk <[email protected]>; 6MAN <[email protected]>
Cc: SPRING WG <[email protected]>
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
> [email protected] <mailto:[email protected]>
> 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
[email protected]
Administrative Requests:
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
