Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service
draft-ietf-v6ops-framework-md-ipv6only-underlay-27

[Ballot comment]
I debated this one heavily with myself between DISCUSS and ABSTAIN because while this is a topic I think makes sense to have a document on, I think everyone else has sufficiently pointed out enough issues that I do not think it would be productive for me to laundry list everything at the risk of suggesting I caught everything I would want to correct. I sincerely appreciate the intdir review (and everyone else's from directorates) for the addition insight that has pushed me to ABSTAIN. I think the document, despite its obviously dedicated revisions, needs to fundamentally be rewritten before it would be appropriate for publication.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-v6ops-framework-md-ipv6only-underlay-27
CC @evyncke

Thank you for the work put into this document, while I am balloting a DISCUSS, the work is useful once the document is cleaned up.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Ron Bonica for the shepherd's write-up including the WG consensus *but* it lacks the justification of the intended status; having some reports of deployments/implementations would have been useful though.

Other thanks to Xiao Min, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-v6ops-framework-md-ipv6only-underlay-25-intdir-telechat-min-2026-08-16/ (and I have read the email discussion)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Title

In my opinion, the title is misleading as it is neither an "underlay" when translation is used and, while it does work over multi-domain, the core of the document works perfectly fine within a single domain.

Also it is *not* IPv4-as-a-Service as the proposal does not offer access to the public IPv4 Internet.

Finally, the word 'framework' is a little too ambitious IMHO as it is not the basis for further work. May I suggest "IPv4 transport over IPv6-only network" ? Of course adding 'scalable' is possible.

### Why BGP ?

Somehow linked to the above point, I wonder why this document only discusses about BGP, while this is rather obvious for multi-AS, I think that the technique described in this document could also be used on a single AS without BGP (using a different rule mapping distribution).

### Section 3

`This is referred to as a "Multi-domain Underlay Network" in this document.` is not correct as there is no 'underlay' when using translation.

### draft-ietf-idr-mpbgp-extension-4map6 is normative

In section 4.1 `The detailed structure of the address mapping rule is defined in [I-D.ietf-idr-mpbgp-extension-4map6].` clearly makes  draft-ietf-idr-mpbgp-extension-4map6 a *normative* reference.

### Section 4.1

As far as I can tell, this section is underspecified, or at least I do not understand how to implement it:

1) should there be a unique mapping rule encompassing the source and the destination IPv4 address ? Or should there be one for source and one for destination ? Section 4.2 is more explicit, so, at the bare minimum add a forward reference to 4.2.

2) how to process RFC 1918 IPv4 addresses ? Are they allowed ? How to differentiate RFC 1918 prefixes used by different customers ?

What is meant by "direction" in `The address mapping rule for the destination address will determine the direction of IPv4 service data transmission` ?

`As shown in Section 2.2 of [RFC6052], IPv4-embedded IPv6 addresses are composed of a variable-length prefix, the embedded IPv4 address, and a variable-length suffix.` contradicts section 2 `In this document, the IPv4-embedded IPv6 address is composed of an IPv6 mapping prefix and an IPv4 address.` as the latter does not mention a suffix.

### Section 5.3

In the translation part, why not checking the validity of the source IPv4 and source IPv6 with the MR-DB in addition to `Otherwise, the egress PE extracts the original IPv4 source and destination addresses` ?

It is unclear what to do when the prefix length is less than 96 bits? Which value is then used for the IPv6 bits after the appended IPv4 address ? What is the behavior of the egress PE to check these bits ?

In the HTML rendering, it is also unclear when the "encapsulation" part ends in this section as the last paragraph(s) may apply to both translation and encapsulation.

### Section 7

`when translated, the IPv6 header is 20 bytes larger than the IPv4 header.` is not correct if the IPv4 packet needs to be fragmented by the PE or was already fragmented as a Fragment extension header needs to be inserted.

[Ballot comment]

## COMMENTS (non-blocking)

### Support for some other DISCUSS

I support Ketan Talaulikar's DISCUSS 2, 3, and 7.

### Section 1

The first 2 paragraphs are rather useless in 2026, especially with references dating 2022 and 2016.

Also wondering why "NP" is introduced rather than the more usual "SP" and "ISP". Similar issue when using "section" rather than "network". Probably a matter of taste.

This section could also be more concise, e.g., unsure about the added value of `each with a full-mesh or partial-mesh topology`.

`These solutions allocate only IPv6 addresses to customer terminals or networks` is slightly misleading as some public IPv4 addresses are shared by the terminals, so, these solutions require at least one public IPv4 address.

draft-ietf-v6ops-6mops, while being super useful and important, is used only within a customer network and not over the Internet; i.e., mentioning it in this document is only confusing.

`This document presents a framework for building a large-scale IPv6-only network from the perspective of network providers.` seems to misrepresent this document as the goal is to provide IPv4 transport.

### Section 1.1

As BCP term is used only once (a "MUST"), I wonder whether it is useful/required to have this section, especially in an informative document. Please remote this section and use a lower case "must" in section 8.3.

### Section 2

English is not my primary language, but I think that s/An IPv6 address *embedded with* a 32-bit IPv4 address/An IPv6 address *embedding* a 32-bit IPv4 address/ would be better.

The MAN acronym is only used once and brings little to the document, consider removing the acronym.

### Section 4.1

s/the ingress PE can generate corresponding IPv6 source and destination addresses from *its* IPv4 source and destination address as below/the ingress PE can generate corresponding IPv6 source and destination addresses from *the packet* IPv4 source and destination address as below/ ?

Suggest using the more recent work draft-ietf-v6ops-rfc7915-bis rather than RFC 7915.

An example of mapping src/dst IPv4 to IPv6 would be welcome (cfr my DISCUSS issue for this section).

s/2001:db8:122:344:c0:2:2100::/2001:db8:122:344:c0:2:2100:/ (no need for "::" a single ":" is enough).

### Section 4.2

Rather than `Consider the network case of Section 3,` use the Figure number as reference.

### Section 5.2

s/This process can be implemented through the routing layer/This process can be implemented through the routing *process*/ or similar (e.g., "plane") as there is no routing layer defined in the IETF/OSI models.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
I note that the document is Informational and can accept that it references a lot of work in progress to some extent from that status.  This document seems to be more of a guiding draft of "how this could work" not how one can realize this framework today.

I'm abstaining mostly related to the noted lack of coordination with the routing area WGs on which this proposed framework relies.  I would like to see some level of consensus with those WGs.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-v6ops-framework-md-ipv6only-underlay-27

# Thank you to the authors and the working group for the work on this document. I support the objective of simplifying IPv6-only underlays while continuing to carry IPv4 services.

# i support the DISCUSS's from Ketan and Gorry, and will mostly focus upon additional aspects

# From a routing perspective, however, I found several architectural and interoperability questions that I believe need to be resolved before publication.

[DISCUSS#1] The applicability and trust boundary are not defined
It is not clear whether this framework is intended for:
* several ASes belonging to one operator;
* a limited group of cooperating operators; or
* an open inter-provider service with connectivity to the global IPv4 Internet.

Different sections imply different answers. Section 5.2 requires rule distribution across independently administered providers, while Sections 6–8 assume coordinated prefix allocation, bilateral policies, common ICMP filtering rules, and trusted ingress PEs. The companion IDR draft (https://datatracker.ietf.org/doc/draft-ietf-idr-mpbgp-extension-4map6/) explicitly limits itself to a controlled environment consisting of one operator or a small group of cooperating operators, but this document does not carry over that limitation.

This distinction affects mapping-prefix uniqueness, route propagation, source validation, the use of a default egress, and whether mapping prefixes may be reachable from outside the participating networks.

Please add an applicability section that defines:

* the maximum scope of a deployment;
* the participating operators’ trust relationship;
* the boundary of the framework;
* whether mapping prefixes are reachable outside that boundary; and
* the filtering performed at that boundary.

RFC 8799 may be useful if this is intended to be a limited-domain mechanism.

The comparison with existing technologies also needs correction. Section 1 says that existing SRv6/MPLS VPN solutions are for a single provider. That is not generally true: RFC 4364 specifies multi-AS VPN options and carriers’ carrier arrangements. More importantly, RFC 5565 already describes IPv4 islands across an IPv6-only transit network, BGP-based distribution of IPv4 reachability, tunneled forwarding, route reflectors, inter-AS operation, OAM, and tunnel selection.

The document should explain what operational problem remains after RFC 5565 and RFC 8950, and what this framework adds.

[DISCUSS#2] The address construction and mapping-prefix rules are incomplete
Section 4.1 says that the IPv4 address is “appended” to the mapping prefix. That is only a sufficient description for a /96 prefix. For the other prefix lengths, RFC 6052 Section 2.2 inserts the reserved u octet and has a suffix. RFC 6052 permits only /32, /40, /48, /56, /64, and /96 prefixes; bits 64–71 must be zero, and the suffix should be zero.

Section 6 does not state any of these restrictions. It merely recommends using a common prefix length. Please explicitly require the RFC 6052 construction algorithm and the permitted prefix lengths.

Several routing behaviors are also unspecified:
* Section 6 permits a PE to have multiple mapping prefixes, but does not say which one is used to construct the source address.
* “Best matches” in Section 4.2 appears to mean IPv4 longest-prefix match, but this is not stated.
* There is no selection rule when multiple PEs advertise the same IPv4 prefix.
* It is not clear whether multipath or anycast egress is supported.
* A mapping rule can remain present when the corresponding Pref6(PE) becomes unreachable.
* A covering aggregate might route traffic to a site or PE that did not originate the mapping rule.

A mapping rule should only be usable while its Pref6(PE) recursively resolves to a valid IPv6 route reaching the correct egress. The document needs to say what happens when that reachability is lost: withdraw or deactivate the mapping rule, use another egress, use the default egress, or drop the traffic.

[DISCUSS#3] Source-address validation is required
Section 8.1 says that the egress assumes that all ingress PEs are authorized. It then focuses mainly on resource exhaustion and suggests that statelessness limits the consequences.

The more serious issue is source-address spoofing. A sender that can reach an egress mapping prefix can choose an embedded IPv4 source and destination. The egress will then emit an IPv4 packet with the attacker-selected source address. Stateless processing makes that attack inexpensive and possible at line rate.

RFC 6052 Section 5.1 specifically identifies this threat and calls for reverse-path checks and verification that packets originate from an authorized location.

The document needs to require that an egress PE validates at least:

* that the IPv6 source was formed using an authorized ingress PE’s mapping prefix;
* that the embedded IPv4 source is consistent with a mapping rule or policy assigned to that ingress PE; and
* that the packet arrived from the expected participating network.

Packets failing this validation should be discarded and counted. Mapping prefixes should also be filtered at the framework boundary. Please reference BCP 38 and the applicable source-address-validation guidance directly.

[DISCUSS#4] references
RFC 2473 needs to be normative if encapsulation remains part of the framework.
RFC 6040, as updated by RFC 9601, needs to be added and made normative if encapsulation remains.
RFC 8950 needs to be normative if support for it is really a deployment requirement
The 4map6 IDR draft is normative if it defines the mapping-rule structure required by this framework.

References that should probably be added include:
RFC 4364 and RFC 5565 for prior routing and inter-AS work;
RFC 4925 for the softwire mesh problem;
RFC 8799 for a limited-domain applicability statement;
RFC 4291 and RFC 7136 for the u-bit discussion;
RFC 6040 and RFC 9601 for tunnel ECN;
RFC 6438 for tunnel Flow Label and ECMP considerations;
RFC 6791 for ICMP source-address handling;
BCP 38 and current source-address-validation guidance;
RFC 4459 and/or RFC 8900 for tunnel MTU and fragmentation considerations
RFC 9012 if the BGP Tunnel Encapsulation attribute and its sub-TLV terminology are described directly here.

Kind Regards,
Gunter Van de Velde
Routing AD

[Ballot comment]
Resolving the IESG discusses will most likely change the document significantly, hence my first attention was to open technical correctness and discuss those aspects.

[Ballot comment]
Thank you to Stewart Bryant for the GENART review.

I support the DISCUSS positions of Gorry Fairhurst and Ketan Talaulikar.  In these positions, I would like to highlight the GENAREA issues already noted by Ketan on charter scope and applicability.

I am balloting abstain because it is unclear to me what normative, interoperability-focused behavior is being specified in this document.  Furthermore, it is unclear in what way to apply this framework and where.

A few additional comments on the security considerations:

** Section 8.1
  In this framework, as the receiver of IPv4-embedded IPv6 packets,
  each egress PE assumes that all ingress PEs are legal and authorized
  to send IPv4-embedded IPv6 packets to it.

What makes a packet “legal”?

** Section 8.1
  If IPv6 packets
  cannot guarantee their authenticity or integrity, then there may be a
  spoofing attack

What is the appropriate mechanism for a IPv6 packet to use to guarantee “authenticity” or “integrity”?

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

As someone that supports IPv6 and especially IPv6-only underlay deployments, I
find myself conflicted with this document's form and proposals.

This is a routing-heavy document and it's unfortunate that this never
got an RTGDIR (early or any) review. I don't know if it was socialized with
GROW WG given its potential intersection with Internet routing (unless I've
got the document's applicability wrong).

This framework document coming from V6OPS depends on specifications that have
not yet matured or published. This gives the impression that operational
experience on it is pending and that strikes me as highly unusual (I echo
some of the sentiments of GENART reviewer) - is there any precedence for
V6OPS asking for publication of such kind of document? This is what gets
me to the first discussion point.

Please find below some discussion points and comments on this document, inline
in the idnits output of v27. Lookout for the  tag at the end to ensure
you are seeing the full review.


Nature of this document and V6OPS charter fit

I would like to discuss what kind of document this is. It is not a
deployment description, since (I believe) nothing described has been
deployed and the (BGP or DNS-based) rule distribution mechanisms (I believe)
are neither mature nor implemented. It is not a requirements document, since
it states no requirements on the mechanism it depends on - which is what the
INTDIR early review asked for. It is not a problem statement of deployment
or operational issues. Neither is it something that is driving protocol
development work in V6OPS. It is a framework that leaves important things
unspecified and normatively requires work that is not yet mature or even
adopted. How does this fit into V6OPS charter? I don't consider milestone
as a charter fitment.

I looked for a precedent among V6OPS prior work and did not find one.

Please see if the document could be rescoped to the problem statement
(leaning upon deployment or operational challenges), the deployment
requirements, and the required properties of any conforming
rule-distribution mechanism. This fits within V6OPS charter and can help
organize work in other WGs - notably related BGP and routing work in
other WGs.

The applicability of the framework is never stated - whether it
is for multiple ASes of a single provider, a closed set of cooperating
providers, or an open capability reaching the global IPv4 Internet.

603   Although this document illustrates the framework for a multi-domain
604   IPv6-only network operated by multiple NPs, this framework is also
605   applicable to an IPv6-only network operated by a single NP.

This is the document's only applicability statement, and it widens the scope
downward without ever bounding it upward. What is the maximum extent of a
multi-domain IPv6-only underlay network? The Internet?

The text supports opposite answers. Section 1 motivates the work by network
providers requiring access to the global IPv4 Internet, Section 8.1 has the
egress PE forwarding converted packets into the IPv4 Internet, and Section
5.2 requires the distribution procedure to scale across multiple
independently administered NPs. Against that, Section 6 requires mapping
prefix uniqueness across the whole domain, Section 7 requires the
participating carriers to negotiate management-level SLAs for ICMPv6
traversal, and Section 8.3 makes the default rule conditional on explicit
bilateral policy. Every one of the second set is a cooperating-parties
assumption; none of the first set is bounded.

The scale, routing and security analyses all differ between "several ASes
of one provider" and "an open capability reaching the global IPv4 Internet",
and several of my comments below cannot be weighed without the answer. It is
also the point on which this framework differs from 464XLAT, MAP-E, MAP-T and
DS-Lite, which Section 1 places it alongside: those are single-administration,
their mapping rules are provisioned rather than exchanged, and each has one
well-defined edge to the rest of the Internet. This framework has none of those
properties.

Please add an applicability section stating the intended deployment scope,
the cooperation and trust assumptions that scope implies, and the boundary
of the domain - including what a border router does with IPv4-embedded IPv6
packets arriving from outside it. If the answer is a limited domain, RFC
8799 gives the shape of what needs saying. Was this ever discussed in the WG?

The document does not situate itself correctly against the
existing IETF work for the same problem. Instead it has misleading, incorrect
and unhelpful comparisons.

160   solutions.  When transmitting IPv4 service data, this framework
161   enables end-to-end tunneling or translation across multiple network
162   providers, and therefore is different from existing SRv6/MPLS VPN
163   solutions which are for a single NP.  Unlike IP-in-IP tunnel
164   mechanism, where tunnels often operate alongside routing protocols
165   that constitute a control plane (e.g., routing adjacencies over the
166   tunnel), this framework includes a specific mechanism for
167   distributing IPv4-to-IPv6 mapping rules across domains.

First, "existing SRv6/MPLS VPN solutions which are for a single NP" is not
correct. RFC 4364 Section 10, "Multi-AS Backbones", exists precisely for VPN
sites connected to different Autonomous Systems and different SPs, and gives
the three procedures universally known as Inter-AS Options A, B and C. RFC
4364 Section 9, "Carriers' Carriers", covers an SP obtaining backbone
service from another SP. Both have been in the base L3VPN specification
since decades and both are widely deployed between distinct providers.

Second, the contrast with IP-in-IP tunnelling omits the closest prior art.
RFC 5565, the Softwire Mesh Framework, frames exactly this problem in
Section 3.2 - IPv4 islands across an IPv6-only transit core - covers the
multi-AS case in Section 12, and in Section 5 has the AFBRs use BGP to
distribute the other family's reachability with a next hop in the transit
family. That is the requirement RFC 5549 and then RFC 8950 were written to
satisfy; RFC 8950 is cited here while RFC 5565 and RFC 4925 are not. RFC
5565 Section 5 is also explicit that the BGP sessions are not tunnelled, so
softwire mesh does not have the property this paragraph contrasts against.

I don't think this document needs to make these false assertions. What it
does need to acknowledge is the existing prior art in routing technology
deployments when it comes IPv4 over IPv6 and then identify the deployment
or operational issues or improvements that motivated the definition of the
new framework in this document.

Please rewrite the paragraph accordingly and add RFC 4364 and RFC 5565 as
informative references. I would like to check with these prior art were
discussed in the WG?

Vulnerability without source validation and BCP 38 filtering

676   In this framework, as the receiver of IPv4-embedded IPv6 packets,
677   each egress PE assumes that all ingress PEs are legal and authorized
678   to send IPv4-embedded IPv6 packets to it.  After the egress PE
679   receives IPv4-embedded IPv6 packets, it will convert them into IPv4
680   packets and forward them into the IPv4 Internet.  If IPv6 packets
681   cannot guarantee their authenticity or integrity, then there may be a
682   spoofing attack.  A malicious ingress PE could send IPv6 packets
683   converted from IPv4 packets to attack an egress PE.  Since the PEs in
684   this framework are stateless, even when receiving large-volume
685   traffic flows, they will not increase mapping session counts within
686   the device like a stateful NAT device would, thus avoiding
687   significant consequences.  Even if no per-flow state exists, it

The egress PE's behaviour is: match my mapping prefix in the destination,
extract the embedded IPv4 source and destination, emit an IPv4 packet into
the IPv4 Internet. So anywhere the mapping prefix is IPv6-reachable, an
attacker can choose both the IPv4 source and the IPv4 destination of a
packet the egress PE will originate on its behalf, statelessly and at line
rate. That is a source-address-spoofing service rather than a resource-
exhaustion problem, and statelessness makes it cheaper rather than safer.

RFC 6052 Section 5.1 already identifies this case and names the mitigation -
reverse path checks, and verifying that packets come from an authorized
location. The only pointer here is the generic reference to RFC 6052 in
Section 8.2, which does not put an operator anywhere near the control they
need. Note too that the RFC 7915 Section 8 statement adopted in Section 8.2
carries the caveat "and in the routing protocols that are used to make the
packets reach the translator" - and in this framework those are inter-
domain.

Suggest to add: that egress PEs MUST apply source address validation, accepting
only IPv4-embedded IPv6 packets whose IPv6 source is formed from an
authorized PE's mapping prefix and whose embedded IPv4 source is consistent
with that PE's advertised mapping rule, with the behaviour on failure
stated; whether mapping prefixes are expected to be reachable from outside
the participating NPs, and the border filtering that follows; and direct
references to RFC 6052 Sections 5.1 and 5.3 and to BCP 38.

Normative dependency on protocol specifications that don't seem
to have matured, implemented and deployed

432   [I-D.ietf-idr-mpbgp-extension-4map6] can be implemented in PE1 and
433   PE3 to support the MR-DB operations in the framework.  In addition,
434   for the mapping rules to propagate from PE3 to PE1 across the
435   network, the intermediate BGP speakers (e.g., route reflectors /
436   ASBRs) that propagate the relevant NLRI will support [RFC8950].

This places a deployment requirement on route reflectors and ASBRs, which
are not part of the framework's own device model - Section 5.1 lists edge PE
devices, core P devices and customer-side IPv4 routers. It states that
requirement as "will support", which carries no normative force, and it does
so for an NLRI whose encoding this document does not define. The same "will"
pattern appears at line 453 in Section 5.1 and at line 585 in Section 5.3.

The underlying claim is right - RFC 8950 Section 5 anticipates the route
reflector case and requires that a next-hop encoding passed along unchanged
is not altered. It is the framing that needs work. Please add the control-
plane devices to the framework's component list in Section 5.1 and replace
"will support" with a determinate formulation. See also my comments below on
Section 5.2, which is the same defect on a different sentence, and on the
classification of RFC 8950.

The other and larger concern is the normative dependency on the BGP that is
placed as informative when much of this framework is heavily dependent
on routing and the mechanics in the IDR document. There is a similar situation
with DNS-based solution, but that seems like an individual draft that I
have not even looked at.

Please add a short subsection to Section 5.2 stating the properties that any
conforming rule-distribution mechanism must have: which fields are carried,
that the key fields including the Forwarding Type are not modified in
transit, the scoping and filtering expectations at administrative
boundaries, and what origin authentication is assumed. Then remove all of
BGP and routing heavy/specifics from this document to the IDR WG document.
Stick to the high-level functionality and the forwarding aspects in this
document. This will eliminate the reference entirely. It also helps perhaps
with the DNS one - though I don't quite follow that one.

Potential for routing loops

496   With the availability of a default egress PE, the ingress PE can
497   deliver the IPv4 packets to the default egress PE when it does not
498   obtain the address mapping rule for that IPv4 address block.  From

After the default egress PE translates or decapsulates, the recovered IPv4
packet carries no indication that it has already traversed the framework
once, and it is forwarded on that PE's IPv4 routing information. If that
PE's best IPv4 path for the destination points back toward another
participating PE - entirely possible where the default egress PE's IPv4 view
is partial, or where two NPs each treat the other as their default - the
packet is mapped again and the cycle repeats. Section 8.3 covers traffic
attraction and hijack, but not this.

Please state that a default egress PE is expected to have a complete IPv4
forwarding view for the traffic it attracts, and should not resolve traffic
received via the framework back onto a path that re-enters the framework. It
is worth noting explicitly that TTL and hop limit handling bounds the loop
but does not prevent it.

Another issue with applicability - does it work on PEs, CEs, or UEs?

393   To enable IPv4 service data forwarding in a multi-domain IPv6-only
394   network, IPv4 packets need to be converted to IPv6 packets - either
395   at the UEs/CEs or at the PEs located at the edge of the network.

"either at the UEs/CEs or at the PEs" describes two architectures, and
everything after this sentence describes only the second. Section 5.1's
component list has the customer-side routers as IPv4 speakers, not
converters.

This matters more than a loose sentence, because a UE/CE-based model puts
the mapping prefix and the MR-DB at the customer edge, which changes the
applicability answer, the scale, the security model and the addressing plan
together.

Please either delete "at the UEs/CEs or", or state explicitly that UE/CE-
based conversion is covered by the existing access-side technologies listed
in Section 1 and is out of scope for this framework, which is about the
underlay. I would prefer the former, but I would like the document to
answers the question of how this relates to what already exists - which
Section 1 raises and does not close.

The Operational Considerations are written for the translation
path only, and there is no manageability content.

345   *  The IPv6 source address is derived by appending the IPv4 source
346       address to its local IPv6 mapping prefix, i.e., Pref6(ingress PE).

Section 6 says that one or more distinct IPv6 mapping prefixes are assigned
to each PE device, so "its local IPv6 mapping prefix" is ambiguous where a
PE has several. Which one is used for source derivation, and must it be one
the PE has advertised in a mapping rule?

More broadly, the document has no manageability content at all: nothing on
detecting MR-DB inconsistency between PEs, nothing on what an operator
observes when a mapping rule is withdrawn, no counters or diagnostics, and
nothing on OAM across the framework. The last of those is not merely an
omission - see my comment on Section 7 below, where ICMPv6 errors generated
by core P routers are addressed to IPv4-embedded IPv6 addresses and the
document never says who translates them back. For a framework whose stated
motivation in Section 1 is that dual-stack doubles the troubleshooting
effort, this is a conspicuous gap.

Please state which mapping prefix is used and whether it must have been
advertised, and add a manageability subsection covering MR-DB monitoring,
the behaviour on mapping rule withdrawal, and OAM across the framework.

What's the framework about? Translation or Encapsulation or both?

563       2.  Encapsulation
565       The address mapping process for encapsulation follows the same
566       procedure as translation: When the ingress PE receives an IPv4

Translation and encapsulation are presented as two realisations of
one framework, and lines 598 to 601 assert they are equivalent from the
control plane's and the core's point of view. This is not correct and in
fact the rest of the document does not treat them as equals. RFC 6052 and
RFC 7915 are normative; RFC 2473, the only thing this mode rests on, is
informative - which is wrong if encapsulation is a supported mode. The
Abstract does not mention encapsulation. Section 4.1 states the proposal
as translation. Section 8.2 says flatly that the Stateless IP/ICMP
Translation Algorithm is used, and there is no security analysis of the
tunnel mode anywhere. This subsection is defined by reference to the
translation one and never describes outer header construction, which the
INTDIR early review raised and I do not see addressed. Section 7's
operational guidance is entirely RFC 7915-based.

Then there is the routing part (lines 432 to 443) that do not do justice
to the encapsulation mode which uses RFC 5565 and RFC 8950. It misleads
by referring to both the new BGP mapping prefix extensions and the existing
work without getting into which of the two modes they work on and how.

There is also the sense that I get which is that mapping rules are
required when doing encapsulation, and I fail to understand that. Why is
translation required when two IPv4 hosts are talking over an IPv6-only
underlay using an encapsulation mode? I get it that mapping prefixes are
needed for translation. This seems like another area where the two modes
blur into each other and create ambiguity (and for me, confusion).

I can see two options.
Promote encapsulation: make RFC 2473 normative, specify outer header
construction including Traffic Class, Flow Label and Hop Limit, add ECN
handling per RFC 6040, add tunnel MTU and ICMP relay per RFC 2473 Sections
7.1 and 8, extend Sections 7 and 8 to cover the mode, resolve the mode
selection rule at lines 584 to 590, add the routing part, and position the
result against RFC 5565 rather than re-deriving it.
OR demote encapsulation: state that this framework specifies stateless
translation, and that encapsulating IPv4 in IPv6 across a multi-AS core
is an alternative realisation of the same address-mapping control plane,
already framed by RFC 5565 and out of scope here.

My sense from the document is that the second is preferred, but I could be
wrong. The second option resolves the mode selection question outright
and reduces most of the ECN question and parts of the MTU and ICMP ones to
scoping statements, and it makes the document's actual contribution -
stateless per-prefix mapping with no per-destination tunnel state - stand
out instead of being one of two half-described options.

If the authors/WG chose two modes deliberately then so be it, but then the
first option is the obligation, and the reference classification needs
fixing either way. The document needs to clearly disambiguate both modes,
their details, and then do a comparison analysis between them.

Was carrying both an explicit WG choice, and if so what deployment need does
one mode serve that the other does not? It goes both ways.

Note: The comments also indicate some serious defects that could be considered
to be worthy of DISCUSS, but I didn't want to load up everything in this block.
Would appreciate if the comments were also given a thorough treatment. Many of
them are related to the discussion points.

[Ballot comment]
A few general comments first:

1)  Zero-checksum UDP is not addressed. RFC 7915 Section 4.5 requires
the translator to update the transport checksum for UDP packets that carry
one, and for those that do not it says the translator SHOULD provide a
configuration function whose options are to drop the packet and raise a
management event, or to compute the checksum. IPv4 hosts do legitimately
send UDP with a zero checksum. So in translation mode this traffic is either
dropped or costs a full-payload checksum computation at the PE, while in
encapsulation mode it passes untouched - one more way in which the two modes
are not equivalent. This was pointed out in the GENART Last Call review.

2)  In Section 5.3, lines 554 to 561 and 576 to 582 are the same
paragraph with translation and decapsulation swapped, and lines 545 to 552
and 565 to 574 are similarly parallel. Since the egress check needs
rewriting in both places anyway (see my comment at lines 554 to 560), this
is the moment to factor the common procedure out once and state only the
delta for each mode.

More detailed inline comments follow:

94   with IPv6 traffic growing at a faster rate than IPv4.  As of 2022,
95   most IPv6 deployments rely on dual-stack [RFC4213].  However, dual-

A 2022 datum in a document that will publish in 2026 or later. Either
refresh it with a current reference or drop the sentence or drop the year and
make the statement timeless.

152   the definition of "IPv6-only".  Unless otherwise stated, the term
153   “IPv6-only network” in this document refers specifically to
154   “IPv6-only underlay network”. This document presents a framework for

The definition of "IPv6-only network" sits mid-paragraph in Section
1 rather than in the terminology of Section 2. Separately, "IPv6 mapping
prefix" and Pref6(PE) are used throughout the document and are defined
nowhere. Please move this definition into Section 2 and add entries for the
other two.

365   "Network-Specific Prefix".  Note that [RFC7915] also allows the use
366   of unicast addresses without u-bit (as long as they are not derived
367   from an IEEE MAC-layer address).

RFC 7915 does not allow this; RFC 7915 Section 6 notes that RFC 7136
updates RFC 4291 to allow it, and neither RFC 7136 nor RFC 4291 is referenced
here. RFC 6052 Section 2.2 says that bits 64 to 71 MUST be set to zero, and
RFC 7136's relaxation of RFC 4291 does not lift that. Placed immediately
after Table 1, in the section that defines how PEs construct addresses,
this note tells an implementer the u-bit constraint is optional. If that is
the intent it needs to be stated as a deliberate deviation and justified.

The reason it matters: Section 6 never constrains mapping prefixes at all.
It does not say that a mapping prefix must be one of the six lengths RFC
6052 Section 2.2 permits, that bits 64 to 71 are zero - which for a /96
mapping prefix is a constraint on the prefix itself, and therefore on NSP
assignment - or that the suffix is zero. The summary at lines 361 to 362 and
the terminology entry at lines 191 to 192 both omit the u octet as well, so
the document's three descriptions of the address format are mutually
inconsistent. Please align them with RFC 6052 Section 2.2, and point at RFC
6052 Section 3.3 for length selection - this is important as those prefixes
get into routing.

398   e.g., NP-3) from a client-facing interface, it queries its mapping
399   rule database (i.e., MR-DB) to find the rule that best matches the
400   packet's destination IPv4 address.  The IPv6 mapping prefix in the

"Best matches" gives impression of longest-prefix match behaviour
(am I correct?) but not the tie-break when two PEs advertise mapping rules
for the same IPv4 block - multihomed customers, anycast IPv4 services, or
simply two PEs with a route to the same aggregate. Is rule selection delegated
entirely to the distribution protocol's best path process? And is multipath
across egress PEs intended to be supported? If either answer is yes, a sentence
saying so belongs here or in Section 5.2. Please clarify in any case.

476       For IPv4 service delivery, IPv4/IPv6 address mapping rules need
477       to be generated.  In the network shown in Figure 1, when PE3
478       receives an IPv4 BGP route advertisement from an IPv4 border
479       router, e.g., BR1, it extracts IPv4 address blocks and generates
480       address mapping rules by combining them with its own IPv6 mapping
481       prefix.  All the address mapping rules, whether locally generated
482       or received from other PEs, are stored in its local MR-DB.  PE
483       devices also support rule management operations, such as
484       insertion, modification, and deletion of address mapping rules.

Neither this nor the statement in Section 4.1 that a PE's IPv4
blocks are "extracted from local IPv4 routing table or address pool" bounds
how many mapping rules exist. The document never says which IPv4 blocks a PE
should originate rules for, whether rules track received BGP routes one for
one or are aggregated or configured, or what an MR-DB is expected to hold.
So a reader cannot tell whether the intended operating point is tens of
rules per PE or several orders of magnitude more, and an operator cannot
size for either. Note that the default egress PE is introduced here as a
fallback for rules that have not arrived, not as a policy for limiting which
rules are generated.

Please state the rule-origination policy. My suggestion: a PE originates
mapping rules only for IPv4 address blocks for which it is the authoritative
or aggregating egress - customer blocks, address pools, site aggregates -
and not for transit routes learned from external peers, with the default
rule covering the remainder; then give the expected order of magnitude of
an MR-DB under that policy. This all has significant implications on routing.
Was any of this discussed within the WG? The answer also depends on the
applicability question in my DISCUSS.

Please give a proper thought on how much of such and other routing aspects
this framework wants to get into and if all of this should be moved into
a routing document (e.g., the BGP spec).

489       correct egress PE.  To mitigate this issue, the framework
490       introduces a default egress PE, which advertises a default
491       address mapping rule to all other PEs.  The format of default

The default rule is defined here, and the only constraint
on its use - the document's only MUST, at lines 731 to 733 - is in Section
8.3. A reader implementing or deploying from this section gets the mechanism
and a forward pointer to a security discussion, but not the scoping rule.

Please move the normative scoping statement here, immediately after the rule
format at line 494, and leave Section 8.3 with the threat analysis and the
monitoring and rate-limiting advice, cross-referencing back. The substance
does not change; only the location.

506       Address mapping rules generated on a PE device need to be
507       distributed to PE devices in other domains.  During the
508       transmission of these rules, the key information
509       elements,including the Forwarding Type field defined in
510       Section 4.1, must not be modified by any intermediate node.
511       Furthermore, the transmission procedure must support scalability
512       across multiple independently administered network providers
513       (NPs).

Three things in one sentence, in a document that has a BCP 14
section.

"must not be modified by any intermediate node" is a requirement on third-
party BGP speakers, and whether they honour it determines whether the
framework works. Two implementations reading this differently - one treating
the Forwarding Type as a modifiable transitive attribute - would produce a
working-looking control plane that selects the wrong transformation mode.
That is an interoperability consequence, so the lowercase here is a problem.

Next, the cross-reference is wrong: Section 4.1 does not define the
Forwarding Type field, it names it and delegates the structure to draft-
ietf-idr-mpbgp-extension-4map6 - yet another normative dependency. Third,
"must support scalability" at lines 511 to 513 is a design goal in
requirement clothing, and nothing can be tested against it.

Perhaps: "The key information elements of an address mapping rule, including
the Forwarding Type field, MUST NOT be modified by any intermediate node."
Then correct or remove the Section 4.1 pointer, and reword lines 511 to 513
as a design goal. Better still, fold this into the properties subsection
suggested in my first general comment above, where it is a statement about
what a conforming distribution mechanism must guarantee.

554       Upon receiving the IPv6 packet, the egress PE checks whether the
555       destination IPv6 prefix matches its own IPv6 mapping prefix.  If
556       not, it discards it or forwards it as a regular IPv6 packet.
557       Otherwise, the egress PE extracts the original IPv4 source and
558       destination addresses from the IPv4-embedded IPv6 addresses and
559       reconstructs the original IPv4 packet, and this process complies
560       with [RFC7915].  The IPv4 packet is then forwarded based on the

Two error-handling gaps, both of which appear twice - the same
paragraph recurs at lines 576 to 578.

The only test is on the destination. Line 557 then assumes the source is an
IPv4-embedded IPv6 address, but nothing has checked that. A native IPv6 host
- or an attacker, per my DISCUSS on Section 8.1 - can send to Pref6(PE) with
an arbitrary IPv6 source, and a stateless translator cannot derive an IPv4
source from it. The document needs to say the packet is discarded.

And "it discards it or forwards it as a regular IPv6 packet" is not a
specification. Two implementations can legitimately choose differently, with
different observable behaviour: a silent drop, or a packet re-entering the
IPv6 forwarding path possibly toward the same PE.

Perhaps, for both occurrences: if the destination address does not match one
of the PE's own IPv6 mapping prefixes, the packet is not subject to this
framework and is forwarded according to the normal IPv6 forwarding rules; if
the destination matches but the source is not an IPv4-embedded IPv6 address
formed from an authorized PE's mapping prefix, the packet MUST be discarded
and SHOULD be counted.



572       procedure described in Section 4.1.  The framework utilizes the
573       IPv4-in-IPv6 tunnel technique defined in [RFC2473], which enables
574       IPv4 packets to traverse through native IPv6 networks.

RFC 6040 specifies ECN handling for IP-in-IP tunnels, and its scope
covers any IP-in-IP tunnelling irrespective of which version is used for the
inner or outer header, so this mode is covered. RFC 2473 predates it and is
not conformant. RFC 2473 Section 5 lets the tunnel entry point set the outer
Traffic Class to a pre-configured value, overwriting the ECN codepoint that
RFC 6040 Section 4.1 requires be copied. And RFC 2473 has no rule for
propagating congestion experienced inside the tunnel, so a CE mark applied
by a P router in the IPv6-only core is discarded at lines 579 to 580 when
the outer header is removed, where RFC 6040 Section 4.2 requires the more
severe of the inner and outer markings to be propagated.

This is not a corner case: the whole point of the framework is that traffic
crosses several IPv6-only ASes, which is where the congestion happens.
Section 7 already worries about ECN for the translation path; the
encapsulation path has the same problem by a different route and is not
mentioned.

Please add a pointer that PEs implementing encapsulation follow RFC 6040 for
ECN field construction and propagation, notwithstanding RFC 2473's traffic
class text; add RFC 6040 to the references; and extend the ECN paragraph in
Section 7 to cover both modes.

Separately, on the translation side: the "administrative bleaching" concern
in Section 7 is a property of RFC 7915 Sections 4.1 and 5.1 rather than of
this document, and draft-ietf-v6ops-rfc7915-bis is a V6OPS WG document. The
durable fix is to have the bis require that the ECN bits be preserved where
the DSCP is administratively rewritten, and that is worth raising there.

584   For IPv4 packet delivery across one IPv6-only network, the ingress PE
585   and the egress PE will use the same IPv4/IPv6 transformation
586   mechanism (translation or encapsulation).  When the address mapping
587   rule corresponding to the destination address of a given IPv4 packet
588   is available, based on the value of Forwarding Type of the egress PE,
589   the ingress PE can select the IPv4/IPv6 transformation mechanism
590   which are supported by itself and the egress PE.

Where both PEs advertise support for both mechanisms, there is no
tie-break. Two ingress PEs sending to the same egress PE may choose
differently, and the forward and reverse directions of a single flow may use
different mechanisms.

Lines 598 to 601 are true of the control plane and of the core, and
misleading about the data plane. The modes differ in header overhead - 40
bytes against 20 or 28 - in whether IPv4 options survive, in the treatment
of zero-checksum UDP, in ECN behaviour, and in fragmentation and ICMP relay.

This was raised in the INTDIR early review I do not see it addressed.
Please either state a deterministic selection rule - for example,
encapsulation preferred where both PEs support it, and translation used only
where an egress PE is translation-only - and state that the choice is per
egress PE and applies in both directions of a flow; or, if the choice is
intended to be a local policy matter, say so explicitly and replace lines
598 to 601 with an honest list of the ways in which the two modes differ, so
that an operator can make the choice on informed grounds.

592   For IPv4-embedded IPv6 packets, regardless of whether translation or
593   encapsulation is used, the Pref6 part of the IPv6 destination address
594   identifies the egress point.  Therefore, packet forwarding can be
595   performed by P devices solely based on the Pref6 part of the
596   destination address.

True of the forwarding decision, and it omits the load balancing
decision, which is where multi-domain backbones actually live. In
encapsulation mode the outer header has Next Header 4, and RFC 2473 Section
5 says the Flow Label is typically set to zero, so a P router or a LAG
hashing on the outer 5-tuple sees a zero flow label and, for an unparsed
inner IPv4 header, no ports. The only entropy available is the embedded IPv4
source and destination pair, which gives per-address-pair granularity -
adequate for aggregate traffic, poor for a small number of large flows
between the same pair, which is the data centre to data centre case Section
3 calls out. Translation mode is better off, since the outer header carries
the real transport ports at their normal offsets - which is one more
asymmetry between the two modes.

Please add a sentence that ingress PEs performing encapsulation should set
the IPv6 Flow Label per RFC 6437 from the inner packet's flow
identification, so that ECMP and LAG hashing in the IPv6-only core has
usable entropy, and note the difference between the modes.

And then, related to my DISCUSS point, why is the Pref6 coming into play
when IPv4 traffic is being encapsulated across and IPv6-only core?

616   PE's IPv6 mapping prefix should be allocated as a sub-prefix of a
617   larger IPv6 prefix that is already advertised in the network and
618   whose next hop reaches that PE (or its site).  This allows
619   IPv4-embedded IPv6 packets to be forwarded using existing aggregate
620   routes, avoiding the need for additional FIB entries in the IPv6
621   core.

This is the only place where the relationship between a mapping
prefix and IPv6 reachability is addressed, and it is a lowercase "should"
with no failure analysis. Three consequences the document does not draw.

Nothing requires the ingress PE to verify that Pref6(egress PE) resolves to
a usable IPv6 route before installing and using a mapping rule. In BGP terms
this is a next hop with no recursive resolution requirement. A rule whose
Pref6 is unreachable - the covering aggregate withdrawn, filtered at a
boundary, or never advertised toward this NP - silently drops traffic for the
entire IPv4 block it covers, and the ingress PE has no reason to fall back
to the default egress PE, because it has a rule.

If the covering aggregate is advertised from more than one site, which is
normal practice for a multihomed NP, the packet can be delivered to a PE
that did not advertise the rule. That PE hits the branch at lines 555 to 556
and either discards it or forwards it as a regular IPv6 packet - silently
either way.

And per-PE mapping prefixes are longer than anything most operators will
accept inter-domain, so the framework depends entirely on the covering
aggregate being advertised and accepted across the boundary. That is a real
addressing and routing policy prerequisite and the document does not name
it.

Please state that a mapping rule is usable only while Pref6(PE) resolves to
a reachable IPv6 route, and what a PE does when it does not; and add a
sentence that mapping prefixes are not expected to be advertised inter-
domain, so the framework depends on the covering aggregate propagating to
all participating NPs.

Again, related to my DISCUSS point, there is a lot of routing specifics being
tackled in the document that need a thorough review; seriously consider
the scope of this document and whether these topics are best covered in the
BGP spec.

631   network.  When IPv4 packets are encapsulated in IPv6, the resulting
632   packet is 40 bytes larger than the original; when translated, the
633   IPv6 header is 20 bytes larger than the IPv4 header.  In a multi-

"20 bytes larger" is the best case rather than the general one. RFC
7915 Section 4.1 adds a Fragment Header when the incoming IPv4 packet is
already a fragment, or when the DF bit is clear and the resulting IPv6
packet would exceed the configured lowest-ipv6-mtu. A Fragment Header is 8
octets, so the translation overhead is 28 bytes precisely in the large-
packet, non-DF case that drives the rest of this paragraph. RFC 7915 Section
1.4 itself says "20+ octets" for the IPv4 header, since options are possible
(I doubt they are used though) and are not translated. Since this paragraph
tells operators how much headroom to provision, the number needs to be right.

Separately, all the guidance at lines 638 to 642 is translation-only - every
cross-reference is to RFC 7915. The encapsulation mode's MTU and ICMP
behaviour is in RFC 2473 Section 7.1 and Section 8, neither of which is
cited, so an operator following this section for an encapsulation deployment
gets no guidance at all. RFC 7915 Section 7, on ICMPv6 Packet Too Big, is
also uncited and is directly relevant to the paragraph that follows.

Consider giving a concrete number as well - for example an IPv6-only core
MTU of at least 1500 plus 48 bytes if 1500-byte IPv4 payloads are to survive
without fragmentation in either mode - since "ensuring consistent MTU across
domains" is not actionable without one.

642   translation handling.  It should be noted that the IPv4 data delivery
643   across IPv6-only network specified in [RFC7915] has already been
644   tested on some large-scale networks, such as CERNET, and there are no
645   major issues observed.  In addition, section 4.1 and section 5.1 of
646   [RFC7915] give translators a SHOULD-level option to zero the TOS/

Three problems in one sentence. RFC 7915 specifies a translation
algorithm, not IPv4 data delivery across an IPv6-only network - what was
deployed on CERNET is a deployment, not a specification. "No major issues
observed" carries no reference and no scope, and it directly undercuts the
three sentences before it, which describe MTU differences between domains as
a fundamental operational concern for any IPv4-over-IPv6 framework. And
CERNET is a single-operator network (but I could be wrong?), so it is not
evidence about the multi-domain case that is this document's whole subject.

Either scope the claim honestly - for example, that stateless translation
per RFC 7915 has been deployed at scale within single operators, while the
multi-domain case in this document has not been operationally validated -
or delete the sentence. The paragraph is stronger without it. Does any
implementation of the framework exist, and has any inter-provider deployment
been attempted or planned? I realize one of the authors is from CERNET
and they will correct me; if I were to name deployments, I would do it
as a separate section in the appendix and give far more details than just
one such blanket statement.

"SHOULD-level" is an all-capitals keyword occurrence in a document
whose Section 1.1 says such occurrences are to be interpreted per BCP 14.
Perhaps "a normatively recommended configuration option". The citation is
also a little loose: RFC 7915 Section 4.1 says a translator SHOULD support a
configurable option to ignore the IPv4 TOS and set the IPv6 traffic class to
zero, while Section 5.1 says the ability to set the IPv4 TOS octet to a
specified value, not necessarily zero.

651   One potential risk specific to multi-domain is Path MTU Discovery
652   reliability, an ICMPv6 Type 2 (Packet Too Big) message from a P
653   router in one IPv6 carrier's AS has to reach the originating IPv4
654   host across administrative boundaries with independent ICMP-filtering
655   policies.  In this case, IPv4 hosts may not receive "Packet Too Big"
656   notifications, and will keep trying to send large packets.  These

This treats cross-domain ICMP filtering as the risk and assumes the
message otherwise reaches the originating IPv4 host. It cannot, as written,
because nothing says who converts it.

In translation mode, a P router in the core drops an oversized IPv4-embedded
IPv6 packet and emits ICMPv6 Packet Too Big. Its destination is the IPv6
source of the offending packet, so it routes back to the ingress PE - but
its source is the P router's own IPv6 address, which in an IPv6-only core
has no IPv4 representation at all. To hand an ICMPv4 message to the IPv4
host, the ingress PE must translate ICMPv6 to ICMPv4 per RFC 7915 Sections
5.2 and 5.3 and synthesise an IPv4 source address for it - the case RFC 7915
Section 6 points to RFC 6791 for. The document never says ingress PEs do
this, never mentions RFC 6791 or any pool for it, and Section 5.3 describes
the ingress PE only as a producer of IPv4-embedded IPv6 packets. In
encapsulation mode the problem appears differently: RFC 2473 Section 8 puts
the relay obligation on the tunnel entry-point node, which must recover the
inner IPv4 header from the ICMPv6 payload. Also uncited.

The consequences are the PMTUD drops this paragraph itself describes,
arriving by a route it does not consider, and that traceroute and ICMP-based
troubleshooting across the framework do not work - which is worth weighing
against the motivation in Section 1.

Please state that PEs implement the full RFC 7915 behaviour including ICMPv6
to ICMPv4 translation for errors generated inside the core, that an RFC 6791
pool or equivalent is required at each PE for the ICMPv4 source address, and
the RFC 2473 Section 8 equivalent for encapsulation. Then rewrite the
paragraph so the filtering concern sits on a described mechanism rather than
an assumed one.

This all will add to the normative references.

713   When the capability to advertise address mapping rules via BGP is
714   introduced, attackers may alter the IPv6 mapping prefix within these
715   rules, leading to improper delivery of IPv4 service traffic over an
716   IPv6-only network.  Such an attack differs from pre-existing
717   vulnerabilities in that traffic could be forwarded to a remote target
718   across an intervening network infrastructure (e.g., an IPv6 core),
719   allowing an attack to potentially succeed more easily since less
720   infrastructure needs to be compromised.  To mitigate this risk,
721   [I-D.ietf-sidrops-moa-profile] proposes an approach by leveraging
722   RPKI [RFC6480] architecture to verify the authenticity of the address
723   mapping rule associated with an IPv4 address block.

This identifies a security risk that the framework creates, states
that it is easier to exploit than the pre-existing case, and then offers
exactly one mitigation for it: a draft in SIDROPS (which also brings the
question whether the scope is the Internet or some limited domain(s)).
There is no second mitigation for this risk here - the paragraph that
follows is about the default rule, a different exposure.

So the document is on a fork. Either the mitigation is load-bearing, in
which case the reference is normative; or it is not, in which case the
document has identified a novel security risk and left it unmitigated.
The wording "proposes an approach" is what keeps the reference off the
normative list, and it is not a resolution.

There is a third path and I think it is the right one. State in Sections 5.2
and 8.3 that any conforming mapping-rule distribution mechanism must provide
origin authentication for mapping rules, and that a PE must not accept a
mapping rule binding an IPv4 address block to a mapping prefix belonging to
a PE not authorized for that block. That is a property statement - the same
thing my first general comment asks Section 5.2 to supply - and it is
implementable by bilateral filtering or provisioning as well as by RPKI.
The there is no need to reference draft-ietf-sidrops-moa-profile (same as
no need to reference the BGP spec). This connects with my DISCUSS on
Section 8.1: source validation at the egress PE and origin validation of the
mapping rule are two halves of one control, and the document requires
neither.

Separately, RFC 8950 should be a normative reference. Section 4.2 states a
deployment dependency on it - mapping rules cannot propagate unless the
intermediate BGP speakers support it - which is a condition for the
framework working rather than background. But again, it is possible to keep
BGP and routing out of this document and avoid this.

728   obvious implications, such as traffic attraction (posing a DoS
729   concentration risk) and becoming a "catch-all" hijack target if rule
730   distribution is compromised.  To mitigate these issues, the default
731   rule MUST only be used within a single administrative domain unless
732   explicit bilateral policy exists.  Even in those cases, its use is
733   OPTIONAL.  Network providers can consider applying monitoring and
734   rate-limiting/ACLs on the default egress PE, and avoid exporting the
735   default rule across inter-domain boundaries.

Setting aside the placement, which I raise on Section 5.2 above,
these three sentences do not cohere.

The placement of "only" leaves it open whether the restriction is on where
the default rule may be used or on what it may be used for. "Even in those
cases, its use is OPTIONAL" has two available antecedents, and OPTIONAL adds
nothing, since nothing preceding it made the default rule mandatory - so it
reads as retracting the MUST rather than qualifying it. The INTDIR early
review flagged this ambiguity. And "avoid exporting the default rule across
inter-domain boundaries" restates, at advisory strength, the constraint that
the MUST has just imposed.

Perhaps:

  The default address mapping rule is optional. Where it is used, it
  SHOULD NOT be advertised across an administrative boundary unless the
  participating network providers have an explicit bilateral agreement
  covering its use. Network providers using a default egress PE should
  apply monitoring and rate-limiting or ACLs on that PE.

It is also worth asking whether the document wants a MUST here at all.

[Ballot discuss]
# Gorry Fairhurst WIT AD comments

Thank you for the work that has been put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

- Gorry

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 7:  Operational Considerations
The current text reads:
  "In addition, section 4.1 and section 5.1 of
  [RFC7915] give translators a SHOULD-level option to zero the TOS/
  Traffic Class octet entirely on translation ("administrative
  bleaching"), which silently kills ECN if an operator enables it for
  DSCP hygiene."

(1) Is it possible to avoid terms such as "DSCP hygiene", avoid "kills" (blocks?) and avoid/clarify that the term "TOS/Traffic Class octet" is Historic. I note that RFC 7915 refers to the former ToS Field" and introduces ToS semantics, this detail should be clarified in the present document, because such a policy is no longer applicable in 2026.

(2) I would like to discuss if this I-D can clearly state that other fields in the IPv4/IPv6 header ought to be mapped to corresponding values, in particular the DiffServ Field (subject to the filtering and update considerations of [RFC2475]) and the ECN Field. As per
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6146-bis/

[Ballot comment]
## COMMENTS (non-blocking)

### Section 7:  Operational Considerations

“Therefore, network providers must handle MTU and fragmentation issues, for example, by configuring appropriate MSS
clamping,"
- This is a TCP-specific mechanism, it would be super helpful to indicate that this is for "TCP".

[Ballot comment]
# IESG review of draft-ietf-v6ops-framework-md-ipv6only-underlay-27

CC @MikeBishop

## Comments

### Section 2, paragraph 1

This section expands common abbreviations, but doesn't point to
definitions of the expanded terms.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 2
```
-    IETF work focusing on IPv6 optimization”[IAB-statement].  To ensure
+    IETF work focusing on IPv6 optimization” [IAB-statement].  To ensure
+                                            +
```

[Ballot discuss]
I am travelling this review is pending, the treatment does not follow current BCPs, and therefore needs careful wording:

This text needs more consideration:
  In addition, section 4.1 and section 5.1 of
  [RFC7915] give translators a SHOULD-level option to zero the TOS/
  Traffic Class octet entirely on translation ("administrative
  bleaching"), which silently kills ECN if an operator enables it for
  DSCP hygiene.

The following Last Call announcement was sent out (ends 2026-06-22):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-framework-md-ipv6only-underlay@ietf.org, mjethanandani@gmail.com, ron@bonica.org, v6ops-chairs@ietf.org, v6ops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Framework for Multi-domain IPv6-only
Underlay Network and IPv4-as-a-
  Service'
  as Informational
  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 2026-06-22. 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


  For the IPv6 transition, IPv6-only is considered the final stage
  where only IPv6 protocol is used for transport while maintaining
  global reachability for both IPv6 and IPv4 services.  This document
  introduces a framework for a multi-domain IPv6-only underlay network
  from the perspective of network operators.  In particular, it
  proposes stateless address mapping as the basis for enabling IPv4
  service data transmission in a multi-domain IPv6-only environment
  (i.e., IPv4-as-a-Service).  It describes the methodology of stateless
  IPv4/IPv6 mapping, illustrates the behaviors of network devices,
  analyzes the options of IPv6 mapping prefix allocation, and discusses
  the security considerations.  This framework is not intended to
  replace existing IPv6-only technologies, but rather to leverage or
  remain compatible with them.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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 is strong consensus with many participants commenting over four years

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

While there was active debate, all issues have been resolved

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)?

This is not a protocol document

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

Most members of 6man also participate in v6ops. Many have commented on this draft

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]?

This document does not contain a YANG module

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.

The document contains no formal syntax. The document has been reviewed by the chairs, all of the people who commented on the draft, and me.

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

Yes

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?

As this is an OPS document, it requires no review other than that offered by 6man participants.

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?

INFORMATIONAL.

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.

All authors are aware of IPR responsibilities and have responded to the poll.

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. There are exactly five authors.

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

None

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

No

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

None

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.

No. This is an INFORMATIONAL RFC

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]).

As this is an operational document, there are no IANA actions requested

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.

None

[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.*

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 is strong consensus with many participants commenting over four years

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

While there was active debate, all issues have been resolved

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)?

This is not a protocol document

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

Most members of 6man also participate in v6ops. Many have commented on this draft

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]?

This document does not contain a YANG module

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.

The document contains no formal syntax. The document has been reviewed by the chairs, all of the people who commented on the draft, and me.

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

Yes

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?

As this is an OPS document, it requires no review other than that offered by 6man participants.

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?

INFORMATIONAL.

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.

All authors are aware of IPR responsibilities and have responded to the poll.

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. There are exactly five authors.

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

None

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

No

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

None

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.

No. This is an INFORMATIONAL RFC

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]).

As this is an operational document, there are no IANA actions requested

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.

None

[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.*

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 is strong consensus with many participants commenting over four years

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

While there was active debate, all issues have been resolved

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)?

This is not a protocol document

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

Most members of 6man also participate in v6ops. Many have commented on this draft

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]?

This document does not contain a YANG module

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.

The document contains no formal syntax. The prose have been reviewed by the chairs, all of the people who commented on the draft and me.

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

Yes

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?

As this is an OPS document, it requires no review other than that offered by 6man participants.

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?

INFORMATIONAL.

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.

All authors are aware of IPR responsibilities and have responded to the poll.

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. There are exactly five authors. One author is an AD and is expected to recuse on this document.

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

None

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

No

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

None

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.

No. This is an INFORMATIONAL RFC

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]).

As this is an operational document, there are no IANA actions requested

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.

None

[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.*

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 is strong consensus with many participants commenting over four years

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

While there was active debate, all issues have been resolved

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)?

This is not a protocol document

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

Most members of 6man also participate in v6ops. Many have commented on this draft

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]?

This document does not contain a YANG module

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.

The document contains no formal syntax. The prose have been reviewed by the chairs, all of the people who commented on the draft and me.

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

Almost ready. The chairs are requested to update the status in datatracker. The authors are requested to run the nit checker.

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?

As this is an OPS document, it requires no review other than that offered by 6man participants.

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?

INFORMATIONAL. The chairs are requested to change the status 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.

All authors are aware of IPR responsibilities and have responded to the poll.

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. There are exactly five authors. One author is an AD and is expected to recuse on this document.

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

No

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

No

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

None

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.

No. This is an INFORMATIONAL RFC

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]).

As this is an operational document, there are no IANA actions requested

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.

None

[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/