Internet DRAFT - draft-templin-6man-omni-option
draft-templin-6man-omni-option
Network Working Group F. Templin, Ed.
Internet-Draft The Boeing Company
Intended status: Standards Track A. Whyman
Expires: August 16, 2021 MWA Ltd c/o Inmarsat Global Ltd
February 12, 2021
IPv6 Neighbor Discovery Overlay Multilink Network Interface (OMNI)
Option
draft-templin-6man-omni-option-09
Abstract
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.
Status of This Memo
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 August 16, 2021.
Copyright Notice
Copyright (c) 2021 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
Templin & Whyman Expires August 16, 2021 [Page 1]
Internet-Draft IPv6 ND OMNI Option February 2021
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Overlay Multilink Network Interface (OMNI) IPv6 ND Option 3
3.1. Sub-Options . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Interface Attributes (Type 1) . . . . . . . . . . . . 6
3.1.4. Sub-Type Extension . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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 [I-D.templin-6man-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
[I-D.templin-6man-omni-interface], where the International Civil
Aviation Organization (ICAO) has expressed interest in the option in
support of their Document 9896 [ATN][ATN-IPS]. An IPv6 ND option
Type number assignment is requested in the IANA Considerations
section.
2. Terminology
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.
Templin & Whyman Expires August 16, 2021 [Page 2]
Internet-Draft IPv6 ND OMNI Option February 2021
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 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The Overlay Multilink Network Interface (OMNI) IPv6 ND Option
An Overlay Multilink Network Interface (OMNI) IPv6 ND option is
defined. The option (known as the "OMNI option") is formatted as
shown in Figure 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Preflen | S/T-omIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sub-Options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: OMNI Option Format
In this format:
o Type is set to TBD1.
o Length is set to the number of 8 octet blocks in the option.
o Preflen is an 8 bit field that determines the length of prefix
associated with an IPv6 address of the IPv6 ND message. Values 0
through 128 specify a valid prefix length (all other values are
invalid). For IPv6 ND messages sent from the source to a target
node, Preflen applies to the IPv6 source address and provides the
length that the source is requesting or asserting. For IPv6 ND
messages replies from the target to the original source, Preflen
applies to the IPv6 destination address and indicates the length
that the target is granting.
o 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.
Templin & Whyman Expires August 16, 2021 [Page 3]
Internet-Draft IPv6 ND OMNI Option February 2021
o 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 Section 3.1.
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 multiple OMNI option instances appear in the
same IPv6 ND message, the interface processes the Preflen and S/
T-omIndex fields in the first instance and ignores those fields in
all other instances. The interface processes the Sub-Options of all
OMNI option instances in the same IPv6 ND message in the consecutive
order in which they occur.
The OMNI option(s) in each IPv6 ND message may include full or
partial information for the neighbor. 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.
3.1. Sub-Options
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:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Sub-Type| Sub-length | Sub-Option Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: Sub-Option Format
o Sub-Type is a 5-bit field that encodes the Sub-Option type. Sub-
Options defined in this document are:
Option Name Sub-Type
Pad1 0
PadN 1
Interface Attributes (Type 1) 2
Sub-Type Extension 30
Figure 3
Sub-Types 3-29 are available for future assignment for major
protocol functions. Sub-Type 31 is reserved by IANA.
Templin & Whyman Expires August 16, 2021 [Page 4]
Internet-Draft IPv6 ND OMNI Option February 2021
o Sub-Length is an 11-bit field that encodes the length of the Sub-
Option Data (i.e., ranging from 0 to 2034 octets).
o Sub-Option Data is a block of data with format determined by Sub-
Type and length determined by Sub-Length.
During transmission, the OMNI interface codes Sub-Type and Sub-Length
together in network byte order in 2 consecutive octets, where Sub-
Option Data may be up to 2034 octets in length. This allows ample
space for coding large objects (e.g., ascii character strings,
protocol messages, security codes, etc.), while a single OMNI option
is limited to 2040 octets the same as for any IPv6 ND option. If the
Sub-Options to be coded would cause an OMNI option to exceed 2040
octets, the OMNI interface codes any remaining Sub-Options in
additional OMNI option instances in the intended order of processing
in the same IPv6 ND message. Implementations must therefore observe
size limitations, and must refrain from sending IPv6 ND messages
larger than the OMNI interface MTU.
During reception, the OMNI interface processes each OMNI option Sub-
Option while skipping over and ignoring any unrecognized Sub-Options.
The OMNI interface processes the Sub-Options of all OMNI option
instances in the consecutive order in which they appear in the IPv6
ND message, beginning with the first instance and continuing through
any additional instances to the end of the message. If a Sub-Option
length would cause the running total for that OMNI option to exceed
the length coded in the option header, the interface accepts any Sub-
Options already processed and ignores the remainder of that OMNI
option. The interface then processes any remaining OMNI options in
the same fashion to the end of the IPv6 ND message.
Note: large objects that exceed the Sub-Option Data limit of 2034
octets are not supported under the current specification; if this
proves to be limiting in practice, future specifications may define
support for fragmenting large objects across multiple OMNI options
within the same IPv6 ND message.
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):
3.1.1. Pad1
Templin & Whyman Expires August 16, 2021 [Page 5]
Internet-Draft IPv6 ND OMNI Option February 2021
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| S-Type=0|x|x|x|
+-+-+-+-+-+-+-+-+
Figure 4: Pad1
o Sub-Type is set to 0. If multiple instances appear in OMNI
options of the same message all are processed.
o Sub-Type is followed by three 'x' bits, set randomly on
transmission and ignored on receipt. Pad1 therefore consists of a
whole single octet with the most significant 5 bits set to 0, and
with no Sub-Length or Sub-Option Data fields following.
3.1.2. PadN
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| S-Type=1| Sub-length=N | N padding octets ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: PadN
o Sub-Type is set to 1. If multiple instances appear in OMNI
options of the same message all are processed.
o Sub-Length is set to N (from 0 to 2047) being the number of
padding octets that follow.
o 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).
3.1.3. Interface Attributes (Type 1)
Templin & Whyman Expires August 16, 2021 [Page 6]
Internet-Draft IPv6 ND OMNI Option February 2021
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-Type=2| Sub-length=N | omIndex | omType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Provider ID | Link | Resvd |P00|P01|P02|P03|P04|P05|P06|P07|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19|P20|P21|P22|P23|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P24|P25|P26|P27|P28|P29|P30|P31|P32|P33|P34|P35|P36|P37|P38|P39|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P40|P41|P42|P43|P44|P45|P46|P47|P48|P49|P50|P51|P52|P53|P54|P55|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P56|P57|P58|P59|P60|P61|P62|P63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Interface Attributes (Type 1)
o Sub-Type is set to 2. If multiple instances with different
omIndex values appear in OMNI options of the same message all are
processed; if multiple instances with the same omIndex value
appear, the first is processed and all others are ignored.
o Sub-Length is set to N (from 1 to 2047) that encodes the number of
Sub-Option Data octets that follow.
o omIndex is a 1-octet field containing a value from 0 to 255
identifying the underlying interface for which the interface
attributes apply.
o omType is a 1-octet field containing a value from 0 to 255
corresponding to the underlying interface identified by omIndex.
o Provider ID is a 1-octet field containing a value from 0 to 255
corresponding to the underlying interface identified by omIndex.
o 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").
o Resvd is reserved for future use.
o 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 [RFC2474]. 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.
Templin & Whyman Expires August 16, 2021 [Page 7]
Internet-Draft IPv6 ND OMNI Option February 2021
3.1.4. Sub-Type Extension
Since the Sub-Type field is only 5 bits in length, future
specifications of major protocol functions may exhaust the remaining
Sub-Type values available for assignment. This document therefore
defines Sub-Type 30 as an "extension", meaning that the actual sub-
option type is determined by examining a 1 octet "Extension-Type"
field immediately following the Sub-Length field. The Sub-Type
Extension is formatted as shown in Figure 7:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S-Type=30| Sub-length=N | Extension-Type| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ ~
~ Extension-Type Body ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Sub-Type Extension
o Sub-Type is set to 30. If multiple instances appear in OMNI
options of the same message all are processed, where each
individual extension defines its own policy for processing
multiple of that type.
o Sub-Length is set to N (from 1 to 2034) that encodes the number of
Sub-Option Data octets that follow. The Extension-Type field is
always present; hence, the maximum Extension-Type Body length is
2033 octets.
o Extension-Type contains a 1 octet Sub-Type Extension value between
0 and 255.
o Extension-Type Body contains an N-1 octet block with format
defined by the given extension specification.
Extension-Type values 0 through 252 are available for assignment by
future specifications, which must also define the format of the
Extension-Type Body and its processing rules. Extension-Type values
253 and 254 are reserved for experimentation, as recommended in
[RFC3692], and value 255 is reserved by IANA.
Templin & Whyman Expires August 16, 2021 [Page 8]
Internet-Draft IPv6 ND OMNI Option February 2021
4. IANA Considerations
The IANA is instructed to allocate a Type number TBD1 from the
registry "IPv6 Neighbor Discovery Option Formats" for the OMNI option
(see: Section 13 of [RFC4861]) as a provisional registration in
accordance with Section 4.13 of [RFC8126].
The OMNI option defines a 5-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 [RFC8126].
Value Sub-Type name Reference
----- ------------- ----------
0 Pad1 [RFCXXXX]
1 PadN [RFCXXXX]
2 Interface Attributes (Type 1) [RFCXXXX]
3-29 Unassigned
30 Sub-Type Extension [RFCXXXX]
31 Reserved [RFCXXXX]
Figure 8: OMNI Option Sub-Type Values
5. Security Considerations
Security considerations for IPv6 [RFC8200] and IPv6 Neighbor
Discovery [RFC4861] apply.
6. Acknowledgements
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.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Templin & Whyman Expires August 16, 2021 [Page 9]
Internet-Draft IPv6 ND OMNI Option February 2021
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
7.2. Informative References
[ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground
Interface for Civil Aviation, IETF Liaison Statement
#1676, https://datatracker.ietf.org/liaison/1676/", March
2020.
[ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the
Aeronautical Telecommunication Network (ATN) using
Internet Protocol Suite (IPS) Standards and Protocol),
Draft Edition 3 (work-in-progress)", December 2020.
[I-D.templin-6man-omni-interface]
Templin, F. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", draft-
templin-6man-omni-interface-69 (work in progress), January
2021.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
Templin & Whyman Expires August 16, 2021 [Page 10]
Internet-Draft IPv6 ND OMNI Option February 2021
Authors' Addresses
Fred L. Templin (editor)
The Boeing Company
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Tony Whyman
MWA Ltd c/o Inmarsat Global Ltd
99 City Road
London EC1Y 1AX
England
Email: tony.whyman@mccallumwhyman.com
Templin & Whyman Expires August 16, 2021 [Page 11]
