Joel, Am I wrong understanding that definition of "limited domain" was never approved by any formal IETF process ?
If so do you really think we should be bounded on something which has been defined outside of IETF ? Cheers, Robert On Mon, Oct 10, 2022 at 4:03 PM Joel Halpern <jmh.dir...@joelhalpern.com> wrote: > SRH was explicitly defined for use in limited domains. That is why I > think dropping it is acceptable. Certainly not required, but permitted. > The closest equivalent is NSH, which is also defined for limited domains. > In my personal opinion (not speaking for the SFC working group) I think it > would be legitimate for a domain, particularly one that is using NSH, to > drop packets where the IP carried protocol is NSH. (I would prefer that > they block only packets to their domain with carried protocol of NSH, but > that is up to the operator.) > > You have said that you consider the limited domain requirement to be wrong > and irrelevant. Whether you agree with it or not, it is in the RFC. > Operators may reasonably act on that. > > Yours, > > Joel > On 10/10/2022 9:59 AM, Robert Raszuk wrote: > > > it seems acceptable to block all packets with SRH > > And such statements you are making are exactly my point. > > Just curious - Is there any other extension header type subject to being a > good enough reason to drop packets at any transit node in IPv6 ? > > Thx, > R. > > On Mon, Oct 10, 2022 at 3:53 PM Joel Halpern <jmh.dir...@joelhalpern.com> > wrote: > >> Protection from leaking inwards is required by the RFCs as far as I know. >> >> Note that there are multiple ways to apply such protection. It is >> sufficient for the domain only to block packets addressed to its own SID >> prefixes. If the domain is using SRv6 without compression or reduction, it >> seems acceptable to block all packets with SRH. After all, they should not >> be occurring. But we do not tell operators how to perform the filtering. >> It is up to them what they do. >> >> Yours, >> >> Joel >> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
