idnits 2.17.1 draft-templin-intarea-6706bis-16.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 : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 1760 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) == Unused Reference: 'I-D.ietf-intarea-gue-extensions' is defined on line 3000, but no explicit reference was found in the text == Unused Reference: 'RFC2764' is defined on line 3076, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 3128, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 3163, but no explicit reference was found in the text == Unused Reference: 'RFC7269' is defined on line 3246, but no explicit reference was found in the text == Unused Reference: 'RFC8086' is defined on line 3262, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-15) exists of draft-ietf-dmm-distributed-mobility-anchoring-13 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-07 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-26) exists of draft-ietf-rtgwg-atn-bgp-02 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-08 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-24 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 15 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 Obsoletes: rfc5320, rfc5558, rfc5720, June 29, 2019 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: December 31, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-16.txt 13 Abstract 15 This document specifies the operation of IP over tunnel virtual links 16 using Asymmetric Extended Route Optimization (AERO). AERO interfaces 17 use an IPv6 link-local address format that supports operation of the 18 IPv6 Neighbor Discovery (ND) protocol and links ND to IP forwarding. 19 Prefix delegation services are employed for network admission and to 20 manage the routing system. Multilink operation, mobility management, 21 quality of service (QoS) signaling and route optimization are 22 naturally supported through dynamic neighbor cache updates. Standard 23 IP multicasting services are also supported. AERO is a widely- 24 applicable tunneling solution especially well-suited to aviation 25 services, mobile Virtual Private Networks (VPNs) and many other 26 applications. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 31, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 10 65 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 10 66 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 12 67 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 13 68 3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 15 69 3.5. Spanning Partitioned AERO Networks (SPAN) . . . . . . . . 17 70 3.6. AERO Interface Characteristics . . . . . . . . . . . . . 21 71 3.7. AERO Interface Initialization . . . . . . . . . . . . . . 24 72 3.7.1. AERO Server/Gateway Behavior . . . . . . . . . . . . 25 73 3.7.2. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 25 74 3.7.3. AERO Client Behavior . . . . . . . . . . . . . . . . 25 75 3.7.4. AERO Relay Behavior . . . . . . . . . . . . . . . . . 26 76 3.8. AERO Interface Neighbor Cache Maintenance . . . . . . . . 26 77 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 28 78 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 29 79 3.11. AERO Interface Data Origin Authentication . . . . . . . . 29 80 3.12. AERO Interface Forwarding Algorithm . . . . . . . . . . . 30 81 3.12.1. Client Forwarding Algorithm . . . . . . . . . . . . 31 82 3.12.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 31 83 3.12.3. Server/Gateway Forwarding Algorithm . . . . . . . . 32 84 3.12.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 34 85 3.13. AERO Interface MTU and Fragmentation . . . . . . . . . . 34 86 3.13.1. MTU and Fragmentation in the ATN/IPS . . . . . . . . 37 87 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 37 88 3.15. AERO Router Discovery, Prefix Delegation and 89 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 40 90 3.15.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 40 91 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 41 92 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 43 94 3.16. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . 45 95 3.17. AERO Route Optimization . . . . . . . . . . . . . . . . . 47 96 3.17.1. Route Optimization Initiation . . . . . . . . . . . 48 97 3.17.2. Relaying the NS . . . . . . . . . . . . . . . . . . 48 98 3.17.3. Processing the NS and Sending the NA . . . . . . . . 48 99 3.17.4. Relaying the NA . . . . . . . . . . . . . . . . . . 49 100 3.17.5. Processing the NA . . . . . . . . . . . . . . . . . 49 101 3.17.6. Route Optimization Maintenance . . . . . . . . . . . 49 102 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 50 103 3.19. Mobility Management and Quality of Service (QoS) . . . . 51 104 3.19.1. Mobility Update Messaging . . . . . . . . . . . . . 52 105 3.19.2. Announcing Link-Layer Address and/or QoS Preference 106 Changes . . . . . . . . . . . . . . . . . . . . . . 52 107 3.19.3. Bringing New Links Into Service . . . . . . . . . . 53 108 3.19.4. Removing Existing Links from Service . . . . . . . . 53 109 3.19.5. Moving to a New Server . . . . . . . . . . . . . . . 53 110 3.20. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 54 111 3.20.1. Source-Specific Multicast (SSM) . . . . . . . . . . 55 112 3.20.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 56 113 3.20.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 57 114 3.21. Operation over Multiple AERO Links (VLANs) . . . . . . . 57 115 3.22. DNS Considerations . . . . . . . . . . . . . . . . . . . 58 116 3.23. Transition Considerations . . . . . . . . . . . . . . . . 58 117 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 59 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 119 6. Security Considerations . . . . . . . . . . . . . . . . . . . 59 120 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 122 8.1. Normative References . . . . . . . . . . . . . . . . . . 63 123 8.2. Informative References . . . . . . . . . . . . . . . . . 64 124 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 70 125 Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 72 126 Appendix C. Non-Normative Considerations . . . . . . . . . . . . 73 127 C.1. Implementation Strategies for Route Optimization . . . . 73 128 C.2. Implicit Mobility Management . . . . . . . . . . . . . . 74 129 C.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 74 130 C.4. AERO Clients on the Open Internetwork . . . . . . . . . . 75 131 C.5. Operation on AERO Links with /64 ASPs . . . . . . . . . . 75 132 C.6. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . 76 133 C.7. AERO Critical Infrastructure Considerations . . . . . . . 76 134 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 77 135 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 82 137 1. Introduction 139 Asymmetric Extended Route Optimization (AERO) fulfills the 140 requirements of Distributed Mobility Management (DMM) [RFC7333] and 141 route optimization [RFC5522] for aeronautical networking and other 142 network mobility use cases. AERO is based on a Non-Broadcast, 143 Multiple Access (NBMA) virtual link model known as the AERO link. 144 The AERO link is configured over one or more underlying 145 Internetworks, and nodes on the link can exchange IP packets via 146 tunneling. Multilink operation allows for increased reliability, 147 bandwidth optimization and traffic path diversity. 149 The AERO service comprises Clients, Proxys, Servers, and Gateways 150 that are seen as AERO link neighbors. Each node's AERO interface 151 uses an IPv6 link-local address format (known as the AERO address) 152 that supports operation of the IPv6 Neighbor Discovery (ND) protocol 153 [RFC4861] and links ND to IP forwarding. A node's AERO interface can 154 be configured over multiple underlying interfaces, and may therefore 155 may appear as a single interface with multiple link-layer addresses. 156 Each link-layer address is subject to change due to mobility and/or 157 QoS fluctuations, and link-layer address changes are signaled by ND 158 messaging the same as for any IPv6 link. 160 AERO links provide a cloud-based service where mobile nodes may use 161 any Server acting as a Mobility Anchor Point (MAP) and fixed nodes 162 may use any Gateway on the link for efficient communications. Fixed 163 nodes forward packets destined to other AERO nodes to the nearest 164 Gateway, which forwards them through the cloud. A mobile node's 165 initial packets are forwarded through the MAP, while direct routing 166 is supported through asymmetric route optimization while data packets 167 are flowing. Both unicast and multicast communications are 168 supported, and mobile nodes may efficiently move between locations 169 while maintaining continuous communications with correspondents and 170 without changing their IP Address. 172 AERO Relays are interconnected in a secured private BGP overlay 173 routing instance known as the "SPAN". The SPAN provides a hybrid 174 routing/bridging service to join the underlying Internetworks of 175 multiple disjoint administrative domains into a single unified AERO 176 link. Each AERO link instance is characterized by the set of 177 Mobility Service Prefixes (MSPs) common to all mobile nodes. The 178 link should extend to the point where a Gateway/MAP is on the optimal 179 route from any correspondent node on the link, and provides a gateway 180 between the underlying Internetwork and the SPAN. To the underlying 181 Internetwork, the Gateway/MAP is the source of a route to its MSP, 182 and hence uplink traffic to the mobile node is naturally routed to 183 the nearest Gateway/MAP. 185 AERO assumes the use of PIM Sparse Mode in support of multicast 186 communication. In support of Source Specific Multicast (SSM) when a 187 Mobile Node is the source, AERO route optimization ensures that a 188 shortest-path multicast tree is established with provisions for 189 mobility and multilink operation. In all other multicast scenarios 190 there are no AERO dependencies. 192 AERO was designed for aeronautical networking for both manned and 193 unmanned aircraft, where the aircraft is treated as a mobile node 194 that can connect an Internet of Things (IoT). AERO is also 195 applicable to a wide variety of other use cases. For example, it can 196 be used to coordinate the Virtual Private Network (VPN) links of 197 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 198 connect into a home enterprise network via public access networks 199 using services such as OpenVPN [OVPN]. Other applicable use cases 200 are also in scope. 202 The following numbered sections present the AERO specification. The 203 appendices at the end of the document are non-normative. 205 2. Terminology 207 The terminology in the normative references applies; the following 208 terms are defined within the scope of this document: 210 IPv6 Neighbor Discovery (ND) 211 an IPv6 control message service for coordinating neighbor 212 relationships between nodes connected to a common link. AERO 213 interfaces use the ND service specified in [RFC4861]. 215 IPv6 Prefix Delegation (PD) 216 a networking service for delegating IPv6 prefixes to nodes on the 217 link. The nominal PD service is DHCPv6 [RFC8415], however 218 alternate services (e.g., based on ND messaging) are also in scope 219 [I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt]. Most 220 notably, a form of PD known as "Prefix Assertion" can be used if 221 the prefix can be represented in the IPv6 source address of an ND 222 message. 224 Access Network (ANET) 225 a node's first-hop data link service network, e.g., a radio access 226 network, cellular service provider network, corporate enterprise 227 network, or the public Internet itself. For secured ANETs, link- 228 layer security services such as IEEE 802.1X and physical-layer 229 security prevent unauthorized access internally while border 230 network-layer security services such as firewalls and proxies 231 prevent unauthorized outside access. 233 ANET interface 234 a node's attachment to a link in an ANET. 236 ANET address 237 an IP address assigned to a node's interface connection to an 238 ANET. 240 Internetwork (INET) 241 a connected IP network topology with a coherent routing and 242 addressing plan and that provides an Internetworking backbone 243 service. INETs also provide an underlay service over which the 244 AERO virtual link is configured. Example INETs include corporate 245 enterprise networks, aviation networks, and the public Internet 246 itself. When there is no administrative boundary between an ANET 247 and the INET, the ANET and INET are one and the same. 249 INET Partition 250 frequently, INETs such as large corporate enterprise networks are 251 sub-divided internally into separate isolated partitions. Each 252 partition is fully connected internally but disconnected form 253 other partitions, and there is no requirement that separate 254 partitions maintain consistent Internet Protocol and/or addressing 255 plans. (An INET partition is the same as a SPAN segment discussed 256 below.) 258 INET interface 259 a node's attachment to a link in an INET. 261 INET address 262 an IP address assigned to a node's interface connection to an 263 INET. 265 AERO link 266 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 267 configured over one or more underlying INETs. Nodes on the AERO 268 link appear as single-hop neighbors from the perspective of the 269 virtual overlay even though they may be separated by many 270 underlying INET hops. AERO links may be configured over multiple 271 underlying SPAN segments (see below). 273 AERO interface 274 a node's attachment to an AERO link. Since the addresses assigned 275 to an AERO interface are managed for uniqueness, AERO interfaces 276 do not require Duplicate Address Detection (DAD) and therefore set 277 the administrative variable 'DupAddrDetectTransmits' to zero 278 [RFC4862]. 280 AERO address 281 an IPv6 link-local address assigned to an AERO interface and 282 constructed as specified in Section 3.4. 284 base AERO address 285 the lowest-numbered AERO address aggregated by the MNP (see 286 Section 3.4). 288 Mobility Service Prefix (MSP) 289 an IP prefix assigned to the AERO link and from which more- 290 specific Mobile Network Prefixes (MNPs) are derived. 292 Mobile Network Prefix (MNP) 293 an IP prefix allocated from an MSP and delegated to an AERO Client 294 or Gateway. 296 AERO node 297 a node that is connected to an AERO link, or that provides 298 services to other nodes on an AERO link. 300 AERO Client ("Client") 301 an AERO node that connects to one or more ANETs and requests MNP 302 PDs from AERO Servers. Following PD, the Client assigns a Client 303 AERO address to the AERO interface for use in ND exchanges with 304 other AERO nodes and forwards packets to correspondents according 305 to AERO interface neighbor cache state. 307 AERO Server ("Server") 308 an INET node that configures an AERO interface to provide default 309 forwarding services and a Mobility Anchor Point (MAP) for AERO 310 Clients. The Server assigns an administratively-provisioned AERO 311 address to the AERO interface to support the operation of the ND/ 312 PD services, and advertises all of its associated MNPs via BGP 313 peerings with Relays. 315 AERO Gateway ("Gateway") 316 an AERO Server that also provides forwarding services between 317 nodes reached via the AERO link and correspondents on other links. 318 AERO Gateways are provisioned with MNPs (i.e., the same as for an 319 AERO Client) and run a dynamic routing protocol to discover any 320 non-MNP IP routes. In both cases, the Gateway advertises the 321 MSP(s) over INET interfaces, and distributes all of its associated 322 MNPs and non-MNP IP routes via BGP peerings with Relays (i.e., the 323 same as for an AERO Server). 325 AERO Relay ("Relay") 326 a node that provides hybrid routing/bridging services (as well as 327 a security trust anchor) for nodes on an AERO link. As a router, 328 the Relay forwards packets using standard IP forwarding. As a 329 bridge, the Relay forwards packets over the AERO link without 330 decrementing the IPv6 Hop Limit. AERO Relays peer with Servers 331 and other Relays to discover the full set of MNPs for the link as 332 well as any non-MNPs that are reachable via Gateways. 334 AERO Proxy ("Proxy") 335 a node that provides proxying services between Clients in an ANET 336 and Servers in external INETs. The AERO Proxy is a conduit 337 between the ANET and external INETs in the same manner as for 338 common web proxies, and behaves in a similar fashion as for ND 339 proxies [RFC4389]. 341 Spanning Partitioned AERO Networks (SPAN) 342 a means for bridging disjoint INET partitions as segments of a 343 unified AERO link the same as for a bridged campus LAN. The SPAN 344 is a mid-layer IPv6 encapsulation service in the AERO routing 345 system that supports a unified AERO link view for all segments. 346 Each segment in the SPAN is a distinct INET partition. 348 SPAN Service Prefix (SSP) 349 a global or unique local /96 IPv6 prefix assigned to the AERO link 350 to support SPAN services. 352 SPAN Partition Prefix (SPP) 353 a sub-prefix of the SPAN Service Prefix uniquely assigned to a 354 single SPAN segment. 356 SPAN Address 357 a global or unique local IPv6 address taken from a SPAN Partition 358 Prefix and constructed as specified in Section 3.5. SPAN 359 addresses are statelessly derived from AERO addresses, and vice- 360 versa. 362 ingress tunnel endpoint (ITE) 363 an AERO interface endpoint that injects encapsulated packets into 364 an AERO link. 366 egress tunnel endpoint (ETE) 367 an AERO interface endpoint that receives encapsulated packets from 368 an AERO link. 370 link-layer address 371 an IP address used as an encapsulation header source or 372 destination address from the perspective of the AERO interface. 373 When UDP encapsulation is used, the UDP port number is also 374 considered as part of the link-layer address. From the 375 perspective of the AERO interface, the link-layer address is 376 either an INET address for intra-segment encapsulation or a SPAN 377 address for inter-segment encapsulation. 379 network layer address 380 the source or destination address of an encapsulated IP packet 381 presented to the AERO interface. 383 end user network (EUN) 384 an internal virtual or external edge IP network that an AERO 385 Client or Gateway connects to the rest of the network via the AERO 386 interface. The Client/Gateway sees each EUN as a "downstream" 387 network, and sees the AERO interface as the point of attachment to 388 the "upstream" network. 390 Mobile Node (MN) 391 an AERO Client and all of its downstream-attached networks that 392 move together as a single unit, i.e., an end system that connects 393 an Internet of Things. 395 Mobile Router (MR) 396 a MN's on-board router that forwards packets between any 397 downstream-attached networks and the AERO link. 399 Mobility Anchor Point (MAP) 400 an AERO Server that is currently tracking and reporting the 401 mobility events of its associated Mobile Node Clients. 403 Route Optimization Source (ROS) 404 the AERO node nearest the source that initiates route 405 optimization. The ROS may be a Server or Proxy acting on behalf 406 of the source Client. 408 Route Optimization responder (ROR) 409 the AERO node nearest the target destination that responds to 410 route optimization requests. The ROR may be a Server acting as a 411 MAP on behalf of a target MNP Client, or a Gateway for a non-MNP 412 destination. 414 MAP List 415 a geographically and/or topologically referenced list of AERO 416 addresses of all MAPs within the same AERO link. There is a 417 single MAP list for the entire AERO link. 419 ROS List 420 a list of AERO/SPAN-to-INET address mappings of all ROSes within 421 the same SPAN segment. There is a distinct ROS list for each 422 segment. 424 Distributed Mobility Management (DMM) 425 a BGP-based overlay routing service coordinated by Servers and 426 Relays that tracks all MAP-to-Client associations. 428 Throughout the document, the simple terms "Client", "Server", 429 "Relay", "Proxy" and "Gateway" refer to "AERO Client", "AERO Server", 430 "AERO Relay", "AERO Proxy" and "AERO Gateway", respectively. 432 Capitalization is used to distinguish these terms from other common 433 Internetworking uses in which they appear without capitalization. 435 The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including 436 the names of node variables, messages and protocol constants) is used 437 throughout this document. Also, the term "IP" is used to generically 438 refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or 439 IPv6 [RFC8200]. 441 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 442 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 443 document are to be interpreted as described in [RFC2119]. Lower case 444 uses of these words are not to be interpreted as carrying RFC2119 445 significance. 447 3. Asymmetric Extended Route Optimization (AERO) 449 The following sections specify the operation of IP over Asymmetric 450 Extended Route Optimization (AERO) links: 452 3.1. AERO Link Reference Model 453 +----------------+ 454 | AERO Relay R1 | 455 | Nbr: S1, S2, P1| 456 |(X1->S1; X2->S2)| 457 | MSP M1 | 458 +-+---------+--+-+ 459 +--------------+ | Secured | | +--------------+ 460 |AERO Server S1| | tunnels | | |AERO Server S2| 461 | Nbr: C1, R1 +-----+ | +-----+ Nbr: C2, R1 | 462 | default->R1 | | | default->R1 | 463 | X1->C1 | | | X2->C2 | 464 +-------+------+ | +------+-------+ 465 | AERO Link | | 466 X---+---+-------------------+--)---------------+---+---X 467 | | | | 468 +-----+--------+ +--------+--+-----+ +--------+-----+ 469 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 470 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 471 | default->S1 | +--------+--------+ | default->S2 | 472 | MNP X1 | | | MNP X2 | 473 +------+-------+ .--------+------. +-----+--------+ 474 | (- Proxyed Clients -) | 475 .-. `---------------' .-. 476 ,-( _)-. ,-( _)-. 477 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 478 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 479 `-(______)-' +-------+ +-------+ `-(______)-' 481 Figure 1: AERO Link Reference Model 483 Figure 1 presents the AERO link reference model. In this model: 485 o the AERO link is an overlay network service configured over one or 486 more underlying INET partitions which may be managed by different 487 administrative authorities and have incompatible protocols and/or 488 addressing plans. 490 o AERO Relay R1 aggregates Mobility Service Prefix (MSP) M1, 491 discovers Mobile Network Prefixes (MNPs) X* and advertises the MSP 492 via BGP peerings over secured tunnels to Servers (S1, S2). Relays 493 use the SPAN service to bridge disjoint segments of a partitioned 494 AERO link. 496 o AERO Servers S1 and S2 configure secured tunnels with Relay R1 and 497 also act as Mobility Anchor Points (MAPs) and default routers for 498 their associated Clients C1 and C2. 500 o AERO Clients C1 and C2 associate with Servers S1 and S2, 501 respectively. They receive Mobile Network Prefix (MNP) 502 delegations X1 and X2, and also act as default routers for their 503 associated physical or internal virtual EUNs. Simple hosts H1 and 504 H2 attach to the EUNs served by Clients C1 and C2, respectively. 506 o AERO Proxy P1 configures a secured tunnel with Relay R1 and 507 provides proxy services for AERO Clients in secured enclaves that 508 cannot associate directly with other AERO link neighbors. 510 Each node on the AERO link maintains an AERO interface neighbor cache 511 and an IP forwarding table the same as for any link. Although the 512 figure shows a limited deployment, in common operational practice 513 there will normally be many additional Relays, Servers, Clients and 514 Proxys. 516 3.2. AERO Node Types 518 AERO Relays provide hybrid routing/bridging services (as well as a 519 security trust anchor) for nodes on an AERO link. Relays use 520 standard IPv6 routing to forward packets both within the same INET 521 partitions and between disjoint INET partitions based on a mid-layer 522 IPv6 encapsulation known as the SPAN header. The inner IP layer 523 experiences a virtual bridging service since the inner IP TTL/Hop 524 Limit is not decremented during forwarding. Each Relay also peers 525 with Servers and other Relays in a dynamic routing protocol instance 526 to provide a Distributed Mobility Management (DMM) service for the 527 list of active MNPs (see Section 3.3). Relays present the AERO link 528 as a set of one or more Mobility Service Prefixes (MSPs) but as link- 529 layer devices need not connect directly to the AERO link themselves 530 unless an administrative interface is desired. Relays configure 531 secured tunnels with Servers, Proxys and other Relays; they further 532 maintain IP forwarding table entries for each Mobile Network Prefix 533 (MNP) and any other reachable non-MNP prefixes. 535 AERO Servers provide default forwarding services and a Mobility 536 Anchor Point (MAP) for AERO Client Mobile Nodes (MNs). Each Server 537 also peers with Relays in a dynamic routing protocol instance to 538 advertise its list of associated MNPs (see Section 3.3). Servers 539 facilitate PD exchanges with Clients, where each delegated prefix 540 becomes an MNP taken from an MSP. Servers forward packets between 541 AERO interface neighbors and track each Client's mobility profiles. 543 AERO Clients receive MNPs through PD exchanges with AERO Servers over 544 the AERO link, and distribute the MNPs to nodes on EUNs. Each Client 545 can associate with a single Server or with multiple Servers (e.g., 546 for fault tolerance, load balancing, etc). A Client may also be co- 547 resident on the same physical or virtual platform as a Server; in 548 that case, the Client and Server behave as a single functional unit 549 and without the need for any Client/Server control messaging. 551 AERO Proxys provide a conduit for AERO Clients in ANETs to associate 552 with AERO Servers in external INETs. Client and Servers exchange 553 control plane messages via the Proxy, which intercepts them at the 554 ANET/INET boundary. The Proxy forwards data packets to and from 555 Clients according to forwarding information in the neighbor cache. 556 The Proxy function is specified in Section 3.16. 558 AERO Gateways are Servers that provide forwarding services between 559 the AERO interface and INET/EUN interfaces. Gateways are provisioned 560 with MNPs the same as for an AERO Client, and also run a dynamic 561 routing protocol to discover any non-MNP IP routes. The Gateway 562 advertises the MSP(s) to INETs, and distributes all of its associated 563 MNPs and non-MNP IP routes via BGP peerings with Relays. 565 AERO Relays, Servers, Proxys and Gateways are critical infrastructure 566 elements in fixed (i.e., non-mobile) INET deployments and hence have 567 permanent and unchanging INET addresses. AERO Clients are MNs that 568 connect via ANET interfaces, i.e., their ANET addresses may change 569 when the Client moves to a new ANET connection. 571 3.3. AERO Routing System 573 The AERO routing system comprises a private instance of the Border 574 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 575 and Servers and does not interact with either the public Internet BGP 576 routing system or any underlying INET routing systems. 578 In a reference deployment, each Server is configured as an Autonomous 579 System Border Router (ASBR) for a stub Autonomous System (AS) using 580 an AS Number (ASN) that is unique within the BGP instance, and each 581 Server further uses eBGP to peer with one or more Relays but does not 582 peer with other Servers. Each INET of a multi-segment AERO link must 583 include one or more Relays, which peer with the Servers and Proxys 584 within that INET. All Relays within the same INET are members of the 585 same hub AS using a common ASN, and use iBGP to maintain a consistent 586 view of all active MNPs currently in service. The Relays of 587 different INETs peer with one another using eBGP. 589 Relays advertise the AERO link's MSPs and any non-MNP routes to each 590 of their Servers. This means that any aggregated non-MNPs (including 591 "default") are advertised to all Servers. Each Relay configures a 592 black-hole route for each of its MSPs. By black-holing the MSPs, the 593 Relay will maintain forwarding table entries only for the MNPs that 594 are currently active, and packets destined to all other MNPs will 595 correctly incur Destination Unreachable messages due to the black- 596 hole route. In this way, Servers have only partial topology 597 knowledge (i.e., they know only about the MNPs of their directly 598 associated Clients) and they forward all other packets to Relays 599 which have full topology knowledge. 601 Servers maintain a working set of associated MNPs, and dynamically 602 announce new MNPs and withdraw departed MNPs in eBGP updates to 603 Relays. Servers that are configured as Gateways also redistribute 604 non-MNP routes learned from non-AERO interfaces via their eBGP Relay 605 peerings. 607 Clients are expected to remain associated with their current Servers 608 for extended timeframes, however Servers SHOULD selectively suppress 609 updates for impatient Clients that repeatedly associate and 610 disassociate with them in order to dampen routing churn. Servers 611 that are configured as Gateways advertise the MSPs via INET/EUN 612 interfaces, and forward packets between INET/EUN interfaces and the 613 AERO interface using standard IP forwarding. 615 For IPv6 MNPs, the AERO routing system includes only IPv6 routes. 616 For IPv4 MNPs, the AERO routing system includes both IPv4 routes and 617 also IPv6 routes based on the IPv4-mapped IPv6 address corresponding 618 to the MNP and with prefix length set to 96 plus the length of the 619 IPv4 prefix. (For example, if the IPv4 MNP is 192.0.2.0/24 then the 620 IPv4-mapped prefix is 0:0:0:0:0:FFFF:192.0.2.0/120.) 622 Scaling properties of the AERO routing system are limited by the 623 number of BGP routes that can be carried by Relays. As of 2015, the 624 global public Internet BGP routing system manages more than 500K 625 routes with linear growth and no signs of router resource exhaustion 626 [BGP]. More recent network emulation studies have also shown that a 627 single Relay can accommodate at least 1M dynamically changing BGP 628 routes even on a lightweight virtual machine, i.e., and without 629 requiring high-end dedicated router hardware. 631 Therefore, assuming each Relay can carry 1M or more routes, this 632 means that at least 1M Clients can be serviced by a single set of 633 Relays. A means of increasing scaling would be to assign a different 634 set of Relays for each set of MSPs. In that case, each Server still 635 peers with one or more Relays, but institutes route filters so that 636 BGP updates are only sent to the specific set of Relays that 637 aggregate the MSP. For example, if the MSP for the AERO link is 638 2001:db8::/32, a first set of Relays could service the MSP 639 2001:db8::/40, a second set of Relays could service 640 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 641 etc. 643 Assuming up to 1K sets of Relays, the AERO routing system can then 644 accommodate 1B or more MNPs with no additional overhead (for example, 645 it should be possible to service 1B /64 MNPs taken from a /34 MSP and 646 even more for shorter prefixes). In this way, each set of Relays 647 services a specific set of MSPs that they advertise to the native 648 Internetwork routing system, and each Server configures MSP-specific 649 routes that list the correct set of Relays as next hops. This 650 arrangement also allows for natural incremental deployment, and can 651 support small scale initial deployments followed by dynamic 652 deployment of additional Clients, Servers and Relays without 653 disturbing the already-deployed base. 655 A full discussion of the BGP-based routing system used by AERO is 656 found in [I-D.ietf-rtgwg-atn-bgp]. The system provides for 657 Distributed Mobility Management (DMM) per the distributed mobility 658 anchoring architecture [I-D.ietf-dmm-distributed-mobility-anchoring]. 660 3.4. AERO Addresses 662 A Client's AERO address is an IPv6 link-local address with an 663 interface identifier based on the Client's delegated MNP. Relay, 664 Server and Proxy AERO addresses are assigned from the range fe80::/96 665 and include an administratively-provisioned value in the lower 32 666 bits. 668 For IPv6, Client AERO addresses begin with the prefix fe80::/64 and 669 include in the interface identifier (i.e., the lower 64 bits) a 670 64-bit prefix taken from one of the Client's IPv6 MNPs. For example, 671 if the AERO Client receives the IPv6 MNP: 673 2001:db8:1000:2000::/56 675 it constructs its corresponding AERO addresses as: 677 fe80::2001:db8:1000:2000 679 fe80::2001:db8:1000:2001 681 fe80::2001:db8:1000:2002 683 ... etc. ... 685 fe80::2001:db8:1000:20ff 687 For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6 688 address formed from an IPv4 MNP and with a Prefix Length of 96 plus 689 the MNP prefix length. For example, for the IPv4 MNP 192.0.2.32/28 690 the IPv4-mapped IPv6 MNP is: 692 0:0:0:0:0:FFFF:192.0.2.16/124 694 The Client then constructs its AERO addresses with the prefix 695 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 696 in the interface identifier as: 698 fe80::FFFF:192.0.2.16 700 fe80::FFFF:192.0.2.17 702 fe80::FFFF:192.0.2.18 704 ... etc. ... 706 fe80:FFFF:192.0.2.31 708 Relay, Server and Proxy AERO addresses are allocated from the range 709 fe80::/96, and MUST be managed for uniqueness. The lower 32 bits of 710 the AERO address includes a unique integer value (e.g., fe80::1, 711 fe80::2, fe80::3, etc.) as assigned by the administrative authority 712 for the link. If the link spans multiple SPAN segments, the AERO 713 addresses are assigned to each segment in 1x1 correspondence with 714 SPAN addresses (see: Section 3.5). The address fe80:: represents the 715 IPv6 default route (i.e., ::/0), and the address fe80::ffff:ffff is 716 reserved as the unspecified AERO address. 718 The lowest-numbered AERO address from a Client's MNP delegation 719 serves as the "base" AERO address (for example, for the MNP 720 2001:db8:1000:2000::/56 the base AERO address is 721 fe80::2001:db8:1000:2000). The Client then assigns the base AERO 722 address to the AERO interface and uses it for the purpose of 723 maintaining the neighbor cache entry. The Server likewise uses the 724 AERO address as its index into the neighbor cache for this Client. 726 If the Client has multiple AERO addresses (i.e., when there are 727 multiple MNPs and/or MNPs with prefix lengths shorter than /64), the 728 Client originates ND messages using the base AERO address as the 729 source address and accepts and responds to ND messages destined to 730 any of its AERO addresses as equivalent to the base AERO address. In 731 this way, the Client maintains a single neighbor cache entry that may 732 be indexed by multiple AERO addresses. 734 The Client's Subnet Router Anycast address can be statelessly 735 determined from its AERO address by simply transposing the AERO 736 address into the upper N bits of the Anycast address followed by 737 128-N bits of zeros. For example, for the AERO address 738 fe80::2001:db8:1:2 the subnet router anycast address is 739 2001:db8:1:2::/64. 741 AERO addresses for mobile node Clients embed a MNP as discussed 742 above, while AERO addresses for non-MNP destinations are constructed 743 in exactly the same way. A Client AERO address therefore encodes 744 either an MNP if the prefix is reached via the SPAN or a non-MNP if 745 the prefix is reached via a Gateway. 747 3.5. Spanning Partitioned AERO Networks (SPAN) 749 In the simplest case, an AERO link configured over a single INET 750 appears as a single unified link with a consistent underlying network 751 addressing plan. In that case, all nodes on the link can exchange 752 packets via encapsulation with INET addresses, since the underlying 753 INET is connected. In common practice, however, an AERO link may be 754 partitioned into multiple "segments", where each segment is a 755 distinct INET potentially managed under a different administrative 756 authority (e.g., as for worldwide aviation service providers such as 757 ARINC, SITA, Inmarsat, etc.). Individual INETs may themselves be 758 partitioned internally, in which case each internal partition is seen 759 as a separate segment. 761 The addressing plan of each segment is consistent internally but will 762 often bear no relation to the addressing plans of other segments. 763 Each segment is also likely to be separated from others by network 764 security devices (e.g., firewalls, proxies, packet filtering 765 gateways, etc.), and in many cases disjoint segments may not even 766 have any common physical link connections at all. Therefore, nodes 767 can only be assured of exchanging packets directly with 768 correspondents in the same segment, and not with those in other 769 segments. The only means for joining the segments therefore is 770 through inter-domain peerings between AERO Relays. 772 The same as for traditional campus LANs, multiple AERO link segments 773 can be joined into a single unified link via a virtual bridging 774 service termed the "SPAN". The SPAN performs link-layer packet 775 forwarding between segments (i.e., bridging) without decrementing the 776 network-layer TTL/Hop Limit. The SPAN model is depicted in Figure 2: 778 . . . . . . . . . . . . . . . . . . . . . . . 779 . . 780 . .-(::::::::) . 781 . .-(::::::::::::)-. +-+ . 782 . (:::: Segment A :::)--|R|---+ . 783 . `-(::::::::::::)-' +-+ | . 784 . `-(::::::)-' | . 785 . | . 786 . .-(::::::::) | . 787 . .-(::::::::::::)-. +-+ | . 788 . (:::: Segment B :::)--|R|---+ . 789 . `-(::::::::::::)-' +-+ | . 790 . `-(::::::)-' | . 791 . | . 792 . .-(::::::::) | . 793 . .-(::::::::::::)-. +-+ | . 794 . (:::: Segment C :::)--|R|---+ . 795 . `-(::::::::::::)-' +-+ | . 796 . `-(::::::)-' | . 797 . | . 798 . ..(etc).. x . 799 . . 800 . . 801 . <- AERO Link Bridged by the SPAN -> . 802 . . . . . . . . . . . . . .. . . . . . . . . 804 Figure 2: The SPAN 806 To support the SPAN, AERO links require a reserved /96 IPv6 "SPAN 807 Service Prefix (SSP)". Although any routable IPv6 prefix can be 808 used, a Unique Local Address (ULA) prefix (e.g., fd00::/96) [RFC4389] 809 is recommended since border routers are commonly configured to 810 prevent packets with ULAs from being injected into the AERO link by 811 an external IPv6 node and from leaking out of the AERO link to the 812 outside world. 814 Each segment in the SPAN assigns a unique sub-prefix of the SSP 815 termed a "SPAN Partition Prefix (SPP)". For example, a first segment 816 could assign fd00::1000/116, a second could assign fd00::2000/116, a 817 third could assign fd00::3000/116, etc. The administrative 818 authorities for each segment must therefore coordinate to assure 819 mutually-exclusive SPP assignments, but internal provisioning of the 820 SPP is a local consideration for each administrative authority. 822 A "SPAN address" is an address taken from a SPP and assigned to a 823 Relay, Server or Proxy interface. SPAN addresses are formed by 824 simply replacing the upper portion of an administratively-assigned 825 AERO address with the SPP. For example, if the SPP is 826 fd00::1000/116, the SPAN address formed from the AERO address 827 fe80::1001 is simply fd00::1001. 829 An "INET address" is an address of a node's interface connection to 830 an INET. AERO/SPAN/INET address mappings are maintained as permanent 831 neighbor cache entires as discussed in Section 3.8. 833 AERO Relays serve as bridges to join multiple segments into a unified 834 AERO link over multiple diverse administrative domains. They support 835 the bridging function by first establishing forwarding table entries 836 for their SPPs either via standard BGP routing or static routes. For 837 example, if three Relays ('A', 'B' and 'C') from different segments 838 serviced the SPPs fd00::1000/116, fd00::2000/116 and fd00::3000/116 839 respectively, then the forwarding tables in each Relay are as 840 follows: 842 A: fd00::1000/116->local, fd00::2000/116->B, fd00::3000/116->C 844 B: fd00::1000/116->A, fd00::2000/116->local, fd00::3000/116->C 846 C: fd00::1000/116->A, fd00::2000/116->B, fd00::3000/116->local 848 These forwarding table entries are permanent and never change, since 849 they correspond to fixed infrastructure elements in their respective 850 segments. This provides the basis for a link-layer forwarding 851 service that cannot be disrupted by routing updates due to node 852 mobility. 854 With the SPPs in place in each Relay's forwarding table, control and 855 data packets sent between AERO nodes in different segments can 856 therefore be carried over the SPAN via encapsulation. For example, 857 when a source node in segment A forwards a packet with IPv6 address 858 2001:db8:1:2::1 to a destination node in segment C with IPv6 address 859 2001:db8:1000:2000::1, it first encapsulates the packet in a SPAN 860 header with source SPAN address taken from fd00::1000/116 (e.g., 861 fd00::1001) and destination SPAN address taken from fd00::3000/116 862 (e.g., fd00::3001). Next, it encapsulates the SPAN message in an 863 INET header with source address set to its own INET address (e.g., 864 192.0.2.100) and destination set to the INET address of a Relay 865 (e.g., 192.0.2.1). 867 SPAN encapsulation is based on Generic Packet Tunneling in IPv6 868 [RFC2473]; the encapsulation format in the above example is shown 869 inFigure 3: 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | INET Header | 873 | src = 192.0.2.100 | 874 | dst = 192.0.2.1 | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | SPAN Header | 877 | src = fd00::1001 | 878 | dst = fd00::3001 | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Inner IP Header | 881 | src = 2001:db8:1:2::1 | 882 | dst = 2001:db8:1000:2000::1 | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | | 885 ~ ~ 886 ~ Inner Packet Body ~ 887 ~ ~ 888 | | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Figure 3: SPAN Encapsulation 893 In this format, the inner IP header and packet body are the original 894 IP packet, the SPAN header is an IPv6 header prepared according to 895 [RFC2473], and the INET header is prepared according to Section 3.9. 896 A packet is said to be "forwarded/sent into the SPAN" when it is 897 encapsulated as described above then forwarded via a secured tunnel 898 to a neighboring Relay. 900 This gives rise to a routing system that contains both MNP routes 901 that may change dynamically due to regional node mobility and SPAN 902 routes that never change. The Relays can therefore provide link- 903 layer bridging by sending packets into the SPAN instead of network- 904 layer routing according to MNP routes. As a result, opportunities 905 for packet loss due to node mobility between different segments are 906 mitigated. 908 With reference to Figure 3, for a Client's AERO address the SPAN 909 address is simply set to the Subnet Router Anycast address. For non- 910 link-local addresses, the destination SPAN address may not be known 911 in advance for the first few packets of a flow sent via the SPAN. In 912 that case, the SPAN destination address is set to the original 913 packet's destination, and the SPAN routing system will direct the 914 packet to the correct SPAN egress node. (In the above example, the 915 SPAN destination address is simply 2001:db8:1000:2000::1.) 917 3.6. AERO Interface Characteristics 919 AERO interfaces use encapsulation (see: Section 3.9) to exchange 920 packets with neighbors attached to the AERO link. 922 AERO interfaces maintain a neighbor cache for tracking per-neighbor 923 state the same as for any interface. AERO interfaces use ND messages 924 including Router Solicitation (RS), Router Advertisement (RA), 925 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for 926 neighbor cache management. 928 AERO interface ND messages include one or more Source/Target Link- 929 Layer Address Options (S/TLLAOs) formatted as shown in Figure 4: 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 = 5 | Prefix Length |S|R|D|X|N|Resvd| 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Interface ID | Port Number | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | | 939 + + 940 | | 941 + Link Layer Address + 942 | | 943 + + 944 | | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 4: AERO Source/Target Link-Layer Address Option (S/TLLAO) 956 Format 958 In this format: 960 o Type is set to '1' for SLLAO or '2' for TLLAO. 962 o Length is set to the constant value '5' (i.e., 5 units of 8 963 octets). 965 o Prefix Length is set to the MNP prefix length in an ND message for 966 the Client AERO address found in the source (RS), destination (RA) 967 or target (NA) address; otherwise set to 0. If the message 968 contains multiple SLLAOs, only the Prefix Length value in the 969 SLLAO with S set to 1 is consulted and the values in other SLLAOs 970 are ignored. 972 o S (the 'Source' bit) is set to '1' in the S/TLLAO of an ND message 973 that corresponds to the ANET/INET interface over which the ND 974 message is sent, and set to 0 in all other S/TLLAOs. 976 o R (the "Release" bit) is set to '1' in an S/TLLAO in an RS/NA sent 977 for the purpose of departing from a Server; otherwise, set to '0'. 978 The recipient places the corresponding neighbor cache entry in the 979 DEPARTED state. For RS message, the recipient then releases the 980 corresponding PD and returns an RA with Router Lifetime set to '0' 982 o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA 983 message for each Interface ID that is to be disabled in the 984 neighbor cache entry; otherwise, set to '0'. 986 o X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA message 987 by the Proxy when there is a Proxy in the path; otherwise, set to 988 '0'. If the message contains multiple SLLAOs, only the X value in 989 the SLLAO with S set to 1 is consulted and the values in other 990 SLLAOs are ignored. 992 o N (the "(Network Address) Translator (NAT)" bit) is set to '1' in 993 the SLLAO of an RA message by the Server if there is a translator 994 in the path; otherwise, set to '0'. If the message contains 995 multiple SLLAOs, only the N value in the SLLAO with S set to 1 is 996 consulted and the values in other SLLAOs are ignored. 998 o Resvd is set to the value '0' on transmission and ignored on 999 receipt. 1001 o Interface ID is set to a 16-bit integer value corresponding to an 1002 AERO node's ANET/INET interface. Once the node has assigned an 1003 Interface ID to an ANET interface, the assignment must remain 1004 unchanged until the node fully detaches from the AERO link. The 1005 value 0xffff is reserved as the Server's INET Interface ID, i.e., 1006 Servers MUST use Interface ID 0xffff, and Clients MUST number 1007 their ANET Interface IDs with values in the range of 0-0xfffe. 1009 o Port Number and Link Layer Address are set to the encapsulation 1010 addresses required to send packets via the target node (or to '0' 1011 when the addresses are left unspecified). When UDP is not used as 1012 part of the encapsulation, Port Number is set to '0'. When the 1013 encapsulation IP address family is IPv4, IP Address is formed as 1014 an IPv4-mapped IPv6 address as specified in Section 3.4. 1016 o P(i) is a set of Preferences that correspond to the 64 1017 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 1018 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 1019 ("medium") or '3' ("high") to indicate a QoS preference level for 1020 packet forwarding purposes. 1022 A Client's AERO interface may be configured over multiple ANET 1023 interface connections. For example, common mobile handheld devices 1024 have both wireless local area network ("WLAN") and cellular wireless 1025 links. These links are typically used "one at a time" with low-cost 1026 WLAN preferred and highly-available cellular wireless as a standby. 1027 In a more complex example, aircraft frequently have many wireless 1028 data link types (e.g. satellite-based, cellular, terrestrial, air-to- 1029 air directional, etc.) with diverse performance and cost properties. 1031 A Client's ANET interfaces are classified as follows: 1033 o Native interfaces connect to the open INET, and have a global IP 1034 address that is reachable from any INET correspondent. 1036 o NATed interfaces connect to an ANET behind a Network Address 1037 Translator (NAT). The NAT does not participate in any AERO 1038 control message signaling, but the Server can issue control 1039 messages on behalf of the Client. Clients that are behind a NAT 1040 are required to send periodic keepalive messages to keep NAT state 1041 alive when there are no data packets flowing. If no other 1042 periodic messaging service is available, the Client can send RS 1043 messages to receive RA replies from its Server(s). 1045 o VPNed interfaces use security encapsulation over the ANET to a 1046 Virtual Private Network (VPN) server that also acts as an AERO 1047 Server. As with NATed links, the Server can issue control 1048 messages on behalf of the Client, but the Client need not send 1049 periodic keepalives in addition to those already used to maintain 1050 the VPN connection. 1052 o Proxyed interfaces connect to an ANET that is separated from the 1053 open INET by an AERO Proxy. Unlike NATed and VPNed interfaces, 1054 the Proxy can actively issue control messages on behalf of the 1055 Client. 1057 o Direct interfaces connect the Client directly to a neighbor 1058 without crossing any ANET/INET paths. An example is a line-of- 1059 sight link between a remote pilot and an unmanned aircraft. 1061 If a Client's multiple ANET interfaces are used "one at a time" 1062 (i.e., all other interfaces are in standby mode while one interface 1063 is active), then ND messages include only a single S/TLLAO with 1064 Interface ID set to a constant value. In that case, the Client would 1065 appear to have a single ANET interface but with a dynamically 1066 changing ANET address. 1068 If the Client has multiple active ANET interfaces, then from the 1069 perspective of ND it would appear to have multiple link-layer 1070 addresses. In that case, ND messages MAY include multiple S/TLLAOs 1071 -- each with an Interface ID that corresponds to a specific ANET 1072 interface. S must be set to 1 in the S/TLLAO corresponding to the 1073 AERO node's ANET interface used to transmit the message and set to 0 1074 in all other S/TLLAOs. 1076 When the Client includes an S/TLLAO for an ANET interface for which 1077 it is aware that there is a NAT on the path to the Server, or when a 1078 node includes an S/TLLAO solely for the purpose of announcing new QoS 1079 preferences, the node MAY set both Port Number and Link-Layer Address 1080 to 0 to indicate that the addresses are unspecified at the network 1081 layer and must instead be derived from the link-layer encapsulation 1082 headers. 1084 Relay, Server and Proxy AERO interfaces may be configured over one or 1085 more secured tunnel interfaces. The AERO interface configures both 1086 an AERO address and its corresponding SPAN address, while the 1087 underlying secured tunnel interfaces are either unnumbered or 1088 configure the same SPAN address. The AERO interface encapsulates 1089 each IP packet in a SPAN header and presents the packet to the 1090 underlying secured tunnel interface. For Relays that do not 1091 configure an AERO interface, the secured tunnel interfaces themselves 1092 are exposed to the IP layer with each interface configuring the 1093 Relay's SPAN address. Routing protocols such as BGP therefore run 1094 directly over the Relay's secured tunnel interfaces. For nodes that 1095 configure an AERO interface, routing protocols such as BGP run over 1096 the AERO interface but do not employ SPAN encapsulation. Instead, 1097 the AERO interface presents the routing protocol messages directly to 1098 the underlying secured tunnels without applying encapsulation and 1099 while using the SPAN address as the source address. This distinction 1100 must be honored consistently according to each node's configuration 1101 so that the IP forwarding table will associate discovered IP routes 1102 with the correct interface. 1104 3.7. AERO Interface Initialization 1106 AERO Servers, Proxys and Clients configure AERO interfaces as their 1107 point of attachment to the AERO link. AERO nodes assign the MSPs for 1108 the link to their AERO interfaces (i.e., as a "route-to-interface") 1109 to ensure that packets with destination addresses covered by an MNP 1110 not explicitly assigned to a non-AERO interface are directed to the 1111 AERO interface. 1113 AERO interface initialization procedures for Servers, Proxys, Clients 1114 and Relays are discussed in the following sections. 1116 3.7.1. AERO Server/Gateway Behavior 1118 When a Server enables an AERO interface, it assigns AERO/SPAN 1119 addresses and configures permanent neighbor cache entries for 1120 neighbors in the same SPAN segment by consulting the ROS list for the 1121 segment. The Server also configures secured tunnels with one or more 1122 neighboring Relays and engages in a BGP routing protocol session with 1123 each Relay. 1125 The AERO interface provides a single interface abstraction to the IP 1126 layer, but internally comprises multiple secured tunnels as well as 1127 an NBMA nexus for sending encapsulated data packets to AERO interface 1128 neighbors. The Server further configures a service to facilitate ND/ 1129 PD exchanges with AERO Clients and manages per-Client neighbor cache 1130 entries and IP forwarding table entries based on control message 1131 exchanges. 1133 Gateways are simply Servers that run a dynamic routing protocol 1134 between the AERO interface and INET/EUN interfaces (see: 1135 Section 3.3). The Gateway provisions MNPs to networks on the INET/ 1136 EUN interfaces (i.e., the same as a Client would do) and advertises 1137 the MSP(s) for the AERO link over the INET/EUN interfaces. The 1138 Gateway further provides an attachment point of the AERO link to the 1139 non-MNP-based global topology. 1141 3.7.2. AERO Proxy Behavior 1143 When a Proxy enables an AERO interface, it assigns AERO/SPAN 1144 addresses and configures permanent neighbor cache entries the same as 1145 for Servers. The Proxy also configues secured tunnels with one or 1146 more neighboring Relays and maintains per-Client neighbor cache 1147 entries based on control message exchanges. 1149 3.7.3. AERO Client Behavior 1151 When a Client enables an AERO interface, it sends RS messages with 1152 ND/PD parameters over an ANET interface to one or more Servers in the 1153 MAP list, which return RA messages with corresponding PD parameters. 1154 (The RS/RA messages may pass through a Proxy in the case of a 1155 Client's Proxyed interface.) 1156 After the initial ND/PD message exchange, the Client assigns AERO 1157 addresses to the AERO interface based on the delegated prefix(es). 1158 The Client can then register additional ANET interfaces with the 1159 Server by sending an RS message over each ANET interface. 1161 3.7.4. AERO Relay Behavior 1163 AERO Relays need not connect directly to the AERO link, since they 1164 operate as link-layer forwarding devices instead of network layer 1165 routers. Configuration of AERO interfaces on Relays is therefore 1166 OPTIONAL, e.g., if an administrative interface is needed. Relays 1167 configure secured tunnels with Servers, Proxys and other Relays; they 1168 also configure AERO/SPAN addresses and permanent neighbor cache 1169 entries the same as Servers. Relays engage in a BGP routing protocol 1170 session with a subset of the Servers on the local SPAN segment, and 1171 with other Relays on the SPAN (see: Section 3.3). 1173 3.8. AERO Interface Neighbor Cache Maintenance 1175 Each AERO interface maintains a conceptual neighbor cache that 1176 includes an entry for each neighbor it communicates with on the AERO 1177 link per [RFC4861]. AERO interface neighbor cache entries are said 1178 to be one of "permanent", "symmetric", "asymmetric" or "proxy". 1180 Permanent neighbor cache entries are created through explicit 1181 administrative action; they have no timeout values and remain in 1182 place until explicitly deleted. AERO Servers and Proxys maintain 1183 permanent neighbor cache entries for all other Servers and Proxys 1184 within the same SPAN segment. Each entry maintains the mapping 1185 between the neighbor's network-layer AERO address and corresponding 1186 INET address. The list of all permanent neighbor cache entries for 1187 the SPAN segment is maintained in the segment's ROS list. 1189 Symmetric neighbor cache entries are created and maintained through 1190 RS/RA exchanges as specified in Section 3.15, and remain in place for 1191 durations bounded by ND/PD lifetimes. AERO Servers maintain 1192 symmetric neighbor cache entries for each of their associated 1193 Clients, and AERO Clients maintain symmetric neighbor cache entries 1194 for each of their associated Servers. The list of all Servers on the 1195 AERO link is maintained in the link's MAP list. 1197 Asymmetric neighbor cache entries are created or updated based on 1198 route optimization messaging as specified in Section 3.17, and are 1199 garbage-collected when keepalive timers expire. AERO route 1200 optimization sources (ROSs) maintain asymmetric neighbor cache 1201 entries for active targets with lifetimes based on ND messaging 1202 constants. Asymmetric neighbor cache entries are unidirectional 1203 since only the ROS and not the target (e.g., a Client's MAP) creates 1204 an entry. 1206 Proxy neighbor cache entries are created and maintained by AERO 1207 Proxys when they process Client/Server ND/PD exchanges, and remain in 1208 place for durations bounded by ND/PD lifetimes. AERO Proxys maintain 1209 proxy neighbor cache entries for each of their associated Clients. 1210 Proxy neighbor cache entries track the Client state and the address 1211 of the Client's associated Server. 1213 To the list of neighbor cache entry states in Section 7.3.2 of 1214 [RFC4861], AERO interfaces add an additional state DEPARTED that 1215 applies to symmetric and proxy neighbor cache entries for Clients 1216 that have recently departed. The interface sets a "DepartTime" 1217 variable for the neighbor cache entry to "DEPARTTIME" seconds. 1218 DepartTime is decremented unless a new ND message causes the state to 1219 return to REACHABLE. While a neighbor cache entry is in the DEPARTED 1220 state, packets destined to the target Client are forwarded to the 1221 Client's new location instead of being dropped. When DepartTime 1222 decrements to 0, the neighbor cache entry is deleted. It is 1223 RECOMMENDED that DEPARTTIME be set to the default constant value 40 1224 seconds to allow for packets in flight to be delivered while stale 1225 route optimization state may be present. 1227 When a target Server (acting as a Mobility Anchor Point (MAP)) 1228 receives a valid NS message used for route optimization, it searches 1229 for a symmetric neighbor cache entry for the target Client. The MAP 1230 then returns a solicited NA message without creating a neighbor cache 1231 entry for the ROS, but creates a target Client "Report List" entry 1232 for the ROS and sets a "ReportTime" variable for the entry to 1233 REPORTTIME seconds. The MAP resets ReportTime when it receives a new 1234 authentic NS message, and otherwise decrements ReportTime while no NS 1235 messages have been received. It is RECOMMENDED that REPORTTIME be 1236 set to the default constant value 40 seconds to allow a 10 second 1237 window so that route optimization can converge before ReportTime 1238 decrements below REACHABLETIME. 1240 When the ROS receives a solicited NA message response to its NS 1241 message, it creates or updates an asymmetric neighbor cache entry for 1242 the target network-layer and link-layer addresses. The ROS then 1243 (re)sets ReachableTime for the neighbor cache entry to REACHABLETIME 1244 seconds and uses this value to determine whether packets can be 1245 forwarded directly to the target, i.e., instead of via a default 1246 route. The ROS otherwise decrements ReachableTime while no further 1247 solicited NA messages arrive. It is RECOMMENDED that REACHABLETIME 1248 be set to the default constant value 30 seconds as specified in 1249 [RFC4861]. 1251 The ROS also uses the value MAX_UNICAST_SOLICIT to limit the number 1252 of NS keepalives sent when a correspondent may have gone unreachable, 1253 the value MAX_RTR_SOLICITATIONS to limit the number of RS messages 1254 sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT 1255 to limit the number of unsolicited NAs that can be sent based on a 1256 single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT, 1257 MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the 1258 same as specified in [RFC4861]. 1260 Different values for DEPARTTIME, REPORTTIME, REACHABLETIME, 1261 MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and 1262 MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if 1263 different values are chosen, all nodes on the link MUST consistently 1264 configure the same values. Most importantly, DEPARTTIME and 1265 REPORTTIME SHOULD be set to a value that is sufficiently longer than 1266 REACHABLETIME to avoid packet loss due to stale route optimization 1267 state. 1269 3.9. AERO Interface Encapsulation and Re-encapsulation 1271 AERO interfaces encapsulate packets according to whether they are 1272 entering the AERO interface from the network layer or if they are 1273 being re-admitted into the same AERO link they arrived on. This 1274 latter form of encapsulation is known as "re-encapsulation". 1276 For packets entering the AERO interface from the network layer, the 1277 AERO interface copies the "TTL/Hop Limit", "Type of Service/Traffic 1278 Class" [RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion 1279 Experienced" [RFC3168] values in the packet's IP header into the 1280 corresponding fields in the encapsulation header(s). 1282 For packets undergoing re-encapsulation, the AERO interface instead 1283 copies these values from the original encapsulation header into the 1284 new encapsulation header, i.e., the values are transferred between 1285 encapsulation headers and *not* copied from the encapsulated packet's 1286 network-layer header. (Note especially that by copying the TTL/Hop 1287 Limit between encapsulation headers the value will eventually 1288 decrement to 0 if there is a (temporary) routing loop.) For IPv4 1289 encapsulation/re-encapsulation, the AERO interface sets the DF bit as 1290 discussed in Section 3.13. 1292 Proxy and Relay AERO interfaces encapsulate each packet in a SPAN 1293 header, then encapsulate the resulting SPAN packet in an INET header 1294 according to the next hop determined in the forwarding algorithm in 1295 Section 3.12. If the next hop is reached via a secured tunnel, the 1296 AERO interface uses an INET encapsulation format specific to the 1297 secured tunnel type (see: Section 6). If the next hop is reached via 1298 an unsecured underlying interface, the AERO interface instead uses 1299 Generic UDP Encapsulation (GUE) [I-D.ietf-intarea-gue] or an 1300 alternate minimal encapsulation format Appendix A. 1302 Client AERO interfaces can avoid encapsulation over underlying 1303 interfaces for which the first-hop access router is AERO-aware. For 1304 other underlying interfaces, Client interfaces use INET encapsulation 1305 the same as for Relays/Proxys but do not use SPAN encapsulation 1306 unless the underlying interface itself connects to the SPAN. 1308 When GUE encapsulation is used, the AERO interface next sets the UDP 1309 source port to a constant value that it will use in each successive 1310 packet it sends, and sets the UDP length field to the length of the 1311 SPAN packet plus 8 bytes for the UDP header itself plus the length of 1312 the GUE header (or 0 if GUE direct IP encapsulation is used). For 1313 packets sent to a Server or Relay, the AERO interface sets the UDP 1314 destination port to 8060, i.e., the IANA-registered port number for 1315 AERO. For packets sent to a Client, the AERO interface sets the UDP 1316 destination port to the port value stored in the neighbor cache entry 1317 for this Client. The AERO interface then either includes or omits 1318 the UDP checksum according to the GUE specification. 1320 AERO interfaces observes the packet sizing and fragmentation 1321 considerations found in Section 3.13. 1323 3.10. AERO Interface Decapsulation 1325 AERO interfaces decapsulate packets destined either to the AERO node 1326 itself or to a destination reached via an interface other than the 1327 AERO interface the packet was received on. When the encapsulated 1328 packet arrives in multiple fragments, the AERO interface reassembles 1329 as discussed in Section 3.13. Further decapsulation steps are 1330 performed according to the appropriate encapsulation format 1331 specification. 1333 3.11. AERO Interface Data Origin Authentication 1335 AERO nodes employ simple data origin authentication procedures. In 1336 particular: 1338 o AERO Relays, Servers and Proxys accept encapsulated data packets 1339 and control messages received from secured tunnels. 1341 o AERO Servers and Proxys accept encapsulated data packets and NS 1342 messages used for Neighbor Unreachability Detection (NUD) received 1343 from a source found in the ROS list. 1345 o AERO Proxys and Clients accept packets that originate from within 1346 the same secured ANET. 1348 o AERO Clients and Gateways accept packets from downstream network 1349 correspondents based on ingress filtering. 1351 AERO nodes silently drop any packets that do not satisfy the above 1352 data origin authentication procedures. Further security 1353 considerations are discussed Section 6. 1355 3.12. AERO Interface Forwarding Algorithm 1357 IP packets enter a node's AERO interface either from the network 1358 layer (i.e., from a local application or the IP forwarding system) or 1359 from the link layer (i.e., from an AERO interface neighbor). All 1360 packets entering a node's AERO interface first undergo data origin 1361 authentication as discussed in Section 3.11. Packets that satisfy 1362 data origin authentication are processed further, while all others 1363 are dropped silently. 1365 Packets that enter the AERO interface from the network layer are 1366 forwarded to an AERO interface neighbor. Packets that enter the AERO 1367 interface from the link layer are either re-admitted into the AERO 1368 link or forwarded to the network layer where they are subject to 1369 either local delivery or IP forwarding. In all cases, the AERO 1370 interface itself MUST NOT decrement the network layer TTL/Hop-count 1371 since its forwarding actions occur below the network layer. 1373 AERO interfaces may have multiple underlying ANET/INET interfaces 1374 and/or neighbor cache entries for neighbors with multiple Interface 1375 ID registrations (see Section 3.6). The AERO interface uses each 1376 packet's DSCP value (and/or port number) to select an outgoing ANET/ 1377 INET interface based on the node's own QoS preferences, and also to 1378 select a destination link-layer address based on the neighbor's ANET/ 1379 INET interface with the highest preference. AERO implementations 1380 SHOULD allow for QoS preference values to be modified at runtime 1381 through network management. 1383 If multiple outgoing interfaces and/or neighbor interfaces have a 1384 preference of "high", the AERO node replicates the packet and sends 1385 one copy via each of the (outgoing / neighbor) interface pairs; 1386 otherwise, the node sends a single copy of the packet via the 1387 interface with the highest preference. AERO nodes keep track of 1388 which ANET/INET interfaces are currently "reachable" or 1389 "unreachable", and only use "reachable" interfaces for forwarding 1390 purposes. 1392 The following sections discuss the AERO interface forwarding 1393 algorithms for Clients, Proxys, Servers and Relays. In the following 1394 discussion, a packet's destination address is said to "match" if it 1395 is the same as a cached address, or if it is covered by a cached 1396 prefix (which may be encoded in an AERO address). 1398 3.12.1. Client Forwarding Algorithm 1400 When an IP packet enters a Client's AERO interface from the network 1401 layer the Client searches for an asymmetric neighbor cache entry that 1402 matches the destination. If there is a match, the Client uses one or 1403 more "reachable" neighbor interfaces in the entry for packet 1404 forwarding. If there is no asymmetric neighbor cache entry, the 1405 Client instead forwards the packet toward a Server (the packet is 1406 intercepted by a Proxy if there is a Proxy on the path). 1408 When an IP packet enters a Client's AERO interface from the link- 1409 layer, if the destination matches one of the Client's MNPs or link- 1410 local addresses the Client decapsulates the packet (if necessary) and 1411 delivers it to the network layer. Otherwise, the Client drops the 1412 packet and MAY return a network-layer ICMP Destination Unreachable 1413 message subject to rate limiting (see: Section 3.14). 1415 3.12.2. Proxy Forwarding Algorithm 1417 For control messages originating from or destined to a Client, the 1418 Proxy intercepts the message and updates its proxy neighbor cache 1419 entry for the Client. The Proxy then forwards a (proxyed) copy of 1420 the control message. (For example, the Proxy forwards a proxied 1421 version of a Client's NS/RS message to the target neighbor, and 1422 forwards a proxied version of the NA/RA reply to the Client.) 1424 When the Proxy receives a data packet from a Client within the ANET, 1425 the Proxy searches for an asymmetric neighbor cache entry that 1426 matches the destination and forwards the packet as follows: 1428 o if the destination matches an asymmetric neighbor cache entry, the 1429 Proxy uses one or more "reachable" neighbor interfaces in the 1430 entry for packet forwarding via encapsulation. If the neighbor 1431 interface is in the same SPAN segment, the Proxy forwards the 1432 packet directly to the neighbor; otherwise, it forwards the packet 1433 to a Relay. 1435 o else, the Proxy encapsulates and forwards the packet to a Relay 1436 while using the packet's destination address as the SPAN 1437 destination address. (If the destination is an AERO address, the 1438 Proxy instead uses the corresponding Subnet Router Anycast address 1439 for Client AERO addresses and the SPAN address for 1440 administratively-provisioned AERO addresses.). 1442 When the Proxy receives an encapsulated data packet from an INET 1443 neighbor or from a secured tunnel, it accepts the packet only if data 1444 origin authentication succeeds and the SPAN destination address is 1445 its own adddress. If the packet is a SPAN fragment, the Proxy then 1446 adds the fragment to the reassembly buffer and returns if the 1447 reassembly is still incomplete. Otherwise, the Proxy reassembles the 1448 packet (if necessary) and continues processing. 1450 Next, the Proxy searches for a proxy neighbor cache entry that 1451 matches the destination. If there is a proxy neighbor cache entry in 1452 the REACHABLE state, the Proxy decapsulates and forwards the packet 1453 to the Client. If the neighbor cache entry is in the DEPARTED state, 1454 the Proxy instead re-encpasulates the message with the address of the 1455 Client's Server as the SPAN destination address and forwards the 1456 packet to a Relay. The Proxy then returns an unsolicited NA message 1457 as discussed in Section 3.19. If there is no neighbor cache entry, 1458 the Proxy instead discards the packet. 1460 3.12.3. Server/Gateway Forwarding Algorithm 1462 For control messages destined to a target Client's AERO address that 1463 are received from a secured tunnel, the Server (acting as a MAP) 1464 intercepts the message and sends an appropriate response on behalf of 1465 the Client. (For example, the Server sends an NA message reply in 1466 response to an NS message directed to one of its associated Clients.) 1467 If the Client's neighbor cache entry is in the DEPARTED state, 1468 however, the Server instead forwards the packet to the Client's new 1469 Server as discussed in Section 3.19. 1471 When the Server receives an encapsulated data packet from an INET 1472 neighbor or from a secured tunnel, it accepts the packet only if data 1473 origin authentication succeeds. If the SPAN destination address is 1474 its own adddress, the Server reassembles if necessary and discards 1475 the SPAN header (if the reassembly is incomplete, the Server instead 1476 adds the fragment to the reassembly buffer and returns). The Server 1477 then continues processing as follows: 1479 o if the destination matches a symmetric neighbor cache entry in the 1480 REACHABLE state the Server prepares the packet for forwarding to 1481 the destination Client. If the current header is a SPAN header, 1482 the Server reassembles if necessary and discards the SPAN header 1483 (if the reassembly is incomplete, the Server instead adds the 1484 fragment to the reassembly buffer and returns). The Server then 1485 forwards the packet according to the cached link-layer 1486 information, while using SPAN encapsulation for the Client's 1487 Proxyed/Native interfaces, simple INET encapsulation for NATed/ 1488 VPNed interfaces, or no encapsulation for Direct interfaces. If 1489 the packet is destined to the same Client from which it arrived 1490 (i.e., if the packet was forwarded by one of the Client's Proxys), 1491 the Server forwards the packet via a different "reachable" 1492 neighbor interface than the one the packet arrived on. If there 1493 are no "reachable" neighbor interfaces, the Server drops the 1494 packet. 1496 o else, if the destination matches a symmetric neighbor cache entry 1497 in the DEPARETED state the Server encapsulates the packet in a new 1498 SPAN header and forwards it to the Client's new Server (noting 1499 that the encapsulation may result in the addition of a second SPAN 1500 header). The Server uses its own SPAN address as the source and 1501 the SPAN address of the new Server as the destination. 1503 o else, if the destination matches an asymmetric neighbor cache 1504 entry, the Server uses one or more "reachable" neighbor interfaces 1505 in the entry for packet forwarding via the local INET if the 1506 neighbor is in the same SPAN segment or via a Relay otherwise. 1508 o else, if the destination is an AERO address that is not assigned 1509 on the AERO interface the Server drops the packet. 1511 o else, the Server (acting as a Gateway) releases the packet to the 1512 network layer for local delivery or IP forwarding. Based on the 1513 information in the forwarding table, the network layer may return 1514 the packet to the same AERO interface in which case further 1515 processing occurs as below. (Note that this arrangement 1516 accommodates common implementations in which the IP forwarding 1517 table is not accessible from within the AERO interface. If the 1518 AERO interface can directly access the IP forwarding table, the 1519 forwarding table lookup can instead be performed internally from 1520 within the AERO interface itself.) 1522 When the Server's AERO interface receives a data packet from the 1523 network layer or from a NATed/VPNed/Direct Client, it processes the 1524 packet according to the network-layer destination address as follows: 1526 o if the destination matches a symmetric or asymmetric neighbor 1527 cache entry the Server processes the packet as above. 1529 o else, the Server encapsulates the packet and forwards it to a 1530 Relay. For administratively-assigned AERO address destinations, 1531 the Server uses the SPAN address corresponding to the destination 1532 as the SPAN destination address. For Client AERO address 1533 destinations, the Server uses the Subnet Router Anycast address 1534 corresponding to the destination as the SPAN destination address. 1535 For all others, the Server uses the packet's destination IP 1536 address as the SPAN destination address. 1538 3.12.4. Relay Forwarding Algorithm 1540 Relays forward packets over secured tunnels the same as any IP 1541 router. When the Relay receives an encapsulated packet via a secured 1542 tunnel, it removes the INET header and searches for a forwarding 1543 table entry that matches the destination address in the next header. 1544 The Relay then processes the packet as follows: 1546 o if the destination matches one of the Relay's own addresses, the 1547 Relay submits the packet for local delivery. 1549 o else, if the destination matches a forwarding table entry the 1550 Relay forwards the packet via a secured tunnel to the next hop. 1551 If the destination matches an MSP without matching an MNP, 1552 however, the Relay instead drops the packet and returns an ICMP 1553 Destination Unreachable message subject to rate limiting (see: 1554 Section 3.14). 1556 o else, the Relay drops the packet and returns an ICMP Destination 1557 Unreachable as above. 1559 As for any IP router, the Relay decrements the TTL/Hop Limit when it 1560 forwards the packet. If the packet is encapsulated in a SPAN header, 1561 only the Hop Limit in the SPAN header is decremented, and not the 1562 TTL/Hop Limit in the inner packet header. 1564 3.13. AERO Interface MTU and Fragmentation 1566 The AERO interface is the node's attachment to the AERO link. For 1567 AERO link neighbor underlying interface paths that do not require 1568 encapsulation, the AERO interface sends unencapsulated IP packets. 1569 For other paths, the AERO interface acts as a tunnel ingress when it 1570 sends packets to the neighbor and as a tunnel egress when it receives 1571 packets from the neighbor. 1573 AERO interfaces configure an MTU the same as for any IP interface, 1574 however the MTU does not reflect the physical size of any links in 1575 the path but rather determines the maximum size for reassembly. AERO 1576 interfaces observe the packet sizing considerations for tunnels 1577 discussed in [I-D.ietf-intarea-tunnels] and as specified below. 1579 The Internet Protocol expects that IP packets will either be 1580 delivered to the destination or a suitable Packet Too Big (PTB) 1581 message returned to support the process known as IP Path MTU 1582 Discovery (PMTUD) [RFC1191][RFC8201]. However, PTB messages may be 1583 crafted for malicious purposes or lost in the network [RFC2923]. 1584 This can be especially problematic for tunnels, where a condition 1585 known as a PMTUD "black hole" can result. For these reasons, AERO 1586 interfaces employ operational procedures that avoid interactions with 1587 PMTUD, including the use of fragmentation when necessary. 1589 AERO interfaces observe three different types of fragmentation. 1590 Source fragmentation occurs when the AERO interface (acting as a 1591 tunnel ingress) fragments the encapsulated packet into multiple 1592 fragments before admitting each fragment into the tunnel. Network 1593 fragmentation occurs when an encapsulated packet admitted into the 1594 tunnel by the ingress is fragmented by an IPv4 router on the path to 1595 the egress. Finally, link-layer fragmentation (aka link adaptation) 1596 occurs at a layer below IP and is coordinated between underlying data 1597 link endpoints. 1599 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1600 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1601 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1602 for IPv4 even if encapsulated packets may incur network 1603 fragmentation. 1605 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1606 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1607 (but, note that many standard IPv6 over IPv4 tunnel types already 1608 assume a larger MRU than the IPv4 minimum). 1610 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1611 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1612 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1613 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1614 configure a Maximum Segment Unit (MSU) as the maximum-sized 1615 encapsulated packet that the ingress can inject into the tunnel 1616 without source fragmentation. The MSU value MUST NOT be larger than 1617 1280 bytes unless there is operational assurance that a larger size 1618 can traverse the link along all paths. 1620 All AERO interfaces on the link MUST configure the same MTU value for 1621 reasons cited in [RFC3819][RFC4861]; in particular, multicast support 1622 requires a common MTU value among all nodes on the link. All AERO 1623 interfaces MUST configure an MRU large enough to reassemble packets 1624 up to (MTU+ENCAPS) bytes in length; nodes that cannot configure a 1625 large-enough MRU MUST NOT enable an AERO interface. For example, for 1626 an MTU of 1500 bytes an appropriate MRU might be 2KB. 1628 The network layer proceeds as follows when it forwards an IP packet 1629 to the AERO interface. For each IPv4 packet that is larger than the 1630 AERO interface MTU and with DF set to 0, the network layer uses IPv4 1631 fragmentation to break the packet into a minimum number of non- 1632 overlapping fragments where the first fragment is no larger than the 1633 MTU and the remaining fragments are no larger than the first. For 1634 all other IP packets, if the packet is larger than the AERO interface 1635 MTU, the network layer drops the packet and returns a PTB message to 1636 the original source. Otherwise, the network layer admits each IP 1637 packet or fragment into the AERO interface. 1639 For each IP packet admitted into the AERO interface, if the neighbor 1640 is reached via an underlying interface that does not require 1641 encapsulation the AERO interface proceeds according to the underlying 1642 interface MTU. If the packet is no larger than the underlying 1643 interface MTU, the AERO interface presents the packet to the 1644 underlying interface. Otherwise, for IPv4 packets with DF set to 0 1645 the AERO interface uses IPv4 fragmentation to break the packet into 1646 fragments no larger than the underlying interface MTU. For other 1647 packets, the AERO interface either performs link adaptation or drops 1648 the packet and returns a PTB message to the original source. (If the 1649 original source corresponds to a local application, the PTB would 1650 appear to have originated from a router on the path when in fact it 1651 was locally generated from within the AERO interface.) In the same 1652 way, when a packet that has been admitted into the AERO link reaches 1653 a target neighbor but is too large to be delivered over the final-hop 1654 underlying interface, the target either performs link adaptation or 1655 drops the packet and returns a PTB. Link adaptation is preferred in 1656 both cases when possible to avoid packet loss. 1658 For underlying interfaces that require encapsulation, the AERO 1659 interface (acting as a tunnel ingress) instead encapsulates the 1660 packet in a SPAN header. If the SPAN packet is larger than the MSU, 1661 the ingress source fragments the SPAN packet into a minimum number of 1662 non-overlapping fragments where the first fragment is no larger than 1663 the MSU and the remaining fragments are no larger than the first. 1664 The ingress then encapsulates each SPAN packet/fragment in an INET 1665 header and admits them into the tunnel. For IPv4, the ingress sets 1666 the DF bit to 0 in the INET header in case any network fragmentation 1667 is necessary. The encapsulated packets will be delivered to the 1668 egress, which reassembles them into a whole packet if necessary. 1670 By fragmenting at the SPAN layer instead of lower layers, standard 1671 IPv6 fragmentation and reassembly [RFC8200] ensures that IPv4 issues 1672 such as data corruption due to reassembly misassociations will not 1673 occur [RFC6864][RFC4963]. Incomplete reassemblies are discarded when 1674 the corresponding neighbor cache entry is deleted. 1676 Since the SPAN header and IPv6 fragment extension header reduces the 1677 room available for packet data, but the original source has no way to 1678 control its insertion, the ingress MUST include their lengths in 1679 ENCAPS even for packets in which the header is absent. 1681 3.13.1. MTU and Fragmentation in the ATN/IPS 1683 The Aeronautical Telecommunications Network with Internet Protocol 1684 Services (ATN/IPS) is an IPv6 mobile networking service designed to 1685 support communications for aircraft operating over various aviation 1686 wireless data links. These links are often bandwidth-constrained and 1687 with high cost, packet loss and error rate profiles. 1689 Aircraft often communicate with the ground domain directly over 1690 aviation data links without over-the-air encapsulation, where the 1691 full MTU of the data link is available for conveying useful data. 1692 The cost-per-bit, bandwidth and reliability are often maximized by 1693 sending the largest possible packets within a single channel access. 1694 The ATN/IPS ground domain therefore must never drop a packet that was 1695 successfully transmitted by an aircraft due to size expansion caused 1696 by encapsulation. Instead, ground domain nodes employ source 1697 fragmentation during encapsulation so that the packet can 1698 successfully traverse the AERO link. 1700 The ATN/IPS therefore SHOULD institute an AERO link MTU of 1500 bytes 1701 or larger. Aviation data links that configure a smaller native MTU 1702 SHOULD perform link adaptation at a layer below IP; otherwise, they 1703 must drop packets that are too large and return a PTB. 1705 3.14. AERO Interface Error Handling 1707 When an AERO node admits encapsulated packets into the AERO 1708 interface, it may receive link-layer or network-layer error 1709 indications. 1711 A link-layer error indication is an ICMP error message generated by a 1712 router in the INET on the path to the neighbor or by the neighbor 1713 itself. The message includes an IP header with the address of the 1714 node that generated the error as the source address and with the 1715 link-layer address of the AERO node as the destination address. 1717 The IP header is followed by an ICMP header that includes an error 1718 Type, Code and Checksum. Valid type values include "Destination 1719 Unreachable", "Time Exceeded" and "Parameter Problem" 1720 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1721 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1722 only emit packets that are guaranteed to be no larger than the IP 1723 minimum link MTU as discussed in Section 3.13.) 1725 The ICMP header is followed by the leading portion of the packet that 1726 generated the error, also known as the "packet-in-error". For 1727 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1728 much of invoking packet as possible without the ICMPv6 packet 1729 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1730 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1731 "Internet Header + 64 bits of Original Data Datagram", however 1732 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1733 ICMP datagram SHOULD contain as much of the original datagram as 1734 possible without the length of the ICMP datagram exceeding 576 1735 bytes". 1737 The link-layer error message format is shown in Figure 5 (where, "L2" 1738 and "L3" refer to link-layer and network-layer, respectively): 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 ~ ~ 1742 | L2 IP Header of | 1743 | error message | 1744 ~ ~ 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 | L2 ICMP Header | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1748 ~ ~ P 1749 | IP and other encapsulation | a 1750 | headers of original L3 packet | c 1751 ~ ~ k 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1753 ~ ~ t 1754 | IP header of | 1755 | original L3 packet | i 1756 ~ ~ n 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 ~ ~ e 1759 | Upper layer headers and | r 1760 | leading portion of body | r 1761 | of the original L3 packet | o 1762 ~ ~ r 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1765 Figure 5: AERO Interface Link-Layer Error Message Format 1767 The AERO node rules for processing these link-layer error messages 1768 are as follows: 1770 o When an AERO node receives a link-layer Parameter Problem message, 1771 it processes the message the same as described as for ordinary 1772 ICMP errors in the normative references [RFC0792][RFC4443]. 1774 o When an AERO node receives persistent link-layer Time Exceeded 1775 messages, the IP ID field may be wrapping before earlier fragments 1776 awaiting reassembly have been processed. In that case, the node 1777 SHOULD begin including integrity checks and/or institute rate 1778 limits for subsequent packets. 1780 o When an AERO node receives persistent link-layer Destination 1781 Unreachable messages in response to encapsulated packets that it 1782 sends to one of its asymmetric neighbor correspondents, the node 1783 SHOULD process the message as an indication that a path may be 1784 failing, and MAY initiate NUD over that path. If it receives 1785 Destination Unreachable messages on many or all paths, the node 1786 SHOULD set ReachableTime for the corresponding asymmetric neighbor 1787 cache entry to 0 and allow future packets destined to the 1788 correspondent to flow through a default route. 1790 o When an AERO Client receives persistent link-layer Destination 1791 Unreachable messages in response to encapsulated packets that it 1792 sends to one of its symmetric neighbor Servers, the Client SHOULD 1793 mark the path as unusable and use another path. If it receives 1794 Destination Unreachable messages on many or all paths, the Client 1795 SHOULD associate with a new Server and release its association 1796 with the old Server as specified in Section 3.19.5. 1798 o When an AERO Server receives persistent link-layer Destination 1799 Unreachable messages in response to encapsulated packets that it 1800 sends to one of its symmetric neighbor Clients, the Server SHOULD 1801 mark the underlying path as unusable and use another underlying 1802 path. If it receives Destination Unreachable messages on multiple 1803 paths, the Server should take no further actions unless it 1804 receives an explicit ND/PD release message or if the PD lifetime 1805 expires. In that case, the Server MUST release the Client's 1806 delegated MNP, withdraw the MNP from the AERO routing system and 1807 delete the neighbor cache entry. 1809 o When an AERO Server or Proxy receives link-layer Destination 1810 Unreachable messages in response to an encapsulated packet that it 1811 sends to one of its permanent neighbors, it treats the messages as 1812 an indication that the path to the neighbor may be failing. 1813 However, the dynamic routing protocol should soon reconverge and 1814 correct the temporary outage. 1816 When an AERO Relay receives a packet for which the network-layer 1817 destination address is covered by an MSP, if there is no more- 1818 specific routing information for the destination the Relay drops the 1819 packet and returns a network-layer Destination Unreachable message 1820 subject to rate limiting. The Relay writes the network-layer source 1821 address of the original packet as the destination address and uses 1822 one of its non link-local addresses as the source address of the 1823 message. 1825 When an AERO node receives an encapsulated packet for which the 1826 reassembly buffer it too small, it drops the packet and returns a 1827 network-layer Packet Too Big (PTB) message. The node first writes 1828 the MRU value into the PTB message MTU field, writes the network- 1829 layer source address of the original packet as the destination 1830 address and writes one of its non link-local addresses as the source 1831 address. 1833 3.15. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1835 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1836 coordinated as discussed in the following Sections. 1838 3.15.1. AERO ND/PD Service Model 1840 Each AERO Server on the link configures a PD service to facilitate 1841 Client requests. Each Server is provisioned with a database of MNP- 1842 to-Client ID mappings for all Clients enrolled in the AERO service, 1843 as well as any information necessary to authenticate each Client. 1844 The Client database is maintained by a central administrative 1845 authority for the AERO link and securely distributed to all Servers, 1846 e.g., via the Lightweight Directory Access Protocol (LDAP) [RFC4511], 1847 via static configuration, etc. Clients can receive new PDs from new 1848 Servers before releasing PDs received from existing Servers for 1849 service continuity. Clients receive the same service regardless of 1850 the Servers they select, although selecting Servers that are 1851 topologically nearby may provide better routing. 1853 AERO Clients and Servers use ND messages to maintain neighbor cache 1854 entries. AERO Servers configure their AERO interfaces as advertising 1855 interfaces, and therefore send unicast RA messages with configuration 1856 information in response to a Client's RS message. Thereafter, 1857 Clients send additional RS messages to refresh prefix and/or router 1858 lifetimes. 1860 AERO Clients and Servers include PD parameters in RS/RA messages (see 1861 [I-D.templin-6man-dhcpv6-ndopt] for ND/PD alternatives). The unified 1862 ND/PD messages are exchanged between Client and Server according to 1863 the prefix management schedule required by the PD service. If the 1864 Client knows its MNP in advance, it can include its AERO address as 1865 the source address of an RS message and with an SLLAO with a valid 1866 Prefix Length for the MNP. If the Server (and Proxy) accept the 1867 Client's MNP assertion, they inject the prefix into the routing 1868 system and establish the necessary neighbor cache state. 1870 The following sections specify the Client and Server behavior. 1872 3.15.2. AERO Client Behavior 1874 AERO Clients can discover the addresses of Servers in the MAP list 1875 via static configuration (e.g., from a flat-file map of Server 1876 addresses and locations), or through an automated means such as 1877 Domain Name System (DNS) name resolution [RFC1035]. In the absence 1878 of other information, the Client can resolve the DNS Fully-Qualified 1879 Domain Name (FQDN) "linkupnetworks.[domainname]" where 1880 "linkupnetworks" is a constant text string and "[domainname]" is a 1881 DNS suffix for the AERO link (e.g., "example.com"). Alternatively, 1882 the Client can discover the Server's address through a multicast RS 1883 as described below. 1885 To associate with a Server, the Client acts as a requesting router to 1886 request MNPs. The Client prepares an RS message with PD parameters 1887 (e.g., with an SLLAO with non-zero Prefix Length) and SHOULD include 1888 a Nonce and Timestamp option if the Client needs to correlate RA 1889 replies. If the Client already knows the Server's AERO address, it 1890 includes the AERO address as the network-layer destination address; 1891 otherwise, it includes all-routers multicast (ff02::2) as the 1892 network-layer destination address. If the Client already knows its 1893 own AERO address, it uses the AERO address as the network-layer 1894 source address; otherwise, it uses the unspecified AERO address 1895 (fe80::ffff:ffff) as the network-layer source address. 1897 The Client next includes an SLLAO in the RS message formatted as 1898 described in Section 3.6 to register its link-layer information with 1899 the Server. The SLLAO corresponding to the ANET interface over which 1900 the Client will send the RS message MUST set S to 1. The Client MAY 1901 include additional SLLAOs specific to other underlying interfaces, 1902 but if so it MUST set their S, Port Number and Link Layer Address 1903 fields to 0. If the Client is connected to an ANET for which 1904 encapsulation is required, the Client finally encapsulates the RS 1905 message in an ANET header with its own ANET address as the source 1906 address and the INET address of the Server as the destination. 1908 The Client then sends the RS message (either directly via Direct 1909 interfaces, via INET encapsulation for NATed interfaces, via a VPN 1910 for VPNed interfaces, via a Proxy for proxyed interfaces or via a 1911 Relay for native interfaces) and waits for an RA message reply (see 1912 Section 3.15.3). The Client retries up to MAX_RTR_SOLICITATIONS 1913 times until an RA is received. If the Client receives no RAs, or if 1914 it receives an RA with Router Lifetime set to 0, the Client SHOULD 1915 abandon this Server and try another Server. Otherwise, the Client 1916 processes the PD information found in the RA message. 1918 Next, the Client creates a symmetric neighbor cache entry with the 1919 Server's AERO address as the network-layer address and the address in 1920 the first SLLAO as the Server's INET address. The Client records the 1921 RA Router Lifetime field value in the neighbor cache entry as the 1922 time for which the Server has committed to maintaining the MNP in the 1923 routing system. The Client then autoconfigures AERO addresses for 1924 each of the delegated MNPs and assigns them to the AERO interface. 1925 The Client also caches any MSPs included in Route Information Options 1926 (RIOs) [RFC4191] as MSPs to associate with the AERO link, and assigns 1927 the MTU value in the MTU option to its AERO interface while 1928 configuring an appropriate MRU. 1930 The Client then registers additional ANET interfaces with the Server 1931 by sending RS messages via each additional ANET interface. The RS 1932 messages include the same parameters as for the initial RS/RA 1933 exchange, but with destination address set to the Server's AERO 1934 address and with an SLLAO specific to the ANET interface. 1936 The Client examines the X and N bits in the SLLAO with S set to 1 in 1937 each RA message it receives. If X is 1 the Client infers that there 1938 is a Proxy on the path, and if N is 1 the Client infers that there is 1939 a NAT on the path. If N is 1, the Client SHOULD set Port Number and 1940 Link-Layer Address to 0 in the first S/TLLAO of any subsequent ND 1941 messages it sends to the Server over that link. 1943 Following autoconfiguration, the Client sub-delegates the MNPs to its 1944 attached EUNs and/or the Client's own internal virtual interfaces as 1945 described in [I-D.templin-v6ops-pdhost] to support the Client's 1946 downstream attached "Internet of Things (IoT)". The Client 1947 subsequently maintains its MNP delegations through each of its 1948 Servers by sending additional RS messages before Router Lifetime 1949 expires. 1951 After the Client registers its ANET interfaces, it may wish to change 1952 one or more registrations, e.g., if an ANET interface changes address 1953 or becomes unavailable, if QoS preferences change, etc. To do so, 1954 the Client prepares an RS message to send over any available ANET 1955 interface. The RS MUST include an SLLAO with S set to 1 for the 1956 selected ANET interface and MAY include any additional SLLAOs 1957 specific to other ANET interfaces. The Client includes fresh P(i) 1958 values in each SLLAO to update the Server's neighbor cache entry. If 1959 the Client wishes to update only the P(i) values, it sets the Port 1960 Number and Link-Layer Address fields to 0. If the Client wishes to 1961 disable the underlying interface, it sets D to 1. When the Client 1962 receives the Server's RA response, it has assurance that the Server 1963 has been updated with the new information. 1965 If the Client wishes to discontinue use of a Server it issues an RS 1966 message over any underlying interface with an SLLAO with R set to 1 . 1967 When the Server processes the message, it releases the MNP, sets the 1968 symmetric neighbor cache entry state for the Client to DEPARTED, 1969 withdraws the IP route from the routing system and returns an RA 1970 reply with Router Lifetime set to 0. 1972 Clients SHOULD NOT remain associated with multiple Servers for long 1973 durations, since routing inconsistencies could cause some fragments 1974 of a fragmented packet to be delivered to Server A and others to 1975 Server B. Clients SHOULD therefore associate with a single primary 1976 Server, and send a departure message to the former Server soon after 1977 moving to a new Server. 1979 3.15.3. AERO Server Behavior 1981 AERO Servers act as IP routers and support a PD service for Clients. 1982 Servers arrange to add their AERO and INET addresses to a static map 1983 of Server addresses for the link and/or the DNS resource records for 1984 the FQDN "linkupnetworks.[domainname]" before entering service. The 1985 list of Server addresses should be geographically and/or 1986 topologically referenced, and forms the MAP list for the AERO link. 1988 When a Server receives a prospective Client's RS message on its AERO 1989 interface, it SHOULD return an immediate RA reply with Router 1990 Lifetime set to 0 if it is currently too busy or otherwise unable to 1991 service the Client. Otherwise, the Server authenticates the RS 1992 message and processes the PD parameters. The Server first determines 1993 the correct MNPs to delegate to the Client by searching the Client 1994 database. When the Server delegates the MNPs, it also creates an IP 1995 forwarding table entry for each MNP so that the MNPs are propagated 1996 into the routing system (see: Section 3.3). For IPv6, the Server 1997 creates a single IPv6 forwarding table entry for each MNP. For IPv4, 1998 the Server creates both an IPv4 forwarding table entry and an IPv6 1999 forwarding table entry with the IPv4-mapped IPv6 address 2000 corresponding to the IPv4 address. 2002 The Server next creates a symmetric neighbor cache entry for the 2003 Client using the base AERO address as the network-layer address and 2004 with lifetime set to no more than the smallest PD lifetime. Next, 2005 the Server updates the neighbor cache entry by recording the 2006 information in each SLLAO in the RS indexed by the Interface ID and 2007 including the Port Number, Link Layer Address and P(i) values. For 2008 the SLLAO with S set to 1, however, the Server records the actual 2009 INET header source addresses instead of those that appear in the 2010 SLLAO in case there was a NAT in the path. The Server also records 2011 the value of the X bit to indicate whether there is a Proxy on the 2012 path. 2014 Next, the Server prepares an RA message using its AERO address as the 2015 network-layer source address and the network-layer source address of 2016 the RS message as the network-layer destination address. The Server 2017 includes the delegated MNPs, any other PD parameters and an SLLAO 2018 with the Link Layer Address set to the Server's SPAN address and with 2019 Interface ID set to 0xffff. The Server then includes one or more 2020 RIOs that encode the MSPs for the AERO link, plus an MTU option for 2021 the link MTU (see Section 3.13). The Server finally forwards the 2022 message to the Client using SPAN, INET or NULL encapsulation 2023 according to the Client interface type. (For Proxy/Native 2024 interfaces, the Server encapsulates the message in a SPAN header with 2025 source address set to its own SPAN address and destination address 2026 set to the Proxy's (or Client's) SPAN address, then forwards the 2027 message into the SPAN.) 2029 After the initial RS/RA exchange, the Server maintains the symmetric 2030 neighbor cache entry for the Client. If the Client (or Proxy) issues 2031 additional NS/RS messages, the Server resets ReachableTime. If the 2032 Client (or Proxy) issues an RS with PD release parameters (e.g., by 2033 including an SLLAO with R set to 1), or if the Client becomes 2034 unreachable, the Server sets the Client's symmetric neighbor cache 2035 entry to the DEPARTED state and withdraws the IP routes from the AERO 2036 routing system. 2038 The Server processes these and any other Client ND/PD messages, and 2039 returns an NA/RA reply. The Server may also issue unsolicited RA 2040 messages, e.g., with PD reconfigure parameters to cause the Client to 2041 renegotiate its PDs, with Router Lifetime set to 0 if it can no 2042 longer service this Client, etc. Finally, If the symmetric neighbor 2043 cache entry is in the DEPARTED state, the Server deletes the entry 2044 after DepartTime expires. 2046 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 2048 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 2049 Servers are always on the same link (i.e., the AERO link) from the 2050 perspective of DHCPv6. However, in some implementations the DHCPv6 2051 server and ND function may be located in separate modules. In that 2052 case, the Server's AERO interface module can act as a Lightweight 2053 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 2054 the DHCPv6 server module. 2056 When the LDRA receives an authentic RS message, it extracts the PD 2057 message parameters and uses them to construct an IPv6/UDP/DHCPv6 2058 message. It sets the IPv6 source address to the source address of 2059 the RS message, sets the IPv6 destination address to 2060 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 2061 that will be understood by the DHCPv6 server. 2063 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 2064 header and includes an 'Interface-Id' option that includes enough 2065 information to allow the LDRA to forward the resulting Reply message 2066 back to the Client (e.g., the Client's link-layer addresses, a 2067 security association identifier, etc.). The LDRA also wraps the 2068 information in all of the SLLAOs from the RS message into the 2069 Interface-Id option, then forwards the message to the DHCPv6 server. 2071 When the DHCPv6 server prepares a Reply message, it wraps the message 2072 in a 'Relay-Reply' message and echoes the Interface-Id option. The 2073 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 2074 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 2075 uses the DHCPv6 message to construct an RA response to the Client. 2076 The Server uses the information in the Interface-Id option to prepare 2077 the RA message and to cache the link-layer addresses taken from the 2078 SLLAOs echoed in the Interface-Id option. 2080 3.16. The AERO Proxy 2082 Clients may connect to ANETs that require a perimeter security 2083 gateway to enable communications to Servers in outside INETs. In 2084 that case, the ANET can employ an AERO Proxy. The Proxy is located 2085 at the ANET/INET border and listens for RS messages originating from 2086 or RA messages destined to ANET Clients. The Proxy acts on these 2087 control messages as follows: 2089 o when the Proxy receives an RS message from a new ANET Client, it 2090 first authenticates the message then examines the network-layer 2091 destination address. If the destination address is a Server's 2092 AERO address, the Proxy proceeds to the next step. Otherwise, if 2093 the destination is all-routers multicast the Proxy selects a 2094 "nearby" Server that is likely to be a good candidate to serve the 2095 Client and replaces the destination address with the Server's AERO 2096 address. Next, the Proxy creates a proxy neighbor cache entry and 2097 caches the Client and Server addresses along with any identifying 2098 information including Transaction IDs, Client Identifiers, Nonce 2099 values, etc. The Proxy then examines the address in the RS 2100 message SLLAO with S set to 1. If the address is different than 2101 the Client's ANET address, the Proxy notes that the Client is 2102 behind a NAT. The Proxy then sets X to 1 and changes the Link 2103 Layer Address to its own SPAN address. The Proxy finally 2104 encapsulates the RS message in a SPAN header with destination set 2105 to the Server's SPAN address then forwards the message into the 2106 SPAN. 2108 o when the Server receives the RS message, it authenticates the 2109 message then creates or updates a symmetric neighbor cache entry 2110 for the Client with the Proxy's SPAN address as the link-layer 2111 address. The Server then sends an RA message with a single SLLAO 2112 back to the Proxy via the SPAN. 2114 o when the Proxy receives the RA message, it matches the message 2115 with the RS that created the proxy neighbor cache entry. The 2116 Proxy then caches the PD route information as a mapping from the 2117 Client's MNPs to the Client's ANET address, and sets the neighbor 2118 cache entry state to REACHABLE. The Proxy then changes the SLLAO 2119 Link Layer Address to its own ANET address, sets X to 1, sets N to 2120 1 if the Client is behind a NAT, then re-encapsulates the RA 2121 message in an ANET header and forwards it to the Client. 2123 After the initial RS/RA exchange, the Proxy forwards any Client data 2124 packets for which there is no matching asymmetric neighbor cache 2125 entry to the Server via the SPAN. Finally, the Proxy forwards any 2126 Client data destined to an asymmetric neighbor cache target directly 2127 to the target according to the link-layer information - the process 2128 of establishing asymmetric neighbor cache entries is specified in 2129 Section 3.17. 2131 While the Client is still attached to the ANET, the Proxy 2132 periodically sends NS/RS messages to update the Server's symmetric 2133 neighbor cache entries on behalf of the Client and/or to convey QoS 2134 updates. If the Server ceases to send solicited NA/RA responses, the 2135 Proxy marks the Server as unreachable and sends an unsolicited RA 2136 with Router Lifetime set to zero to inform the Client that this 2137 Server is no longer able to provide Service. If the Client becomes 2138 unreachable, the Proxy sets the neighbor cache entry state to 2139 DEPARTED and sends an RS message to the Server with an SLLAO with D 2140 set to 1 and with Interface ID set to the Client's interface ID so 2141 that the Server will de-register this Interface ID. Although the 2142 Proxy engages in these ND exchanges on behalf of the Client, the 2143 Client can also send ND messages on its own behalf, e.g., if it is in 2144 a better position than the Proxy to convey QoS changes, etc. 2146 In some ANETs that employ a Proxy, the Client's MNP can be injected 2147 into the ANET routing system. In that case, the Client can send data 2148 messages without encapsulation so that the ANET native routing system 2149 transports the unencapsulated packets to the Proxy. This can be very 2150 beneficial, e.g., if the Client connects to the ANET via low-end data 2151 links such as some aviation wireless links. 2153 If the first-hop ANET access router is AERO-aware, the Client can 2154 avoid encapsulation for both its control and data messages. When the 2155 Client connects to the link, it can send an unencapsulated RS message 2156 with source address set to its AERO address and with destination 2157 address set to the AERO address of the Client's selected Server or to 2158 all-routers multicast. The Client includes an SLLAO with Interface 2159 ID, Prefix Length and P(i) information but with Port Number and Link- 2160 Layer Address set to 0. 2162 The Client then sends the unencapsulated RS message, which will be 2163 intercepted by the AERO-Aware access router. The access router then 2164 encapsulates the RS message in an ANET header with its own address as 2165 the source address and the address of a Proxy as the destination 2166 address. The access router further remembers the address of the 2167 Proxy so that it can encapsulate future data packets from the Client 2168 via the same Proxy. If the access router needs to change to a new 2169 Proxy, it simply sends another RS message toward the Server via the 2170 new Proxy on behalf of the Client. 2172 In some cases, the access router and Proxy may be one and the same 2173 node. In that case, the node would be located on the same physical 2174 link as the Client, but its message exchanges with the Server would 2175 need to pass through a security gateway at the ANET/INET border. The 2176 method for deploying access routers and Proxys (i.e. as a single node 2177 or multiple nodes) is an ANET-local administrative consideration. 2179 3.17. AERO Route Optimization 2181 While data packets are flowing between a source and target node, 2182 route optimization SHOULD be used. Route optimization is initiated 2183 by the first eligible Route Optimization Source (ROS) closest to the 2184 source as follows: 2186 o For Clients on VPNed, NATed and Direct interfaces, the Server is 2187 the ROS. 2189 o For Clients on Proxyed interfaces, the Proxy is the ROS. 2191 o For Clients on native interfaces, the Client itself is the ROS. 2193 o For correspondent nodes on INET/EUN interfaces serviced by a 2194 Gateway, the Gateway is the ROS. 2196 The route optimization procedure is conducted between the ROS and the 2197 target Server/Gateway acting as a Route Optimization Responder (ROR) 2198 in the same manner as for IPv6 ND Address Resolution and using the 2199 same NS/NA messaging. The target may either be a MNP Client serviced 2200 by a Server, or a non-MNP correspondent reachable via a Gateway. 2202 The procedures are specified in the following sections. 2204 3.17.1. Route Optimization Initiation 2206 While data packets are flowing from the source node toward a target 2207 node, the ROS performs address resolution by sending an NS message to 2208 receive a solicited NA message from the ROR. 2210 When the ROS sends an NS, it includes the AERO address of the ROS as 2211 the source address (e.g., fe80::1) and the AERO address corresponding 2212 to the data packet's destination address as the destination address 2213 (e.g., if the destination address is 2001:db8:1:2::1 then the 2214 corresponding AERO address is fe80::2001:db8:1:2). The NS message 2215 includes an SLLAO with Link Layer Address set to the SPAN address of 2216 the ROS and with all other fields set to 0. The message SHOULD also 2217 include a Nonce and Timestamp option if the ROS needs to correlate NA 2218 replies. 2220 The ROS then encapsulates the NS message in a SPAN header with source 2221 set to its own SPAN address and destination set to the data packet's 2222 destination address, then sends it into the SPAN without decrementing 2223 the network-layer TTL/Hop Limit field. 2225 3.17.2. Relaying the NS 2227 When the Relay receives the NS message from the ROS, it discards the 2228 INET header and determines that the ROR is the next hop by consulting 2229 its standard IPv6 forwarding table for the SPAN header destination 2230 address. The Relay then forwards the SPAN message toward the ROR the 2231 same as for any IPv6 router. The final-hop Relay in the SPAN will 2232 deliver the message via a secured tunnel to the ROR. 2234 3.17.3. Processing the NS and Sending the NA 2236 When the ROR receives the NS message, it examines the AERO 2237 destination address to determine whether it has a neighbor cache 2238 entry and/or route that matches the target; if not, it drops the NS 2239 message and returns from processing. Next, if the target belongs to 2240 an MNP Client neighbor in the DEPARTED state the ROR changes the NS 2241 message SPAN destination address to the address of the Client's new 2242 Server, forwards the message into the SPAN and returns from 2243 processing. If the target belongs to an MNP Client neighbor in the 2244 REACHABLE state, the ROR instead adds the AERO source address to the 2245 target Client's Report List with time set to ReportTime. If the 2246 target belongs to a non-MNP route, the ROR continues processing 2247 without adding an entry to the Report List. 2249 The ROR then prepares a solicited NA message to send back to the ROS 2250 but does not create a neighbor cache entry. The ROR sets the NA 2251 source address to the destination AERO address of the NS, and 2252 includes the Nonce value received in the NS plus the current 2253 Timestamp. The ROR next includes a TLLAO with Interface ID set to 2254 0xffff, with S set to 1, with all P(i) values set to "low", and with 2255 Link Layer Address set to the ROR's SPAN address. If the target 2256 belongs to an MNP Client, the ROR sets the Prefix Length to the MNP 2257 prefix length; otherwise, it sets Prefix Length to the maximum of the 2258 non-MNP prefix length and 64. (Note that a /64 limit is imposed to 2259 avoid causing the ROS to set short prefixes (e.g., "default") that 2260 would match destinations for which the routing system includes more- 2261 specific prefixes. Note also that prefix lengths longer than /64 are 2262 out of scope for this specification.) 2264 If the target belongs to an MNP Client, the ROR next includes 2265 additional TLLAOs for all of the target Client's Interface IDs. For 2266 NATed, VPNed and Direct interfaces, the TLLAO Link Layer Addresses 2267 are the SPAN address of the ROR. For Proxyed and native interfaces, 2268 the TLLAO Link Layer Addresses are the SPAN addresses of the Proxys 2269 and the Client's native interfaces. The ROR finally encapsulates the 2270 NA message in a SPAN header with source set to its own SPAN address 2271 and destination set to the source SPAN address of the NS message, 2272 then forwards the message into the SPAN without decrementing the 2273 network-layer TTL/Hop Limit field. 2275 3.17.4. Relaying the NA 2277 When the Relay receives the NA message from the ROR, it discards the 2278 INET header and determines that the ROS is the next hop by consulting 2279 its standard IPv6 forwarding table for the SPAN header destination 2280 address. The Relay then forwards the SPAN-encapsulated NA message 2281 toward the ROS the same as for any IPv6 router. The final-hop Relay 2282 in the SPAN will deliver the message via a secured tunnel to the ROS. 2284 3.17.5. Processing the NA 2286 When the ROS receives the solicited NA message, it discards the INET 2287 and SPAN headers. The ROS next verifies the Nonce and Timestamp 2288 values, then creates an asymmetric neighbor cache entry for the ROR 2289 and caches all information found in the solicited NA TLLAOs. The ROS 2290 finally sets the asymmetric neighbor cache entry lifetime to 2291 ReachableTime seconds. 2293 3.17.6. Route Optimization Maintenance 2295 Following route optimization, the ROS forwards future data packets 2296 destined to the target via the addresses found in the cached link- 2297 layer information. The route optimization is shared by all sources 2298 that send packets to the target via the ROS, i.e., and not just the 2299 source on behalf of which the route optimization was initiated. 2301 While new data packets destined to the target are flowing through the 2302 ROS, it sends additional NS messages to the ROR before ReachableTime 2303 expires to receive a fresh solicited NA message the same as described 2304 in the previous sections. (Route optimization refreshment strategies 2305 are an implementation matter, with a non-normative example given in 2306 Appendix C.1). 2308 The ROS then updates the asymmetric neighbor cache entry to refresh 2309 ReachableTime, while (for MNP destinations) the ROR adds or updates 2310 the ROS address to the target Client's Report List and with time set 2311 to ReportTime. While no data packets are flowing, the ROS instead 2312 allows ReachableTime for the asymmetric neighbor cache entry to 2313 expire. When ReachableTime expires, the ROS deletes the asymmetric 2314 neighbor cache entry. Future data packets flowing through the ROS 2315 will again trigger a new route optimization exchange while initial 2316 data packets travel over a suboptimal route. 2318 The ROS may also receive unsolicited NA messages from the ROR at any 2319 time. If there is an asymmetric neighbor cache entry for the target, 2320 the ROS updates the link-layer information but does not update 2321 ReachableTime since the receipt of an unsolicited NA does not confirm 2322 that the forward path is still working. If there is no asymmetric 2323 neighbor cache entry, the route optimization source simply discards 2324 the unsolicited NA. Cases in which unsolicited NA messages are 2325 generated are specified in Section 3.19. 2327 In this arrangement, the ROS holds an asymmetric neighbor cache entry 2328 for the ROR, but the ROR does not hold an asymmetric neighbor cache 2329 entry for the ROS. The route optimization neighbor relationship is 2330 therefore asymmetric and unidirectional. If the target node also has 2331 packets to send back to the source node, then a separate route 2332 optimization procedure is performed in the reverse direction. But, 2333 there is no requirement that the forward and reverse paths be 2334 symmetric. 2336 3.18. Neighbor Unreachability Detection (NUD) 2338 AERO nodes perform Neighbor Unreachability Detection (NUD) per 2339 [RFC4861]. NUD is performed either reactively in response to 2340 persistent link-layer errors (see Section 3.14) or proactively to 2341 confirm reachability. The NUD algorithm may further be seeded by ND 2342 hints of forward progress, but care must be taken to avoid inferring 2343 reachability based on spoofed information. 2345 When an ROR directs an ROS to a neighbor with one or more target 2346 link-layer addresses, the ROS can proactively test each direct path 2347 by sending an initial NS message to elicit a solicited NA response. 2348 While testing the paths, the ROS can optionally continue sending 2349 packets via the SPAN, maintain a small queue of packets until target 2350 reachability is confirmed, or (optimistically) allow packets to flow 2351 via the direct paths. In any case, the ROS should only consider the 2352 neighbor unreachable if NUD fails over multiple target link-layer 2353 address paths. 2355 When a ROS sends an NS message used for NUD, it uses its AERO 2356 addresses as the IPv6 source address and the AERO address 2357 corresponding to a target link-layer address as the destination. For 2358 each target link-layer address, the source node encapsulates the NS 2359 message in SPAN/INET headers with its own SPAN address as the source 2360 and the SPAN address of the target as the destination, If the target 2361 is located within the same SPAN segment, the source sets the INET 2362 address of the target as the destination; otherwise, it sets the INET 2363 address of a Relay as the destination. The source then forwards the 2364 message into the SPAN. 2366 Paths that pass NUD tests are marked as "reachable", while those that 2367 do not are marked as "unreachable". These markings inform the AERO 2368 interface forwarding algorithm specified in Section 3.12. 2370 Proxys can perform NUD to verify Server reachability on behalf of 2371 their proxyed Clients so that the Clients need not engage in NUD 2372 messaging themselves. 2374 3.19. Mobility Management and Quality of Service (QoS) 2376 AERO is a Distributed Mobility Management (DMM) service. Each Server 2377 is responsible for only a subset of the Clients on the AERO link, as 2378 opposed to a Centralized Mobility Management (CMM) service where 2379 there is a single network mobility service for all Clients. Clients 2380 coordinate with their associated Servers via RS/RA exchanges to 2381 maintain the DMM profile, and the AERO routing system tracks all 2382 current Client/Server peering relationships. 2384 Servers provide a Mobility Anchor Point (MAP) for their dependent 2385 Clients. Clients are responsible for maintaining neighbor 2386 relationships with their Servers through periodic RS/RA exchanges, 2387 which also serves to confirm neighbor reachability. When a Client's 2388 underlying interface address and/or QoS information changes, the 2389 Client is responsible for updating the Server with this new 2390 information. Note that for Proxyed interfaces, however, the Proxy 2391 can perform the RS/RA exchanges on the Client's behalf. 2393 Mobility management considerations are specified in the following 2394 sections. 2396 3.19.1. Mobility Update Messaging 2398 Servers acting as MAPs accommodate mobility and/or QoS change events 2399 by sending an unsolicited NA message to each ROS in the target 2400 Client's Report List. When a MAP sends an unsolicited NA message, it 2401 sets the IPv6 source address to the Client's AERO address and sets 2402 the IPv6 destination address to all-nodes multicast (ff02::1). The 2403 MAP also includes a TLLAO with Interface ID 0xffff, S set to 1 and 2404 Link Layer address set to the MAP's SPAN address, and includes 2405 additional TLLAOs for all of the target Client's Interface IDs with 2406 Link Layer Addresses set to the corresponding SPAN addresses. The 2407 MAP finally encapsulates the message in a SPAN header with source set 2408 to its own SPAN address and destination set to the SPAN address of 2409 the ROS, then sends the message to a Relay in the SPAN. 2411 As for the hot-swap of interface cards discussed in Section 7.2.6 of 2412 [RFC4861], the transmission and reception of unsolicited NA messages 2413 is unreliable but provides a useful optimization. In well-connected 2414 Internetworks with robust data links unsolicited NA messages will be 2415 delivered with high probability, but in any case the MAP can 2416 optionally send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to 2417 each ROS to increase the likelihood that at least one will be 2418 received. 2420 When an ROS receives an unsolicited NA message, it ignores the 2421 message if there is no existing neighbor cache entry for the Client. 2422 Otherwise, it uses the included TLLAOs to update the Link Layer 2423 Address and QoS information in the neighbor cache entry, but does not 2424 reset ReachableTime since the receipt of an unsolicited NA message 2425 from the target Server does not provide confirmation that any forward 2426 paths to the target Client are working. 2428 If unsolicited NA messages are lost, the ROS may be left with stale 2429 address and/or QoS information for the Client for up to ReachableTime 2430 seconds. During this time, the ROS can continue sending packets to 2431 the target Client according to its current neighbor cache information 2432 but may receive persistent unsolicited NA messages as discussed in 2433 Section 3.19.5.1. 2435 3.19.2. Announcing Link-Layer Address and/or QoS Preference Changes 2437 When a Client needs to change its ANET addresses and/or QoS 2438 preferences (e.g., due to a mobility event), either the Client or its 2439 Proxys send RS messages to the Server via the SPAN with SLLAOs that 2440 include the new Client Port Number, Link Layer Address and P(i) 2441 values. If the RS messages are sent solely for the purpose of 2442 updating QoS preferences, Port Number and Link-Layer Address are set 2443 to 0. 2445 Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with 2446 sending actual data packets in case one or more RAs are lost. If all 2447 RAs are lost, the Client SHOULD re-associate with a new Server. 2449 When the Server receives the Client's changes, it sends unsolicited 2450 NA messages to all nodes in the Report List the same as described in 2451 the previous section. 2453 3.19.3. Bringing New Links Into Service 2455 When a Client needs to bring new ANET interfaces into service (e.g., 2456 when it activates a new data link), it sends an RS message to its 2457 Server via the ANET interface with SLLAOs that include the new Client 2458 Link Layer Address information. 2460 3.19.4. Removing Existing Links from Service 2462 When a Client needs to remove existing ANET interfaces from service 2463 (e.g., when it de-activates an existing data link), it sends an RS 2464 message to its Server with SLLAOs with D set to 1. 2466 If the Client needs to send RS messages over an ANET interface other 2467 than the one being removed from service, it MUST include a current 2468 SLLAO with S set to 1 for the sending interface and include 2469 additional SLLAOs with S set to 0 for any ANET interfaces being 2470 removed from service. 2472 3.19.5. Moving to a New Server 2474 When a Client associates with a new Server, it performs the Client 2475 procedures specified in Section 3.15.2. The Client then sends an RS 2476 message over any working ANET interface with destination set to the 2477 old Server's AERO address and with an SLLAO with R set to 1 to fully 2478 release itself from the old Server. The SLLAO also includes the SPAN 2479 address of the new Server in the Link Layer Address. If the Client 2480 does not receive an RA reply after MAX_RTR_SOLICITATIONS attempts 2481 over multiple ANET interfaces, the old Server may have failed and the 2482 Client should discontinue its release attempts. 2484 When the old Server processes the RS, it sends unsolicited NA 2485 messages with a single TLLAO with Interface ID set to 0xffff and with 2486 R and S set to 1 to all ROSs in the Client's Report List. The Server 2487 also changes the symmetric neighbor cache entry state to DEPARTED, 2488 sets the link-layer address of the Client to the address found in the 2489 RS SLLAO (i.e., the SPAN address of the new Server), and sets a timer 2490 to DepartTime seconds. The old Server then returns an immediate RA 2491 message to the Client with Router Lifetime set to 0. After a short 2492 delay (e.g., 2 seconds), the old Server withdraws the Client's MNP 2493 from the routing system. After DepartTime expires, the old Server 2494 deletes the symmetric neighbor cache entry. 2496 Clients SHOULD NOT move rapidly between Servers in order to avoid 2497 causing excessive oscillations in the AERO routing system. Examples 2498 of when a Client might wish to change to a different Server include a 2499 Server that has gone unreachable, topological movements of 2500 significant distance, movement to a new geographic region, movement 2501 to a new SPAN segment, etc. 2503 3.19.5.1. Accommodating Orphaned Fragments 2505 When a Client moves to a new Server, there is a chance that some of 2506 the fragments of a multiple fragment SPAN packet have already arrived 2507 at the old Server, while others are en route to the new Server. The 2508 old Server forwards these orphaned fragments to the new Server over 2509 the SPAN by encapsulating them in a second SPAN header with the old 2510 Server's SPAN address as the source and the SPAN address of the new 2511 Server as the destination. 2513 The new Server will then receive a packet that has an outer SPAN 2514 header inserted by the old Server and an inner SPAN header inserted 2515 by the original ROS. It then discards the outer SPAN header and adds 2516 the enclosed fragment to the reassembly buffer for this SPAN packet. 2517 If the Client has already departed from this new Server, the new 2518 Server instead re-encapsulates the fragment by replacing the outer 2519 SPAN header and forwarding the packet to the next Server the same as 2520 described above. In this way, wayward fragments will follow the 2521 trail of departed Servers until they eventually reach the current 2522 Server. 2524 Note that in some cases reassemblies may be left incomplete after the 2525 Client has departed. Proxys and Servers discard any incomplete 2526 reassemblies when the DEPARTED neighbor cache entry is deleted. 2528 3.20. Multicast 2530 The AERO Client provides an IGMP (IPv4) [RFC2236] or MLD (IPv6) 2531 [RFC3810] proxy service for its EUNs and/or hosted applications 2532 [RFC4605]. The Client forwards IGMP/MLD messages over any of its 2533 ANET interfaces for which group membership is required. The IGMP/MLD 2534 messages may be further forwarded by a first-hop ANET access router 2535 acting as an IGMP/MLD-snooping switch [RFC4541], then ultimately 2536 delivered to an AERO Proxy/Server acting as a Protocol Independent 2537 Multicast - Sparse-Mode (PIM-SM, or simply "PIM") Designated Router 2538 (DR) [RFC7761]. AERO Gateways also act as PIM routers (i.e., the 2539 same as AERO Proxys/Servers) on behalf of nodes on INET/EUN networks. 2540 The behaviors identified in the following sections correspond to 2541 Source-Specific Multicast (SSM) and Any-Source Multicast (ASM) 2542 operational modes. 2544 3.20.1. Source-Specific Multicast (SSM) 2546 When an ROS (i.e., an AERO Proxy/Server/Gateway) "X" acting as PIM 2547 router receives a Join/Prune message from a node on its downstream 2548 interfaces containing one or more ((S)ource, (G)roup) pairs, it 2549 updates its Multicast Routing Information Base (MRIB) accordingly. 2550 For each S belonging to a prefix reachable via X's non-AERO 2551 interfaces, X then forwards the (S, G) Join/Prune to any PIM routers 2552 on those interfaces per [RFC7761]. 2554 For each S belonging to a prefix reachable via X's AERO interface, X 2555 originates a separate copy of the Join/Prune for each (S,G) in the 2556 message using its own AERO address as the source address and ALL-PIM- 2557 ROUTERS as the destination address. X then encapsulates each message 2558 in a SPAN header with source address set to the SPAN address of X and 2559 destination address set to S then forwards the message into the SPAN. 2560 The SPAN in turn forwards the message to AERO Server/Gateway "Y" that 2561 services S. At the same time, if the message was a Join, X sends a 2562 route-optimization NS message toward each S the same as discussed in 2563 Section 3.17. The resulting NAs will return the AERO address for the 2564 prefix that matches S as the network-layer source address and TLLAOs 2565 with the SPAN addresses corresponding to any Interface IDs that are 2566 currently servicing S. 2568 When Y processes the Join/Prune message, if S located behind any 2569 Native, Direct, VPNed or NATed interfaces Y acts as a PIM router and 2570 updates its MRIB to list X as the next hop in the reverse path. If S 2571 is located behind any Proxys "Z"*, Y also forwards the message to 2572 each Z* over the SPAN while continuing to use the AERO address of X 2573 as the source address. Each Z* then updates its MRIB accordingly and 2574 maintains the AERO address of X as the next hop in the reverse path. 2575 Since the Relays in the SPAN do not examine network layer control 2576 messages, this means that the (reverse) multicast tree path is simply 2577 from each Z* (and/or Y) to X with no other multicast-aware routers in 2578 the path. If any Z* (and/or Y) is located on the same SPAN segment 2579 as X, the multicast data traffic sent to X directly using SPAN/INET 2580 encapsulation instead of via a Relay. 2582 Following the initial Join/Prune and NS/NA messaging, X maintains an 2583 asymmetric neighbor cache entry for each S the same as if X was 2584 sending unicast data traffic to S. In particular, X performs 2585 additional NS/NA exchanges to keep the neighbor cache entry alive for 2586 up to t_periodic seconds [RFC7761]. If no new Joins are received 2587 within t_periodic seconds, X allows the neighbor cache entry to 2588 expire. Finally, if X receives any additional Join/Prune messages 2589 for (S,G) it forwards the messages to each Y and Z* in the neighbor 2590 cache entry over the SPAN. 2592 At some later time, Client C that holds an MNP for source S may 2593 depart from a first Proxy Z1 and/or connect via a new Proxy Z2. In 2594 that case, Y sends an unsolicited NA message to X the same as 2595 specified for unicast mobility in Section 3.19. When X receives the 2596 unsolicited NA message, it updates its asymmetric neighbor cache 2597 entry for the AERO address for source S and sends new Join messages 2598 to any new Proxys Z2. There is no requirement to send any Prune 2599 messages to old Proxys Z1 since source S will no longer source any 2600 multicast data traffic via Z1. Instead, the multicast state for 2601 (S,G) in Proxy Z1 will soon time out since no new Joins will arrive. 2603 After some later time, C may move to a new Server Y2 and depart from 2604 old Sever Y1. In that case, Y1 sends Join messages for any of C's 2605 active (S,G) groups to Y2 while including its own AERO address as the 2606 source address. This causes Y2 to include Y1 in the multicast 2607 forwarding tree during the interim time that Y1's symmetric neighbor 2608 cache entry for C is in the DEPARTED state. At the same time, Y1 2609 sends an unsolicited NA message to X with an Interface ID 0xffff and 2610 R set to 1 to cause X to release its asymmetric neighbor cache entry. 2611 X then sends a new Join message to S via the SPAN and re-initiates 2612 route optimization the same as if it were receiving a fresh Join 2613 message from a node on a downstream link. 2615 3.20.2. Any-Source Multicast (ASM) 2617 When an ROS X acting as a PIM router receives a Join/Prune from a 2618 node on its downstream interfaces containing one or more (*,G) pairs, 2619 it updates its Multicast Routing Information Base (MRIB) accordingly. 2620 X then forwards a copy of the message to the Rendezvous Point (RP) R 2621 for each G over the SPAN. X uses its own AERO address as the source 2622 address and ALL-PIM-ROUTERS as the destination address, then 2623 encapsulates each message in a SPAN header with source address set to 2624 the SPAN address of X and destination address set to R, then sends 2625 the message into the SPAN. At the same time, if the message was a 2626 Join X initiates NS/NA route optimization the same as for the SSM 2627 case discussed in Section 3.20.1. 2629 For each source S that sends multicast traffic to group G via R, the 2630 Proxy/Server Z* for the Client that aggregates S encapsulates the 2631 packets in PIM Register messages and forwards them to R via the SPAN. 2632 R may then elect to send a PIM Join to Z* over the SPAN. This will 2633 result in an (S,G) tree rooted at Z* with R as the next hop so that R 2634 will begin to receive two copies of the packet; one native copy from 2635 the (S, G) tree and a second copy from the pre-existing (*, G) tree 2636 that still uses PIM Register encapsulation. R can then issue a PIM 2637 Register-stop message to suppress the Register-encapsulated stream. 2638 At some later time, if C moves to a new Proxy/Server Z*, it resumes 2639 sending packets via PIM Register encapsulation via the new Z*. 2641 At the same time, as multicast listeners discover individual S's for 2642 a given G, they can initiate an (S,G) Join for each S under the same 2643 procedures discussed in Section 3.20.1. Once the (S,G) tree is 2644 established, the listeners can send (S, G) Prune messages to R so 2645 that multicast packets for group G sourced by S will only be 2646 delivered via the (S, G) tree and not from the (*, G) tree rooted at 2647 R. All mobility considerations discussed for SSM apply. 2649 3.20.3. Bi-Directional PIM (BIDIR-PIM) 2651 Bi-Directional PIM (BIDIR-PIM) [RFC5015] provides an alternate 2652 approach to ASM that treats the Rendezvous Point (RP) as a Designated 2653 Forwarder (DF). Further considerations for BIDIR-PIM are out of 2654 scope. 2656 3.21. Operation over Multiple AERO Links (VLANs) 2658 An AERO Client can connect to multiple AERO links the same as for any 2659 data link service. In that case, the Client maintains a distinct 2660 AERO interface for each link, e.g., 'aero0' for the first link, 2661 'aero1' for the second, 'aero2' for the third, etc. Each AERO link 2662 would include its own distinct set of Relays, Servers and Proxys, 2663 thereby providing redundancy in case of failures. 2665 The Relays, Servers and Proxys on each AERO link can assign AERO and 2666 SPAN addresses that use the same or different numberings from those 2667 on other links. Since the links are mutually independent there is no 2668 requirement for avoiding inter-link address duplication, e.g., the 2669 same AERO address such as fe80::1000 could be used to number distinct 2670 nodes that connect to different links. 2672 Each AERO link could utilize the same or different ANET connections. 2673 The links can be distinguished at the link-layer via Virtual Local 2674 Area Network (VLAN) tagging (e.g., IEEE 802.1Q) and/or through 2675 assignment of distinct sets of MSPs on each link. This gives rise to 2676 the opportunity for supporting multiple redundant networked paths, 2677 where each VLAN is distinguished by a different label (e.g., colors 2678 such as Red, Green, Blue, etc.). In particular, the Client can tag 2679 its RS messages with the appropriate label to cause the network to 2680 select the desired VLAN. 2682 Clients that connect to multiple AERO interfaces can select the 2683 outgoing interface appropriate for a given Red/Blue/Green/etc. 2684 traffic profile while (in the reverse direction) correspondent nodes 2685 must have some way of steering their packets destined to a target via 2686 the correct AERO link. 2688 In a first alternative, if each AERO link services different MSPs, 2689 then the Client can receive a distinct MNP from each of the links. 2690 IP routing will therefore assure that the correct Red/Green/Blue/etc. 2691 network is used for both outbound and inbound traffic. This can be 2692 accomplished using existing technologies and approaches, and without 2693 requiring any special supporting code in correspondent nodes or 2694 Relays. 2696 In a second alternative, if each AERO link services the same MSP(s) 2697 then each link could assign a distinct "AERO Link Anycast" address 2698 that is configured by all Relays on the link. Correspondent nodes 2699 then include a "type 4" routing header with the Anycast address for 2700 the AERO link as the IPv6 destination and with the address of the 2701 target encoded as the "next segment" in the routing header 2702 [RFC8402][I-D.ietf-6man-segment-routing-header]. Standard IP routing 2703 will then direct the packet to the nearest Relay for the correct AERO 2704 link, which will replace the destination address with the target 2705 address then forward the packet to the target. 2707 3.22. DNS Considerations 2709 AERO Client MNs and INET correspondent nodes consult the Domain Name 2710 System (DNS) the same as for any Internetworking node. When 2711 correspondent nodes and Client MNs use different IP protocol versions 2712 (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain 2713 A records for IPv4 address mappings to MNs which must then be 2714 populated in Gateway NAT64 mapping caches. In that way, an IPv4 2715 correspondent node can send packets to the IPv4 address mapping of 2716 the target MN, and the Gateway will translate the IPv4 header and 2717 destination address into an IPv6 header and IPv6 destination address 2718 of the MN. 2720 When an AERO Client registers with an AERO Server, the Server returns 2721 the address(es) of DNS servers in RDNSS options [RFC6106]. The DNS 2722 server provides the IP addresses of other MNs and correspondent nodes 2723 in AAAA records for IPv6 or A records for IPv4. 2725 3.23. Transition Considerations 2727 The SPAN ensures that dissimilar INET partitions can be joined into a 2728 single unified AERO link, even though the partitions themselves may 2729 have differing protocol versions and/or incompatible addressing 2730 plans. However, a commonality can be achieved by incrementally 2731 distributing globally routable (i.e., native) IP prefixes to 2732 eventually reach all nodes (both mobile and fixed) in all SPAN 2733 segments. This can be accomplished by incrementally deploying AERO 2734 Gateways on each INET partition, with each Gateway distributing its 2735 MNPs and/or discovering non-MNP prefixes on its INET links. 2737 This gives rise to the opportunity to eventually distribute native IP 2738 addresses to all nodes, and to present a unified AERO link view 2739 (bridged by the SPAN) even if the INET partitions remain in their 2740 current protocol and addressing plans. In that way, the AERO link 2741 can serve the dual purpose of providing a mobility service and a 2742 transition service. Or, if an INET partition is transitioned to a 2743 native IP protocol version and addressing scheme that is compatible 2744 with the AERO link MNP-based addressing scheme, the partition and 2745 AERO link can be joined by Gateways. 2747 Gateways that connect INETs/EUNs with dissimilar IP protocol versions 2748 must employ a network address and protocol translation function such 2749 as NAT64[RFC6146]. 2751 4. Implementation Status 2753 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2754 announced on the v6ops mailing list on January 10, 2018 and an 2755 initial public release of the AERO proof-of-concept source code was 2756 announced on the intarea mailing list on August 21, 2015. The latest 2757 versions are available at: http://linkupnetworks.net/aero. 2759 5. IANA Considerations 2761 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2762 AERO in the "enterprise-numbers" registry. 2764 The IANA has assigned the UDP port number "8060" for an earlier 2765 experimental version of AERO [RFC6706]. This document obsoletes 2766 [RFC6706] and claims the UDP port number "8060" for all future use. 2768 No further IANA actions are required. 2770 6. Security Considerations 2772 AERO Relays configure secured tunnels with AERO Servers and Proxys 2773 within their local SPAN segments. Applicable secured tunnel 2774 alternatives include IPsec [RFC4301], TLS/SSL [RFC8446], DTLS 2775 [RFC6347], etc. The AERO Relays of all SPAN segments in turn 2776 configure secured tunnels for their neighboring AERO Relays across 2777 the SPAN. Therefore, packets that traverse the SPAN between any pair 2778 of AERO link neighbors are already secured. 2780 AERO Servers, Gateways and Proxys targeted by a route optimization 2781 may also receive packets directly from the INET partitions instead of 2782 via the SPAN. For INET partitions that apply effective ingress 2783 filtering to defeat source address spoofing, the simple data origin 2784 authentication procedures in Section 3.11 can be applied. This 2785 implies that the ROS list must be maintained consistently by all 2786 route optimization targets within the same INET partition, and that 2787 the ROS list must be securely managed by the partition's 2788 administrative authority. 2790 For INET partitions that cannot apply effective ingress filtering, 2791 the two options for securing communications include 1) disable route 2792 optimization so that all traffic is conveyed over secured tunnels via 2793 the SPAN, or 2) enable on-demand secure tunnel creation between INET 2794 partition neighbors. Option 1) would result in longer routes than 2795 necessary and traffic concentration on critical infrastructure 2796 elements. Option 2) could be coordinated by establishing a secured 2797 tunnel on-demand instead of performing an NS/NA exchange in the route 2798 optimization procedures. Procedures for establishing on-demand 2799 secured tunnels are out of scope. 2801 AERO Clients that connect to secured enclaves need not apply security 2802 to their ND messages, since the messages will be intercepted by a 2803 perimeter Proxy that applies security on its outward-facing 2804 interface. AERO Clients located outside of secured enclaves SHOULD 2805 use symmetric network and/or transport layer security services, but 2806 when there are many prospective neighbors with dynamically changing 2807 connectivity an asymmetric security service such as SEND may be 2808 needed (see: Appendix C.6). 2810 Application endpoints SHOULD use application-layer security services 2811 such as TLS/SSL, DTLS or SSH [RFC4251] to assure the same level of 2812 protection as for critical secured Internet services. AERO Clients 2813 that require host-based VPN services SHOULD use symmetric network 2814 and/or transport layer security services such as IPsec, TLS/SSL, 2815 DTLS, etc. AERO Proxys and Servers can also provide a network-based 2816 VPN service on behalf of the Client, e.g., if the Client is located 2817 within a secured enclave and cannot establish a VPN on its own 2818 behalf. 2820 AERO Servers and Relays present targets for traffic amplification 2821 Denial of Service (DoS) attacks. This concern is no different than 2822 for widely-deployed VPN security gateways in the Internet, where 2823 attackers could send spoofed packets to the gateways at high data 2824 rates. This can be mitigated by connecting Servers and Relays over 2825 dedicated links with no connections to the Internet and/or when 2826 connections to the Internet are only permitted through well-managed 2827 firewalls. Traffic amplification DoS attacks can also target an AERO 2828 Client's low data rate links. This is a concern not only for Clients 2829 located on the open Internet but also for Clients in secured 2830 enclaves. AERO Servers and Proxys can institute rate limits that 2831 protect Clients from receiving packet floods that could DoS low data 2832 rate links. 2834 AERO Gateways must implement ingress filtering to avoid a spoofing 2835 attack in which spurious SPAN messages are injected into an AERO link 2836 from an outside attacker. AERO Clients MUST ensure that their 2837 connectivity is not used by unauthorized nodes on their EUNs to gain 2838 access to a protected network, i.e., AERO Clients that act as routers 2839 MUST NOT provide routing services for unauthorized nodes. (This 2840 concern is no different than for ordinary hosts that receive an IP 2841 address delegation but then "share" the address with other nodes via 2842 some form of Internet connection sharing such as tethering.) 2844 The MAP list and ROS lists MUST be well-managed and secured from 2845 unauthorized tampering, even though the list contains only public 2846 information. The MAP list can be conveyed to the Client, e.g., 2847 through secure upload of a static file, through DNS lookups, etc. 2848 The ROS list can be conveyed to Servers and Proxys through 2849 administrative action, secured file distribution, etc. 2851 Although public domain and commercial SEND implementations exist, 2852 concerns regarding the strength of the cryptographic hash algorithm 2853 have been documented [RFC6273] [RFC4982]. 2855 Security considerations for accepting link-layer ICMP messages and 2856 reflected packets are discussed throughout the document. 2858 7. Acknowledgements 2860 Discussions in the IETF, aviation standards communities and private 2861 exchanges helped shape some of the concepts in this work. 2862 Individuals who contributed insights include Mikael Abrahamsson, Mark 2863 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2864 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2865 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2866 Hlusiak, Lee Howard, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy 2867 Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru 2868 Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, 2869 Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members 2870 of the IESG also provided valuable input during their review process 2871 that greatly improved the document. Special thanks go to Stewart 2872 Bryant, Joel Halpern and Brian Haberman for their shepherding 2873 guidance during the publication of the AERO first edition. 2875 This work has further been encouraged and supported by Boeing 2876 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2877 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2878 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2879 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Greg 2880 Saccone, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan 2881 Williams, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 2882 BR&T and BIT mobile networking teams. Kyle Bae, Wayne Benson and 2883 Eric Yeh are especially acknowledged for implementing the AERO 2884 functions as extensions to the public domain OpenVPN distribution. 2886 Earlier works on NBMA tunneling approaches are found in 2887 [RFC2529][RFC5214][RFC5569]. 2889 Many of the constructs presented in this second edition of AERO are 2890 based on the author's earlier works, including: 2892 o The Internet Routing Overlay Network (IRON) 2893 [RFC6179][I-D.templin-ironbis] 2895 o Virtual Enterprise Traversal (VET) 2896 [RFC5558][I-D.templin-intarea-vet] 2898 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2899 [RFC5320][I-D.templin-intarea-seal] 2901 o AERO, First Edition [RFC6706] 2903 Note that these works cite numerous earlier efforts that are not also 2904 cited here due to space limitations. The authors of those earlier 2905 works are acknowledged for their insights. 2907 This work is aligned with the NASA Safe Autonomous Systems Operation 2908 (SASO) program under NASA contract number NNA16BD84C. 2910 This work is aligned with the FAA as per the SE2025 contract number 2911 DTFAWA-15-D-00030. 2913 This work is aligned with the Boeing Information Technology (BIT) 2914 MobileNet program. 2916 This work is aligned with the Boeing autonomy program. 2918 8. References 2919 8.1. Normative References 2921 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2922 DOI 10.17487/RFC0791, September 1981, 2923 . 2925 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2926 RFC 792, DOI 10.17487/RFC0792, September 1981, 2927 . 2929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2930 Requirement Levels", BCP 14, RFC 2119, 2931 DOI 10.17487/RFC2119, March 1997, 2932 . 2934 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2935 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2936 December 1998, . 2938 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2939 "Definition of the Differentiated Services Field (DS 2940 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2941 DOI 10.17487/RFC2474, December 1998, 2942 . 2944 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2945 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2946 DOI 10.17487/RFC3971, March 2005, 2947 . 2949 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2950 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2951 . 2953 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2954 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2955 November 2005, . 2957 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2958 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2959 DOI 10.17487/RFC4861, September 2007, 2960 . 2962 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2963 Address Autoconfiguration", RFC 4862, 2964 DOI 10.17487/RFC4862, September 2007, 2965 . 2967 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2968 (IPv6) Specification", STD 86, RFC 8200, 2969 DOI 10.17487/RFC8200, July 2017, 2970 . 2972 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2973 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2974 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2975 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2976 . 2978 8.2. Informative References 2980 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2981 2016. 2983 [I-D.ietf-6man-segment-routing-header] 2984 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 2985 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 2986 Routing Header (SRH)", draft-ietf-6man-segment-routing- 2987 header-21 (work in progress), June 2019. 2989 [I-D.ietf-dmm-distributed-mobility-anchoring] 2990 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 2991 "Distributed Mobility Anchoring", draft-ietf-dmm- 2992 distributed-mobility-anchoring-13 (work in progress), 2993 March 2019. 2995 [I-D.ietf-intarea-gue] 2996 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2997 Encapsulation", draft-ietf-intarea-gue-07 (work in 2998 progress), March 2019. 3000 [I-D.ietf-intarea-gue-extensions] 3001 Herbert, T., Yong, L., and F. Templin, "Extensions for 3002 Generic UDP Encapsulation", draft-ietf-intarea-gue- 3003 extensions-06 (work in progress), March 2019. 3005 [I-D.ietf-intarea-tunnels] 3006 Touch, J. and M. Townsley, "IP Tunnels in the Internet 3007 Architecture", draft-ietf-intarea-tunnels-09 (work in 3008 progress), July 2018. 3010 [I-D.ietf-rtgwg-atn-bgp] 3011 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 3012 Moreno, "A Simple BGP-based Mobile Routing System for the 3013 Aeronautical Telecommunications Network", draft-ietf- 3014 rtgwg-atn-bgp-02 (work in progress), May 2019. 3016 [I-D.templin-6man-dhcpv6-ndopt] 3017 Templin, F., "A Unified Stateful/Stateless Configuration 3018 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-08 3019 (work in progress), June 2019. 3021 [I-D.templin-intarea-grefrag] 3022 Templin, F., "GRE Tunnel Level Fragmentation", draft- 3023 templin-intarea-grefrag-04 (work in progress), July 2016. 3025 [I-D.templin-intarea-seal] 3026 Templin, F., "The Subnetwork Encapsulation and Adaptation 3027 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 3028 progress), January 2014. 3030 [I-D.templin-intarea-vet] 3031 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 3032 templin-intarea-vet-40 (work in progress), May 2013. 3034 [I-D.templin-ironbis] 3035 Templin, F., "The Interior Routing Overlay Network 3036 (IRON)", draft-templin-ironbis-16 (work in progress), 3037 March 2014. 3039 [I-D.templin-v6ops-pdhost] 3040 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 3041 Models", draft-templin-v6ops-pdhost-24 (work in progress), 3042 June 2019. 3044 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 3046 [RFC1035] Mockapetris, P., "Domain names - implementation and 3047 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3048 November 1987, . 3050 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3051 Communication Layers", STD 3, RFC 1122, 3052 DOI 10.17487/RFC1122, October 1989, 3053 . 3055 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3056 DOI 10.17487/RFC1191, November 1990, 3057 . 3059 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 3060 RFC 1812, DOI 10.17487/RFC1812, June 1995, 3061 . 3063 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 3064 DOI 10.17487/RFC2003, October 1996, 3065 . 3067 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3068 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 3069 . 3071 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3072 Domains without Explicit Tunnels", RFC 2529, 3073 DOI 10.17487/RFC2529, March 1999, 3074 . 3076 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 3077 Malis, "A Framework for IP Based Virtual Private 3078 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 3079 . 3081 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 3082 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 3083 DOI 10.17487/RFC2784, March 2000, 3084 . 3086 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 3087 RFC 2890, DOI 10.17487/RFC2890, September 2000, 3088 . 3090 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 3091 RFC 2923, DOI 10.17487/RFC2923, September 2000, 3092 . 3094 [RFC2983] Black, D., "Differentiated Services and Tunnels", 3095 RFC 2983, DOI 10.17487/RFC2983, October 2000, 3096 . 3098 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3099 of Explicit Congestion Notification (ECN) to IP", 3100 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3101 . 3103 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 3104 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 3105 DOI 10.17487/RFC3810, June 2004, 3106 . 3108 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 3109 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 3110 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 3111 RFC 3819, DOI 10.17487/RFC3819, July 2004, 3112 . 3114 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 3115 for IPv6 Hosts and Routers", RFC 4213, 3116 DOI 10.17487/RFC4213, October 2005, 3117 . 3119 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 3120 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 3121 January 2006, . 3123 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 3124 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3125 DOI 10.17487/RFC4271, January 2006, 3126 . 3128 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3129 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3130 2006, . 3132 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3133 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3134 December 2005, . 3136 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 3137 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 3138 2006, . 3140 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3141 Control Message Protocol (ICMPv6) for the Internet 3142 Protocol Version 6 (IPv6) Specification", STD 89, 3143 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3144 . 3146 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3147 Protocol (LDAP): The Protocol", RFC 4511, 3148 DOI 10.17487/RFC4511, June 2006, 3149 . 3151 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 3152 "Considerations for Internet Group Management Protocol 3153 (IGMP) and Multicast Listener Discovery (MLD) Snooping 3154 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 3155 . 3157 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3158 "Internet Group Management Protocol (IGMP) / Multicast 3159 Listener Discovery (MLD)-Based Multicast Forwarding 3160 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 3161 August 2006, . 3163 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3164 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 3165 . 3167 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3168 Errors at High Data Rates", RFC 4963, 3169 DOI 10.17487/RFC4963, July 2007, 3170 . 3172 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 3173 Algorithms in Cryptographically Generated Addresses 3174 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 3175 . 3177 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 3178 "Bidirectional Protocol Independent Multicast (BIDIR- 3179 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 3180 . 3182 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3183 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3184 DOI 10.17487/RFC5214, March 2008, 3185 . 3187 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 3188 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 3189 February 2010, . 3191 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 3192 Route Optimization Requirements for Operational Use in 3193 Aeronautics and Space Exploration Mobile Networks", 3194 RFC 5522, DOI 10.17487/RFC5522, October 2009, 3195 . 3197 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 3198 RFC 5558, DOI 10.17487/RFC5558, February 2010, 3199 . 3201 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 3202 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 3203 January 2010, . 3205 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 3206 "IPv6 Router Advertisement Options for DNS Configuration", 3207 RFC 6106, DOI 10.17487/RFC6106, November 2010, 3208 . 3210 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3211 NAT64: Network Address and Protocol Translation from IPv6 3212 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3213 April 2011, . 3215 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 3216 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 3217 . 3219 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 3220 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 3221 DOI 10.17487/RFC6221, May 2011, 3222 . 3224 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 3225 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 3226 DOI 10.17487/RFC6273, June 2011, 3227 . 3229 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3230 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3231 January 2012, . 3233 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 3234 for Equal Cost Multipath Routing and Link Aggregation in 3235 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3236 . 3238 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3239 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3240 . 3242 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 3243 RFC 6864, DOI 10.17487/RFC6864, February 2013, 3244 . 3246 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 3247 Deployment Options and Experience", RFC 7269, 3248 DOI 10.17487/RFC7269, June 2014, 3249 . 3251 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 3252 Korhonen, "Requirements for Distributed Mobility 3253 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 3254 . 3256 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 3257 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 3258 Multicast - Sparse Mode (PIM-SM): Protocol Specification 3259 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 3260 2016, . 3262 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 3263 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 3264 March 2017, . 3266 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 3267 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 3268 DOI 10.17487/RFC8201, July 2017, 3269 . 3271 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 3272 Decraene, B., Litkowski, S., and R. Shakir, "Segment 3273 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 3274 July 2018, . 3276 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3277 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3278 . 3280 Appendix A. AERO Alternate Encapsulations 3282 When GUE encapsulation is not needed, AERO can use common 3283 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 3284 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 3285 encapsulation is therefore only differentiated from non-AERO tunnels 3286 through the application of AERO control messaging and not through, 3287 e.g., a well-known UDP port number. 3289 As for GUE encapsulation, alternate AERO encapsulation formats may 3290 require encapsulation layer fragmentation. For simple IP-in-IP 3291 encapsulation, an IPv6 fragment header is inserted directly between 3292 the inner and outer IP headers when needed, i.e., even if the outer 3293 header is IPv4. The IPv6 Fragment Header is identified to the outer 3294 IP layer by its IP protocol number, and the Next Header field in the 3295 IPv6 Fragment Header identifies the inner IP header version. For GRE 3296 encapsulation, a GRE fragment header is inserted within the GRE 3297 header [I-D.templin-intarea-grefrag]. 3299 Figure 6 shows the AERO IP-in-IP encapsulation format before any 3300 fragmentation is applied: 3302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3303 | Outer IPv4 Header | | Outer IPv6 Header | 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 | Inner IP Header | | Inner IP Header | 3308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3309 | | | | 3310 ~ ~ ~ ~ 3311 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 3312 ~ ~ ~ ~ 3313 | | | | 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 3318 Figure 6: Minimal Encapsulation Format using IP-in-IP 3320 Figure 7 shows the AERO GRE encapsulation format before any 3321 fragmentation is applied: 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3324 | Outer IP Header | 3325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3326 | GRE Header | 3327 | (with checksum, key, etc..) | 3328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3329 | GRE Fragment Header (optional)| 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | Inner IP Header | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | | 3334 ~ ~ 3335 ~ Inner Packet Body ~ 3336 ~ ~ 3337 | | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 Figure 7: Minimal Encapsulation Using GRE 3342 Alternate encapsulation may be preferred in environments where GUE 3343 encapsulation would add unnecessary overhead. For example, certain 3344 low-bandwidth wireless data links may benefit from a reduced 3345 encapsulation overhead. 3347 GUE encapsulation can traverse network paths that are inaccessible to 3348 non-UDP encapsulations, e.g., for crossing Network Address 3349 Translators (NATs). More and more, network middleboxes are also 3350 being configured to discard packets that include anything other than 3351 a well-known IP protocol such as UDP and TCP. It may therefore be 3352 necessary to determine the potential for middlebox filtering before 3353 enabling alternate encapsulation in a given environment. 3355 In addition to IP-in-IP, GRE and GUE, AERO can also use security 3356 encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO 3357 control messaging and route determination occur before security 3358 encapsulation is applied for outgoing packets and after security 3359 decapsulation is applied for incoming packets. 3361 AERO is especially well suited for use with VPN system encapsulations 3362 such as OpenVPN [OVPN]. 3364 Appendix B. S/TLLAO Extensions for Special-Purpose Links 3366 The AERO S/TLLAO format specified in Section 3.6 includes a Length 3367 value of 5 (i.e., 5 units of 8 octets). However, special-purpose 3368 links may extend the basic format to include additional fields and a 3369 Length value larger than 5. 3371 For example, adaptation of AERO to the Aeronautical 3372 Telecommunications Network with Internet Protocol Services (ATN/IPS) 3373 includes link selection preferences based on transport port numbers 3374 in addition to the existing DSCP-based preferences. ATN/IPS nodes 3375 maintain a map of transport port numbers to 64 possible preference 3376 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 3377 maps to preference field 20, UDP port 8060 maps to preference field 3378 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 3379 Figure 8, where the Length value is 7 and the 'Q(i)' fields provide 3380 link preferences for the corresponding transport port number. 3382 0 1 2 3 3383 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 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | Type | Length = 7 | Prefix Length | Reserved | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | Interface ID | Port Number | 3388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3389 | | 3390 + + 3391 | | 3392 + Link-Layer Address + 3393 | | 3394 + + 3395 | | 3396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3399 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3401 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 3402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 3404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3405 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 3406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3407 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 Figure 8: ATN/IPS Extended S/TLLAO Format 3416 Appendix C. Non-Normative Considerations 3418 AERO can be applied to a multitude of Internetworking scenarios, with 3419 each having its own adapations. The following considerations are 3420 provided as non-normative guidance: 3422 C.1. Implementation Strategies for Route Optimization 3424 Route optimization as discussed in Section 3.17 results in the route 3425 optimization source (ROS) creating an asymmetric neighbor cache entry 3426 for the target neighbor. The neighbor cache entry is maintained for 3427 at most REACHABLE_TIME seconds and then deleted unless updated. In 3428 order to refresh the neighbor cache entry lifetime before the 3429 ReachableTime timer expires, the specification requires 3430 implementations to issue a new NS/NA exchange to reset ReachableTime 3431 to REACHABLE_TIME seconds while data packets are still flowing. 3432 However, the decision of when to initiate a new NS/NA exchange and to 3433 perpetuate the process is left as an implementation detail. 3435 One possible strategy may be to monitor the neighbor cache entry 3436 watching for data packets for (REACHABLE_TIME - 5) seconds. If any 3437 data packets have been sent to the neighbor within this timeframe, 3438 then send an NS to receive a new NA. If no data packets have been 3439 sent, wait for 5 additional seconds and send an immediate NS if any 3440 data packets are sent within this "expiration pending" 5 second 3441 window. If no additional data packets are sent within the 5 second 3442 window, delete the neighbor cache entry. 3444 The monitoring of the neighbor data packet traffic therefore becomes 3445 an asymmetric ongoing process during the neighbor cache entry 3446 lifetime. If the neighbor cache entry expires, future data packets 3447 will trigger a new NS/NA exchange while the packets themselves are 3448 delivered over a longer path until route optimization state is re- 3449 established. 3451 C.2. Implicit Mobility Management 3453 AERO interface neighbors MAY provide a configuration option that 3454 allows them to perform implicit mobility management in which no ND 3455 messaging is used. In that case, the Client only transmits packets 3456 over a single interface at a time, and the neighbor always observes 3457 packets arriving from the Client from the same link-layer source 3458 address. 3460 If the Client's ANET interface address changes (either due to a 3461 readdressing of the original interface or switching to a new 3462 interface) the neighbor immediately updates the neighbor cache entry 3463 for the Client and begins accepting and sending packets according to 3464 the Client's new ANET address. This implicit mobility method applies 3465 to use cases such as cellphones with both WiFi and Cellular 3466 interfaces where only one of the interfaces is active at a given 3467 time, and the Client automatically switches over to the backup 3468 interface if the primary interface fails. 3470 C.3. Direct Underlying Interfaces 3472 When a Client's AERO interface is configured over a Direct interface, 3473 the neighbor at the other end of the Direct link can receive packets 3474 without any encapsulation. In that case, the Client sends packets 3475 over the Direct link according to QoS preferences. If the Direct 3476 interface has the highest QoS preference, then the Client's IP 3477 packets are transmitted directly to the peer without going through an 3478 ANET/INET. If other interfaces have higher QoS preferences, then the 3479 Client's IP packets are transmitted via a different interface, which 3480 may result in the inclusion of Proxys, Servers and Relays in the 3481 communications path. Direct interfaces must be tested periodically 3482 for reachability, e.g., via NUD. 3484 C.4. AERO Clients on the Open Internetwork 3486 AERO Clients that connect to the open Internetwork via either a 3487 native or NATed interface can establish a VPN to securely connect to 3488 a Server. Alternatively, the Client can exchange ND messages 3489 directly with other AERO nodes on the same SPAN segment using INET 3490 encapsulation only and without joining the SPAN. In that case, 3491 however, the Client must apply asymmetric security for ND messages to 3492 ensure routing and neighbor cache integrity (see: Section 6). 3494 C.5. Operation on AERO Links with /64 ASPs 3496 IPv6 AERO links typically have MSPs that aggregate many candidate 3497 MNPs of length /64 or shorter. However, in some cases it may be 3498 desirable to use AERO over links that have only a /64 MSP. This can 3499 be accommodated by treating all Clients on the AERO link as simple 3500 hosts that receive /128 prefix delegations. 3502 In that case, the Client sends an RS message to the Server the same 3503 as for ordinary AERO links. The Server responds with an RA message 3504 that includes one or more /128 prefixes (i.e., singleton addresses) 3505 that include the /64 MSP prefix along with an interface identifier 3506 portion to be assigned to the Client. The Client and Server then 3507 configure their AERO addresses based on the interface identifier 3508 portions of the /128s (i.e., the lower 64 bits) and not based on the 3509 /64 prefix (i.e., the upper 64 bits). 3511 For example, if the MSP for the host-only IPv6 AERO link is 3512 2001:db8:1000:2000::/64, each Client will receive one or more /128 3513 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 3514 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 3515 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 3516 the AERO interface, and assigns the global IPv6 addresses (i.e., the 3517 /128s) to either the AERO interface or an internal virtual interface 3518 such as a loopback. In this arrangement, the Client conducts route 3519 optimization in the same sense as discussed in Section 3.17. 3521 This specification has applicability for nodes that act as a Client 3522 on an "upstream" AERO link, but also act as a Server on "downstream" 3523 AERO links. More specifically, if the node acts as a Client to 3524 receive a /64 prefix from the upstream AERO link it can then act as a 3525 Server to provision /128s to Clients on downstream AERO links. 3527 C.6. AERO Adaptations for SEcure Neighbor Discovery (SEND) 3529 SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically 3530 Generated Addresses (CGAs) [RFC3972] were designed to secure IPv6 ND 3531 messaging in environments where symmetric network and/or transport- 3532 layer security services are impractical (see: Section 6). AERO nodes 3533 that use SEND/CGA employ the following adaptations. 3535 When a source AERO node prepares a SEND-protected ND message, it uses 3536 a link-local CGA as the IPv6 source address and writes the prefix 3537 embedded in its AERO address (i.e., instead of fe80::/64) in the CGA 3538 parameters Subnet Prefix field. When the neighbor receives the ND 3539 message, it first verifies the message checksum and SEND/CGA 3540 parameters while using the link-local prefix fe80::/64 (i.e., instead 3541 of the value in the Subnet Prefix field) to match against the IPv6 3542 source address of the ND message. 3544 The neighbor then derives the AERO address of the source by using the 3545 value in the Subnet Prefix field as the interface identifier of an 3546 AERO address. For example, if the Subnet Prefix field contains 3547 2001:db8:1:2, the neighbor constructs the AERO address as 3548 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 3549 neighbor cache entry it creates for the source, and uses the AERO 3550 address as the IPv6 destination address of any ND message replies. 3552 C.7. AERO Critical Infrastructure Considerations 3554 AERO Relays can be either Commercial off-the Shelf (COTS) standard IP 3555 routers or virtual machines in the cloud. Relays must be 3556 provisioned, supported and managed by the INET administrative 3557 authority, and connected to the Relays of other INETs via inter- 3558 domain peerings. Cost for purchasing, configuring and managing 3559 Relays is nominal even for very large AERO links. 3561 AERO Servers can be standard dedicated server platforms, but most 3562 often will be deployed as virtual machines in the cloud. The only 3563 requirements for Servers are that they can run the AERO user-level 3564 code and have at least one network interface connection to the INET. 3565 As with Relays, Servers must be provisioned, supported and managed by 3566 the INET administrative authority. Cost for purchasing, configuring 3567 and managing Servers is nominal especially for virtual Servers hosted 3568 in the cloud. 3570 AERO Proxys are most often standard dedicated server platforms with 3571 one network interface connected to the ANET and a second interface 3572 connected to an INET. As with Servers, the only requirements are 3573 that they can run the AERO user-level code and have at least one 3574 interface connection to the INET. Proxys must be provisioned, 3575 supported and managed by the ANET administrative authority. Cost for 3576 purchasing, configuring and managing Proxys is nominal, and borne by 3577 the ANET administrative authority. 3579 AERO Gateways can be any dedicated server or COTS router platform 3580 connected to INETs and/or EUNs. The Gateway joins the SPAN and 3581 engages in eBGP peering with one or more Relays as a stub AS. The 3582 Gateway then injects its MNPs and/or non-MNP prefixes into the BGP 3583 routing system, and provisions the prefixes to its downstream- 3584 attached networks. The Gateway can perform ROS and MAP services the 3585 same as for any Server, and can route between the MNP and non-MNP 3586 address spaces. 3588 Appendix D. Change Log 3590 << RFC Editor - remove prior to publication >> 3592 Changes from draft-templin-intarea-6706bis-14 to draft-templin- 3593 intrea-6706bis-15: 3595 o MTU and fragmentation 3597 o New details in movement to new Server 3599 Changes from draft-templin-intarea-6706bis-13 to draft-templin- 3600 intrea-6706bis-14: 3602 o Security based on secured tunnels, ingress filtering, MAP list and 3603 ROS list 3605 Changes from draft-templin-intarea-6706bis-12 to draft-templin- 3606 intrea-6706bis-13: 3608 o New paragraph in Section 3.6 on AERO interface layering over 3609 secured tunnels 3611 o Removed extraneous text in Section 3.7 3613 o Added new detail to the forwarding algorithm in Section 3.9 3615 o Clarified use of fragmentation 3617 o Route optimization now supported for both MNP and non-MNP-based 3618 prefixes 3620 o Relays are now seen as link-layer elements in the architecture. 3622 o Built out multicast section in detail. 3624 o New Appendix on implementation considerations for route 3625 optimization. 3627 Changes from draft-templin-intarea-6706bis-11 to draft-templin- 3628 intrea-6706bis-12: 3630 o Introduced Gateways as a new AERO element for connecting 3631 Correspondent Nodes on INET links 3633 o Introduced terms "Access Network (ANET)" and "Internetwork (INET)" 3635 o Changed "ASP" to "MSP", and "ACP" to "MNP" 3637 o New figure on the relation of Segments to the SPAN and AERO link 3639 o New "S" bit in S/TLLAO to indicate the "Source" S/TLLAO as opposed 3640 to additional S/TLLAOs 3642 o Changed Interface ID for Servers from 255 to 0xffff 3644 o Significant updates to Route Optimization, NUD, and Mobility 3645 Management 3647 o New Section on Multicast 3649 o New Section on AERO Clients in the open Internetwork 3651 o New Section on Operation over multiple AERO links (VLANs over the 3652 SPAN) 3654 o New Sections on DNS considerations and Transition considerations 3656 o 3658 Changes from draft-templin-intarea-6706bis-10 to draft-templin- 3659 intrea-6706bis-11: 3661 o Added The SPAN 3663 Changes from draft-templin-intarea-6706bis-09 to draft-templin- 3664 intrea-6706bis-10: 3666 o Orphaned packets in flight (e.g., when a neighbor cache entry is 3667 in the DEPARTED state) are now forwarded at the link layer instead 3668 of at the network layer. Forwarding at the network layer can 3669 result in routing loops and/or excessive delays of forwarded 3670 packets while the routing system is still reconverging. 3672 o Update route optimization to clarify the unsecured nature of the 3673 first NS used for route discovery 3675 o Many cleanups and clarifications on ND messaging parameters 3677 Changes from draft-templin-intarea-6706bis-08 to draft-templin- 3678 intrea-6706bis-09: 3680 o Changed PRL to "MAP list" 3682 o For neighbor cache entries, changed "static" to "symmetric", and 3683 "dynamic" to "asymmetric" 3685 o Specified Proxy RS/RA exchanges with Servers on behalf of Clients 3687 o Added discussion of unsolicited NAs in Section 3.16, and included 3688 forward reference to Section 3.18 3690 o Added discussion of AERO Clients used as critical infrastructure 3691 elements to connect fixed networks. 3693 o Added network-based VPN under security considerations 3695 Changes from draft-templin-intarea-6706bis-07 to draft-templin- 3696 intrea-6706bis-08: 3698 o New section on AERO-Aware Access Router 3700 Changes from draft-templin-intarea-6706bis-06 to draft-templin- 3701 intrea-6706bis-07: 3703 o Added "R" bit for release of PDs. Now have a full RS/RA service 3704 that can do PD without requiring DHCPv6 messaging over-the-air 3706 o Clarifications on solicited vs unsolicited NAs 3708 o Clarified use of MAX_NEIGHBOR_ADVERTISEMENTS for the purpose of 3709 increase reliability 3711 Changes from draft-templin-intarea-6706bis-05 to draft-templin- 3712 intrea-6706bis-06: 3714 o Major re-work and simplification of Route Optimization function 3716 o Added Distributed Mobility Management (DMM) and Mobility Anchor 3717 Point (MAP) terminology 3719 o New section on "AERO Critical Infrastructure Element 3720 Considerations" demonstrating low overall cost for the service 3722 o minor text revisions and deletions 3724 o removed extraneous appendices 3726 Changes from draft-templin-intarea-6706bis-04 to draft-templin- 3727 intrea-6706bis-05: 3729 o New Appendix E on S/TLLAO Extensions for special-purpose links. 3730 Discussed ATN/IPS as example. 3732 o New sentence in introduction to declare appendices as non- 3733 normative. 3735 Changes from draft-templin-intarea-6706bis-03 to draft-templin- 3736 intrea-6706bis-04: 3738 o Added definitions for Potential Router List (PRL) and secure 3739 enclave 3741 o Included text on mapping transport layer port numbers to network 3742 layer DSCP values 3744 o Added reference to DTLS and DMM Distributed Mobility Anchoring 3745 working group document 3747 o Reworked Security Considerations 3749 o Updated references. 3751 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 3752 intrea-6706bis-03: 3754 o Added new section on SEND. 3756 o Clarifications on "AERO Address" section. 3758 o Updated references and added new reference for RFC8086. 3760 o Security considerations updates. 3762 o General text clarifications and cleanup. 3764 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 3765 intrea-6706bis-02: 3767 o Note on encapsulation avoidance in Section 4. 3769 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 3770 intrea-6706bis-01: 3772 o Remove DHCPv6 Server Release procedures that leveraged the old way 3773 Relays used to "route" between Server link-local addresses 3775 o Remove all text relating to Relays needing to do any AERO-specific 3776 operations 3778 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 3779 as source addresses, and destination address of RA reply is to the 3780 AERO address corresponding to the Client's ACP. 3782 o Proxy uses SEND to protect RS and authenticate RA (Client does not 3783 use SEND, but rather relies on subnetwork security. When the 3784 Proxy receives an RS from the Client, it creates a new RS using 3785 its own addresses as the source and uses SEND with CGAs to send a 3786 new RS to the Server. 3788 o Emphasize distributed mobility management 3790 o AERO address-based RS injection of ACP into underlying routing 3791 system. 3793 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 3794 6706bis-00: 3796 o Document use of NUD (NS/NA) for reliable link-layer address 3797 updates as an alternative to unreliable unsolicited NA. 3798 Consistent with Section 7.2.6 of RFC4861. 3800 o Server adds additional layer of encapsulation between outer and 3801 inner headers of NS/NA messages for transmission through Relays 3802 that act as vanilla IPv6 routers. The messages include the AERO 3803 Server Subnet Router Anycast address as the source and the Subnet 3804 Router Anycast address corresponding to the Client's ACP as the 3805 destination. 3807 o Clients use Subnet Router Anycast address as the encapsulation 3808 source address when the access network does not provide a 3809 topologically-fixed address. 3811 Author's Address 3813 Fred L. Templin (editor) 3814 Boeing Research & Technology 3815 P.O. Box 3707 3816 Seattle, WA 98124 3817 USA 3819 Email: fltemplin@acm.org