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. "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 ;-) "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 1. Secure the network edges so that packets cannot enter the network and join the tunnel mid-way 2. Use end-to-end security on the tunnel "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. Ron - nit. Section 7 s/fo/of/ Cheers, Adrian From: Ron Bonica <[email protected]> Sent: 04 February 2025 17:37 To: [email protected]; Linda Dunbar <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: [IPv6]Re: Genart last call review of draft-ietf-6man-vpn-dest-opt-01 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. 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 <[email protected]> Sent: Tuesday, February 4, 2025 12:14 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Genart last call review of draft-ietf-6man-vpn-dest-opt-01 [External Email. Be cautious of content] Reviewer: Linda Dunbar Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__; !!NEt6yMaO-gk!BLykpJutCCzxKiIZjeHVdoB338VQZhpLkmdB5B4S_VdshlvRcmCmLJElE3_jeg Ow0G6IKgyNWQDToPU$ >. Document: draft-ietf-6man-vpn-dest-opt-01 Reviewer: Linda Dunbar Review Date: 2025-02-04 IETF LC End Date: 2025-02-04 IESG Telechat date: Not scheduled for a telechat Summary: the document proposes an experiment to encode VPN service information within an IPv6 Destination Option to facilitate VPN deployments Major issues: - IPv6 Destination Options are typically meant for end-host processing, not for PE routers. Many IPv6 deployments drop packets with extension headers, particularly in transit networks. The draft assumes that ingress and egress PE routers will process the VPN Service Option, but if intermediate routers drop these packets, the approach may fail in real-world deployments. - There is a security risk of VPN boundaries being breached if an attacker injects a packet with a forged VPN Service Option. - The document does not clearly explain why this approach is preferable to SRv6 or MPLS-over-IPv6 Minor issues: Nits/editorial comments: Best Regards, Linda Dunbar
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
