On Wed, 5 Feb 2025, 04:40 Ron Bonica, <rbonica=40juniper....@dmarc.ietf.org>
wrote:
> Linda,
>
> I think that you are assuming the PE's are always routers. They can be
> hosts that support VPN.
>
Going by IPv6's definitions of routers and hosts,
router a node that forwards IPv6 packets not explicitly
addressed to itself.
host any node that is not a router.
routers as *devices* perform both host processing and router processing
(forwarding) of packets. The IPv6 definitions are really functional
definitions.
The host processing of packets occurs whenever packets are received by the
router (device) when the destination address in the packet matches any
address that has been explicitly assigned to the router (device).
Processing of tunnel packets at the tunnel end-point is host processing,
with the tunnel "application" being the implemention of a virtual link.
So a Destination Option is the correct type of option to instruct the host
processing of tunnel packets at the tunnel destination end point.
Regards,
Mark.
> 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 <nore...@ietf.org>
> *Sent:* Tuesday, February 4, 2025 12:14 PM
> *To:* gen-art@ietf.org <gen-art@ietf.org>
> *Cc:* draft-ietf-6man-vpn-dest-opt....@ietf.org <
> draft-ietf-6man-vpn-dest-opt....@ietf.org>; i...@ietf.org <i...@ietf.org>;
> last-c...@ietf.org <last-c...@ietf.org>
> *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_jegOw0G6IKgyNWQDToPU$
> >.
>
> 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
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> i...@ietf.org
> List Info: https://mailman3.ietf.org/mailman3/lists/i...@ietf.org/
> --------------------------------------------------------------------
>
_______________________________________________
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
