]> 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 have a need for carrying an identifier in IPv6 packets. While those drafts might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, and so for very similar situations, 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 32-bit, 64-bit or 128-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 have a need for carrying an identifier in IPv6 packets. Two examples are and . While those drafts might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, and so for very similar situations, 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 32-bit, 64-bit or 128-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 two different solutions to carry an identifier in IPv6 packets, in order to avoid the aforementioned issue. Each solution defines a new option in the Destination Options and Hop-by-Hop Options sub-registry. Both are 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.

Solution 1: Generic Identifier For simple use cases such as a single identifier carried without additional fields and without specific context, a new Option Type named "Generic Identifier" is defined as follows: where:

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

Pros and Cons (+) Totally generic solution, similar to an Identifier container. (-) Too generic, as it could be used to carry all and nothing.
(-) No context for the carried identifier, which might disturb the receiver.
(-) No multiple identifiers, where some use cases might need to carry more than one.
(-) No additional fields, where some use cases might need that.

Solution 2: Identifier with Context For use cases where one or several identifiers are carried with additional fields, or when a context is required, a new Option Type named "Identifier with Context" is defined as follows: where:

• Option Type: 8-bit option type as defined in .
• Opt Data Len: 8-bit unsigned integer. Length of this option, in octets, not including the first 2 octets.
• Context-ID: 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 representing a data structure which depends on the Context-ID field.

Pros and Cons (+) Allows for a context.
(+) Allows for multiple identifiers.
(+) Allows for additional fields.
(+) IETF review process for new Context-ID code points. (-) Not hardware friendly.

IANA Considerations

Generic Identifier (Solution 1) If the solution is adopted, this document requests IANA to allocate the following IPv6 Option Type in the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters:

Identifier with Context (Solution 2) If the solution is adopted, this document requests IANA to allocate the following IPv6 Option Type in the Destination Options and Hop-by-Hop Options sub-registry of Internet Protocol Version 6 (IPv6) Parameters: This document also requests IANA to define a registry group named "Identifier with Context". The following subsections detail the registries therein contained.

Context-ID This registry defines 65536 code points for the Context-ID field, in order to know the context. The following code points are defined in this document: Unassigned code points are available for assignment via the "IETF Review" process, as per . For a new registration request to be accepted, its main purpose MUST be to carry an identifier. The aforementioned identifier MUST be the centerpiece of the new context. New registration requests MUST use the following template:

• Code point: requested code point for the new Context-ID.
• Description: name of the new Context-ID.
• Reference: reference to the document that defines the new Context-ID.

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 security considerations for the Context-Data field of the Identifier with Context Option, which varies based on the Context-ID. These custom data structures will have security considerations in their own documents that define the new formats.

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. 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. 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 of 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.

Acknowledgments