Eric, you seem to be objecting to something I did not say. I have not
asked, and do not expect, for the document to mandate or even suggest
that arbitrary domains should drop packets with SRH. I will note that
given that SRH is explicitly for limited domains, an operator who
chooses to drop such packets is well within his rights. And I am told
there are such operators. But that is not what I asked for this document.
What I asked, and I believe Suresh has agreed to, and I beleive the WG
supports, is that the document note that an operator using SRv6 who does
not use the allocated SID, and block the allocated SID at his
boundaries, has to be more careful to define his ingress and egress
filters to comply with the existing RFCs which require that SRv6 not
leak inwards or outwards.
Robert objected to that requirement. And propounde3d a use case that he
says he needs. I pointed out that the use case violates the RFC. And
then pointed out one of the many reasons why the IETF has put in the
requirement which he wants to violate.
Yours,
Joel
On 10/10/2022 5:57 AM, Eric Vyncke (evyncke) wrote:
Hmmm I really wonder why a transit network should look into my packets
(to check for SRH) and decide to drop my packets; assuming of course
that my packets are not damaging the transit network (like some
hop-by-hop years ago) or attempting to trick my network (anti-spoofing
or using transit provider own SID -- both being layer-3 filters BTW).
-éric
*From: *ipv6 <ipv6-boun...@ietf.org> on behalf of Joel Halpern
<j...@joelhalpern.com>
*Date: *Sunday, 9 October 2022 at 16:38
*To: *Robert Raszuk <rob...@raszuk.net>
*Cc: *6man <i...@ietf.org>, SPRING WG List <spring@ietf.org>
*Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
We require, per the RFC, blocking SRH outside of the limited domain
for many reasons.
One example is that it turns SRH into a powerful attack vector, given
that source address spoofing means there is little way to tell whether
an unencapsulated packet actually came from another piece of the same
domain.
So yes, I think making this restriction clear in this RFC is important
and useful.
Yours,
Joel
On 10/8/2022 5:07 PM, Robert Raszuk wrote:
Hi Brian,
Completely agree.
One thing is not to guarantee anything in respect to forwarding
IPv6 packets with SRH (or any other extension header) and the
other thing is to on purpose recommending killing it at
interdomain boundary as some sort of evil.
Cheers,
R.
On Sat, Oct 8, 2022 at 9:51 PM Brian E Carpenter
<brian.e.carpen...@gmail.com> wrote:
Robert,
> 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.
The Internet is more or less opaque to most extension headers,
especially to recently defined ones, so I don't hold out much
hope for SRH outside SR domains.
https://www.rfc-editor.org/rfc/rfc9098.html
https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-fw
Regards
Brian Carpenter
On 09-Oct-22 07:52, 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 <mailto: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.
>
>
>
--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
