Skip to main content

Source IPv6 Address Programmability
draft-cheng-6man-source-address-programmability-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Weiqiang Cheng , Liyan Gong , Changwang Lin , Hao Li
Last updated 2023-03-09
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cheng-6man-source-address-programmability-00
6man Working Group                                             W. Cheng
Internet Draft                                                  L. Gong
Intended status: Informational                             China Mobile
Expires: Sep 8, 2023                                             C. Lin
                                                                  H. Li
                                                  New H3C Technologies
                                                          March 7, 2023

                    Source IPv6 Address Programmability
             draft-cheng-6man-source-address-programmability-00

Abstract

   IPv6-based tunneling technologies, such as SRv6, have been deployed
   by provider on transport networks to provide users with services
   such as VPN and SD-WAN.

   After the service traffic enters the provider's transport network,
   it will be encapsulated by tunnel (SRv6 encapsulation). In order to
   better meet the SLA requirements of users, some technologies need to
   carry relevant information along with the flow to guide the
   processing of packets during forwarding.

   This document discusses the programmability of IPv6 source addresses
   to carry the necessary flow information

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

Cheng, et al.           Expire September, 2023                 [Page 1]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 7, 2023.

Copyright Notice

   Copyright (c) 2023 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
   (http://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 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
      1.1. Requirements Language .................................. 3
   2. Restrictions for IPv6 Source address programmability ........ 3
   3. Requirement for IPv6 source address programmability.......... 4
   4. Scenarios of IPv6 source address programmability ............ 5
   5. IANA Considerations ......................................... 7
   6. Security Considerations ..................................... 7
   7. References .................................................. 7
      7.1. Normative References ................................... 7
   Contributors ................................................... 9
   Authors' Addresses ............................................ 10

1. Introduction

   IPv6-based tunneling technologies, such as SRv6, have been deployed
   by provider on transport networks to provide users with services
   such as VPN and SD-WAN.

   When the ingress node (PE) of the transport network receives user
   traffic, it can add IPv6 (SRv6) encapsulation to the user traffic
   according to VPN routes and policies, and the encapsulated service
   traffic is forwarded to the egress device of the transport network.

Cheng, et al.          Expires September, 2023                 [Page 2]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   SRv6 [RFC8754] is a source routing technology. The ingress node of
   the transport network encapsulates the forwarding path (segment
   list) of user traffic in SRH. The encapsulated user traffic will be
   forwarded to the egress node according to the path specified by the
   SRH.

   Meanwhile, in order to better meet user SLA requirements and provide
   differentiated services, it is necessary to be able to carry flow-
   related information with the traffic.

   Although IPv6 itself provides a variety of extension headers, which
   can carry various flow information through extension headers, due to
   various considerations such as bandwidth utilization and device
   implementation difficulty, carrying flow information through source
   addresses is becoming a possible choice

   This document mainly discusses the requirements for source IPv6
   address programmability to support subsequent related specifications
   or protocol extensions.

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. Restrictions for IPv6 Source address programmability

   The IPv6 source address programmability described in this document
   is limited to a limited or trusted domain, such as the SRv6 domain
   of a provider's transport network.

   In a limited domain or trusted domain, the programmable capability
   of the IPv6 source address is allowed to carry flow information.
   That is, when the business flow enters the trust domain, it is
   encapsulated, and the flow information is encoded in the source
   address at the same time. Encapsulation is removed when business
   traffic leaves the trust domain. This leakage of source addresses
   outside the trusted domain needs to be avoided.

   End-to-end IPv6 source address programmability is not recommended.

Cheng, et al.          Expires September, 2023                 [Page 3]
Internet-Draft      Source IPv6 Address Programmability      March 2023

                       +----+     +----+    +----+
   SRv6 Encapsulated   +----+     +----+    +----+
    packet             |    |     |    |    |    |
            +-----+    +----+     +----+    +----+    +----+
   Original |     |                                   |    |
   packet   +-----+                                   +----+
     ---------------------------------------------------------->

                +-------------------------------------+
                |             SRv6  domain            |
         +---+  |   +---+    +--+     +--+     +---+  |  +---+
    -----+CE1+--+---+PE1+----+P1+-----+P2+-----+PE2+--+--+CE2+----
         +---+  |   +---+    +--+     +--+     +---+  |  +---+
                |                                     |
                +-------------------------------------+

                       Figure 1: example topology

3. Requirement for IPv6 source address programmability

   In some scenarios, flow information needs to be carried with the
   packet to help routers to perform special processing on the packet
   when forwarding. The flow information may be associated with the
   local resources of the router, and are used to guarantee the
   bandwidth of a specific flow; or identify a certain attribute of the
   service flow, through which the forwarding policy can be applied,
   and so on.

   Although various extension headers have been defined in [RFC8200],
   information can be carried through these different types of
   extension headers. However, based on the current actual situation,
   there are some defects in carrying information through the extension
   header, such as

   o Low bandwidth utilization

   Taking SRv6 TE as an example, user traffic is encapsulated with SRH
   and IPv6 headers on the headend node, and the newly added
   encapsulation itself occupies part of the bandwidth. If flow
   information is carried through other extension headers such as DOH
   or HBH, the bandwidth utilization rate will further decrease,
   especially for small packets.

   o Highly difficult to implement

   According to the definition of [RFC8200], the DOH and HBH option
   extension headers are suitable for carrying information. If the DOH

Cheng, et al.          Expires September, 2023                 [Page 4]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   is placed before the SRH, each endpoint node can read the content of
   the DOH; if it is placed after the SRH, only the destination node
   can read the content of the DOH.

   If it is required that the forwarding nodes along the way can read
   the flow information, the information can only be carried through
   HBH. However, due to historical reasons, current mainstream network
   devices generally support HBH only limitedly. Although currently
   IETF has some discussions and related documents on HBH, such as [I-
   D.ietf-6man-hbh-processing], it is still difficult for routers to
   support HBH

   In this realistic situation, it is hoped that the information along
   with the flow can be carried without increasing the length of the
   packet, and the intermediate router can realize the function
   relatively easily. IPv6 source address has become an unavoidable
   choice.

   IPv6 addresses have a relatively large 128-bit space. SRv6 uses this
   feature to define segments with various behaviors, most of which can
   be used as IPv6 destination addresses. When the IPv6 destination
   address of a packet is a segment instantiated locally, the Endpoint
   processes the packet according to the definition of the segment. The
   transit node only uses the destination address for basic IPv6
   forwarding. [I-D.ietf-6man-sids] also explains this situation.

   This document discusses the need for IPv6 source address
   programmability. It is hoped that as the source address of the IPv6
   header, it can be used to identify the source node of the tunnel
   encapsulation, and at the same time, it can also carry related
   information of the flow.

   The intermediate nodes of the forwarding path, not limited to the
   endpoint, can obtain the necessary information from the source
   address, and guide the forwarding and processing of the flow
   together with the destination address

   Address structures for programmable source addresses are outside the
   scope of this document

4. Scenarios of IPv6 source address programmability

   This section lists some scenarios where flow information needs to be
   carried with the packet.

   o Scenario of network slicing

Cheng, et al.          Expires September, 2023                 [Page 5]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   Network slicing provides the ability to partition a physical network
   into multiple isolated logical networks of varying sizes,
   structures, and functions so that each slice can be dedicated to
   specific services or customers. [I-D.ietf-teas-ietf-network-slices]
   defines the term "IETF Network Slice" and establishes the general
   principles of network slicing in the IETF context.

   Packets belong to a network slice need to be forwarded using the
   specific network resources. [I-D.ietf-teas-ietf-network-slices]
   defines the network resource mapped to the network slice as NRP,
   that is, the Network Resource Partition, and defines the nrp-id to
   identify the NRP used in the forwarding process.

   In a network that provides slicing services, the NRP-ID can be
   carried in the packet. In the process of packet forwarding, the
   routers on the forwarding path can extract NRP-ID from the packet,
   determine the NRP to which the packet belongs, and then forward the
   packet using the resources associated with the NRP.

   There are still various discussions on how to carry NRP-ID. For
   example, [I-D.ietf-6man-enhanced-vpn-vtn-id] defines options for
   carrying NRP-ID through IPv6 extension headers. [I-D.liu-spring-nrp-
   id-in-srv6-segment] proposes to carry the NRP-ID through the arg
   field of the segment. [I-D.cheng-spring-srv6-encoding-network-
   sliceid] proposed to carry NRP-ID through source address.

   Therefore, for network slicing, carrying the NRP-ID through the
   source address is a direction that can be considered.

   o Scenario of APN

   [I-D.li-apn-problem-statement-usecases] analyzes the existing
   problems caused by lack of application awareness, and outlines
   various use cases that could benefit from Application-aware
   Networking (APN) architecture.

   [I-D.li-apn-ipv6-encap] defines the option to carry the APN
   attribute in the IPv6 data plane, which can be applied to DOH, HBH
   option extension header, and TLV of SRH.

   Of course, APN attributes can be very rich, but if the APN attribute
   can be abstracted into a digital APN ID, which can represent the
   application to which a flow belongs, the intermediate node of the
   forwarding path can apply related policies based on this APN ID.
   Then this APN-ID can also be carried by the source IPv6 address.

   o Scenario of MVPN

Cheng, et al.          Expires September, 2023                 [Page 6]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   The provider offer VPN service, and after the user traffic reaches
   the egress router, it needs to know which VPN the user traffic
   belongs to. How to identify which VPN the user traffic belongs to,
   unicast and multicast behave differently.

   Still taking the IPv6 data plane as an example, SRv6 is used to
   provide unicast L3VPN services. When the user traffic reaches the
   egress router, its destination address is usually the segment of the
   End.DT4/End.DT6/End.DT46[RFC8986] type of the egress router. These
   segments are created on the egress router and associated with the
   local VPN. The egress router continues to forward the decapsulated
   user traffic within the VPN associated with the segment.

   For multicast VPN, encapsulated user traffic is sent to multiple
   egress routers at the same time through multicast forwarding, so the
   segment of the egress router cannot be used like unicast VPN
   service.

   Therefore, multicast VPN is also a potential scenario where IPv6
   source addresses can be programmed.

5. IANA Considerations

   This document has no IANA actions.

6. Security Considerations

   TBD

7. References

7.1. Normative References

   [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6
             Hop-by-Hop Options Processing Procedures", Work in
             Progress, Internet-Draft, draft-ietf-6man-hbh-processing-
             05, 23 February 2023.

   [I-D.ietf-6man-sids] Krishnan. S, "Segment Identifiers in SRv6",
             Work in Progress, Internet-Draft, draft-ietf-6man-sids-02,
             11 October 2022.

Cheng, et al.          Expires September, 2023                 [Page 7]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   [I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J.,
             Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
             Tantsura, "Framework for IETF Network Slices", draft-ietf-
             teas-ietf-network-slices-19 (work in progress), January
             2023.

   [I-D.li-apn-problem-statement-usecases] Li, Z., Peng, S., Voyer, D.,
             Xie, C., Liu, P., Qin, Z., and Mishra, G., " Problem
             Statement and Use Cases of Application-aware Networking
             (APN) ", draft-li-apn-problem-statement-usecases-07 (work
             in progress), April 2023.

   [I-D.li-apn-ipv6-encap] Li, Z., Peng, S., and Xie, C., "
             Application-aware IPv6 Networking (APN6) Encapsulation ",
             draft-li-apn-ipv6-encap-06 (work in progress), December
             2022.

   [I-D.ietf-6man-enhanced-vpn-vtn-id] Dong, J., Li, Z., Xie, C., Ma,
             C., and G. Mishra, "Carrying Virtual Transport Network
             (VTN) Identifier in IPv6 Extension Header", Work in
             Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-
             vtn-id-02, April 2023.

   [I-D.liu-spring-nrp-id-in-srv6-segment] Liu, Y., Lin, C., Li, H.,
             and Gong, L., "NRP ID in SRv6 segment", draft-liu-spring-
             nrp-id-in-srv6-segment-01 (Work in Progress), April 2023.

   [I-D.cheng-spring-srv6-encoding-network-sliceid] Cheng, W., Lin, C.,
             Gong, L., Zadok, S., and X. Wang, "Encoding Network
             SliceIdentification for SRv6", Work in Progress, Internet-
             Draft, draft-cheng-spring-srv6-encoding-network-sliceid-
             05, April 2023.

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

Cheng, et al.          Expires September, 2023                 [Page 8]
Internet-Draft      Source IPv6 Address Programmability      March 2023

   [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", STD 86, RFC 8200, DOI
             10.17487/RFC8200, July 2017, <https://www.rfc-
             editor.org/info/rfc8200>.

   [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
             0.17487/RFC8986, February 2021, <https://www.rfc-
             editor.org/info/rfc8986>.

Contributors

Cheng, et al.          Expires September, 2023                 [Page 9]
Internet-Draft      Source IPv6 Address Programmability      March 2023

Authors' Addresses

   Weiqiang Cheng
   China Mobile
   Beijing
   China

   Email: chengweiqiang@chinamobile.com

   Liyan Gong
   China Mobile
   Beijing
   China
   Email: gongliyan@chinamobile.com

   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com

   Hao Li
   New H3C Technologies
   Beijing
   China

   Email: lihao@h3c.com

Cheng, et al.          Expires September, 2023                [Page 10]