Telechat Review of draft-ietf-6man-vpn-dest-opt-04
review-ietf-6man-vpn-dest-opt-04-intdir-telechat-fressancourt-2025-04-04-00

I am an assigned INT directorate reviewer for
<draft-ietf-6man-vpn-dest-opt-04.txt>. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, the document is _nearly_ ready to go to IETF Last Call and
therefore can be forwarded to the IESG.

Overall, the document is clear. The description of the VPN Service option is
consistent with RFC 8200 from what I can judge, and the formatting of the
option respect the formatting boundaries stated for destination options.

I have three remarks regarding the formatting of the IPv6 packet containing
this option and its interpretation:
        - In section 3, it is mentioned that the low order 20 bits of the
        Option data are used to identify the outgoing interface or a
        VPN-specific portion of the FIB that will be used to identify the
        outgoing interface. I wonder whether this should be clarified, and
        whether a flag of some sort could be used to determine whether the 20
        bits identify an interface directly or a FIB portion. - In Section 4,
        the ESP header is mentioned at the end of the section but it is not
        listed among the optional headers to be included at the beginning of
        the section, which is a bit astonishing. It is even more astonishing
        since ESP is clearly mentioned in Section 7. Besides, I am wondering
        why the use of ESP is not encouraged, given that my assumption for a
        tunneling technology would be that the content of the tunnel is hidden
        or encrypted from the outside. - In my understanding, the end of
        section 4 describes the Destination Options extension header of the
        outer IPv6 packet carrying the tunneled packet. Thus, I am wondering
        why the authors mention that the Next Header field must identify the
        protocol of the customer data and not the fact that the payload carries
        an IPv6 packet, thus using value 41 as mentioned in RFC 2473.

The following are other issues I found with this document that SHOULD be
corrected before publication:
        - In Section 7, the sentence describing the behavior of edge nodes with
        regards to the filtering of the VPN Service option is unclear (at least
        for me). For instance, I would mention that the packet are discarded if
        they are bound to exit the edge node through an interface exiting the
        limited domain.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:
        - Throughout Section 9, I was left wondering whether an open testbed is
        already available, against which potential experimenters could test
        their implementation. If such a testbed exists, I would reference it.