idnits 2.17.1 draft-templin-atn-aero-interface-06.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 (August 21, 2019) is 1709 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 887 -- Looks like a reference, but probably isn't: '2' on line 380 == Missing Reference: 'N' is mentioned on line 392, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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 Boeing Research & Technology 4 Intended status: Standards Track A. Whyman 5 Expires: February 22, 2020 MWA Ltd c/o Inmarsat Global Ltd 6 August 21, 2019 8 Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces 9 draft-templin-atn-aero-interface-06.txt 11 Abstract 13 Mobile nodes (e.g., aircraft of various configurations) communicate 14 with networked correspondents over multiple access network data links 15 and configure mobile routers to connect their on-board networks. 16 Mobile nodes connect to access networks using either the classic or 17 mobility service-enabled link model. This document specifies the 18 transmission of IPv6 packets over aeronautical ("aero") interfaces. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 22, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Aeronautical ("aero") Interface Model . . . . . . . . . . . . 4 58 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 6 59 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 6 61 8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 8 62 9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 11 63 10. Address Mapping for IPv6 Neighbor Discovery Messages . . . . 11 64 11. Conceptual Sending Algorithm . . . . . . . . . . . . . . . . 12 65 11.1. Multiple Aero Interfaces . . . . . . . . . . . . . . . . 12 66 12. Router Discovery and Prefix Registration . . . . . . . . . . 13 67 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 70 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 16.1. Normative References . . . . . . . . . . . . . . . . . . 17 72 16.2. Informative References . . . . . . . . . . . . . . . . . 18 73 Appendix A. Aero Registration Option Extensions for Special- 74 Purpose Links . . . . . . . . . . . . . . . . . . . 19 75 Appendix B. Prefix Length Considerations . . . . . . . . . . . . 20 76 Appendix C. VDL Mode 2 Considerations . . . . . . . . . . . . . 20 77 Appendix D. RS/RA Messaging as the Single Standard API . . . . . 22 78 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 22 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 81 1. Introduction 83 Mobile Nodes (MNs) such as aircraft of various configurations may 84 have multiple data links for communicating with networked 85 correspondents. These data links often have differing performance, 86 cost and availability characteristics that can change dynamically 87 according to mobility patterns, flight phases, proximity to 88 infrastructure, etc. 90 Each MN receives an IPv6 Mobile Network Prefix (MNP) that can be used 91 by on-board networks independently of the access network data links 92 selected for data transport. The MN performs router discovery the 93 same as for customer edge routers [RFC7084], and acts as a mobile 94 router on behalf of its on-board networks. The MN connects to access 95 networks using either the classic [RFC4861] or Mobility Service (MS)- 96 enabled link model. 98 In the classic model, all IPv6 Neighbor Discovery (IPv6 ND) messaging 99 is directly over native access network interfaces managed according 100 to the weak end system model. The MN discovers neighbors on the link 101 through link-scoped multicast and/or unicast transmissions that map 102 to their corresponding link layer addresses per standard address 103 resolution / mapping procedures. The MN then coordinates with 104 mobility agents located in the larger Internetwork beyond the first- 105 hop access links by employing an on-board mobility function. This 106 arrangement requires the MN to engage in active mobility messaging on 107 its own behalf and with no assistance from the access network. 109 In the MS-enabled model, a virtual interface (termed the "aero 110 interface") is configured as a thin layer over the underlying access 111 network interfaces. The aero interface is therefore the only 112 interface abstraction exposed to the IPv6 layer and behaves according 113 to the Non-Broadcast, Multiple Access (NBMA) interface principle, 114 while underlying access network interfaces appear as link layer 115 communication channels in the architecture. The aero interface 116 connects to a virtual overlay cloud service known as the "aero link". 118 Each aero link has one or more associated Mobility Service Prefixes 119 (MSPs) that identify the link. An MSP is an aggregated IPv6 prefix 120 from which aero link MNPs are derived. If the MN connects to 121 multiple aero links, then it configures a separate aero interface for 122 each link. 124 The aero interface interacts with the ground-domain MS through IPv6 125 ND control message exchanges [RFC4861]. The MS tracks MN movements 126 and represents their MNPs in a global routing or mapping system. 128 The aero interface provides a traffic engineering nexus for guiding 129 inbound and outbound traffic to the correct underlying interface(s). 130 The IPv6 layer sees the aero interface as a point of connection to 131 the aero link; if there are multiple aero links (i.e., multiple 132 MS's), the IPv6 layer will see multiple aero interfaces. 134 This document specifies the transmission of IPv6 packets [RFC8200] 135 and MN/MS control messaging over aeronautical ("aero") interfaces in 136 the MS-enabled link model, and also includes all necessary details 137 for MN operation in the classic link model. 139 2. Terminology 141 The terminology in the normative references applies; especially, the 142 terms "link" and "interface" are the same as defined in the IPv6 143 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 145 The following terms are defined within the scope of this document: 147 Access Network (ANET) 148 a data link service network (e.g., an aviation radio access 149 network, satellite service provider network, cellular operator 150 network, etc.) protected by physical and/or link layer security. 151 Each ANET connects to outside Internetworks via border security 152 devices such as proxys, firewalls, packet filtering gateways, etc. 154 ANET interface 155 a node's attachment to a link in an ANET. 157 Internetwork (INET) 158 a connected network region with a coherent IP addressing plan that 159 provides transit forwarding services for ANET mobile nodes and 160 INET correspondents. Examples include private enterprise 161 networks, aviation networks and the global public Internet itself. 163 INET interface 164 a node's attachment to a link in an INET. 166 aero link 167 a virtual overlay cloud service configured over one or more INETs 168 and their connected ANETs. An aero link may comprise multiple 169 segments joined by bridges the same as for any link; the 170 addressing plans in each segment may be mutually exclusive and 171 managed by different administrative entities. 173 aero interface 174 a node's attachment to an aero link, and configured over one or 175 more underlying ANET/INET interfaces. 177 aero address 178 an IPv6 link-local address constructed as specified in Section 7, 179 and assigned to an aero interface. 181 3. Requirements 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. Lower case 186 uses of these words are not to be interpreted as carrying RFC2119 187 significance. 189 4. Aeronautical ("aero") Interface Model 191 An aero interface is a MN virtual interface configured over one or 192 more ANET interfaces, which may be physical (e.g., an aeronautical 193 radio link) or virtual (e.g., an Internet or higher-layer "tunnel"). 194 The MN coordinates with the MS through IPv6 ND message exchanges. 196 The aero interface architectural layering model is the same as in 197 [RFC7847], and augmented as shown in Figure 1. The IPv6 layer 198 therefore sees the aero interface as a single network layer interface 199 with multiple underlying ANET interfaces that appear as link layer 200 communication channels in the architecture. 202 +----------------------------+ 203 | TCP/UDP | 204 Session-to-IP +---->| | 205 Address Binding | +----------------------------+ 206 +---->| IPv6 | 207 IP Address +---->| | 208 Binding | +----------------------------+ 209 +---->| aero Interface | 210 Logical-to- +---->| (aero address) | 211 Physical | +----------------------------+ 212 Interface +---->| L2 | L2 | | L2 | 213 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 214 +------+------+ +------+ 215 | L1 | L1 | | L1 | 216 | | | | | 217 +------+------+ +------+ 219 Figure 1: Aero Interface Architectural Layering Model 221 The aero virtual interface model gives rise to a number of 222 opportunities: 224 o since aero interface link-local addresses are uniquely derived 225 from an MNP (see: Section 7, no Duplicate Address Detection (DAD) 226 messaging is necessary over the aero interface. 228 o ANET interfaces can remain unnumbered in environments where 229 communications are coordinated entirely over the aero interface. 231 o as ANET interface properties change (e.g., link quality, cost, 232 availability, etc.), any active ANET interface can be used to 233 update the profiles of multiple additional ANET interfaces in a 234 single message. This allows for timely adaptation and service 235 continuity under dynamically changing conditions. 237 o coordinating ANET interfaces in this way allows them to be 238 represented in a unified MS profile with provisions for mobility 239 and multilink operations. 241 o exposing a single virtual interface abstraction to the IPv6 layer 242 allows for traffic engineering (including QoS based link 243 selection, packet replication, load balancing, etc.) at the link 244 layer while still permitting queuing at the IPv6 layer based on, 245 e.g., traffic class, flow label, etc. 247 o the IPv6 layer sees the aero interface as a point of connection to 248 the aero link; if there are multiple aero links (i.e., multiple 249 MS's), the IPv6 layer will see multiple aero interfaces. 251 Other opportunities are discussed in [RFC7847]. 253 5. Maximum Transmission Unit 255 All IPv6 interfaces MUST configure an MTU of at least 1280 bytes 256 [RFC8200], while the aero interface configures an MTU based on the 257 largest MTU among all underlying ANET interfaces. 259 The aero interface returns internally-generated IPv6 Path MTU 260 Discovery (PMTUD) Packet Too Big (PTB) messages [RFC8201] for packets 261 admitted into the aero interface that are too large for the outbound 262 underlying ANET interface. Similarly, the aero interface performs 263 PMTUD even if the destination appears to be on the same link since a 264 proxy on the path could return a PTB message. PMTUD therefore 265 ensures that the aero interface MTU is adaptive and reflects the 266 current path used for a given data flow. 268 Applications that cannot tolerate loss due to MTU restrictions should 269 refrain from sending packets larger than 1280 bytes, since dynamic 270 path changes can reduce the path MTU at any time. 272 6. Frame Format 274 The aero interface transmits IPv6 packets according to the native 275 frame format of each underlying ANET interface. For example, for 276 Ethernet-compatible interfaces the frame format is specified in 277 [RFC2464], for aeronautical radio interfaces the frame format is 278 specified in standards such as ICAO Doc 9776 (VDL Mode 2 Technical 279 Manual), for tunnels over IPv6 the frame format is exactly as 280 specified in [RFC2473], etc. 282 7. Link-Local Addresses 284 A MN "aero address" is an IPv6 link-local address with an interface 285 identifier based on its assigned MNP. MN aero addresses begin with 286 the prefix fe80::/64 followed by a 64-bit prefix taken from the MNP 287 (see: Appendix B). For example, for the MNP: 289 2001:db8:1000:2000::/56 291 the corresponding aero addresses are: 293 fe80::2001:db8:1000:2000 295 fe80::2001:db8:1000:2001 297 fe80::2001:db8:1000:2002 299 ... etc. ... 301 fe80::2001:db8:1000:20ff 303 When the MN configures aero addresses from its MNP, it assigns them 304 to each ANET interface (and also to the aero interface in the MS- 305 enabled model). The lowest-numbered aero address serves as the 306 "base" address (for example, for the MNP 2001:db8:1000:2000::/56 the 307 base aero address is fe80::2001:db8:1000:2000). The MN uses the base 308 aero address for IPv6 ND messaging, but accepts packets destined to 309 all aero addresses equally (i.e., the same as for any multi-addressed 310 IPv6 interface). 312 In the MS-enabled link model, MS endpoint (MSE) aero addresses are 313 allocated from the range fe80::/96, and MUST be managed for 314 uniqueness by the collective aero link administrative authorities. 315 The lower 32 bits of the address includes a unique integer value, 316 e.g., fe80::1, fe80::2, fe80::3, etc. The address fe80::ffff:ffff is 317 reserved and the address fe80:: is the IPv6 link-local Subnet Router 318 Anycast address [RFC4291]; hence, these values are not available for 319 general assignment. 321 In the classic link model, ANET link devices number their interfaces 322 from the range fe80::/96 the same as above except that these 323 addresses need not be managed for uniqueness outside of the local 324 ANET link. It is therefore possible that different ANET links could 325 reuse numbers from the fe80::/96 space since the addresses are link- 326 scope only. 328 In a mixed model, both the classic and MS-enabled numbering schemes 329 can be used without conflict within the same ANET, as the two 330 services would be conducted as ships in the night. A mix of MNs 331 operating according to classic and MS-enabled models could then 332 operate within the same ANETs without interference. 334 Since MN aero addresses are guaranteed unique by the nature of the 335 unique MNP delegation, aero interfaces set the autoconfiguration 336 variable DupAddrDetectTransmits to 0 [RFC4862]. 338 8. Address Mapping - Unicast 340 Aero interfaces maintain a neighbor cache for tracking per-neighbor 341 state the same as for any IPv6 interface and use the link-local 342 address format specified in Section 7. IPv6 Neighbor Discovery (ND) 343 [RFC4861] messages on aero interfaces use the native Source/Target 344 Link-Layer Address Option (S/TLLAO) formats of the underlying ANET 345 interfaces (e.g., for Ethernet the S/TLLAO is specified in 346 [RFC2464]). 348 MNs such as aircraft typically have many wireless data link types 349 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 350 etc.) with diverse performance, cost and availability properties. 351 The aero interface would therefore appear to have multiple link layer 352 connections, and may include information for multiple ANET interfaces 353 in a single message exchange. 355 Aero interfaces use a new IPv6 ND options called the "Aero 356 Registration (AR)" option. MNs that wish to invoke the MS include 357 the AR option in Router Solicitation (RS) and/or unsolicited Neighbor 358 Advertisement (uNA) messages to request registration/deregistration, 359 and the MS includes the AR option in Router Advertisement (RA) 360 messages to acknowledge the MN's registration/deregistration. 362 AR options in a MN's RS/uNA messages are formatted as shown in 363 Figure 2: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Length | Prefix Length |R| Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Nonce | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | ifIndex [1] |P00|P01|P02|P03|P04|P05|P06|P07| 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19|P20|P21|P22|P23| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |P24|P25|P26|P27|P28|P29|P30|P31|P32|P33|P34|P35|P36|P37|P38|P39| 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |P40|P41|P42|P43|P44|P45|P46|P47|P48|P49|P50|P51|P52|P53|P54|P55| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |P56|P57|P58|P59|P60|P61|P62|P63| ifIndex [2] | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 ... 391 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 ... | ifIndex [N] | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Trailing zero padding (0 - 6 octets) | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 2: Aero Registration (AR) Option Format in RS/uNA Messages 407 In this format: 409 o Type is set to TBD. 411 o Length is set to the number of 8 octet blocks in the option (with 412 trailing zero padding added if necessary to produce an integral 413 number of 8 octet blocks). 415 o Prefix Length is set to the length of the MNP embedded in the MN's 416 aero address. 418 o R (the "Register" bit) is set to '1' to sustain the MNP 419 registration or set to '0' to request de-registration. 421 o Reserved is set to the value '0' on transmission. 423 o Nonce is set to a (pseudo)-random 32-bit value selected by the MN, 424 and used to correlate received confirmations. 426 o A list of N (ifIndex[i], P[i])-tuples are included as follows: 428 * ifIndex[i] [RFC2863] is set to a 16-bit integer value 429 corresponding to a specific underlying ANET interface. The 430 first ifIndex MUST correspond to the ANET interface over which 431 the message is sent. Once the MN has assigned an ifIndex to an 432 ANET interface, the assignment MUST remain unchanged until the 433 MN disables the interface. MNs MUST number each ifIndex with a 434 value between '1' and '0xffff'. 436 * P[i] is a per-ifIndex set of Preferences that correspond to the 437 64 Differentiated Service Code Point (DSCP) values [RFC2474] 438 pertaining to the ANET interface. Each (P00 - P63) field is 439 set to the value '0' ("disabled"), '1' ("low"), '2' ("medium") 440 or '3' ("high") to indicate a QoS preference level for ANET 441 interface selection purposes. 443 AR options in the MS RA replies are 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 = 2 | Prefix Length |R| Reserved | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Nonce | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Prefix Lifetime | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 3: Aero Registration (AR) Option Format in RA messages 459 In this format: 461 o Type is set to TBD. 463 o Length is set to the constant value '2' (i.e., 2 units of 8 464 octets). 466 o Prefix Length is set to the length included in the AR option of 467 the RS message that triggered the RA response. 469 o R is set to '1' to confirm registration or set to '0' to release/ 470 decline registration. 472 o Reserved is set to the value '0' on transmission. 474 o Nonce echoes the 32 bit value received in the AR option of the 475 corresponding RS message. 477 o Prefix Lifetime is set to the time in seconds that the MSE will 478 maintain the Prefix registration. 480 9. Address Mapping - Multicast 482 The multicast address mapping of the native underlying ANET interface 483 applies. The mobile router on board the aircraft also serves as an 484 IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] 485 while using the link layer address of the router as the link layer 486 address for all multicast packets. 488 10. Address Mapping for IPv6 Neighbor Discovery Messages 490 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 491 unicast link-scoped IPv6 destination address. For aero interfaces in 492 the MS-enabled model, however, IPv6 ND messaging must be coordinated 493 between the MN and MS only without invoking other nodes on the ANET. 495 For this reason, ANET links maintain one or more unicast link-layer 496 address ("MSADDR") for the purpose of supporting MN/MS IPv6 ND 497 messaging. For Ethernet-compatible ANETs, this specification 498 reserves one Ethernet unicast address 00-00-5E-00-52-14. For non- 499 Ethernet statically-addressed ANETs, MSADDR is reserved per the 500 assigned numbers authority for the ANET addressing space. On still 501 other links, one or more MSADDR is discovered through dynamic link- 502 layer beacons received from ANET access routers. 504 MNs operating according to the MS-enabled model map all IPv6 ND 505 messages they send (i.e., both multicast and unicast) to an MSADDR 506 instead of to an ordinary unicast or multicast link-layer address. 508 In this way, all of the MN's IPv6 ND messages will be received by MS 509 devices that are configured to accept packets destined to MSADDR 510 (i.e., a point-to-point neighbor model). Note that multiple MS 511 devices on the link could be configured to accept packets destined to 512 MSADDR, e.g., as a basis for virtual router redundancy. 514 Therefore, ANET access routers MUST accept and process packets 515 destined to MSADDR, while all other devices MUST NOT process packets 516 destined to MSADDR. This model has a well-established operational 517 experience in Proxy Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 519 11. Conceptual Sending Algorithm 521 The MN's IPv6 layer selects the outbound aero interface according to 522 standard IPv6 requirements. The aero interface maintains default 523 routes and neighbor cache entries for MSEs, and may also include 524 additional neighbor cache entries created through other means (e.g., 525 Address Resolution, static configuration, etc.). 527 When the MN sends an NS message for Address Resolution, the aero 528 interface forwards the message to an MSE (see: Section 12) which acts 529 as a link-layer forwarding agent according to the NBMA link model. 530 The resulting NA message will provide link-layer address information 531 for the neighbor. When Neighbor Unreachability Detection is used, 532 the NS/NA exchange confirms reachability the same as for any IPv6 533 interface. 535 After a packet enters the aero interface, an outbound ANET interface 536 is selected based on traffic engineering information such as DSCP, 537 application port number, cost, performance, etc. Aero interface 538 traffic engineering could also be configured to perform replication 539 across multiple ANET interfaces for increased reliability at the 540 expense of packet duplication. 542 When a target neighbor has multiple link-layer addresses (each with a 543 different traffic engineering profile), the aero interface selects 544 ANET interfaces and neighbor link-layer addresses according to both 545 its own outbound preferences and the inbound preferences of the 546 target neighbor. 548 11.1. Multiple Aero Interfaces 550 MNs may associate with multiple MS instances concurrently. Each MS 551 instance represents a distinct aero link distinguished by its 552 associated MSPs. The MN configures a separate aero interface for 553 each link so that multiple interfaces (e.g., aero0, aero1, aero2, 554 etc.) are exposed to the IPv6 layer. 556 Depending on local policy and configuration, an MN may choose between 557 alternative active aero interfaces using a packet's DSCP, routing 558 information or static configuration. In particular, the MN can add 559 the MSPs received in Prefix Information Options (PIOs) [RFC4861] 560 [RFC8028] as guidance for aero interface selection based on per- 561 packet source addresses. 563 Each aero interface can be configured over the same or different sets 564 of ANET interfaces. Each ANET distinguishes between the different 565 aero links based on the MSPs represented in per-packet IPv6 566 addresses. 568 Multiple distinct aero links can therefore be used to support fault 569 tolerance, load balancing, reliability, etc. The architectural model 570 parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs 571 serve as (virtual) VLAN tags. 573 12. Router Discovery and Prefix Registration 575 ANET access routers accept IPv6 ND messages destined to the link- 576 local Subnet Router Anycast Address (fe80::), all-routers multicast 577 and any unicast link-local IPv6 addresses they are configured to 578 listen to. ANET access routers that support the classic link model 579 configure link-local addresses that are guaranteed not to conflict 580 with MN link-local addresses as discussed in Section 7. ANET access 581 routers that support the MS-enabled model configure the link-layer 582 address MSADDR (see: Section 10) and act as proxies for all MSEs from 583 the range fe80::1 through fe80::ffff:fffe. 585 MNs that support the classic model perform ordinary RS/RA exchanges 586 over each ANET the same as for ordinary IPv6 links. ANET access 587 routers send RAs with an IPv6 link-local source address from the 588 range fe80::1 through fe80::ffff:fffe that is guaranteed not to 589 conflict with the MN's aero address nor the address of any other 590 routers on the link. The RA messages include normal configuration 591 options including prefix information, MTU, etc. The MNs are then 592 responsible for coordinating their ANET interfaces on their own 593 behalf and for coordinating with any INET-based mobility agents. No 594 further support from the ANET is needed. 596 MNs that support the MS-enabled model interface with the MS by 597 sending RS messages with AR options. For each ANET interface, the MN 598 sends initial RS messages with AR options with link-layer address set 599 to MSADDR and with network-layer address set to either a specific MSE 600 address or to all-routers multicast. The ANET access router receives 601 the RS messages and contacts the corresponding MSE (when the 602 destination is all-routers multicast, the access router itself 603 selects an MSE). When the MSE responds, the ANET access router 604 returns RA messages with AR options and with any information for the 605 link that would normally be delivered in a solicited RA message. 607 Note that some ANET access routers that listen on MSADDR may not be 608 configured to recognize and/or process AR options. Those access 609 routers must still obey the requirements of [RFC4861] that state: 611 "Future versions of this protocol may define new option types. 612 Receivers MUST silently ignore any options they do not recognize 613 and continue processing the message." 615 In that case, the access router processes the RS message and returns 616 an RA message according to the classic link model including any 617 configuration options but without including an AR option. Upon 618 receiving the RA message, the MN must manage this ANET interface 619 according to the classic link model and must not configure it as an 620 underlying interface of the aero interface. 622 MNs configure aero interfaces that observe the properties discussed 623 in the previous section. The aero interface and its underlying 624 interfaces are said to be in either the "UP" or "DOWN" state 625 according to administrative actions in conjunction with the interface 626 connectivity status. An aero interface transitions to UP or DOWN 627 through administrative action and/or through state transitions of the 628 underlying interfaces. When a first underlying interface transitions 629 to UP, the aero interface also transitions to UP. When all 630 underlying interfaces transition to DOWN, the aero interface also 631 transitions to DOWN. 633 When an aero interface transitions to UP, the MN sends initial RS 634 messages to register its MNP and an initial set of underlying ANET 635 interfaces that are also UP. The MN sends additional RS messages to 636 refresh lifetimes and to register/deregister underlying ANET 637 interfaces as they transition to UP or DOWN. 639 MS-enabled ANET access routers coordinate with the MSE and send RA 640 messages with configuration information in response to a MN's RS 641 messages. The RA includes a Router Lifetime value and PIOs with (A; 642 L=0) that include MSPs for the link. The configuration information 643 may also include Route Information Options (RIO) options [RFC4191] 644 with more-specific routes, and an MTU option that specifies the 645 maximum acceptable packet size for the link. The ANET access router 646 sends immediate unicast RA responses without delay; therefore, the 647 'MAX_RA_DELAY_TIME' and 'MIN_DELAY_BETWEEN_RAS' constants for 648 multicast RAs do not apply. The ANET access router MAY send periodic 649 and/or event-driven unsolicited RA messages, but is not required to 650 do so for unicast advertisements [RFC4861]. 652 The MN sends RS messages from within the aero interface while using 653 an UP underlying ANET interface as the outbound interface. Each RS 654 message is formatted as though it originated from the IPv6 layer, but 655 the process is coordinated wholly from within the aero interface and 656 is therefore opaque to the IPv6 layer. The MN sends initial RS 657 messages over an UP underlying interface with its aero address as the 658 source and the address of an MSE as the destination. The RS messages 659 include AR options with a valid Prefix Length as well as ifIndex and 660 P(i) values appropriate for underlying ANET interfaces. The MS- 661 enabled ANET access router processes RS message and forwards the 662 information in the AR option to the MSE. 664 When the MSE processes the AR information, if the prefix registration 665 was accepted the MSE injects the MNP into the routing/mapping system 666 then caches the new Prefix Length, MNP, ifIndex and P(i) values. The 667 MSE then returns a non-zero Prefix Lifetime if the prefix assertion 668 was acceptable; otherwise, with a zero Prefix Lifetime. The ANET 669 access router then returns an RA message with an AR option to the MN. 671 When the MN receives the RA message, it creates a default route with 672 next hop address set to the MSE found in the RA source address and 673 with link-layer address set to MSADDR. The ANET access router will 674 then forward packets acting as a proxy between the MN and the actual 675 MSE. 677 The MN then manages its underlying ANET interfaces according to their 678 states as follows: 680 o When an underlying ANET interface transitions to UP, the MN sends 681 an RS over the ANET interface with an AR option. The AR option 682 contains a first ifIndex-tuple with values appropriate for this 683 ANET interface, and may contain additional ifIndex-tuples 684 appropriate for other ANET interfaces. 686 o When an underlying ANET interface transitions to DOWN, the MN 687 sends an RS/uNA message over any UP ANET interface with an AR 688 option containing an ifIndex-tuple for the DOWN ANET interface 689 with all P(i) values set to '0'. The MN sends an RS when an 690 acknowledgement is required, or an uNA when reliability is not 691 thought to be a concern (e.g., if redundant transmissions are sent 692 on multiple ANET interfaces). 694 o When a MN wishes to release from the current MSE, it sends an RS 695 message over any UP ANET interface with an AR option with R set to 696 0. The corresponding MSE then withdraws the MNP from the routing/ 697 mapping system and returns an RA message with an AR option with 698 Prefix Lifetime set to 0. 700 o When all of a MNs underlying interfaces have transitioned to DOWN, 701 the MSE withdraws the MNP the same as if it had received a message 702 with an AR option with R set to 0. 704 The MN is responsible for retrying each RS exchange up to 705 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 706 seconds until an RA is received. If no RA is received over multiple 707 UP ANET interfaces, the MN declares this MSE unreachable and tries a 708 different MSE. 710 The IPv6 layer sees the aero interface as an ordinary IPv6 interface. 711 Therefore, when the IPv6 layer sends an RS message the aero interface 712 returns an internally-generated RA message as though the message 713 originated from an IPv6 router. The internally-generated RA message 714 contains configuration information (such as Router Lifetime, MTU, 715 etc.) that is consistent with the information received from the RAs 716 generated by the MS. 718 Whether the aero interface IPv6 ND messaging process is initiated 719 from the receipt of an RS message from the IPv6 layer is an 720 implementation matter. Some implementations may elect to defer the 721 IPv6 ND messaging process until an RS is received from the IPv6 722 layer, while others may elect to initiate the process independently 723 of any IPv6 layer messaging. 725 13. IANA Considerations 727 The IANA is instructed to allocate an official Type number from the 728 IPv6 Neighbor Discovery Option Formats registry for the Aero 729 Registration (AR) option. Implementations set Type to 253 as an 730 interim value [RFC4727]. 732 The IANA is instructed to allocate one Ethernet unicast address, 733 00-00-5E-00-52-14 [RFC5214] in the registry "IANA Ethernet Address 734 Block - Unicast Use". 736 14. Security Considerations 738 Security considerations are the same as defined for the specific 739 access network interface types, and readers are referred to the 740 appropriate interface specifications. 742 IPv6 and IPv6 ND security considerations also apply, and are 743 specified in the normative references. 745 15. Acknowledgements 747 This document was prepared per the consensus decision at the 8th 748 Conference of the International Civil Aviation Organization (ICAO) 749 Working Group-I Mobility Subgroup on March 22, 2019. Attendees and 750 contributors included: Guray Acar, Danny Bharj, Francois D'Humieres, 751 Pavel Drasil, Nikos Fistas, Giovanni Garofolo, Vaughn Maiolla, Tom 752 McParland, Victor Moreno, Madhu Niraula, Brent Phillips, Liviu 753 Popescu, Jacky Pouzet, Aloke Roy, Greg Saccone, Robert Segers, 754 Stephane Tamalet, Fred Templin, Bela Varkonyi, Tony Whyman, and 755 Dongsong Zeng. 757 The following individuals are acknowledged for their useful comments: 758 Pavel Drasil, Zdenek Jaron, Michael Matyas, Madhu Niraula, Greg 759 Saccone. 761 . 763 16. References 765 16.1. Normative References 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, 769 DOI 10.17487/RFC2119, March 1997, 770 . 772 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 773 "Definition of the Differentiated Services Field (DS 774 Field) in the IPv4 and IPv6 Headers", RFC 2474, 775 DOI 10.17487/RFC2474, December 1998, 776 . 778 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 779 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 780 November 2005, . 782 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 783 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 784 2006, . 786 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 787 ICMPv6, UDP, and TCP Headers", RFC 4727, 788 DOI 10.17487/RFC4727, November 2006, 789 . 791 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 792 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 793 DOI 10.17487/RFC4861, September 2007, 794 . 796 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 797 Address Autoconfiguration", RFC 4862, 798 DOI 10.17487/RFC4862, September 2007, 799 . 801 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 802 Hosts in a Multi-Prefix Network", RFC 8028, 803 DOI 10.17487/RFC8028, November 2016, 804 . 806 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 807 (IPv6) Specification", STD 86, RFC 8200, 808 DOI 10.17487/RFC8200, July 2017, 809 . 811 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 812 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 813 DOI 10.17487/RFC8201, July 2017, 814 . 816 16.2. Informative References 818 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 819 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 820 . 822 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 823 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 824 December 1998, . 826 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 827 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 828 . 830 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 831 "Internet Group Management Protocol (IGMP) / Multicast 832 Listener Discovery (MLD)-Based Multicast Forwarding 833 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 834 August 2006, . 836 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 837 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 838 RFC 5213, DOI 10.17487/RFC5213, August 2008, 839 . 841 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 842 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 843 DOI 10.17487/RFC5214, March 2008, 844 . 846 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 847 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 848 2012, . 850 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 851 Requirements for IPv6 Customer Edge Routers", RFC 7084, 852 DOI 10.17487/RFC7084, November 2013, 853 . 855 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 856 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 857 Boundary in IPv6 Addressing", RFC 7421, 858 DOI 10.17487/RFC7421, January 2015, 859 . 861 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 862 Support for IP Hosts with Multi-Access Support", RFC 7847, 863 DOI 10.17487/RFC7847, May 2016, 864 . 866 Appendix A. Aero Registration Option Extensions for Special-Purpose 867 Links 869 Adaptation of the aero interface to the Aeronautical 870 Telecommunications Network with Internet Protocol Services (ATN/IPS) 871 includes link selection preferences based on transport port numbers 872 in addition to the existing DSCP-based preferences. ATN/IPS nodes 873 maintain a map of transport port numbers to 64 possible preference 874 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 875 maps to preference field 20, UDP port 8060 maps to preference field 876 34, etc. The extended aero registration option format for ATN/IPS is 877 shown in Figure 4, where the 'Q(i)' fields provide link preferences 878 for the corresponding transport port number. 880 0 1 2 3 881 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 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Type | Length | Prefix Length |R| Reserved | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Nonce | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | ifIndex [1] |P00|P01|P02|P03|P04|P05|P06|P07| 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19|P20|P21|P22|P23| 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |P24|P25|P26|P27|P28|P29|P30|P31|P32|P33|P34|P35|P36|P37|P38|P39| 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 |P40|P41|P42|P43|P44|P45|P46|P47|P48|P49|P50|P51|P52|P53|P54|P55| 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |P56|P57|P58|P59|P60|P61|P62|P63|Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07| 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15|Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23| 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31|Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39| 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 |Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47|Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55| 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 |Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| ... 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Figure 4: ATN/IPS Extended Aero Option Format 908 Appendix B. Prefix Length Considerations 910 The IPv6 addressing architecture [RFC4291] reserves the prefix ::/8; 911 this assures that MNPs will not begin with ::32 so that MN and MS 912 aero addresses cannot overlap. Additionally, this specification 913 currently observes the 64-bit boundary in IPv6 addresses [RFC7421]. 915 MN aero addresses insert the most-significant 64 MNP bits into the 916 least-significant 64 bits of the prefix fe80::/64, however [RFC4291] 917 defines the link-local prefix as fe80::/10 meaning "fe80" followed by 918 54 unused bits followed by the least-significant 64 bits of the 919 address. Future versions of this specification may adapt the 54 920 unused bits for extended coding of MNP prefixes of /65 or longer (up 921 to /118). 923 Appendix C. VDL Mode 2 Considerations 925 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 926 (VDLM2) that specifies an essential radio frequency data link service 927 for aircraft and ground stations in worldwide civil aviation air 928 traffic management. The VDLM2 link type is "multicast capable" 929 [RFC4861], but with considerable differences from common multicast 930 links such as Ethernet and IEEE 802.11. 932 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 933 magnitude less than most modern wireless networking gear. Second, 934 due to the low available link bandwidth only VDLM2 ground stations 935 (i.e., and not aircraft) are permitted to send broadcasts, and even 936 so only as compact layer 2 "beacons". Third, aircraft employ the 937 services of ground stations by performing unicast RS/RA exchanges 938 upon receipt of beacons instead of listening for multicast RA 939 messages and/or sending multicast RS messages. 941 This beacon-oriented unicast RS/RA approach is necessary to conserve 942 the already-scarce available link bandwidth. Moreover, since the 943 numbers of beaconing ground stations operating within a given spatial 944 range must be kept as sparse as possible, it would not be feasible to 945 have different classes of ground stations within the same region 946 speaking different protocols. It is therefore highly desirable that 947 all ground stations speak a common language of RS/RA as specified in 948 this document. 950 An aircraft that encounters a beaconing ground station can elect to 951 solicit either the classic or MS-enabled link models discussed in 952 Section 12. If the aircraft employs the classic link model, it sends 953 an RS message with no AR option. The ground station will return an 954 RA message with no AR option along with any configuration options for 955 the link (e.g., prefix information, MTU, etc.). If the aircraft 956 wishes to engage the MS-enabled model, it instead sends an RS message 957 with an AR option. 959 Upon receipt of an RS message with an AR option, the ground station 960 proceeds according to the MS-enabled model if it is configured to do 961 so. If the ground station does not recognize the AR option (or, if 962 it is not configured for MS-enabled operation) it instead ignores the 963 option and processes the rest of the RS message per [RFC4861]. 965 This flexibility notwithstanding, VDLM2 ground stations must be 966 consistent in terms of the service they offer. In particular, while 967 it is permissible for a ground station to simultaneously offer 968 different link models to different aircraft, it should not switch 969 between the classic and MS-enabled operating models for ongoing RS/RA 970 exchanges with the same aircraft. 972 Appendix D. RS/RA Messaging as the Single Standard API 974 At the ICAO Working Group I Mobility Subgroup meeting in London, July 975 8-12, 2019 an assertion was made that the MS-enabled link model must 976 employ a different message type besides RS/RA. This was based on the 977 pretext that including a new IPv6 ND option in an RS message would 978 cause routers that do not recognize the option to do "strange 979 things". However, [RFC4861] assures that no standards-compliant 980 router would have trouble processing an RS with unrecognized options 981 due to the following Section 4.1 requirement: 983 "Future versions of this protocol may define new option types. 984 Receivers MUST silently ignore any options they do not recognize 985 and continue processing the message." 987 Indeed, this same normative requirement appeared in both RFC2461 and 988 RFC1970 (the predecessors of RFC2460) dating back to August 1996. 989 Therefore, any router that refused to continue processing an RS 990 message after encountering a properly-formed but unrecognized option 991 would not be standards-compliant and should not be used in any 992 production network capacity. 994 Assuming for a moment however that a new message type were used to 995 invoke the MS-enabled link model, this would require two message 996 exchanges between the MN and ANET access router - a first exchange 997 with RS/RA with no new IPv6 ND options, and a second exchange with 998 the new message type. However, on links such as VDLM2 (see: 999 Appendix C) the addition of a second message exchange would impart 1000 unacceptable delay in closing the link and unacceptable extraneous 1001 message overhead that impacts link capacity for all. This clearly 1002 indicates a need to include all link establishment signaling in a 1003 single message exchange and not multiple. 1005 We therefore see strong motivation for including a new IPv6 ND option 1006 in RS/RA messages instead of creating a new message type, and proof 1007 that doing so will not harm standards-compliant access routers. 1008 Routers that recognize the options can at their discretion either 1009 honor or ignore them, while assuring that the MN will be provided 1010 with either its first choice or second choice link model. However, 1011 service providers that do not offer MN customers their first choice 1012 may risk losing business to others that do. 1014 Appendix E. Change Log 1016 << RFC Editor - remove prior to publication >> 1018 Differences from draft-templin-atn-aero-interface-05 to draft- 1019 templin-atn-aero-interface-06: 1021 o New Appendix C on "VDL Mode 2 Considerations" 1023 o New Appendix D on "RS/RA Messaging as a Single Standard API" 1025 o Various significant updates in Section 5, 10 and 12. 1027 Differences from draft-templin-atn-aero-interface-04 to draft- 1028 templin-atn-aero-interface-05: 1030 o Introduced RFC6543 precedent for focusing IPv6 ND messaging to a 1031 reserved unicast link-layer address 1033 o Introduced new IPv6 ND option for Aero Registration 1035 o Specification of MN-to-MSE message exchanges via the ANET access 1036 router as a proxy 1038 o IANA Considerations updated to include registration requests and 1039 set interim RFC4727 option type value. 1041 Differences from draft-templin-atn-aero-interface-03 to draft- 1042 templin-atn-aero-interface-04: 1044 o Removed MNP from aero option format - we already have RIOs and 1045 PIOs, and so do not need another option type to include a Prefix. 1047 o Clarified that the RA message response must include an aero option 1048 to indicate to the MN that the ANET provides a MS. 1050 o MTU interactions with link adaptation clarified. 1052 Differences from draft-templin-atn-aero-interface-02 to draft- 1053 templin-atn-aero-interface-03: 1055 o Sections re-arranged to match RFC4861 structure. 1057 o Multiple aero interfaces 1059 o Conceptual sending algorithm 1061 Differences from draft-templin-atn-aero-interface-01 to draft- 1062 templin-atn-aero-interface-02: 1064 o Removed discussion of encapsulation (out of scope) 1066 o Simplified MTU section 1067 o Changed to use a new IPv6 ND option (the "aero option") instead of 1068 S/TLLAO 1070 o Explained the nature of the interaction between the mobility 1071 management service and the air interface 1073 Differences from draft-templin-atn-aero-interface-00 to draft- 1074 templin-atn-aero-interface-01: 1076 o Updates based on list review comments on IETF 'atn' list from 1077 4/29/2019 through 5/7/2019 (issue tracker established) 1079 o added list of opportunities afforded by the single virtual link 1080 model 1082 o added discussion of encapsulation considerations to Section 6 1084 o noted that DupAddrDetectTransmits is set to 0 1086 o removed discussion of IPv6 ND options for prefix assertions. The 1087 aero address already includes the MNP, and there are many good 1088 reasons for it to continue to do so. Therefore, also including 1089 the MNP in an IPv6 ND option would be redundant. 1091 o Significant re-work of "Router Discovery" section. 1093 o New Appendix B on Prefix Length considerations 1095 First draft version (draft-templin-atn-aero-interface-00): 1097 o Draft based on consensus decision of ICAO Working Group I Mobility 1098 Subgroup March 22, 2019. 1100 Authors' Addresses 1102 Fred L. Templin (editor) 1103 Boeing Research & Technology 1104 P.O. Box 3707 1105 Seattle, WA 98124 1106 USA 1108 Email: fltemplin@acm.org 1109 Tony Whyman 1110 MWA Ltd c/o Inmarsat Global Ltd 1111 99 City Road 1112 London EC1Y 1AX 1113 England 1115 Email: tony.whyman@mccallumwhyman.com