Skip to main content

4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks
draft-dong-spring-sr-4map6-segments-01

Document Type Active Internet-Draft (individual)
Authors Guozhen Dong , Chongfeng Xie , Xing Li , Shuping Peng
Last updated 2024-06-30
Replaces draft-dong-spring-sr-4map6-segment
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
On agenda spring at IETF-120
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dong-spring-sr-4map6-segments-01
Network Working Group                                            G. Dong
Internet-Draft                                                    C. Xie
Intended status: Standards Track                           China Telecom
Expires: 2 January 2025                                            X. Li
                                       CERNET Center/Tsinghua University
                                                                 S. Peng
                                                     Huawei Technologies
                                                             1 July 2024

    4map6 Segments for IPv4 Service delivery over IPv6-only underlay
                                networks
                 draft-dong-spring-sr-4map6-segments-01

Abstract

   This document defines a new type of segment for Segment Routing,
   4map6 segment, which is an IPv4/IPv6 conversion function based on
   stateless mapping rules running in PE nodes for the delivery of IPv4
   services over IPv6-only network.  At the same time, the BGP Prefix-
   SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6
   address mapping rules in IPv6-only domain and cross-domain.

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 2 January 2025.

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.

Dong, et al.             Expires 2 January 2025                 [Page 1]
Internet-Draft          4map6s Segments Delivery               July 2024

   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 . . . . . . . . . . . . . . . . . .   3
   2.  Overview of the new SID . . . . . . . . . . . . . . . . . . .   3
   3.  SRv6 Service TLV Extension  . . . . . . . . . . . . . . . . .   4
   4.  Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

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

Dong, et al.             Expires 2 January 2025                 [Page 2]
Internet-Draft          4map6s Segments Delivery               July 2024

   This mapping-based conversion can also work in SRv6 [RFC8986]
   networks.  SRv6 defines packet processing in IPv6 networks as a list
   of instructions, which are represented as 128-bit segments, often
   referred to as Segment ID (SID).  In this document, a new type of
   segments, 4map6 segments, is defined for Segment Routing.  They run
   in PE nodes and provide support for implementing IPv4/IPv6 conversion
   function based on mapping rules.  In multi-domain IPv6-only networks,
   ingress nodes can convert IPv4 packets into IPv6 packets by stateless
   encapsulation or translation using the information in 4map6 segments,
   and egress nodes can restore IPv4 packets after transmission in
   IPv6-only networks.

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.  Overview of the new SID

   The SRv6 SID has the same format as a 128-bit IPv6 address, and
   according to Section 3 of [RFC8986], the SID consists of
   LOC:FUNCT:ARG, where the address (LOC) is encoded in the L most
   significant bits of the SID, followed by F bits of the function
   (FUNCT), and A bits of the argument (ARG).

   +----------+----------------+----------+------------+------------+
   |      LOC(L bits)          |      FUNCT(F bits)    | ARG(32bits)|
   +----------+----------------+----------+------------+------------+
                     Figure 1: SID architecture

   The LOC identifies the node where SID is instantiated and directs the
   packet to it.  The FUNCT is an opaque identity for a behavior bound
   to SID.  The ARG field provides additional information for its
   processing.  As a new type of SID, the 4map6 segment will follow the
   format of the general SID.  In addition, some information items
   specific to stateless address mapping and packet translation are
   carried in the relevant fields of the 4map6 SID as follows:

       • The LOC field has the positioning function, which is unique in
       the SR domain.  It is a prefix assigned by the operator, and its
       value reflects the operator's IPv6 address planning.  The
       operator needs to plan according to its own networking and
       business classification, and it is used to identify the node that
       instantiates the 4map6 SID.

Dong, et al.             Expires 2 January 2025                 [Page 3]
Internet-Draft          4map6s Segments Delivery               July 2024

       • The FUNCT field identifies the behavior bound to the 4map6 SID
       and is used to instruct the 4map6 SID node to perform the
       corresponding functional operation.

       • The ARG field contains the behavioral identity of whether
       stateless encapsulation or translation is performed at that point
       and the IPv4 address associated with the PE node.  The value of
       L+F should be less than or equal to 96 since 32 bits are required
       for IPv4 address.

   For a PE node instantiating a 4map6 SID, its IPv6 mapping prefix IPv6
   Prefix for IPv4 transmission corresponds to the LOC field.  For the
   encapsulation or translation processing of IPv4 packets E/T is
   distinguished by the identity of ARG field.  The 4map6 SID therefore
   has the structure IPv6 Prefix + E/T + IPv4 address.  In general, the
   number of SIDs that can be instantiated on a PE is equal to the
   number of associated IPv4 address blocks.

3.  SRv6 Service TLV Extension

   In SRv6 network environment, 4map6 SID needs to be published to
   implement IPv4/IPv6 address mapping rule advertisement.  This
   document specifies that an egress PE can implement the BGP protocol
   and extend in its BGP Prefix-SID property [RFC8669] to support
   publishing the service SID contained in its TLV, that is, the 4map6
   SID, as an overlay service prefix in the network.  The standard BGP
   update propagation scheme [RFC4271] can make use of route reflectors
   [RFC4456] to propagate these prefixes.  This document defines a new
   BGP prefixed SID attribute extension TLV in the SRv6 Service TLVs to
   implement SID signaling for the 4map6 service of the SRv6 service:

   SRv6 4map6 Service TLV: Used to carry SRv6 SID information of 4map6
   service in multi-domain IPv6-only network, extended to support
   carrying End.4map6 SID.

   The format of the extended SRv6 Services TLV is depicted below:

   0              7              15           23             31
   +--------------+----------------------------+--------------+
   |   TLV Type   |       TLV  Length          |   Reserved   |
   +--------------+----------------------------+--------------+
   |                                                          |
   |                   SRv6 Service Sub-TLVs                  |
   |                                                          |
   +----------------------------------------------------------+
                    Figure 2: SRv6 Services TLV

Dong, et al.             Expires 2 January 2025                 [Page 4]
Internet-Draft          4map6s Segments Delivery               July 2024

   TLV Type (8 bits):
      Used to identify different TLVS, SRv6 4map6 Service TLV is 8.

   TLV Length (16 bits):
      Total length of the TLV.

   RESERVED (8 bits):
      Reserved fields.

   SRv6 Service Sub-TLVs (variable):
      This field contains more specific SRv6 service information and is
      encoded as an unordered list of Sub-TLVs whose format is described
      below.

   The format of SRv6 Service Sub-TLVs is depicted below:

   0              7              15           23             31
   +--------------+----------------------------+--------------+
   | SRv6 Service |       SRv6 Service         | SRv6 Service |
   | Sub-TLV Type |       Sub-TLV Length       | Sub-TLV Value|
   +--------------+----------------------------+--------------+
                Figure 3: SRv6 Service Sub-TLV

   SRv6 Service Sub-TLV Type (8 bits):
      This field identifies the type of SRv6 service information, which
      takes the value 1, indicates the SRv6 SID Information Sub-TLV.

   SRv6 Service Sub-TLV Length (16 bits):
      The sub-TLV length.

   SRv6 Service Sub-TLV Value (variable):
      This field contains data specific to the Sub-TLV Type.  The SRv6
      SID information of 4map6 Service is filled in the SRv6 Service
      Sub-TLV Value field.

4.  Behavior

   In general, 4map6 SID nodes operate in pairs.  For a particular data
   stream, one node is the ingress PE, denoted by PE1, and the other is
   the egress PE, denoted by PE2.  Each PE maintains a Mapping rule
   Database (MD) as shown in Figure.  The table entries in the MD
   database consist of IPv4 address prefixes, IPv6 mapping prefixes, and
   the encapsulation or translation processing E/T way of IPv4 packets.
   It should be noted that the database here is only an example, and
   developers can design the structure of the database according to the
   actual situation.

Dong, et al.             Expires 2 January 2025                 [Page 5]
Internet-Draft          4map6s Segments Delivery               July 2024

+-------------------+-------------------+--------------------------------+
|IPv4 Address Prefix|IPv6 Mapping Prefix|Encapsulation or Translation E/T|
+-------------------+-------------------+--------------------------------+
                 Figure 4: The Structure of Map Rule Database

   Before transmitting an IPv4 packet from PE1 to PE2, the address
   mapping rule corresponding to its IPv4 destination address needs to
   be transferred from PE2 to PE1.  Therefore, PE2, which supports 4map6
   service based on SRv6, publishes the 4map6 SID corresponding to the
   IPv4 destination address in the BGP Prefix-SID attribute, so as to
   realize the PE2 node located at the edge of the network to other
   nodes and synchronize the address mapping rule database on each PE
   device.  PE2 announces its capabilities to other nodes in the format
   of the 4map6 SID of the SRv6 domain in the control plane.  When PE1
   receives the 4map6 SID announced by PE2, it extracts the relevant
   information and stores it in the local mapping rule database.  The
   LOC field in the 4map6 SID corresponds to the database IPv6 Mapping
   Prefix, the Encapsulation/Translation behavior identifier bit in the
   ARG corresponds to the database encapsulation or translation E/T, and
   the address field in the ARG corresponds to the database IPv4 address
   block.

   When PE1 receives an IPv4 packet, it first uses the destination IPv4
   address block to find the corresponding IPv4 address block entry in
   the local mapping rule database.  If there is a matching IPv4 address
   block entry, the corresponding IPv6 mapping prefix will concatenate
   the IPv4 destination address to generate the 4map6 SID, and the
   32-bit IPv4 destination address in the packet is placed in the ARG
   field.  According to the general SRv6 procedure, the SID is
   programmed as an IPv6 destination address, and the newly generated
   packet is sent to the pure IPv6 network for further delivery.

   When a new IPv6 packet arrives at PE2, PE2 resolves the IPv6
   destination address of the packet.  If it matches an IPv6 mapping
   prefix in its instantiated SID, it will process the packet according
   to the 4map6 instruction in FUNCT, remove the IPv6 mapping prefix and
   forward it to the next hop according to the encapsulation/translation
   behavior in ARG field and the destination IPv4 address carried.

5.  IANA Considerations

   This document requests IANA to allocate the following codepoints in
   "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing
   Parameters" top-level registry.

Dong, et al.             Expires 2 January 2025                 [Page 6]
Internet-Draft          4map6s Segments Delivery               July 2024

   +----------+--------+-----------------------+-----------------+
   |   Value  |   Hex  |  Endpoint behavior    |     Reference   |
   |----------|--------|-----------------------|-----------------|
   |    TBD   |        |     End.4map6         |   [This.ID]     |
   +----------+--------+-----------------------+-----------------+
                    Figure 5: End.4map6 Endpoint Behavior

6.  Security Considerations

   There is no additional security risk introduced by this design.

7.  References

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

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
              <https://www.rfc-editor.org/info/rfc4456>.

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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8669]  Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
              A., and H. Gredler, "Segment Routing Prefix Segment
              Identifier Extensions for BGP", RFC 8669,
              DOI 10.17487/RFC8669, December 2019,
              <https://www.rfc-editor.org/info/rfc8669>.

Dong, et al.             Expires 2 January 2025                 [Page 7]
Internet-Draft          4map6s Segments Delivery               July 2024

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9252]  Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
              B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
              Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
              DOI 10.17487/RFC9252, July 2022,
              <https://www.rfc-editor.org/info/rfc9252>.

7.2.  Informative References

   [I-D.ietf-v6ops-framework-md-ipv6only-underlay]
              Xie, C., Ma, C., Li, X., Mishra, G. S., Boucadair, M., and
              T. Graf, "Framework of Multi-domain IPv6-only Underlay
              Network and IPv4-as-a-Service", Work in Progress,
              Internet-Draft, draft-ietf-v6ops-framework-md-ipv6only-
              underlay-06, 10 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
              framework-md-ipv6only-underlay-06>.

Authors' Addresses

   Guozhen Dong
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: donggz@chinatelecom.cn

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

Dong, et al.             Expires 2 January 2025                 [Page 8]
Internet-Draft          4map6s Segments Delivery               July 2024

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

   Shuping Peng
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: pengshuping@huawei.com

Dong, et al.             Expires 2 January 2025                 [Page 9]