idnits 2.17.1 draft-templin-6man-omni-option-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 12, 2021) is 1168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '00' on line 316 -- Looks like a reference, but probably isn't: '63' on line 316 == Missing Reference: 'RFCXXXX' is mentioned on line 386, but not defined == Outdated reference: A later version (-99) exists of draft-templin-6man-omni-interface-69 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft The Boeing Company 4 Intended status: Standards Track A. Whyman 5 Expires: August 16, 2021 MWA Ltd c/o Inmarsat Global Ltd 6 February 12, 2021 8 IPv6 Neighbor Discovery Overlay Multilink Network Interface (OMNI) 9 Option 10 draft-templin-6man-omni-option-09 12 Abstract 14 This document defines a new IPv6 Neighbor Discovery (ND) option 15 termed the "Overlay Multilink Network Interface (OMNI) Option". The 16 OMNI option may appear in any IPv6 ND message type; it is processed 17 by interface types that recognize the option and ignored by all other 18 interface types. The option supports functions such as prefix 19 registration and multilink coordination, and is extensible to support 20 additional functions in the future. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 16, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. The Overlay Multilink Network Interface (OMNI) IPv6 ND Option 3 59 3.1. Sub-Options . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.3. Interface Attributes (Type 1) . . . . . . . . . . . . 6 63 3.1.4. Sub-Type Extension . . . . . . . . . . . . . . . . . 8 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 This document defines a new IPv6 Neighbor Discovery (ND) option 75 termed the "Overlay Multilink Network Interface (OMNI) Option". The 76 OMNI option may appear in any IPv6 ND message type; it is processed 77 by interface types that recognize the option and ignored by all other 78 interface types. The option supports functions such as prefix 79 registration and multilink coordination for interface types such as 80 the OMNI interface [I-D.templin-6man-omni-interface], and is 81 extensible to support additional functions in the future. 83 The following sections discuss the OMNI option format and contents. 84 Use cases appear in IPv6 over specific link layer documents such as 85 [I-D.templin-6man-omni-interface], where the International Civil 86 Aviation Organization (ICAO) has expressed interest in the option in 87 support of their Document 9896 [ATN][ATN-IPS]. An IPv6 ND option 88 Type number assignment is requested in the IANA Considerations 89 section. 91 2. Terminology 93 The terminology in the normative references applies. The term 94 "underlying interface" refers to one of potentially multiple Layer-2 95 interfaces over which a Layer-3 (virtual) interface is configured. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119][RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. The Overlay Multilink Network Interface (OMNI) IPv6 ND Option 105 An Overlay Multilink Network Interface (OMNI) IPv6 ND option is 106 defined. The option (known as the "OMNI option") is formatted as 107 shown in Figure 1: 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Type | Length | Preflen | S/T-omIndex | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | | 115 ~ Sub-Options ~ 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Figure 1: OMNI Option Format 121 In this format: 123 o Type is set to TBD1. 125 o Length is set to the number of 8 octet blocks in the option. 127 o Preflen is an 8 bit field that determines the length of prefix 128 associated with an IPv6 address of the IPv6 ND message. Values 0 129 through 128 specify a valid prefix length (all other values are 130 invalid). For IPv6 ND messages sent from the source to a target 131 node, Preflen applies to the IPv6 source address and provides the 132 length that the source is requesting or asserting. For IPv6 ND 133 messages replies from the target to the original source, Preflen 134 applies to the IPv6 destination address and indicates the length 135 that the target is granting. 137 o S/T-omIndex is a 1-octet field that encodes a value between 0 and 138 255 identifying the source or target underlying interface for the 139 IPv6 ND message. For RS and NS messages S/T-omIndex refers to the 140 "Source" underlying interface over which the message is sent, 141 while for RA and NA messages S/T-omIndex refers to the "Target" 142 underlying interface that will receive the message. 144 o Sub-Options is a Variable-length field, of length such that the 145 complete OMNI Option is an integer multiple of 8 octets long. 146 Contains one or more Sub-Options, as described in Section 3.1. 148 The OMNI option may appear in any IPv6 ND message type; it is 149 processed by interfaces that recognize the option and ignored by all 150 other interfaces. If multiple OMNI option instances appear in the 151 same IPv6 ND message, the interface processes the Preflen and S/ 152 T-omIndex fields in the first instance and ignores those fields in 153 all other instances. The interface processes the Sub-Options of all 154 OMNI option instances in the same IPv6 ND message in the consecutive 155 order in which they occur. 157 The OMNI option(s) in each IPv6 ND message may include full or 158 partial information for the neighbor. The union of the information 159 in the most recently received OMNI options is therefore retained, and 160 the information is aged/removed in conjunction with the corresponding 161 neighbor cache entry. 163 3.1. Sub-Options 165 The OMNI option includes zero or more Sub-Options. Each consecutive 166 Sub-Option is concatenated immediately after its predecessor. All 167 Sub-Options except Pad1 (see below) are in type-length-value (TLV) 168 encoded in the following format: 170 0 1 2 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 173 | Sub-Type| Sub-length | Sub-Option Data ... 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 176 Figure 2: Sub-Option Format 178 o Sub-Type is a 5-bit field that encodes the Sub-Option type. Sub- 179 Options defined in this document are: 181 Option Name Sub-Type 182 Pad1 0 183 PadN 1 184 Interface Attributes (Type 1) 2 185 Sub-Type Extension 30 187 Figure 3 189 Sub-Types 3-29 are available for future assignment for major 190 protocol functions. Sub-Type 31 is reserved by IANA. 192 o Sub-Length is an 11-bit field that encodes the length of the Sub- 193 Option Data (i.e., ranging from 0 to 2034 octets). 195 o Sub-Option Data is a block of data with format determined by Sub- 196 Type and length determined by Sub-Length. 198 During transmission, the OMNI interface codes Sub-Type and Sub-Length 199 together in network byte order in 2 consecutive octets, where Sub- 200 Option Data may be up to 2034 octets in length. This allows ample 201 space for coding large objects (e.g., ascii character strings, 202 protocol messages, security codes, etc.), while a single OMNI option 203 is limited to 2040 octets the same as for any IPv6 ND option. If the 204 Sub-Options to be coded would cause an OMNI option to exceed 2040 205 octets, the OMNI interface codes any remaining Sub-Options in 206 additional OMNI option instances in the intended order of processing 207 in the same IPv6 ND message. Implementations must therefore observe 208 size limitations, and must refrain from sending IPv6 ND messages 209 larger than the OMNI interface MTU. 211 During reception, the OMNI interface processes each OMNI option Sub- 212 Option while skipping over and ignoring any unrecognized Sub-Options. 213 The OMNI interface processes the Sub-Options of all OMNI option 214 instances in the consecutive order in which they appear in the IPv6 215 ND message, beginning with the first instance and continuing through 216 any additional instances to the end of the message. If a Sub-Option 217 length would cause the running total for that OMNI option to exceed 218 the length coded in the option header, the interface accepts any Sub- 219 Options already processed and ignores the remainder of that OMNI 220 option. The interface then processes any remaining OMNI options in 221 the same fashion to the end of the IPv6 ND message. 223 Note: large objects that exceed the Sub-Option Data limit of 2034 224 octets are not supported under the current specification; if this 225 proves to be limiting in practice, future specifications may define 226 support for fragmenting large objects across multiple OMNI options 227 within the same IPv6 ND message. 229 The following Sub-Option types and formats are defined in this 230 document (note that other documents that are active at the time of 231 this writing will define additional Sub-Option types in the near 232 future): 234 3.1.1. Pad1 235 0 236 0 1 2 3 4 5 6 7 237 +-+-+-+-+-+-+-+-+ 238 | S-Type=0|x|x|x| 239 +-+-+-+-+-+-+-+-+ 241 Figure 4: Pad1 243 o Sub-Type is set to 0. If multiple instances appear in OMNI 244 options of the same message all are processed. 246 o Sub-Type is followed by three 'x' bits, set randomly on 247 transmission and ignored on receipt. Pad1 therefore consists of a 248 whole single octet with the most significant 5 bits set to 0, and 249 with no Sub-Length or Sub-Option Data fields following. 251 3.1.2. PadN 253 0 1 2 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 256 | S-Type=1| Sub-length=N | N padding octets ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 259 Figure 5: PadN 261 o Sub-Type is set to 1. If multiple instances appear in OMNI 262 options of the same message all are processed. 264 o Sub-Length is set to N (from 0 to 2047) being the number of 265 padding octets that follow. 267 o Sub-Option Data consists of N padding octets that are typically 268 zero-valued (any non-zero values that may appear in the padding 269 octets are not to be interpreted in any way other than as simple 270 padding). 272 3.1.3. Interface Attributes (Type 1) 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | S-Type=2| Sub-length=N | omIndex | omType | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Provider ID | Link | Resvd |P00|P01|P02|P03|P04|P05|P06|P07| 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19|P20|P21|P22|P23| 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |P24|P25|P26|P27|P28|P29|P30|P31|P32|P33|P34|P35|P36|P37|P38|P39| 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |P40|P41|P42|P43|P44|P45|P46|P47|P48|P49|P50|P51|P52|P53|P54|P55| 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |P56|P57|P58|P59|P60|P61|P62|P63| 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 6: Interface Attributes (Type 1) 291 o Sub-Type is set to 2. If multiple instances with different 292 omIndex values appear in OMNI options of the same message all are 293 processed; if multiple instances with the same omIndex value 294 appear, the first is processed and all others are ignored. 296 o Sub-Length is set to N (from 1 to 2047) that encodes the number of 297 Sub-Option Data octets that follow. 299 o omIndex is a 1-octet field containing a value from 0 to 255 300 identifying the underlying interface for which the interface 301 attributes apply. 303 o omType is a 1-octet field containing a value from 0 to 255 304 corresponding to the underlying interface identified by omIndex. 306 o Provider ID is a 1-octet field containing a value from 0 to 255 307 corresponding to the underlying interface identified by omIndex. 309 o Link encodes a 4-bit link metric. The value '0' means the link is 310 DOWN, and the remaining values mean the link is UP with metric 311 ranging from '1' ("lowest") to '15' ("highest"). 313 o Resvd is reserved for future use. 315 o A 16-octet ""Preferences" field immediately follows 'Resvd', with 316 values P[00] through P[63] corresponding to the 64 Differentiated 317 Service Code Point (DSCP) values [RFC2474]. Each 2-bit P[*] field 318 is set to the value '0' ("disabled"), '1' ("low"), '2' ("medium") 319 or '3' ("high") to indicate a QoS preference for underlying 320 interface selection purposes. 322 3.1.4. Sub-Type Extension 324 Since the Sub-Type field is only 5 bits in length, future 325 specifications of major protocol functions may exhaust the remaining 326 Sub-Type values available for assignment. This document therefore 327 defines Sub-Type 30 as an "extension", meaning that the actual sub- 328 option type is determined by examining a 1 octet "Extension-Type" 329 field immediately following the Sub-Length field. The Sub-Type 330 Extension is formatted as shown in Figure 7: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |S-Type=30| Sub-length=N | Extension-Type| ~ 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 337 ~ ~ 338 ~ Extension-Type Body ~ 339 ~ ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 7: Sub-Type Extension 344 o Sub-Type is set to 30. If multiple instances appear in OMNI 345 options of the same message all are processed, where each 346 individual extension defines its own policy for processing 347 multiple of that type. 349 o Sub-Length is set to N (from 1 to 2034) that encodes the number of 350 Sub-Option Data octets that follow. The Extension-Type field is 351 always present; hence, the maximum Extension-Type Body length is 352 2033 octets. 354 o Extension-Type contains a 1 octet Sub-Type Extension value between 355 0 and 255. 357 o Extension-Type Body contains an N-1 octet block with format 358 defined by the given extension specification. 360 Extension-Type values 0 through 252 are available for assignment by 361 future specifications, which must also define the format of the 362 Extension-Type Body and its processing rules. Extension-Type values 363 253 and 254 are reserved for experimentation, as recommended in 364 [RFC3692], and value 255 is reserved by IANA. 366 4. IANA Considerations 368 The IANA is instructed to allocate a Type number TBD1 from the 369 registry "IPv6 Neighbor Discovery Option Formats" for the OMNI option 370 (see: Section 13 of [RFC4861]) as a provisional registration in 371 accordance with Section 4.13 of [RFC8126]. 373 The OMNI option defines a 5-bit Sub-Type field, for which IANA is 374 instructed to create and maintain a new registry entitled "OMNI 375 option Sub-Type values". Initial values for the OMNI option Sub-Type 376 values registry are given below; future assignments are to be made 377 through Expert Review [RFC8126]. 379 Value Sub-Type name Reference 380 ----- ------------- ---------- 381 0 Pad1 [RFCXXXX] 382 1 PadN [RFCXXXX] 383 2 Interface Attributes (Type 1) [RFCXXXX] 384 3-29 Unassigned 385 30 Sub-Type Extension [RFCXXXX] 386 31 Reserved [RFCXXXX] 388 Figure 8: OMNI Option Sub-Type Values 390 5. Security Considerations 392 Security considerations for IPv6 [RFC8200] and IPv6 Neighbor 393 Discovery [RFC4861] apply. 395 6. Acknowledgements 397 This document is aligned with the International Civil Aviation 398 Organization (ICAO) Aeronautical Telecommunications Network (ATN) 399 with Internet Protocol Services (ATN/IPS) development program. 401 This document is aligned with the IETF 6man (IPv6) working group. 403 7. References 405 7.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 413 Considered Useful", BCP 82, RFC 3692, 414 DOI 10.17487/RFC3692, January 2004, 415 . 417 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 418 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 419 DOI 10.17487/RFC4861, September 2007, 420 . 422 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 423 Writing an IANA Considerations Section in RFCs", BCP 26, 424 RFC 8126, DOI 10.17487/RFC8126, June 2017, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 432 (IPv6) Specification", STD 86, RFC 8200, 433 DOI 10.17487/RFC8200, July 2017, 434 . 436 7.2. Informative References 438 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 439 Interface for Civil Aviation, IETF Liaison Statement 440 #1676, https://datatracker.ietf.org/liaison/1676/", March 441 2020. 443 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 444 Aeronautical Telecommunication Network (ATN) using 445 Internet Protocol Suite (IPS) Standards and Protocol), 446 Draft Edition 3 (work-in-progress)", December 2020. 448 [I-D.templin-6man-omni-interface] 449 Templin, F. and T. Whyman, "Transmission of IP Packets 450 over Overlay Multilink Network (OMNI) Interfaces", draft- 451 templin-6man-omni-interface-69 (work in progress), January 452 2021. 454 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 455 "Definition of the Differentiated Services Field (DS 456 Field) in the IPv4 and IPv6 Headers", RFC 2474, 457 DOI 10.17487/RFC2474, December 1998, 458 . 460 Authors' Addresses 462 Fred L. Templin (editor) 463 The Boeing Company 464 P.O. Box 3707 465 Seattle, WA 98124 466 USA 468 Email: fltemplin@acm.org 470 Tony Whyman 471 MWA Ltd c/o Inmarsat Global Ltd 472 99 City Road 473 London EC1Y 1AX 474 England 476 Email: tony.whyman@mccallumwhyman.com