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

Reply via email to