[SRv6OPS] Re: [spring] Second WG Last Call: draft-ietf-spring-srv6-security-14 (Ends 2026-06-02)

[Mikael Abrahamsson <[e-mail]>]

I'm aware that I'm late to the game here so I am not going to oppose the 
LC of this draft, but I would say it's a missed opportunity to not give 
clear guidance to users and vendors of SRv6 enabled equipment to put in 
two very strong recommendations/requirements:

1. Put your customers in VRFs.

2. Vendor must make sure that packets sent to SIDs on interfaces that are 
in a VRF, should not be processed as SRv6 packets.

The whole focus on users implementing filtering to protect the SRv6 domain 
is operationally fragile. To me it's surprising this is still the main 
recommendation.

For MPLS, there was a knob one enabled on the interface to "enable MPLS 
frame processing". Without it, MPLS frames are supposed to be dropped. 
SRv6 has, as far as I can tell, no such thing. Instead the operator is 
supposed to make sure there are ACLs on each and every interface where 
SRv6 packets aren't expected.

I would never ever ever deploy SRv6 without first making sure that all 
non-SRv6 interfaces were in a VRF, and verify that the vendor equipment 
didn't process SRv6 packets received on a VRF enabled interface.

-- 
Mikael Abrahamsson    email: [e-mail]