All switches within the limited domain also need to be upgraded (as Brian
noted) since they would drop frames received with the new ethertype by
default..
Now, the only normative statement I find in the draft is:
<excerpt>
6.2. Transit and egress routers
A router configured to process TD-SRv6 MUST drop packets containing
an SRH if received on any ethertype except srv6-td.
</excerpt>
That does not cover what the transit router needs to do when it receives a
packet with the new ethertype on an (internal) interface enabled for the
new ethertype and forwards it out an (internal) interface enabled for the
new ethertype. I think something like the foll. also needs to be added:
A transit router receiving a packet with the new ethertype on an interface
enabled for processing the new ethertype and forwarding it on an interface
enabled for the new thertype MUST forward the packet with the new ethertype.
Just curious, the new ethertype is essentially an indication that the
packet was already inspected by the (ingress) edge router and is safe to
process without having to apply complex IPv6 rules on transit/egress
routers, right? Why can't it be generalized for any packet sent inside an
IPv6 tunnel b/w edge routers i.e. define a ipv6-td (instead of srv6-td)
ethertype? Or is only SRH considered an evil extension header for the
Internet? :)
Regards,
Muthu
On Thu, Mar 30, 2023 at 9:58 AM Joel Halpern <j...@joelhalpern.com> wrote:
> Not quite, but close.
>
> Routers which are not upgraded, and receive packets with the new
> ethertype, will drop them. Which theoretically is fine for routers which
> are not intended to be on SRv6 paths. Practically, since you want to be
> able to run the paths where you need them, you probably do need to upgrade
> all routers to accept and propagate the new ethertype if you want to use
> this solution. For some operators, that is a show stopper and they will
> not use this capabilities. For others, it is quite deployable, and even
> helpful in keeping control of what servicces are offered where.
>
> Yours,
>
> Joel
> On 3/29/2023 12:00 PM, Muthu Arul Mozhi Perumal wrote:
>
> So, using the new ethertype inside a (closed/open) domain would require
> all IPv6 routers inside the domain to support SRv6 or at least support the
> new ethertype to check if any IPv6 packet containing an SRH was received
> with this ethertype? If an IPv6 router supports neither, then one cannot
> enable this feature on any of its neighbor's interface, right?
>
> Regards,
> Muthu
>
> On Wed, Mar 29, 2023 at 5:40 PM Robert Raszuk <rob...@raszuk.net> wrote:
>
>> Nope, that is completely not what I have in mind,
>>
>> Please remember that transit nodes are not SRv6 aware in closed or open
>> domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink to
>> my MEC or private DC where services are being properly demuxed based on the
>> SID/uSID.
>>
>> If you close this date plane option by new ethertype my car is
>> disconnected,
>>
>> So I am not sure who is "incredibly naive" here or perhaps to put it a
>> bit more politely who does not understand the power of new technology.
>>
>> Regards,
>> R.
>>
>>
>> On Wed, Mar 29, 2023 at 5:02 AM Mark Smith <markzzzsm...@gmail.com>
>> wrote:
>>
>>> On Wed, 29 Mar 2023 at 22:46, Robert Raszuk <rob...@raszuk.net> wrote:
>>> >
>>> > Guys,
>>> >
>>> > What you are really saying here is that the concept of using network
>>> programmability should be killed and we should get stuck for decades to
>>> come with closed domains only innovation.
>>> >
>>> > I find it quite disturbing especially as we are talking about Internet
>>> Engineering Task Force produced standards here.
>>> >
>>> > Yes it has been derailed {not to say hijacked} into standardization of
>>> private extensions for various protocols which are limited to closed
>>> domains as the technology of new forwarding paradigm called MPLS simply by
>>> design was not applicable to be deployed in the open Internet. But that
>>> should not mean we should get stuck with this till new generation
>>> understands mistakes made and moves forward,
>>> >
>>> > It is obvious that those who invested heavily in MPLS will fight to
>>> protect it no matter what. But new technologies and services are being
>>> deployed over SRv6 using native IPv6 dataplane. Examples are mobile nodes
>>> which move from network to network.
>>> >
>>> > Is this closed domain - no by any means. Is it working today - yes
>>> pretty well.
>>> >
>>> > So proposing a new ethertype for SRv6 today seems to be comparable to
>>> putting a stick into the wheels of a cool bicycle starting to gain speed.
>>> >
>>>
>>> If you believe one network operator is going to let another network
>>> operator program the first network operator's network, then I think
>>> you're incredibly naive about how the multi-party Internet is operated
>>> and the security and availability concerns network operators have.
>>>
>>>
>>>
>>> > Respectfully to all td-srv6 authors and cheerleaders,
>>> > Robert
>>> >
>>> >
>>> > On Wed, Mar 29, 2023 at 1:58 AM Tony Przygienda <tonysi...@gmail.com>
>>> wrote:
>>> >>
>>> >> Though I would like to cheer for Kireeti's 2. as well I think the
>>> point of SHOULD is more realistic (for now) as Joel points out ...
>>> >>
>>> >> As to ethertype, I think grown-ups in the room were since long time
>>> drily observing that a new IP version would have been appropriate after
>>> enough
>>> contortions-of-it's-an-IPv6-address-sometimes-and-sometimes-not-and-sometimes-only-1/4
>>> were performed with drafts whose authors' list length sometimes rivaled
>>> pages of content ;-) I think this ship has sailed and that's why after
>>> some discussions with Andrew we went the ether type route as more
>>> realistic. Additionally, yes, lots encaps (not encodings) carrying SRv6
>>> should get new codepoints if we are really serious about trusted domains
>>> here.
>>> >>
>>> >> And folks who went the MPLS curve know that none of this is new, same
>>> curve was walked roughly (though smoother, no'one was tempted to "hide
>>> label stack in extension headers" ;-) and it would go a long way if
>>> deploying secure SRv6 becomes as simple as *not* switching on "address
>>> family srv6" on an interface until needed and then relying on BGP-LU (oops
>>> ;-) to build according lookup FIBs for SRv6 instead of going in direction
>>> of routers becoming massive wildcard matching and routing header processing
>>> firewalls ...
>>> >>
>>> >> --- tony
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Mar 29, 2023 at 4:33 PM Kireeti Kompella <
>>> kireeti.i...@gmail.com> wrote:
>>> >>>
>>> >>> On Mar 28, 2023, at 11:24, Adrian Farrel <adr...@olddog.co.uk>
>>> wrote:
>>> >>>
>>> >>> [Spring cc’ed because, well, you know, SR. I wonder whether 6man and
>>> 6ops should care as well.]
>>> >>>
>>> >>>
>>> >>> SPRING cc’ed because, you know, replying to Adrian’s email. Agree
>>> that 6man and 6ops [sh|w]ould be interested.
>>> >>>
>>> >>> tl;dr
>>> >>>
>>> >>> I think this is a good initiative and worth discussion. Thanks
>>> >>>
>>> >>> for the draft.
>>> >>>
>>> >>>
>>> >>> Agree. In particular:
>>> >>> 1. There is an acknowledged security problem. Might be worth
>>> summarizing, as it is central to this draft, but an example is in rfc
>>> 8402/section 8. Section 3 of this draft (“The SRv6 Security Problem”)
>>> doesn’t actually describe the security problem; Section 5 does, briefly.
>>> >>>
>>> >>> 2. The solution (using a new EtherType, SRv6-ET) is a good one.
>>> It’s sad that this wasn’t done from the get-go, as the solution is a bit
>>> “evil bit”-ish. I’d prefer to see ALL SRv6 packets (i.e., those containing
>>> SRH) use SRv6-ET. Boundary routers SHOULD drop packets with SRv6-ET that
>>> cross the boundary in either direction; all routers MUST drop packets with
>>> SRH that don’t have SRv6-ET. Yeah, difficult, but the added security is
>>> worth it.
>>> >>>
>>> >>> 3. Ease of secure deployment is a major consideration; this draft is
>>> a big step in that direction.
>>> >>>
>>> >>> 4. As Adrian said, several nits. Will send separately to authors.
>>> >>>
>>> >>> Kireeti
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> spring mailing list
>>> >>> spring@ietf.org
>>> >>> https://www.ietf.org/mailman/listinfo/spring
>>> >>
>>> >> _______________________________________________
>>> >> spring mailing list
>>> >> spring@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/spring
>>> >
>>> > _______________________________________________
>>> > spring mailing list
>>> > spring@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/spring
>>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>
> _______________________________________________
> Int-area mailing
> listInt-area@ietf.orghttps://www.ietf.org/mailman/listinfo/int-area
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
