idnits 2.17.1 draft-templin-atn-aero-interface-10.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 2, 2020) is 1547 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 400 -- Looks like a reference, but probably isn't: '2' on line 410 == Missing Reference: 'N' is mentioned on line 422, but not defined == Unused Reference: 'RFC2225' is defined on line 862, 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: July 5, 2020 MWA Ltd c/o Inmarsat Global Ltd 6 January 2, 2020 8 Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces 9 draft-templin-atn-aero-interface-10 11 Abstract 13 Aeronautical mobile nodes (e.g., aircraft of various configurations) 14 communicate with networked correspondents over multiple access 15 network data links and configure mobile routers to connect their on- 16 board networks. An Air-to-Ground (A/G) interface specification is 17 therefore needed for coordination with the ground domain network. 18 This document specifies the transmission of IPv6 packets over 19 aeronautical ("aero") interfaces. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 5, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Aeronautical ("aero") Interface Model . . . . . . . . . . . . 4 59 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 7 60 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 7 62 8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 8 63 9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 12 64 10. Address Mapping for IPv6 Neighbor Discovery Messages . . . . 13 65 11. Conceptual Sending Algorithm . . . . . . . . . . . . . . . . 13 66 11.1. Multiple Aero Interfaces . . . . . . . . . . . . . . . . 14 67 12. Router Discovery and Prefix Registration . . . . . . . . . . 14 68 13. Detecting and Responding to MSE Failures . . . . . . . . . . 17 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 15. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 72 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 17.1. Normative References . . . . . . . . . . . . . . . . . . 18 74 17.2. Informative References . . . . . . . . . . . . . . . . . 20 75 Appendix A. AERO Option Extensions for Pseudo-DSCP Mappings . . 21 76 Appendix B. Prefix Length Considerations . . . . . . . . . . . . 22 77 Appendix C. VDL Mode 2 Considerations . . . . . . . . . . . . . 22 78 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 23 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 81 1. Introduction 83 Aeronautical Mobile Nodes (MNs) such as aircraft of various 84 configurations often have multiple data links for communicating with 85 networked correspondents. These data links may have differing 86 performance, cost and availability characteristics that can change 87 dynamically according to mobility patterns, flight phases, proximity 88 to 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 (i.e., 93 similar to IPv6 customer edge routers [RFC7084]) and acts as a mobile 94 router on behalf of its on-board networks. 96 The MN configures a virtual interface (termed the "aero interface") 97 as a thin layer over the underlying access network interfaces. The 98 aero interface is therefore the only interface abstraction exposed to 99 the IPv6 layer and behaves according to the Non-Broadcast, Multiple 100 Access (NBMA) interface principle, while underlying access network 101 interfaces appear as link layer communication channels in the 102 architecture. The aero interface connects to a virtual overlay cloud 103 service known as the "aero link". The aero link spans a worldwide 104 Internetwork that may be either a private-use infrastructure or the 105 global public Internet itself. 107 The aero interface provides a traffic engineering nexus for guiding 108 inbound and outbound traffic to the correct underlying Access Network 109 (ANET) interface(s). The IPv6 layer sees the aero interface as a 110 point of connection to the aero link. Each aero link has one or more 111 associated Mobility Service Prefixes (MSPs) from which aero link MNPs 112 are derived. If there are multiple aero links, the IPv6 layer will 113 see multiple aero interfaces. 115 The aero interface interacts with the ground-domain Mobility Service 116 (MS) through IPv6 Neighbor Discovery (ND) control message exchanges 117 [RFC4861]. The MS provides Mobility Service Endpoints (MSEs) that 118 track MN movements and represent their MNPs in a global routing or 119 mapping system. 121 This document specifies the transmission of IPv6 packets [RFC8200] 122 and MN/MS control messaging over aeronautical ("aero") interfaces. 124 2. Terminology 126 The terminology in the normative references applies; especially, the 127 terms "link" and "interface" are the same as defined in the IPv6 128 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 130 The following terms are defined within the scope of this document: 132 Access Network (ANET) 133 a data link service network (e.g., an aviation radio access 134 network, satellite service provider network, cellular operator 135 network, etc.) protected by physical and/or link layer security. 136 Each ANET provides an Access Router (AR), and connects to outside 137 Internetworks via border security devices such as proxys, 138 firewalls, packet filtering gateways, etc. 140 ANET interface 141 a node's attachment to a link in an ANET. 143 Internetwork (INET) 144 a connected network region with a coherent IP addressing plan that 145 provides transit forwarding services for ANET mobile nodes and 146 INET correspondents. Examples include private enterprise 147 networks, aviation networks and the global public Internet itself. 149 INET interface 150 a node's attachment to a link in an INET. 152 aero link 153 a virtual overlay cloud service configured over one or more INETs 154 and their connected ANETs. An aero link may comprise multiple 155 INET segments joined by bridges the same as for any link; the 156 addressing plans in each segment may be mutually exclusive and 157 managed by different administrative entities. 159 aero interface 160 a node's attachment to an aero link, and configured over one or 161 more underlying ANET/INET interfaces. 163 aero address 164 an IPv6 link-local address constructed as specified in Section 7, 165 and assigned to an aero interface. 167 3. Requirements 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. Lower case 172 uses of these words are not to be interpreted as carrying RFC2119 173 significance. 175 4. Aeronautical ("aero") Interface Model 177 An aero interface is a MN virtual interface configured over one or 178 more ANET interfaces, which may be physical (e.g., an aeronautical 179 radio link) or virtual (e.g., an Internet or higher-layer "tunnel"). 180 The MN coordinates with the MS through IPv6 ND message exchanges. 182 The aero interface architectural layering model is the same as in 183 [RFC7847], and augmented as shown in Figure 1. The IPv6 layer 184 therefore sees the aero interface as a single network layer interface 185 with multiple underlying ANET interfaces that appear as link layer 186 communication channels in the architecture. 188 +----------------------------+ 189 | TCP/UDP | 190 Session-to-IP +---->| | 191 Address Binding | +----------------------------+ 192 +---->| IPv6 | 193 IP Address +---->| | 194 Binding | +----------------------------+ 195 +---->| aero Interface | 196 Logical-to- +---->| (aero address) | 197 Physical | +----------------------------+ 198 Interface +---->| L2 | L2 | | L2 | 199 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 200 +------+------+ +------+ 201 | L1 | L1 | | L1 | 202 | | | | | 203 +------+------+ +------+ 205 Figure 1: Aero Interface Architectural Layering Model 207 The aero virtual interface model gives rise to a number of 208 opportunities: 210 o since aero interface link-local addresses are uniquely derived 211 from an MNP (see: Section 7, no Duplicate Address Detection (DAD) 212 messaging is necessary over the aero interface. 214 o ANET interfaces can remain unnumbered in environments where 215 communications are coordinated entirely over the aero interface. 217 o as ANET interface properties change (e.g., link quality, cost, 218 availability, etc.), any active ANET interface can be used to 219 update the profiles of multiple additional ANET interfaces in a 220 single message. This allows for timely adaptation and service 221 continuity under dynamically changing conditions. 223 o coordinating ANET interfaces in this way allows them to be 224 represented in a unified MS profile with provisions for mobility 225 and multilink operations. 227 o exposing a single virtual interface abstraction to the IPv6 layer 228 allows for traffic engineering (including QoS based link 229 selection, packet replication, load balancing, etc.) at the link 230 layer while still permitting queuing at the IPv6 layer based on, 231 e.g., traffic class, flow label, etc. 233 o the IPv6 layer sees the aero interface as a point of connection to 234 the aero link; if there are multiple aero links (i.e., multiple 235 MS's), the IPv6 layer will see multiple aero interfaces. 237 Other opportunities are discussed in [RFC7847]. 239 Figure 2 depicts the architectural model for a MN connecting to the 240 MS via multiple independent ANETs. When an ANET interface becomes 241 active, the MN sends native (i.e., unencapsulated) IPv6 ND messages 242 via the underlying ANET interface. IPv6 ND messages traverse the 243 ground domain ANETs until they reach an Access Router (AR#1, AR#2, 244 .., AR#n). The AR then coordinates with a Mobility Service Endpoint 245 (MSE#1, MSE#2, ..., MSE#m) in the INET and returns an IPv6 ND message 246 response to the MN. IPv6 ND messages traverse the ANET at layer 2; 247 hence, the Hop Limit is not decremented. 249 +--------------+ 250 | MN | 251 +--------------+ 252 |aero interface| 253 +----+----+----+ 254 +--------|IF#1|IF#2|IF#n|------ + 255 / +----+----+----+ \ 256 / | \ 257 / Native | IPv6 \ 258 v v v 259 (:::)-. (:::)-. (:::)-. 260 .-(::ANET:::) .-(::ANET:::) .-(::ANET:::) 261 `-(::::)-' `-(::::)-' `-(::::)-' 262 +----+ +----+ +----+ 263 ... |AR#1| .......... |AR#2| ......... |AR#n| ... 264 . +-|--+ +-|--+ +-|--+ . 265 . | | | 266 . v v v . 267 . <----- Encapsulation -----> . 268 . . 269 . +-----+ (:::)-. . 270 . |MSE#2| .-(::::::::) +-----+ . 271 . +-----+ .-(::: INET :::)-. |MSE#m| . 272 . (::::: Routing ::::) +-----+ . 273 . `-(::: System :::)-' . 274 . +-----+ `-(:::::::-' . 275 . |MSE#1| +-----+ +-----+ . 276 . +-----+ |MSE#3| |MSE#4| . 277 . +-----+ +-----+ . 278 . . 279 . . 280 . <----- Worldwide Connected Internetwork ----> . 281 ........................................................... 283 Figure 2: MN/MS Coordination via Multiple ANETs 285 After the initial IPv6 ND message exchange, the MN can send and 286 receive unencapsulated IPv6 data packets over the aero interface. 287 Traffic engineering will forward the packets via ARs in the correct 288 underlying ANETs. The AR encapsulates the packets according to the 289 capabilities provided by the MS and forwards them to the next hop 290 within the worldwide connected Internetwork via optimal routes. 292 5. Maximum Transmission Unit 294 All IPv6 interfaces MUST configure an MTU of at least 1280 bytes 295 [RFC8200]. The aero interface configures its MTU based on the 296 largest MTU among all underlying ANET interfaces. The value may be 297 overridden if an RA message with an MTU option is received. 299 The aero interface returns internally-generated IPv6 Path MTU 300 Discovery (PMTUD) Packet Too Big (PTB) messages [RFC8201] for packets 301 admitted into the aero interface that are too large for the outbound 302 underlying ANET interface. Similarly, the aero interface performs 303 PMTUD even if the destination appears to be on the same link since a 304 proxy on the path could return a PTB message. PMTUD therefore 305 ensures that the aero interface MTU is adaptive and reflects the 306 current path used for a given data flow. 308 Applications that cannot tolerate loss due to MTU restrictions should 309 refrain from sending packets larger than 1280 bytes, since dynamic 310 path changes can reduce the path MTU at any time. Applications that 311 may benefit from sending larger packets even though the path MTU may 312 change dynamically can use larger sizes. 314 6. Frame Format 316 The aero interface transmits IPv6 packets according to the native 317 frame format of each underlying ANET interface. For example, for 318 Ethernet-compatible interfaces the frame format is specified in 319 [RFC2464], for aeronautical radio interfaces the frame format is 320 specified in standards such as ICAO Doc 9776 (VDL Mode 2 Technical 321 Manual), for tunnels over IPv6 the frame format is specified in 322 [RFC2473], etc. 324 7. Link-Local Addresses 326 Aero interfaces assign link-local addresses the same as any IPv6 327 interface. The link-local address format for aero interfaces is 328 known as the "aero address". 330 MN aero addresses begin with the prefix fe80::/64 followed by a 331 64-bit prefix taken from the MNP (see: Appendix B). The lowest- 332 numbered aero address serves as the "base" address. The MN uses the 333 base aero address in IPv6 ND messages, but accepts packets destined 334 to all aero addresses equally. For example, for the MNP 335 2001:db8:1000:2000::/56 the corresponding aero addresses are: 337 fe80::2001:db8:1000:2000 339 fe80::2001:db8:1000:2001 341 fe80::2001:db8:1000:2002 343 ... etc. ... 345 fe80::2001:db8:1000:20ff 347 MSE aero addresses are allocated from the range fe80::/96, and MUST 348 be managed for uniqueness by the collective aero link administrative 349 authorities. The lower 32 bits of the address includes a unique 350 integer value, e.g., fe80::1, fe80::2, fe80::3, etc. The address 351 fe80:: is the IPv6 link-local Subnet Router Anycast address [RFC4291] 352 and the address fe80::ffff:ffff is reserved; hence, these values are 353 not available for general assignment. 355 The IPv6 addressing architecture [RFC4291] reserves the prefix ::/8; 356 this assures that MNPs will not begin with ::/32 so that MN and MSE 357 aero addresses cannot overlap. 359 Since MN aero addresses are based on the distribution of 360 administratively assured unique MNPs, and since MSE aero addresses 361 are guaranteed unique through administrative assignment, aero 362 interfaces set the autoconfiguration variable DupAddrDetectTransmits 363 to 0 [RFC4862]. 365 IPv4-compatible aero addresses are allocated as fe80::ffff:[v4addr], 366 i.e., fe80::/10, followed by 70 '0' bits, followed by 16 '1' bits, 367 followed by a 32bit IPv4 address. IPv4 address usage is outside the 368 scope of this document. 370 8. Address Mapping - Unicast 372 Aero interfaces maintain a neighbor cache for tracking per-neighbor 373 state and use the link-local address format specified in Section 7. 374 IPv6 Neighbor Discovery (ND) [RFC4861] messages on aero interfaces 375 observe the native Source/Target Link-Layer Address Option (S/TLLAO) 376 formats of the underlying ANET interfaces (e.g., for Ethernet the S/ 377 TLLAO is specified in [RFC2464]). 379 MNs such as aircraft typically have many wireless data link types 380 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 381 etc.) with diverse performance, cost and availability properties. 382 The aero interface would therefore appear to have multiple link layer 383 connections, and may include information for multiple ANET interfaces 384 in a single message exchange. 386 Aero interfaces use a new IPv6 ND option called the "Aeronautical 387 Endpoint Registration Option (AERO)". MNs invoke the MS by including 388 an AERO option in Router Solicitation (RS) and (unsolicited) Neighbor 389 Advertisement (NA) messages, and the MS includes an AERO option in 390 unicast Router Advertisement (RA) responses to an RS. 392 RS/NA messages sent by the MN include AERO options formatted as shown 393 in Figure 3: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | Prefix Length |R| Reserved | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | ifIndex[1] | ifType[1] | Flags [1] |Link[1]|QoS[1] | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | ifIndex[2] | ifType[2] | Flags [2] |Link[2]|QoS[2] | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 ... ... ... 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | ifIndex[N] | ifType[N] | Flags [N] |Link[N]|QoS[N] | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | zero-padding | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Figure 3: Aeronautical Endpoint Registration Option (AERO) Format in 436 RS/NA Messages 438 In this format: 440 o Type is set to TBD. 442 o Length is set to the number of 8 octet blocks in the option (with 443 zero-padding added to the end of the option if necessary to 444 produce an integral number of 8 octet blocks). 446 o Prefix Length is set to the length of the MNP embedded in the MN's 447 aero address. 449 o R (the "Register" bit) is set to '1' to assert the MNP 450 registration or set to '0' to request de-registration. 452 o Reserved is set to the value '0' on transmission. 454 o A set of N ANET interface "ifIndex-tuples" are included as 455 follows: 457 * ifIndex[i] is set to an 8-bit integer value corresponding to a 458 specific underlying ANET interface. The first ifIndex-tuple 459 MUST correspond to the ANET interface over which the message is 460 sent. Once the MN has assigned an ifIndex to an ANET 461 interface, the assignment MUST remain unchanged while the MN 462 remains registered in the network. MNs MUST number each 463 ifIndex with a value between '1' and '255' that represents a 464 MN-specific 8-bit mapping for the actual ifIndex value assigned 465 to the ANET interface by network management [RFC2863]. 467 * ifType[i] is set to an 8-bit integer value corresponding to the 468 underlying ANET interface identified by ifIndex. The value 469 represents an aero interface-specific 8-bit mapping for the 470 actual IANA ifType value assigned to the ANET interface by 471 network management [RFC2863]. 473 * Flags[i] is an 8-bit flags field. All flag bits are currently 474 undefined and set to the value '0' on transmission. Future 475 updates may specify new flags. 477 * Link[i] encodes a 4-bit link metric. The value '0' means the 478 link is DOWN, and the remaining values mean the link is UP with 479 metric ranging from '1' ("low") to '15' ("high"). 481 * QoS[i] encodes the number of 4-byte blocks (between '0' and 482 '15') of two-bit P[i] values that follow. The first 4 blocks 483 correspond to the 64 Differentiated Service Code Point (DSCP) 484 values P00 - P63 [RFC2474]. If additional 4-byte P[i] blocks 485 follow, their values correspond to "pseudo-DSCP" values P64, 486 P65, P66, etc. numbered consecutively. The pseudo-DSCP values 487 correspond to ancillary QoS information defined for the 488 specific aero interface (e.g., see Appendix A). 490 * P[i] includes zero or more per-ifIndex 4-byte blocks of two-bit 491 Preferences. Each P[i] field is set to the value '0' 492 ("disabled"), '1' ("low"), '2' ("medium") or '3' ("high") to 493 indicate a QoS preference level for ANET interface selection 494 purposes. The first four blocks always correspond to the 64 495 DSCP values. If one or more of the blocks are absent (e.g., 496 for QoS values 0,1,2,3) the P[i] values for the missing blocks 497 default to "medium". 499 Unicast RA messages sent by the MS in response to MN RS messages 500 include AERO options formatted as shown in Figure 4: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Type | Length = 1 | Prefix Length |R| Reserved | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | ifIndex | ifType | Flags | Link | QoS | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 4: Aeronautical Endpoint Registration Option (AERO) Format in 511 RA messages 513 In this format: 515 o Type is set to TBD. 517 o Length is set to the constant value '1' (i.e., 1 unit of 8 518 octets). 520 o Prefix Length is set to the length associated with the aero 521 address of the destination MN. 523 o R is set to '1' to confirm registration or set to '0' to release/ 524 decline registration. 526 o ifIndex, ifType, Flags, Link and QoS echo the values of the same 527 fields that were received in the first ifIndex-tuple of the 528 soliciting RS. The echoed values provide a nonce that allows the 529 MN to associate the received RA with the soliciting RS. 531 9. Address Mapping - Multicast 533 The multicast address mapping of the native underlying ANET interface 534 applies. The mobile router on board the aircraft also serves as an 535 IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] 536 while using the link layer address of the router as the link layer 537 address for all multicast packets. 539 10. Address Mapping for IPv6 Neighbor Discovery Messages 541 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 542 unicast link-scoped IPv6 destination address. However, IPv6 ND 543 messaging must be coordinated between the MN and MS only without 544 invoking other nodes on the ANET. 546 For this reason, ANET links maintain unicast link-layer addresses 547 ("MSADDR") for the purpose of supporting MN/MS IPv6 ND messaging. 548 For Ethernet-compatible ANETs, this specification reserves one 549 Ethernet unicast address 00-00-5E-00-52-14. For non-Ethernet 550 statically-addressed ANETs, MSADDR is reserved per the assigned 551 numbers authority for the ANET addressing space. For still other 552 ANETs, MSADDR may be dynamically discovered through other means, 553 e.g., link-layer beacons. 555 MNs map all IPv6 ND messages they send (i.e., both multicast and 556 unicast) to an MSADDR instead of to an ordinary unicast or multicast 557 link-layer address. In this way, all of the MN's IPv6 ND messages 558 will be received by MS devices that are configured to accept packets 559 destined to MSADDR. Note that multiple MS devices on the link could 560 be configured to accept packets destined to MSADDR, e.g., as a basis 561 for supporting redundancy. 563 Therefore, ARs MUST accept and process packets destined to MSADDR, 564 while all other devices MUST NOT process packets destined to MSADDR. 565 This model has a well-established operational experience in Proxy 566 Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 568 11. Conceptual Sending Algorithm 570 The MN's IPv6 layer selects the outbound aero interface according to 571 standard IPv6 requirements. The aero interface maintains default 572 routes and neighbor cache entries for MSEs, and may also include 573 additional neighbor cache entries created through other means (e.g., 574 Address Resolution, static configuration, etc.). 576 After a packet enters the aero interface, an outbound ANET interface 577 is selected based on traffic engineering information such as DSCP, 578 application port number, cost, performance, message size, etc. Aero 579 interface traffic engineering could also be configured to perform 580 replication across multiple ANET interfaces for increased reliability 581 at the expense of packet duplication. 583 11.1. Multiple Aero Interfaces 585 MNs may associate with multiple MS instances concurrently. Each MS 586 instance represents a distinct aero link distinguished by its 587 associated MSPs. The MN configures a separate aero interface for 588 each link so that multiple interfaces (e.g., aero0, aero1, aero2, 589 etc.) are exposed to the IPv6 layer. 591 Depending on local policy and configuration, an MN may choose between 592 alternative active aero interfaces using a packet's DSCP, routing 593 information or static configuration. Interface selection based on 594 per-packet source addresses is also enabled when the MSPs for each 595 aero interface are known (e.g., discovered through Prefix Information 596 Options (PIOs) and/or Route Information Options (RIOs)). 598 Each aero interface can be configured over the same or different sets 599 of ANET interfaces. Each ANET distinguishes between the different 600 aero links based on the MSPs represented in per-packet IPv6 601 addresses. 603 Multiple distinct aero links can therefore be used to support fault 604 tolerance, load balancing, reliability, etc. The architectural model 605 parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs 606 serve as (virtual) VLAN tags. 608 12. Router Discovery and Prefix Registration 610 ARs process IPv6 ND messages destined to all-routers multicast, 611 subnet router anycast and unicast link-local IPv6 addresses. ARs 612 configure the link-layer address MSADDR (see: Section 10) and act as 613 a proxy for MSE addresses in the range fe80::1 through 614 fe80::ffff:fffe. 616 MNs interface with the MS by sending RS messages with AERO options. 617 For each ANET interface, the MN sends RS messages with AERO options 618 with link-layer destination address set to MSADDR and with network- 619 layer destination address set to either a specific MSE aero address, 620 subnet router anycast, or all-routers multicast. The MN discovers 621 MSE addresses either through an RA message response to an initial 622 anycast/multicast RS or before sending an initial RS message. 623 [RFC5214] provides example MSE address discovery methods, including 624 information conveyed during data link login, name service lookups, 625 static configuration, etc. 627 The AR receives the RS messages and contacts the corresponding MSE. 628 When the MSE responds, the AR returns an RA message with source 629 address set to the MSE address, with an AERO option and with any 630 information for the link that would normally be delivered in a 631 solicited RA message. 633 MNs configure aero interfaces that observe the properties discussed 634 in the previous section. The aero interface and its underlying 635 interfaces are said to be in either the "UP" or "DOWN" state 636 according to administrative actions in conjunction with the interface 637 connectivity status. An aero interface transitions to UP or DOWN 638 through administrative action and/or through state transitions of the 639 underlying interfaces. When a first underlying interface transitions 640 to UP, the aero interface also transitions to UP. When all 641 underlying interfaces transition to DOWN, the aero interface also 642 transitions to DOWN. 644 When an aero interface transitions to UP, the MN sends initial RS 645 messages to register its MNP and an initial set of underlying ANET 646 interfaces that are also UP. The MN sends additional RS messages to 647 refresh lifetimes and to register/deregister underlying ANET 648 interfaces as they transition to UP or DOWN. 650 ARs coordinate with the MSE and return RA messages with configuration 651 information in response to a MN's RS messages. The RAs include a 652 Router Lifetime value and any necessary options, such as: 654 o PIOs with (A; L=0) that include MSPs for the link [RFC8028]. 656 o RIOs [RFC4191] with more-specific routes. 658 o an MTU option that specifies the maximum acceptable packet size 659 for the aero link 661 The AR sends immediate unicast RA responses without delay; therefore, 662 the 'MAX_RA_DELAY_TIME' and 'MIN_DELAY_BETWEEN_RAS' constants for 663 multicast RAs do not apply. The AR MAY send periodic and/or event- 664 driven unsolicited RA messages, but is not required to do so for 665 unicast advertisements [RFC4861]. 667 The MN sends RS messages from within the aero interface while using 668 an UP underlying ANET interface as the outbound interface. Each RS 669 message is formatted as though it originated from the IPv6 layer, but 670 the process is coordinated wholly from within the aero interface and 671 is therefore opaque to the IPv6 layer. The MN sends initial RS 672 messages over an UP underlying interface with its aero address as the 673 source. The RS messages include AERO options with a valid Prefix 674 Length as well as ifIndex-tuples appropriate for underlying ANET 675 interfaces. The AR processes RS message and forwards the information 676 in the AERO option to the MSE. 678 When the MSE processes the AR information, if the prefix registration 679 was accepted the MSE injects the MNP into the routing/mapping system 680 then caches the new Prefix Length, MNP and ifIndex-tuples. The MSE 681 then coordinates with the AR to return an RA message to the MN with 682 an AERO option with a non-zero Router Lifetime if the prefix 683 assertion was acceptable; otherwise, with a zero Router Lifetime. 685 When the MN receives the RA message, it creates a default route with 686 next hop address set to the MSE found in the RA source address and 687 with link-layer address set to MSADDR. The AR will then forward 688 packets acting as a proxy between the MN and the MS. 690 The MN then manages its underlying ANET interfaces according to their 691 states as follows: 693 o When an underlying ANET interface transitions to UP, the MN sends 694 an RS over the ANET interface with an AERO option. The AERO 695 option contains a first ifIndex-tuple with values specific to this 696 ANET interface, and may contain additional ifIndex-tuples specific 697 to other ANET interfaces. 699 o When an underlying ANET interface transitions to DOWN, the MN 700 sends an RS or unsolicited NA message over any UP ANET interface 701 with an AERO option containing an ifIndex-tuple for the DOWN ANET 702 interface with Link(i) set to '0'. The MN sends an RS when an 703 acknowledgement is required, or an unsolicited NA when reliability 704 is not thought to be a concern (e.g., if redundant transmissions 705 are sent on multiple ANET interfaces). 707 o When a MN wishes to release from a current MSE, it sends RS 708 messages over any UP ANET interfaces with an AERO option with R 709 set to 0. The corresponding MSE then withdraws the MNP from the 710 routing/mapping system and returns an RA message with an AERO 711 option with Router Lifetime set to 0. 713 o When all of a MNs underlying interfaces have transitioned to DOWN, 714 the MSE withdraws the MNP the same as if it had received a message 715 with an AERO option with R set to 0. 717 The MN is responsible for retrying each RS exchange up to 718 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 719 seconds until an RA is received. If no RA is received over multiple 720 UP ANET interfaces, the MN declares this MSE unreachable and tries a 721 different MSE. 723 The IPv6 layer sees the aero interface as an ordinary IPv6 interface. 724 Therefore, when the IPv6 layer sends an RS message the aero interface 725 returns an internally-generated RA message as though the message 726 originated from an IPv6 router. The internally-generated RA message 727 contains configuration information (such as Router Lifetime, MTU, 728 etc.) that is consistent with the information received from the RAs 729 generated by the MS. 731 Whether the aero interface IPv6 ND messaging process is initiated 732 from the receipt of an RS message from the IPv6 layer is an 733 implementation matter. Some implementations may elect to defer the 734 IPv6 ND messaging process until an RS is received from the IPv6 735 layer, while others may elect to initiate the process independently 736 of any IPv6 layer messaging. 738 13. Detecting and Responding to MSE Failures 740 In environments where fast recovery from MSE failure is required, ARs 741 SHOULD use proactive Neighbor Unreachability Detection (NUD) in a 742 manner that parallels Bidirectional Forwarding Detection (BFD) 743 [RFC5880] to track MSE reachability. ARs can then quickly detect and 744 react to failures so that cached information is re-established 745 through alternate paths. Proactive NUD control messaging is carried 746 only over well-connected ground domain networks (i.e., and not low- 747 end aeronautical radio links) and can therefore be tuned for rapid 748 response. 750 ARs employ proactive NUD with MSEs for which there are currently 751 active ANET MNs. If an MSE fails, ARs can quickly inform MNs of the 752 outage by sending RA messages on the ANET interface. The AR sends RA 753 messages with source address set to the MSEs address, destination 754 address set to all-nodes multicast, and Router Lifetime set to 0. 756 The AR SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated 757 by small delays [RFC4861]. Any MNs on the ANET interface that have 758 been using the (now defunct) MSE will receive the RA messages and 759 associate with a new MSE. 761 14. IANA Considerations 763 The IANA is instructed to allocate an official Type number from the 764 IPv6 Neighbor Discovery Option Formats registry for the Aero 765 Registration (AR) option. Implementations set Type to 253 as an 766 interim value [RFC4727]. 768 The IANA is instructed to allocate one Ethernet unicast address, 769 00-00-5E-00-52-14 [RFC5214] in the registry "IANA Ethernet Address 770 Block - Unicast Use". 772 15. Security Considerations 774 Security considerations are the same as defined for the specific 775 access network interface types, and readers are referred to the 776 appropriate interface specifications. 778 IPv6 and IPv6 ND security considerations also apply, and are 779 specified in the normative references. 781 16. Acknowledgements 783 The first version of this document was prepared per the consensus 784 decision at the 7th Conference of the International Civil Aviation 785 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 786 2019. Consensus to take the document forward to the IETF was reached 787 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 788 Attendees and contributors included: Guray Acar, Danny Bharj, 789 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 790 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 791 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 792 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 793 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 794 Fryderyk Wrobel and Dongsong Zeng. 796 The following individuals are acknowledged for their useful comments: 797 Pavel Drasil, Zdenek Jaron, Michael Matyas, Madhu Niraula, Greg 798 Saccone, Stephane Tamalet. Naming of the IPv6 ND option was 799 discussed on the 6man mailing list. 801 This work is aligned with the NASA Safe Autonomous Systems Operation 802 (SASO) program under NASA contract number NNA16BD84C. 804 This work is aligned with the FAA as per the SE2025 contract number 805 DTFAWA-15-D-00030. 807 17. References 809 17.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, 813 DOI 10.17487/RFC2119, March 1997, 814 . 816 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 817 "Definition of the Differentiated Services Field (DS 818 Field) in the IPv4 and IPv6 Headers", RFC 2474, 819 DOI 10.17487/RFC2474, December 1998, 820 . 822 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 823 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 824 November 2005, . 826 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 827 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 828 2006, . 830 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 831 ICMPv6, UDP, and TCP Headers", RFC 4727, 832 DOI 10.17487/RFC4727, November 2006, 833 . 835 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 836 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 837 DOI 10.17487/RFC4861, September 2007, 838 . 840 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 841 Address Autoconfiguration", RFC 4862, 842 DOI 10.17487/RFC4862, September 2007, 843 . 845 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 846 Hosts in a Multi-Prefix Network", RFC 8028, 847 DOI 10.17487/RFC8028, November 2016, 848 . 850 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 851 (IPv6) Specification", STD 86, RFC 8200, 852 DOI 10.17487/RFC8200, July 2017, 853 . 855 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 856 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 857 DOI 10.17487/RFC8201, July 2017, 858 . 860 17.2. Informative References 862 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 863 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 864 . 866 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 867 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 868 . 870 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 871 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 872 December 1998, . 874 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 875 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 876 . 878 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 879 "Internet Group Management Protocol (IGMP) / Multicast 880 Listener Discovery (MLD)-Based Multicast Forwarding 881 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 882 August 2006, . 884 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 885 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 886 RFC 5213, DOI 10.17487/RFC5213, August 2008, 887 . 889 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 890 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 891 DOI 10.17487/RFC5214, March 2008, 892 . 894 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 895 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 896 . 898 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 899 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 900 2012, . 902 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 903 Requirements for IPv6 Customer Edge Routers", RFC 7084, 904 DOI 10.17487/RFC7084, November 2013, 905 . 907 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 908 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 909 Boundary in IPv6 Addressing", RFC 7421, 910 DOI 10.17487/RFC7421, January 2015, 911 . 913 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 914 Support for IP Hosts with Multi-Access Support", RFC 7847, 915 DOI 10.17487/RFC7847, May 2016, 916 . 918 Appendix A. AERO Option Extensions for Pseudo-DSCP Mappings 920 Adaptation of the aero interface to specific Internetworks such as 921 the Aeronautical Telecommunications Network with Internet Protocol 922 Services (ATN/IPS) includes link selection preferences based on 923 transport port numbers in addition to the existing DSCP-based 924 preferences. ATN/IPS nodes maintain a map of transport port numbers 925 to additional "pseudo-DSCP" P[i] preference fields beyond the first 926 64. For example, TCP port 22 maps to pseudo-DSCP value P67, TCP port 927 443 maps to P70, UDP port 8060 maps to P76, etc. Figure 5 shows an 928 example AERO option with extended P[i] values beyond the base 64 used 929 for DSCP mapping (i.e., for QoS values 5 or greater): 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Type | Length | Prefix Length |R| Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | ifIndex | ifType | Flags | Link |QoS=5+ | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 |P64|P65|P66|P67|P68|P69|P70|P71|P72|P73|P74|P75|P76|P77|P78|P79| 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 ... 950 Figure 5: ATN/IPS Extended Aero Option Format 952 Appendix B. Prefix Length Considerations 954 The 64-bit boundary in IPv6 addresses [RFC7421] determines the MN 955 aero address format for encoding the most-significant 64 MNP bits 956 into the least-significant 64 bits of the prefix fe80::/64 as 957 discussed in Section 7. 959 [RFC4291] defines the link-local address format as fe80::/10,followed 960 by 54 unused bits, followed by the least-significant 64 bits of the 961 address. If the 64-bit boundary is relaxed through future standards 962 activity, then the 54 unused bits can be employed for extended coding 963 of MNPs of length /65 up to /118. 965 The extended coding format would continue to encode MNP bits 0-63 in 966 bits 64-127 of the aero address, while including MNP bits 64-117 in 967 bits 10-63. For example, the aero address corresponding to the MNP 968 2001:db8:1111:2222:3333:4444:5555::/112 would be 969 fe8c:ccd1:1115:5540:2001:db8:1111:2222, and would still be a valid 970 IPv6 link-local unicast address per [RFC4291]. 972 Appendix C. VDL Mode 2 Considerations 974 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 975 (VDLM2) that specifies an essential radio frequency data link service 976 for aircraft and ground stations in worldwide civil aviation air 977 traffic management. The VDLM2 link type is "multicast capable" 978 [RFC4861], but with considerable differences from common multicast 979 links such as Ethernet and IEEE 802.11. 981 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 982 magnitude less than most modern wireless networking gear. Second, 983 due to the low available link bandwidth only VDLM2 ground stations 984 (i.e., and not aircraft) are permitted to send broadcasts, and even 985 so only as compact layer 2 "beacons". Third, aircraft employ the 986 services of ground stations by performing unicast RS/RA exchanges 987 upon receipt of beacons instead of listening for multicast RA 988 messages and/or sending multicast RS messages. 990 This beacon-oriented unicast RS/RA approach is necessary to conserve 991 the already-scarce available link bandwidth. Moreover, since the 992 numbers of beaconing ground stations operating within a given spatial 993 range must be kept as sparse as possible, it would not be feasible to 994 have different classes of ground stations within the same region 995 observing different protocols. It is therefore highly desirable that 996 all ground stations observe a common language of RS/RA as specified 997 in this document. 999 Appendix D. Change Log 1001 << RFC Editor - remove prior to publication >> 1003 Differences from draft-templin-atn-aero-interface-09 to draft- 1004 templin-atn-aero-interface-10: 1006 o Renamed ARO option to AERO option 1008 o Re-worked Section 13 text to discuss proactive NUD. 1010 Differences from draft-templin-atn-aero-interface-08 to draft- 1011 templin-atn-aero-interface-09: 1013 o Version and reference update 1015 Differences from draft-templin-atn-aero-interface-07 to draft- 1016 templin-atn-aero-interface-08: 1018 o Removed "Classic" and "MS-enabled" link model discussion 1020 o Added new figure for MN/AR/MSE model. 1022 o New Section on "Detecting and responding to MSE failure". 1024 Differences from draft-templin-atn-aero-interface-06 to draft- 1025 templin-atn-aero-interface-07: 1027 o Removed "nonce" field from AR option format. Applications that 1028 require a nonce can include a standard nonce option if they want 1029 to. 1031 o Various editorial cleanups. 1033 Differences from draft-templin-atn-aero-interface-05 to draft- 1034 templin-atn-aero-interface-06: 1036 o New Appendix C on "VDL Mode 2 Considerations" 1038 o New Appendix D on "RS/RA Messaging as a Single Standard API" 1040 o Various significant updates in Section 5, 10 and 12. 1042 Differences from draft-templin-atn-aero-interface-04 to draft- 1043 templin-atn-aero-interface-05: 1045 o Introduced RFC6543 precedent for focusing IPv6 ND messaging to a 1046 reserved unicast link-layer address 1048 o Introduced new IPv6 ND option for Aero Registration 1050 o Specification of MN-to-MSE message exchanges via the ANET access 1051 router as a proxy 1053 o IANA Considerations updated to include registration requests and 1054 set interim RFC4727 option type value. 1056 Differences from draft-templin-atn-aero-interface-03 to draft- 1057 templin-atn-aero-interface-04: 1059 o Removed MNP from aero option format - we already have RIOs and 1060 PIOs, and so do not need another option type to include a Prefix. 1062 o Clarified that the RA message response must include an aero option 1063 to indicate to the MN that the ANET provides a MS. 1065 o MTU interactions with link adaptation clarified. 1067 Differences from draft-templin-atn-aero-interface-02 to draft- 1068 templin-atn-aero-interface-03: 1070 o Sections re-arranged to match RFC4861 structure. 1072 o Multiple aero interfaces 1074 o Conceptual sending algorithm 1076 Differences from draft-templin-atn-aero-interface-01 to draft- 1077 templin-atn-aero-interface-02: 1079 o Removed discussion of encapsulation (out of scope) 1081 o Simplified MTU section 1083 o Changed to use a new IPv6 ND option (the "aero option") instead of 1084 S/TLLAO 1086 o Explained the nature of the interaction between the mobility 1087 management service and the air interface 1089 Differences from draft-templin-atn-aero-interface-00 to draft- 1090 templin-atn-aero-interface-01: 1092 o Updates based on list review comments on IETF 'atn' list from 1093 4/29/2019 through 5/7/2019 (issue tracker established) 1095 o added list of opportunities afforded by the single virtual link 1096 model 1098 o added discussion of encapsulation considerations to Section 6 1100 o noted that DupAddrDetectTransmits is set to 0 1102 o removed discussion of IPv6 ND options for prefix assertions. The 1103 aero address already includes the MNP, and there are many good 1104 reasons for it to continue to do so. Therefore, also including 1105 the MNP in an IPv6 ND option would be redundant. 1107 o Significant re-work of "Router Discovery" section. 1109 o New Appendix B on Prefix Length considerations 1111 First draft version (draft-templin-atn-aero-interface-00): 1113 o Draft based on consensus decision of ICAO Working Group I Mobility 1114 Subgroup March 22, 2019. 1116 Authors' Addresses 1118 Fred L. Templin (editor) 1119 The Boeing Company 1120 P.O. Box 3707 1121 Seattle, WA 98124 1122 USA 1124 Email: fltemplin@acm.org 1126 Tony Whyman 1127 MWA Ltd c/o Inmarsat Global Ltd 1128 99 City Road 1129 London EC1Y 1AX 1130 England 1132 Email: tony.whyman@mccallumwhyman.com