Skip to main content

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

Document Type Active Internet-Draft (v6ops WG)
Authors Chongfeng Xie , Chenhao Ma , Xing Li , Gyan Mishra , Mohamed Boucadair , Thomas Graf
Last updated 2024-05-10
Replaces draft-xie-v6ops-framework-md-ipv6only-underlay
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-v6ops-framework-md-ipv6only-underlay-06
v6ops Working Group                                               C. Xie
Internet-Draft                                                     C. Ma
Intended status: Informational                             China Telecom
Expires: 11 November 2024                                          X. Li
                                       CERNET Center/Tsinghua University
                                                               G. Mishra
                                                             Verizon Inc
                                                            M. Boucadair
                                                                  Orange
                                                                 T. Graf
                                                                Swisscom
                                                             10 May 2024

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

Abstract

   For the IPv6 transition, dual-stack deployments require both IPv4 and
   IPv6 forwarding capabilities to be deployed in parallel.  IPv6-only
   is considered as the ultimate stage where only IPv6 bearer
   capabilities are used while ensuring global reachability for both
   IPv6 and IPv4 services(usually known as IPv4aaS).  This document
   proposes a general framework for deploying IPv6-only in one multi-
   domain underlay network.  It lists the requirements of service
   traffic, illustrates major components and interfaces, IPv6 mapping
   prefix allocation, typical procedures for service delivery.  The
   document also discusses related security considerations.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 November 2024.

Xie, et al.             Expires 11 November 2024                [Page 1]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IPv6-only Deployment in Multi-domain Network  . . . . . . . .   6
   5.  General Requirements  . . . . . . . . . . . . . . . . . . . .   8
   6.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.2.  ADPT Description  . . . . . . . . . . . . . . . . . . . .  12
       6.2.1.  Rule Processing Layer . . . . . . . . . . . . . . . .  13
       6.2.2.  Rule Transport Layer  . . . . . . . . . . . . . . . .  14
       6.2.3.  Data Forwarding Layer . . . . . . . . . . . . . . . .  14
     6.3.  IPv6 Mapping Prefix Allocation  . . . . . . . . . . . . .  15
     6.4.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .  17
   7.  Integration with IPv6-only Access Mechanisms  . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     8.1.  Authenticity and Integrity of Packets . . . . . . . . . .  19
     8.2.  BGP-4 and Multiprotocol Extensions for BGP-4  . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  19
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     12.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   IPv6 capabilities have been widely deployed during the past decade
   with IPv6 traffic growing faster than IPv4.  [RFC9386] provides an
   overview of IPv6 deployment status and how the transition to IPv6 is
   progressing among network operators and enterprises.

Xie, et al.             Expires 11 November 2024                [Page 2]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   As of 2022, most IPv6 deployments rely on dual-stack[RFC4213].  Dual-
   stack does have a few disadvantages in the long run, like the
   duplication of the network resources and states and increased
   complexity for network operation to maintain both protocol stacks.
   For example, when broadband users encounter malfunctions in accessing
   services, network operators need to troubleshoot whether it is an
   IPv4 protocol failure or an IPv6 protocol failure, which increases
   the workload by at least twice.  For those reasons, and when IPv6
   usage has been dominant, it makes more sense to consider IPv6-only to
   reduce network resources and operational complexity.

   In 2016, the IAB announced that it "expects that the IETF will stop
   requiring IPv4 compatibility in new or extended protocols.  Future
   IETF protocol work will then optimize for and depend on IPv6"
   [IAB-statement].  To guarantee the normal operation of the service
   after IPv4 address depletion, operators need to provide IPv6 services
   and preserve access to the global IPv4 Internet as a Service(i.e.
   IPv4aaS) is a natural consideration for IPv6-only network.

   Several IPv4 service continuity mechanisms have been designed within
   IETF during the past twenty years[RFC9313].  For IPv4 service
   delivery, these approaches use different IPv4/IPv6 conversion
   methods.  For instance, 464XLAT[RFC6877] uses both stateless and
   stateful NAT64 translation, MAP-E[RFC7597]and MAP-T [RFC7599] use
   stateless IPv4-IPv6 address translation for encapsulation and
   translation respectively.  DS-Lite[RFC6333] utilizes AFTR-based
   4over6 tunneling approach.

   This document specifies the requirements for multi-domain IPv6-only
   underlay network and proposes a general framework for network
   operators.  In such a multi-domain IPv6-only underlay network, the
   conversion between IPv4 and IPv6 packets is implemented through
   stateless address mapping at the edge devices, so that the remaining
   IPv4 services can still be accessed by users.  The term "stateless"
   here refers to no need to maintain user-related status or translation
   tables for packet transformation at the edge devices.  In addition,
   the network specified by this framework can be integrated with other
   existing IPv6-only access schemes, thereby reducing unnecessary IPv4/
   IPv6 conversions.  The objective of such a framework is to help
   operators implement the transition to IPv6-only and support cross
   domain, end-to-end IPv6 and IPv4 service delivery in an efficiently
   way.  In this document, the term of “IPv6-only network” stands for
   “IPv6-only underlay network”, unless there is a specific statement.
   This document does not introduce any new IPv6 transition mechanisms
   nor IPv4aaS.

Xie, et al.             Expires 11 November 2024                [Page 3]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

1.1.  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[RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Terminology

   The following terms are used in this document:

   *  Multi-domain IPv6-only underlay network: IPv6-only underlay
      network which consists of multiple ASes operated by single or
      multiple operators.

   *  UE: User Equipment, e.g., mobile phone.

   *  CLAT: Customer-side translator (Section 1 of [RFC6877]).

   *  CPE: Customer Premise Equipment.

   *  DC: Data Center.

   *  IXP: Internet Exchange Point.

   *  WKP: Well-Known Prefix.

   *  NSP: Network-Specific Prefix.

   *  P: Provider Router.

   *  PE: Provider Edge (Section 5.2 of [RFC4026]).

   *  IPv4-embedded IPv6 addresses: IPv6 addresses used to represent
      IPv4 nodes in an IPv6 network, 32 bits in the IPv6 addresses
      contain IPv4 addresses, also known as IPv6 mapping
      address([RFC6052]).

   *  IPv4-embedded IPv6 packet: IPv6 packet which is generated from
      IPv4 packet by statelessly mapping of the source and destination
      IPv4 addresses to IPv6 addresses.

   *  PLAT: Provider-side translator (Section 1 of [RFC6877]).

   *  ASBR: Autonomous System Boundary Router, which runs External
      Border Gateway Protocol(eBGP) and peering with the BGP routers of
      external ASes.

Xie, et al.             Expires 11 November 2024                [Page 4]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   *  AFBR: Address Family Border Router, which supports both IPv4 and
      IPv6 address families and serves to provide transit services for
      the other in a backbone network (Section 1 of [RFC5565]).

   *  ADPT: Adapter in PE, a function entity which implements the two-
      way IPv4 and IPv6 packet conversion for IPv4 service delivery over
      IPv6-only network.

   *  Conversion point: A function which provides conversion between
      IPv4 and IPv6 realms.  This is, for example, the translation(XLAT)
      function in [RFC6144]

   *  GUA: IPv6 Global Unicast Address (Section 3 of [RFC3587]).

3.  Scenarios

   Up to present the global Internet industry has not given a unified
   definition of IPv6-only network so far.  This document defines such a
   notion as a IPv6-centric network in which data packets are forwarded
   upon IPv6 capability, IPv6-only network may interconnect with
   external networks, including IPv4-only networks.

   Generally, IPv6-only network should support the following scenarios,

       Scenario 1: IPv6 user to IPv4 server, i.e., IPv6-only user
       accesses IPv4 services hosted in data centers.

       Scenario 2: IPv4 user to IPv4 server, i.e., IPv4-only user
       accesses IPv4 services hosted in data centers.

       Scenario 3: IPv6 user to IPv6 server, i.e., IPv6-only user
       accesses IPv6 services hosted in data centers.

       Scenario 4: DC-to-DC, i.e., IPv6-only network provides
       communications between servers hosted in data centers, despite
       they are IPv4, IPv6 or IPv4/IPv6 dual-stack.

       Scenario 5: Transit for neighbor networks, i.e., IPv6-only
       network serves as an interconnection between several segregated
       IPv4-only networks, IPv4 packets are transported over the
       IPv6-only network between IPv4 networks.

       Scenario 6: IPv6-only eBGP Edge peering in IXP[I-D.ietf-bess-
       ipv6-only-pe-design], this serves to eliminate IPv4 provisioning
       at the edge of IXP that is facing IPv4 address depletion at large
       peering points.

       Scenario 7: 5G Transport service, SD-WAN, network slicing, etc.

Xie, et al.             Expires 11 November 2024                [Page 5]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   It should be noted that the scenarios above are only a subset of the
   scenarios that IPv6-only network will work for in the future.

4.  IPv6-only Deployment in Multi-domain Network

   For large-scale operators, their networks usually comprise multiple
   inter-connected autonomous systems (ASes).  Different ASes may serve
   different scenarios, such as Metro Area Network(MAN), backbone
   network, 4G or 5G mobile core network, data center and are often
   managed by different departments or institutions, using different
   routing and security policies.

   Using Figure 1 as an example, Network N1, belonging to and operated
   by operator 1, is composed of multiple inter-connected ASes(i. e.
   ,AS1, AS2 and AS3).  N1 provides access to multiple types of users,
   including mobile, home broadband and enterprise customers, denoted by
   CPE1, CPE2 and CPE3 respectively.  Routers that are outside the
   backbone but directly attached to it are known as “Customer Edge”
   (CE) routers.  [RFC8585] specifies the IPv4 service continuity
   requirements for IPv6 Customer Edge (CE) routers.  Specifically, it
   extends the basic requirements for IPv6 CE routers to allow for
   delivering IPv4 in IPv6-only access networks.  In addition, the
   service instances in data centers must be able to communicate across
   different sites, both on-premises and in data centers.  Multi-domain
   network needs to provide connections for data center.  Network N1
   supports at least two connection modes of data centers, the first is
   the mode between data center and individual users, for instance, the
   user of CPE1 accesses the service hosted in DC1, the second is the
   mode between data centers, for instance, communications between
   service instances hosted in DC1 and DC2 respectively.

   Multi-domain network discussed in this document is open, it is
   interworking with external networks.  Operator 2 is one of the
   neighbor operators of operator 1, AS4 of operator 2 and AS3 of
   operator 1 are interconnected through BGP protocol.  AS4 is an
   IPv4-only network, which means that it does not run IPv6 protocol.
   The edge nodes of the Network N1 are often known as “Provider Edge”
   (PE) routers.  The term “ingress” (or “ingress PE”) refers to the
   router at which a packet enters the network, and the term “egress”
   (or “egress PE”) refers to the router at which it leaves the network.
   Interior nodes are often known as “P routers” (Provider Routers).

Xie, et al.             Expires 11 November 2024                [Page 6]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

                        +---+          +---+
                       /     \        /     \
                      |  DC1  |      |  DC2  |
                       \     /        \     /
                        +---+          +---+
                 ---------|--------------|---------
                |         |      N1      |         |
                |         | (Operator 1) |         |     (Operator2)
                |        PE3            PE4        |       +---+
                |      /    \         /     \      |      /     \
      +----+    |     |  AS1 |       |       |     |     |       |
      |UE/ |---------PE1     R1-----R2      PE5---------BR1 AS4  |
      |CPE1|    |     |      |       |       |     |     |       |
      +----+    |      \    /        |       |     |      \     /
                |        R5          |  AS3  |     |       +---+
                |        |           |       |     |
      +----+    |        |           |       |     |     (Operator3)
      |UE/ |-   |        R6          |       |     |       +---+
      |CPE2| \  |      /    \        |       |     |      /     \
      +----+  \ |     |  AS2 |       |       |     |     |       |
                -----PE2     R3-----R4      PE6---------BR2 AS5  |
      +----+  / |     |      |       |       |     |     |       |
      |UE/ | /  |      \    /         \     /      |      \     /
      |CPE3|-   |       +--+           +---+       |       +---+
      +----+    |                                  |
                 ----------------------------------

      Figure 1. Multi-domain Underlay Network

   For one multi-domain IPv6-only network, transition to IPv6-only from
   dual-stack means some or all the IPv4 protocol instances of dual-
   stack network will be disabled gradually, thereby IPv6 will become
   the main network-layer protocol.  To be specific, the P routers in
   the core only support IPv6, but the PEs support IPv4 on interfaces
   facing IPv4 client networks and IPv6 on interfaces facing the core,
   in this case, the PEs need to support both address families.  Network
   N1 provides transport services for packets that originate outside the
   network and whose destinations are outside the network.  These
   packets enter the IPv6 network at one of its PE routers.  They are
   routed through the network to another PE router, at which they leave
   the IPv6-only network and continue their way.

   When IPv4 capability is disabled, the first question is how to make
   remaining IPv4 services running normally and users’ experience does
   not deteriorate.  The deployment of IPv6-only should not be based on
   the premise of the extinction of all IPv4-only services, it is very
   possible that some portion of the Internet service will consistently
   be IPv4-based.  In other words, IPv6-only network should not only

Xie, et al.             Expires 11 November 2024                [Page 7]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   carry native IPv6 services, but also allow users to reach IPv4-only
   services.  [RFC5565] describes the IPv4-over-IPv6 scenario, where the
   network core is IPv6-only and the interconnected IPv4 networks are
   called IPv4 client networks.  The P Routers in the core only support
   IPv6, but the ASBRs support IPv4 on interfaces facing IPv4 client
   networks and IPv6 on interfaces facing the core.  The routing
   solution defined in [RFC5565] is to run IBGP among AFBRs to exchange
   IPv4 routing information in the core, and the IPv4 packets are
   forwarded from one IPv4 client network to the other through a
   softwire using tunneling technologies, such as MPLS, LSP, GRE, VXLAN,
   L2TPv3, etc.

   [RFC6992] describes a routing scenario where IPv4 packets are
   transported over an IPv6 network, based on [RFC7915] and [RFC6052],
   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 IPv4aaS within a single AS.

   For one multi-domain network, when IPv6-only scheme is deployed
   without any collaboration, different ASes adopt the IPv6 transition
   approach independently, the result is that multiple IPv6-only islands
   are connected by IPv4 links between domains.  With independent
   deployment in different domains, there will be multiple IPv4-IPv6
   packet conversion gateways with different functions in the network.
   Under this circumstance, IPv6 packets converted from IPv4 packets
   need to be transformed back to IPv4 packets at the egress of one AS,
   and then back to IPv6 in the next domain, and the number of
   conversion gateways will increase along with the increasing of the
   number of ASes.  Excessive IPv4-IPv6 conversion gateways lead to
   complexity of network and CAPEX increasing.  Therefore, an overall
   framework is required to specify the behaviors of the network edge
   for IPv4 service delivery and eliminate unnecessary IPv4/IPv6
   conversion gateways within the multi-domain network.

5.  General Requirements

   Native IPv6 traffic can be transported over an IPv6-only network
   following legacy procedures.

   In order to support IPv4 service continuity, the following
   requirements should be met by multi-domain IPv6-only network.

   Requirement 1: Beneficial to wider IPv6 adoption

   It should largely reduce IPv4 public address consumption and
   accelerate the deployment of IPv6, rather than prolonging the
   lifecycle of IPv4 by introducing multiple layers of NAT44.

Xie, et al.             Expires 11 November 2024                [Page 8]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   Requirement 2: No service degradation

   There should be no perceived degradation of customer experience when
   accessing the remaining IPv4 services.

   Requirement 3: Optimized end-to-end

   For any given IPv4 traffic flow, there should be no IPv4-IPv6
   conversion point in the middle of the IPv6 data path when traversing
   multi-domain IPv6-only network, in other words, IPv4 packet should
   not appear in the middle of the IPv6 data path, the quantity of the
   conversion points should not exceed two.  In addition, IPv6-only
   network should support the following two directions of IPv6 data
   path.

       -From UE to egress, the packets of IPv4 service can be translated
       (or encapsulated) into IPv6 packets within the UE or CPE, and
       there should be no IPv6/IPv4 conversion before they reach the
       egress of the network.

       -From ingress to egress, since the core of the network is
       IPv6-based, all IPv4 packets that reach the edge of the network
       will be transformed into IPv6 packets by the ingress and
       forwarded to the egress of the network.

   The end-to-end requirement should also be valid for DC-to-DC
   communications.

   Requirement 4: Support of double translation and encapsulation

   The data-plane has two approaches for traversing the IPv6 provider
   network: 4-6-4 translation and 4over6 encapsulation, at least one
   mode should be supported by the IPv6-only network, the core nodes do
   not distinguish between translation-based IPv6 packet and
   encapsulation-based IPv6 packet.  At the egress, the PE can recover
   IPv4 packet by reading the next-header field of the packet.
   Moreover, translation mode and encapsulation mode should share the
   same IPv4-IPv6 address mapping algorithm.  Note that the double
   translation can reduce to single translation, while the encapsulation
   cannot.  At the ingress an IPv6 forwarding function is needed to
   forward IPv4 service data to the right egress network node (via
   encapsulation / translation) or right interface towards an external
   network.

   Requirement 5: User stateless at the border gateway

Xie, et al.             Expires 11 November 2024                [Page 9]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   Maintaining user status will consume great volume of storage and
   computation power, so it is generally stored or managed at the edge
   of network and close to the user side.  It is unsuitable to store
   user-related status at the inter-connection points with external
   networks.  The border ASBR that is interworking with external
   networks should be unaware of the user-related status, it only needs
   to perform stateless translation or encapsulation/decapsulation when
   necessary.

   Requirement 6: High scalability

   It should achieve high scalability, simplicity and availability,
   especially for large-scale operators.  When PE processes
   IPv4-features at the edge of the network, the quantity of the
   IPv4-related status should not increase linearly or exponentially
   along with the quantity of the user or traffic.  Considering this, it
   is better to adopt stateless mapping approach to avoid excessive
   status storage at the edge.  It would also avoid overloading of the
   IPv6 routing table.

   Requirement 7: Incremental deployment

   It can be deployed in an incremental fashion and the overall
   transition process should be stable and operational.

   Requirement 8: No security compromises

   The technologies proposed must not introduce additional security
   compromise.

6.  Framework

6.1.  Overview

   The framework described in this document is deliberately at a high
   level.  It is not intended to be prescriptive, implementations and
   technical solutions may vary freely.  To support the forwarding of
   IPv4 service data, multi-domain IPv6-only network needs to transform
   IPv4 packets into IPv6 ones in the UE/CPE or at the edge of the
   network.  Take the latter case as an example, when IPv4 packets reach
   the edge of the lPv6-only network, the ingress PE, i.e., PE1, will
   convert them into lPv6 packets by translation or encapsulation and
   send them into IPv6 network.  After intra-domain and cross-domain
   transmission, the IPv6 packets reach the egress PE, i.e., PE2, then
   be restored to IPv4 packets.  In this process, the forwarding of IPv4
   service data will follow the topology of IPv6 network.

Xie, et al.             Expires 11 November 2024               [Page 10]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   In the new framework proposed in this document, each PE device will
   be allocated and identified by at least one IPv6 mapping prefix,
   denoted by Pref6(PE), it will also have one or more associated IPv4
   address blocks which are extracted from local IPv4 routing table or
   address pool.  The mapping relationship between IPv4 address block
   and IPv6 mapping prefix is called mapping rule, which will have at
   least the following data structure,

           IPv4 address block: Pref6(PE)

   It should be noted that the mapping rule contains not only the data
   structure above, but also other necessary information to support IPv4
   service delivery over IPv6-only network, the detailed structure of
   the mapping rule is out of the scope of this document.

   The mapping rule of destination address will give the direction of
   IPv4 service data transmission in multi-domain IPv6-only network.
   When the 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 its IPv4
   source and destination address as below,

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

       -The IPv6 destination address is derived by appending the IPv4
       destination address to the Pref6(egress PE) in the mapping rule.

   Since mapping rule is prefix-level mapping, there is no need to
   maintain user-related status or translation tables for packet
   transformation at the PE devices.

   [RFC6052] illustrates the algorithmic translation of an IPv4 address
   to a corresponding IPv6 address, and vice versa, using only
   statically configured information.  With this approach, IPv4-embedded
   IPv6 addresses are composed by concatenating the prefix, the 32 bits
   of the IPv4 address, and the suffix (if needed) to obtain a 128-bit
   address.  The prefixes can only have one of the following lengths:
   32, 40, 48,56, 64, or 96.

   For the IPv6-only deployment scenario in this document, it is
   proposed that IPv4 address is located at the last 32 bits of the IPv6
   address, most significant bits first.  The bits between IPv6 mapping
   prefix and IPv4 address SHOULD be set to zero and are reserved for
   future extensions.  Examples of such representations are presented in
   Table 1.

Xie, et al.             Expires 11 November 2024               [Page 11]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   +-------------------+------------+--------------------------+
   |IPv6 mapping prefix|IPv4 address|IPv4-embedded IPv6 address|
   +-------------------+------------+--------------------------+
   |2001:db8::/32      |192.0.2.33  |2001:db8::192.0.2.33      |
   |2001:db8:100::/40  |192.0.2.33  |2001:db8:100::192.0.2.33  |
   |2001:db8:122::/48  |192.0.2.33  |2001:db8:122::192.0.2.33  |
   +-------------------+------------+--------------------------+
    Table 1. Text Representation of IPv4-Embedded IPv6 Address

   Prior to IPv4/IPv6 packets conversion, the mapping rules need to be
   obtained remotely in advance.  To meet this requirement, specific
   mechanism of mapping rule exchange needs to be designed, the exchange
   can be within or across domains.  However, this has been beyond the
   scope of this document, and it will be addressed in other documents.
   Using the mechanism of mapping rule exchange, an egress PE can tell
   other PEs that IPv4 packet whose IPv4 destination address is within
   the scope IPv4 address block of the mapping rule, can be forwarded to
   the egress PE identified by the corresponding IPv6 mapping prefix of
   the mapping rule.

   Although this document illustrates the framework of multi-domain
   IPv6-only network operated by a single operator, this multi-domain
   model can naturally be extended to IPv6-only network which is
   operated by multiple operators.

6.2.  ADPT Description

   In this framework, PE device is the key part and provides the
   statelessly IPv4/IPv6 packet transformation for IPv4 service delivery
   in a multi-domain IPv6-only network environment, there is no specific
   requirements to the P devices.  This section illustrates the
   components and interfaces of ADPT in PE devices.  ADPT is the entity
   in PE which accommodates the conversion of IPv4 packets into IPv6
   ones for IPv4 service delivery over IPv6-only network.  ADPT
   comprises the following components, as shown in figure 2.

Xie, et al.             Expires 11 November 2024               [Page 12]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

             +-----------------------------------------------+
             | PE1             /------------\                |    +-------+
             |                | ADPT         |               |    |PE2    |
 +-------+   | +-------+      |      +-----+ |               |    | +---+ |
 |       |   | |IPv4   | I3   |      |     | |      I1       |    | |   | |
 |       +---+-+routing+------+------+ RP  +-+--- --+--------+----+-+ RP| |
 |       |   | |engine |      |  +---+     | |               |    | |   | |
 |       |   | +-------+      |  |   +--+--+ |               |    | +---+ |
 |       |   |     |          |  +I7    +I2  |               |    +---+---+
 |       |   |     |          |  |   +--+--+ |   +-------+   |        |
 |       |   |     |          |+--+  |     | |I4 | IPv6  |   |    +---+---+
 |  R1   |   |     |          ||MD|  | RT  +-+---+routing+---+----+       |
 |(IPv4  |   |     |          |+--+  |     | |   |engine |   |    |       |
 |Router)|   |     |          |  |   +-----+ |   +---+---+   |    |  R2   |
 |       |   |     |          |  +I8         |       |       |    |(IPv6  |
 |       |   | +----------+   |  |   +-----+ |   +---+------+|    |Router)|
 |       |   | |IPv4      |I5 |  +---+     | |I6 |IPv6      ||    |       |
 |       +---+-+packet    +---+------+ DF  +-+---+packet    ++----+       |
 |       |   | |forwarding|   |      |     | |   |forwarding||    |       |
 +-------+   | +----------+   |      +-----+ |   +----------+|    +-------+
             |                 \____________/                |
             +-----------------------------------------------+

     RP: Rule Processing Layer
     RT: Rule Transport Layer
     DF: Data Forwarding Layer
     MD: Mapping rule Database

                   Figure 2. Components and Interfaces of ADPT

6.2.1.  Rule Processing Layer

   The Rule Processing Layer, i.e., RP, deals with the management of
   mapping relationship between IPv4 address blocks and their IPv6
   mapping prefixes.

   In each PE, there is a Mapping rule Database, i.e., MD, to store all
   the mapping rule entries it receives from other PEs, as shown in
   figure 2.  Rule Processing Layer provides management functions to
   Mapping rule Database through interface I7, for example, insertion,
   modification, or deletion mapping rules.  The interface with the ADPT
   of other PE is I1, which is used for the exchanging of mapping rule
   with each other.  Interface I2, which is illustrated in section
   6.2.2, is I2, is used for the transmission of mapping rule through
   Rule Transport Layer.  PE1 can extract the IPv4 address blocks from
   its IPv4 BGP routing instance through interface I3, and generate the
   mapping rules of the device in combination with its own IPv6 mapping
   prefix.  When the mapping rules are ready, they will be sent to Rule

Xie, et al.             Expires 11 November 2024               [Page 13]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   Transport Layer through interface I2.  Correspondingly, PE1 will
   receive the mapping rules of other PEs through interface I2 and
   stores them in the local Mapping rule Database.

   For some IPv4 address blocks which are not announced explicitly by
   any egress PEs to the ingress PE, there will be no corresponding
   mapping rule in the Mapping rule Database.  To solve this problem,
   the default egress PE is defined in this framework, which announces
   the default IPv6 mapping rule with the default mapping prefix to
   other PEs.  The format of the mapping rule for default IPv4 address
   is as follows,

           0.0.0.0/0: Pref6(PE)

6.2.2.  Rule Transport Layer

   Rule Transport Layer, i.e., RT, is in charge of the exchanging of
   mapping rule with other PEs and its related routing information at
   the routing layer.  The exchanging of the mapping rule should precede
   to the process of IPv4 data transmission, otherwise, the data
   originated from IPv4 network will be dropped due to the absence of
   the IPv6 mapping prefix corresponding to its destination address.

   When the request of the mapping rule from Rule Processing Layer
   through interface I2 is being received, Rule Transport Layer will
   convert the mapping rule into data structure that is suitable for the
   transmission in the IPv6 routing system and send it to the IPv6
   routing engine through interface I4.  In opposite direction, when
   receiving the routing update from IPv6 routing engine through
   interface I4, Rule Transport Layer will extract mapping rule from the
   routing information and send it to the Rule Processing Layer.

   To support the transmission of mapping rules at the routing layer,
   MP-BGP4 protocol or other control protocols needs to be extended.
   However, this has been out of the scope of the draft and will be
   discussed in other documents.

6.2.3.  Data Forwarding Layer

   Data Forwarding Layer, i.e., DF, provides data forwarding function to
   IPv6 packets, including native IPv6 packets and IPv4-embedded IPv6
   packets.  Multi-domain IPv6-only network needs to support both
   translation and encapsulation technologies for IPv4 data delivery:

   1.  Translation

Xie, et al.             Expires 11 November 2024               [Page 14]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   Translation refers to the conversion of IPv4 packet into IPv6 packet,
   then transmits it in the multi-domain IPv6-only network.  When
   receiving an IPv4 packet through interface I5 from IPv4 packet
   forwarding module, the data forwarding layer will look up the Mapping
   rule Database through the interface I8, if the mapping rule
   corresponding to the IPv4 destination address is found, then it
   generates corresponding IPv6 source and destination addresses from
   its IPv4 source and destination address following the procedure
   illustrated in section 6.1.

   2.  Encapsulation

   Encapsulation is the process in which PE adds a new IPv6 header is to
   the original IPv4 packet received, then transmits it in the multi-
   domain IPv6-only network.  Address mapping in encapsulation mode is
   same to that in translation mode, when receiving IPv4 packet through
   interface I5 from IPv4 packet forwarding module, the data forwarding
   layer will look up the Mapping rule Database through the interface
   I8, if the mapping rule corresponding to the IPv4 destination address
   is found, then it generates corresponding IPv6 source and destination
   addresses from its IPv4 source and destination address following the
   procedure illustrated in section 6.1.

   For an IPv4-embedded IPv6 packet, whether it is based on translation
   or encapsulation, the Pref6 part of the destination address can
   identify the egress in the network, so the forwarding of the IPv6
   packet can be implemented based on the Pref6 part of the destination
   address.

6.3.  IPv6 Mapping Prefix Allocation

   With this framework, a specific IPv6 range is used to represent IPv4
   address space by stateless mapping as with section 6.1, there are two
   options to allocate IPv6 mapping prefixes:

   1) WKP

   A specific WKP can be allocated from the global IPv6 address prefix,
   e.g., 64:ff9b:: /96, or an IPv6 address prefix specifically assigned
   for this purpose.

       Pros:

       Operators do not need to allocate IPv6 address prefixes specially
       used for mapping IPv4 addresses from their own IPv6 address
       resources.  Secondly, operators can easily control the range of
       IPv6 mapping routes, such as implementing routing restrictions at
       the boundaries to prevent them from leaking into other networks.

Xie, et al.             Expires 11 November 2024               [Page 15]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

       Cons:

       If the PE device converts the IPv4 address into IPv6 address with
       WKP, the IPv4 part of the IPv4-embedded IPv6 address is used for
       the routing of the IPv4-embedded IPv6 packet.  For this reason,
       many fine routes with prefix length greater than 96 will be
       introduced into the FIB of P routers in IPv6-only network.  In
       most networks, fine routes with long prefix length greater than
       96 is not supported.

   2) NSP

   Operator allocates a specific IPv6 prefix or prefixes from their
   existing IPv6 address resources to each PE for IPv4 addresses
   mapping.  The IPv6 mapping prefix varies for different PEs.

       Pros:

       Within the multi-domain network, the length of IPv6 mapping
       prefix can be easily tailored to meet the requirements of IPv6
       network for routing length, and the routing of the packets can be
       based on the IPv6 mapping prefix part of the IPv6 address.  The
       IPv6 mapping prefix is inside a bigger IPv6 address block
       allocated to the PE, which is routable, so IPv6 devices can
       forward IPv6 packets in legacy manner without setting up a
       specific entry for IPv6 mapping prefix in FIB.  In addition,
       because the IPv6 mapping prefix has been included in operator's
       existing IPv6 address space, it will not introduce any new
       routing items and affect the global IPv6 routing system.

       Cons:

       If the operator does not have a specific address prefix planning
       and policy configuration, in the case of operator-interworking,
       the same IPv4 address block will receive NSP prefixes from
       different operators, forming different IPv6 mapping routes.  This
       may lead to increase the scale of the routing table in the IPv6
       network, including FIB and RIB.

   As mentioned in section 6.1, each PE will be identified by at least
   one IPv6 mapping prefix, which is used as the basic routing
   information to forward IPv4-embedded IPv6 packet to the right egress
   PE.  For operators, the selection of the length of IPv6 mapping
   prefix should be given specific consideration.  The length of all the
   IPv6 mapping prefixes should be the same, to avoid unnecessary
   processing cost and complexity induced by the prefix length
   diversity.

Xie, et al.             Expires 11 November 2024               [Page 16]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

6.4.  Procedures

   This section gives a brief overview of the procedures of the IPv4
   service delivery over IPv6-only network.  When the ingress PE
   receives an IPv4 packet from a client-facing interface destined to a
   remote IPv4 network, it looks up in its mapping rule database to find
   the mapping rule which best matches the packet’s destination IPv4
   address.  The IPv6 mapping prefix in the mapping rule will help to
   find another PE, i.e., the egress PE.  Since this happens in multi-
   domain IPv6-only network, the ingress and egress may belong to
   different ASes, as shown in figure 3, the ingress PE1 is in AS 1 and
   egress is PE3 in AS 3.  The ingress PE must convert the IPv4
   destination address into IPv6 destination address using the IPv6
   mapping prefix of PE3 and forward the IPv6 packet to PE3.  When PE3
   receives the IPv6 packet, it derives the IPv4 source and destination
   addresses from the IPv4-embedded IPv6 addresses respectively and
   restore the original IPv4 packet.  Afterwards, the IPv4 packet will
   be further forwarded according to the IPv4 routing table maintained
   on the egress.  The IPv6 data path in this process is shown as below.

                              IPv6 Data Path
                   |<----------------------------------->|
                   |                                     |
                   |   ----         ----          ----   |
                   |  /    \       /     \       /    \  |      ----
        +----+     | | AS1  |     |  AS2  |     | AS3  | |    /      \
        |UE/ |-----PE1      R1---R2       R3---R4      PE3----| AS4  |
        |CPE1|       |      |     |       |     |      |      \(IPv4)/
        +----+        \    /       \     /       \    /         ----
                       ----         ----          ----

       Figure 3. End-to-end IPv4 Service Delivery from Ingress to Egress

   In this case, there are only two IPv4-IPv6 conversion actions, which
   occur in PE1 and PE3 respectively.

7.  Integration with IPv6-only Access Mechanisms

   One typical case is that IPv4 packets may have been transformed into
   IPv6 packet in UE/CPE, as done by CLAT of 464XLAT[RFC6877], before
   they reach the edge of the network.  In this case, the PLAT of
   464XLAT and ADPT will converge in ingress PE.  As shown in figure 4,
   when IPv6 packet reaches the ingress PE, the ingress PE, i.e. PE1,
   does not need to implement the conversion between IPv4 and IPv6
   packets.  For the source IPv6 address, because the address adopted by
   UE is generally GUA, and the source address of the IPv4-embedded IPv6
   packet is IPv4-embedded address in the core of this framework, it is

Xie, et al.             Expires 11 November 2024               [Page 17]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   necessary to convert the source address from GUA to IPv4-embedded
   IPv6 address.  In addition, because the quantity of IPv4-embedded
   IPv6 address is limited, it is necessary to take IPv6 address
   multiplexing here, one IPv4-embedded IPv6 address is shared among
   multiple IPv6-only clients with GUA addresses.  For the destination
   address, with 464XLAT, UE synthesizes the destination IPv4 address
   into IPv6 address by appending IPv4 address to the IPv6 prefix
   provided by DNS64 server.  When the IPv6 packet reaches the edge the
   multi-domain IPv6 network, i.e. PE1, the destination IPv6 address is
   converted into IPv4-embedded IPv6 address too.  This process is
   implemented by looking for the mapping rule corresponding to the
   original destination IPv4 address in mapping rule database, and then
   substituting the NAT64 prefix with the IPv6 mapping prefix of the
   egress PE.

                              IPv6 Data Path
           |<------------------------------------------->|
           |                                             |
           |           ----         ----          ----   |
           |          /    \       /     \       /    \  |      ----
        +----+       | AS1  |     |  AS2  |     | AS3  | |    /      \
        |UE/ |-----PE1      R1---R2       R3---R4      PE3----| AS4  |
        |CPE1|       |      |     |       |     |      |      \(IPv4)/
        +----+        \    /       \     /       \    /         ----
                       ----         ----          ----

        Figure 4. Integration with IPv6-only Access Mechanisms

   In this case, the functions of stateful NAT64 and stateless IPv4/IPv6
   conversion converge in PE1, so the client-facing interface and the
   core-facing interface are both IPv6.  Along the IPv6 data path, there
   are only one stateless IPv4-IPv6 conversion action, which occurs in
   PE3.  Compared with the case of independent deployment mentioned in
   section 5, the quantity of IPv4-IPv6 conversion points is reduced
   from three to one in the new framework.  Besides 464XLAT, other
   IPv6-only technologies, such as DS-Lite, Lightweight 4over6, MAP-T/
   MAP-T, can also be integrated with the PE of the multi-domain
   IPv6-only network.

8.  Security Considerations

   Besides regular security checks on configured mapping rules, the
   following two aspects need to be considered as well.

Xie, et al.             Expires 11 November 2024               [Page 18]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

8.1.  Authenticity and Integrity of Packets

   In this framework, for each egress PE, they assume that all ingress
   PEs are legal and authorized to convert the received IPv4 packets
   into IPv6 packets and send them into IPv6-only network.  If IPv6
   packets cannot guarantee its authenticity or integrity, then there
   may be a spoofing attack.  Some faked ingress PEs can send IPv6 data
   converted from IPv4 to attack the egress PE.  After the egress PE
   recovers the received IPv6 packets into IPv4 packets, they are routed
   based on the destination IPv4 address and enter the Internet.  They
   use global IPv4 address, not private address.  Therefore, these
   attacks cannot cause payload packets to be delivered to an address
   other than the one appearing in the destination address field of the
   IP packet.  Since the PE in this framework is stateless, the effect
   of the attack is limited.

8.2.  BGP-4 and Multiprotocol Extensions for BGP-4

   The framework allows BGP to propagate mapping rule information over
   an IPv6-only underlay network, BGP is vulnerable to traffic diversion
   attacks.  The ability to advertise a mapping rule adds a new means by
   which an attacker could cause traffic to be diverted from its normal
   path.  Such an attack differs from pre-existing vulnerabilities in
   that traffic could be forwarded to a distant target across an
   intervening network infrastructure (e.g., an IPv6 core), allowing an
   attack to potentially succeed more easily since less infrastructure
   would have to be subverted.  The security issues already exist in
   BGP-4 and MP-BGP for IPv6, the same security mechanisms are
   applicable.

9.  IANA Considerations

   There are no other special IANA considerations.

10.  Acknowledgements

   The authors would like to thank Brian E.  Carpenter, 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, Tianran Zhou and Huaimo Chen for their review and comments.

11.  Contributors

   Guoliang Han
   Indirection Network Inc.
   China
   Email: guoliang.han@indirectionnet.com

Xie, et al.             Expires 11 November 2024               [Page 19]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   Ruoyu Zhao
   Beijing TC Group
   China
   Email: api_zhao@126.com

   Linjian Song
   Alibaba Cloud
   China
   Email: linjian.slj@alibaba-inc.com

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3587]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
              Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
              August 2003, <https://www.rfc-editor.org/info/rfc3587>.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <https://www.rfc-editor.org/info/rfc4026>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
              <https://www.rfc-editor.org/info/rfc5565>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <https://www.rfc-editor.org/info/rfc6052>.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,
              <https://www.rfc-editor.org/info/rfc6877>.

Xie, et al.             Expires 11 November 2024               [Page 20]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   [RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
              "IP/ICMP Translation Algorithm", RFC 7915,
              DOI 10.17487/RFC7915, June 2016,
              <https://www.rfc-editor.org/info/rfc7915>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2.  Informative References

   [IAB-statement]
              "IAB statement",
              <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213,
              DOI 10.17487/RFC4213, October 2005,
              <https://www.rfc-editor.org/info/rfc4213>.

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
              April 2011, <https://www.rfc-editor.org/info/rfc6144>.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
              <https://www.rfc-editor.org/info/rfc6333>.

   [RFC6992]  Cheng, D., Boucadair, M., and A. Retana, "Routing for
              IPv4-Embedded IPv6 Packets", RFC 6992,
              DOI 10.17487/RFC6992, July 2013,
              <https://www.rfc-editor.org/info/rfc6992>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/RFC7597, July 2015,
              <https://www.rfc-editor.org/info/rfc7597>.

   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <https://www.rfc-editor.org/info/rfc7599>.

Xie, et al.             Expires 11 November 2024               [Page 21]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   [RFC8585]  Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
              "Requirements for IPv6 Customer Edge Routers to Support
              IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
              2019, <https://www.rfc-editor.org/info/rfc8585>.

   [RFC9313]  Lencse, G., Palet Martinez, J., Howard, L., Patterson, R.,
              and I. Farrer, "Pros and Cons of IPv6 Transition
              Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313,
              DOI 10.17487/RFC9313, October 2022,
              <https://www.rfc-editor.org/info/rfc9313>.

   [RFC9386]  Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G.,
              and C. Xie, "IPv6 Deployment Status", RFC 9386,
              DOI 10.17487/RFC9386, April 2023,
              <https://www.rfc-editor.org/info/rfc9386>.

Authors' Addresses

   Chongfeng Xie
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: xiechf@chinatelecom.cn

   Chenhao Ma
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: machh@chinatelecom.cn

   Xing Li
   CERNET Center/Tsinghua University
   Shuangqing Road No.30, Haidian District
   Beijing
   100084
   China
   Email: xing@cernet.edu.cn

   Gyan Mishra
   Verizon Inc
   Email: gyan.s.mishra@verizon.com

Xie, et al.             Expires 11 November 2024               [Page 22]
Internet-Draft       Multi-domain IPv6-only Underlay            May 2024

   Mohamed Boucadair
   Orange
   France
   Email: mohamed.boucadair@orange.com

   Thomas Graf
   Swisscom
   Binzring 17
   CH- CH-8045 Zurich
   Switzerland
   Email: thomas.graf@swisscom.com

Xie, et al.             Expires 11 November 2024               [Page 23]