Thanks for your answers. See some comments after your answers, prefixed with [AFT].
From: Ron Bonica <rbonica@xxxxxxxxxxx>
Sent: dimanche 6 avril 2025 01:32
To: int-dir@xxxxxxxx; Antoine Fressancourt <antoine@aft.network>
Cc: draft-ietf-6man-vpn-dest-opt.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: Intdir telechat review of draft-ietf-6man-vpn-dest-opt-04
Thanks for reviewing the document. Responses inline [RB].
Juniper Business Use Only
[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.
[AFT] I think the editorial change makes the text clearer, and addresses my comment. Thanks !
- 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!
[AFT] Indeed, ESP is mentioned 4 times, I agree. The reason for my comment is that I would have listed it in the first dotted list in section 4. In the current document, it contains 3 items (IPv6 header, optional IPv6 AH and IPv6 Destination
Options). I would have added ESP to that list (Sorry if it is a bit nit-picking, feel free to ignore if you think it is not relevant).
[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?
[AFT] Sorry, I was not clear enough in the first place. If we consider an edge node N in a limited domain, it may have outbound interfaces to other nodes within the limited domain and to the outside. (If we consider a relatively small deployment,
it is common that some edge routers are not dedicated to operating outbound traffic). Then My remark would be to specify that your filtering of the Destination Option should only be done at the interfaces to the outside, not at the interface to the limited
domain. In the draft’s text, in my perspective, the filtering policy should be attributed to the egress interfaces rather than to the edge node to be clearer.
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.
[AFT] OK, In my remark, I had something like the SCIONLab testbed in mind (https://scied.scion-architecture.net/scionlab-network-testbed/)
