David, No, that is not what I am saying. I am saying that the concept of limited domains is very loosely defined in rfc8799 and using it as a base to drop packets which contain SRH is not right.
For example are my enterprise sites interconnected with SD-WAN a limited domain - surely is for me even if I use vanilla IPv6 Interconnect to talk between them. And let's not worry about such sites' security ... This is a completely different topic. Let's agree that dropping IPv6 packets somewhere in transit only because they contain specific extension header is illegal. Thx, R. On Mon, Oct 10, 2022 at 4:56 PM David Farmer <far...@umn.edu> wrote: > If you are saying the concept of Limited Domains does not apply to SRH > since it isn't an IETF consensus document, then I believe that calls the > consensus for SRH into serious question. Furthermore, if the SRH consensus > is questionable, the idea that operators might filter it shouldn't be > surprising. > > Thanks > > On Mon, Oct 10, 2022 at 9:24 AM Robert Raszuk <rob...@raszuk.net> wrote: > >> 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 >>>> >>>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > -- > =============================================== > David Farmer Email:far...@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
