Re: [IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg-hdr

[Justin Iurman <[e-mail]>]

+1 to what Tom just said.

As is, there is no such thing as "SRv6 packets". At the end of the day, 
it's still an IPv6 packet. Of course, it has a specific extension header 
attached... but that does *not* make it something different than an IPv6 
packet.

Cheers,
Justin

On 11/1/23 12:40, Tom Herbert wrote:
> On Wed, Nov 1, 2023 at 11:40 AM Tony Przygienda <[e-mail]> wrote:
>>
>>
>>
>> On Tue, Oct 31, 2023 at 9:45 PM Tom Herbert <[e-mail]> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, Oct 31, 2023, 12:54 PM Tony Przygienda <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Oct 31, 2023 at 5:47 PM Tom Herbert <tom=[e-mail]> wrote:
>>>>>
>>>>> On Mon, Oct 30, 2023 at 6:33 PM Joel Halpern <[e-mail]> wrote:
>>>>>>
>>>>>> Maybe I am dense, but I have trouble seeing how a node could have enough information to compose a useful CRH source route, and not have enough information to know where the relevant decapsulator is.  The most obvious candidate would be simply to decapsulate at the last entry in the source route.  it doesn't matter if that is (as is likely) not actually the egress.
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> Yes, that would probably be the most obvious candidate, and it's also
>>>>> a candidate for removing the RH. Once segments left is zero, the
>>>>> routing header is not operationally relevant to any downstream nodes.
>>>>>
>>>>> But even if that were the obvious choice for an encapsulation, I still
>>>>> don't see how the source could know when to encapsulate and when not
>>>>> to. A possible solution might be to tunnel all packets, but then
>>>>> that's a lot of per packet overhead especially if most packets never
>>>>> actually leave the limited domain.
>>>>>
>>>>> More generally, constraining protocols like routing header to a
>>>>> limited domain is required and it's clear that *something* needs to
>>>>> happen at edge routers of the limited domain.
>>>>> draft-raviolli-intarea-trusted-domain-srv6 has a good description of
>>>>> the problem. That's focused on SR, but other routing headers like CRH,
>>>>> and other use cases of extension headers also have similar
>>>>> requirements-- I would hope that there might be a general solution to
>>>>> limiting protocol to limited domains (IMO, a new Ethertype like
>>>>> described in that draft isn't the best solution and is likely to
>>>>> create a set of new problems)
>>>>
>>>>
>>>> can you be more specific here? seemed to have worked for mpls like a charm, for a very long time, at a very large scale ... and to differentiate v4 from v6 and many, many other use cases where it was necessary to quickly deploy a domain boundary ...
>>>
>>>
>>> Hi Tony,
>>>
>>> Right there's an Ethertype to differentiate IPv4 and IPv6, and there's an Ethertype for MPLS. But unlike those cases and contrary to what some people might claim :-), segment routing is *not* a new network protocol-- it is IPv6 with a routing header.
>>
>>
>>   Hey Tom,
>>
>> I have heard/seen adamant claims that SRv6 with compression may NOT carry a routing header.
>>
>> As to whether it's IPv6 I see since years sets of discussions claiming a yes or no depending on proponents of drafts and whichever way serves them best to support their idea.  Claiming SRv6 is IPv6 seems to me leading down the path where a IPv6 packet (and dst address in particular) can be defined to mean anything, including replication bitmasks and then declaring things like BIER being IPv6 [and don't think that hasn't been tried] ;-)  Layering and abstraction are the only ways technologies (and in general complexity) scale and this kind of logic runs straight against it IME.
> 
> Tony,
> 
> I don't believe calling segment routing IPv6 is a subjective opinion.
> If we sample a packet on a network and it has Ethertype 0x800 and IP
> version number is six, then it *is* an IPv6 packet and will be
> processed as such. Sure, it might also be a SRv6 packet or a BIER
> packet, but fundamentally to the network an especially at intermediate
> nodes between segments it is processed and forwarded as an IPv6
> packet. Such packets MUST conform to RFC8200 for instance.
> 
> Defining a new Ethertype for SRV6 would change that so that SRV6 could
> be a distinct protocol with its own requirements. As I said, I believe
> there's a risk of divergence with IPv6 so that it becomes a new L3
> protocol. Even so, if there is some need to fundamentally make SRv6 a
> distinct L3 protocol from IPv6 like the header format needs to be
> different, then IMO a new Ethertype would be much better route than
> trying to infer alternative semantics based on the the context of the
> limited domain in which the protocol is used. In other words, if
> Ethertype is 0x800 then the packet is IPv6 universally, it's not "IPv6
> for the Internet" or "IPv6 in the limited domain".
> 
>>
>>>
>>> So a new Ethertype would at best be a synonym for IPv6, and in the worst case it might be an incentive to branch IPv6 in odd and non compatible ways. That coupled with the massive change in implementations, tooling, and operations that would be needed makes me think it's not a preferred solution. These points were raised at the 6man IETF117 meeting.
>>
>>
>>
>> well, I do work with good amount of very experienced chip folks and according to them it presents  little difficulty. ethertype points at certain block processing and then hands off to srv6 block and that's about it.
> 
> It may be a little easier to filter at the edge, but now we have to
> change every router in the network and potentially every host and also
> all of the tooling and tracing to accommodate a new Ethertype that is
> the same thing as 0x800. I still don't see that the benefits outweigh
> the costs.
> 
>>
>>
>>>
>>>
>>>>
>>>>
>>>> Unless we have a clear, simple demarcation on the packet we end up building basically a stateful firewall by deep inspection or state-tying-together magic. one can afford that at L4 throughputs (at high cost) but the game is very different with the L3 or L2.5 economics as they are today.  As long CRH is mandatory on _every_ SRv6 packet, ok, it's bit deep to parse into but maybe somewhat workable, without, it eludes me how to build a simple, economical, non-stateful solution to delineate a possible SRv6 injection attack surface distinguishable from normal v6 forwarding unless a new ethertype is required.
>>>
>>>
>>> As the CRH draft already says, a packet can be identified at the edge by inspection to see if it contains a routing header. Checking for a routing header is a simple stateless operation and the network is free to set limits on how much DPI it's willing to do to find the routing header.
>>
>>
>> Please point me at a definitive normative statement in existing RFC that give me the assurance that a SRv6 packet will and MUST ALWAYS carry a SRH and anything else MUST never be processed as SRv6. if that's the case and we can strictly make that a normative RFC, yes, I start to feel more sympathetic towards your arguments.  Even then, you ask us to built a firewall processing IPv6 header very deeply on every device on every packet. There is a good reason why you see most of internet  not even letting EH stuff through ...
> 
> RFC8754 gives the normative requirements for how to do segment routing
> with SRH and I believe there is a similar definition for MPLS. Can you
> point me to the RFC with the  normative requirements and also the
> motivation for how to segment routing without any sort of routing
> header?
> 
> Thanks,
> Tom
> 
>>
>> Things would have been easy and make sense, loose source routing option in IP packets would have been on the chips/working last 20 years and frankly, most real-life use cases claimed for SR I see on real networks could be solved with 1 or 2 addresses in such option all I've seen ...
> 
>>
>> thanks
>>
>>
>> --- tony
>>
>>>
>>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------