<?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-dong-spring-sr-4map6-segments-00"
     ipr="trust200902">
  <front>
    <title abbrev="MP-BGP Extension for 4map6 Advertisement">4map6 Segments
    for IPv4 Service delivery over IPv6-only underlay networks</title>

    <author fullname="Guozhen Dong" initials="G" surname="Dong">
      <organization>China Telecom</organization>

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

          <city>Beijing</city>

          <code>102209</code>

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

        <email>donggz@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>

          <code>102209</code>

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

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

    <author fullname="Xing Li" initials="X" surname="Li">
      <organization>CERNET Center/Tsinghua University</organization>

      <address>
        <postal>
          <street>Shuangqing Road No.30, Haidian District</street>

          <city>Beijing</city>

          <code>100084</code>

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

        <email>xing@cernet.edu.cn</email>
      </address>
    </author>

    <author fullname="Shuping Peng" initials="S" surname="Peng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Building, No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>pengshuping@huawei.com</email>
      </address>
    </author>

    <date day="14" month="September" year="2023"/>

    <workgroup>Network Working Group</workgroup>

    <keyword>RFC</keyword>

    <abstract>
      <t>This document defines two new types of segments for Segment Routing,
      i.e., M46S and M46D segments, which are mapping rules based IPv4/IPv6
      conversion function running in PE nodes. This segment can be used for
      IPv4 service delivery over IPv6-only undelay networks.Both M46S and M46D
      are called 4map6 segments. Both M46S and M46D are called 4map6 segments
      and run in pairs.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The document [I-D./draft-ietf-v6ops-framework-md-ipv6only-underlay]
      proposes a framework for deploying IPv6-only as the underlay in
      multi-domain networks. In this framework, each PE will be identified by
      at least one IPv6 mapping prefix, it will also have one or more
      associated IPv4 address blocks which are extracted from local IPv4
      routing table or address pool. In addition, a specific data structure
      called address mapping rule is defined to express the mapping
      relationship between IPv4 address blocks and the IPv6 mapping prefix of
      the remote PE. With this design, if the mapping rules of the remote PE
      are obtained by the ingress PE, the mapping rule will give the
      forwarding guidance of IPv4 packet delivery in the IPv6-only network
      when the destination address of the IPv4 packet matches its IPv4 address
      block, the ingress PE will use the mapping rule to generate
      corresponding IPv6 source and destination addresses from its IPv4 source
      and destination addresses, and then generate a new IPv6 packet.</t>

      <t>This mapping-based conversion can also work in SRv6 <xref
      target="RFC8986"/> networks. SRv6 defines packet processing in IPv6
      network as a list of instructions, which are represented as 128-bit
      segments, often called Segment ID (SID). This document defines two new
      types of segments for Segment Routing, i.e., M46S and M46D segments,
      which are mapping rules based IPv4/IPv6 conversion function running in
      PE nodes. In multi-domain IPv6-only networks, the M46S and M46D segments
      at the ingress node can convert IPv4 packets into IPv6 ones by stateless
      encapsulation or translation, another M46S and M46D segments at the
      egress node can restore them to IPv4 packets after being transmitted in
      IPv6-only networks.</t>

      <section title="Requirements Language">
        <t>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<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Overview of the new SID">
      <t>SRv6 SID has the same format as a 128-bit IPv6 address, As per
      section 3 of <xref target="RFC8986"/>, a SID consists of LOC:FUNCT:ARG,
      where a locator (LOC) is encoded in the L most significant bits of the
      SID, followed by F bits of function (FUNCT) and A bits of arguments
      (ARG).</t>

      <t><figure>
          <artwork><![CDATA[
+----------+----------------+----------+------------+------------+
|      LOC(L bits)          |      FUNCT(F bits)    | ARG(32bits)|
+----------+----------------+----------+------------+------------+
     Figure 1: 4map6 SID architecture]]></artwork>
        </figure></t>

      <t>The LOC identifies the node which instantiates the SID and will lead
      the packets to the node. The FUNCT is an opaque identification of
      behavior bound to the SID. ARG field provides additional information for
      its processing. As new types of SID, M46S and M46D segments will follow
      the format of a general SID. Furthermore, several information items
      specific to stateless address mapping and packet conversion are carried
      in the relevant fields of the M46S SID and M46D SID, as below,</t>

      <t>&bull; The LOC field is a prefix allocated by operators to identify
      the node which instantiates the M46S/M46D SID.</t>

      <t>&bull; The FUNCT field identifies the behavior bound to the M46S/M46D
      SID, the behavior will be defined in Section 4.</t>

      <t>&bull; The ARG field contains the IPv4 address prefix associated with
      the PE node. Since the IPv4 address prefix requires a maximum of 32 bits
      of a SID, the value of L+F should be less than or equal to 96.</t>

      <t>For the PE node which instantiates M46S/M46D SID, its IPv6 mapping
      prefix for IPv4 delivery corresponds to the combination of LOC and FUNCT
      fields. Generally, the number of SIDs that can be instantiated by both
      M46S SID and M46D SID is equal to the number of associated IPv4 address
      blocks.</t>

      <t>When an operator instantiates a M46S/M46D SID at an edge node, they
      specify a SID value LOC:FUNCT:ARG and the behavior bound to the SID, An
      SRv6 endpoint behavior may require additional information for its
      processing (e.g. tunnel or translation). This information may be carried
      in the control plane, which is out of the scope of this draft.</t>
    </section>

    <section title="Behavior">
      <t>Generally, the M46S/M46D SID nodes run in pairs. For a specific data
      flow, one node is ingress PE, denoted by PE1, and the other is egress
      PE, denoted by PE2.</t>

      <t>All nodes located at the edge of the network need to announce their
      M46D SIDs to other nodes. PE2 announces its ability to other nodes in
      the format of M46D SID in the SRv6 domain at the control plane. When PE1
      receives the M46D SID announced by PE2, it will bestored in the local
      database. This database can store multiple entries, and each entry
      includes IPv4 address block, Locator, Function, device capability and
      other information corresponding to the SID, The IPv6 mapping prefix,
      i.e. Locator and Function, represents the egress of the packet whose
      destination address is the IPv4 address block.</t>

      <t>When PE1 receives an IPv4 packet, it uses the destination IPv4
      address block to look for the corresponding IPv4 address block entry in
      the local database. If a matching IPv4 address block entry is found, the
      corresponding IPv6 mapping prefix will splice the IPv4 destination
      address to generate a M46D SID, and the 32-bit IPv4 address is placed in
      the ARG field. Following the general SRv6 procedure, the SID is
      programmed into SRH.</t>

      <t>After that, the IPv4 destination address needs to be spliced with the
      corresponding IPv6 mapping prefix, and the M46S SID behavior identifier
      is placed in the FUNCT field to generate the M46S SID. The 32-bit IPv4
      source address in the data packet is placed in the ARG field. Following
      the general SRv6 procedure, M46S SID is programmed into SRH.</t>

      <t>The newly generated packet with the SRH is sent into the IPv6-only
      network for further delivery. In this case, the source address SA of the
      IPv6 packet is the PE1 local address, and the destination address DA is
      taken from SRH according to the SRv6 procedure. The process is shown in
      the figure below,<figure>
          <artwork><![CDATA[
               +-------------------------------------+
              /                                       \
        +----+----+           Multi-domain        +----+----+
        |    PE1  |        IPv6-only Network      |   PE1   |
        +----+----+                               +----+----+
              \                                       /
               +-------------------------------------+
                +-----------------------------------+
                |                IPv6               |
                |               SA=PE1              |
                |               DA=PE2              |
                +-----------------------------------+
                |                SRH              |
                | LOC=PE2   FUNCT=M46D  ARG=IPv4 DA |
                | LOC=PE1   FUNCT=M46S  ARG=IPv4 SA |
                +-----------------------------------+
                |                IPv6               |   
                +-----------------------------------+     
Figure 2: IPv6 packet delivery process carrying M46D and M46S SID          
]]></artwork>
        </figure></t>

      <t>When a new IPv6 packet arrives at PE2, PE2 parses its Locator part.
      If it matches the IPv6 mapping prefix instantiated by itself, it
      decapsulates the packet according to the instructions in Function,
      removes the SRH and IPv6 mapping prefix of the outer layer, and then
      forwards it to the next-hop according to the destination IPv4 address
      carried in the ARG field.</t>

      <t>When a new IPv6 packet arrives at PE2, PE2 resolves the LOC part of
      SRH in this packet layer by layer. If it matches the IPv6 mapping prefix
      of its own instantiation, it decapsulates the packet according to the
      instructions in the FUNCT. Recognition to the FUNCT field M46S and M46D
      respectively, to extract the corresponding to the ARG field source IPv4
      address and purpose to carry the IPv4 address forward IPv4 packet to the
      next-hop recovery.</t>
    </section>

    <section title=" Advertising 4map6 SID">
      <t>In an SRv6 network environment, the M46S/M46D SID needs to be
      advertised. The node advertises the M46S/M46D SID, B:N:FUNCT:ARG,through
      the control plane together with the SRv6 Endpoint Behavior codepoint
      identifying the behavior of the SID. Similar to other types of SIDs, the
      M46S/M46D SID can be distributed within and across domains via IGP and
      BGP or other approaches. The advertisement method and reachability
      calculation are specific to the chosen routing protocol. The
      distribution of the M46S/M46D Endpoint Behavior codepoint is left in
      future documents, e.g. by extending the SRv6 L3 Service TLV as defined
      in <xref target="RFC9252"/>.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requests IANA to allocate the following codepoints in
      "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing Parameters"
      top-level registry.</t>

      <figure>
        <artwork><![CDATA[  
+----------+--------+-----------------------+-----------------+
|   Value  |   Hex  |  Endpoint behavior    |     Reference   | 
|----------|--------|-----------------------|-----------------| 
|    TBD   |        |     End.M46S          |   [This.ID]     |
+----------+--------+-----------------------+-----------------+
|    TBD   |        |     End.M46D          |   [This.ID]     |
+----------+--------+-----------------------+-----------------+
                 table 1:   End.4map6 Endpoint Behavior]]></artwork>
      </figure>
    </section>

    <section title="Security Considerations">
      <t>There is no additional security risk introduced by this design.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

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

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

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

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

      <?rfc include='reference.RFC.8754'?>

      <?rfc include="reference.RFC.8986"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-v6ops-framework-md-ipv6only-underlay'?>
    </references>
  </back>
</rfc>
