|
Antoine,
Thanks for reviewing the document. Responses inline [RB].
Ron
Juniper Business Use Only
From: Antoine Fressancourt via Datatracker
Sent: Friday, April 4, 2025 7:19 AM To: int-dir@xxxxxxxx Cc: draft-ietf-6man-vpn-dest-opt.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx Subject: Intdir telechat review of draft-ietf-6man-vpn-dest-opt-04 [External Email. Be cautious of content]
Document: draft-ietf-6man-vpn-dest-opt Title: The IPv6 VPN Service Destination Option Reviewer: Antoine Fressancourt Review result: Ready with Nits 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://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!CAQGbATJFHtDnpYLrPCgQdyKUse8ht3qRcisUHsTcdaUNwHkCNIWtkYrk5mP5X0ZqwXSvPz3sXpG-dk$ <https://urldefense.com/v3/__https://datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!CAQGbATJFHtDnpYLrPCgQdyKUse8ht3qRcisUHsTcdaUNwHkCNIWtkYrk5mP5X0ZqwXSvPz3sXpG-dk$ >. 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. [RB] I have just posted a new version that clarifies the issue. Please tell me if it addresses your concerns.
- 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. [RB] The ESP can be used. It is mentioned four times in the draft!
[RB} In fact, an operator who is concerned with traffic analysis needs data encryption as well as data authentication. That user SHOULD use the ESP.
[RB] However, for the purposes of this experiment, the operator may use data authentication to secure the limited domain. They may also use ACL's. But for the purposes of the experiment,
encryption isn't required.
[RB] If this experiment succeeds and we post a standards track document, we will certainly add ESP details.
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. [RB] I'm not sure that I understand the question. Could you clarify?
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. [RB] Sorry, no such testbed exists.
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
