<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-v6ops-ipv6only-pe-requirements-00"
     ipr="trust200902">
  <front>
    <title abbrev="">Basic Requirements for IPv6-only Provider Edge Routers</title>

    <author fullname="Cong Li" initials="C" surname="Li">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>licong@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Chongfeng Xie" initials="C" surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>xiechf@chinatelecom.cn</email>
      </address>
    </author>

    <date day="7" month="July" year="2025"/>

    <workgroup>v6ops Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This document specifies the basic requirements for multi-domain 
	  IPv6-only Provider Edge (PE) routers. The requirements cover several
	  key aspects: support for fundamental IPv6 protocols, such as, MP-BGP and ICMPv6, 
	  implementation of 4map6 based MP-BGP extensions, stateless encapsulation
	  and translation functions using IPv6 mapping prefixes as well as support for SRv6 and NAT64 functionalities.
	  By defining these requirements, this document aims to facilitate the development,
	  deployment and interoperability of such PE routers, thereby promoting the smooth 
	  establishment and operation of multi-domain IPv6-only Networks.
	</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <section title="IPv6-only Evolution Trend">
	   
	  <t><xref target="I-D.ietf-v6ops-framework-md-ipv6only-underlay"/>
      describes a framework for deploying IPv6-only underlay in multi-domain
      networks, IPv4 packets are statelessly translated or encapsulated into
      IPv6 packets for transmission. This framework requires IPv4/IPv6 address
      mapping rule to support stateless packet conversion at Provider Edge
      (PE) routers.
	  In recent years, the deployment of IPv6 has been accelerating globally. 
	  Many regions and service providers have started to promote the use of IPv6 in their networks.
	  As IPv6 traffic gradually increases in some networks, 
	  showing a trend of exceeding IPv4 traffic, there is a growing need to consider systematically 
	  the transition from IPv4/IPv6 dual-stack networks to IPv6-only networks.
	  </t>
	  
	 <t>The evolution towards IPv6-only networks aims to simplify the network architecture,
	 eliminate the complexity caused by the co-existence of IPv4 and IPv6 protocols,
	 and fully leverage the advantages of IPv6. By removing the redundant functions related to IPv4, 
	 network operators can optimize resource utilization, reduce operational costs, 
	 and improve the overall efficiency and performance of the network.
	 </t>
	  
      <t>The framework of multi-domain IPv6-only underlay network 
	  is defined in <xref target="I-D.ietf-v6ops-framework-md-ipv6only-underlay"/>. 
	  A multi-domain IPv6-only Network refers to a network environment 
	  where multiple autonomous systems (ASs) or administrative domains 
	  operate with IPv6 as the sole network protocol. In such a network, 
	  all internal network devices, e.g. core routers, 
	  are configured to support only IPv6 for addressing, routing, and packet forwarding. 
	  This type of network is designed to provide seamless end-to-end IPv6 connectivity
	  across different domains, enabling more efficient use of IPv6 resources and better 
	  support for emerging IPv6-based applications. 
	  </t>
	  <t>In a multi-domain IPv6-only Network, the cooperation and interoperability 
	  between different domains are crucial. To achieve this, standardized protocols 
	  and mechanisms are required to ensure the correct exchange of routing information, 
	  the seamless transfer of packets across domain boundaries, and the proper handling 
	  of various network services.
	  </t>
	  <t>Provider Edge (PE) devices are the edge routers located at the boundary between
	  a service provider's network and its customer networks or other service provider 
	  networks in a multi-domain IPv6-only network. These devices play a vital role 
	  in connecting different networks and facilitating the exchange of traffic. 
	  In an IPv6-only environment, PE devices are responsible for performing a series of functions,
	  such as routing IPv6 packets between different domains, providing connectivity for customer networks, 
	  and handling the translation and encapsulation of packets when necessary to support legacy IPv4 services.
	  </t>
	  <t>PE devices need to support a wide range of IPv6-related features and protocols 
	   to ensure smooth operation in the multi-domain IPv6-only network. 
	   They must be able to interact with other network devices, both within the same domain 
	   and across different domains, in a compliant and efficient manner.
	  </t>
	   </section>
	   
	  <section title="Scope of this Document">
	  <t>This document focuses on defining the basic requirements for PE Routers 
	  located at the edge of  multi-domain IPv6-only networks. 
	  It outlines the necessary functions and capabilities that PE devices should 
	  possess to operate effectively in a multi-domain IPv6-only Network environment. 
	  The requirements include the support for fundamental IPv6 protocols, 
	  the implementation of extensions related to MP-BGP for 4map6, the ability to perform encapsulation
	  and translation based on IPv6 mapping prefix, as well as the support for SRv6 and NAT64 functions.
	  </t>
	  <t>It should be noted that this document does not cover all the requirements for PE devices, 
	  it only introduces the parts directly related to IPv6-only.
	  By specifying these requirements, this document aims to provide a common recommendation for 
	  equipment vendors and network operators, facilitating the development, deployment, 
	  and interoperability of multi-domain IPv6-only PE Routers. 
	  This will ultimately contribute to the successful establishment and 
	  operation of multi-domain IPv6-only network.
	  </t>
      </section>
	</section>

    <section title="Conventions used in this document">
      <t>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 <xref target="RFC2119"/>
      .</t>
    </section>

    <section title="Terminology">
      <t>The following terms are defined in this draft:<list style="symbols">
          <t> multi-domain IPv6-only underlay network: IPv6-only underlay
      network which consists of multiple ASes operated by single or
      multiple operators.</t>

		  <t>AS: Autonomous System</t>
		  <t>ICMPv6:Internet Control Message Protocol for the Version 6 Internet Protocol</t>
		  <t>MP-BGP: Multiprotocol Border Gateway Protocol</t>
		  <t>SRv6: Segment Routing over IPv6</t>
          <t>PE: Provider Edge, defined in <xref target="RFC4026"/></t>

        </list></t>

      <t/>
    </section>

    <section title="IPv6 Base Protocols Requirements">
      <section title="IPv6 Addressing">
        <t>PE devices must support <xref target="RFC8200"/> and correctly handle different
		IPv6 address formats, including unicast, multicast, and anycast addresses.
		They should be able to identify and process these address types in routing 
		and packet forwarding operations. The representation of IPv6 addresses should
		follow the standard notation defined in <xref target="RFC5952"/>. </t>
		
        <t>For instance, when a PE router receives a packet destined for a multicast IPv6 address,
		it should be able to forward the packet to the appropriate multicast group members 
			based on its multicast routing table, which is built using protocols like Multicast
			Listener Discovery for IPv6.</t>
		</section>

      <section title="IPv6 Routing Protocols">
		<section title="Interior Gateway Protocols">
		<t>PE devices must support at least one IGP protocols such as IS-IS <xref target="RFC5308"/>, OSPFv3<xref target="RFC5340"/>,, etc., 
		though the specific protocol employed is at the operator's discretion.
        This document provides no specific recommendations in this regard.
		</t>		
		</section>  
		 
		<section title="Exterior Gateway Protocol">
        <t>PE devices shall support Multi-Protocol Border Gateway Protocol (MP-BGP),
		MP-BGP is essential for inter - domain routing in a multi-domain IPv6-only Network.
		PE routers shall use MP-BGP to exchange routing information with other autonomous systems.
		They should be able to establish MP-BGP sessions with peer routers in other domains,
		advertise and receive IPv6 routes, and apply appropriate routing policies. 
		For example, when a service provider's network needs to connect to 
		another service provider's multi-domain IPv6-only network, 
		the PE routers at the inter-domain boundaries use MP-BGP to exchange routing information,
		enabling the transfer of traffic between the two networks.</t>
		</section> 
	  </section> 
	
	<section title="Internet Control Message Protocol version 6 (ICMPv6)">
		<t>PE devices must fully support ICMPv6 as defined in <xref target="RFC4443"/>.
		ICMPv6 is used for various control and diagnostic functions in IPv6 networks.
		PE routers should be able to generate, process, and forward ICMPv6 messages such as echo requests and replies,
		router solicitations and advertisements, and neighbor solicitations and advertisements. </t>
		
		<t>For example, when receiving a Neighbor Solicitation (NS) message sent by a host in the user-side network,
		the PE router can respond with a Neighbor Advertisement (NA) message. 
		The PE router can advertise the routing information of the user network to 
		the service provider, enabling routing intercommunication between the enterprise network 
		and the external network, so that devices within the enterprise can communicate with the external network.
		</t>
		
        <t>Additionally, ICMPv6 error messages, such as destination unreachable messages, 
		are crucial for network troubleshooting.PE routers must be able to correctly handle and
		forward these error messages to the appropriate sources.</t>
	</section>
	</section>
	
	<section title="MP-BGP Extension for IPv4/IPv6 Mapping Advertisement">
      <section title="Overview of IPv4/IPv6 Mapping Advertisement">
	  <t>IPv4/IPv6 mapping advertisement mechanism can be used to support the 
	  translation and encapsulation of IPv4 packets in an IPv6-only network environment(i.e. IPv4-as-a-Service). 
	  It allows for the co-existence of IPv4 services within a multi-domain IPv6-only Network. 
	  In this case, IPv4 addresses are mapped to IPv6 addresses, enabling the transfer of
	  IPv4-based traffic over an IPv6 infrastructure.</t>
	  </section>
	  
	  <section title="MP-BGP Extension Requirements">
		<section title="Route Type">
		<t>PE routers must support the new route types defined for the MP-BGP extension related to 
		4map6 as specified in <xref target="I-D.ietf-idr-mpbgp-extension-4map6"/>. 
		These route types are used to carry information about the mapping between IPv4
		addresses and IPv6 addresses. For example, the PE router should be able to
		advertise and receive routes that contain information about which IPv4 
		address ranges are associated with which IPv6 mapping prefixes. 
		This information is crucial for other routers in the network to correctly route IPv4-mapped traffic.</t>
		</section>
		
		<section title="Attribute Support">
		<t>MP-BGP Attributes for IPv4/IPv6 mapping advertisement: 
		PE devices need to support the specific MP-BGP attributes defined for 4map6.
		These attributes carry additional information related to the 4map6 translation and encapsulation process. 
		The PE router must be able to correctly attach and interpret these attributes when advertising and receiving routes.
		</t>
		</section>
		
		<section title="Route Advertisement and Withdrawal">
		<t>PE routers should be capable of accurately advertising 4map6-related routes to other routers in the network. 
		When a new IPv4-to-IPv6 mapping is established, the PE router must advertise the relevant route information 
		to its peers in a timely manner. Similarly, when a mapping is removed or changed, 
		the PE router should withdraw the old route and advertise the updated information. 
		This ensures that the network's routing tables are always up-to-date and that traffic is routed correctly.</t>
		
		<t>For example, if a new enterprise customer with IPv4-only applications is added to 
		the multi-domain IPv6-only Network, the PE router serving that customer needs to 
		advertise the appropriate 4map6 routes to other routers in the service provider's network, 
		enabling the delivery of the customer's IPv4 traffic.
		</t>
		</section>
	</section>

</section>
	
	<section title="Encapsulation and Translation Based on IPv6 Mapping Prefix">
      <section title="Stateless IPv4-in-IPv6 Encapsulation">
	  <t>PE devices must support the encapsulation of IPv4 packets within IPv6 packets. 
	  When an IPv4 packet needs to be transported over an IPv6-only network,
	  the PE router should be able to encapsulate the IPv4 packet inside an IPv6 header. 
	  The IPv6 header will contain the source and destination IPv6 addresses, 
	  which are used for routing the encapsulated packet through the IPv6 network. </t>
	  <t>For example, consider a scenario where a customer in a multi-domain IPv6-only Network
	  has an application that still uses IPv4. When the customer's device sends an IPv4 packet, 
	  the PE router at the edge of the customer's network encapsulates this IPv4 packet within an IPv6 packet.
	  The IPv6 packet is then routed through the service provider's IPv6-only network until it reaches the appropriate egress PE router, 
	  which will decapsulate the IPv4 packet and forward it to the final IPv4-based destination. </t>
	  </section>
	  
	  <section title="Translation Function">
		<section title="Stateless IPv4/IPv6 Translation">
		 <t>PE devices must support the stateless translation mechanism as defined 
		 in <xref target="RFC7915"/>. 
		 Stateless translation allows for the translation of IPv4 packets to IPv6 packets and 
		 vice versa without maintaining state information about the translation. 
		 When an IPv4 packet arrives at a PE router in an IPv6-only network, the router should 
		 be able to translate the IPv4 packet into an IPv6 packet. This involves translating the 
		 IPv4 header fields, such as source and destination addresses, into their equivalent IPv6 formats. </t>
		 
		 <t>For example, if an IPv4-only server is accessed from a client in an IPv6-only network, 
		the PE router at the network edge can use Stateless IPv4/IPv6 Translation to translate 
		the IPv4 packets sent by the server into IPv6 packets that can be routed through the IPv6 network 
		to reach the client. Similarly, when the client sends a response, the PE router can translate the
		IPv6 packet back into an IPv4 packet for the server to understand.</t>
		</section>
		
		<section title="Stateful NAT64">
		<t>PE routers shall support Stateful NAT64 <xref target="RFC6145"/> to connect with the customer 
		network and enable IPv6-only users to access IPv4 services over IPv6-only network.
		Stateful NAT64 is a technology used to enable communication between IPv6-only hosts and 
		IPv4-only hosts as defined in RFC 6146. It allows IPv6-only devices to access IPv4-based 
		services by translating IPv6 addresses to IPv4 addresses. In a multi-domain IPv6-only Network,
		NAT64 is important for providing backward compatibility and enabling the continued use of legacy 
		IPv4 applications.</t>
		<t>PE routers must support the translation of IPv6 addresses to IPv4 addresses. 
		When an IPv6-only host in a customer network connected to a PE router attempts to access an IPv4-only server,
		the PE router should be able to translate the IPv6 source and destination addresses in the packet to their equivalent IPv4 addresses.
		This translation process involves mapping the IPv6 addresses to an available pool of IPv4 addresses maintained by the PE router.</t>
		<t>For example, if an IPv6-only mobile device in a customer's network tries to access an IPv4 - based website, 
		the PE router serving that customer will perform the IPv6-to-IPv4 translation. 
		It will select an available IPv4 address from its pool, and create a stateful NAT64 IP address translation state.</t>
		</section>
	</section>
	</section>
	
	<section title="SRv6 Support">
		<section title="Segment Routing over IPv6 (SRv6) Basics">
		<t>SRv6 <xref target="RFC8402"/> is a form of segment routing that uses IPv6 as the underlying technology. 
		It allows for the encoding of a sequence of network segments (represented as IPv6 addresses) 
		in the packet header, enabling more flexible and programmable routing. 
		In a multi-domain IPv6-only Network, SRv6 can be used to provide efficient traffic engineering, 
		simplify network operations, and support new services.</t>
		</section>
		<section title="SRv6 Functionality Requirements in PE Routers">
			<section title="SRv6 Endpoint Function">
			<t>PE routers shall support the SRv6 endpoint function. 
			This means that when a packet arrives at a PE router with an SRv6 segment list in its header, 
			the router should be able to process the segment list and perform the appropriate actions. 
			The PE router may need to pop the top - most segment from the list, forward the packet to 
			the next hop based on the remaining segment list, or perform other operations as defined by the SRv6 architecture.</t>
			<t>For example, in a service provider network using SRv6 for traffic engineering, 
			a PE router may receive a packet with an SRv6 segment list that directs the packet to traverse
			a specific path through the network. The PE router, acting as an SRv6 endpoint, will process the 
			segment list and forward the packet accordingly, ensuring that the packet follows the intended path.</t>
			</section>
			
			<section title="SRv6 Policy Support">
			<t>PE devices should support SRv6 policies. These policies can be used to define 
			how traffic should be routed based on various criteria such as source and destination 
			addresses, application type, or QoS requirements. The PE router must be able to enforce these
			policies by correctly handling SRv6-enabled packets. For instance, a service provider may 
			define an SRv6 policy that routes high-priority video traffic along a different path 
			than regular data traffic. The PE router, upon receiving packets marked as high-priority video traffic, 
			will apply the SRv6 policy and route the packets along the pre-defined path.</t>
			</section>
			
			<section title="SRv6-related Routing Information Exchange">
			<t>PE routers need to participate in the exchange of SRv6-related routing information. 
			This may involve advertising SRv6 capabilities, segment lists, and other relevant information
			to other routers in the network. The exchange of this information can be achieved through 
			existing routing protocols such as MP-BGP, where additional attributes or extensions can be used to
			carry SRv6-specific information. For example, a PE router may advertise its SRv6 capabilities and 
			the available segment lists to its MP-BGP peers, enabling them to make informed routing decisions 
			when handling SRv6-enabled traffic.</t>
			</section>
		</section>
	</section>
	

<section title="Configuration and Management Considerations">
      <t>As a forwarding node in IPv6-only networks, PE router shall accept centralized policy scheduling 
	  from the network controller and implementing automated configuration through the NETCONF protocol/YANG model.
	  Meanwhile, the PE supports syslog and SNMP Trap alarm mechanisms,
	  enabling rapid fault location and security incident tracing through standardized logs.</t>
    </section> 

    
    <section title="Security Considerations">
      <t>TBD</t>
          </section> 

    <section title="Acknowledgements">
   
      <t>TBD</t>
    </section>
 
  </middle>

  <back>
    <references title="Normative References">

      <?rfc include="reference.RFC.2119"?>
         
      <?rfc include="reference.RFC.2473"?>

      <?rfc include="reference.RFC.3315"?>
	  
	 <?rfc include="reference.RFC.4026"?>

      <?rfc include="reference.RFC.4443"?>

      <?rfc include="reference.RFC.5308"?>
	  
	 <?rfc include="reference.RFC.5340"?>
	  
	 <?rfc include="reference.RFC.5952"?>
	  
	 <?rfc include="reference.RFC.6145"?>
	  
	 <?rfc include="reference.RFC.6146"?>
	  
	 <?rfc include="reference.RFC.7915"?>
	  
	 <?rfc include="reference.RFC.8200"?>
	  
      <?rfc include="reference.RFC.8402"?>
	  
	 <?rfc include="reference.RFC.8986"?>
	  
	 <?rfc include="reference.RFC.9514"?>
	 
    </references>

    <references title="Iormative References">
      <?rfc include="reference.RFC.4861"?>
	  
	 <?rfc include="reference.RFC.6052"?>

      <?rfc include="reference.I-D.ietf-v6ops-framework-md-ipv6only-underlay"?>
	  
      <?rfc include="reference.I-D.ietf-idr-mpbgp-extension-4map6"?>
      
    </references>
  </back>
</rfc>