Early Review of draft-ietf-v6ops-framework-md-ipv6only-underlay-23
review-ietf-v6ops-framework-md-ipv6only-underlay-23-intdir-early-jinmei-2026-06-17-00

I am the assigned int-dir reviewer for this draft. For background on int-dir,
please see the FAQ (https://wiki.ietf.org/en/group/intdir). Please resolve
these comments along with any other comments you may receive.

I've read draft-ietf-v6ops-framework-md-ipv6only-underlay-23. It proposes an
architecture for a multi-operator IPv6-only network to support end-to-end IPv4
communication using stateless address mapping and prefix-based mapping
distribution.

Overall, the draft is well written. The problem description is clear, and the
proposed direction is reasonable. However, the architecture depends critically
on one aspect that is not sufficiently specified.

## Major Comment

As I read it, the key element of this architecture is the distribution of
IPv4-to-IPv6 address mapping rules across domains. While the draft appears to
assume the use of a specific mechanism (draft-ietf-idr-mpbgp-extension-4map6),
this is not clearly specified, and Section 5.2 explicitly allows for other
unspecified mechanisms.

This leaves a critical part of the architecture underspecified. Mapping rule
distribution is not a peripheral detail but a requirement for correctness and
interoperability across domains. Without a clearly defined mechanism (including
encoding, propagation, and consistency behavior), it is difficult to assess
whether the architecture is deployable in a multi-operator environment.

While different "multi-domain underlay" networks could in principle use
different distribution mechanisms, this would reduce interoperability between
domains and make it more difficult to interconnect multiple such networks into
a larger system. To that end, it may be preferable for this document to
normatively specify a distribution mechanism (e.g.,
draft-ietf-idr-mpbgp-extension-4map6), or at least clearly define the required
properties of any compliant mechanism.

## Minor Comments

### Section 3

> \[...] Figure 1 shows a multi-domain network, namely NP-1, which consists of
three interconnected ASes, i.e., AS1, AS2, and AS3.

This description is confusing, since NP-1 is earlier described as operating AS1
and AS2, while AS3 belongs to NP-2.

### Section 3

> \[...] Excessive IPv4-IPv6 conversion gateways introduce network complexity
and increases capital expenditures (CAPEX).

The term "CAPEX" is introduced but not reused. Consider removing.

### Section 5.2

> \[...] To mitigate this issue, the framework introduces a default egress PE,
which advertises a default address mapping rule to all other PEs.

The introduction of a default mapping rule (0.0.0.0/0) raises scalability and
security concerns that are not discussed at this point in the document. For
example:

- A default egress PE may become a concentration point for traffic and resource
consumption. - It introduces obvious traffic-attraction and hijacking risks.

While some security aspects are discussed later in Section 8.3, it would help
readers if these implications were briefly acknowledged here, with a forward
reference to the Security Considerations section. It is less clear whether the
scalability implications are fully addressed.

### Section 5.3

> 2. Encapsulation
>    \[...] the ingress PE will generate corresponding IPv6 source and
destination addresses from the IPv4 addresses, following the procedure
described in Section 4.1.

This text describes address derivation but does not explicitly describe the
encapsulation behavior itself (e.g., construction of the outer IPv6 header). It
would be helpful to clarify this.

Additionally, the document allows both translation and encapsulation but does
not provide guidance on when each should be used. In a multi-operator
environment, this flexibility may lead to interoperability issues if different
domains make different choices. It would be useful to either:

- define interoperability requirements between the two modes, or
- provide guidance on their usage.

### Section 6

> \[...] For any PE device, its IPv6 mapping prefix is part of a larger and
routable IPv6 address prefix previously assigned, if Pref6(PE) is allocated
from a prefix that is already advertised with a next hop that reaches that PE
(or its site), additional FIB entries in the IPv6 core may be avoided.

This sentence is difficult to parse. It appears to be expressing the following
idea:

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

If this interpretation is correct, consider rewriting the original text
accordingly.

### Section 8.3

> To mitigate these issues, the default rule (0.0.0.0/0:Pref6(PE)) is OPTIONAL
and is only used within a single administrative domain unless explicit
bilateral policy exists.

This sentence is ambiguous regarding what is OPTIONAL. A possible
interpretation is:

- The default rule MUST only be used within a single administrative domain
unless explicit bilateral policy exists; and - Even in those cases, its use is
OPTIONAL.

If this is the intended meaning, consider rewriting as:

> To mitigate these issues, the default rule MUST only be used within a single
administrative domain unless explicit bilateral policy exists. Even in those
cases, its use is OPTIONAL.