Internet DRAFT - draft-dong-spring-sr-4map6-segment

draft-dong-spring-sr-4map6-segment







Network Working Group                                            G. Dong
Internet-Draft                                                    C. Xie
Intended status: Standards Track                           China Telecom
Expires: 13 September 2023                                         X. Li
                                       CERNET Center/Tsinghua University
                                                                 S. Peng
                                                     Huawei Technologies
                                                           12 March 2023


4map6 Segment for IPv4 Service delivery over IPv6-only underlay networks
                 draft-dong-spring-sr-4map6-segment-00

Abstract

   This document defines a new type of segment for Segment Routing,
   i.e., 4map6 segment, which is a mapping rule-based IPv4/IPv6
   conversion function running in PE nodes.  This segment can be used
   for IPv4 service delivery over IPv6-only undelay 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 13 September 2023.

Copyright Notice

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










Dong, et al.            Expires 13 September 2023               [Page 1]

Internet-Draft  MP-BGP Extension for 4map6 Advertisement      March 2023


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

1.  Introduction

   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.

   This mapping-based conversion can also work in SRv6 [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 a new type of segment
   for Segment Routing, i.e., 4map6 segment, which is a mapping rule-
   based IPv4/IPv6 conversion function running in PE nodes.  In multi-



Dong, et al.            Expires 13 September 2023               [Page 2]

Internet-Draft  MP-BGP Extension for 4map6 Advertisement      March 2023


   domain IPv6-only networks, a 4map6 segment at the ingress node can
   convert IPv4 packets into IPv6 ones by stateless encapsulation or
   translation, another 4map6 segment at the egress node can restore
   them to IPv4 packets after being transmitted 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

   SRv6 SID has the same format as a 128-bit IPv6 address, As per
   section 3 of [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).

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

   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 a new type of SID, 4map6 segment 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 4map6 SID, as below,

   • The LOC field is a prefix allocated by operators to identify the
   node which instantiates the 4map6 SID.

   • The FUNCT field identifies the behavior bound to the 4map6 SID, the
   behavior will be defined in Section 4.

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

   For the PE node which instantiates 4map6 SID, its IPv6 mapping prefix
   for IPv4 delivery corresponds to the combination of LOC and FUNCT
   fields.  Generally, the number of the SIDs it can instantiate equals
   to the number of IPv4 address block associated.




Dong, et al.            Expires 13 September 2023               [Page 3]

Internet-Draft  MP-BGP Extension for 4map6 Advertisement      March 2023


   When an operator instantiates a 4map6 SID at an edge node, they
   specify a SID value LOC:FUNCT:ARG and the behavior bound to the 4map6
   SID, An 4map6 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.

3.  Behavior

   Generally, the 4map6 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.

   All 4map6 nodes located at the edge of the network need to announce
   their 4map6 SIDs to other nodes.  PE2 announces its ability to other
   nodes in the format of 4map6 SID in the SRv6 domain at the control
   plane.  When PE1 receives the 4map6 SID announced by PE2, it will be
   stored 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.

   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 4map6 SID, and the 32-bit IPv4
   address is placed in the ARG field.  Following the general SRv6
   procedure, the SID is programmed into SRH.  The newly generated
   packet with the SRH is sent into the IPv6-only network for further
   delivery.

   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.











Dong, et al.            Expires 13 September 2023               [Page 4]

Internet-Draft  MP-BGP Extension for 4map6 Advertisement      March 2023


4.  Advertising 4map6 SID

   In an SRv6 network environment, the 4map6 SID needs to be advertised.
   The node advertises the 4map6 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 4map6
   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 4map6 Endpoint Behavior codepoint is left in
   future documents, e.g. by extending the SRv6 L3 Service TLV as
   defined in [RFC9252].

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.


   +----------+--------+-----------------------+------------+
   |   Value  |   Hex  |  Endpoint behavior    |     Reference   |
   |----------|--------|-----------------------|-------------|
   |    TBD   |        |     End.4map6         |   [This.ID]     |
   +----------+--------+-----------------------+-------------+
                    table 1:   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>.

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



Dong, et al.            Expires 13 September 2023               [Page 5]

Internet-Draft  MP-BGP Extension for 4map6 Advertisement      March 2023


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

   [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
              Networks and IPv4-as-a-Service", Work in Progress,
              Internet-Draft, draft-ietf-v6ops-framework-md-ipv6only-
              underlay-01, 3 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
              framework-md-ipv6only-underlay-01>.

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



Dong, et al.            Expires 13 September 2023               [Page 6]

Internet-Draft  MP-BGP Extension for 4map6 Advertisement      March 2023


   Beijing
   102209
   China
   Email: xiechf@chinatelecom.cn


   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 13 September 2023               [Page 7]