Joel, If anyone would be really serious about keeping SRv6 closed new ethertype should have been allocated to it. But since it reuses IPv6 one filtering packets based on the presence of specific extension headers type is not something we should be endorsing.
Just imagine the security aspect when someone attached to a data plane will insert even empty SRH to your v6 packets and have your packets being dropped N AS hops away when some implementation decides to apply subject filters. Note also commercial efforts to use SRv6 to Program the Internet .. https://medium.com/syntropynet/perfecting-the-networks-noias-programmable-internet-part-4-e1e1acadcc14 https://medium.com/syntropynet/srv6-is-official-paving-the-way-for-global-noia-adoption-523b40fac26b Sure you may say they are not compliant with "limited domain" paradigm ... but that is so much you can do about it :). Best, R. On Sat, Oct 8, 2022 at 9:11 PM Joel Halpern <j...@joelhalpern.com> wrote: > Robert, whether you "buy into limited domain" or not, it is in the RFC and > was part of what the IESG considered when they approved it. As such, > unless you believe you can change the community consensus our > specifications need to conform to that. > > Yours, > > Joel > On 10/8/2022 2:52 PM, Robert Raszuk wrote: > > Hi Joel, > > I was hoping this is apparent so let me restate that I do not buy into > "limited domain" business for SRv6. > > I have N sites connected over v6 Internet. I want to send IPv6 packets > between my "distributed globally limited domain" without yet one more > encap. > > If there is any spec which mandates that someone will drop my IPv6 packets > only because they contain SRH in the IPv6 header I consider this an evil > and unjustified action. > > Kind regards, > Robert > > On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern <j...@joelhalpern.com> wrote: > >> Robert, I am having trouble understanding your email. >> >> 1) A Domain would only filter the allocated SIDs plus what it chooses to >> use for SRv6. >> >> 2) Whatever it a domain filters should be irrelevant to any other domain, >> since by definition SRv6 is for use only within a limited domain. So as >> far as I can see there is no way a domain can apply incorrect filtering. >> >> Yours, >> >> Joel >> On 10/8/2022 3:16 AM, Robert Raszuk wrote: >> >> Hi Suresh, >> >> NEW: >>> In case the deployments do not use this allocated prefix additional care >>> needs to be exercised at network ingress and egress points so that SRv6 >>> packets do not leak out of SR domains and they do not accidentally enter SR >>> unaware domains. >>> >> >> IMO this is too broad. I would say that such ingress filtering >> could/should happen only if dst or locator is within locally >> configured/allocated prefixes. Otherwise it is pure IPv6 transit and I see >> no harm not to allow it. >> >> >>> Similarly as stated in Section 5.1 of RFC8754 packets entering an SR >>> domain from the outside need to be configured to filter out the selected >>> prefix if it is different from the prefix allocated here. >>> >> >> Again the way I read it this kills pure IPv6 transit for SRv6 packets. >> Why ? >> >> (Well I know the answer to "why" from our endless discussions about SRv6 >> itself and network programming however I still see no need to mandate in >> any spec to treat SRv6 packets as unwanted/forbidden for pure IPv6 transit.) >> >> Thx, >> R. >> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
