Tom,
There is a difference between C-SID and the common mobile practice......
Consider an SRv6 domain where:
- The common prefix is 2001:db8::/48
- Each C-SID is 16 bits long
- Node A instantiates the segment 2001:db8:1::/128
The following are all addresses of Node A:
- 2001:db8:2:1::/128
- 2001:db8:3:1::/128
-2001:db8:2:3:1::/128
- And billions of others...
Yes, they are all drawn from 2001:db8::/48. But Node A is not the sole owner of
2001:db8::/48.
Ron
Juniper Business Use Only
-----Original Message-----
From: Tom Herbert <t...@herbertland.com>
Sent: Monday, October 11, 2021 8:48 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: Brian E Carpenter <brian.e.carpen...@gmail.com>; Robert Raszuk
<rob...@raszuk.net>; 6MAN <6...@ietf.org>; SPRING WG <spring@ietf.org>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
[External Email. Be cautious of content]
On Mon, Oct 11, 2021 at 4:14 PM Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org> wrote:
>
> 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,
I'm not sure I understand this. Isn't it already common practice in mobile
networks to assign each host its own /64 from which the host can use SLAAC to
dynamically create fully qualified and routable 128-bit addresses? If such a
host wants to create one, two, or a billion addresses from that space for its
own purposes then what does the Internet or the protocol care? In fact, the
idea of creating a unique source address for each client TCP connection has
already been floated as there are potential advantages for privacy by
obfuscating addresses to prevent third parties from making correlations to
identify the sender of different flows (e.g.
draft-herbert-ipv6-prefix-address-privacy).
Tom
>
> 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/ip
> > v6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnl
> > vFNF5R1tp_Xys0a$
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
> 6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFN
> F5R1tp_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!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF
> 5R1tp_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!REt-sc-5MVBAhjDSPz9fTwGxMKwFtdLhqQSna9TRwtrsuHyrYl4Mv
> K_MoR27s2Jl$
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
