]> Generalized IPv6 Tunnel for QUIC Huawei
Beiqing Road Beijing China lizhenbin@huawei.com
Huawei
Beiqing Road Beijing chenshuanglong@huawei.com
Huawei
Beiqing Road Beijing China shihang9@huawei.com
Routing rtgwg IPSec This document defines a new encapsulation method for QUIC packet transmission based on IPv6 extension headers. This method enables QUIC packet transmission to easily inherit the extended functions of IPv6.
Introduction proposes the Generalize IPv6 Tunnel to unify the IP tunnels and remove duplicate functions and support new features. QUIC, as a general-purpose transport layer network protocol, is gradually being applied on the network side, such as DNS over QUIC and QUIC tunnel . QUIC tunnel-based packet transmission also faces the issue of being extended to support new features. This document defines encapsulation of QUIC headers into the GIP6 tunnel encapsulation and attempts to solve these issues.
Terminology
  • APN: Application-aware Networking
  • IOAM: In-situ Operations, Administration, and Maintenance
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 when, and only when, they appear in all capitals, as shown here.
Problem Statement As mentioned in the draft , many new features, such as Alternate Marking , IOAM , resource isolation , and APN , are emerging and the corresponding encapsulations over the IPv6 are defined. Since there are all kinds of existing IP tunnels (including UDP-based tunnels), if these new features need to be supported over these tunnels, it is very difficult to extend for these tunnels. If QUIC is used as a tunnel for transmission of data packets in the network, it will also face the challenge to support these new features.
Encapsulation of GIP6 for QUIC defined the GIP6 tunnel which uses the IPv6 header and IPv6 extension header to support both functions of existing IP tunnels and new features. The GIP6 tunnel unifies the IP tunnels which removes the duplicate functions and supports new features. This can greatly reduce the repeated effort to extend the exiting IP tunnels to support the new features. To support existing QUIC functions, the GIP6 tunnel is extended as follows:
  1. Definition of the QUIC Option: A new option called QUIC Option is defined to carry the QUIC header information. The QUIC Option MUST only be encapsulated in the Destination Options Header (DOH). The format of the QUIC option is shown in :
  2. The function of the UDP header for ECMP can 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.
QUIC option header
where:
  • Option Type: 8-bit selector. QUIC 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.
  • Option Data: variable. QUIC Header Information. For the detailed definition of the QUIC headers, please refer to .
Security Considerations This document does not introduce any new security considerations.
IANA Considerations 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.
References Normative References DNS over Dedicated QUIC Connections This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Version-Independent Properties of QUIC This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. Informative References Generalized IPv6 Tunnel (GIP6) Huawei Huawei Huawei China Unicom Agricultural Bank of China This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels. Tunneling Internet protocols inside QUIC UCLouvain UCLouvain Apple Inc. This document specifies methods for tunneling Ethernet frames and Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC connection. IPv6 Application of the Alternate-Marking Method Huawei Huawei Telecom Italia China Mobile China Unicom This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header. IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) Thoughtspot Cisco Systems, Inc. In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6. Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header Huawei Technologies Huawei Technologies China Telecom China Telecom Verizon Inc. Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction and evolvement of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs (VPN+). VPN+ can be used, for example, to deliver IETF network slice services. A VTN is a virtual underlay network that is associated with a network topology, and is allocated with a set of dedicated or shared resources from the underlay physical network. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. For packet forwarding in a specific VTN, some fields in the data packet are used to identify the VTN the packet belongs to, so that VTN-specific processing can be performed on each node along a VTN-specific path. This document specifies a new IPv6 Hop-by-Hop option to carry the VTN related information in data packets, which could be used to identify the VTN-specific processing to be performed on the packets by each network node along a VTN-specific path. Application-aware IPv6 Networking (APN6) Encapsulation Huawei Technologies Huawei Technologies China Telecom Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the encapsulation of the APN header in the IPv6 data plane.