Ballot for draft-ietf-6man-vpn-dest-opt
Discuss
Yes
No Objection
Abstain
No Record
Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Thanks so much for putting this document together and for clearly laying out the intent behind it. I appreciate the effort to capture experimental work, it's always valuable to explore new approaches and understand how they might complement or improve upon existing solutions. That said, after reviewing the draft, I’ve decided to ballot a DISCUSS, based on two specific observations. I also want to express support for the technical concerns raised by Ketan and Med, which I believe are valid and worth addressing. At a high level, this proposal does seem to outline a mechanism capable of transporting payloads from one domain to another across a backbone (such as the Internet or another independent domain). From a conceptual standpoint, I don’t see any technical flaws that would prevent this from working as an experiment. However, I do have a blocking concern that the document gives the impression that VPNs are exclusively MPLS-based (DISCUSS-1), and it fails to acknowledge other existing IP-based VPN technologies (DISCUSS-2). This leads to two specific DISCUSS points: DISCUSS-1: The introduction seems to suggest that IPv6-based VPN solutions must use an MPLS data plane. This overlooks the fact that both MPLS and SRv6 are capable of supporting VPNs. The document would benefit from referencing Segment Routing over IPv6 (SRv6) Network Programming (RFC 8986), and better positioning the proposed IPv6 VPN Service Destination Option in relation to existing SRv6-based VPN solutions. I realized that similar observation was made by Sue Hares OPS-DIR review. It might not be a beauty contest, as Adrian noted in his response to the OPS-DIR review, but adding some context about where this solution applies, and how it compares to alternative approaches, would really help readers/implementors to better understand the relevance and potential value of the experiment outcome on a future standard track procedure. DISCUSS-2: There are several IP-based VPN solutions, particularly in the data center space. It would be useful to acknowledge these existing technologies. A helpful reference here is RFC 9638 ("Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations"), which offers a good comparison of technologies in this area. Including such a comparison, or at least recognizing the existence of these alternatives, would provide better context for the proposed solution. Once these DISCUSS items are addressed, I’d be happy to update my ballot to Abstain rather than No Objection. I’m choosing to abstain because I’m not yet fully convinced of the added value this experiment brings compared to existing, well-established solutions. That said, from a conceptual standpoint, the proposal seems sound and I don’t see any major issues that would prevent it from functioning as described, so I have no intention of blocking its progress. I’m definitely open to further discussion and look forward to seeing how the document continues to develop Thanks again for the work on this. Gunter Van de Velde RTG Area Director
Thanks for the work on this document, there are a few points that I would like to discuss to help bring more clarity and improve this document (some use idnits output of v05 as a reference): <discuss-1> Having read the document, the objective of the experiment is not clear to me. I would have expected that something new that needs experimentation would be enabling new use-cases, improving some operational aspects, improving scaling/performance, enabling deployment of new services with the use of IPv6 (given this is from 6man WG), etc. However, the document's motivation for experimenting is to mainly demonstrate that the solution is implementable and deployable. Some text describing the purpose behind the need for publishing this experiment and asking the community to perform/participate in this experiment in view of existing IETF standards based solutions (see below) would be helpful. A brief overview of existing IETF standards based solutions for deploying VPN with IPv6: a) The first are BGP based MPLS VPN solutions (L3VPN, L2VPN, EVPN) that work within a service provider network using IPv6 infrastructure. These solutions are based on MPLS encapsulation over IPv6 (next header type set to 137) as the data plane. The packet is very similar except that top-level MPLS label (immediately following the IPv6 packet instead of a DOH) conveys the VPN context and is followed by the VPN payload. It leverages the existing MPLS control plane (e.g., BGP). Exactly the same as described in section 4 and section 5. It also provides exactly the same 20 bits for the VPN context in the form of MPLS label instead of the new destination option. More importantly, this solution has decades worth of deployment and operational experience along with a well understood security model. b) The second is classic IPSec VPN solution that works over the IPv6 Internet. The VPN context is encoded in the IPSec parameters and security model (AH, ESP, etc.) is well understood. This works also works within a service provider network. This too has long deployment and operational experience. <discuss-2> Going over the security considerations, the security model is ambiguous. It talks about limited domains as well Internet deployments. It is not clear about the prerequisites (those that are mandatory) for each of those deployments using normative language. There also exist some contradicting statements that straddle these two models (see comments below). Without this clarity, it is hard to evaluate whether the security analysis has been completed. This is especially important given the existence of solutions (see above) that have well-known security models. <disuss-3> The security considerations has the following text: 311 The mitigation techniques mentioned above also address the tunneling 312 concerns raised in [RFC6169]. Could you please clarify in a little more details on this? Perhaps a couple of examples of the tunneling concerns and how they are addressed in the security considerations of this document?
Following are some comments and suggestions provided inline in the idnits output of v05: 127 The mechanism described above requires both PE devices (ingress and 128 egress) to support MPLS. It cannot be deployed where one or both of 129 the PEs does not support MPLS. <major> Section 5 talks about using LFIB and other signaling elements from MPLS. In Section 3, the encoding proposal uses exactly the 20 bits in the option field for carrying the service context - exactly same as an MPLS label. In light of this, I find the above sentence confusing. To me, it looks like MPLS support is required for this solution as well. 131 This document describes an experiment in which VPN service 132 information for both layer 2 and layer 3 VPNs is encoded in a new 133 IPv6 Destination Option [RFC8200] called the VPN Service Option. <minor> Is this document describing an actual experiment that was carried out, or does it describe a recipe for an experiment that the IETF (by means of publication of this document) is asking people to carry out? 137 One purpose of this experiment is to demonstrate that the VPN Service 138 Option can be implemented and deployed in a production network. 139 Another purpose is to demonstrate that the security considerations, 140 described in this document, are sufficient to protect use of the VPN 141 Service Option. Experimenters should report any security flaws that 142 they discover. Finally, this document encourages replication of the 143 experiment, so that operational issues can be discovered. <major> What is meant by "replication of the experiment"? Is the document suggesting that people find out all sorts of problem spaces and try to see if IPv6 Dest Options can be used to address them? Or is the document asking implementers (and operators) to carry out this specific experiment related to the VPN Dest Options. I presume, it is the latter, but I find the "replication" part confusing since the document does not document the details of an actual experiment that was carried out, its implementation details, etc. 174 - Low-order 20 bits: Identifies a FIB entry on the egress PE. 175 The FIB entry determines how the egress PE will forward 176 customer data to a CE device. <minor> The choice of this 20 bit encoding is obvious that this is identical to an MPLS label. Is the idea to leverage the existing MPLS implementation support on the devices for this new proposal? If so, would be good to call it out up front in the introduction. 178 The VPN Service Option MAY appear in a Destination Options header 179 that precedes an upper-layer header. It MUST NOT appear in any other 180 extension header. If a receiver finds the VPN Service option in <major> Does this mean to say that the VPN Service Option cannot be used in the HBH or the Dest options that are place before the RH? Or something else? 269 If the FIB is populated using BGP, BGP creates a Label-FIB (LFIB), 270 exactly as it would if VPN service information were encoded in an 271 MPLS service label. The egress PE queries the LFIB to resolve 272 information contained by the VPN Service Option. <minor> Is the idea to leverage the existing MPLS implementation support on the devices for this new proposal? If so, would be good to call it out up front in the introduction. 278 However, if the experiment described herein succeeds, the authors 279 will reissue this document, to be published on the Standards Track. 280 The reissued document will request an IPv6 Destination Option number, 281 and contain operational recommendations reguarding a migration to a 282 new code point. <major> I think the above text is premature and not something relevant that IANA can take an action on. Suggest to take out the above paragraph. 284 7. Security Considerations 286 IETF VPN technologies assume that PE devices trust one another. If <major> Can you provide a reference for this claim? Is it specific to MPLS VPN deployments that are within a service provider domain or VPNs (like IPSec/SSL) that work over the Internet? 290 The following are acceptable methods of risk mitigation: <major> As mentioned in one of my DISCUSS points, it would help to list and describe the models first and then each of their security analysis. Given that there are existing solutions with well known security properties, this new experiment should be expected to have performed more robust analysis. 307 The mitigation techniques mentioned above operate in fail-open mode. 308 See Section 3 of [I-D.wkumari-intarea-safe-limited-domains] for a 309 discussion of fail-open and fail-closed modes. <minor> The reference is not an IETF WG document. Given that the reliance is only on the definition of the term "fail-open", perhaps that text can be borrowed and placed inline in this document with attribution to that document's authors. 316 The VPN Service Option is imposed by an ingress PE and processed by 317 an egress PE. It is not processed by any nodes along the delivery 318 path between the ingress PE and egress PE. So, it is safe to deploy 319 the VPN Service Option across the Internet. <major> Looking at the security considerations above, does this claim of "safe to deploy ... across the Internet" require some qualification? 338 9. Experimental Results <major> Are the authors (or anyone in the WG) aware of any actual running code that has been developed (or is being developed) as part of this experiment. If so, it would be good to share the experience so far for the benefit of the community. 340 Parties participating in this experiment should publish experimental 341 results within one year of the publication of this document. 342 Experimental results should address the following: <EoR v05>
# Éric Vyncke, INT AD, comments for draft-ietf-6man-vpn-dest-opt-05 CC @evyncke Thank you for the work put into this document. I am balloting a DISCUSS to address some important points, and I intend to ballot ABSTAIN once the DISCUSS is cleared (in line with Mohamed Boucadair's ballot). Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Bob Hinden for the shepherd's write-up including the WG consensus *but it lacks* the justification of the intended status. Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-6man-vpn-dest-opt-04-intdir-telechat-fressancourt-2025-04-04/ (and I have read Ron's replies) I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Abstract As the I-D reuse (rightfully) the existing experimental code point, there is no `The new IPv6 Destination Option`. Please be specific that the I-D re-uses the experimental code point. ### Section 1 Even for an experimental status, I would assume something more descriptive than `Experimenters should report any security flaws that they discover.` what kind of security test ? I also usually think that security flaw are discovered by protocol analysis rather than experimentation. ### Section 4 It appears that this document only allows for AH/ESP (and DO) extension headers. This prevents fragmentation and routing headers. Please add some text why fragmentation header is forbidden. Please justify why routing header (e.g., CRH or draft-pb-6man-deterministic-crh-01 ;-) ) cannot be combined with this experiment ?
## COMMENTS (non-blocking) ### Section 1 Please be clear in `It then searches its FIB for an entry that matches the incoming service label` as it assumes that MPLS is used (i.e., make sure that `A popular tunnel technology` applies to both bullets). `The egress PE removes the tunnel header, exposing the customer data.` isn't the first step to look at the FIB before decapsulation? It is unclear what scope is `production network` ? It is a single provider network ? the global Internet (like popular SD-WAN products) ? ### Section 3 Please add a justification for the length of option data of 20 bits. It smells a lot like an MPLS label of course. ### Section 4 Should RFC 6724 be mentioned when describing the source/destination address fields ? ### Section 6 Please move the 2nd paragraph in the introduction.
1. Section 9 does not explain how to clean-up after the experiment. Section 1.1 of RFC 3692 includes text that I thought was helpful, and I’m surprised that this text (preferably quoted as-is) did not appear in this document’s deployment section. When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. 2. The text in section 8 only seems to assume “care” about potentially overlapping use. I recognise that the experimental numbers are not guaranteed to be unique in any environment, however could this format include a prefix that could help distinguish this experiment from other uses. For example, I’m curious why the option does not include an identifier to associate it with the closed domain in which it is intended to operate? That might reduce the potential for accidental misinterpretation if a packet was forwarded to another closed domain. Even a short randomly chosen identifier could help reduce any confusion if this same code point was to be used by another experimental option (or perhaps more significantly were to remain deployed at the end of the experiment). 4. Please could you fix the following NiTs: /OAM mechanism/OAM mechanisms/ /If VPN Service option/If the VPN Service option/ /Was there a need to synchronize configurations at each node or could nodes be configured independently/ please add a question mark. --- Note my previous discuss concerned rev -03: This EXP specification seeks to place normative requirements on configuring nodes, but is very general as to where the option configuration needs to be applied. The document said: It MUST NOT appear in any other extension header. If VPN Service option appears in another extension header, the receiver MUST discard the packet. This adds a requirement to drop a packet if the new option appears in a HBH EH, whereas the processing defined in RFC 9673 would skip this option if present in a HBH EH, and therefore would require explicit configuration to drop this packet. Can the rule for the HBH EH be to ignore this option?
Inspired by the concepts in outlined in Section 2 of draft-bonica-gendispatch-exp: what exactly are the success criteria for the experiment outlined in this document? ** Section 3. - High-order 12 bits: Reserved. SHOULD be set to 0 by the sender and MUST be ignored by the receiver. Under what circumstances would these bits NOT be set to zero?
Hi Ron, Xing, Adrian, Yuji, and Luay, Thank you for the work put into this specification. Also, thanks to Susan Hares for the OPSDIR review and to Adrian for the prompt reply. Let me first insist that I’m supportive of nurturing experiments and iterate in our process. Also, I understand that an experiment does not need to cover every aspect of a solution and that a goal of an experiment is to feed that tweaking process. I won’t thus complain that the control plane considerations (which are key here) are under-specified. So, you have my sympathy for the approach being proposed here. That’s said, I’m not comfortable with the experiment as set, for various reasons: * It does not solve an operator problem (at least, what I’m aware of) * It does not introduce a unique feature to the already-saturated VPN solution space + I won’t enumerate all the technologies we do already have out there. The authors are very familiar with this + It is not clear what is the value of this approach and what does it bring in term of innovation * The experiment is too generic and can be applied to any IPv6 dst option. + The pattern used in the spec can be generalized to any similar option independent of the information it carries. Really. * We don’t need to coin an RFC to run another experiment to see how IPv6 dst options are handled on the Internet. * The technical foundations are questionable. For example, + The base spec RFC2473 was removed from the IPv6 node requirements (was used to be cited in RFC4294 but removed from RFC6434/RFC8504). Support by routers is thus not given. + I’m aware of deployments based on RFC2473 but mainly for establishing individual tunnels (DS-lite, for example), though. + We don’t have evidence that there are current deployments where RFC2473 is used as an underly tunnel protocol for VPN purposes or whether there are operators asking for this. - Adding an EH is a matter of details, but the core question is elsewhere. - BTW, I failed to find records where OPS area was solicited for feedback for this matter early in the process. It is too late to have that as this stage, though. * The solution is not reliable as it depends on on-path devices behavior (e.g., discard packets with such option). + An operator cannot rely on such solutions to deliver VPN services, especially that strict commitments are usually associated with such service offerings. + Given that dependency, deployability is really a concern. This specific experiment won’t change how IPv6 EH are handled on the Internet. Note that the document has this right (even if this can be seen as an internal inconsistency) as it says that "it is safe to deploy the VPN Service Option across the Internet" and then "However, some networks discard packets that include IPv6 Destination Options. This is an impediment to deployment". I’m not balloting DISCUSS because I’m afraid that changes to the document won’t help me reconsider my position. For all these reasons, I’m balloting ABSTAIN as I don’t think it is good idea to publish this document in the IETF stream. Cheers, Med
After dicsussion with authors, I realized that I don't think we are on a converging path. While I don't believe this document is actively harmul, like Med I am also not convinced of its use cases. Additionally, I find the naming to be too misleading. I have updated my DISCUSS to an ABSTAIN.