idnits 2.17.1 draft-templin-atn-aero-interface-16.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 date (February 3, 2020) is 1543 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: '1' on line 450 -- Looks like a reference, but probably isn't: '2' on line 460 == Missing Reference: 'N' is mentioned on line 472, but not defined == Unused Reference: 'RFC2225' is defined on line 937, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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 6, 2020 MWA Ltd c/o Inmarsat Global Ltd 6 February 3, 2020 8 Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) 9 Interfaces 10 draft-templin-atn-aero-interface-16 12 Abstract 14 Mobile nodes (e.g., aircraft of various configurations, terrestrial 15 vehicles, seagoing vessels, mobile enterprise devices, etc.) 16 communicate with networked correspondents over multiple access 17 network data links and configure mobile routers to connect end user 18 networks. A multilink interface specification is therefore needed 19 for coordination with the network-based mobility service. This 20 document specifies the transmission of IPv6 packets over Overlay 21 Multilink Network (OMNI) Interfaces. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 6, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overlay Multilink Network (OMNI) Interface Model . . . . . . 5 61 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 9 62 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 9 64 8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 10 65 9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 13 66 10. Address Mapping for IPv6 Neighbor Discovery Messages . . . . 13 67 11. Conceptual Sending Algorithm . . . . . . . . . . . . . . . . 14 68 11.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 14 69 12. Router Discovery and Prefix Registration . . . . . . . . . . 15 70 13. AR and MSE Resilience . . . . . . . . . . . . . . . . . . . . 18 71 14. Detecting and Responding to MSE Failures . . . . . . . . . . 18 72 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 73 16. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 75 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 18.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 18.2. Informative References . . . . . . . . . . . . . . . . . 21 78 Appendix A. OMNI Option Extensions for Pseudo-DSCP Mappings . . 22 79 Appendix B. Prefix Length Considerations . . . . . . . . . . . . 23 80 Appendix C. VDL Mode 2 Considerations . . . . . . . . . . . . . 23 81 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 24 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 84 1. Introduction 86 Mobile Nodes (MNs) (e.g., aircraft of various configurations, 87 terrestrial vehicles, seagoing vessels, mobile enterprise devices, 88 etc.) often have multiple data links for communicating with networked 89 correspondents. These data links may have diverse performance, cost 90 and availability properties that can change dynamically according to 91 mobility patterns, flight phases, proximity to infrastructure, etc. 92 MNs coordinate their data links in a discipline known as "multilink", 93 in which a single virtual interface is configured over the underlying 94 data link interfaces. 96 The MN configures a virtual interface (termed the "Overlay Multilink 97 Network (OMNI) interface") as a thin layer over the underlying access 98 network interfaces. The OMNI interface is therefore the only 99 interface abstraction exposed to the IPv6 layer and behaves according 100 to the Non-Broadcast, Multiple Access (NBMA) interface principle, 101 while underlying access network interfaces appear as link layer 102 communication channels in the architecture. The OMNI interface 103 connects to a virtual overlay service known as the "OMNI link". The 104 OMNI link spans a worldwide Internetwork that may include private-use 105 infrastructures and/or the global public Internet itself. 107 Each MN receives a Mobile Network Prefix (MNP) for numbering 108 downstream-attached End User Networks (EUNs) independently of the 109 access network data links selected for data transport. The MN 110 performs router discovery over the OMNI interface (i.e., similar to 111 IPv6 customer edge routers [RFC7084]) and acts as a mobile router on 112 behalf of its EUNs. The router discovery process is iterated over 113 each of the OMNI interface's underlying access network data links in 114 order to register per-link parameters (see Section 12). 116 The OMNI interface provides a multilink nexus for exchanging inbound 117 and outbound traffic via the correct underlying Access Network (ANET) 118 interface(s). The IPv6 layer sees the OMNI interface as a point of 119 connection to the OMNI link. Each OMNI link has one or more 120 associated Mobility Service Prefixes (MSPs) from which OMNI link MNPs 121 are derived. If there are multiple OMNI links, the IPv6 layer will 122 see multiple OMNI interfaces. 124 The OMNI interface interacts with a network-based Mobility Service 125 (MS) through IPv6 Neighbor Discovery (ND) control message exchanges 126 [RFC4861]. The MS provides Mobility Service Endpoints (MSEs) that 127 track MN movements and represent their MNPs in a global routing or 128 mapping system. 130 This document specifies the transmission of IPv6 packets [RFC8200] 131 and MN/MS control messaging over OMNI interfaces. 133 2. Terminology 135 The terminology in the normative references applies; especially, the 136 terms "link" and "interface" are the same as defined in the IPv6 137 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 138 Also, the Protocol Constants defined in Section 10 of [RFC4861] are 139 used in their same format and meaning in this document. 141 The following terms are defined within the scope of this document: 143 Mobile Node (MN) 144 an end system with multiple distinct upstream data link 145 connections that are managed together as a single logical unit. 146 The MN's data link connection parameters can change over time due 147 to, e.g., node mobility, link quality, etc. The MN further 148 connects a downstream-attached End User Network (EUN). The term 149 MN used here is distinct from uses in other documents, and does 150 not imply a particular mobility protocol. 152 End User Network (EUN) 153 a simple or complex downstream-attached mobile network that 154 travels with the MN as a single logical unit. The IPv6 addresses 155 assigned to EUN devices remain stable even if the MN's upstream 156 data link connections change. 158 Mobility Service (MS) 159 a mobile routing service that tracks MN movements and ensures that 160 MNs remain continuously reachable even across mobility events. 161 Specific MS details are out of scope for this document. 163 Mobility Service Prefix (MSP) 164 an aggregated IPv6 prefix (e.g., 2001:db8::/32) advertised to the 165 rest of the Internetwork by the MS, and from which more-specific 166 Mobile Network Prefixes (MNPs) are derived. 168 Mobile Network Prefix (MNP) 169 a longer IPv6 prefix taken from the MSP (e.g., 170 2001:db8:1000:2000::/56) and assigned to a MN. MNs sub-delegate 171 the MNP to devices located in EUNs. 173 Access Network (ANET) 174 a data link service network (e.g., an aviation radio access 175 network, satellite service provider network, cellular operator 176 network, etc.) that provides an Access Router (AR) for connecting 177 MNs to correspondents in outside Internetworks. Physical and/or 178 data link level security between the MN and AR are assumed. 180 ANET interface 181 a MN's attachment to a link in an ANET. 183 Internetwork (INET) 184 a connected network region with a coherent IP addressing plan that 185 provides transit forwarding services for ANET MNs and INET 186 correspondents. Examples include private enterprise networks, 187 ground domain aviation service networks and the global public 188 Internet itself. 190 INET interface 191 a node's attachment to a link in an INET. 193 OMNI link 194 a virtual overlay configured over one or more INETs and their 195 connected ANETs. An OMNI link can comprise multiple INET segments 196 joined by bridges the same as for any link; the addressing plans 197 in each segment may be mutually exclusive and managed by different 198 administrative entities. 200 OMNI interface 201 a node's attachment to an OMNI link, and configured over one or 202 more underlying ANET/INET interfaces. 204 OMNI link local address (LLA) 205 an IPv6 link-local address constructed as specified in Section 7, 206 and assigned to an OMNI interface. 208 Multilink 209 an OMNI interface's manner of managing diverse underlying data 210 link interfaces as a single logical unit. The OMNI interface 211 provides a single unified interface to upper layers, while 212 underlying data link selections are performed on a per-packet 213 basis considering factors such as DSCP, flow label, application 214 policy, signal quality, cost, etc. Multilinking decisions are 215 coordinated in both the outbound (i.e. MN to correspondent) and 216 inbound (i.e., correspondent to MN) directions. 218 L2 219 The second layer in the OSI network model. Also known as "layer- 220 2", "link-layer", "sub-IP layer", "data link layer", etc. 222 L3 223 The third layer in the OSI network model. Also known as "layer- 224 3", "network-layer", "IPv6 layer", etc. 226 3. Requirements 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 230 "OPTIONAL" in this document are to be interpreted as described in BCP 231 14 [RFC2119][RFC8174] when, and only when, they appear in all 232 capitals, as shown here. 234 4. Overlay Multilink Network (OMNI) Interface Model 236 An OMNI interface is a MN virtual interface configured over one or 237 more ANET interfaces, which may be physical (e.g., an aeronautical 238 radio link) or virtual (e.g., an Internet or higher-layer "tunnel"). 239 The MN receives a MNP from the MS, and coordinates with the MS 240 through IPv6 ND message exchanges. The MN uses the MNP to construct 241 a unique OMNI LLA through the algorithmic derivation specified in 242 Section 7 and assigns the LLA to the OMNI interface. 244 The OMNI interface architectural layering model is the same as in 245 [RFC7847], and augmented as shown in Figure 1. The IP layer (L3) 246 therefore sees the OMNI interface as a single network layer interface 247 with multiple underlying ANET interfaces that appear as L2 248 communication channels in the architecture. 250 +----------------------------+ 251 | Upper Layer Protocol | 252 Session-to-IP +---->| | 253 Address Binding | +----------------------------+ 254 +---->| IP (L3) | 255 IP Address +---->| | 256 Binding | +----------------------------+ 257 +---->| OMNI Interface | 258 Logical-to- +---->| (OMNI LLA) | 259 Physical | +----------------------------+ 260 Interface +---->| L2 | L2 | | L2 | 261 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 262 +------+------+ +------+ 263 | L1 | L1 | | L1 | 264 | | | | | 265 +------+------+ +------+ 267 Figure 1: OMNI Interface Architectural Layering Model 269 The OMNI virtual interface model gives rise to a number of 270 opportunities: 272 o since OMNI LLAs are uniquely derived from an MNP, no Duplicate 273 Address Detection (DAD) messaging is necessary over the OMNI 274 interface. 276 o ANET interfaces do not require any L3 addresses (i.e., not even 277 link-local) in environments where communications are coordinated 278 entirely over the OMNI interface. 280 o as ANET interface properties change (e.g., link quality, cost, 281 availability, etc.), any active ANET interface can be used to 282 update the profiles of multiple additional ANET interfaces in a 283 single message. This allows for timely adaptation and service 284 continuity under dynamically changing conditions. 286 o coordinating ANET interfaces in this way allows them to be 287 represented in a unified MS profile with provisions for mobility 288 and multilink operations. 290 o exposing a single virtual interface abstraction to the IPv6 layer 291 allows for multilink operation (including QoS based link 292 selection, packet replication, load balancing, etc.) at L2 while 293 still permitting queuing at the L3 based on, e.g., DSCP, flow 294 label, etc. 296 o L3 sees the OMNI interface as a point of connection to the OMNI 297 link; if there are multiple OMNI links (i.e., multiple MS's), L3 298 will see multiple OMNI interfaces. 300 Other opportunities are discussed in [RFC7847]. 302 Figure 2 depicts the architectural model for a MN connecting to the 303 MS via multiple independent ANETs. When an ANET interface becomes 304 active, the MN's OMNI interface sends native (i.e., unencapsulated) 305 IPv6 ND messages via the underlying ANET interface. IPv6 ND messages 306 traverse the ground domain ANETs until they reach an Access Router 307 (AR#1, AR#2, .., AR#n). The AR then coordinates with a Mobility 308 Service Endpoint (MSE#1, MSE#2, ..., MSE#m) in the INET and returns 309 an IPv6 ND message response to the MN. IPv6 ND messages traverse the 310 ANET at layer 2; hence, the Hop Limit is not decremented. 312 +--------------+ 313 | MN | 314 +--------------+ 315 |OMNI interface| 316 +----+----+----+ 317 +--------|IF#1|IF#2|IF#n|------ + 318 / +----+----+----+ \ 319 / | \ 320 / <---- Native | IP ----> \ 321 v v v 322 (:::)-. (:::)-. (:::)-. 323 .-(::ANET:::) .-(::ANET:::) .-(::ANET:::) 324 `-(::::)-' `-(::::)-' `-(::::)-' 325 +----+ +----+ +----+ 326 ... |AR#1| .......... |AR#2| ......... |AR#n| ... 327 . +-|--+ +-|--+ +-|--+ . 328 . | | | 329 . v v v . 330 . <----- Encapsulation -----> . 331 . . 332 . +-----+ (:::)-. . 333 . |MSE#2| .-(::::::::) +-----+ . 334 . +-----+ .-(::: INET :::)-. |MSE#m| . 335 . (::::: Routing ::::) +-----+ . 336 . `-(::: System :::)-' . 337 . +-----+ `-(:::::::-' . 338 . |MSE#1| +-----+ +-----+ . 339 . +-----+ |MSE#3| |MSE#4| . 340 . +-----+ +-----+ . 341 . . 342 . . 343 . <----- Worldwide Connected Internetwork ----> . 344 ........................................................... 346 Figure 2: MN/MS Coordination via Multiple ANETs 348 After the initial IPv6 ND message exchange, the MN can send and 349 receive unencapsulated IPv6 data packets over the OMNI interface. 350 OMNI interface multilink services will forward the packets via ARs in 351 the correct underlying ANETs. The AR encapsulates the packets 352 according to the capabilities provided by the MS and forwards them to 353 the next hop within the worldwide connected Internetwork via optimal 354 routes. 356 5. Maximum Transmission Unit 358 All IPv6 interfaces MUST configure an MTU of at least 1280 bytes 359 [RFC8200]. The OMNI interface configures its MTU based on the 360 largest MTU among all underlying ANET interfaces. The value MAY be 361 overridden if an RA message with an MTU option is received. 363 The OMNI interface returns internally-generated IPv6 Path MTU 364 Discovery (PMTUD) Packet Too Big (PTB) messages [RFC8201] for packets 365 admitted into the OMNI interface that are too large for the outbound 366 underlying ANET interface. Similarly, the OMNI interface performs 367 PMTUD even if the destination appears to be on the same link since a 368 proxy on the path could return a PTB message. PMTUD therefore 369 ensures that the OMNI interface MTU is adaptive and reflects the 370 current path used for a given data flow. 372 Applications that cannot tolerate loss due to MTU restrictions SHOULD 373 refrain from sending packets larger than 1280 bytes, since dynamic 374 path changes can reduce the path MTU at any time. Applications that 375 may benefit from sending larger packets even though the path MTU may 376 change dynamically MAY use larger sizes. 378 6. Frame Format 380 The OMNI interface transmits IPv6 packets according to the native 381 frame format of each underlying ANET interface. For example, for 382 Ethernet-compatible interfaces the frame format is specified in 383 [RFC2464], for aeronautical radio interfaces the frame format is 384 specified in standards such as ICAO Doc 9776 (VDL Mode 2 Technical 385 Manual), for tunnels over IPv6 the frame format is specified in 386 [RFC2473], etc. 388 7. Link-Local Addresses 390 OMNI interfaces assign IPv6 Link-Local Addresses (i.e., "OMNI LLAs") 391 using the following constructs: 393 o IPv6 MN OMNI LLAs encode the most-significant 64 bits of a MNP 394 within the least-significant 64 bits (i.e., the interface ID) of a 395 Link-Local IPv6 Unicast Address (see: [RFC4291], Section 2.5.6). 396 For example, for the MNP 2001:db8:1000:2000::/56 the corresponding 397 LLA is fe80::2001:db8:1000:2000. 399 o IPv4-compatible MN OMNI LLAs are assigned as fe80::ffff:[v4addr], 400 i.e., the most significant 10 bits of the prefix fe80::/10, 401 followed by 70 '0' bits, followed by 16 '1' bits, followed by a 402 32bit IPv4 address. For example, the IPv4-Compatible MN OMNI LLA 403 for 192.0.2.1 is fe80::ffff:192.0.2.1 (also written as 404 fe80::ffff:c000:0201). 406 o MSE OMNI LLAs are assigned from the range fe80::/96, and MUST be 407 managed for uniqueness. The lower 32 bits of the LLA includes a 408 unique integer value between '1' and 'fffffffe', e.g., as in 409 fe80::1, fe80::2, fe80::3, etc., fe80::ffff:fffe. The address 410 fe80:: is the link-local Subnet-Router anycast address [RFC4291] 411 and the address fe80::ffff:ffff is reserved. (Note that distinct 412 OMNI link segments can avoid overlap by assignig MSE OMNI LLAs 413 from unique fe80::/96 sub-prefixes. For example, a first segment 414 could assign from fe80::1000/116, a second from fe80::2000/116, a 415 third from fe80::3000/116, etc.) 417 Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 418 MNPs can be allocated from that block ensuring that there is no 419 possibility for overlap between the above OMNI LLA constructs. 421 Since MN OMNI LLAs are based on the distribution of administratively 422 assured unique MNPs, and since MSE OMNI LLAs are guaranteed unique 423 through administrative assignment, OMNI interfaces set the 424 autoconfiguration variable DupAddrDetectTransmits to 0 [RFC4862]. 426 8. Address Mapping - Unicast 428 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 429 state and use the link-local address format specified in Section 7. 430 IPv6 Neighbor Discovery (ND) [RFC4861] messages on MN OMNI interfaces 431 observe the native Source/Target Link-Layer Address Option (S/TLLAO) 432 formats of the underlying ANET interfaces (e.g., for Ethernet the S/ 433 TLLAO is specified in [RFC2464]). 435 MNs such as aircraft typically have many wireless data link types 436 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 437 etc.) with diverse performance, cost and availability properties. 438 The OMNI interface would therefore appear to have multiple L2 439 connections, and may include information for multiple ANET interfaces 440 in a single IPv6 ND message exchange. 442 OMNI interfaces use an IPv6 ND option called the "OMNI option" 443 formatted as shown in Figure 3: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type | Length | Prefix Length |R|N| Reserved | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | ifIndex[1] | ifType[1] | Reserved [1] |Link[1]|QoS[1] | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | ifIndex[2] | ifType[2] | Reserved [2] |Link[2]|QoS[2] | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 ... ... ... 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | ifIndex[N] | ifType[N] | Reserved [N] |Link[N]|QoS[N] | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | zero-padding (if necessary) | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Notification ID (present only if N=1) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 3: OMNI Option Format 489 In this format: 491 o Type is set to TBD. 493 o Length is set to the number of 8 octet blocks in the option. 495 o Prefix Length is set according to the IPv6 source LLA type. For 496 MN OMNI LLAs, the value is set to the length of the embedded MNP. 497 For MSE OMNI LLAs, the value is set to 128. 499 o R (the "Register/Release" bit) is set to '1' to register an MNP or 500 set to '0' to release a registration. 502 o N (the "Notify" bit) is set to '1' if the option includes a 503 trailing 4 byte "Notification ID" (see below); set to '0' 504 otherwise. 506 o Reserved is set to the value '0' on transmission and ignored on 507 reception. 509 o A set of N ANET interface "ifIndex-tuples" are included as 510 follows: 512 * ifIndex[i] is set to an 8-bit integer value corresponding to a 513 specific underlying ANET interface. The first ifIndex-tuple 514 MUST correspond to the ANET interface over which the message is 515 sent. IPv6 ND messages originating from a MN may include 516 multiple ifIndex-tuples, and MUST number each with a distinct 517 ifIndex value between '1' and '255' that represents a MN- 518 specific 8-bit mapping for the actual ifIndex value assigned to 519 the ANET interface by network management [RFC2863]. IPv6 ND 520 messages originating from the MS include a single ifIndex-tuple 521 with ifIndex set to the value '0'. 523 * ifType[i] is set to an 8-bit integer value corresponding to the 524 underlying ANET interface identified by ifIndex. The value 525 represents an OMNI interface-specific 8-bit mapping for the 526 actual IANA ifType value registered in the 'IANAifType-MIB' 527 registry [http://www.iana.org]. 529 * Reserved[i] is set to the value '0' on transmission and ignored 530 on reception. 532 * Link[i] encodes a 4-bit link metric. The value '0' means the 533 link is DOWN, and the remaining values mean the link is UP with 534 metric ranging from '1' ("lowest") to '15' ("highest"). 536 * QoS[i] encodes the number of 4-byte blocks (between '0' and 537 '15') of two-bit P[*] values that follow. The first 4 blocks 538 correspond to the 64 Differentiated Service Code Point (DSCP) 539 values P00 - P63 [RFC2474]. If additional 4-byte P[i] blocks 540 follow, their values correspond to "pseudo-DSCP" values P64, 541 P65, P66, etc. numbered consecutively. The pseudo-DSCP values 542 correspond to ancillary QoS information defined for the 543 specific OMNI interface (e.g., see Appendix A). 545 * P[*] includes zero or more per-ifIndex 4-byte blocks of two-bit 546 Preferences. Each P[*] field is set to the value '0' 547 ("disabled"), '1' ("low"), '2' ("medium") or '3' ("high") to 548 indicate a QoS preference level for ANET interface selection 549 purposes. The first four blocks always correspond to the 64 550 DSCP values in consecutive order. If one or more of the blocks 551 are absent (e.g., for QoS values 0,1,2,3) the P[*] values for 552 the missing blocks default to "medium". 554 o Zero-padding added if necessary to produce an integral number of 8 555 octet blocks. 557 o Notification ID (present only if N = '1') contains the least- 558 significant 32 bits of an MSE OMNI LLA to notify. For example, 559 for the LLA fe80::face:cafe the field contains 0xfacecafe. 561 9. Address Mapping - Multicast 563 The multicast address mapping of the native underlying ANET interface 564 applies. The mobile router on board the aircraft also serves as an 565 IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] 566 while using the L2 address of the router as the L2 address for all 567 multicast packets. 569 10. Address Mapping for IPv6 Neighbor Discovery Messages 571 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 572 unicast link-scoped IPv6 destination address. However, IPv6 ND 573 messaging is coordinated between the MN and MS only without invoking 574 other nodes on the ANET. 576 For this reason, ANET links maintain unicast L2 addresses ("MSADDR") 577 for the purpose of supporting MN/MS IPv6 ND messaging. For Ethernet- 578 compatible ANETs, this specification reserves one Ethernet unicast 579 address TBD2. For non-Ethernet statically-addressed ANETs, MSADDR is 580 reserved per the assigned numbers authority for the ANET addressing 581 space. For still other ANETs, MSADDR may be dynamically discovered 582 through other means, e.g., L2 beacons. 584 MNs map the L3 addresses of all IPv6 ND messages they send (i.e., 585 both multicast and unicast) to an MSADDR instead of to an ordinary 586 unicast or multicast L2 address. In this way, all of the MN's IPv6 587 ND messages will be received by MS devices that are configured to 588 accept packets destined to MSADDR. Note that multiple MS devices on 589 the link could be configured to accept packets destined to MSADDR, 590 e.g., as a basis for supporting redundancy. 592 Therefore, ARs MUST accept and process packets destined to MSADDR, 593 while all other devices MUST NOT process packets destined to MSADDR. 594 This model has well-established operational experience in Proxy 595 Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 597 11. Conceptual Sending Algorithm 599 The MN's IPv6 layer selects the outbound OMNI interface according to 600 standard IPv6 requirements when forwarding data packets from local or 601 EUN applications to external correspondents. The OMNI interface 602 maintains default routes and neighbor cache entries for MSEs, and may 603 also include additional neighbor cache entries created through other 604 means (e.g., Address Resolution, static configuration, etc.). 606 After a packet enters the OMNI interface, an outbound ANET interface 607 is selected based on multilink parameters such as DSCP, application 608 port number, cost, performance, message size, etc. OMNI interface 609 multilink selections could also be configured to perform replication 610 across multiple ANET interfaces for increased reliability at the 611 expense of packet duplication. 613 OMNI interface multilink service designers MUST observe the BCP 614 guidance in Section 15 [RFC3819] in terms of implications for 615 reordering when packets from the same flow may be spread across 616 multiple ANET interfaces having diverse properties. 618 11.1. Multiple OMNI Interfaces 620 MNs may associate with multiple MS instances concurrently. Each MS 621 instance represents a distinct OMNI link distinguished by its 622 associated MSPs. The MN configures a separate OMNI interface for 623 each link so that multiple interfaces (e.g., omni0, omni1, omni2, 624 etc.) are exposed to the IPv6 layer. 626 Depending on local policy and configuration, an MN may choose between 627 alternative active OMNI interfaces using a packet's DSCP, routing 628 information or static configuration. Interface selection based on 629 per-packet source addresses is also enabled when the MSPs for each 630 OMNI interface are known (e.g., discovered through Prefix Information 631 Options (PIOs) and/or Route Information Options (RIOs)). 633 Each OMNI interface can be configured over the same or different sets 634 of ANET interfaces. Each ANET distinguishes between the different 635 OMNI links based on the MSPs represented in per-packet IPv6 636 addresses. 638 Multiple distinct OMNI links can therefore be used to support fault 639 tolerance, load balancing, reliability, etc. The architectural model 640 parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs 641 serve as (virtual) VLAN tags. 643 12. Router Discovery and Prefix Registration 645 ARs process IPv6 ND messages destined to All-Routers multicast 646 (ff02::2), Subnet-Router anycast (fe80::) and unicast IPv6 LLAs 647 [RFC4291]. ARs configure the L2 address MSADDR (see: Section 10) and 648 act as a proxy for MSE OMNI LLAs. 650 MNs interface with the MS by sending RS messages with OMNI options. 651 For each ANET interface, the MN sends an RS message with an OMNI 652 option, with L2 destination address set to MSADDR and with L3 653 destination address set to either a specific MSE OMNI LLA, link-local 654 Subnet-Router anycast, or All-Routers multicast. The MN discovers 655 MSE OMNI LLAs either through an RA message response to an initial 656 anycast/multicast RS or before sending an initial RS message. 657 [RFC5214] provides example MSE address discovery methods, including 658 information conveyed during data link login, name service lookups, 659 static configuration, etc. 661 The AR receives the RS messages and coordinates with the 662 corresponding MSE in a manner outside the scope of this document. 663 The AR returns an RA message with source address set to the MSE OMNI 664 LLA, with an OMNI option and with any information for the link that 665 would normally be delivered in a solicited RA message. (Note that if 666 all MSEs share common state, the AR can instead return an RA with 667 source address set to link-local Subnet-Router anycast.) 669 MNs configure OMNI interfaces that observe the properties discussed 670 in the previous section. The OMNI interface and its underlying 671 interfaces are said to be in either the "UP" or "DOWN" state 672 according to administrative actions in conjunction with the interface 673 connectivity status. An OMNI interface transitions to UP or DOWN 674 through administrative action and/or through state transitions of the 675 underlying interfaces. When a first underlying interface transitions 676 to UP, the OMNI interface also transitions to UP. When all 677 underlying interfaces transition to DOWN, the OMNI interface also 678 transitions to DOWN. 680 When an OMNI interface transitions to UP, the MN sends initial RS 681 messages to register its MNP and an initial set of underlying ANET 682 interfaces that are also UP. The MN sends additional RS messages to 683 refresh lifetimes and to register/deregister underlying ANET 684 interfaces as they transition to UP or DOWN. 686 ARs return RA messages with configuration information in response to 687 a MN's RS messages. The RAs include a Router Lifetime value and any 688 necessary options, such as: 690 o PIOs with (A; L=0) that include MSPs for the link [RFC8028]. 692 o RIOs [RFC4191] with more-specific routes. 694 o an MTU option that specifies the maximum acceptable packet size 695 for the OMNI link 697 The AR coordinates with the MSE and sends immediate unicast RA 698 responses without delay; therefore, the IPv6 ND MAX_RA_DELAY_TIME and 699 MIN_DELAY_BETWEEN_RAS constants for multicast RAs do not apply. The 700 AR MAY send periodic and/or event-driven unsolicited RA messages, but 701 is not required to do so for unicast advertisements [RFC4861]. 703 The MN sends RS messages from within the OMNI interface while using 704 an UP underlying ANET interface as the outbound interface. Each RS 705 message is formatted as though it originated from the IPv6 layer, but 706 the process is coordinated wholly from within the OMNI interface and 707 is therefore opaque to the IPv6 layer. The MN sends initial RS 708 messages over an UP underlying interface with its OMNI LLA as the 709 source. The RS messages include an OMNI option with a valid Prefix 710 Length as well as ifIndex-tuples appropriate for underlying ANET 711 interfaces. The AR processes RS message and conveys the OMNI option 712 information to the MSE. 714 When the MSE processes the OMNI information, it first validates the 715 prefix registration information. If the prefix registration was 716 valid, the MSE injects the MNP into the routing/mapping system then 717 caches the new Prefix Length, MNP and ifIndex-tuples. The MSE then 718 directs the AR to return an RA message to the MN with an OMNI option 719 and with a non-zero Router Lifetime if the prefix registration was 720 successful; otherwise, with a zero Router Lifetime. If the MN's OMNI 721 option included a Notification ID, the new MSE also notifies the 722 former MSE. 724 When the MN receives the RA message, it creates a default route with 725 L3 next hop address set to the address found in the RA source address 726 and with L2 address set to MSADDR. The AR will then forward packets 727 between the MN and the MS. 729 The MN then manages its underlying ANET interfaces according to their 730 states as follows: 732 o When an underlying ANET interface transitions to UP, the MN sends 733 an RS over the ANET interface with an OMNI option. The OMNI 734 option contains a first ifIndex-tuple with values specific to this 735 ANET interface, and may contain additional ifIndex-tuples specific 736 to other ANET interfaces. 738 o When an underlying ANET interface transitions to DOWN, the MN 739 sends an RS or unsolicited NA message over any UP ANET interface 740 with an OMNI option containing an ifIndex-tuple for the DOWN ANET 741 interface with Link(i) set to '0'. The MN sends an RS when an 742 acknowledgement is required, or an unsolicited NA when reliability 743 is not thought to be a concern (e.g., if redundant transmissions 744 are sent on multiple ANET interfaces). 746 o When a MN wishes to release from a current MSE, it sends an RS or 747 unsolicited NA message over any UP ANET interfaces with an OMNI 748 option with R set to 0. The corresponding MSE then withdraws the 749 MNP from the routing/mapping system and (for RS responses) returns 750 an RA message with an OMNI option and with Router Lifetime set to 751 0. 753 o When a MN wishes to transition to a new MSE, it sends an RS or 754 unsolicited NA message over any UP ANET interfaces with an OMNI 755 option with R set to 1, with the new MSE OMNI LLA set in the 756 destination address, and (optionally) with N set to 1 and a 757 Notification ID included for the former MSE. 759 o When all of a MNs underlying interfaces have transitioned to DOWN 760 (or if no further MN RS messages are received before Router 761 Lifetime expires) the MSE withdraws the MNP the same as if it had 762 received a message with an OMNI option with R set to 0. 764 The MN is responsible for retrying each RS exchange up to 765 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 766 seconds until an RA is received. If no RA is received over multiple 767 UP ANET interfaces, the MN declares this MSE unreachable and tries a 768 different MSE. 770 The IPv6 layer sees the OMNI interface as an ordinary IPv6 interface. 771 Therefore, when the IPv6 layer sends an RS message the OMNI interface 772 returns an internally-generated RA message as though the message 773 originated from an IPv6 router. The internally-generated RA message 774 contains configuration information (such as Router Lifetime, MTU, 775 etc.) that is consistent with the information received from the RAs 776 generated by the MS. 778 Whether the OMNI interface IPv6 ND messaging process is initiated 779 from the receipt of an RS message from the IPv6 layer is an 780 implementation matter. Some implementations may elect to defer the 781 IPv6 ND messaging process until an RS is received from the IPv6 782 layer, while others may elect to initiate the process proactively. 784 13. AR and MSE Resilience 786 ANETs SHOULD deploy ARs in Virtual Router Redundancy Protocol (VRRP) 787 [RFC5798] configurations so that service continuity is maintained 788 even if one or more ARs fail. Using VRRP, the MN is unaware which of 789 the (redundant) ARs is currently providing service, and any service 790 discontinuity will be limited to the failover time supported by VRRP. 791 Widely deployed public domain implementations of VRRP are available. 793 MSEs SHOULD use high availability clustering services so that 794 multiple redundant systems can provide coordinated response to 795 failures. As with VRRP, widely deployed public domain 796 implementations of high availability clustering services are 797 available. Note that special-purpose and expensive dedicated 798 hardware is not necessary, and public domain implementations can be 799 used even between lightweight virtual machines in cloud deployments. 801 14. Detecting and Responding to MSE Failures 803 In environments where fast recovery from MSE failure is required, ARs 804 SHOULD use proactive Neighbor Unreachability Detection (NUD) in a 805 manner that parallels Bidirectional Forwarding Detection (BFD) 806 [RFC5880] to track MSE reachability. ARs can then quickly detect and 807 react to failures so that cached information is re-established 808 through alternate paths. Proactive NUD control messaging is carried 809 only over well-connected ground domain networks (i.e., and not low- 810 end aeronautical radio links) and can therefore be tuned for rapid 811 response. 813 ARs perform proactive NUD for MSEs for which there are currently 814 active ANET MNs. If an MSE fails, ARs can quickly inform MNs of the 815 outage by sending multicast RA messages on the ANET interface. The 816 AR sends RA messages to the MN via the ANET interface with source 817 address set to the MSEs OMNI LLA, destination address set to All- 818 Nodes multicast (ff02::1) [RFC4291], and Router Lifetime set to 0. 820 The AR SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated 821 by small delays [RFC4861]. Any MNs on the ANET interface that have 822 been using the (now defunct) MSE will receive the RA messages and 823 associate with a new MSE. 825 15. IANA Considerations 827 The IANA is instructed to allocate an official Type number TBD from 828 the registry "IPv6 Neighbor Discovery Option Formats" for the OMNI 829 option. Implementations set Type to 253 as an interim value 830 [RFC4727]. 832 The IANA is instructed to allocate one Ethernet unicast address TBD2 833 (suggest 00-00-5E-00-52-14 [RFC5214]) in the registry "IANA Ethernet 834 Address Block - Unicast Use". 836 16. Security Considerations 838 Security considerations for IPv6 [RFC8200] and IPv6 Neighbor 839 Discovery [RFC4861] apply. OMNI interface IPv6 ND messages SHOULD 840 include Nonce and Timestamp options [RFC3971] when synchronized 841 transaction confirmation is needed. 843 Security considerations for specific access network interface types 844 are covered under the corresponding IP-over-(foo) specification 845 (e.g., [RFC2464]). 847 17. Acknowledgements 849 The first version of this document was prepared per the consensus 850 decision at the 7th Conference of the International Civil Aviation 851 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 852 2019. Consensus to take the document forward to the IETF was reached 853 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 854 Attendees and contributors included: Guray Acar, Danny Bharj, 855 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 856 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 857 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 858 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 859 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 860 Fryderyk Wrobel and Dongsong Zeng. 862 The following individuals are acknowledged for their useful comments: 863 Pavel Drasil, Zdenek Jaron, Michael Matyas, Madhu Niraula, Greg 864 Saccone, Stephane Tamalet, Eric Vyncke. Naming of the IPv6 ND option 865 was discussed on the 6man mailing list. 867 This work is aligned with the NASA Safe Autonomous Systems Operation 868 (SASO) program under NASA contract number NNA16BD84C. 870 This work is aligned with the FAA as per the SE2025 contract number 871 DTFAWA-15-D-00030. 873 18. References 875 18.1. Normative References 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, 879 DOI 10.17487/RFC2119, March 1997, 880 . 882 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 883 "Definition of the Differentiated Services Field (DS 884 Field) in the IPv4 and IPv6 Headers", RFC 2474, 885 DOI 10.17487/RFC2474, December 1998, 886 . 888 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 889 "SEcure Neighbor Discovery (SEND)", RFC 3971, 890 DOI 10.17487/RFC3971, March 2005, 891 . 893 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 894 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 895 November 2005, . 897 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 898 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 899 2006, . 901 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 902 ICMPv6, UDP, and TCP Headers", RFC 4727, 903 DOI 10.17487/RFC4727, November 2006, 904 . 906 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 907 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 908 DOI 10.17487/RFC4861, September 2007, 909 . 911 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 912 Address Autoconfiguration", RFC 4862, 913 DOI 10.17487/RFC4862, September 2007, 914 . 916 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 917 Hosts in a Multi-Prefix Network", RFC 8028, 918 DOI 10.17487/RFC8028, November 2016, 919 . 921 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 922 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 923 May 2017, . 925 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 926 (IPv6) Specification", STD 86, RFC 8200, 927 DOI 10.17487/RFC8200, July 2017, 928 . 930 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 931 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 932 DOI 10.17487/RFC8201, July 2017, 933 . 935 18.2. Informative References 937 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 938 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 939 . 941 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 942 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 943 . 945 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 946 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 947 December 1998, . 949 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 950 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 951 . 953 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 954 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 955 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 956 RFC 3819, DOI 10.17487/RFC3819, July 2004, 957 . 959 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 960 "Internet Group Management Protocol (IGMP) / Multicast 961 Listener Discovery (MLD)-Based Multicast Forwarding 962 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 963 August 2006, . 965 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 966 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 967 RFC 5213, DOI 10.17487/RFC5213, August 2008, 968 . 970 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 971 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 972 DOI 10.17487/RFC5214, March 2008, 973 . 975 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 976 Version 3 for IPv4 and IPv6", RFC 5798, 977 DOI 10.17487/RFC5798, March 2010, 978 . 980 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 981 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 982 . 984 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 985 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 986 2012, . 988 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 989 Requirements for IPv6 Customer Edge Routers", RFC 7084, 990 DOI 10.17487/RFC7084, November 2013, 991 . 993 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 994 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 995 Boundary in IPv6 Addressing", RFC 7421, 996 DOI 10.17487/RFC7421, January 2015, 997 . 999 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 1000 Support for IP Hosts with Multi-Access Support", RFC 7847, 1001 DOI 10.17487/RFC7847, May 2016, 1002 . 1004 Appendix A. OMNI Option Extensions for Pseudo-DSCP Mappings 1006 Adaptation of the OMNI interface to specific Internetworks such as 1007 the Aeronautical Telecommunications Network with Internet Protocol 1008 Services (ATN/IPS) includes link selection preferences based on 1009 transport port numbers in addition to the existing DSCP-based 1010 preferences. ATN/IPS nodes maintain a map of transport port numbers 1011 to additional "pseudo-DSCP" P[*] preference fields beyond the first 1012 64. For example, TCP port 22 maps to pseudo-DSCP value P67, TCP port 1013 443 maps to P70, UDP port 8060 maps to P76, etc. Figure 4 shows an 1014 example OMNI option with extended P[*] values beyond the base 64 used 1015 for DSCP mapping (i.e., for QoS values 5 or greater): 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Type | Length | Prefix Length |R|N| Reserved | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | ifIndex | ifType | Flags | Link |QoS=5+ | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 |P64|P65|P66|P67|P68|P69|P70|P71|P72|P73|P74|P75|P76|P77|P78|P79| 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 ... 1036 Figure 4: ATN/IPS Extended OMNI Option Format 1038 Appendix B. Prefix Length Considerations 1040 The 64-bit boundary in IPv6 addresses [RFC7421] determines the MN 1041 OMNI LLA format for encoding the most-significant 64 MNP bits into 1042 the least-significant 64 bits of the prefix fe80::/64 as discussed in 1043 Section 7. 1045 [RFC4291] defines the link-local address format as the most 1046 significant 10 bits of the prefix fe80::/10, followed by 54 unused 1047 bits, followed by the least-significant 64 bits of the address. If 1048 the 64-bit boundary is relaxed through future standards activity, 1049 then the 54 unused bits can be employed for extended coding of MNPs 1050 of length /65 up to /118. 1052 The extended coding format would continue to encode MNP bits 0-63 in 1053 bits 64-127 of the OMNI LLA, while including MNP bits 64-117 in bits 1054 10-63. For example, the OMNI LLA corresponding to the MNP 1055 2001:db8:1111:2222:3333:4444:5555::/112 would be 1056 fe8c:ccd1:1115:5540:2001:db8:1111:2222, and would still be a valid 1057 IPv6 LLA per [RFC4291]. 1059 Appendix C. VDL Mode 2 Considerations 1061 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 1062 (VDLM2) that specifies an essential radio frequency data link service 1063 for aircraft and ground stations in worldwide civil aviation air 1064 traffic management. The VDLM2 link type is "multicast capable" 1066 [RFC4861], but with considerable differences from common multicast 1067 links such as Ethernet and IEEE 802.11. 1069 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 1070 magnitude less than most modern wireless networking gear. Second, 1071 due to the low available link bandwidth only VDLM2 ground stations 1072 (i.e., and not aircraft) are permitted to send broadcasts, and even 1073 so only as compact layer 2 "beacons". Third, aircraft employ the 1074 services of ground stations by performing unicast RS/RA exchanges 1075 upon receipt of beacons instead of listening for multicast RA 1076 messages and/or sending multicast RS messages. 1078 This beacon-oriented unicast RS/RA approach is necessary to conserve 1079 the already-scarce available link bandwidth. Moreover, since the 1080 numbers of beaconing ground stations operating within a given spatial 1081 range must be kept as sparse as possible, it would not be feasible to 1082 have different classes of ground stations within the same region 1083 observing different protocols. It is therefore highly desirable that 1084 all ground stations observe a common language of RS/RA as specified 1085 in this document. 1087 Note that links of this nature may benefit from compression 1088 techniques that reduce the bandwidth necessary for conveying the same 1089 amount of data. The IETF lpwan working group is considering possible 1090 alternatives: [https://datatracker.ietf.org/wg/lpwan/documents]. 1092 Appendix D. Change Log 1094 << RFC Editor - remove prior to publication >> 1096 Differences from draft-templin-atn-aero-interface-15 to draft- 1097 templin-atn-aero-interface-16: 1099 o New note on MSE OMNI LLA uniqueness assurance. 1101 o General cleanup. 1103 Differences from draft-templin-atn-aero-interface-14 to draft- 1104 templin-atn-aero-interface-15: 1106 o General cleanup. 1108 Differences from draft-templin-atn-aero-interface-13 to draft- 1109 templin-atn-aero-interface-14: 1111 o General cleanup. 1113 Differences from draft-templin-atn-aero-interface-12 to draft- 1114 templin-atn-aero-interface-13: 1116 o Minor re-work on "Notify-MSE" (changed to Notification ID). 1118 Differences from draft-templin-atn-aero-interface-11 to draft- 1119 templin-atn-aero-interface-12: 1121 o Removed "Request/Response" OMNI option formats. Now, there is 1122 only one OMNI option format that applies to all ND messages. 1124 o Added new OMNI option field and supporting text for "Notify-MSE". 1126 Differences from draft-templin-atn-aero-interface-10 to draft- 1127 templin-atn-aero-interface-11: 1129 o Changed name from "aero" to "OMNI" 1131 o Resolved AD review comments from Eric Vyncke (posted to atn list) 1133 Differences from draft-templin-atn-aero-interface-09 to draft- 1134 templin-atn-aero-interface-10: 1136 o Renamed ARO option to AERO option 1138 o Re-worked Section 13 text to discuss proactive NUD. 1140 Differences from draft-templin-atn-aero-interface-08 to draft- 1141 templin-atn-aero-interface-09: 1143 o Version and reference update 1145 Differences from draft-templin-atn-aero-interface-07 to draft- 1146 templin-atn-aero-interface-08: 1148 o Removed "Classic" and "MS-enabled" link model discussion 1150 o Added new figure for MN/AR/MSE model. 1152 o New Section on "Detecting and responding to MSE failure". 1154 Differences from draft-templin-atn-aero-interface-06 to draft- 1155 templin-atn-aero-interface-07: 1157 o Removed "nonce" field from AR option format. Applications that 1158 require a nonce can include a standard nonce option if they want 1159 to. 1161 o Various editorial cleanups. 1163 Differences from draft-templin-atn-aero-interface-05 to draft- 1164 templin-atn-aero-interface-06: 1166 o New Appendix C on "VDL Mode 2 Considerations" 1168 o New Appendix D on "RS/RA Messaging as a Single Standard API" 1170 o Various significant updates in Section 5, 10 and 12. 1172 Differences from draft-templin-atn-aero-interface-04 to draft- 1173 templin-atn-aero-interface-05: 1175 o Introduced RFC6543 precedent for focusing IPv6 ND messaging to a 1176 reserved unicast link-layer address 1178 o Introduced new IPv6 ND option for Aero Registration 1180 o Specification of MN-to-MSE message exchanges via the ANET access 1181 router as a proxy 1183 o IANA Considerations updated to include registration requests and 1184 set interim RFC4727 option type value. 1186 Differences from draft-templin-atn-aero-interface-03 to draft- 1187 templin-atn-aero-interface-04: 1189 o Removed MNP from aero option format - we already have RIOs and 1190 PIOs, and so do not need another option type to include a Prefix. 1192 o Clarified that the RA message response must include an aero option 1193 to indicate to the MN that the ANET provides a MS. 1195 o MTU interactions with link adaptation clarified. 1197 Differences from draft-templin-atn-aero-interface-02 to draft- 1198 templin-atn-aero-interface-03: 1200 o Sections re-arranged to match RFC4861 structure. 1202 o Multiple aero interfaces 1204 o Conceptual sending algorithm 1206 Differences from draft-templin-atn-aero-interface-01 to draft- 1207 templin-atn-aero-interface-02: 1209 o Removed discussion of encapsulation (out of scope) 1211 o Simplified MTU section 1213 o Changed to use a new IPv6 ND option (the "aero option") instead of 1214 S/TLLAO 1216 o Explained the nature of the interaction between the mobility 1217 management service and the air interface 1219 Differences from draft-templin-atn-aero-interface-00 to draft- 1220 templin-atn-aero-interface-01: 1222 o Updates based on list review comments on IETF 'atn' list from 1223 4/29/2019 through 5/7/2019 (issue tracker established) 1225 o added list of opportunities afforded by the single virtual link 1226 model 1228 o added discussion of encapsulation considerations to Section 6 1230 o noted that DupAddrDetectTransmits is set to 0 1232 o removed discussion of IPv6 ND options for prefix assertions. The 1233 aero address already includes the MNP, and there are many good 1234 reasons for it to continue to do so. Therefore, also including 1235 the MNP in an IPv6 ND option would be redundant. 1237 o Significant re-work of "Router Discovery" section. 1239 o New Appendix B on Prefix Length considerations 1241 First draft version (draft-templin-atn-aero-interface-00): 1243 o Draft based on consensus decision of ICAO Working Group I Mobility 1244 Subgroup March 22, 2019. 1246 Authors' Addresses 1248 Fred L. Templin (editor) 1249 The Boeing Company 1250 P.O. Box 3707 1251 Seattle, WA 98124 1252 USA 1254 Email: fltemplin@acm.org 1255 Tony Whyman 1256 MWA Ltd c/o Inmarsat Global Ltd 1257 99 City Road 1258 London EC1Y 1AX 1259 England 1261 Email: tony.whyman@mccallumwhyman.com