I believe I disagree with the analysis below. As far as I can tell from
the draft, the destination option is included in an encapsulating
header. And is processed by the destination of that encapsulating
header. This seems to me to be a clear and valid use of the IPv6
destination option.
Yours,
Joel
On 2/4/2025 12:14 PM, Linda Dunbar via Datatracker wrote:
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://wiki.ietf.org/en/group/gen/GenArtFAQ>.
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 -- gen-art@xxxxxxxx
To unsubscribe send an email to gen-art-leave@xxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
