idnits 2.17.1 draft-templin-atn-aero-interface-08.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 (December 10, 2019) is 1592 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 857, 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 Boeing Research & Technology 4 Intended status: Standards Track A. Whyman 5 Expires: June 12, 2020 MWA Ltd c/o Inmarsat Global Ltd 6 December 10, 2019 8 Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces 9 draft-templin-atn-aero-interface-08.txt 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 June 12, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . 19 75 Appendix A. ARO Extensions for Pseudo-DSCP Mappings . . . . . . 21 76 Appendix B. Prefix Length Considerations . . . . . . . . . . . . 21 77 Appendix C. VDL Mode 2 Considerations . . . . . . . . . . . . . 22 78 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 22 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 inteface | 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 "Aero 387 Registration Option (ARO)". MNs invoke the MS by including an ARO in 388 Router Solicitation (RS) and (unsolicited) Neighbor Advertisement 389 (NA) messages, and the MS includes an ARO in unicast Router 390 Advertisement (RA) responses to an RS. 392 RS/NA messages sent by the MN include AROs formatted as shown in 393 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: Aero Registration Option (ARO) Format in RS/NA Messages 437 In this format: 439 o Type is set to TBD. 441 o Length is set to the number of 8 octet blocks in the option (with 442 zero-padding added to the end of the option if necessary to 443 produce an integral number of 8 octet blocks). 445 o Prefix Length is set to the length of the MNP embedded in the MN's 446 aero address. 448 o R (the "Register" bit) is set to '1' to assert the MNP 449 registration or set to '0' to request de-registration. 451 o Reserved is set to the value '0' on transmission. 453 o A set of N ANET interface "ifIndex-tuples" are included as 454 follows: 456 * ifIndex[i] is set to an 8-bit integer value corresponding to a 457 specific underlying ANET interface. The first ifIndex-tuple 458 MUST correspond to the ANET interface over which the message is 459 sent. Once the MN has assigned an ifIndex to an ANET 460 interface, the assignment MUST remain unchanged while the MN 461 remains registered in the network. MNs MUST number each 462 ifIndex with a value between '1' and '255' that represents a 463 MN-specific 8-bit mapping for the actual ifIndex value assigned 464 to the ANET interface by network management [RFC2863]. 466 * ifType[i] is set to an 8-bit integer value corresponding to the 467 underlying ANET interface identified by ifIndex. The value 468 represents an aero interface-specific 8-bit mapping for the 469 actual IANA ifType value assigned to the ANET interface by 470 network management [RFC2863]. 472 * Flags[i] is an 8-bit flags field. All flag bits are currently 473 undefined and set to the value '0' on transmission. Future 474 updates may specify new flags. 476 * Link[i] encodes a 4-bit link metric. The value '0' means the 477 link is DOWN, and the remaining values mean the link is UP with 478 metric ranging from '1' ("low") to '15' ("high"). 480 * QoS[i] encodes the number of 4-byte blocks (between '0' and 481 '15') of two-bit P[i] values that follow. The first 4 blocks 482 correspond to the 64 Differentiated Service Code Point (DSCP) 483 values P00 - P63 [RFC2474]. If additional 4-byte P[i] blocks 484 follow, their values correspond to "pseudo-DSCP" values P64, 485 P65, P66, etc. numbered consecutively. The pseudo-DSCP values 486 correspond to ancillary QoS information defined for the 487 specific aero interface (e.g., see Appendix A). 489 * P[i] includes zero or more per-ifIndex 4-byte blocks of two-bit 490 Preferences. Each P[i] field is set to the value '0' 491 ("disabled"), '1' ("low"), '2' ("medium") or '3' ("high") to 492 indicate a QoS preference level for ANET interface selection 493 purposes. The first four blocks always correspond to the 64 494 DSCP values. If one or more of the blocks are absent (e.g., 495 for QoS values 0,1,2,3) the P[i] values for the missing blocks 496 default to "medium". 498 Unicast RA messages sent by the MS in response to MN RS messages 499 include AROs formatted as shown in Figure 4: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type | Length = 1 | Prefix Length |R| Reserved | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | ifIndex | ifType | Flags | Link | QoS | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 4: Aero Registration Option (ARO) Format in RA messages 511 In this format: 513 o Type is set to TBD. 515 o Length is set to the constant value '1' (i.e., 1 unit of 8 516 octets). 518 o Prefix Length is set to the length associated with the aero 519 address of the destination MN. 521 o R is set to '1' to confirm registration or set to '0' to release/ 522 decline registration. 524 o ifIndex, ifType, Flags, Link and QoS echo the values of the same 525 fields that were received in the first ifIndex-tuple of the 526 soliciting RS. The echoed values provide a nonce that allows the 527 MN to associate the received RA with the soliciting RS. 529 9. Address Mapping - Multicast 531 The multicast address mapping of the native underlying ANET interface 532 applies. The mobile router on board the aircraft also serves as an 533 IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] 534 while using the link layer address of the router as the link layer 535 address for all multicast packets. 537 10. Address Mapping for IPv6 Neighbor Discovery Messages 539 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 540 unicast link-scoped IPv6 destination address. However, IPv6 ND 541 messaging must be coordinated between the MN and MS only without 542 invoking other nodes on the ANET. 544 For this reason, ANET links maintain unicast link-layer addresses 545 ("MSADDR") for the purpose of supporting MN/MS IPv6 ND messaging. 546 For Ethernet-compatible ANETs, this specification reserves one 547 Ethernet unicast address 00-00-5E-00-52-14. For non-Ethernet 548 statically-addressed ANETs, MSADDR is reserved per the assigned 549 numbers authority for the ANET addressing space. For still other 550 ANETs, MSADDR may be dynamically discovered through other means, 551 e.g., link-layer beacons. 553 MNs map all IPv6 ND messages they send (i.e., both multicast and 554 unicast) to an MSADDR instead of to an ordinary unicast or multicast 555 link-layer address. In this way, all of the MN's IPv6 ND messages 556 will be received by MS devices that are configured to accept packets 557 destined to MSADDR. Note that multiple MS devices on the link could 558 be configured to accept packets destined to MSADDR, e.g., as a basis 559 for supporting redundancy. 561 Therefore, ARs MUST accept and process packets destined to MSADDR, 562 while all other devices MUST NOT process packets destined to MSADDR. 563 This model has a well-established operational experience in Proxy 564 Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 566 11. Conceptual Sending Algorithm 568 The MN's IPv6 layer selects the outbound aero interface according to 569 standard IPv6 requirements. The aero interface maintains default 570 routes and neighbor cache entries for MSEs, and may also include 571 additional neighbor cache entries created through other means (e.g., 572 Address Resolution, static configuration, etc.). 574 After a packet enters the aero interface, an outbound ANET interface 575 is selected based on traffic engineering information such as DSCP, 576 application port number, cost, performance, message size, etc. Aero 577 interface traffic engineering could also be configured to perform 578 replication across multiple ANET interfaces for increased reliability 579 at the expense of packet duplication. 581 11.1. Multiple Aero Interfaces 583 MNs may associate with multiple MS instances concurrently. Each MS 584 instance represents a distinct aero link distinguished by its 585 associated MSPs. The MN configures a separate aero interface for 586 each link so that multiple interfaces (e.g., aero0, aero1, aero2, 587 etc.) are exposed to the IPv6 layer. 589 Depending on local policy and configuration, an MN may choose between 590 alternative active aero interfaces using a packet's DSCP, routing 591 information or static configuration. Interface selection based on 592 per-packet source addresses is also enabled when the MSPs for each 593 aero interface are known (e.g., discovered through Prefix Information 594 Options (PIOs) and/or Route Information Options (RIOs)). 596 Each aero interface can be configured over the same or different sets 597 of ANET interfaces. Each ANET distinguishes between the different 598 aero links based on the MSPs represented in per-packet IPv6 599 addresses. 601 Multiple distinct aero links can therefore be used to support fault 602 tolerance, load balancing, reliability, etc. The architectural model 603 parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs 604 serve as (virtual) VLAN tags. 606 12. Router Discovery and Prefix Registration 608 ARs process IPv6 ND messages destined to all-routers multicast, 609 subnet router anycast and unicast link-local IPv6 addresses. ARs 610 configure the link-layer address MSADDR (see: Section 10) and act as 611 a proxy for MSE addresses in the range fe80::1 through 612 fe80::ffff:fffe. 614 MNs interface with the MS by sending RS messages with AROs. For each 615 ANET interface, the MN sends RS messages with AROs with link-layer 616 destination address set to MSADDR and with network-layer destination 617 address set to either a specific MSE aero address, subnet router 618 anycast, or all-routers multicast. The MN discovers MSE addresses 619 either through an RA message response to an initial anycast/multicast 620 RS or before sending an initial RS message. [RFC5214] provides 621 example MSE address discovery methods, including information conveyed 622 during data link login, name service lookups, static configuration, 623 etc. 625 The AR receives the RS messages and contacts the corresponding MSE. 626 When the MSE responds, the AR returns an RA message with source 627 address set to the MSE address, with an ARO and with any information 628 for the link that would normally be delivered in a solicited RA 629 message. 631 MNs configure aero interfaces that observe the properties discussed 632 in the previous section. The aero interface and its underlying 633 interfaces are said to be in either the "UP" or "DOWN" state 634 according to administrative actions in conjunction with the interface 635 connectivity status. An aero interface transitions to UP or DOWN 636 through administrative action and/or through state transitions of the 637 underlying interfaces. When a first underlying interface transitions 638 to UP, the aero interface also transitions to UP. When all 639 underlying interfaces transition to DOWN, the aero interface also 640 transitions to DOWN. 642 When an aero interface transitions to UP, the MN sends initial RS 643 messages to register its MNP and an initial set of underlying ANET 644 interfaces that are also UP. The MN sends additional RS messages to 645 refresh lifetimes and to register/deregister underlying ANET 646 interfaces as they transition to UP or DOWN. 648 ARs coordinate with the MSE and return RA messages with configuration 649 information in response to a MN's RS messages. The RAs include a 650 Router Lifetime value and any necessary options, such as: 652 o PIOs with (A; L=0) that include MSPs for the link [RFC8028]. 654 o RIOs [RFC4191] with more-specific routes. 656 o an MTU option that specifies the maximum acceptable packet size 657 for the aero link 659 The AR sends immediate unicast RA responses without delay; therefore, 660 the 'MAX_RA_DELAY_TIME' and 'MIN_DELAY_BETWEEN_RAS' constants for 661 multicast RAs do not apply. The AR MAY send periodic and/or event- 662 driven unsolicited RA messages, but is not required to do so for 663 unicast advertisements [RFC4861]. 665 The MN sends RS messages from within the aero interface while using 666 an UP underlying ANET interface as the outbound interface. Each RS 667 message is formatted as though it originated from the IPv6 layer, but 668 the process is coordinated wholly from within the aero interface and 669 is therefore opaque to the IPv6 layer. The MN sends initial RS 670 messages over an UP underlying interface with its aero address as the 671 source. The RS messages include AROs with a valid Prefix Length as 672 well as ifIndex-tuples appropriate for underlying ANET interfaces. 673 The AR processes RS message and forwards the information in the ARO 674 to the MSE. 676 When the MSE processes the AR information, if the prefix registration 677 was accepted the MSE injects the MNP into the routing/mapping system 678 then caches the new Prefix Length, MNP and ifIndex-tuples. The MSE 679 then coordinates with the AR to return an RA message to the MN with 680 an ARO with a non-zero Router Lifetime if the prefix assertion was 681 acceptable; otherwise, with a zero Router Lifetime. 683 When the MN receives the RA message, it creates a default route with 684 next hop address set to the MSE found in the RA source address and 685 with link-layer address set to MSADDR. The AR will then forward 686 packets acting as a proxy between the MN and the MS. 688 The MN then manages its underlying ANET interfaces according to their 689 states as follows: 691 o When an underlying ANET interface transitions to UP, the MN sends 692 an RS over the ANET interface with an ARO. The ARO contains a 693 first ifIndex-tuple with values specific to this ANET interface, 694 and may contain additional ifIndex-tuples specific to other ANET 695 interfaces. 697 o When an underlying ANET interface transitions to DOWN, the MN 698 sends an RS or unsolicited NA message over any UP ANET interface 699 with an ARO containing an ifIndex-tuple for the DOWN ANET 700 interface with Link(i) set to '0'. The MN sends an RS when an 701 acknowledgement is required, or an unsolicited NA when reliability 702 is not thought to be a concern (e.g., if redundant transmissions 703 are sent on multiple ANET interfaces). 705 o When a MN wishes to release from a current MSE, it sends RS 706 messages over any UP ANET interfaces with an ARO with R set to 0. 707 The corresponding MSE then withdraws the MNP from the routing/ 708 mapping system and returns an RA message with an ARO with Router 709 Lifetime set to 0. 711 o When all of a MNs underlying interfaces have transitioned to DOWN, 712 the MSE withdraws the MNP the same as if it had received a message 713 with an ARO with R set to 0. 715 The MN is responsible for retrying each RS exchange up to 716 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 717 seconds until an RA is received. If no RA is received over multiple 718 UP ANET interfaces, the MN declares this MSE unreachable and tries a 719 different MSE. 721 The IPv6 layer sees the aero interface as an ordinary IPv6 interface. 722 Therefore, when the IPv6 layer sends an RS message the aero interface 723 returns an internally-generated RA message as though the message 724 originated from an IPv6 router. The internally-generated RA message 725 contains configuration information (such as Router Lifetime, MTU, 726 etc.) that is consistent with the information received from the RAs 727 generated by the MS. 729 Whether the aero interface IPv6 ND messaging process is initiated 730 from the receipt of an RS message from the IPv6 layer is an 731 implementation matter. Some implementations may elect to defer the 732 IPv6 ND messaging process until an RS is received from the IPv6 733 layer, while others may elect to initiate the process independently 734 of any IPv6 layer messaging. 736 13. Detecting and Responding to MSE Failures 738 In environments where fast recovery from MSE failure is required, ARs 739 SHOULD use Bidirectional Forwarding Detection (BFD) [RFC5880] to 740 track MSE reachability. Nodes that use BFD can quickly detect and 741 react to failures so that cached information is re-established 742 through alternate paths. BFD control messaging is carried only over 743 well-connected ground domain networks (i.e., and not low-end 744 aeronautical radio links) and can therefore be tuned for rapid 745 response. 747 ARs establish BFD sessions with MSEs for which there are currently 748 active ANET MNs. If an MSE fails, ARs can quickly inform MNs of the 749 outage by sending RA messages on the ANET interface. The AR sends RA 750 messages with source address set to the MSEs address, destination 751 address set to all-nodes multicast, and Router Lifetime set to 0. 752 The AR SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated 753 by small delays [RFC4861]. 755 Any MNs on the ANET interface that have been using the (now defunct) 756 MSE will receive the RA messages and associate with a new MSE. For 757 this reason, MNs SHOULD maintain multiple MSE associations so that 758 loss of a single MSE does not necessitate immediate ANET interface 759 control message signaling. 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. 800 . 802 17. References 804 17.1. Normative References 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 812 "Definition of the Differentiated Services Field (DS 813 Field) in the IPv4 and IPv6 Headers", RFC 2474, 814 DOI 10.17487/RFC2474, December 1998, 815 . 817 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 818 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 819 November 2005, . 821 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 822 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 823 2006, . 825 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 826 ICMPv6, UDP, and TCP Headers", RFC 4727, 827 DOI 10.17487/RFC4727, November 2006, 828 . 830 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 831 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 832 DOI 10.17487/RFC4861, September 2007, 833 . 835 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 836 Address Autoconfiguration", RFC 4862, 837 DOI 10.17487/RFC4862, September 2007, 838 . 840 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 841 Hosts in a Multi-Prefix Network", RFC 8028, 842 DOI 10.17487/RFC8028, November 2016, 843 . 845 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 846 (IPv6) Specification", STD 86, RFC 8200, 847 DOI 10.17487/RFC8200, July 2017, 848 . 850 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 851 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 852 DOI 10.17487/RFC8201, July 2017, 853 . 855 17.2. Informative References 857 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 858 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 859 . 861 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 862 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 863 . 865 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 866 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 867 December 1998, . 869 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 870 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 871 . 873 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 874 "Internet Group Management Protocol (IGMP) / Multicast 875 Listener Discovery (MLD)-Based Multicast Forwarding 876 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 877 August 2006, . 879 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 880 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 881 RFC 5213, DOI 10.17487/RFC5213, August 2008, 882 . 884 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 885 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 886 DOI 10.17487/RFC5214, March 2008, 887 . 889 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 890 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 891 . 893 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 894 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 895 2012, . 897 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 898 Requirements for IPv6 Customer Edge Routers", RFC 7084, 899 DOI 10.17487/RFC7084, November 2013, 900 . 902 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 903 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 904 Boundary in IPv6 Addressing", RFC 7421, 905 DOI 10.17487/RFC7421, January 2015, 906 . 908 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 909 Support for IP Hosts with Multi-Access Support", RFC 7847, 910 DOI 10.17487/RFC7847, May 2016, 911 . 913 Appendix A. ARO Extensions for Pseudo-DSCP Mappings 915 Adaptation of the aero interface to specific Internetworks such as 916 the Aeronautical Telecommunications Network with Internet Protocol 917 Services (ATN/IPS) includes link selection preferences based on 918 transport port numbers in addition to the existing DSCP-based 919 preferences. ATN/IPS nodes maintain a map of transport port numbers 920 to additional "pseudo-DSCP" P[i] preference fields beyond the first 921 64. For example, TCP port 22 maps to pseudo-DSCP value P67, TCP port 922 443 maps to P70, UDP port 8060 maps to P76, etc. Figure 5 shows an 923 example ARO with extended P[i] values beyond the base 64 used for 924 DSCP mapping (i.e., for QoS values 5 or greater): 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Type | Length | Prefix Length |R| Reserved | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | ifIndex | ifType | Flags | Link |QoS=5+ | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 |P64|P65|P66|P67|P68|P69|P70|P71|P72|P73|P74|P75|P76|P77|P78|P79| 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 ... 945 Figure 5: ATN/IPS Extended Aero Option Format 947 Appendix B. Prefix Length Considerations 949 The 64-bit boundary in IPv6 addresses [RFC7421] determines the MN 950 aero address format for encoding the most-significant 64 MNP bits 951 into the least-significant 64 bits of the prefix fe80::/64 as 952 discussed in Section 7. 954 [RFC4291] defines the link-local address format as fe80::/10,followed 955 by 54 unused bits, followed by the least-significant 64 bits of the 956 address. If the 64-bit boundary is relaxed through future standards 957 activity, then the 54 unused bits can be employed for extended coding 958 of MNPs of length /65 up to /118. 960 The extended coding format would continue to encode MNP bits 0-63 in 961 bits 64-127 of the aero address, while including MNP bits 64-117 in 962 bits 10-63. For example, the aero address corresponding to the MNP 963 2001:db8:1111:2222:3333:4444:5555::/112 would be 964 fe8c:ccd1:1115:5540:2001:db8:1111:2222, and would still be a valid 965 IPv6 link-local unicast address per [RFC4291]. 967 Appendix C. VDL Mode 2 Considerations 969 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 970 (VDLM2) that specifies an essential radio frequency data link service 971 for aircraft and ground stations in worldwide civil aviation air 972 traffic management. The VDLM2 link type is "multicast capable" 973 [RFC4861], but with considerable differences from common multicast 974 links such as Ethernet and IEEE 802.11. 976 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 977 magnitude less than most modern wireless networking gear. Second, 978 due to the low available link bandwidth only VDLM2 ground stations 979 (i.e., and not aircraft) are permitted to send broadcasts, and even 980 so only as compact layer 2 "beacons". Third, aircraft employ the 981 services of ground stations by performing unicast RS/RA exchanges 982 upon receipt of beacons instead of listening for multicast RA 983 messages and/or sending multicast RS messages. 985 This beacon-oriented unicast RS/RA approach is necessary to conserve 986 the already-scarce available link bandwidth. Moreover, since the 987 numbers of beaconing ground stations operating within a given spatial 988 range must be kept as sparse as possible, it would not be feasible to 989 have different classes of ground stations within the same region 990 observing different protocols. It is therefore highly desirable that 991 all ground stations observe a common language of RS/RA as specified 992 in this document. 994 Appendix D. Change Log 996 << RFC Editor - remove prior to publication >> 998 Differences from draft-templin-atn-aero-interface-07 to draft- 999 templin-atn-aero-interface-08: 1001 o Removed "Classic" and "MS-enabled" link model discussion 1003 o Added new figure for MN/AR/MSE model. 1005 o New Section on "Detecting and responding to MSE failure". 1007 Differences from draft-templin-atn-aero-interface-06 to draft- 1008 templin-atn-aero-interface-07: 1010 o Removed "nonce" field from AR option format. Applications that 1011 require a nonce can include a standard nonce option if they want 1012 to. 1014 o Various editorial cleanups. 1016 Differences from draft-templin-atn-aero-interface-05 to draft- 1017 templin-atn-aero-interface-06: 1019 o New Appendix C on "VDL Mode 2 Considerations" 1021 o New Appendix D on "RS/RA Messaging as a Single Standard API" 1023 o Various significant updates in Section 5, 10 and 12. 1025 Differences from draft-templin-atn-aero-interface-04 to draft- 1026 templin-atn-aero-interface-05: 1028 o Introduced RFC6543 precedent for focusing IPv6 ND messaging to a 1029 reserved unicast link-layer address 1031 o Introduced new IPv6 ND option for Aero Registration 1033 o Specification of MN-to-MSE message exchanges via the ANET access 1034 router as a proxy 1036 o IANA Considerations updated to include registration requests and 1037 set interim RFC4727 option type value. 1039 Differences from draft-templin-atn-aero-interface-03 to draft- 1040 templin-atn-aero-interface-04: 1042 o Removed MNP from aero option format - we already have RIOs and 1043 PIOs, and so do not need another option type to include a Prefix. 1045 o Clarified that the RA message response must include an aero option 1046 to indicate to the MN that the ANET provides a MS. 1048 o MTU interactions with link adaptation clarified. 1050 Differences from draft-templin-atn-aero-interface-02 to draft- 1051 templin-atn-aero-interface-03: 1053 o Sections re-arranged to match RFC4861 structure. 1055 o Multiple aero interfaces 1057 o Conceptual sending algorithm 1059 Differences from draft-templin-atn-aero-interface-01 to draft- 1060 templin-atn-aero-interface-02: 1062 o Removed discussion of encapsulation (out of scope) 1064 o Simplified MTU section 1066 o Changed to use a new IPv6 ND option (the "aero option") instead of 1067 S/TLLAO 1069 o Explained the nature of the interaction between the mobility 1070 management service and the air interface 1072 Differences from draft-templin-atn-aero-interface-00 to draft- 1073 templin-atn-aero-interface-01: 1075 o Updates based on list review comments on IETF 'atn' list from 1076 4/29/2019 through 5/7/2019 (issue tracker established) 1078 o added list of opportunities afforded by the single virtual link 1079 model 1081 o added discussion of encapsulation considerations to Section 6 1083 o noted that DupAddrDetectTransmits is set to 0 1085 o removed discussion of IPv6 ND options for prefix assertions. The 1086 aero address already includes the MNP, and there are many good 1087 reasons for it to continue to do so. Therefore, also including 1088 the MNP in an IPv6 ND option would be redundant. 1090 o Significant re-work of "Router Discovery" section. 1092 o New Appendix B on Prefix Length considerations 1094 First draft version (draft-templin-atn-aero-interface-00): 1096 o Draft based on consensus decision of ICAO Working Group I Mobility 1097 Subgroup March 22, 2019. 1099 Authors' Addresses 1101 Fred L. Templin (editor) 1102 Boeing Research & Technology 1103 P.O. Box 3707 1104 Seattle, WA 98124 1105 USA 1107 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