idnits 2.17.1 draft-templin-atn-aero-interface-15.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 (January 31, 2020) is 1541 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 447 -- Looks like a reference, but probably isn't: '2' on line 457 == Missing Reference: 'N' is mentioned on line 469, but not defined == Unused Reference: 'RFC2225' is defined on line 934, 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 3, 2020 MWA Ltd c/o Inmarsat Global Ltd 6 January 31, 2020 8 Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) 9 Interfaces 10 draft-templin-atn-aero-interface-15 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 3, 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 sends native (i.e., unencapsulated) IPv6 ND messages 305 via the underlying ANET interface. IPv6 ND messages traverse the 306 ground domain ANETs until they reach an Access Router (AR#1, AR#2, 307 .., AR#n). The AR then coordinates with a Mobility Service Endpoint 308 (MSE#1, MSE#2, ..., MSE#m) in the INET and returns an IPv6 ND message 309 response to the MN. IPv6 ND messages traverse the ANET at layer 2; 310 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 MN OMNI LLAs encode the most-significant 64 bits of a MNP within 394 the least-significant 64 bits (i.e., the interface ID) of a Link- 395 Local IPv6 Unicast Address (see: [RFC4291], Section 2.5.6). For 396 example, for the MNP 2001:db8:1000:2000::/56 the corresponding LLA 397 is fe80::2001:db8:1000:2000. 399 o IPv4-compatible MN OMNI LLAs are allocated 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 allocated from the range fe80::/96, and MUST be 407 managed for uniqueness by the collective OMNI link administrative 408 authorities. The lower 32 bits of the LLA includes a unique 409 integer value between '1' and 'fffffffe', e.g., as in fe80::1, 410 fe80::2, fe80::3, etc., fe80::ffff:fffe. The address fe80:: is 411 the IPv6 link-local Subnet Router Anycast address [RFC4291] and 412 the address fe80::ffff:ffff is reserved. 414 Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 415 MNPs can be allocated from that block ensuring that there is no 416 possibility for overlap between the above OMNI LLA constructs. 418 Since MN OMNI LLAs are based on the distribution of administratively 419 assured unique MNPs, and since MSE OMNI LLAs are guaranteed unique 420 through administrative assignment, OMNI interfaces set the 421 autoconfiguration variable DupAddrDetectTransmits to 0 [RFC4862]. 423 8. Address Mapping - Unicast 425 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 426 state and use the link-local address format specified in Section 7. 427 IPv6 Neighbor Discovery (ND) [RFC4861] messages on MN OMNI interfaces 428 observe the native Source/Target Link-Layer Address Option (S/TLLAO) 429 formats of the underlying ANET interfaces (e.g., for Ethernet the S/ 430 TLLAO is specified in [RFC2464]). 432 MNs such as aircraft typically have many wireless data link types 433 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 434 etc.) with diverse performance, cost and availability properties. 435 The OMNI interface would therefore appear to have multiple L2 436 connections, and may include information for multiple ANET interfaces 437 in a single IPv6 ND message exchange. 439 OMNI interfaces use an IPv6 ND option called the "OMNI option" 440 formatted as shown in Figure 3: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | Length | Prefix Length |R|N| Reserved | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | ifIndex[1] | ifType[1] | Reserved [1] |Link[1]|QoS[1] | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | ifIndex[2] | ifType[2] | Reserved [2] |Link[2]|QoS[2] | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 ... ... ... 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | ifIndex[N] | ifType[N] | Reserved [N] |Link[N]|QoS[N] | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | zero-padding (if necessary) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Notification ID (present only if N=1) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 3: OMNI Option Format 486 In this format: 488 o Type is set to TBD. 490 o Length is set to the number of 8 octet blocks in the option. 492 o Prefix Length is set according to the IPv6 source LLA type. For 493 MN OMNI LLAs, the value is set to the length of the embedded MNP. 494 For MSE OMNI LLAs, the value is set to 128. 496 o R (the "Register" bit) is set to '1' to assert MNP registration or 497 set to '0' to cancel MNP registration. 499 o N (the "Notify" bit) is set to '1' if the option includes a 500 trailing 4 byte "Notification ID" (see below); set to '0' 501 otherwise. 503 o Reserved is set to the value '0' on transmission and ignored on 504 reception. 506 o A set of N ANET interface "ifIndex-tuples" are included as 507 follows: 509 * ifIndex[i] is set to an 8-bit integer value corresponding to a 510 specific underlying ANET interface. The first ifIndex-tuple 511 MUST correspond to the ANET interface over which the message is 512 sent. IPv6 ND messages originating from a MN may include 513 multiple ifIndex-tuples, and MUST number each ifIndex with a 514 distinct value between '1' and '255' that represents a MN- 515 specific 8-bit mapping for the actual ifIndex value assigned to 516 the ANET interface by network management [RFC2863]. IPv6 ND 517 messages originating from the MS include a single ifIndex-tuple 518 with ifIndex set to the value '0'. 520 * ifType[i] is set to an 8-bit integer value corresponding to the 521 underlying ANET interface identified by ifIndex. The value 522 represents an OMNI interface-specific 8-bit mapping for the 523 actual IANA ifType value registered in the 'IANAifType-MIB' 524 registry [http://www.iana.org]. 526 * Reserved[i] is set to the value '0' on transmission and ignored 527 on reception. 529 * Link[i] encodes a 4-bit link metric. The value '0' means the 530 link is DOWN, and the remaining values mean the link is UP with 531 metric ranging from '1' ("lowest") to '15' ("highest"). 533 * QoS[i] encodes the number of 4-byte blocks (between '0' and 534 '15') of two-bit P[*] values that follow. The first 4 blocks 535 correspond to the 64 Differentiated Service Code Point (DSCP) 536 values P00 - P63 [RFC2474]. If additional 4-byte P[i] blocks 537 follow, their values correspond to "pseudo-DSCP" values P64, 538 P65, P66, etc. numbered consecutively. The pseudo-DSCP values 539 correspond to ancillary QoS information defined for the 540 specific OMNI interface (e.g., see Appendix A). 542 * P[*] includes zero or more per-ifIndex 4-byte blocks of two-bit 543 Preferences. Each P[*] field is set to the value '0' 544 ("disabled"), '1' ("low"), '2' ("medium") or '3' ("high") to 545 indicate a QoS preference level for ANET interface selection 546 purposes. The first four blocks always correspond to the 64 547 DSCP values in consecutive order. If one or more of the blocks 548 are absent (e.g., for QoS values 0,1,2,3) the P[*] values for 549 the missing blocks default to "medium". 551 o Zero-padding added if necessary to produce an integral number of 8 552 octet blocks. 554 o Notification ID (present only if N = '1') contains the least- 555 significant 32 bits of an MSE OMNI LLA to notify. For example, 556 for the LLA fe80::face:cafe the field contains 0xfacecafe. 558 9. Address Mapping - Multicast 560 The multicast address mapping of the native underlying ANET interface 561 applies. The mobile router on board the aircraft also serves as an 562 IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] 563 while using the L2 address of the router as the L2 address for all 564 multicast packets. 566 10. Address Mapping for IPv6 Neighbor Discovery Messages 568 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 569 unicast link-scoped IPv6 destination address. However, IPv6 ND 570 messaging is coordinated between the MN and MS only without invoking 571 other nodes on the ANET. 573 For this reason, ANET links maintain unicast L2 addresses ("MSADDR") 574 for the purpose of supporting MN/MS IPv6 ND messaging. For Ethernet- 575 compatible ANETs, this specification reserves one Ethernet unicast 576 address TBD2. For non-Ethernet statically-addressed ANETs, MSADDR is 577 reserved per the assigned numbers authority for the ANET addressing 578 space. For still other ANETs, MSADDR may be dynamically discovered 579 through other means, e.g., L2 beacons. 581 MNs map the L3 addresses of all IPv6 ND messages they send (i.e., 582 both multicast and unicast) to an MSADDR instead of to an ordinary 583 unicast or multicast L2 address. In this way, all of the MN's IPv6 584 ND messages will be received by MS devices that are configured to 585 accept packets destined to MSADDR. Note that multiple MS devices on 586 the link could be configured to accept packets destined to MSADDR, 587 e.g., as a basis for supporting redundancy. 589 Therefore, ARs MUST accept and process packets destined to MSADDR, 590 while all other devices MUST NOT process packets destined to MSADDR. 591 This model has well-established operational experience in Proxy 592 Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 594 11. Conceptual Sending Algorithm 596 The MN's IPv6 layer selects the outbound OMNI interface according to 597 standard IPv6 requirements when forwarding data packets from local or 598 EUN applications to external correspondents. The OMNI interface 599 maintains default routes and neighbor cache entries for MSEs, and may 600 also include additional neighbor cache entries created through other 601 means (e.g., Address Resolution, static configuration, etc.). 603 After a packet enters the OMNI interface, an outbound ANET interface 604 is selected based on multilink parameters such as DSCP, application 605 port number, cost, performance, message size, etc. OMNI interface 606 multilink selections could also be configured to perform replication 607 across multiple ANET interfaces for increased reliability at the 608 expense of packet duplication. 610 OMNI interface multilink service designers MUST observe the BCP 611 guidance in Section 15 [RFC3819] in terms of implications for 612 reordering when packets from the same flow may be spread across 613 multiple ANET interfaces having diverse properties. 615 11.1. Multiple OMNI Interfaces 617 MNs may associate with multiple MS instances concurrently. Each MS 618 instance represents a distinct OMNI link distinguished by its 619 associated MSPs. The MN configures a separate OMNI interface for 620 each link so that multiple interfaces (e.g., omni0, omni1, omni2, 621 etc.) are exposed to the IPv6 layer. 623 Depending on local policy and configuration, an MN may choose between 624 alternative active OMNI interfaces using a packet's DSCP, routing 625 information or static configuration. Interface selection based on 626 per-packet source addresses is also enabled when the MSPs for each 627 OMNI interface are known (e.g., discovered through Prefix Information 628 Options (PIOs) and/or Route Information Options (RIOs)). 630 Each OMNI interface can be configured over the same or different sets 631 of ANET interfaces. Each ANET distinguishes between the different 632 OMNI links based on the MSPs represented in per-packet IPv6 633 addresses. 635 Multiple distinct OMNI links can therefore be used to support fault 636 tolerance, load balancing, reliability, etc. The architectural model 637 parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs 638 serve as (virtual) VLAN tags. 640 12. Router Discovery and Prefix Registration 642 ARs process IPv6 ND messages destined to all-routers multicast 643 (ff02::2), the subnet router anycast LLA (fe80::) and unicast IPv6 644 LLAs. ARs configure the L2 address MSADDR (see: Section 10) and act 645 as a proxy for MSE OMNI LLAs. 647 MNs interface with the MS by sending RS messages with OMNI options. 648 For each ANET interface, the MN sends an RS message with an OMNI 649 option, with L2 destination address set to MSADDR and with L3 650 destination address set to either a specific MSE OMNI LLA, subnet 651 router anycast LLA, or all-routers multicast. The MN discovers MSE 652 OMNI LLAs either through an RA message response to an initial 653 anycast/multicast RS or before sending an initial RS message. 654 [RFC5214] provides example MSE address discovery methods, including 655 information conveyed during data link login, name service lookups, 656 static configuration, etc. 658 The AR receives the RS messages and coordinates with the 659 corresponding MSE in a manner outside the scope of this document. 660 The AR returns an RA message with source address set to the MSE OMNI 661 LLA, with an OMNI option and with any information for the link that 662 would normally be delivered in a solicited RA message. (Note that if 663 all MSEs share common state, the AR can instead return an RA with 664 source address set to the subnet router anycast LLA.) 666 MNs configure OMNI interfaces that observe the properties discussed 667 in the previous section. The OMNI interface and its underlying 668 interfaces are said to be in either the "UP" or "DOWN" state 669 according to administrative actions in conjunction with the interface 670 connectivity status. An OMNI interface transitions to UP or DOWN 671 through administrative action and/or through state transitions of the 672 underlying interfaces. When a first underlying interface transitions 673 to UP, the OMNI interface also transitions to UP. When all 674 underlying interfaces transition to DOWN, the OMNI interface also 675 transitions to DOWN. 677 When an OMNI interface transitions to UP, the MN sends initial RS 678 messages to register its MNP and an initial set of underlying ANET 679 interfaces that are also UP. The MN sends additional RS messages to 680 refresh lifetimes and to register/deregister underlying ANET 681 interfaces as they transition to UP or DOWN. 683 ARs return RA messages with configuration information in response to 684 a MN's RS messages. The RAs include a Router Lifetime value and any 685 necessary options, such as: 687 o PIOs with (A; L=0) that include MSPs for the link [RFC8028]. 689 o RIOs [RFC4191] with more-specific routes. 691 o an MTU option that specifies the maximum acceptable packet size 692 for the OMNI link 694 The AR coordinates with the MSE and sends immediate unicast RA 695 responses without delay; therefore, the IPv6 ND MAX_RA_DELAY_TIME and 696 MIN_DELAY_BETWEEN_RAS constants for multicast RAs do not apply. The 697 AR MAY send periodic and/or event-driven unsolicited RA messages, but 698 is not required to do so for unicast advertisements [RFC4861]. 700 The MN sends RS messages from within the OMNI interface while using 701 an UP underlying ANET interface as the outbound interface. Each RS 702 message is formatted as though it originated from the IPv6 layer, but 703 the process is coordinated wholly from within the OMNI interface and 704 is therefore opaque to the IPv6 layer. The MN sends initial RS 705 messages over an UP underlying interface with its OMNI LLA as the 706 source. The RS messages include an OMNI option with a valid Prefix 707 Length as well as ifIndex-tuples appropriate for underlying ANET 708 interfaces. The AR processes RS message and conveys the OMNI option 709 information to the MSE. 711 When the MSE processes the OMNI information, it first validates the 712 prefix registration information. If the prefix registration was 713 valid, the MSE injects the MNP into the routing/mapping system then 714 caches the new Prefix Length, MNP and ifIndex-tuples. The MSE then 715 directs the AR to return an RA message to the MN with an OMNI option 716 and with a non-zero Router Lifetime if the prefix registration was 717 successful; otherwise, with a zero Router Lifetime. If the MN's OMNI 718 option included a Notification ID, the new MSE also notifies the 719 former MSE. 721 When the MN receives the RA message, it creates a default route with 722 L3 next hop address set to the address found in the RA source address 723 and with L2 address set to MSADDR. The AR will then forward packets 724 between the MN and the MS. 726 The MN then manages its underlying ANET interfaces according to their 727 states as follows: 729 o When an underlying ANET interface transitions to UP, the MN sends 730 an RS over the ANET interface with an OMNI option. The OMNI 731 option contains a first ifIndex-tuple with values specific to this 732 ANET interface, and may contain additional ifIndex-tuples specific 733 to other ANET interfaces. 735 o When an underlying ANET interface transitions to DOWN, the MN 736 sends an RS or unsolicited NA message over any UP ANET interface 737 with an OMNI option containing an ifIndex-tuple for the DOWN ANET 738 interface with Link(i) set to '0'. The MN sends an RS when an 739 acknowledgement is required, or an unsolicited NA when reliability 740 is not thought to be a concern (e.g., if redundant transmissions 741 are sent on multiple ANET interfaces). 743 o When a MN wishes to release from a current MSE, it sends an RS or 744 unsolicited NA message over any UP ANET interfaces with an OMNI 745 option with R set to 0. The corresponding MSE then withdraws the 746 MNP from the routing/mapping system and (for RS responses) returns 747 an RA message with an OMNI option and with Router Lifetime set to 748 0. 750 o When a MN wishes to transition to a new MSE, it sends an RS or 751 unsolicited NA message over any UP ANET interfaces with an OMNI 752 option with R set to 1, with the new MSE OMNI LLA set in the 753 destination address, and (optionally) with N set to 1 and a 754 Notification ID included for the former MSE. 756 o When all of a MNs underlying interfaces have transitioned to DOWN 757 (or if no further MN RS messages are received before Router 758 Lifetime expires) the MSE withdraws the MNP the same as if it had 759 received a message with an OMNI option with R set to 0. 761 The MN is responsible for retrying each RS exchange up to 762 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 763 seconds until an RA is received. If no RA is received over multiple 764 UP ANET interfaces, the MN declares this MSE unreachable and tries a 765 different MSE. 767 The IPv6 layer sees the OMNI interface as an ordinary IPv6 interface. 768 Therefore, when the IPv6 layer sends an RS message the OMNI interface 769 returns an internally-generated RA message as though the message 770 originated from an IPv6 router. The internally-generated RA message 771 contains configuration information (such as Router Lifetime, MTU, 772 etc.) that is consistent with the information received from the RAs 773 generated by the MS. 775 Whether the OMNI interface IPv6 ND messaging process is initiated 776 from the receipt of an RS message from the IPv6 layer is an 777 implementation matter. Some implementations may elect to defer the 778 IPv6 ND messaging process until an RS is received from the IPv6 779 layer, while others may elect to initiate the process proactively. 781 13. AR and MSE Resilience 783 ANETs SHOULD deploy ARs in Virtual Router Redundancy Protocol (VRRP) 784 [RFC5798] configurations so that service continuity is maintained 785 even if one or more ARs fail. Using VRRP, the MN is unaware which of 786 the (redundant) ARs is currently providing service, and any service 787 discontinuity will be limited to the failover time supported by VRRP. 788 Widely deployed public domain implementations of VRRP are available. 790 MSEs SHOULD use high availability clustering services so that 791 multiple redundant systems can provide coordinated response to 792 failures. As with VRRP, widely deployed public domain 793 implementations of high availability clustering services are 794 available. Note that special-purpose and expensive dedicated 795 hardware is not necessary, and public domain implementations can be 796 used even between lightweight virtual machines in cloud deployments. 798 14. Detecting and Responding to MSE Failures 800 In environments where fast recovery from MSE failure is required, ARs 801 SHOULD use proactive Neighbor Unreachability Detection (NUD) in a 802 manner that parallels Bidirectional Forwarding Detection (BFD) 803 [RFC5880] to track MSE reachability. ARs can then quickly detect and 804 react to failures so that cached information is re-established 805 through alternate paths. Proactive NUD control messaging is carried 806 only over well-connected ground domain networks (i.e., and not low- 807 end aeronautical radio links) and can therefore be tuned for rapid 808 response. 810 ARs perform proactive NUD for MSEs for which there are currently 811 active ANET MNs. If an MSE fails, ARs can quickly inform MNs of the 812 outage by sending RA messages on the ANET interface. The AR sends RA 813 messages to the MN via the ANET interface with source address set to 814 the MSEs OMNI LLA, destination address set to all-nodes multicast, 815 and Router Lifetime set to 0. 817 The AR SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated 818 by small delays [RFC4861]. Any MNs on the ANET interface that have 819 been using the (now defunct) MSE will receive the RA messages and 820 associate with a new MSE. 822 15. IANA Considerations 824 The IANA is instructed to allocate an official Type number TBD from 825 the registry "IPv6 Neighbor Discovery Option Formats" for the OMNI 826 option. Implementations set Type to 253 as an interim value 827 [RFC4727]. 829 The IANA is instructed to allocate one Ethernet unicast address TBD2 830 (suggest 00-00-5E-00-52-14 [RFC5214]) in the registry "IANA Ethernet 831 Address Block - Unicast Use". 833 16. Security Considerations 835 Security considerations for IPv6 [RFC8200] and IPv6 Neighbor 836 Discovery [RFC4861] apply. OMNI interface IPv6 ND messages SHOULD 837 include Nonce and Timestamp options [RFC3971] when synchronized 838 transaction confirmation is needed. 840 Security considerations for specific access network interface types 841 are covered under the corresponding IP-over-(foo) specification 842 (e.g., [RFC2464]). 844 17. Acknowledgements 846 The first version of this document was prepared per the consensus 847 decision at the 7th Conference of the International Civil Aviation 848 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 849 2019. Consensus to take the document forward to the IETF was reached 850 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 851 Attendees and contributors included: Guray Acar, Danny Bharj, 852 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 853 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 854 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 855 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 856 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 857 Fryderyk Wrobel and Dongsong Zeng. 859 The following individuals are acknowledged for their useful comments: 860 Pavel Drasil, Zdenek Jaron, Michael Matyas, Madhu Niraula, Greg 861 Saccone, Stephane Tamalet, Eric Vyncke. Naming of the IPv6 ND option 862 was discussed on the 6man mailing list. 864 This work is aligned with the NASA Safe Autonomous Systems Operation 865 (SASO) program under NASA contract number NNA16BD84C. 867 This work is aligned with the FAA as per the SE2025 contract number 868 DTFAWA-15-D-00030. 870 18. References 872 18.1. Normative References 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, 876 DOI 10.17487/RFC2119, March 1997, 877 . 879 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 880 "Definition of the Differentiated Services Field (DS 881 Field) in the IPv4 and IPv6 Headers", RFC 2474, 882 DOI 10.17487/RFC2474, December 1998, 883 . 885 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 886 "SEcure Neighbor Discovery (SEND)", RFC 3971, 887 DOI 10.17487/RFC3971, March 2005, 888 . 890 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 891 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 892 November 2005, . 894 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 895 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 896 2006, . 898 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 899 ICMPv6, UDP, and TCP Headers", RFC 4727, 900 DOI 10.17487/RFC4727, November 2006, 901 . 903 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 904 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 905 DOI 10.17487/RFC4861, September 2007, 906 . 908 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 909 Address Autoconfiguration", RFC 4862, 910 DOI 10.17487/RFC4862, September 2007, 911 . 913 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 914 Hosts in a Multi-Prefix Network", RFC 8028, 915 DOI 10.17487/RFC8028, November 2016, 916 . 918 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 919 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 920 May 2017, . 922 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 923 (IPv6) Specification", STD 86, RFC 8200, 924 DOI 10.17487/RFC8200, July 2017, 925 . 927 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 928 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 929 DOI 10.17487/RFC8201, July 2017, 930 . 932 18.2. Informative References 934 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 935 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 936 . 938 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 939 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 940 . 942 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 943 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 944 December 1998, . 946 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 947 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 948 . 950 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 951 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 952 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 953 RFC 3819, DOI 10.17487/RFC3819, July 2004, 954 . 956 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 957 "Internet Group Management Protocol (IGMP) / Multicast 958 Listener Discovery (MLD)-Based Multicast Forwarding 959 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 960 August 2006, . 962 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 963 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 964 RFC 5213, DOI 10.17487/RFC5213, August 2008, 965 . 967 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 968 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 969 DOI 10.17487/RFC5214, March 2008, 970 . 972 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 973 Version 3 for IPv4 and IPv6", RFC 5798, 974 DOI 10.17487/RFC5798, March 2010, 975 . 977 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 978 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 979 . 981 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 982 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 983 2012, . 985 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 986 Requirements for IPv6 Customer Edge Routers", RFC 7084, 987 DOI 10.17487/RFC7084, November 2013, 988 . 990 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 991 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 992 Boundary in IPv6 Addressing", RFC 7421, 993 DOI 10.17487/RFC7421, January 2015, 994 . 996 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 997 Support for IP Hosts with Multi-Access Support", RFC 7847, 998 DOI 10.17487/RFC7847, May 2016, 999 . 1001 Appendix A. OMNI Option Extensions for Pseudo-DSCP Mappings 1003 Adaptation of the OMNI interface to specific Internetworks such as 1004 the Aeronautical Telecommunications Network with Internet Protocol 1005 Services (ATN/IPS) includes link selection preferences based on 1006 transport port numbers in addition to the existing DSCP-based 1007 preferences. ATN/IPS nodes maintain a map of transport port numbers 1008 to additional "pseudo-DSCP" P[*] preference fields beyond the first 1009 64. For example, TCP port 22 maps to pseudo-DSCP value P67, TCP port 1010 443 maps to P70, UDP port 8060 maps to P76, etc. Figure 4 shows an 1011 example OMNI option with extended P[*] values beyond the base 64 used 1012 for DSCP mapping (i.e., for QoS values 5 or greater): 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Type | Length | Prefix Length |R|N| Reserved | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | ifIndex | ifType | Flags | Link |QoS=5+ | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 |P64|P65|P66|P67|P68|P69|P70|P71|P72|P73|P74|P75|P76|P77|P78|P79| 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 ... 1033 Figure 4: ATN/IPS Extended OMNI Option Format 1035 Appendix B. Prefix Length Considerations 1037 The 64-bit boundary in IPv6 addresses [RFC7421] determines the MN 1038 OMNI LLA format for encoding the most-significant 64 MNP bits into 1039 the least-significant 64 bits of the prefix fe80::/64 as discussed in 1040 Section 7. 1042 [RFC4291] defines the link-local address format as the most 1043 significant 10 bits of the prefix fe80::/10, followed by 54 unused 1044 bits, followed by the least-significant 64 bits of the address. If 1045 the 64-bit boundary is relaxed through future standards activity, 1046 then the 54 unused bits can be employed for extended coding of MNPs 1047 of length /65 up to /118. 1049 The extended coding format would continue to encode MNP bits 0-63 in 1050 bits 64-127 of the OMNI LLA, while including MNP bits 64-117 in bits 1051 10-63. For example, the OMNI LLA corresponding to the MNP 1052 2001:db8:1111:2222:3333:4444:5555::/112 would be 1053 fe8c:ccd1:1115:5540:2001:db8:1111:2222, and would still be a valid 1054 IPv6 LLA per [RFC4291]. 1056 Appendix C. VDL Mode 2 Considerations 1058 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 1059 (VDLM2) that specifies an essential radio frequency data link service 1060 for aircraft and ground stations in worldwide civil aviation air 1061 traffic management. The VDLM2 link type is "multicast capable" 1063 [RFC4861], but with considerable differences from common multicast 1064 links such as Ethernet and IEEE 802.11. 1066 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 1067 magnitude less than most modern wireless networking gear. Second, 1068 due to the low available link bandwidth only VDLM2 ground stations 1069 (i.e., and not aircraft) are permitted to send broadcasts, and even 1070 so only as compact layer 2 "beacons". Third, aircraft employ the 1071 services of ground stations by performing unicast RS/RA exchanges 1072 upon receipt of beacons instead of listening for multicast RA 1073 messages and/or sending multicast RS messages. 1075 This beacon-oriented unicast RS/RA approach is necessary to conserve 1076 the already-scarce available link bandwidth. Moreover, since the 1077 numbers of beaconing ground stations operating within a given spatial 1078 range must be kept as sparse as possible, it would not be feasible to 1079 have different classes of ground stations within the same region 1080 observing different protocols. It is therefore highly desirable that 1081 all ground stations observe a common language of RS/RA as specified 1082 in this document. 1084 Note that links of this nature may benefit from compression 1085 techniques that reduce the bandwidth necessary for conveying the same 1086 amount of data. The IETF lpwan working group is considering possible 1087 alternatives: [https://datatracker.ietf.org/wg/lpwan/documents]. 1089 Appendix D. Change Log 1091 << RFC Editor - remove prior to publication >> 1093 Differences from draft-templin-atn-aero-interface-14 to draft- 1094 templin-atn-aero-interface-15: 1096 o General cleanup. 1098 Differences from draft-templin-atn-aero-interface-13 to draft- 1099 templin-atn-aero-interface-14: 1101 o General cleanup. 1103 Differences from draft-templin-atn-aero-interface-12 to draft- 1104 templin-atn-aero-interface-13: 1106 o Minor re-work on "Notify-MSE" (changed to Notification ID). 1108 Differences from draft-templin-atn-aero-interface-11 to draft- 1109 templin-atn-aero-interface-12: 1111 o Removed "Request/Response" OMNI option formats. Now, there is 1112 only one OMNI option format that applies to all ND messages. 1114 o Added new OMNI option field and supporting text for "Notify-MSE". 1116 Differences from draft-templin-atn-aero-interface-10 to draft- 1117 templin-atn-aero-interface-11: 1119 o Changed name from "aero" to "OMNI" 1121 o Resolved AD review comments from Eric Vyncke (posted to atn list) 1123 Differences from draft-templin-atn-aero-interface-09 to draft- 1124 templin-atn-aero-interface-10: 1126 o Renamed ARO option to AERO option 1128 o Re-worked Section 13 text to discuss proactive NUD. 1130 Differences from draft-templin-atn-aero-interface-08 to draft- 1131 templin-atn-aero-interface-09: 1133 o Version and reference update 1135 Differences from draft-templin-atn-aero-interface-07 to draft- 1136 templin-atn-aero-interface-08: 1138 o Removed "Classic" and "MS-enabled" link model discussion 1140 o Added new figure for MN/AR/MSE model. 1142 o New Section on "Detecting and responding to MSE failure". 1144 Differences from draft-templin-atn-aero-interface-06 to draft- 1145 templin-atn-aero-interface-07: 1147 o Removed "nonce" field from AR option format. Applications that 1148 require a nonce can include a standard nonce option if they want 1149 to. 1151 o Various editorial cleanups. 1153 Differences from draft-templin-atn-aero-interface-05 to draft- 1154 templin-atn-aero-interface-06: 1156 o New Appendix C on "VDL Mode 2 Considerations" 1158 o New Appendix D on "RS/RA Messaging as a Single Standard API" 1159 o Various significant updates in Section 5, 10 and 12. 1161 Differences from draft-templin-atn-aero-interface-04 to draft- 1162 templin-atn-aero-interface-05: 1164 o Introduced RFC6543 precedent for focusing IPv6 ND messaging to a 1165 reserved unicast link-layer address 1167 o Introduced new IPv6 ND option for Aero Registration 1169 o Specification of MN-to-MSE message exchanges via the ANET access 1170 router as a proxy 1172 o IANA Considerations updated to include registration requests and 1173 set interim RFC4727 option type value. 1175 Differences from draft-templin-atn-aero-interface-03 to draft- 1176 templin-atn-aero-interface-04: 1178 o Removed MNP from aero option format - we already have RIOs and 1179 PIOs, and so do not need another option type to include a Prefix. 1181 o Clarified that the RA message response must include an aero option 1182 to indicate to the MN that the ANET provides a MS. 1184 o MTU interactions with link adaptation clarified. 1186 Differences from draft-templin-atn-aero-interface-02 to draft- 1187 templin-atn-aero-interface-03: 1189 o Sections re-arranged to match RFC4861 structure. 1191 o Multiple aero interfaces 1193 o Conceptual sending algorithm 1195 Differences from draft-templin-atn-aero-interface-01 to draft- 1196 templin-atn-aero-interface-02: 1198 o Removed discussion of encapsulation (out of scope) 1200 o Simplified MTU section 1202 o Changed to use a new IPv6 ND option (the "aero option") instead of 1203 S/TLLAO 1205 o Explained the nature of the interaction between the mobility 1206 management service and the air interface 1208 Differences from draft-templin-atn-aero-interface-00 to draft- 1209 templin-atn-aero-interface-01: 1211 o Updates based on list review comments on IETF 'atn' list from 1212 4/29/2019 through 5/7/2019 (issue tracker established) 1214 o added list of opportunities afforded by the single virtual link 1215 model 1217 o added discussion of encapsulation considerations to Section 6 1219 o noted that DupAddrDetectTransmits is set to 0 1221 o removed discussion of IPv6 ND options for prefix assertions. The 1222 aero address already includes the MNP, and there are many good 1223 reasons for it to continue to do so. Therefore, also including 1224 the MNP in an IPv6 ND option would be redundant. 1226 o Significant re-work of "Router Discovery" section. 1228 o New Appendix B on Prefix Length considerations 1230 First draft version (draft-templin-atn-aero-interface-00): 1232 o Draft based on consensus decision of ICAO Working Group I Mobility 1233 Subgroup March 22, 2019. 1235 Authors' Addresses 1237 Fred L. Templin (editor) 1238 The Boeing Company 1239 P.O. Box 3707 1240 Seattle, WA 98124 1241 USA 1243 Email: fltemplin@acm.org 1245 Tony Whyman 1246 MWA Ltd c/o Inmarsat Global Ltd 1247 99 City Road 1248 London EC1Y 1AX 1249 England 1251 Email: tony.whyman@mccallumwhyman.com