idnits 2.17.1 draft-templin-atn-aero-interface-04.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 (June 29, 2019) is 1756 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: December 31, 2019 MWA Ltd c/o Inmarsat Global Ltd 6 June 29, 2019 8 Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces 9 draft-templin-atn-aero-interface-04.txt 11 Abstract 13 Mobile nodes (e.g., aircraft of various configurations) communicate 14 with networked correspondents over multiple access network data links 15 and configure mobile routers to connect their on-board networks. 16 Mobile nodes configure a virtual interface (termed the "aero 17 interface") as a thin layer over their underlying data link 18 interfaces. This document specifies the transmission of IPv6 packets 19 over 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 December 31, 2019. 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 . . . . . . . . . . . . . . . . . . 6 60 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 6 62 8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 7 63 9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 9 64 10. Conceptual Sending Algorithm . . . . . . . . . . . . . . . . 9 65 10.1. Multiple Aero Interfaces . . . . . . . . . . . . . . . . 10 66 11. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 11 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 15.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Aero Option Extensions for Special-Purpose Links . . 15 74 Appendix B. Prefix Length Considerations . . . . . . . . . . . . 16 75 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 Mobile Nodes (MNs) such as aircraft of various configurations may 81 have multiple data links for communicating with networked 82 correspondents. These data links often have differing performance, 83 cost and availability characteristics that can change dynamically 84 according to mobility patterns, flight phases, proximity to 85 infrastructure, etc. 87 Each MN receives an IPv6 Mobile Network Prefix (MNP) that can be used 88 by on-board networks regardless of the access network data links 89 selected for data transport. The MN performs router discovery the 90 same as for customer edge routers [RFC7084], and acts as a mobile 91 router on behalf of its on-board networks. A virtual interface 92 (termed the "aero interface") is configured as a thin layer over the 93 underlying access network interfaces. 95 The aero interface is therefore the only interface abstraction 96 exposed to the IPv6 layer and behaves according to the Non-Broadcast, 97 Multiple Access (NBMA) interface principle, while underlying access 98 network interfaces appear as link layer communication channels in the 99 architecture. The aero interface connects to a virtual overlay cloud 100 service known as the "aero link". 102 Each aero link has one or more associated Mobility Service Prefixes 103 (MSPs) that identify the link. An MSP is an aggregated IPv6 prefix 104 from which aero link MNPs are derived. If the MN connects to 105 multiple aero links, then it configures a separate aero interface for 106 each link. 108 The aero interface interacts with the ground domain Mobility Service 109 (MS) through control message exchanges based on IPv6 Neighbor 110 Discovery [RFC4861]. The MS tracks MN movements and represents their 111 MNPs in a global routing or mapping system. 113 The aero interface provides a traffic engineering nexus for guiding 114 inbound and outbound traffic to the correct underlying interface(s). 115 The IPv6 layer sees the aero interface as a point of connection to 116 the aero link; if there are multiple aero links (i.e., multiple 117 MS's), the IPv6 layer will see multiple aero interfaces. 119 This document specifies the transmission of IPv6 packets [RFC8200] 120 and MN/MS control messaging over aeronautical ("aero") interfaces. 122 2. Terminology 124 The terminology in the normative references applies; especially, the 125 terms "link" and "interface" are the same as defined in the IPv6 126 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 128 The following terms are defined within the scope of this document: 130 Access Network (ANET) 131 a data link service network (e.g., an aviation radio access 132 network, satellite service provider network, cellular operator 133 network, etc.) protected by physical and/or link layer security. 134 Each ANET connects to outside Internetworks via border security 135 devices such as proxys, firewalls, packet filtering gateways, etc. 137 ANET interface 138 a node's attachment to a link in an ANET. 140 Internetwork (INET) 141 a connected network region with a coherent IP addressing plan that 142 provides transit forwarding services for ANET mobile nodes and 143 INET correspondents. Examples include private enterprise 144 networks, aviation networks and the global public Internet itself. 146 INET interface 147 a node's attachment to a link in an INET. 149 aero link 150 a virtual overlay cloud service configured over one or more INETs 151 and their connected ANETs. An aero link may comprise multiple 152 segments joined by bridges the same as for any link; the 153 addressing plans in each segment may be mutually exclusive and 154 managed by different administrative entities. 156 aero interface 157 a node's attachment to an aero link, and configured over one or 158 more underlying ANET/INET interfaces. 160 aero address 161 an IPv6 link-local address constructed as specified in Section 7, 162 and assigned to an aero interface. 164 3. Requirements 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. Lower case 169 uses of these words are not to be interpreted as carrying RFC2119 170 significance. 172 4. Aeronautical ("aero") Interface Model 174 An aero interface is a Mobile Node (MN) virtual interface configured 175 over one or more ANET interfaces, which may be physical (e.g., an 176 aeronautical radio link) or virtual (e.g., an Internet or higher- 177 layer "tunnel"). The MN coordinates with the aero link Mobility 178 Service (MS) through Router Solicitation (RS) / Router Advertisement 179 (RA) and Neighbor Solicitation (NS) / Neighbor Advertisement (NA) 180 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 RS/RA message exchange. This allows for timely adaptation 221 and service 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 5. Maximum Transmission Unit 241 The aero interface and all underlying ANET interfaces MUST configure 242 an MTU of at least 1280 bytes [RFC8200]. The aero interface SHOULD 243 configure an MTU based on the largest MTU among all ANET interfaces. 244 If the aero interface receives an RA message with an MTU option, it 245 configures this new value regardless of any ANET interface MTUs. 247 The aero interface can return internally-generated ICMPv6 "Packet Too 248 Big" messages for packets that are no larger than the aero interface 249 MTU but too large to traverse the selected underlying ANET interface. 250 This ensures that the MTU is adaptive and reflects the ANET interface 251 used for a given data flow. The underlying ANET interface can 252 instead employ link-layer fragmentation at a layer below IPv6 so that 253 packets as large as the aero interface MTU can be accommodated. This 254 ensures that no packets are lost due to a size restrction in either 255 the uplink or downlink direction. 257 6. Frame Format 259 The aero interface transmits IPv6 packets according to the native 260 frame format of each underlying ANET interface. For example, for an 261 Ethernet interface the frame format is exactly as specified in 262 [RFC2464], for tunnels over IPv6 the frame format is exactly as 263 specified in [RFC2473], etc. 265 7. Link-Local Addresses 267 A MN "aero address" is an IPv6 link-local address with an interface 268 identifier based on its assigned MNP. MN aero addresses begin with 269 the prefix fe80::/64 followed by a 64-bit prefix taken from the MNP 270 (see: Appendix B). For example, for the MNP: 272 2001:db8:1000:2000::/56 274 the corresponding aero addresses are: 276 fe80::2001:db8:1000:2000 278 fe80::2001:db8:1000:2001 280 fe80::2001:db8:1000:2002 282 ... etc. ... 284 fe80::2001:db8:1000:20ff 286 When the MN configures aero addresses from its MNP, it assigns them 287 to the aero interface. The lowest-numbered aero address serves as 288 the "base" address (for example, for the MNP 2001:db8:1000:2000::/56 289 the base aero address is fe80::2001:db8:1000:2000). The MN uses the 290 base aero address for IPv6 ND messaging, but accepts packets destined 291 to all aero addresses equally (i.e., the same as for any multi- 292 addressed IPv6 interface). 294 MS aero addresses are allocated from the range fe80::/96, and MUST be 295 managed for uniqueness by the collective aero link administrative 296 authorities. Each address represents a distinct service endpoint in 297 the MS. The lower 32 bits of the address includes a unique integer 298 value, e.g., fe80::1, fe80::2, fe80::3, etc. The address fe80:: is 299 reserved as the IPv6 link-local Subnet Router Anycast address 300 [RFC4291], and the address fe80::ffff:ffff is reserved as the 301 unspecified aero address; hence, these values are not available for 302 general assignment. 304 Since MN aero addresses are guaranteed unique by the nature of the 305 unique MNP delegation, aero interfaces set the autoconfiguration 306 variable DupAddrDetectTransmits to 0 [RFC4862]. 308 8. Address Mapping - Unicast 310 Each aero interface maintains a neighbor cache for tracking per- 311 neighbor state the same as for any IPv6 interface. The aero 312 interface uses standard IPv6 Neighbor Discovery (ND) messaging 313 [RFC4861]. 315 IPv6 ND messages on aero interfaces use the native Source/Target 316 Link-Layer Address Option (S/TLLAO) formats of the underlying ANET 317 interfaces (e.g., for Ethernet the S/TLLAO is specified in 318 [RFC2464]). 320 Aero interfaces also use the link-local address format specified in 321 Section 7, and aero interface IPv6 ND messages include aero options 322 formatted as shown in Figure 2: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length = 3 | Prefix Length |S|R|D| Reserved| 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | ifindex | Reserved | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 2: Aero Option Format 342 In this format: 344 o Type is set to TBD (to be assigned by IANA). 346 o Length is set to the constant value '3' (i.e., 3 units of 8 347 octets). 349 o Prefix Length is set to the length of the MNP embedded in the MN's 350 aero address. For RS messages, the MS validates the MNP 351 assertion, then announces the MNP in the routing system and 352 returns an RA withn aero option and a Router Lifetime set to the 353 MNP assertion lifetime. 355 o S (the 'Source' bit) is set to '1' in the aero options of an ND 356 message that correspond to the ANET interface over which the ND 357 message is sent, and set to '0' in all other aero options. 359 o R (the "Release" bit) is set to '1' in the aero option of an RS 360 message sent for the purpose of withdrawing from the MS; 361 otherwise, set to '0'. The MS withdraws the MNP, then returns an 362 RA with Router Lifetime set to '0'. 364 o D (the "Disable" bit) is set to '1' in the aero option of an RS 365 message for each ifIndex that is to be disabled in the recipient's 366 neighbor cache entry; otherwise, set to '0'. If the message 367 contains multiple aero options the D value in each option is 368 consulted. 370 o Both 'Reserved' fields are set to the value '0' on transmission. 372 o ifIndex is set to a 16-bit integer value corresponding to a 373 specific underlying ANET interface as discussed in [RFC2863]. 374 Once the MN has assigned an ifIndex to an ANET interface, the 375 assignment MUST remain unchanged until the MN disables the 376 interface. MNs MUST number each ifIndex with a value between '1' 377 and '0xffff', and RA messages sent by the MS MUST set ifIndex to 378 0. 380 o P(i) is a set of Preferences that correspond to the 64 381 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 382 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 383 ("medium") or '3' ("high") to indicate a QoS preference level for 384 ANET interface selection purposes. 386 MNs such as aircraft typically have many wireless data link types 387 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 388 etc.) with diverse performance, cost and availability properties. 389 From the perspective of ND, the aero interface would therefore appear 390 to have multiple link layer addresses. In that case, ND messages MAY 391 include multiple aero options - each with an ifIndex that corresponds 392 to a specific ANET interface. 394 When an ND message includes aero options, the options corresponding 395 to the underlying ANET interface used to transmit the message MUST 396 set S to '1'. 398 9. Address Mapping - Multicast 400 The multicast address mapping of the native underlying ANET interface 401 applies, and the ANET interacts with the MS for multicast forwarding 402 and group management purposes. 404 The mobile router on board the aircraft also serves as an IGMP/MLD 405 Proxy for its EUNs and/or hosted applications per [RFC4605] while 406 using the link layer address of the router as the link layer address 407 for all multicast packets. 409 10. Conceptual Sending Algorithm 411 The MN's IPv6 layer selects the outbound aero interface according to 412 standard IPv6 requirements. The aero interface maintains a default 413 route and a neighbor cache entry for MS endpoints, and may also 414 include additional neighbor cache entries created through other means 415 (e.g., Address Resolution, static configuration, etc.). 417 When the MN sends packets via a MS endpoint, it may receive a 418 Redirect message the same as for any IPv6 interface. When the MN 419 uses Address Resolution, the aero interface forwards NS messages to 420 an MS endpoint (see: Section 11) which acts as a link-layer 421 forwarding agent according to the NBMA link model. The resulting NA 422 message will provide link-layer address information for the neighbor. 423 When Neighbor Unreachability Detection is used, the NS/NA exchange 424 confirms reachability the same as for any IPv6 interface. 426 After a packet enters the aero interface, an outbound ANET interface 427 is selected based on traffic engineering information such as DSCP, 428 application port number, cost, performance, etc. Aero interface 429 traffic engineering could also be configured to perform replication 430 across multiple ANET interfaces for increased reliability at the 431 expense of packet duplication. 433 When a target neighbor has multiple link-layer addresses (each with a 434 different traffic engineering profile), the aero interface selects 435 ANET interfaces and neighbor link-layer addresses according to both 436 its own outbound preferences and the inbound preferences of the 437 target neighbor. 439 10.1. Multiple Aero Interfaces 441 MNs may associate with multiple MS instances concurrently. Each MS 442 instance represents a distinct aero link distinguished by its 443 associated MSPs. The MN configures a separate aero interface for 444 each link so that multiple interfaces (e.g., aero0, aero1, aero2, 445 etc.) are exposed to the IPv6 layer. 447 Depending on local policy and configuration, an MN may choose between 448 alternative active aero interfaces using a packet's DSCP, routing 449 information or static configuration. In particular, the MN can add 450 the MSPs received in Prefix Information Options (PIOs) [RFC4861] 451 [RFC8028] as guidance for aero interface selection based on per- 452 packet source addresses . 454 Each aero interface can be configured over the same or different sets 455 of ANET interfaces. Each ANET distinguishes between the different 456 aero links based on the MSPs represented in per-packet IPv6 457 addresses. 459 Multiple distinct aero links can therefore be used to support fault 460 tolerance, load balancing, reliability, etc. The architectural model 461 parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs 462 serve as (virtual) VLAN tags. 464 11. Router and Prefix Discovery 466 MNs interact with the MS through mobility extensions on first-hop 467 ANET Access Routers (ARs). MS extensions on ARs MUST examine the RS 468 messages received on an ANET interface. If the RS message includes 469 aero options, the MS is invoked and an appropriate RA message is 470 generated the same as for an IPv6 router. If the RS message does not 471 include aero options, the AR instead processes the RS message locally 472 the same as for an ordinary IPv6 link. 474 MNs configure aero interfaces that observe the properties discussed 475 in the previous section. The aero interface and its underlying 476 interfaces are said to be in either the "UP" or "DOWN" state 477 according to administrative actions in conjunction with the interface 478 connectivity status. An aero interface transitions to UP or DOWN 479 through administrative action and/or through state transitions of the 480 underlying interfaces. When a first underlying interface transitions 481 to UP, the aero interface also transitions to UP. When all 482 underlying interfaces transition to DOWN, the aero interface also 483 transitions to DOWN. 485 MNs coordinate with the MS through RS/RA exchanges via their aero 486 interfaces. When an aero interface transitions to UP, the MN sends 487 initial RS messages with aero options to assert its MNP and register 488 an initial set of underlying ANET interfaces that are also UP. The 489 MN sends additional RS messages to refresh MNP and/or router 490 lifetimes, and to register/deregister underlying ANET interfaces as 491 they transition to UP or DOWN. 493 The MS sends RA messages with configuration information in response 494 to a MN's RS message. The RA includes an aero option with ifIndex 495 set to 0, a Router Lifetime value and PIOs with (A; L=0) that include 496 MSPs for the link. The configuration information may also include 497 Route Information Options (RIO) options [RFC4191] with more-specific 498 routes, and an MTU option that specifies the maximum acceptable 499 packet size for the link. The MS sends immediate unicast RA 500 responses without delay; therefore, the 'MAX_RA_DELAY_TIME' and 501 'MIN_DELAY_BETWEEN_RAS' constants for multicast RAs do not apply. 502 The MS MAY send periodic and/or event-driven unsolicited RA messages, 503 but is not required to do so for unicast advertisements [RFC4861]. 505 The MN sends RS messages from within the aero interface while using 506 an UP underlying ANET interface as the outbound interface. Each 507 message is formatted as an ordinary RS message as though it 508 originated from the IPv6 layer, but the process is coordinated wholly 509 from within the aero interface and is therefore opaque to the IPv6 510 layer. The MN sends an initial RS message over an UP underlying 511 interface with its base aero address as the source address, all- 512 routers multicast as the destination address and with an aero option 513 with a valid Prefix Length and MNP. The aero option also sets S to 1 514 and contains valid ifIndex and P(i) values appropriate for the 515 underlying ANET interface. 517 When the MS receives the RS, it accepts the message if the prefix 518 assertion was acceptable; otherwise, it drops the message silently. 519 If the prefix assertion was accepted, the MS injects the MNP into the 520 routing/mapping system then caches the new ifIndex, Prefix Length, 521 MNP and P(i) values. The MS then returns an RA with the aero address 522 of an MS endpoint as the source address, the aero address of the MN 523 as the destination address, an aero option and with Router Lifetime 524 set to a non-zero value. 526 After the MN receives the initial RA confirming the MNP assertion, it 527 notes the aero address in the RA as the destination for all 528 subsequent RS messages it sends via this MS endpoint. If the MN 529 needs to change to a different MS endpoint, it discovers and uses a 530 different MS aero address. 532 The MN then manages its underlying ANET interfaces according to their 533 states as follows: 535 o When an underlying ANET interface transitions to UP, the MN sends 536 an RS over the ANET interface with its base aero address as the 537 source address, the MS aero address as the destination address, 538 and with one or more aero options. Aero options corresponding to 539 the ANET interface set S to 1 and contain valid ifIndex and P(i) 540 values appropriate for this ANET interface, while any additional 541 aero options set S to 0 and contain valid ifIndex and P(i) values 542 appropriate for other ANET interfaces. 544 o When an underlying ANET interface transitions to DOWN, the MN 545 sends an RS over any UP ANET interface with an aero option for the 546 DOWN ANET interface with D set to 1. The RS may include 547 additional aero options for additional ANET interfaces as above. 549 o When a MN wishes to release from the current MS endpoint, it sends 550 an RS message over any UP ANET interface with an aero option with 551 R set to 1. When the MS receives the RS message, it withdraws the 552 MNP from the routing/mapping system and returns an RA message with 553 Router Lifetime set to 0. 555 o When all of a MNs underlying interfaces have transitioned to DOWN, 556 the MS withdraws the MNP the same as if it had received an RS with 557 an aero option with R set to 1. 559 The MN is responsible for retrying each RS/RA exchange up to 560 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 561 seconds until an RA is received. If no RA is received over multiple 562 UP ANET interfaces, the MN declares this MS endpoint unreachable and 563 tries a different MS endpoint. 565 The IPv6 layer sees the aero interface as an ordinary IPv6 interface. 566 Therefore, when the IPv6 layer sends an RS message the aero interface 567 returns an internally-generated RA message as though the message 568 originated from an IPv6 router. The internally-generated RA message 569 contains configuration information (such as Router Lifetime, MTU, 570 etc.) that is consistent with the information received from the RAs 571 generated by the MS. 573 Whether the aero interface RS/RA process is initiated from the 574 receipt of an RS message from the IPv6 layer is an implementation 575 matter. Some implementations may elect to defer the RS/RA process 576 until an RS is received from the IPv6 layer, while others may elect 577 to initiate the RS/RA process independently of any IPv6 layer 578 messaging. 580 12. IANA Considerations 582 The IANA is instructed to allocate an IPv6 Neighbor Discovery option 583 type for the aero option in the IPv6 Neighbor Discovery Option 584 Formats registry. 586 13. Security Considerations 588 Security considerations are the same as defined for the specific 589 access network interface types, and readers are referred to the 590 appropriate interface specifications. 592 IPv6 and IPv6 ND security considerations also apply, and are 593 specified in the normative references. 595 14. Acknowledgements 597 This document was prepared per the consensus decision at the 8th 598 Conference of the International Civil Aviation Organization (ICAO) 599 Working Group-I Mobility Subgroup on March 22, 2019. Attendees and 600 contributors included: Guray Acar, Danny Bharj, Francois D'Humieres, 601 Pavel Drasil, Nikos Fistas, Giovanni Garofolo, Vaughn Maiolla, Tom 602 McParland, Victor Moreno, Madhu Niraula, Brent Phillips, Liviu 603 Popescu, Jacky Pouzet, Aloke Roy, Greg Saccone, Robert Segers, 604 Stephane Tamalet, Fred Templin, Bela Varkonyi, Tony Whyman, and 605 Dongsong Zeng. 607 The following individuals are acknowledged for their useful comments: 608 Pavel Drasil, Zdenek Jaron. 610 . 612 15. References 614 15.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 622 "Definition of the Differentiated Services Field (DS 623 Field) in the IPv4 and IPv6 Headers", RFC 2474, 624 DOI 10.17487/RFC2474, December 1998, 625 . 627 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 628 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 629 November 2005, . 631 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 632 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 633 2006, . 635 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 636 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 637 DOI 10.17487/RFC4861, September 2007, 638 . 640 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 641 Address Autoconfiguration", RFC 4862, 642 DOI 10.17487/RFC4862, September 2007, 643 . 645 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 646 Hosts in a Multi-Prefix Network", RFC 8028, 647 DOI 10.17487/RFC8028, November 2016, 648 . 650 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 651 (IPv6) Specification", STD 86, RFC 8200, 652 DOI 10.17487/RFC8200, July 2017, 653 . 655 15.2. Informative References 657 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 658 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 659 . 661 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 662 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 663 December 1998, . 665 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 666 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 667 . 669 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 670 "Internet Group Management Protocol (IGMP) / Multicast 671 Listener Discovery (MLD)-Based Multicast Forwarding 672 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 673 August 2006, . 675 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 676 Requirements for IPv6 Customer Edge Routers", RFC 7084, 677 DOI 10.17487/RFC7084, November 2013, 678 . 680 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 681 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 682 Boundary in IPv6 Addressing", RFC 7421, 683 DOI 10.17487/RFC7421, January 2015, 684 . 686 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 687 Support for IP Hosts with Multi-Access Support", RFC 7847, 688 DOI 10.17487/RFC7847, May 2016, 689 . 691 Appendix A. Aero Option Extensions for Special-Purpose Links 693 The aero option format specified in Section 8 includes a Length value 694 of 3 (i.e., 3 units of 8 octets). However, special-purpose aero 695 links may extend the basic format to include additional fields and a 696 Length value larger than 3. 698 For example, adaptation of the aero interface to the Aeronautical 699 Telecommunications Network with Internet Protocol Services (ATN/IPS) 700 includes link selection preferences based on transport port numbers 701 in addition to the existing DSCP-based preferences. ATN/IPS nodes 702 maintain a map of transport port numbers to 64 possible preference 703 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 704 maps to preference field 20, UDP port 8060 maps to preference field 705 34, etc. The extended aero option format for ATN/IPS is shown in 706 Figure 3, where the Length value is 7 and the 'Q(i)' fields provide 707 link preferences for the corresponding transport port number. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type | Length = 5 | Prefix Length |S|R|D| Reserved| 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | ifIndex | Reserved | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 3: ATN/IPS Extended Aero Option Format 735 Appendix B. Prefix Length Considerations 737 The IPv6 addressing architecture [RFC4291] reserves the prefix ::/8; 738 this assures that MNPs will not begin with ::32 so that MN and MS 739 aero addresses cannot overlap. Additionally, this specification 740 currently observes the 64-bit boundary in IPv6 addresses [RFC7421]. 742 MN aero addresses insert the most-significant 64 MNP bits into the 743 least-significant 64 bits of the prefix fe80::/64, however [RFC4291] 744 defines the link-local prefix as fe80::/10 meaning "fe80" followed by 745 54 unused bits followed by the least-significant 64 bits of the 746 address. Future versions of this specification may adapt the 54 747 unused bits for extended coding of MNP prefixes of /65 or longer (up 748 to /118). 750 Appendix C. Change Log 752 << RFC Editor - remove prior to publication >> 754 Differences from draft-templin-atn-aero-interface-03 to draft- 755 templin-atn-aero-interface-04: 757 o Removed MNP from aero option format - we already have RIOs and 758 PIOs, and so do not need another option type to include a Prefix. 760 o Clarified that the RA message response must include an aero option 761 to indicate to the MN that the ANET provides a MS. 763 o MTU interactions with link adaptation clarified. 765 Differences from draft-templin-atn-aero-interface-02 to draft- 766 templin-atn-aero-interface-03: 768 o Sections re-arranged to match RFC4861 structure. 770 o Multiple aero interfaces 772 o Conceptual sending algorithm 774 Differences from draft-templin-atn-aero-interface-01 to draft- 775 templin-atn-aero-interface-02: 777 o Removed discussion of encapsulation (out of scope) 779 o Simplified MTU section 781 o Changed to use a new IPv6 ND option (the "aero option") instead of 782 S/TLLAO 784 o Explained the nature of the interaction between the mobility 785 management service and the air interface 787 Differences from draft-templin-atn-aero-interface-00 to draft- 788 templin-atn-aero-interface-01: 790 o Updates based on list review comments on IETF 'atn' list from 791 4/29/2019 through 5/7/2019 (issue tracker established) 793 o added list of opportunities afforded by the single virtual link 794 model 796 o added discussion of encapsulation considerations to Section 6 797 o noted that DupAddrDetectTransmits is set to 0 799 o removed discussion of IPv6 ND options for prefix assertions. The 800 aero address already includes the MNP, and there are many good 801 reasons for it to continue to do so. Therefore, also including 802 the MNP in an IPv6 ND option would be redundant. 804 o Significant re-work of "Router Discovery" section. 806 o New Appendix B on Prefix Length considerations 808 First draft version (draft-templin-atn-aero-interface-00): 810 o Draft based on consensus decision of ICAO Working Group I Mobility 811 Subgroup March 22, 2019. 813 Authors' Addresses 815 Fred L. Templin (editor) 816 Boeing Research & Technology 817 P.O. Box 3707 818 Seattle, WA 98124 819 USA 821 Email: fltemplin@acm.org 823 Tony Whyman 824 MWA Ltd c/o Inmarsat Global Ltd 825 99 City Road 826 London EC1Y 1AX 827 England 829 Email: tony.whyman@mccallumwhyman.com