The Boeing Company

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

MWA Ltd c/o Inmarsat Global Ltd

99 City Road London EC1Y 1AX England tony.whyman@mccallumwhyman.com

I-D Internet-Draft This document defines a new IPv6 Neighbor Discovery (ND) option termed the "Overlay Multilink Network Interface (OMNI) Option". The OMNI option may appear in any IPv6 ND message type; it is processed by interface types that recognize the option and ignored by all other interface types. The option supports functions such as prefix registration and multilink coordination, and is extensible to support additional functions in the future.

This document defines a new IPv6 Neighbor Discovery (ND) option termed the "Overlay Multilink Network Interface (OMNI) Option". The OMNI option may appear in any IPv6 ND message type; it is processed by interface types that recognize the option and ignored by all other interface types. The option supports functions such as prefix registration and multilink coordination for interface types such as the OMNI interface , and is extensible to support additional functions in the future. The following sections discuss the OMNI option format and contents. Use cases appear in IPv6 over specific link layer documents such as , where the International Civil Aviation Organization (ICAO) has expressed interest in the option in support of their Document 9896 . An IPv6 ND option Type number assignment is requested in the IANA Considerations section.

The terminology in the normative references applies. The term "underlying interface" refers to one of potentially multiple Layer-2 interfaces over which a Layer-3 (virtual) interface is configured. 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.

An Overlay Multilink Network Interface (OMNI) IPv6 ND option is defined. The option (known as the "OMNI option") is formatted as shown in :

In this format: Type is set to TBD. Length is set to the number of 8 octet blocks in the option. T is a 1-bit flag set to 1 if an address is temporary (otherwise, set to 0) and Preflen is a 7 bit field that determines the length of prefix to be applied to an address. Values 1 through 127 specify a prefix length, while the value 0 indicates a singleton address (i.e., a /128). For IPv6 ND messages sent from a node to a router, T and Preflen apply to the IPv6 source address. For IPv6 ND messages sent from the router to the node, T and Preflen apply to the IPv6 destination address. S/T-omIndex is a 1-octet field that encodes a value between 0 and 255 identifying the source or target underlying interface for the IPv6 ND message. For RS and NS messages S/T-omIndex refers to the "Source" underlying interface over which the message is sent, while for RA and NA messages S/T-omIndex refers to the "Target" underlying interface that will receive the message. Sub-Options is a Variable-length field, of length such that the complete OMNI Option is an integer multiple of 8 octets long. Contains one or more Sub-Options, as described in . The OMNI option may appear in any IPv6 ND message type; it is processed by interfaces that recognize the option and ignored by all other interfaces. If a single IPv6 ND message contains multiple OMNI options, the first option is processed and any additional options are ignored. An OMNI option may include full or partial information for the neighbor. If an OMNI option with full information is received, its contents provide new information and/or update any previously cached information. If an OMNI option with partial information is received, it contents provide new information and/or update only the corresponding previously cached information. The union of the information in the most recently received OMNI options is therefore retained, and the information is aged/removed in conjunction with the corresponding neighbor cache entry.

The OMNI option includes zero or more Sub-Options. Each consecutive Sub-Option is concatenated immediately after its predecessor. All Sub-Options except Pad1 (see below) are in type-length-value (TLV) encoded in the following format:

Sub-Type is a 6-bit field that encodes the Sub-Option type. Sub-Options defined in this document are:

Sub-Types 3-61 are available for future assignment. Sub-Type 62 is reserved for experimentation, as recommended in . Sub-Type 63 is reserved by IANA. Sub-Length is a 10-bit field that encodes the length of the Sub-Option Data (i.e., ranging from 0 to 1023 octets). Sub-Option Data is a block of data with format determined by Sub-Type and length determined by Sub-Length. Note that Sub-Type and Sub-Length are coded together in network byte order in two consecutive octets. Note also that Sub-Option Data may be up to 1023 bytes in length. This allows ample space for encoding large objects (e.g., ascii character strings, security codes, etc.), while the entire OMNI option itself is limited to 2048 bytes the same as for any IPv6 ND option. Implementations must therefore be mindful of size limitations. During processing, unrecognized Sub-Options are ignored and the next Sub-Option processed until the end of the OMNI option is reached. The following Sub-Option types and formats are defined in this document (note that other documents that are active at the time of this writing will define additional Sub-Option types in the near future):

Sub-Type is set to 0. If multiple instances appear in the same OMNI option all are processed. Sub-Type is followed by two 'x' bits, set randomly on transmission and ignored on receipt. Pad1 therefore consists of a whole single octet with the most significant 6 bits set to 0, and with no Sub-Length or Sub-Option Data fields following.

Sub-Type is set to 1. If multiple instances appear in the same OMNI option all are processed. Sub-Length is set to N (from 0 to 1023) being the number of padding octets that follow. Sub-Option Data consists of N padding octets that are typically zero-valued (any non-zero values that may appear in the padding octets are not to be interpreted in any way other than as simple padding).

Sub-Type is set to 2. If multiple instances with different omIndex values appear in the same OMNI option all are processed; if multiple instances with the same omIndex value appear, the first is processed and all others are ignored Sub-Length is set to N (from 1 to 1023 that encodes the number of Sub-Option Data octets that follow. omIndex is a 1-octet field containing a value from 0 to 255 identifying the underlying interface for which the interface attributes apply. omType is a 1-octet field containing a value from 0 to 255 corresponding to the underlying interface identified by omIndex. Provider ID is a 1-octet field containing a value from 0 to 255 corresponding to the underlying interface identified by omIndex. Link encodes a 4-bit link metric. The value '0' means the link is DOWN, and the remaining values mean the link is UP with metric ranging from '1' ("lowest") to '15' ("highest"). Resvd is reserved for future use. A 16-octet ""Preferences" field immediately follows 'Resvd', with values P[00] through P[63] corresponding to the 64 Differentiated Service Code Point (DSCP) values . Each 2-bit P[*] field is set to the value '0' ("disabled"), '1' ("low"), '2' ("medium") or '3' ("high") to indicate a QoS preference for underlying interface selection purposes.

The IANA is instructed to allocate a Type number TBD from the registry "IPv6 Neighbor Discovery Option Formats" for the OMNI option (see: Section 13 of ) as a provisional registration in accordance with Section 4.13 of . The OMNI option also defines an 8-bit Sub-Type field, for which IANA is instructed to create and maintain a new registry entitled "OMNI option Sub-Type values". Initial values for the OMNI option Sub-Type values registry are given below; future assignments are to be made through Expert Review .

Security considerations for IPv6 and IPv6 Neighbor Discovery apply.

This document is aligned with the International Civil Aviation Organization (ICAO) Aeronautical Telecommunications Network (ATN) with Internet Protocol Services (ATN/IPS) development program. This document is aligned with the IETF 6man (IPv6) working group.