Framework for Multi-domain IPv6-only Network and IPv4-as-a-Service

Introduction 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. As of this writing, most IPv6 deployments rely on dual-stack . Dual- stack has long- term drawbacks, including duplicated network resources and states, as well as increased operational complexity from maintaining both protocol stacks. In 2016, the IAB stated that it "expects the IETF to no longer mandate IPv4 compatibility in new or updated protocols, with future IETF work focusing on IPv6 optimization" . To ensure service continuity, network operators require that the network maintains access to the global IPv4 Internet when deploying IPv6-only. This practice is commonly referred to as "IPv4-as-a-Service" and is a logical approach for IPv6-only networks . To avoid confusion when using the term "IPv6-only" in IETF and other documents, provides a definition of "IPv6-only". This document uses the term "IPv6-only network" as defined in . The network infrastructure of large network operators typically consists of at least an access network and a backbone network. The access network serves customers by delivering access links, assigning addresses, and enabling two-way data transmission. The backbone network is typically a multi-domain network comprising interconnected Autonomous Systems (ASes). The backbone network is sometimes referred to as the core network. Accordingly, IPv6-only deployment involves two key parts: IPv6-only in the access network and IPv6-only in the backbone network. For the IPv6-only deployment in the access network, various transition technologies such as 464XLAT , MAP-T , MAP-E , and DS-Lite have been developed and deployed . These solutions allow network operators to allocate only IPv6 addresses to customer terminals or networks, while some public IPv4 addresses are shared on the network side to enable users to access IPv4 Internet services. However, the current IPv6-only ecosystem remains incomplete, particularly in backbone networks. For large-scale network operators, a comprehensive multi-domain IPv6-only framework is needed that integrates multiple related technologies to ensure seamless IPv4 and IPv6 data transmission. presents the softwire problem statement, identifying the requirement for tunneling IPv4 over IPv6 (i.e., ) across an IPv6-only backbone. addresses the fundamental problem of connecting IPv4 islands across an IPv6-only transit core. However, as stated in Section 12 of , its procedures do not function as specified when the transit core consists of multiple Autonomous Systems. defines a BGP/MPLS-based IP VPN scheme. On the control plane, it uses BGP to distribute VPN routes; on the data plane, it relies on MPLS label forwarding, where the outer label identifies the inter-PE tunnel and the inner label identifies the VPN instance. It aims to provide scalable and isolated VPNs over a shared backbone, rather than to address how to carry the remaining IPv4 services in an IPv6-only environment. While access-side IPv6-only solutions have matured, the backbone network side lacks a comparable framework, which is the focus of this document. This document presents an operational and deployment framework for building a multi-AS IPv6-only network and for coordinating the IPv4 and IPv6 address spaces from the perspective of network operators. This multi-AS IPv6-only network may be operated by a single network operator or by multiple cooperating network operators under mutual agreement. For IPv4-as-a- Service, this framework proposes an address-mapping-based mechanism that performs packet translation at the network edge. An alternative realization encapsulates IPv4 in IPv6 using the same address mapping approach. While the primary focus of this document is the translation-based approach, encapsulation aspects are discussed where relevant. With such a framework, IPv4/IPv6 packet conversion relies on stateless address mapping at the edges, meaning no user-specific state or translation tables are required for packet processing, and no IPv4-to-IPv6 conversion gateway is needed along the data path. The document serves as a problem statement, provides guidance, and defines a set of requirements for network operators, rather than as a protocol specification. The remainder of this document is organized as follows. defines terminology used throughout this document. describes the scope and applicability of multi-domain IPv6-only deployment. introduces the IPv4/IPv6 address mapping mechanism for IPv4-as-a-Service. presents the overall framework, including address mapping rule processing, packet conversion, and conversion capability selection. discusses IPv6 mapping prefix allocation. Sections 7 through 9 address operational, manageability, and security considerations, respectively. discusses IANA considerations. Sections 11 and 12 provide acknowledgements and contributors.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are used in this document:

Address mapping rule

The mapping relationship between an IPv4 address block and its corresponding IPv6 mapping prefix in an IPv6-only network.

AS

Autonomous System, this term refers to a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes.

BR

Border Router, a router located at the edge of an AS.

CE

Customer Edge, customer devices attached, via some sort of attachment circuit, to one or more Provider Edge (PE) routers.

DC

Data Center, a physical complex housing physical servers, network switches and routers, network service appliances, and networked storage. The purpose of a data center is to provide application, compute, and/or storage services.

Default egress PE

A designated PE that advertises a default address mapping rule (0.0.0.0/0) to all other PEs, serving as a fallback for IPv4 traffic whose destination lacks a more specific mapping rule in the ingress PE's MR-DB.

Default mapping rule

An address mapping rule with the IPv4 address block 0.0.0.0/0, advertised by the default egress PE, ensuring that IPv4 traffic is not dropped due to missing mapping information.

Egress PE

The PE router where a packet exits the IPv6-only core network. The egress PE reconstructs the original IPv4 packet from the received IPv4-embedded IPv6 packet and forwards it toward the IPv4 destination.

Conversion Type field

An attribute of an address mapping rule that indicates the PE's IPv4/IPv6 conversion capability. The structure and semantics of this field are defined by the specific protocol(s) used for rule distribution.

IPv4-embedded IPv6 address

An IPv6 address formed by a variable- length prefix, a zero-u-octet (bits 64-71), an embedded 32-bit IPv4 address, and a variable-length zero suffix, as defined in Section 2.2 of .

IPv4-embedded IPv6 packet

An IPv6 packet created through translation of an IPv4 packet, where the source and destination IPv4 addresses are statelessly mapped to corresponding IPv6 addresses.

IPv6-only network

Refers specifically to an "IPv6-only core network", where the forwarding plane and transport infrastructure support only IPv6.

IPv6 mapping prefix

A specific IPv6 prefix allocated to a PE device. It is used to construct an IPv4-embedded IPv6 address by combining with an IPv4 address, as described in Section 4.1 of this document.

Ingress PE

The PE router where a packet enters the IPv6-only core network. The ingress PE converts the IPv4 packet into an IPv4-embedded IPv6 packet for forwarding across the core network.

MR-DB

Mapping Rule DataBase, a database which stores the address mapping rules at the PE router.

Multi-domain IPv6-only core network

IPv6-only core network which consists of multiple ASes operated by single or multiple network operators.

NSP

Network-Specific Prefix, as defined in ; it refers to an IPv6 prefix assigned by an organization for use in algorithmic mapping.

P Provider Router, a router in the network operator's network that does not attach to CE devices.

PE

Provider Edge, a device at the edge of the IPv6-only core network, providing the functionality required for IPv4-as- a-Service.

Pref6(PE)

The IPv6 mapping prefix assigned to a specific Provider Edge (PE) device. This prefix uniquely identifies the PE within the IPv6-only core network and is used by other PEs to determine the correct egress PE for an IPv4-over-IPv6 flow.

UE

User Equipment, e.g., mobile phone.

IPv6-only Deployment in Multi-domain Network This framework is designed to assist large network operators in deploying IPv6-only networks in a multi-domain environment. Large- scale network operators usually manage network infrastructure comprising multiple interconnected Autonomous Systems (ASes). This is referred to as a "Multi-domain Core Network" in this document. These ASes often support different functions, such as metro area networks, backbone networks, 4G/5G mobile core networks, Data Centers (DCs), and may be administered by separate departments or network operators with different routing and security policies. In a multi- domain network environment, edge nodes are commonly referred to as Provider Edge (PE) routers. The ingress PE is the router where a packet enters the network, while the egress PE is the router where it exits. Internal nodes are typically called Provider (P) routers. As some Internet services may remain IPv4-based even in an IPv6-dominated environment, an IPv6-only network needs to support access to IPv4-only services, as well as IPv6 services. describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on and , along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. Since it is based on the OSPF protocol, it supports IPv4-as-a-Service within a single AS. To facilitate the illustration of the framework from the perspective of network operators, Figure 1 shows a multi-domain network, which consists of three interconnected ASes, i.e., AS1, AS2, and AS3. Among them, AS1 and AS2 are operated by Operator 1, AS3 is operated by Operator 2. Routers located outside the backbone but directly connected to it are referred to as Customer Edge (CE) routers. AS1 of Operator 1 provides connectivity services to mobile, home broadband, and enterprise customers, represented by CE1, CE2, and CE3, respectively. defines IPv4 service continuity requirements for IPv6 CE routers, extending the basic IPv6 CE specifications to support IPv4 delivery in IPv6-only access networks. Additionally, service instances in DCs often require cross-site communication, whether on- premises or in external data centers. A multi-domain network needs to facilitate these data center connections. Operator 1 needs to support at least two connectivity modes for data centers: The first is between a data center and individual users, for instance, a user of CE1 accesses a service instance hosted in DC1; the second is between data centers, for instance, communications occur between service instances hosted in DC1 and DC2, respectively. Regarding external interconnection, Operator 3 is a neighboring network of Operator 2. AS4 of Operator 3 is an IPv4-only network and does not support IPv6. The interconnection protocol between AS3 and AS4 is BGP that supports IPv4 route advertisement.

An Example of a Multi-domain Core Network For Operator 1, deploying IPv6-only without a unified framework may lead to independent adoption of IPv6 transition approaches across different ASes. This can result in multiple IPv6-only islands interconnected by IPv4 links between domains. Furthermore, the network may operate multiple IPv4/IPv6 packet conversion gateways with varying functionalities. For a given AS, incoming IPv4 packets are converted to IPv6 at an ingress, then reverted to IPv4 at an egress. When the IPv4 packets reach the next AS, another round of IPv4 -> IPv6 -> IPv4 packet conversion is carried out. Excessive IPv4/IPv6 conversion gateways introduce network complexity and increase capital expenditures. Thus, a unified framework is required to define network edge behavior for IPv4 service delivery and eliminate unnecessary IPv4/IPv6 conversion gateways within the multi- domain network. For IPv6-only deployment guided by a unified framework, IPv4 protocol instances are gradually disabled and IPv6 will be the primary network-layer protocol. Specifically, core P routers, such as P1, P2, P3, and P4, operate only IPv6 protocol, while PE routers, such as PE1, PE2, PE3, and PE4, support IPv4 protocol on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core, requiring them to handle both address families. Operator 1 transports packets that originate and terminate outside the network. These packets enter the IPv6 network at a PE router, traverse the network, and exit through another PE router to continue their path.

Scope of Applicability This subsection defines the intended deployment scope, the trust assumptions, and the boundary of the framework. Maximum scope of deployment: This framework targets a multi-domain IPv6-only core network composed of multiple interconnected IPv6-only ASes, which may be operated by a single network operator or multiple cooperating network operators with mutual agreement. The framework is not intended to cover the Internet, and it MUST NOT affect the operation of the existing IPv4 Internet or IPv6 Internet. Address mapping rules are advertised but are not propagated over the Internet. Trust relationship among participating network operators: Participating network operators are assumed to have a pre- existing trust relationship, including bilateral agreements, coordinated mapping-prefix allocation, common ICMP filtering rules, and trusted ingress PEs. These assumptions are prerequisites for deployment, not properties that the framework itself establishes. Boundary of the framework: The framework boundary is the edge of the participating IPv6-only core network. Mapping prefixes are not advertised outside this boundary. Reachability of mapping prefixes outside the boundary: Mapping prefixes are intended to be reachable only within the participating domain. They are not intended to be reachable from the global IPv4 Internet or from non-participating networks. Border routers at the framework boundary MUST filter mapping prefixes to prevent leakage outside the participating domain. Filtering at the boundary: The following filtering requirements apply at the framework boundary:

Ingress and egress filtering of mapping prefixes to prevent leakage outside the participating domain;
Source validation for traffic entering and leaving the core network;
Consistent ICMP filtering rules across participating network operators;
Prevention of default egress use for non-participating destinations.

This framework may be considered a limited-domain mechanism as described in . The operational, routing, and security analyses in this document are based on the assumption of a limited domain with cooperating parties, not an open capability reaching the global IPv4 Internet. Existing technologies such as 464XLAT , MAP-T , MAP-E , and DS-Lite are single-administration access technologies where mapping rules are provisioned rather than exchanged, and each has one well-defined edge to the rest of the Internet. This framework addresses multi-domain backbone networks where mapping rules are exchanged across AS boundaries, which is a complementary rather than substitutive scenario. The Softwire Mesh Framework addresses the fundamental problem of connecting IPv4 islands across an IPv6-only transit core. However, as stated in Section 12 of , its procedures do not work as specified when the transit core consists of multiple ASes. addresses IPv4 NLRI with IPv6 next-hop in BGP, but does not define mapping-prefix uniqueness, boundary filtering, or default- egress behavior in a multi-AS IPv6-only core network. This framework targets the multi-AS environment that is not adequately covered by these existing specifications, and provides the operational considerations and requirements for such deployments.

IPv4/IPv6 Address Mapping for IPv4-as-a-Service

IPv4/IPv6 Address Mapping To support IPv4-as-a-Service in a multi-domain IPv6-only network, the framework proposes that each PE device be allocated and identified by at least one IPv6 mapping prefix, denoted by Pref6(PE). In addition, this framework uses an attribute named "Conversion Type field" to indicate the PE's IPv4/IPv6 conversion capability (e.g., the type(s) of conversion mechanisms the egress PE supports). Each PE device will also have one or more associated IPv4 address blocks which are extracted from local IPv4 routing table or address pool. The mapping relationship can be represented at a minimum by the following data structure.

: IPv4 address block: Pref6(PE)

The address mapping rule comprises the aforementioned data structure and a Conversion Type field. The Conversion Type field indicates the PE's IPv4/IPv6 conversion capability. The structure and semantics of the Conversion Type field, including whether it indicates conversion capabilities beyond the stateless translation specified in this document, are out of the scope of this document and are expected to be defined by the specific protocol(s) used for rule distribution. For an IPv4 packet traversing a multi-domain IPv6-only network, the address mapping rule for the destination address determines the egress PE from which the packet leaves the IPv6-only domain. When the address mapping rule corresponding to the destination address of a given IPv4 packet is available, the ingress PE can generate corresponding IPv6 source and destination addresses from the packet's IPv4 source and destination address as below. The explicit process of converting an IPv4 packet into an IPv6 packet is described in .

The IPv6 source address is derived from an IPv6 mapping prefix that is assigned to the ingress PE and has been advertised via the mapping rule distribution mechanism, using the address construction algorithm specified in Section 2.2. When more than one such mapping prefix is assigned to the ingress PE, the selection of the prefix to use for a given packet is a matter of local policy, but the selected prefix MUST be one that has been advertised for the relevant mapping domain. Network operators SHOULD define a clear policy for selecting which prefix to use as the source when constructing IPv4-embedded IPv6 packets. The selection may be based on, for example, the egress PE's domain (e.g., intra-provider vs. inter-provider), the destination domain, the type of service, or other administrative boundaries. However, this document does not mandate a single selection algorithm or approach, but expects network operators to develop and refine their strategies based on operational needs.
The IPv6 destination address is derived from an IPv6 mapping prefix that has been advertised via the mapping rule distribution mechanism, using the address construction algorithm specified in Section 2.2.

For example, if the ingress PE's mapping prefix is 2001:db8:1::/96 and the source IPv4 address is 192.0.2.1, the source IPv6 address is 2001:db8:1::192.0.2.1. If the destination IPv4 address is 198.51.100.1 and the egress PE's mapping prefix is 2001:db8:2::/96, the destination IPv6 address is 2001:db8:2::198.51.100.1. At the egress PE, the IPv4 address is extracted from the IPv4-embedded IPv6 address following Section 2.3. This document does not define any additional validation of the suffix or u-bit beyond what specifies. Since the address mapping rule adopts prefix-level mapping, there is no need to maintain user-related status or translation tables for packet conversion at the PE devices. This framework proposes to algorithmically translate an IPv4 address to a corresponding IPv6 address, and vice versa, using only statically configured information. The IPv6 address translated from an IPv4 address is called an IPv4-embedded IPv6 address, which has been defined in . As shown in Section 2.2 of , IPv4-embedded IPv6 addresses are composed of a variable-length prefix, a zero u-octet (bits 64-71), the embedded IPv4 address, and a variable-length suffix. Table 1 shows examples of IPv4-embedded IPv6 addresses constructed according to Section 2.2 of . It is the same as Table 1 of , except that the first column is referred to as the "IPv6 mapping prefix" rather than the "Network-Specific Prefix". Representation Examples of IPv4-Embedded IPv6 Addresses

IPv6 mapping prefix	IPv4 address	IPv4-embedded IPv6 address
2001:db8::/32	192.0.2.33	2001:db8:c000:221::
2001:db8:100::/40	192.0.2.33	2001:db8:1c0:2:21::
2001:db8:122::/48	192.0.2.33	2001:db8:122:c000:2:2100::
2001:db8:122:300::/56	192.0.2.33	2001:db8:122:3c0:0:221::
2001:db8:122:344::/64	192.0.2.33	2001:db8:122:344:c0:2:2100::
2001:db8:122:344::/96	192.0.2.33	2001:db8:122:344::192.0.2.33

Prior to IPv4/IPv6 packet conversion, an ingress PE needs to obtain the address mapping rule for the destination address within or across domains. To meet this requirement, a specific mechanism of address mapping rule exchange needs to be designed, so an egress PE can inform other PEs that an IPv4 packet with a destination address being within a specific IPv4 address block can be forwarded to itself directly. addresses are allowed by this framework, and customers can use addresses inside their own networks. prefixes used by different customers can be differentiated by assigning different IPv6 mapping prefixes to different customers at the edge of the IPv6-only core network.

End-to-End IPv4 Service Delivery To enable IPv4 service data forwarding in a multi-domain IPv6-only network, IPv4 packets need to be converted to IPv6 packets at the PEs located at the edge of the network. This framework specifies stateless IPv4/IPv6 address translation, which is used for packet translation at the data layer. Encapsulating IPv4 in IPv6 across a multi-AS core using the same address-mapping approach is an alternative realization. The subsequent text in this document mainly elaborates on the packet translation mode. Consider the network shown in Figure 1, when an ingress PE, e.g., PE1, receives an IPv4 packet (destined for a remote IPv4 network, e.g., Operator 3) from a client-facing interface, it queries its mapping rule database (i.e., MR-DB) to find the rule that longest- prefix matches the packet's destination IPv4 address. The IPv6 mapping prefix in the rule identifies the corresponding egress PE. In this case, the ingress and egress PEs reside in different autonomous systems (ASes): the ingress PE (PE1) is in AS1 of Operator 1, while the egress PE (PE3) is in AS3 of Operator 2. The ingress PE converts the IPv4 destination address into an IPv6 address using PE3's IPv6 mapping prefix and forwards the IPv6 packet to PE3. Upon receiving the IPv6 packet, PE3 extracts the original IPv4 source and destination addresses from the IPv4-embedded IPv6 addresses and reconstructs the IPv4 packet. The packet is then forwarded to Operator 3 based on the IPv4 routing table maintained at PE3. In this case, only the ingress/egress PEs, i.e. PE1 and PE3, convert packets, intermediate P routers just forward, so the overhead introduced by IPv4/IPv6 packet header transformation is incurred once, not per-AS-hop, as shown in Figure 2.

End-to-end IPv4 Service Delivery from Ingress to Egress | | | | +--+ +--+ +--+ | | / \ / \ / \ | +--+ +----+ | | AS1 | | AS2 | | AS3 | | / \ |UE/ |-----PE1 P1---P2 P3---P4 PE3---| IPv4 | |CE | | IPv6 | | IPv6 | | IPv6 | \Op-3/ +----+ \ / \ / \ / +--+ +--+ +--+ +--+ ]]> It should be noted that P3 and P4 are P routers from the perspective of the framework defined by this document, although they are the edges of providers' networks.

Framework Overview

Outline This section outlines the multi-domain IPv6-only core network framework from the perspective of network operators. As shown in Figure 1, the framework consists of edge PE devices, core P devices, and customer-side IPv4 routers. The PE devices are responsible for performing stateless IPv4/IPv6 packet conversion and will support the following functions:

Address Mapping Rule Processing
- Generate and manage the address mapping rules
- Exchange the address mapping rules across an IPv6-only network
Packet Conversion
- Generate IPv4-embedded IPv6 packets using translation
- Recover IPv4 packets from IPv4-embedded IPv6 packets via translation.

Address Mapping Rule Processing Within PE devices, processing of IPv4/IPv6 address mapping rules includes two steps,

Generation For IPv4 service delivery, IPv4/IPv6 address mapping rules need to be generated. In the network shown in Figure 1, when PE3 receives an IPv4 route advertisement from an IPv4 border router, e.g., BR1, it extracts IPv4 address blocks and generates address mapping rules by combining them with its own IPv6 mapping prefix. All the address mapping rules, whether locally generated or received from other PEs, are stored in its local MR-DB. PE devices also support rule management operations, such as insertion, modification, and deletion of address mapping rules. A PE originates mapping rules only for IPv4 address blocks for which it serves as the authoritative or aggregating egress point. These blocks include, but are not limited to, its directly connected customer prefixes, locally provisioned address pools, and site aggregates. A PE MUST NOT originate per-prefix mapping rules for transit routes learned from other PEs of the multi-domain network. Traffic destined for all other IPv4 addresses (i.e., the remainder of the global IPv4 space) is covered by a default mapping rule pointing to a configured default egress PE. When multiple mapping rules match the same IPv4 destination address block (e.g., due to multihoming or anycast services), the ingress PE can select the single best rule; this process depends on its specific underlying mechanism for rule distribution. If a routing protocol is used for rule distribution, the selection can follow that protocol's best-path selection procedure. However, the detailed process is beyond the scope of this document. Multipath forwarding (i.e., load balancing across multiple egress PEs) is not considered in this framework. Anycast egress is also not supported in this framework. If the address mapping rule of a certain IPv4 address block has not been received by the ingress PE, the IPv4 service data destined for that IPv4 address block will not be forwarded to the correct egress PE. To mitigate this issue, the framework introduces a default egress PE, which advertises a default address mapping rule to all other PEs. The format of default address mapping rule is as follows:

: 0.0.0.0/0: Pref6(PE)

The default rule associated with the designated default egress PE serves as a fallback mechanism to ensure connectivity when a more specific address mapping rule for a given IPv4 destination is not available in the ingress PE's MR-DB. When such a rule is present, the ingress PE forwards the corresponding IPv4-embedded IPv6 packets to the default egress PE. This ensures that IPv4 traffic is not dropped due to missing mapping information, though it may lead to suboptimal forwarding paths. Operators should carefully consider the placement and capacity of the default egress PE to avoid congestion or single points of failure. The introduction of the default address mapping rule in an IPv6-only network will cause some IPv4 service traffic to be attracted to the default egress PE, which may introduce security implications, such as hijack risk; discussion on this aspect can be found in . Under the rule-origination policy above, an egress PE will generate mapping entries only for locally significant IPv4 prefixes -- i.e., its own customer blocks, address pools, and site aggregates. The default egress PE mechanism covers all non-local traffic, preventing unbounded MR-DB growth. This ensures that MR-DB lookups, synchronization, and rule management impose minimal overhead on PE control and data planes, making the design operationally manageable even in networks with complex external peering. In typical deployments, this yields an MR-DB size on the order of tens to a few hundred entries, substantially smaller than the global routing table.

Distribution Address mapping rules generated on a PE device need to be distributed to PE devices in other domains. During the transmission of these rules, the key information elements, including the Conversion Type field mentioned in , MUST NOT be modified by any intermediate node. The distribution mechanism should be designed with the goal of supporting scalability across multiple independently administered network operators. This process can be implemented through the routing process. When an address mapping rule is generated locally, the PE device converts it into a data structure and forwards it to the routing engine for transmission. In the opposite direction, upon receiving a routing announcement with an address mapping rule from a neighboring router, the PE device extracts and stores it in its MR-DB. The specific protocol extensions required for address mapping rule transmission are outside the scope of this document. Based on the received mapping rule, the ingress PE can identify the appropriate egress PE (i.e., the Pref6(PE) to use as the destination prefix).

Properties of Conforming Rule Distribution Mechanisms Any conforming mapping-rule distribution mechanism MUST provide the following properties:

Field integrity: The key information elements of an address mapping rule, including the Conversion Type field, MUST NOT be modified by any intermediate node during transit.
Scoping and filtering: The distribution mechanism MUST support scoping and filtering of mapping rules at administrative boundaries. Mapping rules SHOULD NOT be propagated outside the participating domain.
Origin authentication: The distribution mechanism MUST support origin authentication. Specifically, any distribution mechanism that conforms to this framework and is used to distribute mapping rules SHOULD be capable of verifying the authentic origin of the mapping rules, thereby ensuring the legitimacy and trustworthiness of their source.
Rule rejection: PE devices SHOULD reject unauthorized mapping rules. Specifically, when a mapping rule attempts to bind an IPv4 address block to a mapping prefix that is not within the authorized scope of that address block, the PE device MUST detect such a violation and explicitly reject the mapping rule.

Packet Conversion and Transmission In this framework, the PE devices provide forwarding capability to IPv4-embedded IPv6 packets for IPv4 data delivery. IPv4-embedded IPv6 packets are generated using translation, which refers to the packet conversion from one protocol format to the other. When the ingress PE receives an IPv4 packet from its neighboring IPv4 network, it looks for an address mapping rule for the packet's IPv4 destination address; if such a rule is found, it generates the corresponding IPv6 source and destination addresses from the IPv4 addresses, following the procedure described in . This process complies with . For IPv4-embedded IPv6 packets, the Pref6 part of the IPv6 destination address identifies the egress point. Therefore, packet forwarding can be performed by P devices solely based on the Pref6 part of the destination address. Upon receiving the IPv6 packet, the egress PE processes the packet according to the following cases:

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 address DOES match, but the source address is NOT a valid IPv4-embedded IPv6 address (i.e., its IPv6 prefix portion is NOT formed from the mapping prefix of an authorized ingress PE, or its embedded IPv4 source is NOT consistent with the mapping rule or policy assigned to that ingress PE, or the packet did NOT arrive from the expected participating network; see ): The packet MUST be discarded, and implementations SHOULD maintain a counter for such drops for operational visibility and security monitoring.
If BOTH the destination matches AND the source is a valid IPv4-embedded IPv6 address: The egress PE translates the IPv4-embedded IPv6 packet and restores the original IPv4 packet. This process complies with . The IPv4 packet is then forwarded based on the IPv4 routing information maintained at the egress PE.

Source-address validation is described in .

Conversion Capability Selection When a rule-distribution protocol defines more than one conversion capability (e.g., translation and encapsulation), the selection of the conversion mechanism between the ingress PE and the egress PE is defined by that protocol and local policy, and is out of the scope of this document. This document specifies stateless translation as the conversion mechanism of the framework; the behavior of any additional conversion capability and its selection is expected to be defined in the specific protocol(s) used for rule distribution.

IPv6 Mapping Prefix Allocation As shown in , IPv6 mapping prefixes are used by PEs to generate address mapping rules for the IPv4 address blocks they serve (see ). These prefixes are unique within the multi- domain network, and they are to be allocated from the NSPs. An NSP refers to a dedicated IPv6 prefix (or a set of prefixes) assigned from a network operator's available IPv6 address pool for IPv4 address mapping. For an IPv6-only network, one or more distinct IPv6 mapping prefixes are assigned to each PE device. 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. This sub-prefix allocation MAY be deviated from only when the mapping prefix itself is advertised as a more-specific route within the participating domain, so that IPv6 reachability to the originating PE is established without relying on the covering aggregate. The IPv6 mapping prefix MUST be one of the lengths permitted by Section 2.2, i.e., /32, /40, /48, /56, /64, or /96. When the prefix length is less than 96 bits, the bits after the embedded IPv4 address are defined in Section 2.2 as the suffix. The value of the suffix and the u-bit follows ; in particular, for the well-known prefix case the u-bit is set to 0 and the remaining suffix bits are 0, but the exact value is as specified in . Guidance on prefix length selection can be found in Section 3.3 of . From the perspective of network operations, having all IPv6 mapping prefixes share the same length during deployment will likely avoid the unnecessary processing cost and complexity caused by prefix length diversity. The IPv6 mapping prefix Pref6(PE) MUST be selected from the IPv6 address block owned by the egress PE. The IPv6 route for a mapping prefix MUST terminate at the PE that originated the mapping rule. Reachability through a covering aggregate alone does not establish that IPv4-embedded IPv6 packets reach the PE that originated the rule; network operators MUST ensure that the covering aggregate resolves specifically to the originating PE before relying on it. A mapping rule is only usable while its Pref6(PE) recursively resolves to a valid IPv6 route reaching the correct egress. When that reachability is lost, the mapping rule MUST be withdrawn or deactivated. Traffic MUST NOT continue to be forwarded using a mapping rule whose Pref6(PE) is unreachable. The exact mechanism (withdraw, deactivate, or fall back to another egress) is a local policy decision, but the stale mapping rule MUST NOT be used. A PE MUST NOT forward an IPv4-embedded IPv6 packet using a mapping rule whose Pref6(PE) does not recursively resolve to a valid IPv6 route reaching the originating egress PE. When a PE receives an IPv4-embedded IPv6 packet whose destination IPv6 prefix matches one of the PE's own IPv6 mapping prefixes, the PE checks whether its MR- DB contains a locally originated mapping rule covering the destination IPv4 address; if no such rule exists, the PE MUST drop the packet and MAY generate an ICMPv6 Destination Unreachable error. For this check, the default mapping rule (0.0.0.0/0) counts as a locally originated rule only on the default egress PE itself; a receiving PE MUST NOT count a received default rule as a locally originated rule for this purpose, so that the drop above cannot be bypassed merely because a default rule is present in the MR-DB.

Operational Considerations MTU configuration MUST be given consideration when deploying IPv6-only in a multi-domain network. When IPv4 packets are translated (as specified in ), the IPv6 header is 20 octets larger than the IPv4 header in the best case; however, the overhead is not fixed. As per , a Fragment Header (8 octets) is additionally inserted 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. Moreover, IPv4 options, if present, contribute further overhead (hence Section 1.4 uses "20+ octets"). Operators provisioning headroom for MTU MUST therefore account for up to 28 octets of translation overhead, plus any IPv4 options that may be present. In a multi-domain network traversing multiple ASes, MTU differences between domains are likely to cause silent packet drops or performance degradation -- a fundamental operational concern for any IPv4-over-IPv6 framework. Therefore, network operators MUST handle MTU and fragmentation issues, for example, by configuring appropriate MSS clamping for TCP connections, ensuring consistent MTU across domains, or following the recommendations in Section 1.4 of for general MTU/ fragmentation handling, and Sections 4.2 and 5.2 for specific ICMP translation handling. A concrete recommendation is to provision an IPv6-only core MTU of at least 1548 bytes (1500-byte IPv4 payload + 40-byte IPv6 header + 8-byte Fragment Header) to allow a 1500-byte IPv4 packet to traverse without fragmentation in the common translation case. One potential risk specific to multi-domain is Path MTU Discovery reliability. An ICMPv6 Type 2 (Packet Too Big) message from a P router in one IPv6 carrier's AS has to reach the originating IPv4 host across administrative boundaries with independent ICMP-filtering policies. In this case, IPv4 hosts may not receive "Packet Too Big" notifications, and will keep trying to send large packets. These packets will then be repeatedly dropped along the path, ultimately leading to connection interruptions or severe performance degradation -- forming a "PMTUD black hole." This issue has been mentioned in . In this framework, ingress PEs MUST implement the complete behavior specified in . To hand an ICMPv4 message to the IPv4 host, the ingress PE MUST translate ICMPv6 to ICMPv4 per Sections 5.2 and 5.3 and synthesize an IPv4 source address for it -- a case for which points to .

Manageability Considerations This section outlines manageability considerations for the framework, covering MR-DB monitoring, PE behavior upon rule withdrawal, and OAM considerations. These are presented as considerations rather than mandates, to be adapted by network operators based on their specific deployment requirements.

MR-DB Consistency Monitoring Each PE maintains a local MR-DB containing address mapping rules. The following capabilities are RECOMMENDED:

Each mapping rule should be identifiable by a version or timestamp to allow comparison of rule freshness across PEs.
PEs should be able to exchange MR-DB summary information to verify rule set consistency.
PEs should generate notifications upon significant MR-DB changes (addition, modification, or withdrawal of a mapping rule).
PEs should maintain counters for packets forwarded using each mapping rule to enable detection of anomalies (e.g., sustained high volume through a default rule may indicate missing explicit rules).
The MR-DB should be accessible via management interfaces (e.g., NETCONF/YANG) for query and audit purposes.

Behavior on Mapping Rule Withdrawal When a mapping rule is withdrawn, the following behaviors are RECOMMENDED:

The withdrawn rule should be removed immediately and not used for new packet conversions.
A configurable graceful period (on the order of seconds) may be supported for packets already in the forwarding pipeline to avoid disrupting established sessions.
If no explicit rule exists for a destination, the packet should be forwarded via the default mapping rule if configured; otherwise, it should be dropped and an ICMP/ICMPv6 error generated.
A notification should be generated upon rule withdrawal, including the affected IPv4 prefix and the reason.

OAM Requirements

ICMP/ICMPv6 Error Handling When a core P router generates an ICMPv6 error message destined to an IPv4-embedded IPv6 address, the message SHOULD be forwarded to the ingress PE identified by the source mapping prefix. Upon receiving such a message, the ingress PE SHOULD translate it to the corresponding ICMP message and forward it toward the original IPv4 source, in compliance with . Inter-provider SLAs SHOULD permit such ICMPv6 messages to traverse administrative boundaries to avoid PMTUD black holes.

Connectivity Verification Operators should be able to initiate diagnostic probes (e.g., ping, traceroute) from an ingress PE to an IPv4 destination behind a remote egress PE. These tools should support tracing the full path across the IPv6 core network. Each PE should support a diagnostic mode to verify local translation functions using test packets.

Performance Monitoring The following metrics should be monitored at PE devices:

Conversion latency
Packet drop rate due to MR-DB lookup failures
Throughput per egress PE prefix

Operators should establish baselines and alerts for significant deviations.

Cross-Domain Coordination For multi-domain deployments, the following coordination is RECOMMENDED:

Inter-provider SLAs should include provisions for ICMPv6 traversal across administrative boundaries and cooperative troubleshooting.
Out-of-band communication channels should be established for coordinating on inter-domain issues.
PEs should report the reachability and health of their mapping rules to a central management system for unified monitoring.

Security Considerations Besides regular security checks on configured address mapping rules, the following aspects need to be considered.

Authenticity and Integrity of Packets 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. After the egress PE receives IPv4-embedded IPv6 packets, it converts them into IPv4 packets and forwards them into the IPv4 Internet. If IPv6 packets cannot guarantee their authenticity or integrity, then there may be a spoofing attack. A malicious ingress PE could send IPv6 packets converted from IPv4 packets to attack an egress PE. Since the PEs in this framework are stateless, even when receiving large-volume traffic flows, they will not increase mapping session counts within the device like a stateful NAT device would. Even if no per-flow state exists, it should be acknowledged that in some extreme cases PEs can possibly be overwhelmed by bandwidth exhaustion, packet-rate/ CPU exhaustion, MR-DB lookup pressure, or queue/buffer exhaustion. To mitigate these issues, measures such as rate limiting, ACLs between PEs, or provision validation can be applied for actual deployment. Source address validation at the egress PE is described in .

Source Address Validation As stated in Section 5.1 of , an attacker could use an IPv4-embedded IPv6 address as the source address of malicious packets. After translation, the packets will appear as IPv4 packets from the specified source, and the attacker may be hard to track. If left without mitigation, the attack would allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. To prevent source-address spoofing, an egress PE MUST validate the IPv6 source of IPv4-embedded IPv6 packets. In particular, it MUST accept such a packet only if:

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

This validation can be implemented using reverse-path checks (e.g., uRPF) and/or policy checks against the ingress PE's advertised mapping rule, and can be performed statelessly. Packets that fail validation MUST be discarded and, where appropriate, logged or counted for operational purposes. Mapping prefixes SHOULD be filtered at the framework boundary to prevent external spoofing. Deviating from this filtering is acceptable only when the boundary is protected by equivalent means, for example, when source address validation (e.g., uRPF) or ACLs on all external-facing interfaces provide the same protection against packets with spoofed IPv4-embedded IPv6 sources. The analysis of these security risks can be found in Sections 5.1 and 5.3, and in BCP 38 .

Stateless IP/ICMP Translators In this framework, the Stateless IP/ICMP Translation Algorithm is used to translate between IPv4 and IPv6 packet headers. As stated in Section 8 of , the use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator. Other security considerations can be found in .

Address Mapping Rule Distribution The distribution of address mapping rules over an IPv6-only network may use various protocols, each with their own inherent vulnerabilities. For example, when a routing protocol is used for rule distribution, attackers may alter the IPv6 mapping prefix within these rules, leading to improper delivery of IPv4 service traffic over an IPv6-only network. Such an attack differs from pre-existing vulnerabilities in that traffic could be forwarded to a remote target across an intervening network infrastructure (e.g., an IPv6 core), allowing an attack to potentially succeed more easily since less infrastructure needs to be compromised. To mitigate this risk, the distribution mechanism MUST support origin authentication, and PE devices MUST reject unauthorized mapping rules, as described in . This framework proposes a default rule 0.0.0.0/0: Pref6(PE), which sends unknown IPv4 traffic (i.e., IPv4 traffic without definite IPv6 address mapping rule) to a "default egress PE". This approach has obvious implications, such as traffic attraction (posing a DoS concentration risk) and becoming a "catch-all" hijack target if rule distribution is compromised. Where a default address mapping rule is used, it MUST NOT be advertised across an administrative boundary unless the participating network operators have an explicit bilateral agreement covering its use. Operators using a default egress PE should apply monitoring and rate-limiting or ACLs on that PE. After the default egress PE translates, 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 network operators each treat the other as their default -- the packet is mapped again and the cycle repeats. To prevent these potential routing loops, a default egress PE MUST have a complete IPv4 forwarding view for the traffic it attracts, and MUST 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.

IANA Considerations This document has no IANA action.

Acknowledgements The authors would like to thank Brian E. Carpenter, Mohamed Boucadair, Bob Harold, Fred Baker, Xipeng Xiao, Giuseppe Fioccola, Vasilenko Eduard, Zhenbin Li, Jen Linkova, Ron Bonica, Shuping Peng, Jingrong Xie, Eduard Metz, Wu Qin, Dhruv Dhody, Nick Buraglio, Linda Dunbar, Weiqiang Cheng, Aijun Wang, Daryll Swer, Tim Wicinski, David 'equinox' Lamparter, Tianran Zhou and Huaimo Chen for their review and comments. The authors would also like to thank the IESG reviewers -- Ketan Talaulikar, Gunter Van de Velde, Eric Vyncke, Gorry Fairhurst, Mike Bishop, Roman Danyliw, and Christopher Inacio -- for their thorough reviews and constructive comments that significantly improved this document.

Contributors

Guoliang Han, Indirection Network Inc., China (guoliang.han@indirectionnet.com)
Ruoyu Zhao, Xiong’an Tianchuang, China (ruoyu.zhao@tciot.cn)