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, including identifying the requirement for connecting IPv4 islands across an IPv6-only backbone using any of several encapsulations (Section 3.5 of ). The Softwire Mesh Framework addresses that problem using BGP and encapsulation between the edge routers. Its procedures are specified for a transit core of a single Autonomous System, and Section 12 of describes how to extend them to multiple Autonomous Systems, for example by multi-hop BGP between the edge routers or by leaving the BGP next hop unchanged at ASBRs; either way, recursive next-hop resolution is needed and encapsulations may need to be stacked. BGP/MPLS IP VPNs provide comparable multi-AS and carrier's carrier arrangements (Sections 9 and 10 of ). While access-side IPv6-only solutions have matured, a backbone framework based on stateless address translation at the network edge 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 specifies stateless IPv4/IPv6 translation at the network edge, using IPv4-embedded IPv6 addresses derived from address mapping rules. The same address mapping rules could instead be used to encapsulate IPv4 packets in IPv6 in the manner of MAP-E , with the outer IPv6 destination derived from the IPv4 destination; this is what "encapsulation" refers to in this document, and it is not specified further here. IPv4 service across an IPv6-only core can also be provided using BGP, with IPv4 routes advertised with an IPv6 next hop and IPv4 packets carried across the core to that next hop ; that approach involves no address mapping and is not covered by this document. 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 and packet conversion. 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 does not extend across the Internet: IPv6 mapping prefixes and address mapping rules are confined to the participating IPv6-only core network. On the IPv4 side, egress PEs (including any default egress PE) deliver traffic to IPv4 networks, including the IPv4 Internet, using ordinary IPv4 routing. 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. The IPv4 addresses of converted traffic are visible in the IPv6 header to every participating network that carries it. 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 reachable only within the participating domain. Border routers at the framework boundary MUST NOT advertise mapping prefixes, or more-specific prefixes within them, 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.

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 are out of the scope of this document and are expected to be defined by the specific protocol(s) used for rule distribution. Where such a protocol defines more than one conversion capability, the selection between them is likewise defined by that protocol. 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 are translated to IPv6 packets at the PEs located at the edge of the network. 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 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 mapping rules for IPv4 routes learned from other PEs of the multi-domain network, and MUST NOT originate per-prefix mapping rules for transit routes learned from external IPv4 peers. A PE that is the egress toward an external IPv4 network, such as PE3 toward Operator 3 in Figure 1, originates mapping rules only for that network's own address blocks or for aggregates configured by the operator. 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. Where a default address mapping rule is used:

The default rule MUST NOT be advertised across an administrative boundary unless the participating network operators have an explicit bilateral agreement covering its use.
The default egress PE attracts IPv4 traffic for every destination not covered by a more specific mapping rule. It MUST have a complete IPv4 forwarding view for that traffic, for example full IPv4 routing or a default route toward an IPv4 network outside the framework.
The default egress PE MUST forward IPv4 packets that it has recovered from IPv4-embedded IPv6 packets using only routes that lead out of the participating domain, for example by placing them in a separate forwarding context. TTL and Hop Limit processing bound a forwarding loop but do not prevent it.

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. Load balancing across multiple egress PEs, and anycast egress (one mapping prefix shared by more than one PE), are outside the scope of 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 keeps MR-DB lookups, synchronization, and rule management operationally manageable even in networks with complex external peering; the source validation in adds a per-packet lookup at the egress PE. 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. The distribution mechanism provides the properties listed in . 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, are not modified by any intermediate node.
Scoping: mapping rules can be scoped and filtered at administrative boundaries, and are not propagated outside the participating domain (Section 3.1).
Origin authentication: a receiving PE can verify the origin of a mapping rule.
Rule rejection: a PE rejects a mapping rule that binds an IPv4 address block to the mapping prefix of a PE that is not authorized for that block.

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 it as follows, in this order:

If the destination does not match one of the PE's own IPv6 mapping prefixes, forward per normal IPv6 forwarding.
If the packet fails the source validation in Section 9.2, MUST discard, SHOULD count such drops.
If the MR-DB contains no locally originated rule covering the embedded IPv4 destination, MUST discard; MAY send ICMPv6 Destination Unreachable. For this check the default rule counts as locally originated only on the default egress PE.
Otherwise, translate per and forward using IPv4 routing info.

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. Advertising mapping prefixes as more-specific routes adds one IPv6 route per mapping prefix in each participating domain that carries them. The IPv6 mapping prefix MUST be one of the lengths permitted by Section 2.2, i.e., /32, /40, /48, /56, /64, or /96. As specified in Section 2.2 of , bits 64 to 71 (the "u" octet) are zero for every prefix length, and for prefix lengths shorter than /96 the bits after the embedded IPv4 address form a suffix that is set to zero. 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. In addition:

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 this; network operators MUST ensure that the covering aggregate resolves specifically to the originating PE before relying on it.
A PE MUST NOT forward an IPv4-embedded IPv6 packet using a mapping rule whose Pref6(PE) does not resolve to a valid IPv6 route reaching the originating PE. Whether such a rule is then withdrawn, deactivated, or replaced by another egress is left to the rule-distribution mechanism and local policy, which are expected to damp such changes so that IPv6 route instability does not cause mapping-rule churn across administrative boundaries.

Operational Considerations MTU configuration needs care when deploying IPv6-only in a multi-domain network. When IPv4 packets are translated as specified in , the IPv6 header is up to 20 octets larger than the IPv4 header; IPv4 options are not translated (Section 4.1 of ), so their presence reduces the difference. A Fragment Header (8 octets) is added when the incoming IPv4 packet is already a fragment, or when the DF bit is clear and the resulting IPv6 packet would exceed the translator's configured lowest-ipv6-mtu. Translation therefore adds at most 28 octets to an IPv4 packet. 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 ensure that IPv4 packets of the size offered to customers can cross the IPv6-only core after translation. For a 1500-byte IPv4 MTU, this means an IPv6-only core MTU of at least 1528 bytes, with lowest-ipv6-mtu configured to the same value on every PE; with the default lowest-ipv6-mtu of 1280 bytes, an ingress PE fragments IPv4 packets that do not have the DF bit set, whatever the core MTU. Where this cannot be done, operators can use MSS clamping for TCP connections and the fragmentation and ICMP handling in Sections 1.4, 4.2 and 5.2 of . 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, using an IPv4 address or pool configured for this purpose (see Section 6 of and ). Because this framework uses translation, the data-plane properties of apply across the IPv6-only core. In particular, translated packets carry a zero IPv6 Flow Label (Section 4.1 of ), so ECMP and LAG hashing in the core rely on the IPv4-embedded addresses and, where P routers parse them, the transport-layer ports.

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 ICMPv6 error messages generated inside the IPv6-only core, by a P router or by an egress PE that discards a packet, are addressed to an IPv4-embedded IPv6 address and so reach the ingress PE, which translates them as required in . Inter-provider SLAs should permit such ICMPv6 messages to cross 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 accepts only packets whose source has been validated as described in . Without that validation, any node able to reach an egress PE's mapping prefix could cause it to emit IPv4 packets with arbitrary source addresses. 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 validation of provisioned mapping rules 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 on an interface or peering session that the operator has associated with that ingress PE.

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. Packets entering the participating domain with an IPv6 source address within a mapping prefix SHOULD be discarded at the framework boundary, unless the boundary is protected by equivalent means, for example source address validation (e.g., uRPF ) or ACLs on all external-facing interfaces. The analysis of these risks can be found in Sections 5.1 and 5.3 of 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 . In this framework, those routing protocols and the distribution of address mapping rules span multiple administrative domains; the resulting risks are discussed in Sections 9.1, 9.2 and 9.4.

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 provides origin authentication and rule rejection (). 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. The constraints on its use are given in Section 5.2.1. 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. The requirements that prevent such loops are given in Section 5.2.1.

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)