Subject: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

From: Ron Bonica <[email-masked]>
Date: Fri, 1 Oct 2021 20:34:50 +0000

Folks,

Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID types that can occupy the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for details.

The SPRING WG has issued a call for adoption for this draft.

It is not clear that these SID types can be harmonized with the IPv6 addressing architecture.

Does anyone have an opinion?

                                                                                                           Ron

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Oct 2021 17:13:04 +1300

Ron, 

The first sentence cites RFC8402 which unambiguously describes SR as a
limited domain protcol (limited to an "SR domain", that is.)

So within such a domain, this describes using 128 bit quantities called
Segment Identifiers that in some cases, but apparently not in the formats
defined here, has the same structure as an IP address.

Does that harm the Internet, even if it leaks? It might disappoint the
sender, as any sender of a bogus packet is disappointed, but apart from that,
who is damaged?

Regards
   Brian Carpenter

On 02-Oct-21 09:34, Ron Bonica wrote:
> Folks,
> 
>  
> 
> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new 
SID types that can occupy the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for details.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 3 Oct 2021 12:55:47 +0100

> sender, as any sender of a bogus packet is disappointed, but apart from that,

in the smaller sense, limited domain leakage will happen and if the 
destination addresses of packets are routinely changed, then this 
provides the opportunity for potentially serious data leakage.  It would 
be a good idea to note this in the security section of the draft.

It would be a mistake, I think, to dismiss this as a configuration issue 
and then claim that the ietf is not in the business of telling people 
not to make mistakes.  It's more a case of an existing failsafe 
mechanism being removed entirely.  This is a poor idea from both an 
engineering design point of view and in multiple senses from the point 
of view of the principle of least astonishment.

In the bigger scheme of things, it's becoming difficult to reconcile 
whether srv6 is strictly compatible with ipv6.  It's understandable to 
want to declare the existence of a limited domain, throw everything in 
there, apply a different set of rules and claim that it's all ok, but 
there is now a wedge firmly jammed in between rfc8200 and srv6, which is 
being prised open further by drafts like this which introduce more, and 
more substantial semantic incompatibilities.

Rather than concentrating on this draft, it would be a better idea for 
the ietf to ask where does this path lead that we are going down.

There's no issue developing a protocol like SRv6 at the ietf, but if 
drafts of this sort are progressed as-is, it looks likely that that at a 
certain point, the differences between SRv6 and rfc8200 will be large 
enough that it's going to cause pain points for them to share a common 
code point of 6 in the IANA IP version number registry. This would be in 
noone's benefit.

Nick

---

From: Mike Simpson <[email-masked]>
Date: Sun, 3 Oct 2021 14:17:18 +0100

Given that every time a vendor suggests altering the fundamentals of the ipv6 header the reason given for not just using encapsulation and therefore avoiding upsetting the 2 decades worth of running kit is to save the few bytes of overhead it would produce. 

1) Do we not have enough bogus packets on the internets. 
And 
2) just because you can’t define the “harm it will cause” doesn’t mean that it’s not going to cause harm. 

Man generally seems quite fallible imho. 

> On 3 Oct 2021, at 05:13, Brian E Carpenter <[email-masked]> wrote:
> 
> Ron, 
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 3 Oct 2021 16:25:25 +0200

Hi Mike,

> for not just using encapsulation

Please kindly note that SRv6 (and all discussions about SRv6) already
happen in the *encapsulated header* - not in the native header of the
packet.

Nick,

As to the concerns of "escaping packets" - this draft is no more of a
concern then RFC8986.

Ron,

As to the concerns of purity violation of IPv6 addressing - this draft is
also no more of a concern then RFC8986.

Thx,
R.

On Sun, Oct 3, 2021 at 3:17 PM Mike Simpson <[email-masked]> wrote:

> Given that every time a vendor suggests altering the fundamentals of the
> ipv6 header the reason given for not just using encapsulation and therefore
> avoiding upsetting the 2 decades worth of running kit is to save the few
> bytes of overhead it would produce.
>
> > SID types that can occupy the Destination Address field of an IPv6
> header. See Sections 4.1, 4.2, and 4.3 of the draft for details.
> >>
> >>
> >>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 4 Oct 2021 15:32:19 +0200

Taking this new "philosophy of limited domain" to its bitter conclusion

A is Internet Standard
B is also Internet Standard for "Limited Domain" that violates A
C is also Internet Standard for "Limited Domain" that violates A
D is also Internet Standard for "Limited Domain" that violetes C

so by transitive chain D violates C and hence A but not B. Hence D and B
can be deployed together (maybe) but not any other combination.

So what purposes will IETF serve. To define 4 different "standards" that
have "limited domain violation dependencies" amongst each other but based
on algebra closure can sometimes be deployed together. And we will track
this and call that "standards" ? Really ?

--- tony

On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter <
[email-masked]> wrote:

> SID types that can occupy the Destination Address field of an IPv6 header.
> See Sections 4.1, 4.2, and 4.3 of the draft for details.
> >
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Oct 2021 09:04:54 +1300

Tony,
On 05-Oct-21 02:32, Tony Przygienda wrote:
> so by transitive chain D violates C and hence A but not B. Hence D and B can be deployed together (maybe) but not any other combination.
> 
> So what purposes will IETF serve. To define 4 different "standards" that have "limited domain violation dependencies" amongst each other but based on algebra closure can sometimes be deployed together. And we will track this and call that "standards" ? Really ?

There's an attempted analysis of this issue at https://www.rfc-editor.org/rfc/rfc8799.html#name-the-scope-of-protocols-in-l (which is not, of course, an IETF document).

   Brian

> 
> --- tony
> 
> 
> 
> 
> 
> On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Ron,
> 
>     > [email-masked] <mailto:[email-masked]>
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 4 Oct 2021 21:00:06 +0000

Brian,

Is there any limit to the degree that one Internet Standard can violate another, so long as that violation is constrained to a limited domain?

For example, if I wanted to reduce the size of IPv6 header by shrinking the source and destination addresses to 64 bits each, would that be OK?

                                                                                                                         Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Monday, October 4, 2021 4:05 PM
To: Tony Przygienda <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
Subject: Re: draft-filsfilscheng-spring-srv6-srh-compression-02

[External Email. Be cautious of content]

Tony,
On 05-Oct-21 02:32, Tony Przygienda wrote:
> B is also Internet Standard for "Limited Domain" that violates A C is 
> also Internet Standard for "Limited Domain" that violates A D is also 
> Internet Standard for "Limited Domain" that violetes C
>

There's an attempted analysis of this issue at https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8799.html*name-the-scope-of-protocols-in-l__;Iw!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG7y06gGZe$  (which is not, of course, an IETF document).

   Brian

>     > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$  <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$ >
>     Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3f
> aGG74XUosUG$
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TAuiXvPA041b_8J7ztkKBNVb42V64lWv9vZDhDKSqabZiuhIiSE3faGG74XUosUG$ >

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Oct 2021 23:15:36 +0200

Hi Ron,

Your below example has nothing to do with Internet Standard violation.

You are free to define new ethertype and new IP header format any time you
wish to do so.

Obviously it can not be called IPv6 any more as it is not compatible with
IPv6 IP header format.

Main reason why SRv6 has chosen to use IPv6 is to make
architecture practically deployable and to make sure SR packets can be
forwarded by legacy nodes not SRv6 aware.

Best,
Robert.

On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Brian,
>
> Is there any limit to the degree that one Internet Standard can violate
> another, so long as that violation is constrained to a limited domain?
>
> For example, if I wanted to reduce the size of IPv6 header by shrinking
> the source and destination addresses to 64 bits each, would that be OK?
>
>
>                                                Ron
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Oct 2021 14:44:02 +1300

On 05-Oct-21 10:15, Robert Raszuk wrote:
> You are free to define new ethertype and new IP header format any time you wish to do so. 
> 
> Obviously it can not be called IPv6 any more as it is not compatible with IPv6 IP header format. 
> 
> Main reason why SRv6 has chosen to use IPv6 is to make architecture practically deployable and to make sure SR packets can be forwarded by legacy nodes not SRv6 aware. 

Isn't that the point of Ron's question? If the format of the DA field of a packet doesn't conform to the IPv6 address architecture, how can you call it an IPv6 packet, or expect the "legacy" node to do anything sensible?

I have no intention of studying this work in detail, but if some present or future SID format happens to start with the bytes 0xfe80, a "legacy" node will certainly not forward a packet in which that SID occupies the DA 
space.

I use the word "legacy node" because you do, but actually you mean "normal IPv6 node". SRV6 is the new kid on the block.

More below...

> 
> Best,
> Robert.
> 
> 
> On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica <rbonica=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Brian,
> 

There is serious work on shortened addresses, I believe, but that work includes specifying what happens at the domain boundary. Apart from that, I've already cited my generic analysis of the question.
https://www.rfc-editor.org/rfc/rfc8799.html#name-the-scope-of-protocols-in-l

I wouldn't have co-authored that document if the IETF wasn't already standardizing quite a number of such protocols. As far as I know, there is no 
IETF or IAB document that takes a position on whether this is good, bad, or neutral.

   Brian

                 Ron

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Oct 2021 09:09:50 +0200

Hi Brian,

Thank you - yes by legacy I meant not upgraded one - no different meaning
intended.

As far as conforming to addressing architecture sorry to say but to me this
is red herring. Sure address must be a legal address - no question. But
what bits in the address mean is really up to the person allocating them.

I can have perfectly valid set of IPv4 addresses which each assigned to
different loopback of my node. Then each loopback is configured with
completely different behaviour to the packets arriving to it.

What matters for routing is the prefix - what matters for actually
processing are the remaining bits. Same for IPv6.

Kind regards,
Robert

On Tue, Oct 5, 2021 at 3:44 AM Brian E Carpenter <
[email-masked]> wrote:

> Isn't that the point of Ron's question? If the format of the DA field of a
> packet doesn't conform to the IPv6 address architecture, how can you call
> it an IPv6 packet, or expect the "legacy" node to do anything sensible?
>
> I have no intention of studying this work in detail, but if some present
> or future SID format happens to start with the bytes 0xfe80, a "legacy"
> node will certainly not forward a packet in which that SID occupies the DA
> space.
>
> I use the word "legacy node" because you do, but actually you mean "normal
> IPv6 node". SRV6 is the new kid on the block.
>
> More below...
>
> >
> > Best,
> > Robert.
> >
> >
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Brian,
> >
> >     Is there any limit to the degree that one Internet Standard can
> violate another, so long as that violation is constrained to a limited
> domain?
> >
> >     For example, if I wanted to reduce the size of IPv6 header by
> shrinking the source and destination addresses to 64 bits each, would that
> be OK?
>
> There is serious work on shortened addresses, I believe, but that work
> includes specifying what happens at the domain boundary. Apart from that,
> I've already cited my generic analysis of the question.
>
> I wouldn't have co-authored that document if the IETF wasn't already
> standardizing quite a number of such protocols. As far as I know, there is
> no

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 5 Oct 2021 10:37:43 +0200

On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk <[email-masked]> wrote:

> As far as conforming to addressing architecture sorry to say but to me
> this is red herring. Sure address must be a legal address - no question.
> But what bits in the address mean is really up to the person allocating
> them.
>

unfortunately not. otherwise the postal service would have never worked in
the first place. The semantic concepts (and their semiotics) of
names/addresses & routes predate the internet by a couple of millenia and
did not shift much and we won't most likely shift them (and as side quip
the illusion of "flat" addresses as in MAC has proven unscalable yet again
;-). I recommend in the context of networking the seminal 70s paper by
Schoh from Xerox.

 on top you're logically contradicting yourself in the same sentence, if
anybody can assign any semantics to an address in the same space because
"they allocate it" then no'one can judge what is legal and what isn't

And all this here is not the case of intelligence showing by holding two
contradicting ideas in one's head, this here is simply enshrining two or
more contradicting "standards" in one standards body @ which point in time
the term "standards" quickly starts to lose its meaning in first place.

well, I said my piece, up to IAB and so on to worry about what's happening
here really ...

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Oct 2021 12:09:59 +0200

Tony,

I am afraid you missed my point :(

Any IP address can be split into routable part and non routable part (or
perhaps to be more correct globally routable part and locally routable
part).

So I am not contradicting myself at all stating that if I got /24 or /64
from RIR and I advertise those to attract traffic and I can do whatever I
want with the remaining 8 or 64 bits.

Remember ISDN or better E.164 numbers ? My number is is my base number and
extension - DDI or DID. If I assign DDI to fax or voice mail or phone in
the kitchen has no bearing on the telephone network, rest of the number to
reach me.

Besides all that we are taking here about encapsulated packets anyway - so
even how I make sure the prefix or locator are advertised and installed in
the FIBs should be not a concern to any of my neighbors. If my encapsulated
packets leak (or as some say escape) and I use legal prefix assigned by RIR
as part of the DST address there are bunch of tools deployed today which
should drop it right there on the other edge.

Best,
R.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 5 Oct 2021 16:58:40 +0000

Folks,

In a private communication, someone asked for specific references to RFCs 8200 and 4291 that were difficult to harmonize with draft-filsfilscheng-spring-srv6-srh-compression. References follow:

Section 3 of RFC 8200
-----------------------------
"The Destination Address field of the IPv6 header contains 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."

Section 2 of RFC 4291
-----------------------------
"IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces (where "interface" is as defined in Section 2 of [RFC8200])".

Section 2 of RFC 8200
------------------------------

  *   An interface is "a node's attachment to a link"
  *   A link is "a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6."

So, an IPv6 Destination Address represents a single thing that is instantiated on a single node.

According to draft-filsfilscheng-spring-srv6-srh-compression-02, A Compressed-SID container (C-SID container) is "an entry of the SRH Segment-List field (128 bits) that contains a sequence of C-SIDs." A C-SID is "a  C-SID is a short encoding of a SID in SRv6 packet that does not include the SID block bits (locator block)."

According to RFC  8896, a SID identifies an instruction on a node.

And finally, according to draft-filsfilscheng-spring-srv6-srh-compression-02, an SRv6 node can copy a container C-SID to the  Destination Address fieldd of theIPv6 header.

When this happens, the IPv6 Destination Address doesn't represent a single thing on a single node. It represents an entire SR path.

                                                                                                Ron

Juniper Business Use Only
From: Ron Bonica
Sent: Friday, October 1, 2021 4:35 PM
To: [email-masked]
Cc: SPRING WG <[email-masked]>
Subject: draft-filsfilscheng-spring-srv6-srh-compression-02

Folks,

                                                                                                           Ron

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Oct 2021 10:40:24 +1300

On 05-Oct-21 23:09, Robert Raszuk wrote:
> Any IP address can be split into routable part and non routable part (or perhaps to be more correct globally routable part and locally routable part). 
> 
> So I am not contradicting myself at all stating that if I got /24 or /64 from RIR and I advertise those to attract traffic and I can do whatever I want with the remaining 8 or 64 bits.

Well, they are address bits, not semantic content, in the IP connectionless datagram model invented in the late 1970s and slightly updated in the 1990s. What you are describing is radically different. But nothing you wrote previously made it clear that you were talking about only part of the 
128 bits.

> 
> Remember ISDN or better E.164 numbers ? My number is is my base number and extension - DDI or DID. If I assign DDI to fax or voice mail or phone 
in the kitchen has no bearing on the telephone network, rest of the number to reach me. 
> 
> Besides all that we are taking here about encapsulated packets anyway - 
so even how I make sure the prefix or locator are advertised and installed in the FIBs should be not a concern to any of my neighbors. If my encapsulated packets leak (or as some say escape) and I use legal prefix assigned by RIR as part of the DST address there are bunch of tools deployed today which should drop it right there on the other edge. 

Indeed. I don't actually care what an SRV6 site does in private; but it's 
like forgetting to switch your camera off during a Zoom session, or messing up your BGP update: accidents will happen, and that's what the IETF should worry about.

   Brian

> 
> Best,
> R.
> 
> 
> On Tue, Oct 5, 2021 at 10:38 AM Tony Przygienda <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Brian,
> 
>         Thank you - yes by legacy I meant not upgraded one - no different meaning intended. 
> 
>         As far as conforming to addressing architecture sorry to say but to me this is red herring. Sure address must be a legal address - no question. But what bits in the address mean is really up to the person allocating them. 
> 
> 
>     unfortunately not. otherwise the postal service would have never worked in the first place. The semantic concepts (and their semiotics) of names/addresses & routes predate the internet by a couple of millenia and did not shift much and we won't most likely shift them (and as side quip the illusion of "flat" addresses as in MAC has proven unscalable yet again ;-). I recommend in the context of networking the seminal 70s paper by Schoh from Xerox.
> 
>      on top you're logically contradicting yourself in the same sentence, if anybody can assign any semantics to an address in the same space because "they allocate it" then no'one can judge what is legal and what isn't
> 
>     And all this here is not the case of intelligence showing by holding two contradicting ideas in one's head, this here is simply enshrining two or more contradicting "standards" in one standards body @ which point in time the term "standards" quickly starts to lose its meaning in first place.
> 
>     well, I said my piece, up to IAB and so on to worry about what's happening here really ...
> 
>     -- tony
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 6 Oct 2021 03:27:33 +0000

Hi 6man, A CSID is an SRv6 SID.  It utilizes the SRv6 SID format defined in RFC8986 (not RFC8896) section 3 “This document defines an SRv6 SID as consisting of LOC[ator]:FUNCT[ion]:ARG[ument]”.

Darren

On 2021-10-05, 12:59 PM, "spring" <[email-masked]> wrote:

Folks,

Section 3 of RFC 8200
-----------------------------
“The Destination Address field of the IPv6 header contains 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.”

Section 2 of RFC 4291
-----------------------------
“IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces (where "interface" is as defined in Section 2 of [RFC8200])”.

Section 2 of RFC 8200

-         An interface is “a node's attachment to a link”

-         A link is “a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6.”

According to draft-filsfilscheng-spring-srv6-srh-compression-02, A Compressed-SID container (C-SID container) is “an entry of the SRH Segment-List field (128 bits) that contains a sequence of C-SIDs.” A C-SID is “a  C-SID is a short encoding of a SID in SRv6 packet that does not include the SID block bits (locator block).”

When this happens, the IPv6 Destination Address doesn’t represent a single thing on a single node. It represents an entire SR path.

                                                                                                Ron

Folks,

                                                                                                           Ron

---

From: Eduard Metz <[email-masked]>
Date: Thu, 7 Oct 2021 11:03:25 +0200

Can the SID be viewed as the address of the "interface" to, in this case,
the function that resides in a node? From a routing / forwarding point of
view the group of functions is more similar to a network (represented by a
prefix, rather than a single address), but still.

For my understanding, apart from that the (definition of) SID may not be
aligned with the literal text in below RFCs, what is the real problem? Are
there any protocols that specifically rely on this definition of an IPv6
address?

cheers,
  Eduard

On Tue, Oct 5, 2021 at 6:59 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Folks,
>
>
>
> In a private communication, someone asked for specific references to RFCs
> 8200 and 4291 that were difficult to harmonize with
> draft-filsfilscheng-spring-srv6-srh-compression. References follow:
>
>
>
> Section 3 of RFC 8200
> “The Destination Address field of the IPv6 header contains 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.”
>
>
>
> Section 2 of RFC 4291
>
> “IPv6 addresses are 128-bit identifiers for interfaces and sets of
> interfaces (where "interface" is as defined in Section 2 of [RFC8200])”.
>
>
>
> Section 2 of RFC 8200
>
>    - A link is “a communication facility or medium over which nodes can
>    communicate at the link layer, i.e., the layer immediately below IPv6.”
>
>
>
> According to draft-filsfilscheng-spring-srv6-srh-compression-02, A
> Compressed-SID container (C-SID container) is “an entry of the SRH
> Segment-List field (128 bits) that contains a sequence of C-SIDs.” A C-SID
> is “a  C-SID is a short encoding of a SID in SRv6 packet that does not
> include the SID block bits (locator block).”
>
>
>
> And finally, according to
> draft-filsfilscheng-spring-srv6-srh-compression-02, an SRv6 node can copy a
> container C-SID to the  Destination Address fieldd of theIPv6 header.
>
>
>
> When this happens, the IPv6 Destination Address doesn’t represent a single
> thing on a single node. It represents an entire SR path.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> *From:* Ron Bonica
> *Sent:* Friday, October 1, 2021 4:35 PM
> *To:* [email-masked]
> *Cc:* SPRING WG <[email-masked]>
> *Subject:* draft-filsfilscheng-spring-srv6-srh-compression-02
>
>
>
> Folks,
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 Oct 2021 11:14:06 +0100

Eduard Metz wrote on 07/10/2021 10:03:
> aligned with the literal text in below RFCs, what is the real problem?

the concept of an ipv6 destination address is deeply ingrained in the 
ipv6 protocol.  So, looking at this from a deployment point of view, why 
does an expediency of the sort suggested in this draft justify changing 
the semantics of one of the cornerstones of the ipv6 protocol?

The authors would need to justify this protocol modification on the same 
sort of basis that any other ID might be expected to do.  E.g. for 
starters, including an analysis of how this would impact or potentially 
impact any other RFC which references or implicitly depends on 
currently-defined ipv6 addressing semantics.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Oct 2021 12:32:00 +0200

Nick,

Ok let's zoom on your point.

*IPv6  Addressing Architecture RFC says: *

IPv6 addresses are 128-bit identifiers for interfaces and sets of
   interfaces (where "interface" is as defined in Section 2 of [IPV6]).
   There are three types of addresses:

    Unicast:   An identifier for a single interface.  A packet sent to a
               unicast address is delivered to the interface identified
               by that address.

So what is left to check is what the definition of the "interface" is.

Some folks refer to the definition of the interface as stated verbatim in
*RFC2460/RFC8200: *

2.  Terminology

   interface   - a node's attachment to a link.

*However we all know that outside of IPv6, SRv6 there are many more types
of interfaces which are not attached to any link. We use them every day. *

*RFC7223* did decent job trying to capture what the interface means and
divided the interfaces into system defined and user defined:

1.1.  Terminology

   The following terms are used within this document:

   o  system-controlled interface: An interface is said to be system-
      controlled if the system creates and deletes the interface
      independently of what has been explicitly configured.  Examples
      are interfaces representing physical hardware that appear and
      disappear when hardware (e.g., a line card or hot-pluggable
      wireless interface) is added or removed.  System-controlled
      interfaces may also appear if a certain functionality is enabled
      (e.g., a loopback interface might appear if the IP protocol stack
      is enabled).

   o  user-controlled interface: An interface is said to be user-
      controlled if the creation of the interface is controlled by
      adding explicit interface configuration to the running
      configuration datastore and the removal of the interface is
      controlled by removing explicit interface configuration from the
      running configuration datastore.  Examples are VLAN interfaces
      configured on a system-controlled Ethernet interface.

So please let's consider reality here, not some badly defined dogmas from
the stone age.

And if we will, then the SRv6 destination address is the address of a
special virtual interface in the system. The meaning of the bits outside of
the routable prefix is up to the interface creator.

If that single sentence is missing in any spec it can be added but to me
this is obvious.

Cheers,
R.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 7 Oct 2021 10:47:42 +0000

Data plane “Programmability” in principle should be discarded
If the address is only “a node's attachment to a link”.
I do not want to mention “locator” and “argument” because any programmability is blocked by such address definition.
I hope we do not want to move everything to the control plane again.
It was a nice idea to shift states from the control plane and forwarding tables to the packet itself.
The call to follow “a node's attachment to a link” rule is somehow equivalent to “close SPRING wg”.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, October 7, 2021 1:32 PM
To: Nick Hilliard <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Nick,

IPv6  Addressing Architecture RFC says:

Some folks refer to the definition of the interface as stated verbatim in RFC2460/RFC8200:

2.  Terminology

However we all know that outside of IPv6, SRv6 there are many more types of interfaces which are not attached to any link. We use them every day.

RFC7223 did decent job trying to capture what the interface means and divided the interfaces into system defined and user defined:

1.1.  Terminology

So please let's consider reality here, not some badly defined dogmas from the stone age.

And if we will, then the SRv6 destination address is the address of a special virtual interface in the system. The meaning of the bits outside of the routable prefix is up to the interface creator.

If that single sentence is missing in any spec it can be added but to me this is obvious.

Cheers,
R.

On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard <[email-masked]<mailto:[email-masked]>> wrote:

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Eduard Metz <[email-masked]>
Date: Thu, 7 Oct 2021 12:50:50 +0200

I honestly would like to understand if this discussion about fixing the
wording (e.g. use a more abstract notion of interface / link), or if there
are cases where things (may) break. I was hoping someone could point to
examples?

As pointed out by Robert not all types of interfaces used today fit the
definitions, even loopback doesn't match nicely

/Eduard

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Oct 2021 13:00:11 +0200

Indeed !!! Spot on.

I would further extend your suggestion ... VLAN interfaces should be
obsoleted, any form of tunneling should be considered an IPv6 spec
violation, dial in interfaces should be considered evil, IPv4 in IPv6  etc
... and this is not only in routers but also in compute nodes.

Only then we will have IPv6 address all in its purity attached to a
physical links.

Oh maybe someone say this is also to covers virtual links - ah then great
as SR segment can be treated as a virtual link and if so are we all square
now ?

Best,
R.

On Thu, Oct 7, 2021 at 12:48 PM Vasilenko Eduard <
[email-masked]> wrote:

> I do not want to mention “locator” and “argument” because any
> programmability is blocked by such address definition.
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, October 7, 2021 1:32 PM
> *To:* Nick Hilliard <[email-masked]>
> *Cc:* Ron Bonica <rbonica=[email-masked]>; SPRING WG <
> [email-masked]>; [email-masked]
> *Subject:* Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02
>
>
>
> Nick,
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Oct 2021 23:29:29 +1100

> However we all know that outside of IPv6, SRv6 there are many more types of interfaces which are not attached to any link. We use them every day.

Those other definitions don't matter, because they're not the IPv6
definitions of an interface, and IPv6 is what we're talking about
here. That is the protocol you're saying you want to use.

A SID by itself can have any definition you like - 20 bits, 128 bits,
1024 bits if you want. However, once you want to put a SID value into
an IPv6 DA field, then the SID value is now required to comply with
IPv6's definition of the DA field, and therefore the IPv6 addressing
architecture in RFC4291. Same with the IPv6 definition of an
interface.

The IPv6 IID field isn't a free-for-all. There are reserved IID values
that have semantics -
https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml.
You need to make sure your SID values that you're going to put into an
IPv6 DA field don't collide with these IID values when they are put in
the IPv6 DA field.

That's what complying with a protocol specification means, and that is
what you need to do if you're *using* a protocol.

Protocol specifications naturally inhibit innovation, because they
have to. That is the cost of having interoperability with existing
implementations.

If SPRING want to innovate without constraint, then don't try to use
an existing, widely deployed, 26 year old protocol. Invent a new local
domain protocol that best suits your requirements.

Otherwise, compromise on your solutions and mechanisms such that they
still achieve what you want to achieve, while also complying with the
IPv6 protocol specifications.

<snip>

Regards,
Mark.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Oct 2021 15:19:38 +0200

Hi Mark,

Ok the argument of IID space comes first time - I do apologies if I missed
it and it was mentioned before.

So the consequence of reserved IID space for application A in case of
collision with any other application B may yield unexpected results. And
that apparently is completely agnostic to the actual prefix of the address.

But reading say RFC6543 such IIDs can be present only in link local
addresses not real IPv6 "global" prefixes. So again we are safe.

If there any case that IPv6 stacks are expected to perform any action based
on the IIDs of the packets irrespective of the prefix/locator portion of
the DST address in the packet header ?

Thx,
R.

On Thu, Oct 7, 2021 at 2:29 PM Mark Smith <[email-masked]> wrote:

> > However we all know that outside of IPv6, SRv6 there are many more types
> of interfaces which are not attached to any link. We use them every day.
> >
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Oct 2021 19:35:44 +0000

Inline [RB]

           Ron

Juniper Business Use Only
From: Eduard Metz <[email-masked]>
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Can the SID be viewed as the address of the "interface" to, in this case, the function that resides in a node? From a routing / forwarding point of view the group of functions is more similar to a network (represented by a prefix, rather than a single address), but still.

[RB] In RFC 8986, a classic SRv6 SID represents a *single* function that resides on a *single* node. If you like, you can even say that represents a *single* interface to a *single* function that resides on a *single* node.

By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes

For my understanding, apart from that the (definition of) SID may not be aligned with the literal text in below RFCs, what is the real problem? Are there any protocols that specifically rely on this definition of an IPv6 address?

[RB] We don't know if there are any protocols that rely on this definition of the IPv6 address. And if we don't update RFC 4291 before violating it, we don't know if anybody might write such an application in the future.

                                                                                                   Ron

cheers,
  Eduard

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Oct 2021 10:01:58 +1300

I'm less interested in the definition of an "interface" than I am in the bits in an Interface Identifier (i.e. the bottom 64 bits of an address).

There is a formal update of the addressing architecture on this very point.
https://www.rfc-editor.org/rfc/rfc7136.html#section-5 says:

   ...the method of generating IIDs for
   specific link types MAY define some local significance for certain
   bits.

   In all cases, the bits in an IID have no generic semantics; in other
   words, they have opaque values.  In fact, the whole IID value MUST be
   viewed as an opaque bit string by third parties, except possibly in
   the local context.

Note the references to "local". If all hosts on a link agree about
some magic semantics in the IID, and even agree to call the whole
address a SID, it's consistent with the addressing architecture
*as long as it stays local*. And don't mess with the semantics of
the top 64 bits.

Regards
   Brian Carpenter

On 07-Oct-21 23:32, Robert Raszuk wrote:
> Some folks refer to the definition of the interface as stated verbatim in *RFC2460/RFC8200: *
> 
> 2.  Terminology
> 
> _However we all know that outside of IPv6, SRv6 there are many more types of interfaces which are not attached to any link. We use them every day. _
> 
divided the interfaces into system defined and user defined: 
> On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Eduard Metz <[email-masked]>
Date: Fri, 8 Oct 2021 10:00:36 +0200

If it helps in clarifying updating the definitions may be in order. Anyway
it seems more logical that an (IP) interface is defined by its address than
the other way around. But I do not know the original intention of the text.

I'm not sure I understand your point regarding many functions on many
nodes. Isn't that the case only in combination with the SRv6 functions that
are applied the 128-bit entity? And even then it only points to one
function on one node at a time?

cheers,
  Eduard

On Thu, Oct 7, 2021 at 9:35 PM Ron Bonica <[email-masked]> wrote:

> *From:* Eduard Metz <[email-masked]>
> *Sent:* Thursday, October 7, 2021 5:03 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* [email-masked]; SPRING WG <[email-masked]>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> [RB] In RFC 8986, a classic SRv6 SID represents a **single** function
> that resides on a **single** node. If you like, you can even say that
> represents a **single** interface to a **single** function that resides
> on a **single** node.
>
>
>
> By contrast, a Compressed SID Container (i.e., the 128-bit entity that is
> copied into the IPv6 Destination Address field) represents an entire SR
> Path. Specifically, it represents **many** functions that reside on *
> *many** nodes
>
>
>
>
>
> [RB] We don’t know if there are any protocols that rely on this definition
> of the IPv6 address. And if we don’t update RFC 4291 before violating it,
> we don’t know if anybody might write such an application in the future.
>
>
>
>
> Ron
>
>
>
>
>
> cheers,
>
>   Eduard
>
>
>
>
>
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 8 Oct 2021 08:37:41 +0000

? By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes

But CSID is not an IP address, right? Why IP address rules should be applicable to CSID?

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, October 7, 2021 10:36 PM
To: Eduard Metz <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]
Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Inline [RB]

           Ron

Juniper Business Use Only
From: Eduard Metz <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

                                                                                                   Ron

cheers,
  Eduard

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Oct 2021 07:46:39 -0700

On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard <[email-masked]>
wrote:
>
> Ø By contrast, a Compressed SID Container (i.e., the 128-bit entity that
is copied into the IPv6 Destination Address field) represents an entire SR
Path. Specifically, it represents *many* functions that reside on *many*
nodes
> But CSID is not an IP address, right? Why IP address rules should be
applicable to CSID?
Eduard,

If the protocol is copying the CSI into the IPv6 Destination address the
CSI MUST be an IP address because the Destination Address field in an IPv6
packet *contains* an IPv6 address. Overloading fields in the IPv6 header
with other data would be non-conformant with the IPv6 standard (not just
addresses, see the several attempts to structure flow label for instance).

Frankly, this is one thing that I have found troubling with SrRv6.
Sometimes it is portrayed as an alternative, shadow protocol to IPv6 that
just happens to use the IPv6 protocol format for convenience instead of
creating a new L3 protocol for its purposes. The rationalization for this
seems to be that SRv6 is confined to limited domains, and within a limited
domain we can safely redefine standard protocols in arbitrary ways-- note,
there is no consensus that that philosophy is acceptable.

Tom

>
>
>
> [RB] In RFC 8986, a classic SRv6 SID represents a *single* function that
resides on a *single* node. If you like, you can even say that represents a
*single* interface to a *single* function that resides on a *single* node.
copied into the IPv6 Destination Address field) represents an entire SR
Path. Specifically, it represents *many* functions that reside on *many*
nodes
>
>
>
> [RB] We don’t know if there are any protocols that rely on this
definition of the IPv6 address. And if we don’t update RFC 4291 before
violating it, we don’t know if anybody might write such an application in
the future.
                          Ron

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 8 Oct 2021 17:03:49 +0000

Hi Tom,
It is not related to CSID. Because it is not important how IP address is prepared, it should be IP address at the time of writing to DA field. And it is.

You are asking more general question: what was the legal reason to treat IPv6 address as LOC:FUNCT:ARG?
Sorry, but it is a little bit late – RFC 8986 is already published.
Eduard
From: Tom Herbert [mailto:[email-masked]]
Sent: Friday, October 8, 2021 5:47 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; Eduard Metz <[email-masked]>; SPRING WG <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
>
> Ø By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes
>
>
>
Eduard,

If the protocol is copying the CSI into the IPv6 Destination address the CSI MUST be an IP address because the Destination Address field in an IPv6 packet *contains* an IPv6 address. Overloading fields in the IPv6 header with other data would be non-conformant with the IPv6 standard (not just addresses, see the several attempts to structure flow label for instance).

Frankly, this is one thing that I have found troubling with SrRv6. Sometimes it is portrayed as an alternative, shadow protocol to IPv6 that just happens to use the IPv6 protocol format for convenience instead of creating a new L3 protocol for its purposes. The rationalization for this seems to be that SRv6 is confined to limited domains, and within a limited domain we can safely redefine standard protocols in arbitrary ways-- note, there is no consensus that that philosophy is acceptable.

Tom

>
>
> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ron Bonica
> To: Eduard Metz <[email-masked]<mailto:[email-masked]>>
> Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> [RB] We don’t know if there are any protocols that rely on this definition of the IPv6 address. And if we don’t update RFC 4291 before violating it, we don’t know if anybody might write such an application in the future.
>
>
>
>                                                                                                    Ron
>
>
>
>
>
> cheers,
>
>   Eduard
>
>
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Oct 2021 16:13:44 +1300

> You are asking more general question: what was the legal reason to treat IPv6 address as LOC:FUNCT:ARG?

That is not incompatible with the addressing architecture as long as the locator is 64 bits and any semantics of the IID == FUNCT:ARG are local.
 
> 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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 13:39:58 +0200

Hi Brian,

> Which means: 64 bits.

Sorry but what is so magic about /64 here ?

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.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 9 Oct 2021 12:56:26 +0100

Robert Raszuk wrote on 09/10/2021 12:39:
> In my books if I get allocated say /48 or /40 from RIR what I do with 
> the remaining bits is my own business.

on your own network, indeed you can.  It would interoperate with 
nothing, and no-one else would mind.  But we're not talking about your 
basement: we're talking about a candidate for ietf working group 
adoption for a standards track document, and the discussion is about 
whether long-standing ipv6 semantics right at the bottom of the protocol 
stack should be broken in order to provide a minor convenience for srv6.

Extraordinary asks require extraordinary justification, and certainly on 
6man there doesn't seem to have been any justification provided by 
spring or the authors about why this change is necessary to the ipv6 
protocol stack.  tbh at this point, the draft seems to be a bit of a 
head scratcher.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Oct 2021 23:41:02 +1100

> remaining bits is my own business.

Please read RFC5453.

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 9 Oct 2021 17:49:30 +0200

I object adoption of this document as well based on copious amount of
technical counter arguments laid out in multiple threads. Beside that it
seems that to violate IETF v6 architecture documents we seem to be
trampling on established standards more and more using increasingly
contorted sophisms (yes, you can hijack any address architecture if you
_assume_ that only /4 will be routing table entries & the rest belongs to
your new interpretation of address being a chipmunk that by magic means
will never ever escape a private basement until it does).

Beside that as others already pointed out copiously the document content
does not even seem to actually match WG consensus as recorded to my
understanding

--- tony

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 9 Oct 2021 17:38:05 +0100

I object to adoption on pretty much the same basis as what Tony wrote.

IPv6 isn't some game of Jenga where the object is to see how many 
foundation blocks you can pull out before the whole thing collapses.

Separate to this, the WG adoption call for this draft violates two 
sections of the spring charter (avoiding modification to existing data 
planes and modification of data plane without reference to other WGs. 
The 6man WG was not formally consulted about this and it probably ought 
to have been.

Nick

Tony Przygienda wrote on 09/10/2021 16:49:
> _assume_ that only /4 will be routing table entries & the rest belongs 
> to your new interpretation of address being a chipmunk that by magic 
> means will never ever escape a private basement until it does).
> 
> On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica 
> <rbonica=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Folks,____
> 
>     __ __
> 
>     Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three
>     new SID types that can occupy the Destination Address field of an
>     IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for
>     details.____
> 
>     __ __
> 
>     The SPRING WG has issued a call for adoption for this draft.____
> 
>     __ __
> 
>     It is not clear that these SID types can be harmonized with the IPv6
>     addressing architecture.____
> 
>     __ __
> 
>     Does anyone have an opinion?____
> 
>     __ __
> 
>                                    
>                                                                                  Ron____
> 
>     __ __
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 20:14:18 +0200

Tony,

*(yes, you can hijack any address architecture if you _assume_ that only /4
will be routing table entries & the rest belongs to your new interpretation
of address being a chipmunk that by magic means will never ever escape a
private basement until it does).*

Let's try again ... as it seems this keeps coming back over and over again.

Assume I got allocated /4 from RIR and I have allocated /10 blocks to my
global sites connected over plain IPv6 Internet. I advertise those /10s via
BGP.

What technical harm will happen to anyone if I use bits 11-128 as it seems
to fit and still send those packets via v6 Internet ? No basement, but
public Internet.

Last time I checked bits are bits and there is either 0 or 1 in the packets
(at least till we get to quantum networking). It should be in no one's
business in the transit to look anywhere beyond /10.

Again please limit the answer to technical issues which this will cause.

Kind regards,
Robert

On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda <[email-masked]> wrote:

>> addressing architecture.

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 9 Oct 2021 20:41:39 +0200

As a simple example to which I already know your answer as in the usual
"oh, that will never happen" is the subnet routers anycast address I think.
The all zeroes have a meaning in IPv6 address space and intermediate nodes
that don't know they are dealing with a chipmunk may try to do something
with it, probably kill the chipmunk or maybe turn it into a fish if they
are in the next to be invented "ocean limited domain" which your chipmunk
should never enter.

Or maybe we all should read RFC2526 and make sure THAT never happens in a
chipmunk packet or if it does do we intend to remap a possible combination
that can be mistaken for anycast to something else so chipmunk doesn't
become a fish?  Or maybe there is already a SRv6 draft I missed that
declares IPv6 anycast a violation of the chipmunk limited domain.

As a historical example I lived, this is all oh so clever as folks who
figured out IPv6 actually did not explicitly forbid to assign the same link
local on a box to all interfaces (as far my thinking goes, a significant
mistake) which caused all kind of collateral for a bit actually and even
today, good luck to get all the linux tools to deal properly with %eth2
without coring (and even better luck trying that with funky interface
naming that linux is employing all over the place).

my last email on the subject (and I reserve right to maybe be off here and
there a bit, I'm not too deep into v6 and SRv6 but I've seen enough
architectural and WG mistakes to see this compression draft red-zoning),
let's see what the WG moves fwd' with

-- tony

On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk <[email-masked]> wrote:

> Tony,
>
>
> *(yes, you can hijack any address architecture if you _assume_ that only
> /4 will be routing table entries & the rest belongs to your new
> interpretation of address being a chipmunk that by magic means will never
> ever escape a private basement until it does).*
>
> Last time I checked bits are bits and there is either 0 or 1 in the
> packets (at least till we get to quantum networking). It should be in no
> one's business in the transit to look anywhere beyond /10.
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 21:06:41 +0200

> The all zeroes have a meaning in IPv6 address space

I am not trying to say that all predefined IPv6 innovations in the
remaining bits are bad.

So if I need to use subnet anycast to any ASBR advertising one of said
/10's I will put zeros in the remaining bits. Clearly this will not be SRv6
packet. SRv6 spec does not claim everything MUST be SRv6 from now on :)

Likewise if I need to use some format of the lower bits to get expected
behaviour I will do so.

I guess someone may be concerned what if any of the bits between /4 or /10
to /64 accidentally overlap with standards based reserved use cases ? Well
for one IPv6 stack should prevent one from accidentally using it. And again
this has nothing to do with SPRING. If anything SRv6 implementations use
IPv6 stacks hence such protection will be there anyway.

Best,
R.

On Sat, Oct 9, 2021 at 8:42 PM Tony Przygienda <[email-masked]> wrote:

>> What technical harm will happen to anyone if I use bits 11-128 as it
>> seems to fit and still send those packets via v6 Internet ? No basement,
>> but public Internet.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Oct 2021 09:01:42 +1300

> 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 ? 
> 
> 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.
> 
>  
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Oct 2021 09:22:22 +1300

This would all be much simpler if the SRV6 community explicitly dropped the claim to be implementing standard IPv6.

Whether the IETF wants to standardise something at layer 3 that isn't IPv6 is a separate question. It is pretty obvious that if spring adopts this 
draft and if it comes to IETF last call, that question will have to be resolved then. From the present discussion, there is very little chance of consensus.

Regards
   Brian Carpenter

On 10-Oct-21 08:06, Robert Raszuk wrote:
> I am not trying to say that all predefined IPv6 innovations in the remaining bits are bad. 
> 
> So if I need to use subnet anycast to any ASBR advertising one of said /10's I will put zeros in the remaining bits. Clearly this will not be SRv6 packet. SRv6 spec does not claim everything MUST be SRv6 from now on :) 
> 
behaviour I will do so. 
> 
> I guess someone may be concerned what if any of the bits between /4 or /10 to /64 accidentally overlap with standards based reserved use cases ? Well for one IPv6 stack should prevent one from accidentally using it. And again this has nothing to do with SPRING. If anything SRv6 implementations use IPv6 stacks hence such protection will be there anyway. 
> 
> Best,
> R.
> 
> 
> On Sat, Oct 9, 2021 at 8:42 PM Tony Przygienda <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     As a simple example to which I already know your answer as in the usual "oh, that will never happen" is the subnet routers anycast address I 
think. The all zeroes have a meaning in IPv6 address space and intermediate nodes that don't know they are dealing with a chipmunk may try to do something with it, probably kill the chipmunk or maybe turn it into a fish 
if they are in the next to be invented "ocean limited domain" which your chipmunk should never enter.
> 
>     Or maybe we all should read RFC2526 and make sure THAT never happens in a chipmunk packet or if it does do we intend to remap a possible combination that can be mistaken for anycast to something else so chipmunk doesn't become a fish?  Or maybe there is already a SRv6 draft I missed that declares IPv6 anycast a violation of the chipmunk limited domain.
> 
>     As a historical example I lived, this is all oh so clever as folks who figured out IPv6 actually did not explicitly forbid to assign the same link local on a box to all interfaces (as far my thinking goes, a significant mistake) which caused all kind of collateral for a bit actually and even today, good luck to get all the linux tools to deal properly with %eth2 without coring (and even better luck trying that with funky interface naming that linux is employing all over the place).
> 
>     my last email on the subject (and I reserve right to maybe be off here and there a bit, I'm not too deep into v6 and SRv6 but I've seen enough architectural and WG mistakes to see this compression draft red-zoning), let's see what the WG moves fwd' with
> 
>     -- tony
> 
>     On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Tony,
> 
>         /(yes, you can hijack any address architecture if you _assume_ that only /4 will be routing table entries & the rest belongs to your new 
interpretation of address being a chipmunk that by magic means will never 
ever escape a private basement until it does).
>         /
>         Assume I got allocated /4 from RIR and I have allocated /10 blocks to my global sites connected over plain IPv6 Internet. I advertise those /10s via BGP. 
> 
>         What technical harm will happen to anyone if I use bits 11-128 as it seems to fit and still send those packets via v6 Internet ? No 
basement, but public Internet. 
> 
>         Last time I checked bits are bits and there is either 0 or 1 in 
the packets (at least till we get to quantum networking). It should be in 
no one's business in the transit to look anywhere beyond /10. 
>         On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             I object adoption of this document as well based on copious 
amount of technical counter arguments laid out in multiple threads. Beside that it seems that to violate IETF v6 architecture documents we seem to 
be trampling on established standards more and more using increasingly contorted sophisms (yes, you can hijack any address architecture if you _assume_ that only /4 will be routing table entries & the rest belongs to your new interpretation of address being a chipmunk that by magic means will never ever escape a private basement until it does).
> 
>             Beside that as others already pointed out copiously the document content does not even seem to actually match WG consensus as recorded to my understanding
> 
>             --- tony
> 
>             On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica <rbonica=[email-masked] <mailto:[email-masked]>> wrote:
> 
>                 Folks,____
> 
>                 __ __
> 
>                 Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID types that can occupy the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for details.____
> 
>                 __ __
> 
>                 It is not clear that these SID types can be harmonized with the IPv6 addressing architecture.____
> 
>                 __ __
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 22:26:30 +0200

> 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 ?
> >
> > 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.
> >

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 9 Oct 2021 21:41:31 +0100

> Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 

Robert, there's been extensive discussion about this on 6man.  Please 
run a search on the ietf mail archive for 
draft-bourbaki-6man-classless-ipv6 to get a flavour for some of the 
complexities involved.

Nick

---

From: Ole Troan <[email-masked]>
Date: Sat, 9 Oct 2021 22:44:07 +0200

> On 9 Oct 2021, at 22:02, Brian E Carpenter <[email-masked]> wrote:
> 

I understand that you are trying to make a point. It benefits this discussion to be as precise as possible. 

There are all shades of grey here, as shown by the IETF standards, implementations and deployments. Let’s accept that fact, and we don’t have to make this unnecessarily divisive. 

O.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 9 Oct 2021 21:48:12 +0100

> seems to fit and still send those packets via v6 Internet ? No basement, 

Andrew Alston already answered this question with a production example.

> https://mailarchive.ietf.org/arch/msg/spring/WnTS8xI_M8grDPVs3IvNvc0sSNI/

Not all SRv6 implementations will be green-field or lab.  Probably many 
will not be, which is why the dst field rewriting proposal is actively 
harmful.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 22:51:59 +0200

Hi Nick,

I missed that draft, but I like it :)

Back to our discussion I am not sure how definition of IPv6 Interface
Identifiers came to the context of this thread. To the best of my
understanding no one claims that SRv6 must be contained to IPv6 IIDs.

RFC8986 section 3.2 uses an example of /64 IIDs, but this is only
illustration with explicit wording "a network operator may:" which in no
way should be read as any type of mandatory rule.

Back to my example of few /10 sites interconnected over Internet - how any
transit router is ever going to detect what am I doing with bits 11-128 in
my sites ? Yes I do accept some special use address formats and I perfectly
fine to make sure I will avoid using them.

Many thx,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 22:54:14 +0200

The link below says nothing related to what I was saying. I am
explicitly not talking about some "limited domain" in my example. I am
talking about a few sites connected over wild IPv6 Internet.

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Oct 2021 08:00:43 +1100

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.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 23:04:54 +0200

Please kindly correct me if I am wrong, but where do you see that SRv6 is
mandated to use "IPv6 Interface IDs" ?

On Sat, Oct 9, 2021 at 11:00 PM Mark Smith <[email-masked]> wrote:

>    described in Section 2.5.1 <https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1>.  Global Unicast addresses that start with
>>> 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
>>>
>>> >
>>> >     I have no time to study compressed SIDs, but if they trample on
>>> the
>>> LOC they are not IPv6 addresses.
>>> >
>>> >        Brian
>>> >
>>> >
>>> >
>>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Oct 2021 10:07:31 +1300

On 10-Oct-21 09:26, Robert Raszuk wrote:
> Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 reference. 

An address consists of a subnet prefix followed by an interface ID (see RFC4291 section 2.5). Then:

"  For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long..."

(RFC4291 section 2.5.1)

(The second half of that sentence is updated by https://www.rfc-editor.org/rfc/rfc7136#section-5, but the 64 bits remains.)

hard defined. 

The parameter is set unambiguously by section 2.5.1 and confirmed by RFC7136. I have argued that it should be taken out and put in a separate document, but there was no consensus to do so.

    Brian

>     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
> 
>     >
>     > 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. 
>     >     > Sorry, but it is a little bit late – 
RFC 8986 is already published.
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Oct 2021 10:13:16 +1300

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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Please also see RFC7421,  Analysis of the 64-bit Boundary 
in IPv6 Addressing.
> 
> 
> 
> 
> 
> 
>     On Sun, 10 Oct 2021, 07:27 Robert Raszuk, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             > Hi Brian, 
>             >
>             >> Which means: 64 bits.
>             >

>         Moreover sections 2.4 and 2.5 are very clear that there is no magic /64 hard defined. 
> 
>             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.
>             > 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. 
>             >     > Sorry, but it is a little bit late – RFC 8986 is already published.
>             >

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Oct 2021 23:25:46 +0200

Hi Brian & all,

Last email from me on this topic as I am pretty sure this will otherwise
never end.

I am not sure anyone will hardly argue that SRv6 is IPv6 or not. Maybe it
is IPv6+ fully backwards compatible with IPv6.

What really matters to me is that SRv6 packets can be forwarded by not SR
aware IPv6 network elements with no change to data plane and control plane
required. That's it - no more - no less.

And so far all SPRING work on SRv6 including the draft in the subject line
of this mail meets that.

Kind regards,
Robert

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

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Oct 2021 08:54:58 +1100

> And so far all SPRING work on SRv6 including the draft in the subject line

You've demonstrated you don't know enough IPv6 to say that. That is also
something that 6man are the authority to say, not SPRING.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 9 Oct 2021 23:04:35 +0100

Robert Raszuk wrote on 09/10/2021 22:25:
> What really matters to me is that SRv6 packets can be forwarded by not 
> SR aware IPv6 network elements with no change to data plane and control 
> plane required. That's it - no more - no less.

Andrew Alston's email indicates that there is at least one existing ipv6 
network deployment where this is not the case.  It is unlikely that this 
is an isolated example: there's no shortage of brownfield ipv6 
deployments on the internet.

As a general comment, protocol specification is about ensuring 
wide-scale interoperability, so redefining well-known semantic 
constructions is something that's likely to cause difficulties.  The 
lower in the stack you go, the more likely you are to run into problems.

Nick

---

From: Andrew Alston <[email-masked]>
Date: Sat, 9 Oct 2021 23:17:36 +0000

Robert,

I would say that many of your arguments – particularly that srv6 is not exactly ipv6 – if my interpretation of your emails is correct – indicate that indeed – we seem to be in the terrain of modifying or extending things that would put this wg In violation of its own charter – and the statement made by the chairs here: https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/

As such – can you point me to the I-D’s for the relevant documents which permit these modifications or extensions? Or, can you clarify how what we seeing in this debate does not run up against the aforementioned statement and the wg charter?

Thanks

Andrew

From: ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Sunday, 10 October 2021 at 00:26
To: Brian E Carpenter <[email-masked]>
Cc: SPRING WG <[email-masked]>, 6MAN <[email-masked]>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Hi Brian & all,

Last email from me on this topic as I am pretty sure this will otherwise never end.

I am not sure anyone will hardly argue that SRv6 is IPv6 or not. Maybe it is IPv6+ fully backwards compatible with IPv6.

What really matters to me is that SRv6 packets can be forwarded by not SR aware IPv6 network elements with no change to data plane and control plane required. That's it - no more - no less.

And so far all SPRING work on SRv6 including the draft in the subject line of this mail meets that.

Kind regards,
Robert

   Brian

---

From: Erik Kline <[email-masked]>
Date: Sat, 9 Oct 2021 19:03:48 -0700

<random>

To address the self-rewriting Destination Address complexity, and some
related objections, might it be possible to add a mutable TLV, requiring
the presence of an SRH (no SRH-less packets)?  The mutable TLV would
contain any extra state necessary to continue decompression of the current
segment in the SRH into the Destination Address field or trigger
advancement to the next segment in the list.  This would allow the DA to
remain a plain IPv6 address/SID (current operation).

(I've had a few other thoughts, but they aren't without their own
shortcomings.)

On Sat, Oct 9, 2021 at 2:13 PM Brian E Carpenter <
[email-masked]> wrote:

> >        described in Section 2.5.1 <
> https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1>.  Global
> >             > Is this coming from the longest routable IPv6 prefix ?
> Sort of analogy to /24 in the IPv4 world ? Or something else ?
> >             >
> >             > 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.
> >             >
> >             >
> >             >
> >             >     I have no time to study compressed SIDs, but if they
> trample on the
> 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>>
> >             >
> https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >

---

From: Ron Bonica <[email-masked]>
Date: Mon, 11 Oct 2021 23:14:12 +0000

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!!

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Saturday, October 9, 2021 4:02 PM
To: Robert Raszuk <[email-masked]>; 6MAN <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

   Brian

>     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-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Oct 2021 17:48:19 -0700

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

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 Oct 2021 01:13:26 +0000

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

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Monday, October 11, 2021 8:48 PM
To: Ron Bonica <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Robert Raszuk <[email-masked]>; 6MAN <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

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

> Subject: Re: [spring] 
> draft-filsfilscheng-spring-srv6-srh-compression-02
>
> > 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$ >
> >     
> __;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfcNurer0r4AERnlvFNF
> 5R1tp_Xys0a$
> __;!!NEt6yMaO-gk!REt-sc-5MVBAhjDSPz9fTwGxMKwFtdLhqQSna9TRwtrsuHyrYl4Mv
> K_MoR27s2Jl$

---

From: Erik Kline <[email-masked]>
Date: Mon, 11 Oct 2021 20:04:34 -0700

I've been noodling on these issues for a couple of days now (many thanks to
all who've been trying to help me understand), and I'm kinda confused by
how some unicast address semantics could be met (or not met).
Specifically: how can you ping a CSID?  It's possible to ping a SID, but I
don't yet see how this works with CSIDs.

Per RFC 4443 S4.2, the source address of an Echo Reply MUST be the
Destination Address.  If I understand things correctly (a big "if") the
first segment router won't reply to an Echo Request but instead
`uncompress` the address and forward the packet on, until it reaches the
last node.  The last node won't be able to originate a packet with the
correct source address though, I think.

Am I missing something?  Probably...

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 12 Oct 2021 14:35:42 +0000

<in reply to conversations on this thread>

This is an interesting conversation but I would like to restate something I mentioned early on. I'll try to say it differently this time.

1 - The CSID draft (draft-filsfilscheng-spring-srv6-srh-compression-02) does NOT alter the definition of an SRv6 SID as defined in RFC8754 and RFC8986.

2 - The CSID draft does define flavors of the END and END.X SIDs with arguments.

3 - We know SRv6 SIDs with arguments are defined in RFC8986 (eg section 4.12).

4 - We know SRv6 SIDs are IPv6 addresses (RFC8402, RFC8754 and RFC8986).

Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined in RFC8986 are also IPv6 addresses.

While it is interesting to rehash the discussion we had while working on RFC8754 and RFC8986 regarding SRv6 SIDs as IPv6 addresses, let's acknowledge it is orthogonal to SPRINGs adoption poll and subsequent work on draft-filsfilscheng-spring-srv6-srh-compression-02.

Sincerely,

  Darren

On 2021-10-01, 4:37 PM, "spring" <[email-masked]> wrote:

Folks,

                                                                                                           Ron

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 12 Oct 2021 15:39:45 +0100

> in RFC8986 are also IPv6 addresses.

Ok, this is good that we're all on the same page about SIDs being IPv6 
addresses.  This means that they and 
draft-filsfilscheng-spring-srv6-srh-compression need to comply with 8200 
and 4291, and it looks to me like the draft does not.

Nick

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 12 Oct 2021 15:46:38 +0000

Hi Nick, during review of RFC8986, section 3.2 was added.  SID allocation follows that.

Darren

On 2021-10-12, 10:40 AM, "Nick Hilliard" <[email-masked]> wrote:

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 12 Oct 2021 17:04:00 +0100

Good to hear.  This doesn't address compatibility with 8200 and 4291 
though, which seems to be the bit that's causing people concern.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Oct 2021 08:47:32 +1300

Could somebody provide a copious set of *example* IPv6 addresses that conform to draft-filsfilscheng-spring-srv6-srh-compression?

I means the actual addresses in standard IPv6 address notation (RFC5952) or just as 0x.... hex numbers.

BTW, is there running code for srv6-srh-compression?

Regards
   Brian Carpenter