|
Adrian and Ron, Thank you very much for the quick responses.
Please see my additional comments and some questions inserted below:
Linda From: Adrian Farrel <adrian@xxxxxxxxxxxx>
I concur with Ron while partly agreeing with Linda. “IPv6 Destination Options are typically meant for end-host processing” Exactly! And in a VPN tunnel, the end-host is the end of the tunnel: the node identified by the packet’s destination address. This may very well (erm, nearly always?) be a PE in the case of VPN tunnels. [Linda] Do you assume that the network between ingress and egress is VPN network? if not, the IPv6 packet with the VPN Service Option would be forwarded hop-by-hop as regular IPv6
traffic. Correct? “Many IPv6 deployments drop packets with extension headers, particularly in transit
networks.” Indeed, and if they do this (and everything else that uses extension headers) will fail. I guess that includes SRv6 ;-) [Linda] The key difference is that SRv6 typically operates within SRv6-enabled networks, which have seen significant industry adoption, and operators have adapted to ensure its
usability. However, the same cannot necessarily be said for all use cases, including this proposed VPN Service Option. Have you considered mitigations or operational guidance to address the known deployment challenges caused by extension header filtering in
transit networks? “There is a security risk of VPN boundaries being breached if an attacker injects
a packet with a forged VPN Service Option.” It’s almost as if the Security Considerations section should discuss this. Oh, wait! The challenge of “tunnel security” is fundamental to all VPN deployments regardless of technology. The key solution has been two-fold
[Linda] I understand that tunnel security is a general VPN concern, but my point is about whether the specific risk of injecting a forged VPN Service Option is sufficiently mitigated
in this proposal. The security considerations mention AH and ESP, but are these mandatory, and what happens in deployments where they are not enforced? Could we clarify this in the document? “The document does not clearly explain why this approach is preferable to SRv6 or MPLS-over-IPv6” Well, I think the second approach is covered by the note that the MPLS-based mechanism ‘cannot be deployed where one or both of the PEs does not support MPLS.’ That might not be the case with
modern PE routers, but is likely to be the case with server-based PE implementations (such as virtual routers in a DC). As to compare and contrast with SRv6: I refuse to get drawn into a beauty contest. But by making this draft Experimental, we allow for the possibility that no one will like this idea and it will
not see any experimental results. [Linda] Since SRv6 has been widely adopted, readers should understand why this approach exists alongside SRv6 rather than just stating it as an alternative. Can the document provide
an objective comparison highlighting trade-offs in terms of scalability, operational complexity, and interoperability? Ron – nit. Section 7 s/fo/of/ Cheers, Adrian From: Ron Bonica <rbonica=40juniper.net@xxxxxxxxxxxxxx>
Linda, I think that you are assuming the PE's are always routers. They can be hosts that support VPN. In fact, this is the most likely use-case. These days, most routers support MPLS. So, MPLS VPNs suffice. There is no need for an alternative forwarding plane. The only case where you need an alternative forwarding plane is when the PE is a server that doesn't support MPLS. [Linda] I am actually asking if the network to the End Host is VPN? Or plain IPv6? Also, the Destination Options Header is least likely to be dropped by an intervening network. If we were to follow the reasoning that you present below, we would have to deprecate
all extension headers. Ron Juniper Business Use Only From: Linda Dunbar via Datatracker <noreply@xxxxxxxx> [External Email. Be cautious of content] |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
