Re: [spring] RFC8200 update?

On Sat, 29 Feb 2020, 06:55 Warren Kumari, <warren@kumari.net> wrote:

> On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk <robert@raszuk.net> wrote:
> >
> > > interestingly enough MPLS took the same approach
> >
> > 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."
>

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.
> >
> > On Fri, Feb 28, 2020 at 2:44 PM James Guichard <
> james.n.guichard@futurewei.com> 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
> >>
> >> -----Original Message-----
> >> From: spring <spring-bounces@ietf.org> On Behalf Of Sander Steffann
> >> Sent: Friday, February 28, 2020 8:25 AM
> >> To: Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com>
> >> Cc: SPRING WG List <spring@ietf.org>; 6man WG <ipv6@ietf.org>; Andrew
> Alston <Andrew.Alston@liquidtelecom.com>
> >> Subject: Re: [spring] RFC8200 update?
> >>
> >> 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
> >>
> >> _______________________________________________
> >> spring mailing list
> >> spring@ietf.org
> >> https://www.ietf.org/mailman/listinfo/spring
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>
> --
> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>