Internet-Draft Protocol Extension Requirements of GIP6 November 2022
Li, et al. Expires 10 May 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-rtgwg-gip6-protocol-ext-requirements-01
Published:
Intended Status:
Informational
Expires:
Authors:
Z. Li
Huawei
T. Zhou
Huawei
S. Peng
Huawei
X. Yi
China Unicom

Protocol Extension Requirements of Generalized IPv6 Tunnel

Abstract

IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Slicing, Alternate Marking, IOAM, DetNet, APN. However network devices have different capabilities of IPv6 extension header processing which has much effect on the deployment of these features. This document analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined.

Requirements Language

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 RFC 2119 [RFC2119].

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 10 May 2023.

1. Introduction

IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Slicing, Alternate Marking, IOAM, DetNet and APN. GIP6 [I-D.li-rtgwg-generalized-ipv6-tunnel] defines the generalized IPv6 tunnel to unify the IP tunnels to support the new features. However, when deploying GIP6 in existing networks, network devices have different capabilities of IPv6 extension header processing, which has much effect on the deployment of these features, even causes the packet loss. In order to solve the issues, the capabilities of IPv6 extension header process can be advertised among network devices and reported from network devices to the controller. Based on these IPv6 capability information, the new features can be deployed properly.

This document analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined.

2. Terminology

APN: Application-aware Networking

IPv4: Internet Protocol version 4

IPv6: Internet Protocol version 6

IOAM: In-situ Operations, Administration, and Maintenance

SRv6: Segment Routing over IPv6

3. Problem Statement

Currently many new features are emerging and the corresponding encapsulations over the IPv6 are defined:

- [RFC8704] defines IPv6 encapsulation for SRv6 network programming.

- [I-D.ietf-6man-ipv6-alt-mark] defines IPv6 encapsulation for Alternate Marking.

- [I-D.ietf-ippm-ioam-ipv6-options] defines IPv6 encapsulation for IOAM.

- [I-D.ietf-6man-enhanced-vpn-vtn-id] defines the IPv6 encapsulation used to determine resource isolation.

- [I-D.yzz-detnet-enhanced-data-plane]defines the IPv6 encapsulation for implementing bounded latency.

- [I-D.li-apn-ipv6-encap] defines the IPv6 encapsulation of an APN.

There features uses the IPv6 extension headers including HbH (Hop-by-Hop Options Header), DoH (Destination Options Header) and SRH (Segment Routing Header).

In the process of deployment of these new features, because network devices have different capabilities of IPv6 extension header processing, the following issues are identified:

- Some legacy network devices can only process IPv6 extension header (Hop-by-Hop Options Header) on slow path, which has negative impact on the routing jobs on the control plane. So in existing networks, packet with IPv6 extension headers are usually blocked by ACL. This will cause the packet loss on these network devices if the packet encapsulated with GIP6 tunnel and the HbH is used for the new features.

- Network devices can only support some of the extension headers used for the new features. If the packet encapsulated with GIP6 tunnel and specific types of IPv6 extension headers used cannot be supported by these network devices, new features cannot be guaranteed along the path.

- Network devices can only process limited number of options in an IPv6 extension header (including HbH and DoH). So when multiple options coexists to support different new features in the IPv6 extension header of the GIP6 tunnel, those devices may drop the packet.

4. Requirements

To solve the above issues, there are requirements for protocol extensions to advertise the capability of IPv6 extension header processing so as to identify the unavailable nodes and facilitate the deployment of new features successfully.

4.1. Way to advertise the capability

There are two different ways. One is to advertise the capability among network devices. So that a network device can find the right next hop with IPv6 extension header processing capabilities. In this case, IGP or BGP-SPF extensions are required for the information distribution. The other way is to report the IPv6 capabilities from network nodes to a controller. So that the network controller can calculate the right path comprised with available nodes. In this case, BGP-LS or NETCONF/YANG are considered for the extensions.

4.2. Inter-Domain

A path may be across multiple network domains. The ingress node of the GIP6 tunnel need to know if all the nodes along the path can process the IPv6 extension headers properly. In this case, the capability of IPv6 extension header processing need to be distributed among multiple domains. BGP can be extended to advertise the IPv6 capability information from the egress node to the ingress node. If there is a controller collecting IPv6 capability information from multiple domains, PCEP or BGP can be extended and used by the controller to deliver information to the ingress node about the right path along which network nodes can process the IPv6 extension header properly.

4.3. Capability about IPv6 Extension Header

Network devices need to advertise its capability information about what IPv6 extension header can be supported. These capabilities may include:

  • Supporting Hop by Hop options header (HbH) or not.
  • Fast path or slow path processing of HbH.
  • Supporting Segment Routing Header (SRH) or not.
  • Supporting Destination Options header (DoH) or not.
  • Capabilities about coexistence of multiple extension headers, for example, the combination of HbH and Authentication Header (AH).
  • The maximum length of each IPv6 extension header
  • The maximum total length of IPv6 extension headers

4.4. Capability about Options of IPv6 Extension Header

Network devices need to advertise its capability information about process options in the IPv6 extension headers. These capabilities may include:

  • The maximum number of options supported in the HbH
  • The maximum number of options supported in the DoH
  • Supporting SRH TLV or not and the maximum number of TLVs supported in the SRH
  • The maximum number of segments in the SRH

4.5. Capability about Specific Features

In addition to the common capabilities described above, network devices may support some specific features only. These capabilities may include:

  • Slicing: the NRP option can be supported or not. If support, the NRP option can be placed in HbH and/or DoH.
  • Alternate Marking: the Alternate Marking option can be supported or not. If support, the Alternate Marking option can be placed in HbH and/or DoH.
  • IOAM: the IOAM option can be supported or not. If support, the IOAM option can be placed in HbH and/or DoH.
  • APN: the APN option can be supported or not. If support, the APN option can be placed in HbH, DoH and/or SRH TLV.
  • DetNet: the BLI option [I-D.yzz-detnet-enhanced-data-plane] can be supported or not. If support, the BLI option can be placed in HbH and/or DoH.

5. IANA Considerations

This document makes no request of IANA.

7. Normative References

[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra, "Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header", Work in Progress, Internet-Draft, draft-ietf-6man-enhanced-vpn-vtn-id-02, , <https://www.ietf.org/archive/id/draft-ietf-6man-enhanced-vpn-vtn-id-02.txt>.
[I-D.ietf-6man-ipv6-alt-mark]
Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate Marking Method", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-alt-mark-17, , <https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-alt-mark-17.txt>.
[I-D.ietf-ippm-ioam-ipv6-options]
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-09, , <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-ipv6-options-09.txt>.
[I-D.li-apn-ipv6-encap]
Li, Z., Peng, S., and C. Xie, "Application-aware IPv6 Networking (APN6) Encapsulation", Work in Progress, Internet-Draft, draft-li-apn-ipv6-encap-05, , <https://www.ietf.org/archive/id/draft-li-apn-ipv6-encap-05.txt>.
[I-D.li-rtgwg-generalized-ipv6-tunnel]
Li, Z., Chen, S., Gao, Q., Zhang, S., and Q. Xu, "Generalized IPv6 Tunnel (GIP6)", Work in Progress, Internet-Draft, draft-li-rtgwg-generalized-ipv6-tunnel-03, , <https://datatracker.ietf.org/api/v1/doc/document/draft-li-rtgwg-generalized-ipv6-tunnel/>.
[I-D.yzz-detnet-enhanced-data-plane]
Yang, F., Zhou, T., Zhang, L., and Z. Du, "DetNet Enhanced Data Plane", Work in Progress, Internet-Draft, draft-yzz-detnet-enhanced-data-plane-01, , <https://www.ietf.org/archive/id/draft-yzz-detnet-enhanced-data-plane-01.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/info/rfc8704>.

Authors' Addresses

Zhenbin Li
Huawei
156 Beiqing Road
Beijing,100095
China
Tianran Zhou
Huawei
156 Beiqing Road
Beijing,100095
China
Shuping Peng
Huawei
156 Beiqing Road
Beijing,100095
China
Xinxin Yi
China Unicom
Beijing,100048
China