The IPv6 VPN Service Destination Option
draft-ietf-6man-vpn-dest-opt-11

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-6man-vpn-dest-opt and RFC 9837, changed IESG state to RFC Published)

[Ballot comment]
I would like to thank the authors for engaging in discussions as we worked on bringing more clarity to the document and framing the experiment in an appropriate context. I hope this has improved the document.

One of the key purpose of my discussion was to ascertain the unique proposition or innovation of this experiment that is beyond the bits and bytes of the packet header. I have been unable to identify any such key benefits or advantages over existing VPN technologies both from a feature capabilities or operational aspects.

Given that this document is on an experimental track where the bar is lower (as compared to standards track), I am changing my ballot to Abstain.

I also agree with most of what Med has conveyed in his Abstain comments.

[Ballot comment]
Thanks for addressing my previous DISCUSS and COMMENTS. See:
https://mailarchive.ietf.org/arch/msg/ipv6/svN9H-NuO4BQ5hYx7GQdZ2ssZn0/

I am balloting an ABSTAIN because while the document is technically sound, I cannot refrain from wondering whether the IETF and the industry need yet another VPN technology. Of course, running an experiment is always nice.

[Ballot comment]
[I accidently set a wrong ballot and am correcting this now]

Many thanks for resolving my DISCUSS items.
(DISCUSS comments: https://mailarchive.ietf.org/arch/msg/ipv6/cp-mlQZyo68v17FF5SdH63Wg7R4/ )

My ballot is 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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
I am a bit confused on what this option does and how it supports some VPN Technologies.

The FIB is an identifier, presumably an index of a certain source/dest network pair?
What is the data content of these IPv6 packets?
How are encryption/integrity keys negotiated ?
Why is this needed when there is another protocol negotiating those keys (and / or encapsulation
an encryption of packets or data) ?

I see mention of Authentication Header (AH), but that does not support encryption, only
integrity. So I do not understand why that is in scope for a VPN document.

In short, I understand this is an option that somehow indicates "this is a packet (or data?)
that should be send via a "vpn tunnel" to elsewhere. But does this IPv6 packet contain an inner
packet? An encrypted inner packet? Will it get encrypted based on this VPN Service Option?

Why and when should someone use this option? Would it replace or augment an IPsec VPN? A MacSEC VPN?

My apologies if this is the result of me not being very familiar with this layer of the stack.

[Ballot discuss]
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

[Ballot discuss]
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):

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.


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.

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?

[Ballot comment]
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.

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.

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.

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.

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

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.

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.

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

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:

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.

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.

Looking at the security considerations above, does this claim of
"safe to deploy ... across the Internet" require some qualification?


338 9.  Experimental Results

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:

[Ballot discuss]

# É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 ?

[Ballot comment]

## 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.

[Ballot comment]
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

[Ballot comment]
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 brings 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 run an experiment to see how IPv6 dst options are handled on the Internet.

* The technical foundation 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. The experiment won’t change how IPv6 EH are handled on the Internet. The document has this right (even of this can be seen as an internal inconsistency) as it says that "So, 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

[Ballot comment]
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?

[Ballot discuss]
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.

1.: The document says:

  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?

2. I understand the intent is to specify a new DO for use by a router at the PE edge. However, I cannot tell from the text whether this experiment is also scoped to require filtering of destination options that are processed by the final destination of the packet (host) (see Section 4.1., Note 2) of RFC 8200. This does not seem to be quite what was intended.

3. Section 7 assumes that the only processing of this option is by an egress PE device. It says “It cannot be deployed where one or both of the PEs does not support MPLS.”  Would scoping the receiver processing rules only to egress PE devices reduce the deployment challenges in using an experimental number?

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-vpn-dest-opt-01, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-02-04):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-vpn-dest-opt@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The IPv6 VPN Service Destination Option) to Experimental RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'The IPv6 VPN Service Destination Option'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes an experiment in which VPN service
  information for both layer 2 and layer 3 VPNs is encoded in a new
  IPv6 Destination Option.  The new IPv6 Destination Option is called
  the VPN Service Option.

  One purpose of this experiment is to demonstrate that the VPN Service
  Option can be implemented and deployed in a production network.
  Another purpose is to demonstrate that the security considerations,
  described in this document, have been sufficiently addressed.
  Finally, this document encourages replication of the experiment.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-vpn-dest-opt/



No IPR declarations have been submitted directly on this I-D.

# Internet AD comments for draft-ietf-6man-vpn-dest-opt-01
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

### S6

* "The reissued document will request an IPv6 Destination Option number."

  How about appending something like ", and contain operational
  recommendations for how an operator can undertake a migration to a new
  code point."

  I think the greatest risk, if this experiment is successful, is that
  migrating off the EXP code point will be prohibitively expensive
  (operationally).

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

The IPv6 VPN Service Destination Option
draft-ietf-6man-vpn-dest-opt
Intended status: Experimental
8 November 2024

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

There has been active discussion since June 2018. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Current draft has support for it's intended status, that is,
Experimental.

Reviews were done by Eliot Lear and Mark Smith.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No current implementations.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is good.  I am very pleased with Section 9 "Experimental
Results" that describes the measuring and evaluating the results of the
experiment.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.  This is noted in the header and in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, all authors confirmed that they are not aware of any IPR on this
document.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all five authors who have confirmed willingness to be an author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

IDNITS is clean.  There are three warnings that aren't relavant.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are RFCs and IDs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document does not make any IANA requests.

However, if the experiment is successful, the authors
will reissue this document, to be published on the Standards Track.
The reissued document will request an IPv6 Destination Option number.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

The IPv6 VPN Service Destination Option
draft-ietf-6man-vpn-dest-opt
Intended status: Experimental
8 November 2024

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad
  agreement?

There has been active discussion since June 2018. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Current draft has support for it's intended status, that is,
Experimental.

Reviews were done by Eliot Lear and Mark Smith.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No current implementations.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is good.  I am very pleased with Section 9 "Experimental
Results" that describes the measuring and evaluating the results of the
experiment.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Experimental.  This is noted in the header and in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, all authors confirmed that they are not aware of any IPR on this
document.


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all five authors who have confirmed willingness to be an author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

IDNITS is clean.  There are three warnings that aren't relavant.


15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References reasonable.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are RFCs and IDs.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document does not make any IANA requests.

However, if the experiment is successful, the authors
will reissue this document, to be published on the Standards Track.
The reissued document will request an IPv6 Destination Option number.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/