[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
v6ops Working Group                                               C. Xie
Internet-Draft                                                     C. Ma
Intended status: Informational                             China Telecom
Expires: September 8, 2022                                         X. Li
                                       CERNET Center/Tsinghua University
                                                               G. Mishra
                                                             Verizon Inc
                                                            M. Boucadair
                                                                  Orange
                                                           March 7, 2022


             Requirements to Multi-domain IPv6-only Network
          draft-xie-v6ops-reqirements-multi-domain-ipv6only-01

Abstract

   Dual-stack deployments require both IPv4 and IPv6 transfer
   capabilities are deployed in parallel.  IPv6-only is considered as
   the ultimate stage where only IPv6 transfer capabilities are used
   while ensuring global reachability.  This document specifies
   requirements when deploying IPv6-only in multi-domain networks.

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 September 8, 2022.

Copyright Notice

   Copyright (c) 2022 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



Xie, et al.             Expires September 8, 2022               [Page 1]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


   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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The reason to consider multi-domain factor when implementing
       IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Requirements from IPv6-native traffic . . . . . . . . . . . .   8
   7.  Procedure . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Requirements from IPv4 service delivery . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   IPv6 capabilities have been widely deployed during the past 10 years
   and IPv6 traffic is growing faster than IPv4.  Document
   [I-D.ietf-v6ops-ipv6-deployment] provides an overview of IPv6
   transition deployment status and how the transition to IPv6 is
   progressing among network operators and enterprises.

   When most services and networks did not support IPv6, it was
   straightforward to keep IPv4 function running when IPv6 was
   introduced in early stages.  Which is called IPv4/IPv6 dual-
   stack[RFC4213].  Many IPv6 deployments rely on this dual-stack
   approach.  However, dual-stack does have a few disadvantages in the
   long run, like the duplication of the network resources and states,
   as well as other limitations for network operation.  For this reason,
   when IPv6 usage increases to a certain limit, it would be better to
   consider IPv6-only.  Generally, running an IPv6-only network would
   reduce operational expenditures and optimize operations as compared
   to an IPv4/IPv6 dual-stack environment.  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]



Xie, et al.             Expires September 8, 2022               [Page 2]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


   In order to extend the service in the case of IPv4 address depletion,
   operators need to provide IPv6 services and still keep the ability
   for users to access the global IPv4 Internet.  Therefore, IPv4 as a
   Service (IPv4aaS) is a natural consideration for IPv6-only scheme.
   Several IPv4 service continuity mechanisms have been designed within
   IETF during the past twenty
   years[I-D.ietf-v6ops-transition-comparison].  When these schemes
   support the hosting of IPv4 service, different types of IPv4 and IPv6
   conversion technologies are required, for example, 464XLAT[RFC6877]
   uses stateful NAT64 translation technology, MAP-E[RFC7597]and MAP-T
   [RFC7599] use stateless NAT64 translation.  DS-Lite[RFC6333] adopts
   AFTR-based 4over6 tunneling technology, while the backbone network
   adopts GRE tunneling or stateless translation technology, etc.  This
   document specifies the requirements for multi-domain IPv6-only
   network from the perspective of operators.  It does not introduce any
   new IPv6 transition mechanisms.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

3.  Terminology

   The following terms are defined in this draft:

   o  Multi-domain IPv6-only network: An IPv6-only network which
      consists of multiple ASes belonging to and operated by the same
      operator.

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

   o  CPE: Customer Premise Edge device.

   o  IXP: Internet Exchange Point.

   o  PE : Provider Edge device.

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

   o  Border gateway: A PE router which run eBGP routing protocol and
      peering with the BGP router of external AS.

   o  Conversion point: A function which provides conversion between
      IPv4 and IPv6 realms.



Xie, et al.             Expires September 8, 2022               [Page 3]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


4.  The reason to consider multi-domain factor when implementing
    IPv6-only

   In general, transition to IPv6-only from dual-stack means some or all
   the IPv4 protocol instances of dual-stack network will closed
   gradually, thereby IPv6 will become the main network-layer protocol.
   When IPv4 is closed at the network layer, 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 in short time, it is very possible that some portion of the
   Internet service will consistently be IPv4-based.  In other words,
   IPv6-only network should carry not only IPv6-capable services, but
   also 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 (Provider Routers) in the core
   only support IPv6, but the AFBRs support IPv4 on interfaces facing
   IPv4 client networks and IPv6 on interfaces facing the core.  The
   routing solution defined in [RFC5565] for this scenario 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 technology, such as
   MPLS, LSP, GRE, L2TPv3, etc.

   [RFC6992] describes a routing scenario where IPv4 packets are
   transported over an IPv6 network, based on [RFC6145] and [RFC6052],
   along with a separate OSPFv3 routing table for IPv4-embedded IPv6
   routes in the IPv6 network.

   In general, the networks of large-scale operators are composed of
   multiple autonomous system(AS)es, different ASes may serve different
   scenarios, such as metro network, backbone network, 4G or 5G mobile
   core, data center network, and are often managed by different
   departments or institutions, using different routing and security
   policies.  When introducing the IPv6-only scheme without
   collaboration between ASes, different ASes adopt the IPv6 transition
   approach independently, the result is that multiple IPv6-only islands
   are connected by IPv4 links between domains.  As shown in figure 1,
   there will be more IPv4-IPv6 packet conversion gateways with
   different functions in the network.  Under this circumstance,
   IPv4-embedded IPv6 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 points will increases along with
   the increasing of the number of ASes.  Excessive IPv4-IPv6 conversion
   gateways lead to complexity of network and CAPEX increasing.
   Therefore, there is an urgent need for multi-domain IPv6-only



Xie, et al.             Expires September 8, 2022               [Page 4]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


   solutions to eliminate unnecessary conversion functions and improve
   data forwarding efficiency.

         +---+  +---+                          +------+
         |UE/|--|PGW|                          | IPv4 |
         |CPE|  +---+                          |Server|
         +---+    |                            +------+
                  |                               |
           -----------                        -----------
          /Mobile Core\                      /           \
         |   Network   |                    |    IPv4     |
         | (IPv6-only) |                    |  Internet   |
          \           /                      \           /
           -----------                        -----------
               |                                  |
            +-----+                          +--------+
            |PLAT/|                          |IPv4 BGP|
            |NAT64|                          | Router |
            +-----+                          +--------+
              | IPv4 link                        |IPv4 link
              |            -----------           |
          +---------+     / Backbone  \     +---------+
          |Stateless|----|  Network     ----|Stateless|
          | NAT64   |     \(IPv6-only)/     | NAT64   |
          +---------+      -----------      +---------+
             XLAT-1                            XLAT-2
    Figure 1: IPv6-only Independent Deployment in Multi-domain Network

5.  Scenarios

   This section describes scenarios where IPv4 packets are transported
   over a multi-domain IPv6-only network.  A typical model of multi-
   domain IPv6 network is depicted in figure 2.  Network 1, belonging to
   and operated by operator A, runs IPv6 and is composed of multiple
   inter-connected ASes, i.e., AS1, AS2 and AS3.  In addition, network 1
   provides access to different types of users, including mobile, home
   broadband and enterprise customers, denoted by UE1, UE2 and UE3 in
   figure 2.  Routers that are outside the backbone but directly
   attached to it are known as "Customer Edge" (CE) routers.

   Network 1 is open, it is interworking with the external networks.
   Operator 2 is one of the neighbor operators of Operator 1, AS4 of
   operator 2 and AS3 of operator are interconnected through BGP
   protocol.  In order to illustrate "IPv4 As A service" , AS4 is an
   IPv4-only network, which means that it does not run IPv6 protocol.

   In addition, cloud services are hosted in data centers and connected
   across multiple data centers, the edge, and public and private



Xie, et al.             Expires September 8, 2022               [Page 5]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


   clouds.  The data center must be able to communicate across these
   multiple sites, both on-premises and in the cloud.  IPv6-only network
   need to provide connections for cloud data center.  Network 1
   supports two connections modes of cloud data centers, the first one
   is between cloud data center and individual users, for instance, the
   user of CPE1 access the service hosted in DC1, the second one is the
   connection between cloud data centers, for instance, communications
   between DC1 and DC2.

   The edge nodes of the Network 1 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
   backbone.  Interior nodes are often known as "P routers".  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.

   Network 1 provides transportation 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 "edge routers".
   They are routed through the network to another edge router, after
   which they leave the network and continue on their way.




























Xie, et al.             Expires September 8, 2022               [Page 6]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


                   -----          -----
                  /     \        /     \
                 |  DC1  |      |  DC2  |
                  \     /        \     /
                   -----          -----
            ---------|--------------|---------
           |         |  (Operator1) |         |
           |       +---+  Network +---+       |
           |       |PE3|          |PE4|       |     (Operator2)
           |       +---+          +---+       |       +--+
           |      /    \         /     \      |      /    \
    +----+ | +---+      +--+ +--+       +---+ | +---+      +
    |UE/ |---|PE1| AS1  |R1|-|R2|       |PE5|---|BR1|  AS4 |
    |CPE1| | +---+      +--+ +--+       +---+ | +---+      +
    +----+ |      \    /        |       |     |      \    /
           |       +--+         |       |     |       +--+
           |       |R5|         |       |     |
           |       +--+         | AS3   |     |
           |        |           |       |     |
           |       +--+         |       |     |
    +----+ |       |R6|         |       |     |     (Operator3)
    |UE/ | |       +--+         |       |     |       +--+
    |CPE2|\|      /    \        |       |     |      /    \
    +----+ \ +---+      +--+ +--+       +---+ | +---+      +
           |-|PE2| AS2  |R3|-|R4|       |PE6|---|BR2| AS5  |
    +----+ / +---+      +--+ +--+       +---+ | +---+      +
    |UE/ |/|      \    /         \     /      |      \    /
    |CPE3| |       ----           -----       |       +--+
    +----+ |                                  |
            ----------------------------------
           Figure 2. Multi-domain IPv6 Network Model

   In order to illustrate the requirements of IPv6-only network, the
   following scenarios should be considered,

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

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

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

   Scenario 4: DC-to-DC, IPv6-only provide communications between VMs
   hosted cloud data centers, despite they are IPv4, IPv6 or IPv4/IPv6
   dual-stack.




Xie, et al.             Expires September 8, 2022               [Page 7]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


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

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

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

   It should be noted that the aforementioned scenarios are only a
   subset of the scenarios that multi-domain IPv6-only network will
   support in the future.

6.  Requirements from IPv6-native traffic

   Since there is no IPv4-IPv6 transition issue, native-IPv6 traffic can
   be transported by IPv6-only network naturally, the requirements are
   not covered by this document.

7.  Procedure

   This section firstly gives a very brief overview of the procedures of
   the IPv4 service delivery over IPv6-only network.

   When an ingress PE receives an IPv4 packet from a client-facing
   interface destined to a remote IPv4 network, it looks up the packet's
   destination IP address.  In the scenario of interest, the best match
   will help to find another PE, the egress PE.  Since this is a multi-
   domain IPv6-only network, the ingress and egress may belong to
   different ASes, for example the ingress is in AS 1 and egress is in
   AS 2.  The ingress PE must transform the IPv4 packet into IPv6 packet
   and forward the packet to the egress PE.  The egress PE then derives
   the IPv4 source and destination addresses from the IPv4-embedded IPv6
   addresses, respectively [RFC6052]and restore the original IPv4
   packet, and forwards it further according to the IPv4 routing table
   maintained on the egress.  The IPv6 data-path can be shown as below,












Xie, et al.             Expires September 8, 2022               [Page 8]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


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

       Figure 3. IPv6 Data Path from Ingress PE to Egress PE

   Another case that IPv4 packets may have been transformed into IPv6
   packet in UE/CPE, as done by CLAT of 464XLAT
   [RFC6877][RFC6877]&#65292;before they reach the edge of the network.
   In this case, the ingress PE receives an IPv6 packet from a client-
   facing interface and looks up the packet's destination IPv6 address.
   and forward the packet to the egress PE.  The egress PE then restore
   the original IPv4 packet, and forwards it further by looking up its
   IP destination address.  The IPv6 data-path can be shown as below.

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

        Figure 4. IPv6 Data Path from UE/CPE to Egress PE

   When PE of IPv6-only network UE/CPE need to implement IPv4-IPv6
   conversion, a specific IPv6 address range will represent IPv4 systems
   (IPv4-converted addresses), and the IPv6 systems have addresses
   (IPv4-translatable addresses or IPv4-embedded IPv6 addresses) that
   can be algorithmically mapped to a subset of the service provider's
   IPv4 addresses.  Note that IPv4-translatable addresses are a subset
   of IPv4-converted addresses.  In this way, there is no need to
   concern oneself with translation tables, as the IPv4 and IPv6
   counterparts are algorithmically related.







Xie, et al.             Expires September 8, 2022               [Page 9]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


8.  Requirements from IPv4 service delivery

   In order to support IPv4 service delivery, the following requirements
   should be met by multi-domain IPv6-only network&#65292;

   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 44NAT.

   Requirement 2: IPv4-as-a-Service

   IPv6 transition mechanisms should provide IPv4 service delivery and
   there should be no perceived degradation of customer experience when
   accessing the remaining IPv4 services.

   Requirement 3: end-to-end

   End-to-end means, 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 network, in other words, IPv4 packet
   should not appear in the middle of the IPv6 data path, the maximum
   number of the transition point should be two.  In addition, IPv6-only
   network should support the following two types of IPv6 data path, as
   mentioned in section 7.

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

   -From the ingress to egress, since the core of the network is
   IPv6-based, so all IPv4 packets which reaches the edge of the network
   should be transformed into IPv6 packets by the ingress and forwarded
   to the egress of the network.  The end-to-end requirement also be
   valid for cloud-to-cloud communications.

   Requirement 4: support of translation and encapsulation

   For the data-plane, there are two approaches for traversing the IPv6
   provider network: 4-6-4 translation and 4-in6 encapsulation, both of
   them can be supported by 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.  It should be noted that
   translation mode and encapsulation mode have the same IPv4-IPv6
   address mapping algorithm.




Xie, et al.             Expires September 8, 2022              [Page 10]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


   Requirement 5: controller independent

   In order to forward an IPv4 packet to the right egress point, IPv4
   reachability information must be exchanged in advance between the
   IPv4 networks over in IPv6-only network.  In general, BGP4+ is used
   to distribute external IPv4 routing information among AFBRs.  In the
   scenarios of interest, the extension of BGP4+ sessions can be used to
   pass IPv4 routing information.  This would require that IPv4-embedded
   IPv6 routes be flooded throughout the entire IPv6-only network and
   stored on every router.  It does not rely on the deployment of any
   centralized controller.  Note that with this routing solution, the
   IPv4 and IPv6 header conversion performed in both directions by the
   PE is stateless.

   Requirement 6: user stateless at the border gateway

   Maintaining user status will need 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 point.  The border
   gateway with other networks should be unaware of the user-related
   information, it only needs to perform stateless translation or
   encapsulation/decapsulation.

   Requirement 7: high scalability

   It should achieve scalability, simplicity and high availability,
   especially for large-scale SPs.  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
   algorithm-based mapping approach to avoid excessive status storage at
   the edge. it would also prevent overload of the IPv6 routing table.

   Requirement 8: SRv6 applicable

   SRv6 can be supported by inserting SRH in translated IPv6 packet, so
   the network programming can be realized for IPv4 traffic flow.

   Requirement 9: incremental deployment

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








Xie, et al.             Expires September 8, 2022              [Page 11]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


9.  Security Considerations

   There are no other special security considerations.

10.  IANA Considerations

   There are no other special IANA considerations.

11.  Acknowledgement

   This is under development by a large group of people.  Those who have
   posted to the list during the discussion.

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

12.2.  Informative References

   [I-D.ietf-bess-ipv6-only-pe-design]
              Mishra, G., Mishra, M., Tantsura, J., Madhavi, S., Yang,
              Q., Simpson, A., and S. Chen, "IPv6-Only PE Design for
              IPv4-NLRI with IPv6-NH", draft-ietf-bess-ipv6-only-pe-
              design-00 (work in progress), September 2021.

   [I-D.ietf-v6ops-ipv6-deployment]
              Fioccola, G., Volpato, P., Elkins, N., Martinez, J. P.,
              Mishra, G. S., and C. Xie, "IPv6 Deployment Status",
              draft-ietf-v6ops-ipv6-deployment-04 (work in progress),
              February 2022.

   [I-D.ietf-v6ops-transition-comparison]
              Lencse, G., Martinez, J. P., Howard, L., Patterson, R.,
              and I. Farrer, "Pros and Cons of IPv6 Transition
              Technologies for IPv4aaS", draft-ietf-v6ops-transition-
              comparison-02 (work in progress), March 2022.

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






Xie, et al.             Expires September 8, 2022              [Page 12]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


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

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

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
              <https://www.rfc-editor.org/info/rfc6145>.

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

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

   [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 September 8, 2022              [Page 13]


Internet-Draft     Multi-domain IPv6-only Requirements        March 2022


Authors' Addresses

   Chongfeng Xie
   China Telecom
   Beiqijia Town, Changping District
   Beijing, Beijing  102209
   China

   Email: xiechf@chinatelecom.cn


   Chenhao Ma
   China Telecom
   Beiqijia Town, Changping District
   Beijing, Beijing  102209
   China

   Email: machh@chinatelecom.cn


   Xing Li
   CERNET Center/Tsinghua University
   Shuangqing Road No.30, Haidian District
   Beijing, Beijing  100084
   China

   Email: xing@cernet.edu.cn


   Gyan Mishra
   Verizon Inc

   Email: gyan.s.mishra@verizon.com


   Mohamed Boucadair
   Orange
   France

   Email: mohamed.boucadair@orange.com











Xie, et al.             Expires September 8, 2022              [Page 14]