]> ULiege

Institut Montefiore B28 Allée de la Découverte 10 Liège 4000 Belgium justin.iurman@uliege.be

Internet IPv6 Maintenance Some recent use cases seem to have a need for carrying IDs within packets. Two examples are I-D.draft-ietf-6man-enhanced-vpn-vtn-id and I-D.draft-li-6man-topology-id. While they might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, which could quickly exhaust the allocation space if similar designs are proposed in the future. As an example, one might need an 8-bit ID, while another one might need a 24-bit, 32-bit, or 64-bit ID. Or, even worse, one might need a 32-bit ID in a specific context, while someone else might also need a 32-bit ID in another context. Therefore, allocating a new code point for each similar option is probably not the way to go. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IPv6 Maintenance Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Some recent use cases seem to have a need for carrying IDs within packets. Two examples are and . While they might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, which could quickly exhaust the allocation space if similar designs are proposed in the future. As an example, one might need an 8-bit ID, while another one might need a 24-bit, 32-bit, or 64-bit ID. Or, even worse, one might need a 32-bit ID in a specific context, while someone else might also need a 32-bit ID in another context. Therefore, allocating a new code point for each similar option is probably not the way to go. This document proposes a solution to carry IDs generically to avoid the problem mentioned previously. Two new Hop-by-Hop and Destination options are defined, called "Generic ID Option" and "Generic Context-ID Option". Both are defined and explained in this document.

Conventions and Definitions 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.

New IPv6 Destination and Hop-by-Hop Options

Generic ID Option For simple use cases where an ID is carried without extra fields and without any specific context, a new option type "Generic ID" is defined to carry such ID generically in IPv6 packets, as defined below: where:

• Option Type: 8-bit option type identifier as defined in .
• Opt Data Len: 8-bit unsigned integer. Length of the Generic ID field, in octets.
• Generic ID: variable length field.

Note: as an example, both and should use this option to carry IDs they define respectively.

Generic Context-ID Option For other use cases where an ID is carried with extra fields or when a context is required, a new option type "Generic Context-ID" is defined to carry such ID generically in IPv6 packets, as defined below: where:

• Option Type: 8-bit option type identifier as defined in .
• Opt Data Len: 8-bit unsigned integer. Length of this option, in octets, not including the first 2 octets.
• Context-Type: 16-bit field as defined in .
• Reserved: 16-bit field MUST be set to zero upon transmission and ignored upon reception.
• Context Data: variable length field. Context-Type-specific data.

Note: as an example, should use this option to carry the 16-bit ID and flags it defines.

IANA Considerations This document requests the following IPv6 Option Type assignments from the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters. http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 This document also requests IANA to define a registry group named "Generic Context-ID". This group includes the following registries:

• Context-Type

The subsequent subsections detail the registries therein contained.

Context-Type This registry defines 65535 code points for the Context-Type field to identify the type of context. The following code points are defined in this document:

• 0: Reserved
• 1: VTN

Other code points are available for assignment via the "IETF Review" process, as per . New registration requests MUST use the following template:

• Name: name of the newly registered Context-Type.
• Code point: desired value of the requested code point.
• Reference: reference to the document that defines the new Context-Type.

Security Considerations As this document describes new options for IPv6, these are similar to the security considerations of and the weakness documented in . This document does not define the data contents of custom Generic Context-ID options. These custom options will have security considerations corresponding to their defined data contents that need to be described where those formats are defined.

References Normative References 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. 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. Informative References 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 other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional VPNs. Such kind of network service is called enhanced VPNs (VPN+). VPN+ can be used to deliver IETF network slices, and could also be used for other application scenarios. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. In packet forwarding, some fields in the data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be performed on each node the packet traverses. This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the VTN related information, which could used to identify the set of network resources allocated to a VTN and the rules for packet processing. The procedure for processing the VTN option is also specified. Huawei Technologies Huawei Technologies Huawei Technologies This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the topology identifier, which is used to identify the forwarding table instance created by the Multi Topology Routing or Flexible Algorithm. 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 other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional VPNs. Such kind of network service is called enhanced VPNs (VPN+). A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. In packet forwarding, some fields in the data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be performed on each node the packet traverses. This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the VTN Resource ID, which is used to identify the set of network resources allocated to a VTN for packet processing. The procedure for processing the VTN option is also specified. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.

Acknowledgments