On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk <[email protected]> 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." > > 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 protected]> 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 <[email protected]> On Behalf Of Sander Steffann >> Sent: Friday, February 28, 2020 8:25 AM >> To: Wang, Weibin (NSB - CN/Shanghai) <[email protected]> >> Cc: SPRING WG List <[email protected]>; 6man WG <[email protected]>; Andrew Alston >> <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > 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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
