Subject: [spring] RFC8200 update?

From: Sander Steffann <[email-masked]>
Date: Fri, 28 Feb 2020 13:02:07 +0100

Hi,

I have been thinking about SRv6 and the whole discussion around header removal at one of the SR nodes. While I strongly see the current network programming PSP function as a violation of RFC8200, one of the possible options is of course to update RFC8200 to allow some things that are currently not allowed.

Before you start throwing rotten tomatoes, hear me out :)

The most important argument against modifying a packet between the sender and the final receiver is that it can cause surprises for the sender. ICMP errors getting back to the sender about stuff the sender didn't do, pMTUd problems etc. And I think this is a very strong argument, and we shouldn't cause any surprises for the sender.

But, what if the sender *asks* the network to do things to its packets? Like in network programming. If the sender asks to have the network perform a certain function, it can't come as a surprise when it gets an ICMP error after the packet has been modified. It asked for that modification itself! And with that in mind, we might actually allow much more than just header removal in the network.

What if we update RFC8200 to allow packet manipulation in the network if and only if the sender of the packet explicitly asked for that? That would open the door for a whole range of innovation (PSP, WAN optimisation, payload compression etc), but only when requested. If the sender explicitly includes network programming instructions then there is no need anymore to forbid the execution of those instructions. No surprises, the possibility of smarts in the network, while still preserving the current semantics of an end-to-end network by default with strong rules about not messing with the packet.

Would this be a way forward that would accommodate everyones requirements?

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Fri, 28 Feb 2020 12:18:11 +0000

This is certainly an interesting idea - and I'd probably need to give this a whole lot more thought before commenting properly, but the first thought that comes to mind is - would we be able to standardize a way to instruct like this.

What I would not want to see is every extension header out there having a separate method of instructing the network to allow this behavior whenever they feel like it, because it would create a nightmare both in terms of seeing if something was requesting it, and I would imagine, implementing it.

So - my question is - what would be the standard way to introduce this - and to this I would say - if you wanted to do this you'd almost want to add a very short extension header that contains this instruction, that is easy to see and easy to parse - since I don't see anywhere in the v6 header itself that we could add this functionality as a flag of sorts.

Interesting ideas - but as I said - I'd argue that if we went this route - I'd want a standard shared way to do this by anything coming tomorrow - to avoid still further divergence.

Thanks

Andrew

> -----Original Message-----
> From: spring <[email-masked]> On Behalf Of Sander Steffann
> Sent: Friday, 28 February 2020 15:02
> To: SPRING WG List <[email-masked]>; 6man WG <[email-masked]>
> Subject: [spring] RFC8200 update?
> 
> Hi,
> 
> I have been thinking about SRv6 and the whole discussion around header
> removal at one of the SR nodes. While I strongly see the current network
> programming PSP function as a violation of RFC8200, one of the possible
> options is of course to update RFC8200 to allow some things that are
> currently not allowed.
> 
> The most important argument against modifying a packet between the
> sender and the final receiver is that it can cause surprises for the sender.
> ICMP errors getting back to the sender about stuff the sender didn't do,
> pMTUd problems etc. And I think this is a very strong argument, and we
> shouldn't cause any surprises for the sender.
> 
> But, what if the sender *asks* the network to do things to its packets? Like in
> network programming. If the sender asks to have the network perform a
> certain function, it can't come as a surprise when it gets an ICMP error after
> the packet has been modified. It asked for that modification itself! And with
> that in mind, we might actually allow much more than just header removal in
> the network.
> 
> What if we update RFC8200 to allow packet manipulation in the network if
> and only if the sender of the packet explicitly asked for that? That would
> open the door for a whole range of innovation (PSP, WAN optimisation,
> payload compression etc), but only when requested. If the sender explicitly
> includes network programming instructions then there is no need anymore
> to forbid the execution of those instructions. No surprises, the possibility of
> smarts in the network, while still preserving the current semantics of an end-
> to-end network by default with strong rules about not messing with the
> packet.
>

---

From: Sander Steffann <[email-masked]>
Date: Fri, 28 Feb 2020 13:51:22 +0100

Hi Andrew,

> What I would not want to see is every extension header out there having a separate method of instructing the network to allow this behavior whenever they feel like it, because it would create a nig…

Well, it depends on what you deploy in your network. If you deploy SRv6 NP then nodes sending traffic over your network can use the NP functions you provide. If you don't provide any functions then there is nothing a sender can do. This obviously only works when sender and network cooperate. Otherwise the NP instruction will make no sense. And AFAIK source-routing, segment-routing etc are not enabled by default these days, so packets using them will be dropped unless the network is specifically configured to allow them.

> So - my question is - what would be the standard way to introduce this - and to this I would say - if you wanted to do this you'd almost want to add a very short extension header that contains this…

That might be useful for many things besides this. Let's talk.

> Interesting ideas - but as I said - I'd argue that if we went this route - I'd want a standard shared way to do this by anything coming tomorrow - to avoid still further divergence.

I'm not sure a standard way is needed. Maybe limit the scope to "if the sender of the packet explicitly asked for that using a routing header"?

Cheers,
Sander

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Fri, 28 Feb 2020 13:19:14 +0000

In the bearer of srv6 traffic, srv6 domain is only one part of the whole packet journey. Because the srv6 domain is trusted by single operator, it is no necessary for the outer IPv6 header (for performing SRH function) to inherit all IPv6 extension headers specially designed for the initial end-to-end IPv6 communication, for example, the AH is not must for outer IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6 traffic can appropriately relax the restrictions, that is to say, the outer IPv6 encapsulation only inherits a part of IPv6 spec. For example, it is allowed to perform functions such as PSP within SRv6 domain;  Could we treat IPv6 headers function of internal and external layers differently, after all, their purposes are different.

Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Sander Steffann
Sent: Friday, February 28, 2020 8:51 PM
To: Andrew Alston <[email-masked]>
Cc: SPRING WG List <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [spring] RFC8200 update?

Hi Andrew,

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Fri, 28 Feb 2020 14:24:31 +0100

Hi,

> In the bearer of srv6 traffic, srv6 domain is only one part of the whole packet journey. Because the srv6 domain is trusted by single operator, it is no necessary for the outer IPv6 header (for performing SRH function) to inherit all IPv6 extension headers specially designed for the initial end-to-end IPv6 communication, for example, the AH is not must for outer IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6 traffic can appropriately relax the restrictions, that is to say, the outer IPv6 encapsulation only inherits a part of IPv6 spec.

No. It uses IPv6 and must therefore follow the rules of IPv6. What I propose is to update IPv6 to make this possible, but you can't break the rules in a standard without consensus that the rules can be changed.

> For example, it is allowed to perform functions such as PSP within SRv6 domain;  Could we treat IPv6 headers function of internal and external layers differently, after all, their purposes are different.

Let's not use implicit definitions of "internal" and "external" layers. They don't make sense in a global protocol (and despite your claims that SRv6 is limited to a specific domain, it really isn't. It uses global IPv6 addresses and can traverse the global internet). Let's define global rules that apply to everybody instead, and standardise this behaviour.

Cheers,
Sander

---

From: James Guichard <[email-masked]>
Date: Fri, 28 Feb 2020 13:44:07 +0000

Hi Sander,

RFC8402 explicitly says in section 8 security considerations that "by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain". The intent therefore seems clear that "global internet" does not apply; interestingly enough MPLS took the same approach and has been widely deployed for years.

Respectfully,

Jim

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Sander Steffann
Sent: Friday, February 28, 2020 8:25 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Cc: SPRING WG List <[email-masked]>; 6man WG <[email-masked]>; Andrew Alston <[email-masked]>
Subject: Re: [spring] RFC8200 update?

Hi,

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 15:02:23 +0100

> interestingly enough MPLS took the same approach

Well not really. As you know, MPLS unicast and multicast have a new
ethertype.

SRv6 folks were just too nice and thought to leverage 0x86DD. I think that
was a mistake. I further think we should fix it.

Cheers,
R.

On Fri, Feb 28, 2020 at 2:44 PM James Guichard <
[email-masked]> wrote:

> Hi Sander,
>
> RFC8402 explicitly says in section 8 security considerations that "by
> default, the explicit routing information MUST NOT be leaked through the
> boundaries of the administered domain". The intent therefore seems clear
> that "global internet" does not apply; interestingly enough MPLS took the
> same approach and has been widely deployed for years.
>
> Respectfully,
>
> Jim
>
> > In the bearer of srv6 traffic, srv6 domain is only one part of the whole
> packet journey. Because the srv6 domain is trusted by single operator, it
> is no necessary for the outer IPv6 header (for performing SRH function) to
> inherit all IPv6 extension headers specially designed for the initial
> end-to-end IPv6 communication, for example, the AH is not must for outer
> IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6
> traffic can appropriately relax the restrictions, that is to say, the outer
> IPv6 encapsulation only inherits a part of IPv6 spec.
>
> No. It uses IPv6 and must therefore follow the rules of IPv6. What I
> propose is to update IPv6 to make this possible, but you can't break the
> rules in a standard without consensus that the rules can be changed.
>
> > For example, it is allowed to perform functions such as PSP within SRv6
> domain;  Could we treat IPv6 headers function of internal and external
> layers differently, after all, their purposes are different.
>
> Let's not use implicit definitions of "internal" and "external" layers.
> They don't make sense in a global protocol (and despite your claims that
> SRv6 is limited to a specific domain, it really isn't. It uses global IPv6
> addresses and can traverse the global internet). Let's define global rules
> that apply to everybody instead, and standardise this behaviour.
>
> Cheers,
> Sander
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: James Guichard <[email-masked]>
Date: Fri, 28 Feb 2020 14:08:53 +0000

Indeed although I was commenting on the fact that MPLS does not leak MPLS packets outside of the administrative domain just like SRv6 MUST NOT ..

From: Robert Raszuk <[email-masked]>
Sent: Friday, February 28, 2020 9:02 AM
To: James Guichard <[email-masked]>
Cc: Sander Steffann <[email-masked]>; Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>; SPRING WG List <[email-masked]>; 6man WG <[email-masked]>; Andrew Alston <[email-masked]>
Subject: Re: [spring] RFC8200 update?

> interestingly enough MPLS took the same approach

Well not really. As you know, MPLS unicast and multicast have a new ethertype.

SRv6 folks were just too nice and thought to leverage 0x86DD. I think that was a mistake. I further think we should fix it.

Cheers,
R.

On Fri, Feb 28, 2020 at 2:44 PM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sander,

Respectfully,

Jim

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Sander Steffann
Sent: Friday, February 28, 2020 8:25 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] RFC8200 update?

Hi,

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C855c414ffe774210ff8808d7bc56df71%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184953611018112&sdata=MN7hgUndA0GZdyfHJwN6iFGnFnP3jjXl%2BC94NX0DzNE%3D&reserved=0>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 28 Feb 2020 07:50:23 -0800

> But, what if the sender *asks* the network to do things to its packets? Like in network programming. If the sender asks to have the network perform a certain function, it can't come as a surprise w…
Sander,

Please take a look at draft-herbert-6man-eh-attrib-00, I think it is
very much in line with what you're thinking.

The basic idea is that we create a new "Attribution" Hop-by-Hop
option. The option serves two purposes:

1) If the source host sets the option in a packet then it is giving
permission to intermediate nodes to insert extensions headers (and
Hop-by-Hop options which need to be handled specially). Presumably,
when the source includes the option it is capable of dealing with ICMP
errors with inserted extension headers.
2) The option indicates the extension headers (and Hop-by-Hop options)
that have been inserted by intermediate nodes. So it's modified by
intermediate nodes when insertion happens. The effect is that for any
given packet at any time it is clear which data is attributed to the
source node, and which is attributed to intermediate nodes.

The option would also allow intermediate nodes to remove inserted
headers (ones attributed to intermediate nodes)

Receiver handling of inserted headers needs to be considered.

For making AH work, it would be straightforward simply not include any
inserted headers in the computation, the necessary information to do
that is in the HBH option. In this case, the option can't be ignored
so second high order bit of option type would need to be set.

If AH isn't present, I believe the HBH option could safely be ignored
if unknown at the receiver. Other than AH, I don't see any other cases
where ignoring the HBH option and processing inserted options leads to
incorrect behavior (if there are possible cases please point them
out).

Tom

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

---

From: Sander Steffann <[email-masked]>
Date: Fri, 28 Feb 2020 17:04:17 +0100

Hi,

> headers (ones attributed to intermediate nodes)

I haven't read the draft yet, but that sounds about right :)

> incorrect behavior (if there are possible cases please point them

I think both variants would have to be defined, one with the high order bit set and one with it unset. When AH is used then the one with the high order bit set has to be used, in other cases the sender can choose what is most appropriate for them (probably the other one).

Sounds like a way forward! I think something like this HbH option would be required before SRv6 NP PSP can move forward.

Cheers,
Sander

---

From: Warren Kumari <[email-masked]>
Date: Fri, 28 Feb 2020 14:54:14 -0500

> Well not really. As you know, MPLS unicast and multicast have a new ethertype.

And this is a critical distinction -- Brian Carpenter's limited domain
document (draft-carpenter-limited-domains) says:
"Domain boundaries that are defined administratively (e.g. by address
filtering rules in routers) are prone to leakage caused by human
error, especially if the limited domain traffic appears otherwise
normal to the boundary routers. In this case, the network operator
needs to take active steps to protect the boundary. This form of
leakage is much less likely if nodes must be explicitly configured to
handle a given limited domain protocol, for example by installing a
specific protocol handler."

> On Fri, Feb 28, 2020 at 2:44 PM James Guichard <[email-masked]> wrote:
>>
>> Hi Sander,
>>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Feb 2020 12:13:18 +1100

> specific protocol handler."

Using IPv6 for SR is fundamentally using the wrong tool for the job.

IPv6 is an internetworking protocol used to network networks and to
internetwork all hosts attached to all of those networks.

The SR problem space is typically limited to local network or sub-network,
and usually only between network elements, rather than out to end hosts.

It does make sense to try to use a internetworking protocol to solve a
local sub-network problem when the internetworking protocol has become
commodity. The benefits of the cheapness of the commodity protocol should
outweigh the costs of the drawbacks and compromises that need to be made to
use it.

However, the moment customising the commodity to better suit the problem
starts is the moment the benefits of using the existing commodity start
being lost. Customise too much and all of the benefits of choosing a
commodity in the first place disappear.

That's why I fundamentally think changing IPv6 to suit SR should be avoided
as much as possible.

Compromising SR to suit and fit within existing IPv6 would retain the
benefits of using existing commodity IPv6. Customising IPv6 to suit SR
risks throwing the commodity benefits "baby out with the bathwater", with
the more radical the customising, the greater risk.

Regards,
Mark.

>
>
> >
> > SRv6 folks were just too nice and thought to leverage 0x86DD. I think
> that was a mistake. I further think we should fix it.
> >
> > Cheers,
> > R.
> >
> >> > In the bearer of srv6 traffic, srv6 domain is only one part of the
> whole packet journey. Because the srv6 domain is trusted by single
> operator, it is no necessary for the outer IPv6 header (for performing SRH
> function) to inherit all IPv6 extension headers specially designed for the
> initial end-to-end IPv6 communication, for example, the AH is not must for
> outer IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6
> >> > For example, it is allowed to perform functions such as PSP within
> SRv6 domain;  Could we treat IPv6 headers function of internal and external

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Feb 2020 11:45:11 +0100

Hi Mark,

I actually fully agree with your below note.

However my reasoning to agree perhaps is slightly different then yours :).

I agree on the basis that as defined today in spite huge efforts and good
will by all involved in IPv6 definition it is just not flexible enough to
accommodate current and future needs.

Your reasoning seems to be the opposite - IPv6 is great as is or "it is
what it is: enjoy as served" - and just applications looking for transport
need to be trimmed down to fit it.

Clearly we have different opinions here - but in my books networks are to
serve user needs and carry modern applications as opposed to act as an
emperor telling everyone around how and what can be carried.

And to be very clear - I am not saying you are wrong. Perhaps you look at
train analogy - sure if each passenger would start messing with train
car/wagons construction the train would clearly not go far. But if so we
just need a new train architecture rather then saying - oh no Mr. SR you
can not travel at all.

Many thx,
R.

On Sat, Feb 29, 2020 at 2:13 AM Mark Smith <[email-masked]> wrote:

> That's why I fundamentally think changing IPv6 to suit SR should be
> avoided as much as possible.
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 29 Feb 2020 12:28:16 +0000

Mark,

It is possible to implement the SR architecture without perverting IPv6. That's what SRm6 is all about.

SR solves the following problems:

  *   Traffic steering
  *   Passing information to segment endpoints to support SFC
  *   Passing information to the packet's ultimate destination to support VPNs
  *   Fast Reroute

All of these can be addressed without breaking the IPv6 architecture. See:

  *   https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/ for traffic steering
  *   https://datatracker.ietf.org/doc/draft-bonica-6man-seg-end-opt/ for delivering information to segment endpoints
  *   https://datatracker.ietf.org/doc/draft-bonica-6man-vpn-dest-opt/ for delivering information to the packet's ultimate destination

Fast reroute can be achieved with an IPv6-compliant variation of TI-LFA. Create the repair path by encapsulating the packet in another IPv6 header that has its own Routing header.

                                                                                          Ron

From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Friday, February 28, 2020 8:13 PM
To: Warren Kumari <[email-masked]>
Cc: James Guichard <[email-masked]>; SPRING WG List <[email-masked]>; 6man WG <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [spring] RFC8200 update?

On Sat, 29 Feb 2020, 06:55 Warren Kumari, <[email-masked]<mailto:[email-masked]>> wrote:

IPv6 is an internetworking protocol used to network networks and to internetwork all hosts attached to all of those networks.

The SR problem space is typically limited to local network or sub-network, and usually only between network elements, rather than out to end hosts.

It does make sense to try to use a internetworking protocol to solve a local sub-network problem when the internetworking protocol has become commodity. The benefits of the cheapness of the commodity protocol should outweigh the costs of the drawbacks and compromises that need to be made to use it.

However, the moment customising the commodity to better suit the problem starts is the moment the benefits of using the existing commodity start being lost. Customise too much and all of the benefits of choosing a commodity in the first place disappear.

That's why I fundamentally think changing IPv6 to suit SR should be avoided as much as possible.

Compromising SR to suit and fit within existing IPv6 would retain the benefits of using existing commodity IPv6. Customising IPv6 to suit SR risks throwing the commodity benefits "baby out with the bathwater", with the more radical the customising, the greater risk.

Regards,
Mark.

> On Fri, Feb 28, 2020 at 2:44 PM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Sander,
>>
>> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!RyNO7NdA0TVRLR5IWzQtztXYzSVXXmWf9C42QoCax9VkMMefqNhlkK6es2NheiOg$>
>
> [email-masked]<mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RyNO7NdA0TVRLR5IWzQtztXYzSVXXmWf9C42QoCax9VkMMefqNhlkK6esxpQhIzK$>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RyNO7NdA0TVRLR5IWzQtztXYzSVXXmWf9C42QoCax9VkMMefqNhlkK6esxpQhIzK$>
--------------------------------------------------------------------

Juniper Business Use Only