| Internet-Draft | Generalized IPv6 Tunnel | October 2024 |
| Li, et al. | Expires 24 April 2025 | [Page] |
This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels.¶
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 [RFC2119].¶
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.¶
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.¶
Currently there are many types of IP tunnels, such as VXLAN and GRE. On IPv6 networks, it is hard to define extensions for all these tunnels to support new features. On the other hand it is not recommended to extend new features based on the IPv4 data plane for these tunnels. This document analyzes the problems of IP tunnels and defines a generalized IPv6 tunnel to support the new features.¶
APN: Application-aware Networking¶
GRE: Generic Routing Encapsulation¶
IPv4: Internet Protocol version 4¶
IPv6: Internet Protocol version 6¶
IOAM: In-situ Operations, Administration, and Maintenance¶
ISATAP: Intra-Site Automatic Tunnel Addressing Protocol¶
L2TPv3: Layer Two Tunneling Protocol Version 3¶
MPLS: Multiprotocol Label Switching¶
NVO3: Network Virtualization Overlays¶
SRv6: Segment Routing IPv6¶
SID: SR Identification¶
VNI: VXLAN Network Identifier¶
VXLAN: Virtual eXtensible Local Area Network¶
There have been many types of IP tunnels, including:¶
- GRE Tunnels: it is defined in [RFC2784].¶
- IP in IP Tunnels: it is defined in [RFC1853].¶
- L2TPv3 Tunnels: it is defined in [RFC3931].¶
- ISATAP Tunnels: it is defined in [RFC4214].¶
- IPv4/IPv6 over IPv6 (4over6) Tunnels: it is defined in[RFC2473].¶
- VXLAN Tunnels: it is defined in [RFC7348].¶
- NVGRE Tunnels: it is defined in [RFC7637].¶
- MPLS over UDP: it is defined in [RFC7510].¶
- VXLAN-GPE (Generic Protocol Extension for VXLAN) Tunnels: it is defined in [I-D.ietf-nvo3-vxlan-gpe].¶
Currently many new features are emerging and the corresponding encapsulations over the IPv6 are defined:¶
- [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.dong-6man-enhanced-vpn-vtn-id] defines the IPv6 encapsulation used to determine resource isolation.¶
- [I-D.li-apn-ipv6-encap] defines the IPv6 encapsulation of an APN.¶
If the existing IP tunnels need to support new features such as Alternate Marking, IOAM, resource isolation, and APN, the following problems exist:¶
- All of the IP tunnels mentioned above need to be extended accordingly, resulting in a lot of standardization work.¶
- It is hard to keep the consistency between IPv4 and IPv6 for these IP tunnels (except IPv4 transition tunnels) since the possible extensions are recommended to be only done over the IPv6.¶
- IPv6 can directly support some functions of these IP tunnels which cannot be done over the IPv4. This means such functions becomes redundant over the IPv6. For example, VXLAN takes use of the UDP to support ECMP. However for the IPv6 VXLAN, the Flow Label in the IPv6 header can also be used to support ECMP.¶
- Some IP tunnels such as VXLAN and GRE have their own headers. If these tunnels need to support new features over the IPv6, there will face the challenge of the choice between reusing the exiting IPv6 encapsulations for these new features based on the IPv6 extension header and define new extensions based on their own tunnel headers.¶
-- If the tunnel header is extended, it will be redundant with the existing IPv6 encapsulation for the new features based on the IPv6 extension header.¶
-- For some existing IP tunnels (such as IP in IP) that do not have their own headers, they have to reuse the IPv6 encapsulations for these new features based the IPv6 header. extensions need to be redefined in the IPv6 extension header. As a result, their extensions may be different from that of the IP tunnels which have their own headers.¶
In order to solve the above problems, the following choice can be taken into account:¶
1. It is not recommended to support the new features over the IPv4 for these IP tunnels.¶
2. It is to reuse the existing IPv6 encapsulations based on the IPv6 extension header when support the new features for these IP tunnels over the IPv6.¶
If these IP tunnels takes use of the existing encapsulations based on the IPv6 extension header, for the IP tunnels which have their own headers, there are two possible options to cope with their own headers:¶
Option 1: Tunnels use the IPv6 extension headers to support new features and their own headers are retained.¶
This Option has the following problems:¶
1. Redundant Functions: For example, the UDP-based IP tunnel can directly use IPv6 flow label to implement ECMP.¶
2. Separated process of tunnel functions: Some functions use IPv6 extension headers and some functions use headers of tunnels. As a result, tunnel processing is separated and complex.¶
3. If the IPSec extension header is used, the tunnel's own header maybe encrypted and unable to be parsed when necessary process is needed.¶
The advantage of the option is that the existing tunnel headers are retained and it is easy to implement the smooth evolution. In addition, If the functions of the existing tunnel header is only processed at the destination node, it is easy to be retained because the IPSec extension header has little effect on the retained tunnel headers.¶
Option 2: Define a generalized IPv6 tunnel that contains the IPv6 extension header which not only reuses the existing IPv6 encapsulations to support new features, but also introduces the new extensions to support the necessary functions of their own headers.¶
With this option, all the instructions are encapsulated in the IPv6 extension headers which will facilitate the unifying process. This option is recommended in the document.¶
The Generalized IPv6 (GIP6) tunnel is defined to use the IPv6 header and IPv6 extension header to support both existing IP tunnels functions and new features.¶
A GIP6 encapsulated packet has the following format:¶
+ - - - - - - - - - - - - - - - - - - - - - - - - - -+ ----
| IPv6 Header | |
+ - - - - - - - - - - - - - - - - - - - - - - - - - -+ GIP6
| IPv6 Extension Header | Encapsulation
| (Encapsulations of new features + | |
| Encapsulations of functions of existing IP tunnels)| |
+ - - - - - - - - - - - - - - - - - - - - - - - - - -+ ----
| Payload packet |
+ - - - - - - - - - - - - - - - - - - - - - - - - - -+
Figure 1. GIP6 Encapsulation¶
Different types of tunneled payloads, such as IPv4, IPv6, MPLS, Ethernet, etc., can be indicated by the IPv6 Next Header.¶
Packets encapsulated with the GIP6 tunnel can directly support new functions based on existing encapsulation, including Alternate-Marking, IOAM, Resource-Isolation, and APN.¶
If the functions of the existing tunnel header is only processed at the destination node, the tunnel header can be retained and the format of the GIP6 encapsulated packet is shown in the following figure.¶
+ - - - - - - - - - - - - - - - - - - - - - - - - - -+ ---- | IPv6 Header | | + - - - - - - - - - - - - - - - - - - - - - - - - - -+ GIP6 | IPv6 Extension Header | Encapsulation | (Encapsulations of new features) | | + - - - - - - - - - - - - - - - - - - - - - - - - - -+ ---- | Existing IP Tunnel Headers | + - - - - - - - - - - - - - - - - - - - - - - - - - -+ | Payload packet | + - - - - - - - - - - - - - - - - - - - - - - - - - -+ Figure 2. GIP6 Encapsulation with Existing IP Tunnel Headers¶
To support existing VXLAN functions, the GIP6 tunnel is extended as follows:¶
1. The function of the UDP is replaced by the flow label of the IPv6 header in the GIP6 tunnel. To ensure compatibility, the value of the flow label calculated for the purpose of ECMP SHOULD be the same as that of the source port of the UDP.¶
2. Definition of the VN Option¶
A new option called VN Option is defined to carry the VXLAN header information. The VN Option MUST only be encapsulated in the Destination Options Header (DOH).¶
The following figure shows the data fields format of the VN option:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| VXLAN Header (8 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. VN Option¶
The VN Option contains the following fields:¶
* Option Type: 8-bit selector. VN option. Value TBD by IANA.¶
* Opt Data Len: 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 8.¶
* Option Data: 64-bits VXLAN Header Information.¶
The following figure shows the definition of VXLAN headers in [RFC7358]. For the detailed definition of the data fields, please refer to [RFC7358].¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier(VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. VXLAN headers¶
A new option called GRE Option is defined to carry the GRE header information. The GRE Option MUST only be encapsulated in the Destination Options header (DOH).¶
The definition of a new TLV for the Options Extension Headers, carrying the data fields dedicated to the GRE information, is reported below.¶
The following figure shows the data fields format of the GRE option.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| GRE Header (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. GRE Option¶
The GRE Option contains the following fields:¶
* Option Type: 8-bit selector. GRE option. Value TBD by IANA.¶
* Opt Data Len: 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16.¶
* Option Data: 128-bits GRE Header Information.¶
The following figure shows the definition of the GRE header in [RFC2890]. For the detailed definition of the data fields, please refer to [RFC2784] and [RFC2890].¶
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. GRE Header¶
Note: The function of the Protocol Type in the GRE header can be replaced by that of the NH in the IPv6 header or IPv6 extension header.¶
They will be defined in the future version.¶
TBD.¶
The following people also gave a substantial contribution to the content of this document and should be considered as Contributor:¶
Haibo Wang, Huawei Technologies, rainsword.wang@huawei.com¶
The Option Type should be assigned in IANA's "Destination Options" registry.¶
This draft requests the following IPv6 Option Type assignment from the Destination Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters (https://www.iana.org/assignments/ipv6-parameters/).¶
Hex Value Binary Value Description Reference
act chg rest
----------------------------------------------------------------
TBD 00 0 TBD VN [This draft]
TBD 00 0 TBD GRE [This draft]
Figure 7. IANA Considerations¶