Protocol Extension Requirements of Generalized IPv6 Tunnel
draft-li-rtgwg-gip6-protocol-ext-requirements-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xinxin Yi , Zhenbin Li , Tianran Zhou , Shuping Peng , Qiangzhou Gao , Bing Liu | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-li-rtgwg-gip6-protocol-ext-requirements-02
Network Working Group X. Yi
Internet-Draft China Unicom
Intended status: Informational Z. Li
Expires: 24 April 2025 T. Zhou
S. Peng
Q. Gao
B. Liu
Huawei
21 October 2024
Protocol Extension Requirements of Generalized IPv6 Tunnel
draft-li-rtgwg-gip6-protocol-ext-requirements-02
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 24 April 2025.
Yi, et al. Expires 24 April 2025 [Page 1]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
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.
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Capability Advertisement . . . . . . . . . . . . . . . . 5
4.2. Inter-Domain Operation . . . . . . . . . . . . . . . . . 5
4.3. Capabilities about IPv6 Extension Header . . . . . . . . 5
4.4. Capability about Options of IPv6 Extension Header . . . . 6
4.5. Capability about Specific Features . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Yi, et al. Expires 24 April 2025 [Page 2]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
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
1) Protocol Scalability
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
Yi, et al. Expires 24 April 2025 [Page 3]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
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.
2) Gaps of new scenarios
a. Loss of End-to-End information:
Users such as enterprises or hospitals may have demand for data
sharing and circulation, but these data often involve sensitive
information. Therefore, it is necessary to use a network
identification technology to classify and identify the sensitivity
level of data, and this ID can be encapsulated into IPv6 header.
Therefore, the circulation scope of sensitive data can be controlled
and a credible network path can be ensured throughout the entire
process. Besides, when the data reaches the receiver, the receiver
can also determine whether the data is credible and whether it can be
received based on the ID.
In this scenario, there are two situations:
- Data transmission between cross city user. In this situation, the
tunnel encapsulation methods may be different in different
metropolitan area networks, and the methods for metropolitan area
networks and backbone networks may also differ. 2. User data
entering the cloud. Clouds are generally connected to backbone
networks, the methods for metropolitan area networks and backbone
networks may be different.
- User data entering the cloud. Clouds are generally connected to
backbone networks, the methods for metropolitan area networks and
backbone networks may be different.
Yi, et al. Expires 24 April 2025 [Page 4]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
The differentiated tunnel encapsulation methods may result in the
loss of the encapsulated ID on the packet. For example, when packets
enter MPLS tunnels from IPv6 domain, information encapsulated in IPv6
header is lost. As a result, the credibility and controllability of
data circulation service cannot be guaranteed.
b. Limited header space (TBD)
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. Capability Advertisement
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 Operation
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. Capabilities 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.
Yi, et al. Expires 24 April 2025 [Page 5]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
* 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.
Yi, et al. Expires 24 April 2025 [Page 6]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
* 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.
6. Security Considerations
TBD
7. Normative References
[I-D.ietf-6man-enhanced-vpn-vtn-id]
Dong, J., Li, Z., Xie, C., Ma, C., and G. S. Mishra,
"Carrying Network Resource Partition (NRP) Information in
IPv6 Extension Header", Work in Progress, Internet-Draft,
draft-ietf-6man-enhanced-vpn-vtn-id-07, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
enhanced-vpn-vtn-id-07>.
[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, 27 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
ipv6-alt-mark-17>.
[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-12, 7 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-ipv6-options-12>.
[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-07, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-li-apn-ipv6-
encap-07>.
Yi, et al. Expires 24 April 2025 [Page 7]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
[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,
6 November 2022, <https://datatracker.ietf.org/doc/html/
draft-li-rtgwg-generalized-ipv6-tunnel-03>.
[I-D.yzz-detnet-enhanced-data-plane]
Geng, X., Zhou, T., Zhang, L., and Z. Du, "DetNet Enhanced
Data Plane", Work in Progress, Internet-Draft, draft-yzz-
detnet-enhanced-data-plane-03, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-yzz-detnet-
enhanced-data-plane-03>.
[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>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
Authors' Addresses
Xinxin Yi
China Unicom
Beijing,100048
China
Email: yixx3@chinaunicom.cn
Zhenbin Li
Huawei
156 Beiqing Road
Beijing,100095
China
Email: lizhenbin@huawei.com
Tianran Zhou
Huawei
156 Beiqing Road
Beijing,100095
China
Email: zhoutianran@huawei.com
Yi, et al. Expires 24 April 2025 [Page 8]
Internet-Draft Protocol Extension Requirements of GIP6 October 2024
Shuping Peng
Huawei
156 Beiqing Road
Beijing,100095
China
Email: pengshuping@huawei.com
Qiangzhou Gao
Huawei
156 Beiqing Road
Beijing,100095
China
Email: gaoqiangzhou@huawei.com
Bing Liu
Huawei
156 Beiqing Road
Beijing,100095
China
Email: leo.liubing@huawei.com
Yi, et al. Expires 24 April 2025 [Page 9]