idnits 2.17.1 draft-templin-intarea-6706bis-12.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 (May 1, 2019) is 1821 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: 'RFC4607' is defined on line 3122, but no explicit reference was found in the text == Unused Reference: 'RFC7269' is defined on line 3195, but no explicit reference was found in the text == 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-01 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-07 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-23 -- 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 (~~), 10 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, May 1, 2019 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: November 2, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-12.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 to manage the routing system. 20 Dynamic multilink operation, mobility management, quality of service 21 (QoS) signaling and route optimization are naturally supported 22 through dynamic neighbor cache updates. Standard IP multicasting 23 services are also supported. AERO is a widely-applicable tunneling 24 solution especially well-suited to aviation services, mobile Virtual 25 Private Networks (VPNs) and many other applications. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 2, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 10 64 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 10 65 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 11 66 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 13 67 3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 15 68 3.5. Spanning Partitioned AERO Networks (SPAN) . . . . . . . . 16 69 3.6. AERO Interface Characteristics . . . . . . . . . . . . . 20 70 3.7. AERO Interface Initialization . . . . . . . . . . . . . . 24 71 3.7.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 24 72 3.7.2. AERO Server Behavior . . . . . . . . . . . . . . . . 24 73 3.7.3. AERO Gateway Behavior . . . . . . . . . . . . . . . . 25 74 3.7.4. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 25 75 3.7.5. AERO Client Behavior . . . . . . . . . . . . . . . . 25 76 3.8. AERO Interface Neighbor Cache Maintenance . . . . . . . . 26 77 3.9. AERO Interface Forwarding Algorithm . . . . . . . . . . . 28 78 3.9.1. Client Forwarding Algorithm . . . . . . . . . . . . . 29 79 3.9.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 29 80 3.9.3. Server Forwarding Algorithm . . . . . . . . . . . . . 30 81 3.9.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 31 82 3.9.5. Relay Forwarding Algorithm . . . . . . . . . . . . . 31 83 3.10. AERO Interface Encapsulation and Re-encapsulation . . . . 31 84 3.11. AERO Interface Decapsulation . . . . . . . . . . . . . . 32 85 3.12. AERO Interface Data Origin Authentication . . . . . . . . 32 86 3.13. AERO Interface Packet Size Issues . . . . . . . . . . . . 33 87 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 35 88 3.15. AERO Router Discovery, Prefix Delegation and 89 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 38 90 3.15.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 38 91 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 39 92 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 41 93 3.16. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . 43 94 3.17. AERO Route Optimization . . . . . . . . . . . . . . . . . 45 95 3.17.1. Route Optimization Initiation . . . . . . . . . . . 46 96 3.17.2. Relaying the NS . . . . . . . . . . . . . . . . . . 46 97 3.17.3. Processing the NS and Sending the NA . . . . . . . . 46 98 3.17.4. Relaying the NA . . . . . . . . . . . . . . . . . . 47 99 3.17.5. Processing the NA . . . . . . . . . . . . . . . . . 47 100 3.17.6. Route Optimization Maintenance . . . . . . . . . . . 47 101 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 48 102 3.19. Mobility Management and Quality of Service (QoS) . . . . 49 103 3.19.1. Mobility Update Messaging . . . . . . . . . . . . . 50 104 3.19.2. Forwarding Packets on Behalf of Departed Clients . . 50 105 3.19.3. Announcing Link-Layer Address and/or QoS Preference 106 Changes . . . . . . . . . . . . . . . . . . . . . . 51 107 3.19.4. Bringing New Links Into Service . . . . . . . . . . 51 108 3.19.5. Removing Existing Links from Service . . . . . . . . 51 109 3.19.6. Implicit Mobility Management . . . . . . . . . . . . 52 110 3.19.7. Moving to a New Server . . . . . . . . . . . . . . . 52 111 3.20. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 53 112 4. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 54 113 5. AERO Clients on the Open Internetwork . . . . . . . . . . . . 54 114 6. Operation over Multiple AERO Links . . . . . . . . . . . . . 54 115 7. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 55 116 8. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 56 117 9. AERO Critical Infrastructure Considerations . . . . . . . . . 56 118 10. DNS Considerations . . . . . . . . . . . . . . . . . . . . . 57 119 11. Transition Considerations . . . . . . . . . . . . . . . . . . 57 120 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 58 121 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 122 14. Security Considerations . . . . . . . . . . . . . . . . . . . 58 123 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 124 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 125 16.1. Normative References . . . . . . . . . . . . . . . . . . 61 126 16.2. Informative References . . . . . . . . . . . . . . . . . 62 127 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 69 128 Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 70 129 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 72 130 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 76 132 1. Introduction 134 Asymmetric Extended Route Optimization (AERO) fulfills the 135 requirements of Distributed Mobility Management (DMM) [RFC7333] and 136 route optimization [RFC5522] for aeronautical networking and other 137 network mobility use cases. AERO is based on a Non-Broadcast, 138 Multiple Access (NBMA) virtual link model known as the AERO link. 139 The AERO link is configured over one or more underlying 140 Internetworks, and nodes on the link can exchange IP packets via 141 tunneling. 143 AERO links provide a cloud-based service where mobile nodes may use 144 any Mobility Anchor Point (MAP) and fixed nodes may use any Gateway 145 on the link for efficient communications. Fixed nodes forward 146 packets destined to other AERO nodes to the nearest Gateway, which 147 forwards them through the cloud. A mobile node's initial packets are 148 forwarded through the MAP, while direct routing is supported through 149 route optimization once an initial session has been established. 150 Both unicast and multicast communications are supported, and mobile 151 nodes may efficiently move between locations while maintaining 152 continuous communications with correspondents and without changing 153 their IP Address. 155 The AERO service comprises Clients, Proxies, Servers, and Gateways 156 that are seen as AERO link neighbors. Each node's AERO interface 157 uses an IPv6 link-local address format (known as the AERO address) 158 that supports operation of the IPv6 Neighbor Discovery (ND) [RFC4861] 159 protocol and links ND to IP forwarding. A node's AERO interface can 160 be configured over multiple underlying interfaces, and may therefore 161 may appear as a single interface with multiple link-layer addresses. 162 Each link-layer address is subject to change due to mobility and/or 163 QoS fluctuations, and link-layer address changes are signaled by ND 164 messaging the same as for any IPv6 link. 166 AERO Relays are interconnected in a secured private BGP overlay 167 routing instance known as the "SPAN". The SPAN provides a (virtual) 168 layer 2 bridging service to join the underlying Internetworks of 169 multiple disjoint administrative domains into a single unified AERO 170 link. Each AERO link instance is characterized by the set of 171 Mobility Service Prefixes (MSPs) common to all mobile nodes. The 172 link should extend to the point where a Gateway/MAP is on the optimal 173 route from any correspondent node on the link, and provides a gateway 174 between the underlying Internetwork and the SPAN. To the underlying 175 Internetwork, the Gateway/MAP is the source of a route to its MSP, 176 and hence uplink traffic to the mobile node is naturally routed to 177 the nearest Gateway/MAP. 179 AERO assumes the use of PIM Sparse Mode in support of multicast 180 communication. In support of Source Specific Multicast (SSM) when a 181 Mobile Node is the source, the AERO cloud is included within the 182 multicast distribution tree unless and until it is optimized out by 183 use of AERO Direct Routing. In all other multicast scenarios there 184 are no AERO dependencies. 186 AERO is applicable to a wide variety of use cases. For example, it 187 can be used to coordinate the Virtual Private Network (VPN) links of 188 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 189 connect into a home enterprise network via public access networks 190 using services such as OpenVPN [OVPN]. AERO is also applicable to 191 aeronautical networking for both manned and unmanned aircraft where 192 the aircraft is treated as a mobile node that can connect an Internet 193 of Things (IoT). Other applicable use cases are also in scope. 195 The following numbered sections present the AERO specification. The 196 appendices at the end of the document are non-normative. 198 2. Terminology 200 The terminology in the normative references applies; the following 201 terms are defined within the scope of this document: 203 IPv6 Neighbor Discovery (ND) 204 an IPv6 control message service for coordinating neighbor 205 relationships between nodes connected to a common link. AERO 206 interfaces use the ND service specified in [RFC4861]. 208 IPv6 Prefix Delegation (PD) 209 a networking service for delegating IPv6 prefixes to nodes on the 210 link. The nominal PD service is DHCPv6 [RFC8415], however 211 alternate services (e.g., based on ND messaging) are also in scope 212 [I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt]. Most 213 notably, a form of PD known as "Prefix Assertion" can be used if 214 the prefix can be represented in the IPv6 source address of an ND 215 message. 217 access network (ANET) 218 a node's first-hop data link service network, e.g., a radio access 219 network, cellular service provider network, corporate enterprise 220 network, or the public Internet itself. For secured ANETs, link- 221 layer security services such as IEEE 802.1X and physical-layer 222 security prevent unauthorized access internally while border 223 network-layer security services such as firewalls and proxies 224 prevent unauthorized outside access. When there is no 225 administrative boundary established between an ANET and the 226 outside Internetwork, the ANET and Internetwork are one and the 227 same. 229 ANET interface 230 a node's attachment to a link in an ANET. 232 ANET address 233 an IP address assigned to a node's interface connection to an 234 ANET. 236 Internetwork (INET) 237 a connected IP network topology with a coherent routing and 238 addressing plan and that provides an Internetworking backbone 239 service for ANETs. INETs also provide an underlay service over 240 which the AERO virtual link is configured. Example INETs include 241 corporate enterprise networks, aviation networks, and the public 242 Internet itself. 244 INET interface 245 a node's attachment to a link in an INET. 247 INET address 248 an IP address assigned to a node's interface connection to an 249 INET. 251 AERO link 252 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 253 configured over one or more underlying INETs. Nodes on the AERO 254 link appear as single-hop neighbors from the perspective of the 255 virtual overlay even though they may be separated by many 256 underlying INET hops. 258 AERO interface 259 a node's attachment to an AERO link. Since the addresses assigned 260 to an AERO interface are managed for uniqueness, AERO interfaces 261 do not require Duplicate Address Detection (DAD) and therefore set 262 the administrative variable 'DupAddrDetectTransmits' to zero 263 [RFC4862]. 265 AERO address 266 an IPv6 link-local address assigned to an AERO interface and 267 constructed as specified in Section 3.4. 269 base AERO address 270 the lowest-numbered AERO address aggregated by the MNP (see 271 Section 3.4). 273 Mobility Service Prefix (MSP) 274 an IP prefix assigned to the AERO link and from which more- 275 specific Mobile Network Prefixes (MNPs) are derived. 277 Mobile Network Prefix (MNP) 278 an IP prefix derived from an MSP and delegated to an AERO Client 279 or Gateway. 281 Fixed Node (FN) 282 a node on an INET link serviced by an AERO Gateway. 284 Mobile Node (MN) 285 an AERO Client and all of its downstream-attached networks. 287 Mobile Router (MR) 288 a MN's on-board router that forwards packets between any 289 downstream-attached networks and the AERO link. 291 Correspondent Node (CN) 292 a MN or FN that is reachable over the AERO link 294 AERO node 295 a node that is connected to an AERO link. 297 AERO Client ("Client") 298 an AERO node that connects to one or more ANETs and requests MNP 299 PDs from one or more AERO Servers. Following PD, the Client 300 assigns a Client AERO address to the AERO interface for use in ND 301 exchanges with other AERO nodes. A Client can also be deployed on 302 the same platform as a Server, and a node that acts as a Client on 303 one AERO interface can also act as an AERO Server on a different 304 AERO interface. 306 AERO Server ("Server") 307 an INET node that configures an AERO interface to provide default 308 forwarding services and a Mobility Anchor Point (MAP) for AERO 309 Clients. The Server assigns an administratively-provisioned AERO 310 address to the AERO interface to support the operation of the ND/ 311 PD services, and advertises all of its associated MNPs via BGP 312 peerings with Relays. 314 AERO Gateway ("Gateway") 315 a combined AERO Server/Client that also provides forwarding 316 services between CNs on the AERO link and FNs on INET links. AERO 317 Gateways are provisioned with MNPs used for numbering nodes and 318 networks on downstream-attached INET interfaces (i.e., the same as 319 for an AERO Client) and run a dynamic routing protocol to discover 320 any native INET prefixes. In both cases, the Gateway advertises 321 the MSP(s) to FNs in downstream-attached INET networks, and 322 distributes all of its associated MNPs and native INET prefixes 323 via BGP peerings with Relays (i.e., the same as for an AERO 324 Server). 326 AERO Relay ("Relay") 327 an INET node that provides both layer-3 routing and layer-2 328 bridging services (as well as a security trust anchor) for nodes 329 on an AERO link. As a router, the Relay forwards data packets 330 using standard IP forwarding. As a bridge, the Relay securely 331 forwards control messages between other AERO nodes. AERO Relays 332 peer with Servers and other Relays to discover the full set of 333 MNPs 335 AERO Proxy ("Proxy") 336 a node that provides proxying services between Clients in an ANET 337 and Servers in external INETs. The AERO Proxy is a conduit 338 between the ANET and external INETs in the same manner as for 339 common web proxies, and behaves in a similar fashion as for ND 340 proxies [RFC4389]. 342 Spanning Partitioned AERO Networks (SPAN) 343 a means for bridging disjoint INETs as segments (or, partitions) 344 of a unified AERO link, i.e., the same as for a bridged campus 345 LAN. The SPAN is a mid-layer encapsulation service in the AERO 346 routing system that supports a unified AERO link view for all 347 segments. Each segment in the SPAN is a distinct INET. 349 SPAN Service Prefix (SSP) 350 a global or unique local /96 IPv6 prefix assigned to the AERO link 351 to support SPAN services. 353 SPAN Partition Prefix (SPP) 354 a sub-prefix of the SPAN Service Prefix uniquely assigned to a 355 single AERO link segment. 357 SPAN Address 358 a global or unique local IPv6 address taken from a SPAN Partition 359 Prefix. 361 ingress tunnel endpoint (ITE) 362 an AERO interface endpoint that injects encapsulated packets into 363 an AERO link. 365 egress tunnel endpoint (ETE) 366 an AERO interface endpoint that receives encapsulated packets from 367 an AERO link. 369 link-layer address 370 an IP address used as an encapsulation header source or 371 destination address from the perspective of the AERO interface. 372 When UDP encapsulation is used, the UDP port number is also 373 considered as part of the link-layer address. From the 374 perspective of the AERO interface, the link-layer address is 375 either an INET address for intra-segment encapsulation or a SPAN 376 address for inter-segment encapsulation. 378 network layer address 379 the source or destination address of an encapsulated IP packet 380 presented to the AERO interface. 382 end user network (EUN) 383 an internal virtual or external edge IP network that an AERO 384 Client or Gateway connects to the rest of the network via the AERO 385 interface. The Client/Gateway sees each EUN as a "downstream" 386 network, and sees the AERO interface as the point of attachment to 387 the "upstream" network. 389 Mobility Anchor Point (MAP) 390 an AERO Server that is currently tracking and reporting the 391 mobility events of its associated Clients. 393 Mobile Router (MR) 394 a router on an AERO Client that provides routing services between 395 the Client's EUNs and the AERO interface. 397 MAP List 398 a geographically and/or topologically referenced list of IP 399 addresses of Servers for the AERO link. 401 Distributed Mobility Management (DMM) 402 a BGP-based overlay routing service coordinated by Servers and 403 Relays that tracks all MAP-to-Client associations. 405 Route Optimization Source (ROS) 406 the AERO node nearest the source Client that initiates route 407 optimization. The ROS may be one of the Client's Servers, Proxies 408 or in some cases even the Client itself. 410 Route Optimization Responder (ROR) 411 a Server of the target Client to which a route optimization 412 request is directed. The ROR (acting as a MAP) returns the most 413 current information about the target Client's underlying interface 414 connections. 416 Throughout the document, the simple terms "Client", "Server", 417 "Relay", "Proxy" and "Gateway" refer to "AERO Client", "AERO Server", 418 "AERO Relay", "AERO Proxy" and "AERO Gateway", respectively. 419 Capitalization is used to distinguish these terms from DHCPv6 420 client/server/relay [RFC8415]. 422 The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including 423 the names of node variables, messages and protocol constants) is used 424 throughout this document. Also, the term "IP" is used to generically 425 refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or 426 IPv6 [RFC8200]. 428 The terms Mobility Anchor Point (MAP), Mobile Router (MR) and 429 Distributed Mobility Management (DMM) are used in the same sense as 430 standard Internetworking terminology. 432 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 433 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 434 document are to be interpreted as described in [RFC2119]. Lower case 435 uses of these words are not to be interpreted as carrying RFC2119 436 significance. 438 3. Asymmetric Extended Route Optimization (AERO) 440 The following sections specify the operation of IP over Asymmetric 441 Extended Route Optimization (AERO) links: 443 3.1. AERO Link Reference Model 445 .-(::::::::) 446 .-(::::::::::::)-. 447 (:::: Internet ::::) 448 `-(::::::::::::)-' 449 `-(::::::)-' 450 | 451 +--------------+ +--------+-------+ +--------------+ 452 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 453 | Nbr: C1, R1 | | Nbr: S1, S2, P1| | Nbr: C2, R1 | 454 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 455 | X1->C1 | | MSP M1 | | X2->C2 | 456 +-------+------+ +--------+-------+ +------+-------+ 457 | AERO Link | | 458 X---+---+-------------------+-+----------------+---+---X 459 | | | 460 +-----+--------+ +----------+------+ +--------+-----+ 461 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 462 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 463 | default->S1 | +--------+--------+ | default->S2 | 464 | MNP X1 | | | MNP X2 | 465 +------+-------+ .--------+------. +-----+--------+ 466 | (- Proxyed Clients -) | 467 .-. `---------------' .-. 468 ,-( _)-. ,-( _)-. 469 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 470 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 471 `-(______)-' +-------+ +-------+ `-(______)-' 473 Figure 1: AERO Link Reference Model 475 Figure 1 presents the AERO link reference model. In this model: 477 o the AERO link is an overlay Layer 3 service configured over one or 478 more underlying INETs which may be managed by different 479 administrative authorities and have incompatible protocols and/or 480 addressing plans. 482 o AERO Relay R1 aggregates Mobility Service Prefix (MSP) M1, 483 discovers Mobile Network Prefixes (MNPs) X*, acts as a default 484 router for its associated Servers and Proxies (S1, S2, P1), and 485 connects the AERO link to the external Internet. AERO Relays also 486 use the SPAN service to bridge disjoint segments (i.e., INETs) of 487 a partitioned AERO link. 489 o AERO Servers S1 and S2 associate with Relay R1 and also act as 490 Mobility Anchor Points (MAPs) and default routers for their 491 associated Clients C1 and C2. 493 o AERO Clients C1 and C2 associate with Servers S1 and S2, 494 respectively. They receive Mobile Network Prefix (MNP) 495 delegations X1 and X2, and also act as default routers for their 496 associated physical or internal virtual EUNs. Simple hosts H1 and 497 H2 attach to the EUNs served by Clients C1 and C2, respectively. 499 o AERO Proxy P1 provides proxy services for AERO Clients in secured 500 enclaves that cannot associate directly with other AERO link 501 neighbors. 503 Each node on the AERO link maintains an AERO interface neighbor cache 504 and an IP forwarding table the same as for any link. Although the 505 figure shows a limited deployment, in common operational practice 506 there will normally be many additional Relays, Servers, Clients and 507 Proxies. 509 3.2. AERO Node Types 511 AERO Relays provide both layer-3 routing and layer-2 bridging 512 services (as well as a security trust anchor) for nodes on an AERO 513 link. As a router, the Relay forwards data packets using standard IP 514 forwarding. As a bridge, the Relay securely forwards control 515 messages between Proxies and Servers both within the same INET and 516 between disjoint INETs. Each Relay also peers with Servers and other 517 Relays in a dynamic routing protocol instance to provide a 518 Distributed Mobility Management (DMM) service for the list of active 519 MNPs (see Section 3.3). Relays forward packets between neighbors 520 connected to the same AERO link and also forward packets between the 521 AERO link and the outside world. Relays present the AERO link as a 522 set of one or more Mobility Service Prefixes (MSPs). Relays maintain 523 neighbor cache entries for Servers and Proxies, and maintain an IP 524 forwarding table entry for each Mobile Network Prefix (MNP). 526 AERO Servers provide default forwarding services and a Mobility 527 Anchor Point (MAP) for AERO Client Mobile Nodes (MNs). Each Server 528 also peers with Relays in a dynamic routing protocol instance to 529 advertise its list of associated MNPs (see Section 3.3). Servers 530 facilitate PD exchanges with Clients, where each delegated prefix 531 becomes an MNP taken from an MSP. Servers forward packets between 532 AERO interface neighbors, and maintain neighbor cache entries for 533 Relays. They also maintain both neighbor cache entries and IP 534 forwarding table entries for each of their associated Clients, and 535 track each Client's mobility profiles. 537 AERO Clients act as requesting Mobile Routers (MRs) to receive MNPs 538 through PD exchanges with AERO Servers over the AERO link, and 539 distribute the MNPs to nodes on EUNs. Each Client can associate with 540 a single Server or with multiple Servers, e.g., for fault tolerance, 541 load balancing, etc. Each IPv6 Client receives at least a /64 IPv6 542 MNP, and may receive even shorter prefixes. Similarly, each IPv4 543 Client receives at least a /32 IPv4 MNP (i.e., a singleton IPv4 544 address), and may receive even shorter prefixes. Clients maintain an 545 AERO interface neighbor cache entry for each of their associated 546 Servers as well as for each of their correspondent Clients. A Client 547 may also be co-resident on the same physical or virtual platform as a 548 Server; in that case, the Client and Server behave as a single 549 functional unit and without the need for any Client/Server control 550 messaging. 552 AERO Proxies provide a conduit for AERO Clients in ANETs to associate 553 with AERO Servers in external INETs. The Client sends all of its 554 control plane messages to the Server via the Proxy, which intercepts 555 them before they leave the ANET. The Proxy forwards the Client's 556 control and data plane messages to and from the Client's current 557 Server(s). The Proxy may also discover a better route toward a 558 target destination via AERO route optimization, in which case future 559 outbound data packets would be forwarded via the more direct route. 560 Proxies maintain AERO interface neighbor cache entries for Relays, 561 i.e., the same as Servers. The Proxy function is specified in 562 Section 3.16. 564 AERO Gateways are combined Client/Servers that also provide 565 forwarding services between correspondent nodes (CNs) on the AERO 566 interface and fixed nodes (FNs) on INET interfaces. AERO Gateways 567 are provisioned with MNPs used for numbering nodes and networks on 568 downstream-attached INET interfaces (i.e., the same as for an AERO 569 Client) and may also run a dynamic routing protocol to discover any 570 native INET prefixes. In both cases, the Gateway advertises the 571 MSP(s) to correspondent nodes in downstream-attached INET networks, 572 and distributes all of its associated MNPs and native INET prefixes 573 via BGP peerings with Relays. 575 AERO Relays, Servers, Proxies and Gateways are critical 576 infrastructure elements in fixed (i.e., non-mobile) INET deployments 577 and hence have permanent and unchanging INET addresses. AERO Clients 578 are MNs that connect via ANET interfaces, i.e., their ANET addresses 579 may change when the Client moves to a new ANET connection. 581 3.3. AERO Routing System 583 The AERO routing system comprises a private instance of the Border 584 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 585 and Servers and does not interact with either the public Internet BGP 586 routing system or any underlying INET routing systems. Relays 587 advertise only a small and unchanging set of MSPs to the outside 588 world instead of the full dynamically changing set of MNPs. 590 In a reference deployment, each Server is configured as an Autonomous 591 System Border Router (ASBR) for a stub Autonomous System (AS) using 592 an AS Number (ASN) that is unique within the BGP instance, and each 593 Server further uses eBGP to peer with one or more Relays but does not 594 peer with other Servers. Each INET of a multi-segment AERO link must 595 include one or more Relays, which peer with the Servers and Proxies 596 within that INET. All Relays within the same INET are members of the 597 same hub AS using a common ASN, and use iBGP to maintain a consistent 598 view of all active MNPs currently in service. The Relays of 599 different INETs peer with one another using eBGP. 601 Each Server maintains a working set of associated MNPs and native 602 INET prefixes, and dynamically announces new prefixes and withdraws 603 departed prefixes in its eBGP updates to Relays. Clients are 604 expected to remain associated with their current Servers for extended 605 timeframes, however Servers SHOULD selectively suppress updates for 606 impatient Clients that repeatedly associate and disassociate with 607 them in order to dampen routing churn. Servers that are configured 608 as Gateways advertise the MSP into the INET and forward packets 609 between INET interfaces and the AERO interface. 611 Each Relay configures a black-hole route for each of its MSPs. By 612 black-holing the MSPs, the Relay will maintain forwarding table 613 entries only for the MNPs that are currently active, and packets 614 destined to all other MNPs will correctly incur Destination 615 Unreachable messages due to the black hole route. Relays do not send 616 eBGP updates for MNPs to Servers, but instead only originate a 617 default route. In this way, Servers have only partial topology 618 knowledge (i.e., they know only about the MNPs of their directly 619 associated Clients) and they forward all other packets to Relays 620 which have full topology knowledge. 622 For IPv6 MNPs, the AERO routing system includes only IPv6 routes. 623 For IPv4 MNPs, the AERO routing system includes both IPv4 routes and 624 also IPv6 routes based on the IPv4-mapped IPv6 address corresponding 625 to the MNP and with prefix length set to 96 plus the length of the 626 IPv4 prefix. (For example, if the IPv4 MNP is 192.0.2.0/24 then the 627 IPv4-mapped prefix is 0:0:0:0:0:FFFF:192.0.2.0/120.) 629 Scaling properties of the AERO routing system are limited by the 630 number of BGP routes that can be carried by Relays. As of 2015, the 631 global public Internet BGP routing system manages more than 500K 632 routes with linear growth and no signs of router resource exhaustion 633 [BGP]. More recent network emulation studies have also shown that a 634 single Relay can accommodate at least 1M dynamically changing BGP 635 routes even on a lightweight virtual machine, i.e., and without 636 requiring high-end dedicated router hardware. 638 Therefore, assuming each Relay can carry 1M or more routes, this 639 means that at least 1M Clients can be serviced by a single set of 640 Relays. A means of increasing scaling would be to assign a different 641 set of Relays for each set of MSPs. In that case, each Server still 642 peers with one or more Relays, but institutes route filters so that 643 BGP updates are only sent to the specific set of Relays that 644 aggregate the MSP. For example, if the MSP for the AERO link is 645 2001:db8::/32, a first set of Relays could service the MSP segment 646 2001:db8::/40, a second set of Relays could service 647 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 648 etc. 650 Assuming up to 1K sets of Relays, the AERO routing system can then 651 accommodate 1B or more MNPs with no additional overhead (for example, 652 it should be possible to service 1B /64 MNPs taken from a /34 MSP and 653 even more for shorter prefixes). In this way, each set of Relays 654 services a specific set of MSPs that they advertise to the native 655 Internetwork routing system, and each Server configures MSP-specific 656 routes that list the correct set of Relays as next hops. This 657 arrangement also allows for natural incremental deployment, and can 658 support small scale initial deployments followed by dynamic 659 deployment of additional Clients, Servers and Relays without 660 disturbing the already-deployed base. 662 A full discussion of the BGP-based routing system used by AERO is 663 found in [I-D.ietf-rtgwg-atn-bgp]. The system provides for 664 Distributed Mobility Management (DMM) per the distributed mobility 665 anchoring architecture [I-D.ietf-dmm-distributed-mobility-anchoring]. 667 3.4. AERO Addresses 669 A Client's AERO address is an IPv6 link-local address with an 670 interface identifier based on the Client's delegated MNP. Relay, 671 Server and Proxy AERO addresses are assigned from the range fe80::/96 672 and include an administratively-provisioned value in the lower 32 673 bits. 675 For IPv6, Client AERO addresses begin with the prefix fe80::/64 and 676 include in the interface identifier (i.e., the lower 64 bits) a 677 64-bit prefix taken from one of the Client's IPv6 MNPs. For example, 678 if the AERO Client receives the IPv6 MNP: 680 2001:db8:1000:2000::/56 682 it constructs its corresponding AERO addresses as: 684 fe80::2001:db8:1000:2000 686 fe80::2001:db8:1000:2001 688 fe80::2001:db8:1000:2002 690 ... etc. ... 692 fe80::2001:db8:1000:20ff 694 For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6 695 address formed from an IPv4 MNP and with a Prefix Length of 96 plus 696 the MNP prefix length. For example, for the IPv4 MNP 192.0.2.32/28 697 the IPv4-mapped IPv6 MNP is: 699 0:0:0:0:0:FFFF:192.0.2.16/124 701 The Client then constructs its AERO addresses with the prefix 702 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 703 in the interface identifier as: 705 fe80::FFFF:192.0.2.16 707 fe80::FFFF:192.0.2.17 709 fe80::FFFF:192.0.2.18 711 ... etc. ... 713 fe80:FFFF:192.0.2.31 715 Relay, Server and Proxy AERO addresses are allocated from the range 716 fe80::/96, and MUST be managed for uniqueness. The lower 32 bits of 717 the AERO address includes a unique integer value (e.g., fe80::1, 718 fe80::2, fe80::3, etc.) as assigned by the administrative authority 719 for the link. If the link spans multiple segments (i.e., multiple 720 INETs), the AERO addresses are assigned to each INET in 1x1 721 correspondence with SPAN addresses (see: Section 3.5). The address 722 fe80:: is reserved as the IPv6 link-local Subnet Router Anycast 723 address [RFC4291], and the address fe80::ffff:ffff is reserved as the 724 unspecified AERO address; hence, these values are not available 725 general assignment. 727 The lowest-numbered AERO address from a Client's MNP delegation 728 serves as the "base" AERO address (for example, for the MNP 729 2001:db8:1000:2000::/56 the base AERO address is 730 fe80::2001:db8:1000:2000). The Client then assigns the base AERO 731 address to the AERO interface and uses it for the purpose of 732 maintaining the neighbor cache entry. The Server likewise uses the 733 AERO address as its index into the neighbor cache for this Client. 735 If the Client has multiple AERO addresses (i.e., when there are 736 multiple MNPs and/or MNPs with prefix lengths shorter than /64), the 737 Client originates ND messages using the base AERO address as the 738 source address and accepts and responds to ND messages destined to 739 any of its AERO addresses as equivalent to the base AERO address. In 740 this way, the Client maintains a single neighbor cache entry that may 741 be indexed by multiple AERO addresses. 743 Client AERO addresses can be statelessly transformed into an IPv6 744 Subnet Router Anycast address and vice-versa. For example, for the 745 AERO address fe80::2001:db8:2000:3000 the corresponding Subnet Router 746 Anycast address is 2001:db8:2000:3000::. In the same way, for the 747 IPv6 Subnet Router Anycast address 2001:db8:1:2:: the corresponding 748 AERO address is fe80::2001:db8:1:2. In other words, the low-order 64 749 bits of an AERO address can be used as the high-order 64 bits of a 750 Subnet Router Anycast address, and vice-versa. 752 3.5. Spanning Partitioned AERO Networks (SPAN) 754 In the simplest case, an AERO link configured over a single INET 755 appears as a single unified link with a consistent underlying network 756 addressing plan. In that case, all nodes on the link can exchange 757 packets via encapsulation with INET addresses, since the underlying 758 INET is connected. In common practice, however, an AERO link may be 759 partitioned into multiple "segments", where each segment is a 760 distinct INET managed under a different administrative authority 761 (e.g., as for worldwide aviation service providers such as ARINC, 762 SITA, Inmarsat, etc.). Individual INETs may themselves be 763 partitioned internally, in which case each internal partition is seen 764 as a separate segment. 766 The addressing plan of each segment is consistent internally but will 767 often bear no relation to the addressing plans of other segments. 768 Each segment is also likely to be separated from others by network 769 security devices (e.g., firewalls, proxies, packet filtering 770 gateways, etc.), and in many cases disjoint segments may not even 771 have any common physical link connections at all. Therefore, nodes 772 can only be assured of exchanging packets directly with nodes in the 773 same segment, and not with nodes in other segments. The only means 774 for joining the segments therefore is through inter-domain peerings 775 between AERO Relays acting as bridges. 777 The same as for traditional campus LANs, multiple AERO link segments 778 can be joined into a single unified link via a bridging service 779 termed the "SPAN". The SPAN performs link-layer packet forwarding 780 between segments (i.e., bridging) without decrementing the network- 781 layer TTL/Hop Limit. The SPAN model is depicted in Figure 2: 783 . . . . . . . . . . . . . . . . . . . . . . . 784 . . 785 . .-(::::::::) . 786 . .-(::::::::::::)-. +-+ . 787 . (:::: Segment A :::)--|R|---+ . 788 . `-(::::::::::::)-' +-+ | . 789 . `-(::::::)-' | . 790 . | . 791 . .-(::::::::) | . 792 . .-(::::::::::::)-. +-+ | . 793 . (:::: Segment B :::)--|R|---+ . 794 . `-(::::::::::::)-' +-+ | . 795 . `-(::::::)-' | . 796 . | . 797 . .-(::::::::) | . 798 . .-(::::::::::::)-. +-+ | . 799 . (:::: Segment C :::)--|R|---+ . 800 . `-(::::::::::::)-' +-+ | . 801 . `-(::::::)-' | . 802 . | . 803 . ..(etc).. x . 804 . . 805 . . 806 . <- AERO Link Bridged by the SPAN -> . 807 . . . . . . . . . . . . . .. . . . . . . . . 809 Figure 2: The SPAN 811 To support the SPAN, AERO links require a reserved /96 IPv6 "SPAN 812 Service Prefix (SSP)". Although any routable IPv6 prefix can be 813 used, a Unique Local Address (ULA) prefix (e.g., fd00::/96) [RFC4389] 814 is preferred since border routers are commonly configured to prevent 815 packets with ULAs from being injected into the AERO link by an 816 external IPv6 node and from leaking out of the AERO link to the 817 outside world. 819 Each segment in the SPAN assigns a unique sub-prefix of the SSP 820 termed a "SPAN Partition Prefix (SPP)". For example, a first segment 821 could assign fd00::/116, a second could assign fd00::1000/116, a 822 third could assign fd00::2000/116, etc. The administrative 823 authorities for each segment must therefore coordinate to assure 824 mutually-exclusive SPP assignments, but internal provisioning of the 825 SPP is a local consideration for each administrative authority. 827 A "SPAN address" is an address taken from a SPP and assigned to a 828 Relay, Server or Proxy AERO interface. SPAN addresses are formed by 829 simply replacing the upper portion of an administratively-assigned 830 AERO address with the SPP. For example, if the SPP is fd00::/116, 831 the SPAN address formed from the AERO address fe80::1 is simply 832 fd00::1. (As with AERO addresses, the values ::0 and ::ffff:ffff are 833 reserved and not available for general assignment.) 835 An "INET address" is an address of a node's interface connection to 836 an INET segment. Each Relay, Server and Proxy connected to the same 837 segment maintains a static mapping of AERO/SPAN addresses to INET 838 addresses for all fixed infrastructure elements in that segment. For 839 example, if a Server has AERO/SPAN addresses fe80::1/fd00::1 and INET 840 address 192.0.2.100, then all other Relays, Servers and Proxys in 841 that segment keep a static mapping for those addresses. In that way, 842 any of the AERO/SPAN/INET addresses can be derived from a static 843 lookup without the need for protocol messaging. 845 AERO Relays serve as bridges to join multiple segments into a unified 846 AERO link over multiple diverse administrative domains. They support 847 the bridging function by first establishing forwarding table entries 848 for their SPPs either via standard BGP routing or static routes. For 849 example, if three Relays (Relays 'A', 'B' and 'C') from different 850 segments serviced the SPPs fd00::1000/116, fd00::2000/116 and 851 fd00::3000/116 respectively, then the forwarding tables in each Relay 852 are as follows: 854 A: fd00::1000/116->local, fd00::2000/116->B, fd00::3000/116->C 856 B: fd00::1000/116->A, fd00::2000/116->local, fd00::3000/116->C 858 C: fd00::1000/116->A, fd00::2000/116->B, fd00::3000/116->local 859 These forwarding table entries are permanent and never change, since 860 they correspond to fixed infrastructure elements in their respective 861 segments. This point is of critical importance, since it provides 862 the basis for a link-layer forwarding service that cannot be 863 disrupted by routing updates due to node mobility. 865 With the SPPs in place in each Relay's forwarding table, control and 866 data packets sent between AERO nodes in different segments can 867 therefore be carried over the SPAN via encapsulation. For example, 868 when a source node in segment A forwards a packet with IPv6 address 869 2001:db8:1:2::1 to a destination node in segment C with IPv6 address 870 2001:db8:1000:2000::1, it first encapsulates the packet in a SPAN 871 header with source SPAN address taken from fd00::1000/116 (e.g., 872 fd00::1001) and destination SPAN address taken from fd00::3000/116 873 (e.g., fd00::3001). Next, it encapsulates the SPAN message in an 874 INET header with source address set to its own INET address (e.g., 875 192.0.2.100) and destination set to the INET address of a Relay 876 (e.g., 192.0.2.1). 878 SPAN encapsulation is based on Generic Packet Tunneling in IPv6 879 [RFC2473]; the encapsulation format in the above example is shown 880 inFigure 3: 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | INET Header | 884 | src = 192.0.2.100 | 885 | dst = 192.0.2.1 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | SPAN Header | 888 | src = fd00::1001 | 889 | dst = fd00::3001 | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Inner IP Header | 892 | src = 2001:db8:1:2::1 | 893 | dst = 2001:db8:1000:2000::1 | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | | 896 ~ ~ 897 ~ Inner Packet Body ~ 898 ~ ~ 899 | | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 Figure 3: SPAN Encapsulation 904 In this format, the inner IP header and packet body are the original 905 IP packet, the SPAN header is an IPv6 header prepared according to 906 [RFC2473], and the INET header is prepared according to Section 3.10. 908 A packet is said to be "forwarded/sent into the SPAN" when it is 909 encapsulated as described above then forwarded to a neighboring 910 Relay. This terminology appears throughout the remainder of the 911 document. 913 This gives rise to a routing system that contains both MNP routes 914 that may change dynamically due to regional node mobility and SPAN 915 routes that never change. The Relays can therefore provide link- 916 layer bridging by sending packets into the SPAN instead of network- 917 layer routing according to MNP routes. As a result, opportunities 918 for packet loss due to node mobility between different segments are 919 mitigated. 921 NB: With reference to Figure 3, the destination SPAN address may not 922 be known in advance for the first few packets of a flow sent via the 923 SPAN. In that case, the SPAN destination address is set to the 924 subnet router anycast address corresponding to the original packet's 925 destination, and the SPAN routing system will direct the packet to 926 the correct SPAN egress node. (In the above example, the subnet 927 router anycast address is simply 2001:db8:1000:2000::.) 929 3.6. AERO Interface Characteristics 931 AERO interfaces use encapsulation (see: Section 3.10) to exchange 932 packets with neighbors attached to the AERO link. 934 AERO interfaces maintain a neighbor cache for tracking per-neighbor 935 state the same as for any interface. AERO interfaces use ND messages 936 including Router Solicitation (RS), Router Advertisement (RA), 937 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for 938 neighbor cache management. 940 AERO interface ND messages include one or more Source/Target Link- 941 Layer Address Options (S/TLLAOs) formatted as shown in Figure 4: 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Length = 5 | Prefix Length |S|R|D|X|N|Resvd| 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Interface ID | Port Number | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | | 951 + + 952 | | 953 + Link Layer Address + 954 | | 955 + + 956 | | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 4: AERO Source/Target Link-Layer Address Option (S/TLLAO) 968 Format 970 In this format: 972 o Type is set to '1' for SLLAO or '2' for TLLAO. 974 o Length is set to the constant value '5' (i.e., 5 units of 8 975 octets). 977 o Prefix Length is set to the MNP prefix length in an ND message for 978 the Client AERO address found in the source (RS), destination (RA) 979 or target (NA) address; otherwise set to 0 if the message is not 980 being used for PD or neighbor prefix discovery. If the message 981 contains multiple SLLAOs, only the Prefix Length value in the 982 SLLAO with S set to 1 is consulted and the values in other SLLAOs 983 are ignored. 985 o S (the 'Source' bit) is set to '1' in the S/TLLAO of an ND message 986 that corresponds to the ANET/INET interface over which the ND 987 message is sent, and set to 0 in all other S/TLLAOs. 989 o R (the "Release" bit) is set to '1' in the SLLAO of an RS message 990 sent for the purpose of departing from a Server; otherwise, set to 991 '0'. If the message contains multiple SLLAOs, only the R value in 992 the SLLAO with S set to 1 is consulted and the values in other 993 SLLAOs are ignored. The Server places the corresponding neighbor 994 cache entry in the DEPARTED state and releases the corresponding 995 PD, then returns an RA with Router Lifetime set to '0'. 997 o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA 998 message for each Interface ID that is to be disabled in the 999 neighbor cache entry; otherwise, set to '0'. If the message 1000 contains an S/TLLAO with Interface ID 0xffff, the node places the 1001 corresponding neighbor cache entry in the DEPARTED state. If the 1002 message contains multiple S/TLLAOs the D value in each S/TLLAO is 1003 consulted. 1005 o X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA message 1006 by the Proxy when there is a Proxy in the path; otherwise, set to 1007 '0'. If the message contains multiple SLLAOs, only the X value in 1008 the first SLLAO is consulted and the values in other SLLAOs are 1009 ignored. 1011 o N (the "(Network Address) Translator (NAT)" bit) is set to '1' in 1012 the SLLAO of an RA message by the Server if there is a translator 1013 in the path; otherwise, set to '0'. If the message contains 1014 multiple SLLAOs, only the N value in the first SLLAO is consulted 1015 and the values in other SLLAOs are ignored. 1017 o Resvd is set to the value '0' on transmission and ignored on 1018 receipt. 1020 o Interface ID is set to a 16-bit integer value corresponding to an 1021 AERO node's ANET/INET interface. Once the node has assigned an 1022 Interface ID to an ANET interface, the assignment must remain 1023 unchanged until the node fully detaches from the AERO link. The 1024 value 0xffff is reserved as the AERO Server's INET Interface ID, 1025 i.e., Servers MUST use Interface ID 0xffff, and Clients MUST 1026 number their ANET Interface IDs with values in the range of 1027 0-0xfffe. 1029 o Port Number and Link Layer Address are set to the addresses used 1030 by the AERO node when it sends encapsulated packets over the 1031 specified ANET/INET interface (or to '0' when the addresses are 1032 left unspecified). When UDP is not used as part of the 1033 encapsulation, Port Number is set to '0'. When the encapsulation 1034 IP address family is IPv4, IP Address is formed as an IPv4-mapped 1035 IPv6 address as specified in Section 3.4. 1037 o P(i) is a set of Preferences that correspond to the 64 1038 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 1039 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 1040 ("medium") or '3' ("high") to indicate a QoS preference level for 1041 packet forwarding purposes. 1043 A Client's AERO interface may be configured over multiple ANET 1044 interface connections. For example, common mobile handheld devices 1045 have both wireless local area network ("WLAN") and cellular wireless 1046 links. These links are typically used "one at a time" with low-cost 1047 WLAN preferred and highly-available cellular wireless as a standby. 1048 In a more complex example, aircraft frequently have many wireless 1049 data link types (e.g. satellite-based, cellular, terrestrial, air-to- 1050 air directional, etc.) with diverse performance and cost properties. 1052 A Client's ANET interfaces are classified as follows: 1054 o Native interfaces connect to the open INET, and have a global IP 1055 address that is reachable from any INET correspondent. 1057 o NATed interfaces connect to an ANET behind a Network Address 1058 Translator (NAT). The NAT does not participate in any AERO 1059 control message signaling, but the AERO Server can issue control 1060 messages on behalf of the Client. Clients that are behind a NAT 1061 are required to send periodic keepalive messages to keep NAT state 1062 alive when there are no data packets flowing. 1064 o VPNed interfaces use security encapsulation over the ANET to a 1065 Virtual Private Network (VPN) server that also acts as an AERO 1066 Server. As with NATed links, the AERO Server can issue control 1067 messages on behalf of the Client, but the Client need not send 1068 periodic keepalives in addition to those already used to maintain 1069 the VPN connection. 1071 o Proxyed interfaces connect to an ANET that is separated from the 1072 open INET by an AERO Proxy. Unlike NATed and VPNed interfaces, 1073 the AERO Proxy can actively issue control messages on behalf of 1074 the Client. 1076 o Direct interfaces connect the Client directly to a neighbor 1077 without crossing any ANET/INET paths. An example is a line-of- 1078 sight link between a remote pilot and an unmanned aircraft. 1080 If a Client's multiple ANET interfaces are used "one at a time" 1081 (i.e., all other interfaces are in standby mode while one interface 1082 is active), then ND messages include only a single S/TLLAO with 1083 Interface ID set to a constant value. In that case, the Client would 1084 appear to have a single ANET interface but with a dynamically 1085 changing ANET address. 1087 If the Client has multiple active ANET interfaces, then from the 1088 perspective of ND it would appear to have multiple link-layer 1089 addresses. In that case, ND messages MAY include multiple S/TLLAOs 1090 -- each with an Interface ID that corresponds to a specific ANET 1091 interface. The S bit must be set to 1 in the S/TLLAO corresponding 1092 to the AERO node's ANET interface used to transmit the message and 1093 set to 0 in all other S/TLLAOs. 1095 When the Client includes an S/TLLAO for an ANET interface for which 1096 it is aware that there is a NAT on the path to the Server, or when a 1097 node includes an S/TLLAO solely for the purpose of announcing new QoS 1098 preferences, the node MAY set both Port Number and Link-Layer Address 1099 to 0 to indicate that the addresses are unspecified at the network 1100 layer and must instead be derived from the link-layer encapsulation 1101 headers. 1103 3.7. AERO Interface Initialization 1105 3.7.1. AERO Relay Behavior 1107 When a Relay enables an AERO interface, it first assigns an 1108 administratively-provisioned AERO address (e.g., fe80::1) and its 1109 companion SPAN address (e.g., fd00::1), where each address MUST be 1110 unique among all AERO nodes on the link. The Relay also configures a 1111 neighbor cache entry for Servers, Gateways and Proxys on the local 1112 segment, and maintains a list of INET address mappings for all fixed 1113 infrastructure elements on the local segment. The Relay then engages 1114 in a BGP routing protocol session with Servers/Gateways on the local 1115 segment and other Relays on the AERO link (see: Section 3.3). Each 1116 Relay subsequently maintains an IP forwarding table entry for each 1117 active MNP covered by its MSP(s) as well as for each SPAN prefix. 1119 3.7.2. AERO Server Behavior 1121 When a Server enables an AERO interface, it assigns AERO/SPAN 1122 addresses and maintains a list of INET address mappings the same as 1123 for Relays. The Server further configures a service to facilitate 1124 ND/PD exchanges with AERO Clients, maintains neighbor cache entries 1125 for one or more Relays on the link, and manages per-Client neighbor 1126 cache entries and IP forwarding table entries based on control 1127 message exchanges. The Server also engages in a BGP routing protocol 1128 session with its neighboring Relays via the AERO interface, and also 1129 engages in a dynamic routing protocol over its INET interfaces (see: 1130 Section 3.3). 1132 When the Server receives an NS/RS message on the AERO interface it 1133 authenticates the message and returns a solicited NA/RA message. 1134 (When the Server receives an unsolicited NA message, it likewise 1135 authenticates the message and processes it locally.) The Server 1136 further provides a simple link-layer conduit between AERO interface 1137 neighbors. In particular, when a packet sent by a source CN arrives 1138 on the Server's AERO interface and is destined to a CN belonging to a 1139 MNP not assigned to one of the Server's INET interfaces, the Server 1140 forwards the packet from within the AERO interface at the link layer 1141 without ever disturbing the network layer. 1143 3.7.3. AERO Gateway Behavior 1145 Gateways are simply Servers that run a dynamic routing protocol 1146 between the AERO and INET interfaces. The Gateway provisions MNPs to 1147 networks on the downstream-attached INET interfaces (i.e., the same 1148 as a Client would do) and advertises the MSP(s) for the AERO link 1149 over the INET interfaces. 1151 3.7.4. AERO Proxy Behavior 1153 When a Proxy enables an AERO interface, it assigns AERO/SPAN 1154 addresses and maintains a list of INET address mappings the same as 1155 for Relays, Servers and Gateways. The Proxy further maintains 1156 neighbor cache entires for one or more Relays, and maintains per- 1157 Client neighbor cache entries based on control message exchanges. 1158 Proxies forward packets between each Client and their associated 1159 Servers and neighbors. 1161 When the Proxy receives an RS message from a Client, it creates an 1162 incomplete neighbor cache entry and sends a proxyed RS message to a 1163 Server via the SPAN while using its own INET address as the source 1164 address. When the Server returns an RA message, the Proxy completes 1165 the proxy neighbor cache entry based on autoconfiguration information 1166 in the RA and sends a proxyed RA to the Client while using its own 1167 ANET address as the source address. The Client, Server and Proxy 1168 will then have the necessary state for managing the proxy neighbor 1169 association. 1171 3.7.5. AERO Client Behavior 1173 When a Client enables an AERO interface, it sends RS messages with 1174 ND/PD parameters over an ANET interface to one or more AERO Servers, 1175 which return RA messages with corresponding PD parameters. (The RS/ 1176 RA messages may pass through a Proxy in the case of a Client's 1177 Proxyed interface.) See [I-D.templin-6man-dhcpv6-ndopt] for the 1178 types of ND/PD parameters that can be included in the RS/RA message 1179 exchanges. 1181 After the initial ND/PD message exchange, the Client assigns AERO 1182 addresses to the AERO interface based on the delegated prefix(es). 1184 The Client can then register additional ANET interfaces with the 1185 Server by sending a simple RS message (i.e., one with no PD 1186 parameters) over each ANET interface using its base AERO address as 1187 the source network layer address. The Server will update its 1188 neighbor cache entry for the Client and return a simple RA message. 1190 The Client maintains a neighbor cache entry for each of its Servers 1191 and each of its active target Clients. When the Client receives ND 1192 messages on the AERO interface it updates or creates neighbor cache 1193 entries, including link-layer address and QoS preferences. 1195 When there is a NAT on the path, the Client must send periodic 1196 messages to keep NAT state alive. If no other periodic messaging 1197 service is available, the Client can send RS messages to receive RA 1198 replies from its Server(s). 1200 A Client may be configured as a co-resident function on the same 1201 platform as a Server. In that case, no Client/Server ND messaging is 1202 required and the Client and Server operate as a single functional 1203 unit. The Client function can use its MNP(s) to number downstream- 1204 attached networks, which may connect very large numbers of nodes. 1206 3.8. AERO Interface Neighbor Cache Maintenance 1208 Each AERO interface maintains a conceptual neighbor cache that 1209 includes an entry for each neighbor it communicates with on the AERO 1210 link per [RFC4861]. AERO interface neighbor cache entries are said 1211 to be one of "permanent", "symmetric", "asymmetric" or "proxy". 1213 Permanent neighbor cache entries are created through explicit 1214 administrative action; they have no timeout values and remain in 1215 place until explicitly deleted. AERO Relays maintain permanent 1216 neighbor cache entries for their associated Relays, Servers, Gateways 1217 and Proxys, and AERO Servers and Proxys maintain permanent neighbor 1218 cache entries for their associated Relays. Each entry maintains the 1219 mapping between the neighbor's network-layer AERO address and 1220 corresponding INET address. 1222 Symmetric neighbor cache entries are created and maintained through 1223 ND/PD exchanges as specified in Section 3.15, and remain in place for 1224 durations bounded by ND/PD lifetimes. AERO Servers maintain 1225 symmetric neighbor cache entries for each of their associated 1226 Clients, and AERO Clients maintain symmetric neighbor cache entries 1227 for each of their associated Servers. 1229 Asymmetric neighbor cache entries are created or updated based on 1230 route optimization messaging as specified in Section 3.17, and are 1231 garbage-collected when keepalive timers expire. AERO route 1232 optimization sources (ROSs) maintain asymmetric neighbor cache 1233 entries for each of their active target Clients with lifetimes based 1234 on ND messaging constants. Asymmetric neighbor cache entries are 1235 unidirectional since only the ROS (i.e., and not the route 1236 optimization responder (ROR)) creates an entry. 1238 Proxy neighbor cache entries are created and maintained by AERO 1239 Proxies when they process Client/Server ND/PD exchanges, and remain 1240 in place for durations bounded by ND/PD lifetimes. AERO Proxies 1241 maintain proxy neighbor cache entries for each of their associated 1242 Clients. Proxy neighbor cache entries track the Client state and the 1243 state of each of the Client's associated Servers. 1245 To the list of neighbor cache entry states in Section 7.3.2 of 1246 [RFC4861], AERO interfaces add an additional state DEPARTED that 1247 applies to symmetric and proxy neighbor cache entries for Clients 1248 that have recently departed. The interface sets a "DepartTime" 1249 variable for the neighbor cache entry to "DEPARTTIME" seconds. 1250 DepartTime is decremented unless a new ND message causes the state to 1251 return to REACHABLE. While a neighbor cache entry is in the DEPARTED 1252 state, packets destined to the target Client are forwarded to the 1253 Client's new location instead of being dropped. When DepartTime 1254 decrements to 0, the neighbor cache entry is deleted. It is 1255 RECOMMENDED that DEPARTTIME be set to the default constant value 40 1256 seconds to allow for packets in flight to be delivered while stale 1257 route optimization state may be present. 1259 When a target AERO Server (acting as a Mobility Anchor Point (MAP)) 1260 receives a valid NS message used for route optimization, it searches 1261 for a symmetric neighbor cache entry for the target Client. The 1262 Server then acts as an ROR and returns a solicited NA message without 1263 creating a neighbor cache entry for the ROS, but creates a target 1264 Client "Report List" entry for the ROS and sets a "ReportTime" 1265 variable for the entry to REPORTTIME seconds. The ROR resets 1266 ReportTime when it receives a new authentic NS message, and otherwise 1267 decrements ReportTime while no NS messages have been received. It is 1268 RECOMMENDED that REPORTTIME be set to the default constant value 40 1269 seconds to allow a 10 second window so that route optimization can 1270 converge before ReportTime decrements below REACHABLETIME. 1272 When the ROS receives a solicited NA message response to its NS 1273 message, it creates or updates an asymmetric neighbor cache entry for 1274 the target network-layer and link-layer addresses. The ROS then 1275 (re)sets ReachableTime for the neighbor cache entry to REACHABLETIME 1276 seconds and uses this value to determine whether packets can be 1277 forwarded directly to the target, i.e., instead of via a default 1278 route. The ROS otherwise decrements ReachableTime while no further 1279 solicited NA messages arrive. It is RECOMMENDED that REACHABLETIME 1280 be set to the default constant value 30 seconds as specified in 1281 [RFC4861]. 1283 The ROS also uses the value MAX_UNICAST_SOLICIT to limit the number 1284 of NS keepalives sent when a correspondent may have gone unreachable, 1285 the value MAX_RTR_SOLICITATIONS to limit the number of RS messages 1286 sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT 1287 to limit the number of unsolicited NAs that can be sent based on a 1288 single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT, 1289 MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the 1290 same as specified in [RFC4861]. 1292 Different values for DEPARTTIME, REPORTTIME, REACHABLETIME, 1293 MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and 1294 MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if 1295 different values are chosen, all nodes on the link MUST consistently 1296 configure the same values. Most importantly, DEPARTTIME and 1297 REPORTTIME SHOULD be set to a value that is sufficiently longer than 1298 REACHABLETIME to avoid packet loss due to stale route optimization 1299 state. 1301 3.9. AERO Interface Forwarding Algorithm 1303 IP packets enter a node's AERO interface either from the network 1304 layer (i.e., from a local application or the IP forwarding system) or 1305 from the link layer (i.e., from an AERO interface neighbor). Packets 1306 that enter the AERO interface from the network layer are encapsulated 1307 and forwarded into the AERO link, i.e., they are tunneled to an AERO 1308 interface neighbor. Packets that enter the AERO interface from the 1309 link layer are either re-admitted into the AERO link or forwarded to 1310 the network layer where they are subject to either local delivery or 1311 IP forwarding. In all cases, the AERO interface itself MUST NOT 1312 decrement the network layer TTL/Hop-count since its forwarding 1313 actions occur below the network layer. 1315 AERO interfaces may have multiple underlying ANET/INET interfaces 1316 and/or neighbor cache entries for neighbors with multiple Interface 1317 ID registrations (see Section 3.6). The AERO interface uses each 1318 packet's DSCP value (and/or port number) to select an outgoing ANET/ 1319 INET interface based on the node's own QoS preferences, and also to 1320 select a destination link-layer address based on the neighbor's ANET/ 1321 INET interface with the highest preference. AERO implementations 1322 SHOULD allow for QoS preference values to be modified at runtime 1323 through network management. 1325 If multiple outgoing interfaces and/or neighbor interfaces have a 1326 preference of "high", the AERO node replicates the packet and sends 1327 one copy via each of the (outgoing / neighbor) interface pairs; 1328 otherwise, the node sends a single copy of the packet via the 1329 interface with the highest preference. AERO nodes keep track of 1330 which ANET/INET interfaces are currently "reachable" or 1331 "unreachable", and only use "reachable" interfaces for forwarding 1332 purposes. 1334 For control messages, the source node always encapsulates the message 1335 in SPAN/INET headers, and forwards the message into the SPAN (i.e., 1336 it forwards the message to a Relay). For data packets, if the 1337 neighboring node can only be reached via the SPAN (or, if it is not 1338 yet know that the neighboring node is within the local segment) the 1339 source node encapsulates packets in a SPAN/INET headers and forwards 1340 them into the SPAN. Otherwise, the source node encapsulates packets 1341 in only an INET header for transmission within the local segment. 1343 The following sections discuss the AERO interface forwarding 1344 algorithms for Clients, Proxies, Servers and Relays. In the 1345 following discussion, a packet's destination address is said to 1346 "match" if it is a non-link-local address with a prefix covered by an 1347 MSP/MNP, or if it is an AERO address that embeds an MNP, or if it is 1348 the same as an administratively-provisioned AERO address. 1350 3.9.1. Client Forwarding Algorithm 1352 When an IP packet enters a Client's AERO interface from the network 1353 layer the Client searches for an asymmetric neighbor cache entry that 1354 matches the destination. If there is a match, the Client uses one or 1355 more "reachable" underlying ANET interfaces in the entry for packet 1356 forwarding. If there is no asymmetric neighbor cache entry, the 1357 Client instead forwards the packets to a Server. 1359 When an IP packet enters a Client's AERO interface from the link- 1360 layer, if the destination matches one of the Client's MNPs or link- 1361 local addresses the Client decapsulates the packet (if necessary) and 1362 delivers it to the network layer. Otherwise, the Client drops the 1363 packet and MAY return a network-layer ICMP Destination Unreachable 1364 message subject to rate limiting (see: Section 3.14). 1366 3.9.2. Proxy Forwarding Algorithm 1368 For control messages originating from or destined to a Client, the 1369 Proxy intercepts the message and updates its proxy neighbor cache 1370 entry for the Client. The Proxy then forwards a (proxyed) copy of 1371 the control message. 1373 When the Proxy receives a data packet from a Client within the ANET, 1374 the Proxy searches for an asymmetric neighbor cache entry that 1375 matches the network-layer destination. If there is a match, the 1376 Proxy uses one or more "reachable" neighbor interfaces in the entry 1377 for packet forwarding. Otherwise, the Proxy uses the SPAN/INET 1378 address in a permanent neighbor cache entry for a Relay (selected 1379 through longest-prefix match) as the encapsulation addresses and 1380 forwards the packet into the SPAN. 1382 When the Proxy receives an encapsulated data packet from the INET, it 1383 searches for a proxy neighbor cache entry that matches the 1384 destination. If there is a proxy neighbor cache entry in the 1385 REACHABLE state, the Proxy forwards the packet to the Client; if the 1386 neighbor cache entry is in the DEPARTED state, the Proxy instead 1387 forwards the packet to the Client's Server and may return an 1388 unsolicited NA message as discussed in Section 3.19. If there is no 1389 neighbor cache entry, the Proxy discards the packet. 1391 3.9.3. Server Forwarding Algorithm 1393 When an IP packet enters a Server's AERO interface from either the 1394 network or link-layer, it decapsulates the packet (if the packet 1395 arrived from the link-layer) then processes the packet according to 1396 the network-layer destination address as follows: 1398 o if the destination matches one of the Server's own addresses the 1399 Server forwards it to the network layer for local delivery. 1401 o else, if the destination matches a symmetric neighbor cache entry 1402 the Server forwards the packet according to the neighbor cache 1403 state and link-layer address information. If the neighbor cache 1404 entry is in the REACHABLE state, the Server forwards the packet 1405 according to the cached link-layer information. If the neighbor 1406 cache entry is in the DEPARTED state, the Server instead continues 1407 to forward packets to the Client's new Server as discussed in 1408 Section 3.19. If the packet is destined to the same Client from 1409 which it arrived, however, the Server must forward the packet via 1410 a different "reachable" Interface ID than the one the packet 1411 arrived on. If there are no "reachable" Interface IDs, the Server 1412 must drop the packet. 1414 o else, if the destination matches an asymmetric neighbor cache 1415 entry for a target Client, the Server forwards the packet 1416 according to the cached link-layer information. 1418 o else, the Server uses the SPAN/INET address in a permanent 1419 neighbor cache entry for a Relay (selected through longest-prefix 1420 match) as the encapsulation addresses. 1422 3.9.4. Gateway Forwarding Algorithm 1424 Gateways perform the same forwarding procedures as for Servers, but 1425 also forward packets between the AERO interface and any downstream- 1426 attached INET interfaces. In particular, if the destination address 1427 of a packet that arrives on an AERO interfaces matches a prefix 1428 associated with a downstream-attached INET interface, the Gateway 1429 forwards the packet to the next hop via the INET interface. 1430 Conversely, the Gateway forwards packets that arrive on an INET 1431 interface to the next hop via the AERO interface or another INET 1432 interface according to longest prefix match. 1434 3.9.5. Relay Forwarding Algorithm 1436 Relays forward packets the same as any IP router. When the Relay 1437 receives an encapsulated packet via the AERO link, it removes the 1438 INET header and searches for a forwarding table entry that matches 1439 the destination address in the SPAN header. When the Relay receives 1440 an unencapsulated packet from a node outside the AERO link, it 1441 searches for a forwarding table entry that matches the IP destination 1442 address. The Relay then processes the packet as follows: 1444 o if the destination does not match an MSP or the SSP, or if the 1445 destination matches one of the Relay's own addresses, the Relay 1446 submits the packet for either IP forwarding or local delivery. 1448 o else, if the destination matches an MNP/SPP entry in the IP 1449 forwarding table the Relay encapsulates the packet in an INET 1450 header and forwards it to the neighbor. 1452 o else, the Relay drops the packet and returns an ICMP Destination 1453 Unreachable message subject to rate limiting (see: Section 3.14). 1455 As for any IP router, the Relay decrements the TTL/Hop Count when it 1456 forwards the packet. 1458 3.10. AERO Interface Encapsulation and Re-encapsulation 1460 AERO interfaces encapsulate packets in ANET/INET headers according to 1461 whether they are entering the AERO interface from the network layer 1462 or if they are being re-admitted into the same AERO link they arrived 1463 on. This latter form of encapsulation is known as "re- 1464 encapsulation". Note that Clients can avoid encapsulation when the 1465 first-hop access router is AERO-aware. 1467 The AERO interface encapsulates the packet in an ANET/INET header per 1468 the Generic UDP Encapsulation (GUE) procedures in 1469 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 1470 an alternate encapsulation format (e.g., see: Appendix A, [RFC2784], 1471 [RFC8086], [RFC4301], etc.). 1473 For packets entering the AERO interface from the network layer, the 1474 AERO interface copies the "TTL/Hop Limit", "Type of Service/Traffic 1475 Class" [RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion 1476 Experienced" [RFC3168] values in the packet's IP header into the 1477 corresponding fields in the encapsulation header(s). For packets 1478 undergoing re-encapsulation, the AERO interface instead copies these 1479 values from the original encapsulation header into the new 1480 encapsulation header, i.e., the values are transferred between 1481 encapsulation headers and *not* copied from the encapsulated packet's 1482 network-layer header. (Note especially that by copying the TTL/Hop 1483 Limit between encapsulation headers the value will eventually 1484 decrement to 0 if there is a (temporary) routing loop.) For IPv4 1485 encapsulation/re-encapsulation, the AERO interface sets the DF bit as 1486 discussed in Section 3.13. 1488 When GUE encapsulation is used, the AERO interface next sets the UDP 1489 source port to a constant value that it will use in each successive 1490 packet it sends, and sets the UDP length field to the length of the 1491 encapsulated packet plus 8 bytes for the UDP header itself plus the 1492 length of the GUE header (or 0 if GUE direct IP encapsulation is 1493 used). For packets sent to a Server or Relay, the AERO interface 1494 sets the UDP destination port to 8060, i.e., the IANA-registered port 1495 number for AERO. For packets sent to a Client, the AERO interface 1496 sets the UDP destination port to the port value stored in the 1497 neighbor cache entry for this Client. The AERO interface then either 1498 includes or omits the UDP checksum according to the GUE 1499 specification. 1501 3.11. AERO Interface Decapsulation 1503 AERO interfaces decapsulate packets destined either to the AERO node 1504 itself or to a destination reached via an interface other than the 1505 AERO interface the packet was received on. Decapsulation is per the 1506 procedures specified for the appropriate encapsulation format. 1508 3.12. AERO Interface Data Origin Authentication 1510 AERO nodes employ simple data origin authentication procedures for 1511 encapsulated packets they receive from other nodes on the AERO link. 1512 In particular: 1514 o AERO Relays and Servers accept encapsulated packets with a link- 1515 layer source address that matches a permanent neighbor cache 1516 entry. 1518 o AERO Servers accept authentic encapsulated ND messages from 1519 Clients (either directly or via a Proxy), and create or update a 1520 symmetric neighbor cache entry for the Client based on the 1521 specific message type. 1523 o AERO Clients and Servers accept encapsulated packets if there is a 1524 symmetric neighbor cache entry with a link-layer address that 1525 matches the packet's link-layer source address. 1527 o AERO Proxies accept encapsulated packets if there is a proxy 1528 neighbor cache entry that matches the packet's network-layer 1529 address. 1531 Each packet should include a signature that the recipient can use to 1532 authenticate the message origin, e.g., as for common VPN systems such 1533 as OpenVPN [OVPN]. In some environments, however, it may be 1534 sufficient to require signatures only for ND control plane messages 1535 (see: Section 14) and omit signatures for data plane messages. 1537 3.13. AERO Interface Packet Size Issues 1539 The AERO interface is the node's attachment to the AERO link. The 1540 AERO interface acts as a tunnel ingress when it sends a packet to an 1541 AERO link neighbor and as a tunnel egress when it receives a packet 1542 from an AERO link neighbor. AERO interfaces observe the packet 1543 sizing considerations for tunnels discussed in 1544 [I-D.ietf-intarea-tunnels] and as specified below. 1546 The Internet Protocol expects that IP packets will either be 1547 delivered to the destination or a suitable Packet Too Big (PTB) 1548 message returned to support the process known as IP Path MTU 1549 Discovery (PMTUD) [RFC1191][RFC8201]. However, PTB messages may be 1550 crafted for malicious purposes such as denial of service, or lost in 1551 the network [RFC2923]. This can be especially problematic for 1552 tunnels, where a condition known as a PMTUD "black hole" can result. 1553 For these reasons, AERO interfaces employ operational procedures that 1554 avoid interactions with PMTUD, including the use of fragmentation 1555 when necessary. 1557 AERO interfaces observe two different types of fragmentation. Source 1558 fragmentation occurs when the AERO interface (acting as a tunnel 1559 ingress) fragments the encapsulated packet into multiple fragments 1560 before admitting each fragment into the tunnel. Network 1561 fragmentation occurs when an encapsulated packet admitted into the 1562 tunnel by the ingress is fragmented by an IPv4 router on the path to 1563 the egress. Note that an IPv4 packet that incurs source 1564 fragmentation may also incur network fragmentation. 1566 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1567 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1568 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1569 for IPv4 even if encapsulated packets may incur network 1570 fragmentation. 1572 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1573 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1574 (but, note that many standard IPv6 over IPv4 tunnel types already 1575 assume a larger MRU than the IPv4 minimum). 1577 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1578 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1579 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1580 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1581 configure a Maximum Segment Unit (MSU) as the maximum-sized 1582 encapsulated packet that the ingress can inject into the tunnel 1583 without source fragmentation. The MSU value MUST NOT be larger than 1584 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1585 operational assurance that a larger size can traverse the link along 1586 all paths. 1588 All AERO nodes MUST configure the same MTU value for reasons cited in 1589 [RFC3819][RFC4861]; in particular, multicast support requires a 1590 common MTU value among all nodes on the link. All AERO nodes MUST 1591 configure an MRU large enough to reassemble packets up to 1592 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1593 enough MRU MUST NOT enable an AERO interface. 1595 The network layer proceeds as follow when it presents an IP packet to 1596 the AERO interface. For each IPv4 packet that is larger than the 1597 AERO interface MTU and with the DF bit set to 0, the network layer 1598 uses IPv4 fragmentation to break the packet into a minimum number of 1599 non-overlapping fragments where the first fragment is no larger than 1600 the MTU and the remaining fragments are no larger than the first. 1601 For all other IP packets, if the packet is larger than the AERO 1602 interface MTU, the network layer drops the packet and returns a PTB 1603 message to the original source. Otherwise, the network layer admits 1604 each IP packet or fragment into the AERO interface. 1606 For each IP packet admitted into the AERO interface, the interface 1607 (acting as a tunnel ingress) encapsulates the packet. If the 1608 encapsulated packet is larger than the AERO interface MSU the ingress 1609 source-fragments the encapsulated packet into a minimum number of 1610 non-overlapping fragments where the first fragment is no larger than 1611 the MSU and the remaining fragments are no larger than the first. 1612 The ingress then admits each encapsulated packet or fragment into the 1613 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1614 header in case any network fragmentation is necessary. The 1615 encapsulated packets will be delivered to the egress, which 1616 reassembles them into a whole packet if necessary. 1618 Several factors must be considered when fragmentation is needed. For 1619 AERO links over IPv4, the IP ID field is only 16 bits in length, 1620 meaning that fragmentation at high data rates could result in data 1621 corruption due to reassembly misassociations [RFC6864][RFC4963]. In 1622 environments where IP fragmentation issues could result in 1623 operational problems, the ingress SHOULD employ intermediate-layer 1624 source fragmentation (see: [RFC2764] and 1625 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1626 encapsulation headers to each fragment. Since the encapsulation 1627 fragment header reduces the room available for packet data, but the 1628 original source has no way to control its insertion, the ingress MUST 1629 include the fragment header length in the ENCAPS length even for 1630 packets in which the header is absent. 1632 3.14. AERO Interface Error Handling 1634 When an AERO node admits encapsulated packets into the AERO 1635 interface, it may receive link-layer or network-layer error 1636 indications. 1638 A link-layer error indication is an ICMP error message generated by a 1639 router in the INET on the path to the neighbor or by the neighbor 1640 itself. The message includes an IP header with the address of the 1641 node that generated the error as the source address and with the 1642 link-layer address of the AERO node as the destination address. 1644 The IP header is followed by an ICMP header that includes an error 1645 Type, Code and Checksum. Valid type values include "Destination 1646 Unreachable", "Time Exceeded" and "Parameter Problem" 1647 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1648 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1649 only emit packets that are guaranteed to be no larger than the IP 1650 minimum link MTU as discussed in Section 3.13.) 1652 The ICMP header is followed by the leading portion of the packet that 1653 generated the error, also known as the "packet-in-error". For 1654 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1655 much of invoking packet as possible without the ICMPv6 packet 1656 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1657 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1658 "Internet Header + 64 bits of Original Data Datagram", however 1659 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1660 ICMP datagram SHOULD contain as much of the original datagram as 1661 possible without the length of the ICMP datagram exceeding 576 1662 bytes". 1664 The link-layer error message format is shown in Figure 5 (where, "L2" 1665 and "L3" refer to link-layer and network-layer, respectively): 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 ~ ~ 1669 | L2 IP Header of | 1670 | error message | 1671 ~ ~ 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | L2 ICMP Header | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1675 ~ ~ P 1676 | IP and other encapsulation | a 1677 | headers of original L3 packet | c 1678 ~ ~ k 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1680 ~ ~ t 1681 | IP header of | 1682 | original L3 packet | i 1683 ~ ~ n 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 ~ ~ e 1686 | Upper layer headers and | r 1687 | leading portion of body | r 1688 | of the original L3 packet | o 1689 ~ ~ r 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1692 Figure 5: AERO Interface Link-Layer Error Message Format 1694 The AERO node rules for processing these link-layer error messages 1695 are as follows: 1697 o When an AERO node receives a link-layer Parameter Problem message, 1698 it processes the message the same as described as for ordinary 1699 ICMP errors in the normative references [RFC0792][RFC4443]. 1701 o When an AERO node receives persistent link-layer Time Exceeded 1702 messages, the IP ID field may be wrapping before earlier fragments 1703 awaiting reassembly have been processed. In that case, the node 1704 SHOULD begin including integrity checks and/or institute rate 1705 limits for subsequent packets. 1707 o When an AERO node receives persistent link-layer Destination 1708 Unreachable messages in response to encapsulated packets that it 1709 sends to one of its asymmetric neighbor correspondents, the node 1710 SHOULD process the message as an indication that a path may be 1711 failing, and MAY initiate NUD over that path. If it receives 1712 Destination Unreachable messages on many or all paths, the node 1713 SHOULD set ReachableTime for the corresponding asymmetric neighbor 1714 cache entry to 0 and allow future packets destined to the 1715 correspondent to flow through a default route. 1717 o When an AERO Client receives persistent link-layer Destination 1718 Unreachable messages in response to encapsulated packets that it 1719 sends to one of its symmetric neighbor Servers, the Client SHOULD 1720 mark the path as unusable and use another path. If it receives 1721 Destination Unreachable messages on many or all paths, the Client 1722 SHOULD associate with a new Server and release its association 1723 with the old Server as specified in Section 3.19.7. 1725 o When an AERO Server receives persistent link-layer Destination 1726 Unreachable messages in response to encapsulated packets that it 1727 sends to one of its symmetric neighbor Clients, the Server SHOULD 1728 mark the underlying path as unusable and use another underlying 1729 path. If it receives Destination Unreachable messages on multiple 1730 paths, the Server should take no further actions unless it 1731 receives an explicit ND/PD release message or if the PD lifetime 1732 expires. In that case, the Server MUST release the Client's 1733 delegated MNP, withdraw the MNP from the AERO routing system and 1734 delete the neighbor cache entry. 1736 o When an AERO Relay or Server receives link-layer Destination 1737 Unreachable messages in response to an encapsulated packet that it 1738 sends to one of its permanent neighbors, it treats the messages as 1739 an indication that the path to the neighbor may be failing. 1740 However, the dynamic routing protocol should soon reconverge and 1741 correct the temporary outage. 1743 When an AERO Relay receives a packet for which the network-layer 1744 destination address is covered by an MSP, if there is no more- 1745 specific routing information for the destination the Relay drops the 1746 packet and returns a network-layer Destination Unreachable message 1747 subject to rate limiting. The Relay writes the network-layer source 1748 address of the original packet as the destination address and uses 1749 one of its non link-local addresses as the source address of the 1750 message. 1752 When an AERO node receives an encapsulated packet for which the 1753 reassembly buffer it too small, it drops the packet and returns a 1754 network-layer Packet Too Big (PTB) message. The node first writes 1755 the MRU value into the PTB message MTU field, writes the network- 1756 layer source address of the original packet as the destination 1757 address and writes one of its non link-local addresses as the source 1758 address. 1760 3.15. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1762 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1763 coordinated as discussed in the following Sections. 1765 3.15.1. AERO ND/PD Service Model 1767 Each AERO Server on the link configures a PD service to facilitate 1768 Client requests. Each Server is provisioned with a database of MNP- 1769 to-Client ID mappings for all Clients enrolled in the AERO service, 1770 as well as any information necessary to authenticate each Client. 1771 The Client database is maintained by a central administrative 1772 authority for the AERO link and securely distributed to all Servers, 1773 e.g., via the Lightweight Directory Access Protocol (LDAP) [RFC4511], 1774 via static configuration, etc. Therefore, no Server-to-Server PD 1775 state synchronization is necessary, and Clients can optionally hold 1776 separate PDs for the same MNPs from multiple Servers. Clients can 1777 receive new PDs from new Servers before releasing PDs received from 1778 existing Servers for service continuity. Clients receive the same 1779 service regardless of the Servers they select, although selecting 1780 Servers that are topologically nearby may provide better routing. 1782 AERO Clients and Servers use ND messages to maintain neighbor cache 1783 entries. AERO Servers configure their AERO interfaces as advertising 1784 interfaces, and therefore send unicast RA messages with configuration 1785 information in response to a Client's RS message. Thereafter, 1786 Clients send additional RS messages to refresh prefix and/or router 1787 lifetimes. 1789 AERO Clients and Servers include PD parameters in RS/RA messages to 1790 be used for Prefix Delegation (see [I-D.templin-6man-dhcpv6-ndopt] 1791 for ND/PD alternatives). The unified ND/PD messages are exchanged 1792 between Client and Server according to the prefix management schedule 1793 required by the PD service. If the Client knows its MNP in advance, 1794 it can include its AERO address as the source address of an RS 1795 message and with an SLLAO with a valid Prefix Length for the MNP. If 1796 the Server (and Proxy) accept the Client's MNP assertion, they inject 1797 the prefix into the routing system and establish the necessary 1798 neighbor cache state. 1800 The following sections specify the Client and Server behavior. 1802 3.15.2. AERO Client Behavior 1804 AERO Clients can discover the INET and AERO addresses of AERO Servers 1805 in the MAP list via static configuration (e.g., from a flat-file map 1806 of Server addresses and locations), or through an automated means 1807 such as Domain Name System (DNS) name resolution [RFC1035]. In the 1808 absence of other information, the Client can resolve the DNS Fully- 1809 Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" where 1810 "linkupnetworks" is a constant text string and "[domainname]" is a 1811 DNS suffix for the Client's ANET interface (e.g., "example.com"). 1812 Alternatively, the Client can discover the Server's address through a 1813 multicast RS as described below. 1815 To associate with a Server, the Client acts as a requesting router to 1816 request MNPs. The Client prepares an RS message with PD parameters 1817 (e.g., with an SLLAO with non-zero Prefix Length). If the Client 1818 already knows the Server's AERO address, it includes the AERO address 1819 as the network-layer destination address; otherwise, it includes all- 1820 routers multicast (ff02::2) as the network-layer destination address. 1821 If the Client already knows its own AERO address, it uses the AERO 1822 address as the network-layer source address; otherwise, it uses the 1823 unspecified AERO address (fe80::ffff:ffff) as the network-layer 1824 source address. 1826 The Client next includes an SLLAO in the RS message formatted as 1827 described in Section 3.6 to register its link-layer information with 1828 the Server. The SLLAO corresponding to the ANET interface over which 1829 the Client will send the RS message MUST set the S bit to 1. The 1830 Client MAY include additional SLLAOs specific to other underlying 1831 interfaces, but if so it MUST set their S, Port Number and Link Layer 1832 Address fields to 0. If the Client is connected to an ANET for which 1833 encapsulation is required, the Client finally encapsulates the RS 1834 message in an ANET header with its own ANET address as the source 1835 address and the INET address of the Server as the destination. 1837 The Client then sends the RS message (either via a VPN for VPNed 1838 interfaces, via a Proxy for proxyed interfaces or via the SPAN for 1839 native interfaces) and waits for an RA message reply (see 1840 Section 3.15.3) while retrying up to MAX_RTR_SOLICITATIONS times 1841 until an RA is received. If the Client receives no RAs, or if it 1842 receives an RA with Router Lifetime set to 0, the Client SHOULD 1843 abandon this Server and try another Server. Otherwise, the Client 1844 processes the PD information found in the RA message. 1846 Next, the Client creates a symmetric neighbor cache entry with the 1847 Server's AERO address as the network-layer address and the address in 1848 the first SLLAO as the Server's INET address. The Client records the 1849 RA Router Lifetime field value in the neighbor cache entry as the 1850 time for which the Server has committed to maintaining the MNP in the 1851 routing system. The Client then autoconfigures AERO addresses for 1852 each of the delegated MNPs and assigns them to the AERO interface. 1853 The Client also caches any MSPs included in Route Information Options 1854 (RIOs) [RFC4191] as MSPs to associate with the AERO link, and assigns 1855 the MTU value in the MTU option to its AERO interface while 1856 configuring an appropriate MRU. 1858 The Client then registers additional ANET interfaces with the Server 1859 by sending additional RS messages including SLLAOs via other ANET 1860 interfaces after the initial RS/RA exchange. The Client sends the RS 1861 messages to the Server's AERO address but omits PD parameters since 1862 the initial RS/RA exchange has already established PD state. 1864 The Client examines the X and N bits in the first SLLAO of each RA 1865 message it receives. If the X bit value is 1 the Client infers that 1866 there is a Proxy on the path, and if the N bit value is 1 the Client 1867 infers that there is a NAT on the path. If N is '1', the Client 1868 SHOULD set Port Number and Link-Layer Address to 0 in the first S/ 1869 TLLAO of any subsequent ND messages it sends to the Server over that 1870 link. 1872 Following autoconfiguration, the Client sub-delegates the MNPs to its 1873 attached EUNs and/or the Client's own internal virtual interfaces as 1874 described in [I-D.templin-v6ops-pdhost] to support the Client's 1875 downstream attached "Internet of Things (IoT)". The Client 1876 subsequently maintains its MNP delegations through each of its 1877 Servers by sending additional RS messages with PD parameters before 1878 Router Lifetime expires. 1880 After the Client registers its ANET interfaces, it may wish to change 1881 one or more registrations, e.g., if an ANET interface changes address 1882 or becomes unavailable, if QoS preferences change, etc. To do so, 1883 the Client prepares an RS message to send over any available ANET 1884 interface. The RS MUST include an SLLAO specific to the selected 1885 ANET interface as the first SLLAO and MAY include any additional 1886 SLLAOs specific to other ANET interfaces. The Client includes fresh 1887 'P(i)' values in each SLLAO to update the Server's neighbor cache 1888 entry. If the Client wishes to update only the 'P(i)' values, it 1889 sets the Port Number and Link-Layer Address fields to 0. If the 1890 Client wishes to disable the underlying interface, it sets the D bit 1891 to 1. When the Client receives the Server's RA response, it has 1892 assurance that the Server has been updated with the new information. 1894 If the Client wishes to associate with multiple Servers, it repeats 1895 the same procedures above for each additional Server. If the Client 1896 wishes to discontinue use of a Server it issues an RS message over 1897 any underlying interface with the R bit set to 1 in the first SLLAO. 1899 When the Server processes the message, it releases the MNP, sets the 1900 symmetric neighbor cache entry state for the Client to DEPARTED, 1901 withdraws the IP route from the routing system and returns an RA 1902 reply with Router Lifetime set to 0. 1904 3.15.3. AERO Server Behavior 1906 AERO Servers act as IPv6 routers and support a PD service for 1907 Clients. AERO Servers arrange to add their AERO and INET addresses 1908 to a static map of Server addresses for the link and/or the DNS 1909 resource records for the FQDN "linkupnetworks.[domainname]" before 1910 entering service. The list of Server addresses should be 1911 geographically and/or topologically referenced, and forms the MAP 1912 list for the AERO link. 1914 When an AERO Server receives a prospective Client's RS message with 1915 PD parameters on its AERO interface, it SHOULD return an immediate RA 1916 reply with Router Lifetime set to 0 if it is currently too busy or 1917 otherwise unable to service the Client. Otherwise, the Server 1918 authenticates the RS message and processes the PD parameters. The 1919 Server first determines the correct MNPs to delegate to the Client by 1920 searching the Client database. When the Server delegates the MNPs, 1921 it also creates an IP forwarding table entry for each MNP so that the 1922 MNPs are propagated into the routing system (see: Section 3.3). For 1923 IPv6, the Server creates a single IPv6 forwarding table entry for 1924 each MNP. For IPv4, the Server creates both an IPv4 forwarding table 1925 entry and an IPv6 forwarding table entry with the IPv4-mapped IPv6 1926 address corresponding to the IPv4 address. 1928 The Server next creates a symmetric neighbor cache entry for the 1929 Client using the base AERO address as the network-layer address and 1930 with lifetime set to no more than the smallest PD lifetime. Next, 1931 the Server updates the neighbor cache entry by recording the 1932 information in each SLLAO in the RS indexed by the Interface ID and 1933 including the Port Number, Link Layer Address and P(i) values. For 1934 the SLLAO with S set to 1, however, the Server records the actual 1935 INET header source addresses instead of those that appear in the 1936 SLLAO in case there was a NAT in the path. The Server also records 1937 the value of the X bit to indicate whether there is a Proxy on the 1938 path. 1940 Next, the Server prepares an RA message using its AERO address as the 1941 network-layer source address and the network-layer source address of 1942 the RS message as the network-layer destination address. The Server 1943 includes the delegated MNPs, any other PD parameters and an SLLAO 1944 with the Link Layer Address set to the Server's SPAN address and with 1945 Interface ID set to 0xffff. The Server then includes one or more 1946 RIOs that encode the MSPs for the AERO link, plus an MTU option for 1947 the link MTU (see Section 3.13). The Server finally encapsulates the 1948 message in a SPAN header with source address set to its own SPAN 1949 address and destination address set to the Client's (or Proxy's) SPAN 1950 address, then forwards the message into the SPAN. 1952 After the initial RS/RA exchange, the AERO Server maintains the 1953 symmetric neighbor cache entry for the Client. If the Client (or 1954 Proxy) issues additional NS/RS messages, the Server resets 1955 ReachableTime. If the Client (or Proxy) issues an RS with PD release 1956 parameters (e.g., by including an SLLAO with R set to 1), or if the 1957 Client becomes unreachable, the Server sets the Client's symmetric 1958 neighbor cache entry to the DEPARTED state and withdraws the IP 1959 routes from the AERO routing system. 1961 The Server processes these and any other Client ND/PD messages, and 1962 returns an NA/RA reply. The Server may also issue an unsolicited RA 1963 message with PD reconfigure parameters to cause the Client to 1964 renegotiate its PDs, and may issue an unsolicited RA message with 1965 Router Lifetime set to 0 if it can no longer service this Client. 1966 Finally, If the symmetric neighbor cache entry is in the DEPARTED 1967 state, the Server deletes the entry after DepartTime expires. 1969 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1971 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 1972 Servers are always on the same link (i.e., the AERO link) from the 1973 perspective of DHCPv6. However, in some implementations the DHCPv6 1974 server and ND function may be located in separate modules. In that 1975 case, the Server's AERO interface module can act as a Lightweight 1976 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 1977 the DHCPv6 server module. 1979 When the LDRA receives an authentic RS message, it extracts the PD 1980 message parameters and uses them to construct an IPv6/UDP/DHCPv6 1981 message. It sets the IPv6 source address to the source address of 1982 the RS message, sets the IPv6 destination address to 1983 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 1984 that will be understood by the DHCPv6 server. 1986 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 1987 header and includes an 'Interface-Id' option that includes enough 1988 information to allow the LDRA to forward the resulting Reply message 1989 back to the Client (e.g., the Client's link-layer addresses, a 1990 security association identifier, etc.). The LDRA also wraps the 1991 information in all of the SLLAOs from the RS message into the 1992 Interface-Id option, then forwards the message to the DHCPv6 server. 1994 When the DHCPv6 server prepares a Reply message, it wraps the message 1995 in a 'Relay-Reply' message and echoes the Interface-Id option. The 1996 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1997 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1998 uses the DHCPv6 message to construct an RA response to the Client. 1999 The Server uses the information in the Interface-Id option to prepare 2000 the RA message and to cache the link-layer addresses taken from the 2001 SLLAOs echoed in the Interface-Id option. 2003 3.16. The AERO Proxy 2005 Clients may connect to ANETs that do not support direct 2006 communications to Servers in outside INETs. In that case, the ANET 2007 can employ an AERO Proxy. The Proxy is located at the ANET/INET 2008 border and listens for encapsulated RS messages originating from or 2009 RA messages destined to ANET Clients. The Proxy acts on these 2010 control messages as follows: 2012 o when the Proxy receives an RS message from a new ANET Client, it 2013 first authenticates the message then examines the RS message 2014 network-layer destination address. If the destination address is 2015 a Server's AERO address, the Proxy proceeds to the next step. 2016 Otherwise, if the destination is all-routers multicast the Proxy 2017 selects a "nearby" Server that is likely to be a good candidate to 2018 serve the Client and replaces the RS destination address with the 2019 Server's AERO address. Next, the Proxy creates a proxy neighbor 2020 cache entry and caches the Client and Server addresses along with 2021 any identifying information including Transaction IDs, Client 2022 Identifiers, Nonce values, etc. The Proxy then examines the 2023 address in the RS message SLLAO with S set to 1. If the address 2024 is different than the Client's ANET address, the Proxy notes that 2025 the Client is behind a NAT. The Proxy then sets the X flag in the 2026 SLLAO to 1 and changes the address in the SLLAO to its own SPAN 2027 address. The Proxy finally re-encapsulates the RS message in a 2028 SPAN header using its own SPAN address as the source address and 2029 the SPAN address of the Server as the destination address, then 2030 forwards the message to the Server via the SPAN. 2032 o when the Server receives the RS message, it authenticates the 2033 message then creates or updates a symmetric neighbor cache entry 2034 for the Client with the Proxy's SPAN address as the link-layer 2035 address. The Server then sends an RA message with a single SLLAO 2036 back to the Proxy via the SPAN. 2038 o when the Proxy receives the RA message, it matches the message 2039 with the RS that created the proxy neighbor cache entry. The 2040 Proxy then caches the route information in the message as a 2041 mapping from the Client's MNPs to the Client's ANET address, and 2042 sets the neighbor cache entry state to REACHABLE. The Proxy then 2043 changes the Link Layer Address in the SLLAO to its own ANET 2044 address, re-encapsulates the RA message in an ANET header, sets 2045 the X flag in the SLLAO to 1, sets the N flag in the SLLAO to 1 if 2046 the Client is behind a NAT, and forwards the message to the 2047 Client. 2049 After the initial RS/RA exchange, the Proxy forwards any Client data 2050 packets for which there is no matching asymmetric neighbor cache 2051 entry to a Relay via the SPAN. Finally, the Proxy forwards any 2052 Client data destined to an asymmetric neighbor cache target directly 2053 to the target according to the link-layer information - the process 2054 of establishing asymmetric neighbor cache entries is specified in 2055 Section 3.17. 2057 While the Client is still attached to the ANET, the Proxy continues 2058 to send NS/RS messages to update each Server's symmetric neighbor 2059 cache entries on behalf of the Client and/or to convey QoS updates. 2060 If the Server ceases to send solicited NA/RA responses, the Proxy 2061 marks the Server as unreachable and sends an unsolicited RA with 2062 Router Lifetime set to zero to inform the Client that this Server is 2063 no longer able to provide Service. If the Client becomes 2064 unreachable, the Proxy sets the neighbor cache entry state to 2065 DEPARTED and sends an RS message to each Server with an SLLAO with D 2066 set to 1 and with Interface ID set to the Client's interface ID so 2067 that the Server will de-register this Interface ID. Although the 2068 Proxy engages in these ND exchanges on behalf of the Client, the 2069 Client can also send ND messages on its own behalf, e.g., if it is in 2070 a better position than the Proxy to convey QoS changes, etc. 2072 In some ANETs that employ a Proxy, the Client's MNP can be injected 2073 into the ANET routing system. In that case, the Client can send data 2074 messages without encapsulation so that the ANET native routing system 2075 transports the unencapsulated packets to the Proxy. This can be very 2076 beneficial, e.g., if the Client connects to the ANET via low-end data 2077 links such as some aviation wireless links. This encapsulation 2078 avoidance represents a form of "header compression", meaning that the 2079 MTU should be sized based on the size of full encapsulated messages 2080 even if most messages are sent unencapsulated. 2082 If the first-hop ANET access router is AERO-aware, the Client can 2083 avoid encapsulation for both its control and data messages. When the 2084 Client connects to the link, it can send an unencapsulated RS message 2085 with source address set to its AERO address and with destination 2086 address set to the AERO address of the Client's selected Server or to 2087 all-routers multicast. The Client includes an SLLAO with Interface 2088 ID, Prefix Length and P(i) information but with Port Number and Link- 2089 Layer Address set to 0. 2091 The Client then sends the unencapsulated RS message, which will be 2092 intercepted by the AERO-Aware access router. The access router then 2093 encapsulates the RS message in an ANET header with its own address as 2094 the source address and the address of a Proxy as the destination 2095 address. The access router further remembers the address of the 2096 Proxy so that it can encapsulate future data packets from the Client 2097 via the same Proxy. If the access router needs to change to a new 2098 Proxy, it simply sends another RS message toward the Server via the 2099 new Proxy on behalf of the Client. 2101 In this arrangement, the only control messages sent by the Client are 2102 unencapsulated RS messages with its AERO address as the source 2103 address and the AERO address of the Server as the destination 2104 address. The Client will also receive unencapsulated RA messages 2105 from the Server via both the Proxy and access router. 2107 In some cases, the access router and Proxy may be one and the same 2108 node. In that case, the node would be located on the same physical 2109 link as the Client, but its message exchanges with the Server would 2110 need to pass through a security gateway at the ANET/INET border. The 2111 method for deploying access routers and Proxys (i.e. as a single node 2112 or multiple nodes) is an ANET-local administrative consideration. 2114 3.17. AERO Route Optimization 2116 While data packets are flowing between a source and target node, 2117 route optimization SHOULD be used. Route optimization is initiated 2118 by the first eligible Route Optimization Source (ROS) closest to the 2119 source as follows: 2121 o For Clients on VPNed, NATed and Direct interfaces, the Server is 2122 the ROS. 2124 o For Clients on Proxyed interfaces, the Proxy is the ROS. 2126 o For Clients on native interfaces, the Client itself is the ROS. 2128 o For INET interfaces serviced by a Gateway, the Gateway is the ROS. 2130 The route optimization procedure is conducted between the ROS and a 2131 Route Optimization Responder (ROR) in the same manner as for IPv6 ND 2132 Address Resolution, and using the same NS/NA messaging. The ROR is 2133 the Server (MAP) for MN targets, or the Gateway for FN targets. The 2134 procedures are specified in the following sections. 2136 3.17.1. Route Optimization Initiation 2138 While the data packets are flowing from the source CN toward a target 2139 CN, the ROS also sends an NS message to receive a solicited NA 2140 message from the ROR . 2142 When the ROS sends an NS, it includes the AERO address of the ROS as 2143 the source address (e.g.,fe80::1) and the AERO address corresponding 2144 to the data packet's destination address as the destination address 2145 (e.g., if the destination address is 2001:db8:1:2::1 then the 2146 corresponding AERO address is fe80::2001:db8:1:2). The NS message 2147 includes no SLLAOs, but SHOULD include a Timestamp and Nonce option. 2149 The ROS then encapsulates the message in a SPAN header with source 2150 set to its own SPAN address and destination set to the inner packet 2151 destination, then sends the message into the SPAN without 2152 decrementing the network-layer TTL/Hop Limit field. 2154 3.17.2. Relaying the NS 2156 When the Relay receives the (double-encapsulated) NS message from the 2157 ROS, it discards the outer IP header and determines that the ROR is 2158 the next hop by consulting its standard IP forwarding table for the 2159 SPAN header destination address. The Relay then forwards the SPAN 2160 message toward the ROR the same as for any IP router. The final-hop 2161 Relay in the SPAN will encapsulate the message in an INET header when 2162 it delivers the message to the ROR. 2164 3.17.3. Processing the NS and Sending the NA 2166 When the ROR receives the (double-encapsulated) NS message, it 2167 examines the AERO destination address to determine whether it is the 2168 aggregation point for the target CN; if not, it drops the NS message. 2169 Otherwise, if the target CN is serviced by a Client in the DEPARTED 2170 state the ROR changes the NS message SPAN destination address to the 2171 address of the Client's new Server, re-encapsulates the message in 2172 the appropriate SPAN/INET headers and forwards the message to new 2173 Server. If the target CN is serviced by a Client in the REACHABLE 2174 state the ROR adds the AERO source address to the target Client's 2175 Report List with time set to ReportTime. 2177 For both Servers and Gateways, the ROR next prepares a solicited NA 2178 message to send back to the ROS but does not create a neighbor cache 2179 entry. The ROR sets the NA source address to its own AERO address 2180 and sets the destination address to the AERO address of the ROS. The 2181 NA message includes the Nonce value received in the NS, the current 2182 Timestamp, and a first TLLAO with Interface ID set to 0xffff, with 2183 all P(i) values set to "low", with Prefix Length set to the prefix 2184 length of the target Client's MNP and with Link Layer Address set to 2185 the ROR's SPAN address. 2187 The ROR next includes additional TLLAOs for all of the target 2188 Client's Interface IDs. For NATed, VPNed and Direct interfaces, the 2189 TLLAO Link Layer Addresses are the SPAN address of the ROR. For 2190 Proxyed interfaces, the TLLAO Link Layer Addresses are the SPAN 2191 addresses of the target Client's Proxies, and for native interfaces 2192 the TLLAO Link Layer Addresses are the SPAN addresses of the target 2193 Client. 2195 The ROR finally encapsulates the NA message in a SPAN header with 2196 source set to its own SPAN address and destination set to the source 2197 SPAN address of the NS message, then sends the message into the SPAN 2198 without decrementing the network-layer TTL/Hop Limit field. 2200 3.17.4. Relaying the NA 2202 When the Relay receives the (double-encapsulated) NA message from the 2203 ROR, it discards the INET header and determines that the ROS is the 2204 next hop by consulting its standard IP forwarding table for the SPAN 2205 header destination address. The Relay then forwards the SPAN- 2206 encapsulated NA message toward the ROS the same as for any IP router. 2207 The final-hop Relay in the SPAN will encapsulate the message in an 2208 INET header when it delivers the message to the ROS. 2210 3.17.5. Processing the NA 2212 When the ROS receives the (double-encapsulated) solicited NA message, 2213 it discards the INET and SPAN headers. The ROS next verifies the 2214 Nonce and Timestamp values, then creates an asymmetric neighbor cache 2215 entry for the target Client or Gateway and caches all information 2216 found in the solicited NA TLLAOs. The ROS finally sets the 2217 asymmetric neighbor cache entry lifetime to ReachableTime seconds. 2219 3.17.6. Route Optimization Maintenance 2221 Following route optimization, the ROS forwards future data packets 2222 destined to one of the target's CNs via the addresses found in the 2223 cached link-layer information. The route optimization is shared by 2224 all sources that send packets to the target node via the ROS, i.e., 2225 and not just the source on behalf of which the route optimization was 2226 initiated. 2228 While new data packets destined to one of the target's CNs are 2229 flowing through the ROS, it sends additional NS messages to the ROR 2230 before ReachableTime expires to receive a fresh solicited NA message 2231 the same as described in the previous sections. The ROS then updates 2232 the asymmetric neighbor cache entry to refresh ReachableTime, while 2233 (for target Clients) the ROR adds or updates the ROS address to the 2234 target Client's Report List and with time set to ReportTime. While 2235 no data packets are flowing, the ROS instead allows ReachableTime for 2236 the asymmetric neighbor cache entry to expire. When ReachableTime 2237 expires, the ROS deletes the asymmetric neighbor cache entry. Future 2238 data packets flowing through the ROS will again trigger a new route 2239 optimization exchange while initial data packets travel over a 2240 suboptimal route via Servers and/or Relays. 2242 The ROS may also receive unsolicited NA messages from the ROR at any 2243 time. If there is an asymmetric neighbor cache entry for the target, 2244 the ROS updates the link-layer information but does not update 2245 ReachableTime since the receipt of an unsolicited NA does not confirm 2246 that the forward path is still working. If there is no asymmetric 2247 neighbor cache entry, the route optimization source simply discards 2248 the unsolicited NA. Cases in which unsolicited NA messages are 2249 generated are specified in Section 3.19. 2251 In this arrangement, the ROS holds an asymmetric neighbor cache entry 2252 for the ROR, but the ROR does not hold an asymmetric neighbor cache 2253 entry for the ROS. The route optimization neighbor relationship is 2254 therefore asymmetric and unidirectional. If the target node also has 2255 packets to send back to the source node, then a separate route 2256 optimization procedure is required in the reverse direction. But, 2257 there is no requirement that the forward and reverse paths be 2258 symmetric. 2260 3.18. Neighbor Unreachability Detection (NUD) 2262 AERO nodes perform Neighbor Unreachability Detection (NUD) as 2263 described in [RFC4861]. NUD is performed either reactively in 2264 response to persistent link-layer errors (see Section 3.14) or 2265 proactively to confirm bi-directional reachability. The NUD 2266 algorithm may further be seeded by ND hints of forward progress, but 2267 care must be taken to avoid inferring reachability based on spoofed 2268 information. 2270 When an ROR directs an ROS to one or more target link-layer 2271 addresses, the ROS SHOULD proactively test the direct path to each 2272 address by sending an initial NS message to elicit a solicited NA 2273 response. While testing the path, the ROS can optionally continue 2274 sending packets via its default router, maintain a small queue of 2275 packets until target reachability is confirmed, or (optimistically) 2276 allow packets to flow directly to the target. 2278 AERO nodes may have multiple link-layer addresses for the target 2279 neighbor. In that case, NUD SHOULD be performed over each address 2280 individually, and the source node should only consider the neighbor 2281 unreachable if NUD fails over multiple underlying interface paths. 2283 When a source node sends an NS message used for NUD, it uses its AERO 2284 addresses as the IPv6 source address and the AERO address 2285 corresponding to each target link-layer address as the destination. 2286 For each target link-layer address, if the address is not located 2287 within the same AERO link segment the source node encapsulates the NS 2288 message in a SPAN header with its own SPAN address as the source and 2289 the SPAN address of the target as the destination, then forwards the 2290 message into the SPAN. If the target address is located within the 2291 same segment, however, the source node omits the SPAN header and 2292 encapsulates the message in an INET header with is own INET address 2293 as the source and the INET address of the target as the destination, 2294 then sends the message directly to the target. 2296 Paths that pass NUD tests are marked as "reachable", while those that 2297 do not are marked as "unreachable". These markings inform the AERO 2298 interface forwarding algorithm specified in Section 3.9. 2300 Proxies can perform NUD to verify Server reachability on behalf of 2301 their proxyed Clients so that the Clients need not engage in NUD 2302 messaging themselves. 2304 3.19. Mobility Management and Quality of Service (QoS) 2306 AERO is a Distributed Mobility Management (DMM) service. Each Server 2307 is responsible for only a subset of the Clients on the AERO link, as 2308 opposed to a Centralized Mobility Management (CMM) service where 2309 there is a single network mobility service for all Clients. Clients 2310 coordinate with their associated Servers via RS/RA exchanges to 2311 maintain the DMM profile, and the AERO routing system tracks all 2312 current Client/Server peering relationships. 2314 Servers provide a Mobility Anchor Point (MAP) for their dependent 2315 Clients. Clients are responsible for maintaining neighbor 2316 relationships with their Servers through periodic RS/RA exchanges, 2317 which also serves to confirm neighbor reachability. When a Client's 2318 underlying interface address and/or QoS information changes, the 2319 Client is responsible for updating the Server with this new 2320 information. Note that for Proxyed interfaces, however, the Proxy 2321 can perform the RS/RA exchanges on the Client's behalf. 2323 Mobility management considerations are specified in the following 2324 sections. 2326 3.19.1. Mobility Update Messaging 2328 RORs (i.e., Servers acting as MAPs) accommodate mobility and/or QoS 2329 change events by sending an unsolicited NA message to each ROS in the 2330 target Client's Report List. When an ROR sends an unsolicited NA 2331 message, it sets the IPv6 source address to the Client's AERO address 2332 and sets the IPv6 destination address to all-nodes multicast 2333 (ff02::1). The ROR also includes a TLLAO with Interface ID 0xffff 2334 with Link Layer address set to the ROR's SPAN address, and includes 2335 additional TLLAOs for all of the target Client's Interface IDs with 2336 Link Layer Address set to the corresponding SPAN addresses. The ROR 2337 finally encapsulates the message in a SPAN header with source set to 2338 its own SPAN address and destination set to the SPAN address of the 2339 ROS, then sends the message into the SPAN. 2341 As for the hot-swap of interface cards discussed in Section 7.2.6 of 2342 [RFC4861], the transmission and reception of unsolicited NA messages 2343 is unreliable but provides a useful optimization. In well-connected 2344 Internetworks with robust data links unsolicited NA messages will be 2345 delivered with high probability, but in any case the ROR can 2346 optionally send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to 2347 each ROS to increase the likelihood that at least one will be 2348 received. 2350 When an ROS receives an unsolicited NA message, it ignores the 2351 message if there is no existing neighbor cache entry for the Client. 2352 Otherwise, it uses the included TLLAOs to update the address and QoS 2353 information in the neighbor cache entry, but does not reset 2354 ReachableTime since the receipt of an unsolicited NA message from the 2355 target Server does not provide confirmation that any forward paths to 2356 the target Client are working. 2358 If unsolicited NA messages are lost, the ROS may be left with stale 2359 address and/or QoS information for the Client for up to ReachableTime 2360 seconds. During this time, the ROS can continue sending packets to 2361 the target Client according to its current neighbor cache information 2362 but may receive persistent unsolicited NA messages as discussed in 2363 Section 3.19.2. 2365 3.19.2. Forwarding Packets on Behalf of Departed Clients 2367 When a Server receives packets with destination addresses that match 2368 a symmetric neighbor cache entry in the DEPARTED state, it forwards 2369 the packets to the SPAN address corresponding to the Client's new 2370 Server. If the encapsulation source is in the Report List, the 2371 Server also sends an unsolicited NA message via the SPAN (subject to 2372 rate limiting) with a TLLAO with Interface ID 0xffff and with D set 2373 to 1. The ROS will then realize that it needs to set its asymmetric 2374 neighbor cache entry state for the target to DEPARTED, and SHOULD re- 2375 initiate route optimization after a short delay. 2377 When a Proxy receives packets with destination addresses that match a 2378 proxy neighbor cache entry in the DEPARTED state, it forwards the 2379 packets to one of the target Client's Servers. If the encapsulation 2380 source is not one of its proxy neighbor Clients, the Proxy also 2381 returns an unsolicited NA message via the SPAN (subject to rate 2382 limiting) with a single TLLAO with the target Client's Interface ID 2383 and with D set to 1. The source will then realize that it needs to 2384 mark its neighbor cache entry Interface ID for the Proxy as 2385 "unreachable", and SHOULD re-initiate route optimization while 2386 continuing to forward packets according to the remaining neighbor 2387 cache entry state. 2389 When a Client receives packets with destination addresses that do not 2390 match one of its MNPs, it drops the packets silently. 2392 3.19.3. Announcing Link-Layer Address and/or QoS Preference Changes 2394 When a Client needs to change its ANET addresses and/or QoS 2395 preferences (e.g., due to a mobility event), either the Client or 2396 Proxy sends RS messages to its Servers via the SPAN with SLLAOs that 2397 include the new Client Port Number, Link Layer Address and P(i) 2398 values. If the RS messages are sent solely for the purpose of 2399 updating QoS preferences, S, Port Number and Link-Layer Address are 2400 set to 0. If the RS message is not sent for the purpose of asserting 2401 a PD, the Prefix Length is set to 0. 2403 Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with 2404 sending actual data packets in case one or more RAs are lost. If all 2405 RAs are lost, the Client SHOULD re-associate with a new Server. 2407 3.19.4. Bringing New Links Into Service 2409 When a Client needs to bring new ANET interfaces into service (e.g., 2410 when it activates a new data link), it sends RS messages to its 2411 Servers via the ANET interface with SLLAOs that include the new 2412 Client Link Layer Address information. If the RS message is not sent 2413 for the purpose of asserting a PD, the Prefix Length is set to 0. 2415 3.19.5. Removing Existing Links from Service 2417 When a Client needs to remove existing ANET interfaces from service 2418 (e.g., when it de-activates an existing data link), it sends RS 2419 messages to its Servers with SLLAOs with the D flag set to 1. 2421 If the Client needs to send RS messages over an ANET interface other 2422 than the one being removed from service, it MUST include a current 2423 SLLAO for the sending interface as the first SLLAO and include SLLAOs 2424 for any ANET interfaces being removed from service as additional 2425 SLLAOs. 2427 3.19.6. Implicit Mobility Management 2429 AERO interface neighbors MAY provide a configuration option that 2430 allows them to perform implicit mobility management in which no ND 2431 messaging is used. In that case, the Client only transmits packets 2432 over a single interface at a time, and the neighbor always observes 2433 packets arriving from the Client from the same link-layer source 2434 address. 2436 If the Client's ANET interface address changes (either due to a 2437 readdressing of the original interface or switching to a new 2438 interface) the neighbor immediately updates the neighbor cache entry 2439 for the Client and begins accepting and sending packets according to 2440 the Client's new ANET address. This implicit mobility method applies 2441 to use cases such as cellphones with both WiFi and Cellular 2442 interfaces where only one of the interfaces is active at a given 2443 time, and the Client automatically switches over to the backup 2444 interface if the primary interface fails. 2446 3.19.7. Moving to a New Server 2448 When a Client associates with a new Server, it performs the Client 2449 procedures specified in Section 3.15.2. The Client then sends an RS 2450 message over any working ANET interface with destination set to the 2451 old Server's AERO address, with R set to 1 in the first SLLAO and 2452 with PD parameters to fully release itself from the old Server. The 2453 SLLAO also includes the SPAN address of the new Server in the Link 2454 Layer Address. If the Client does not receive an RA reply after 2455 MAX_RTR_SOLICITATIONS attempts over multiple underlying interfaces, 2456 the old Server may have failed and the Client should discontinue its 2457 release attempts. 2459 When the old Server processes the RS, it sends unsolicited NA 2460 messages with a single TLLAO with Interface ID set to 0xffff and with 2461 D set to 1 to all ROSs in the Client's Report List. The Server also 2462 changes the symmetric neighbor cache entry state to DEPARTED, sets 2463 the link-layer address of the Client to the address found in the RS 2464 SLLAO, and sets a timer to DepartTime seconds. The Server then 2465 returns an RA message to the Client with Router Lifetime set to 0. 2466 After DepartTime seconds expires, the Server deletes the symmetric 2467 neighbor cache entry. 2469 When the Client receives the RA message with Router Lifetime set to 2470 0, it still must inform each of its remaining Proxies that it has 2471 released the old Server from service. To do so, it sends an RS over 2472 each remaining proxyed ANET interface with destination set to the old 2473 Server's AERO address and with R set to 1 in the first SLLAO but with 2474 no PD parameters. The Proxy will mark this Server as DEAPARTED and 2475 return an immediate RA without first performing an RS/RA exchange 2476 with the old Server. 2478 Clients SHOULD NOT move rapidly between Servers in order to avoid 2479 causing excessive oscillations in the AERO routing system. Examples 2480 of when a Client might wish to change to a different Server include a 2481 Server that has gone unreachable, topological movements of 2482 significant distance, movement to a new geographic region, movement 2483 to a new segment, etc. 2485 3.20. Multicast 2487 The AERO Client serves as an IGMPv2 (IPv4) [RFC2236] or MLDv2 (IPv6) 2488 proxy [RFC3810][RFC4605] for its EUNs and/or hosted applications. 2489 The Client forwards IGMPv2/MLDv2 messages over any of its ANET 2490 interfaces for which group membership is required. The IGMP/MLDv2 2491 messages may be further forwarded by a first-hop ANET access router 2492 acting as an IGMPv2/MLDv2-snooping switch [RFC4541], then ultimately 2493 delivered to an AERO Proxy/Server acting as a Protocol Independent 2494 Multicast - Sparse-Mode (PIM-SM) router [RFC7761]. AERO Gateways act 2495 as PIM-SM routers the same as AERO Proxys/Servers, except that no 2496 IGMPv2/MLDv2 proxying/snooping are necessary on the Gateway's 2497 attached EUNs. 2499 When an AERO Proxy/Server/Gateway "X" acting as a PIM-SM router 2500 receives a Source-Specific Multicast (SSM) "Join" message for source 2501 "S" and group "G" (i.e., (S,G)), it forwards the message to a Relay 2502 via the SPAN. The SPAN then forwards the message to AERO Server "Y" 2503 which forwards the message to Proxy "Z" that services "S" (note that 2504 when "Y" is a Gateway there is no need for Proxy "Z".) Since the 2505 Relays in the SPAN do not examine Layer 3 control messages, this 2506 means that the (reverse) multicast tree path is simply from "S" to 2507 "Z" to "Y" to "X" with no other Layer 3 multicast-aware routers in 2508 the path. If "Z", "Y" and "X" are located on the same SPAN segment, 2509 the multicast data traffic between them can be sent via simple INET 2510 encapsulation and need not go over the SPAN. If any of "Z", "Y" and 2511 X" are located in different SPAN segments, however, SPAN 2512 encapsulation is necessary. 2514 When an AERO Proxy/Server/Gateway "X" acting as a PIM-SM router 2515 receives an Any Source Multicast (ASM) "Join" message for source "*" 2516 and group "G" (i.e., (*,G)), it forwards the message toward the 2517 Rendezvous Point "RP" for group "G" the same as if "RP" was the 2518 source "S". The (reverse) multicast tree path is therefore 2519 established in the same way as above. 2521 After the (reverse) multicast tree path has been established via AERO 2522 Proxy "Z", the AERO Client "C" that hosts "S" may move to a different 2523 Proxy "Z2". In that case, the Client's multicast Server "Y" sends a 2524 PIM-SM "Join" to the new Proxy "Z2" for each multicast group "G", 2525 then sends a PIM-SM "Prune" to the old Proxy "Z". 2527 After the (reverse) multicast tree path has been established, the 2528 AERO Client "C" may move to a different Server "Y2". In that case, 2529 the old Server "Y" must transfer its multicast tree state for all of 2530 Client "C"'s multicast sources to the new Server "Y2", and "Y2" must 2531 issue PIM-SM "Join" messages for each of Client "C"'s new Proxys. 2533 4. Direct Underlying Interfaces 2535 When a Client's AERO interface is configured over a Direct interface, 2536 the neighbor at the other end of the Direct link can receive packets 2537 without any encapsulation. In that case, the Client sends packets 2538 over the Direct link according to QoS preferences. If the Direct 2539 interface has the highest QoS preference, then the Client's IP 2540 packets are transmitted directly to the peer without going through an 2541 ANET/INET. If other interfaces have higher QoS preferences, then the 2542 Client's IP packets are transmitted via a different interface, which 2543 may result in the inclusion of Proxies, Servers and Relays in the 2544 communications path. Direct interfaces must be tested periodically 2545 for reachability, e.g., via NUD. 2547 5. AERO Clients on the Open Internetwork 2549 AERO Clients that connect to the open Internetwork via either a 2550 native or NATed interface can establish a VPN to securely connect to 2551 a Server. Alternatively, the Client can exchange ND messages 2552 directly with other AERO nodes on the same Internetwork using INET 2553 encapsulation only and without joining the SPAN. In that case, 2554 however, the Client must apply asymmetric security for ND messages to 2555 ensure routing and neighbor cache integrity (see: Section 14). 2557 6. Operation over Multiple AERO Links 2559 An AERO Client can connect to mutliple AERO links the same as for any 2560 Layer 2 service. In that case, the Client maintains a distinct AERO 2561 interface for each link, e.g., 'aero0' for the first link, 'aero1' 2562 for the second, 'aero2' for the third, etc. Each AERO link would 2563 include its own distinct set of Relays, Servers and Proxies, thereby 2564 providing redundancy in case of failures. Each AERO link would 2565 service a distinct MSP such that the Client would receive multiple 2566 MNP delegations - one for each link. 2568 The Relays, Servers and Proxies on each AERO link can assign AERO and 2569 SPAN addresses that use the same or different numberings from those 2570 on other links. Since the links are distinct there is no requirement 2571 for avoiding inter-link address duplication, e.g., the same AERO 2572 address such as fe80::1000 could be used to number distinct nodes 2573 that connect to different links. 2575 Each AERO link could utilize the same or different ANET connections. 2576 The links can be distinguished at the link-layer via Virtual Local 2577 Area Network (VLAN) tagging the same as definied in IEEE 802.1Q. 2578 This gives rise to the opportunity for supporting multiple redundant 2579 networked paths, where each VLAN is distinguished by a different 2580 label (e.g., colors such as Red, Green, Blue, etc.). In particular, 2581 the Client can tag its RS messages with the appropriate label to 2582 cause the network to select the desired VLAN. 2584 7. Operation on AERO Links with /64 ASPs 2586 IPv6 AERO links typically have MSPs that cover many candidate MNPs of 2587 length /64 or shorter. However, in some cases it may be desirable to 2588 use AERO over links that have only a /64 MSP. This can be 2589 accommodated by treating all Clients on the AERO link as simple hosts 2590 that receive /128 prefix delegations. 2592 In that case, the Client sends an RS message to the Server the same 2593 as for ordinary AERO links. The Server responds with an RA message 2594 that includes one or more /128 prefixes (i.e., singleton addresses) 2595 that include the /64 MSP prefix along with an interface identifier 2596 portion to be assigned to the Client. The Client and Server then 2597 configure their AERO addresses based on the interface identifier 2598 portions of the /128s (i.e., the lower 64 bits) and not based on the 2599 /64 prefix (i.e., the upper 64 bits). 2601 For example, if the MSP for the host-only IPv6 AERO link is 2602 2001:db8:1000:2000::/64, each Client will receive one or more /128 2603 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2604 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2605 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2606 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2607 /128s) to either the AERO interface or an internal virtual interface 2608 such as a loopback. In this arrangement, the Client conducts route 2609 optimization in the same sense as discussed in Section 3.17. 2611 This specification has applicability for nodes that act as a Client 2612 on an "upstream" AERO link, but also act as a Server on "downstream" 2613 AERO links. More specifically, if the node acts as a Client to 2614 receive a /64 prefix from the upstream AERO link it can then act as a 2615 Server to provision /128s to Clients on downstream AERO links. 2617 8. AERO Adaptations for SEcure Neighbor Discovery (SEND) 2619 SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically 2620 Generated Addresses (CGAs) [RFC3972] were designed to secure IPv6 ND 2621 messaging in environments where symmetric network and/or transport- 2622 layer security services are impractical (see: Section 14). AERO 2623 nodes that use SEND/CGA employ the following adaptations. 2625 When a source AERO node prepares a SEND-protected ND message, it uses 2626 a link-local CGA as the IPv6 source address and writes the prefix 2627 embedded in its AERO address (i.e., instead of fe80::/64) in the CGA 2628 parameters Subnet Prefix field. When the neighbor receives the ND 2629 message, it first verifies the message checksum and SEND/CGA 2630 parameters while using the link-local prefix fe80::/64 (i.e., instead 2631 of the value in the Subnet Prefix field) to match against the IPv6 2632 source address of the ND message. 2634 The neighbor then derives the AERO address of the source by using the 2635 value in the Subnet Prefix field as the interface identifier of an 2636 AERO address. For example, if the Subnet Prefix field contains 2637 2001:db8:1:2, the neighbor constructs the AERO address as 2638 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 2639 neighbor cache entry it creates for the source, and uses the AERO 2640 address as the IPv6 destination address of any ND message replies. 2642 9. AERO Critical Infrastructure Considerations 2644 AERO Relays can be either Commercial off-the Shelf (COTS) standard IP 2645 routers or virtual machines in the cloud. Relays must be 2646 provisioned, supported and managed by the INET administrative 2647 authority, and connected to the Relays of other INETs via inter- 2648 domain peerings. Cost for purchasing, configuring and managing 2649 Relays is nominal even for very large AERO links. 2651 AERO Servers can be standard dedicated server platforms, but most 2652 often will be deployed as virtual machines in the cloud. The only 2653 requirements for Servers are that they can run the AERO user-level 2654 code and have at least one network interface connection to the INET. 2655 As with Relays, Servers must be provisioned, supported and managed by 2656 the INET administrative authority. Cost for purchasing, configuring 2657 and managing Servers is nominal especially for virtual Servers hosted 2658 in the cloud. 2660 AERO Proxies are most often standard dedicated server platforms with 2661 one network interface connected to the ANET and a second interface 2662 connected to an INET. As with Servers, the only requirements are 2663 that they can run the AERO user-level code and have at least one 2664 interface connection to the INET. Proxies must be provisioned, 2665 supported and managed by the ANET administrative authority. Cost for 2666 purchasing, configuring and managing Proxies is nominal, and borne by 2667 the ANET administrative authority. 2669 AERO combined Client/Servers can be any dedicated server or COTS 2670 router platform with one network interface connected to the INET and 2671 a second interface connected to a downstream attached network. The 2672 Client/Server joins the SPAN over the INET interface and engages in 2673 eBGP peering with one or more Relays as a stub AS. The Client/Server 2674 then injects its MNP into the BGP routing system, and provisions the 2675 MNP to its downstream-attached networks. No Client/Server ND 2676 messaging is necessary, and the Client/Server can perform ROS and ROR 2677 services the same as for any Server. The combined Client/Server 2678 construct is useful for connecting large fixed networks to the AERO 2679 link. 2681 10. DNS Considerations 2683 AERO Client MNs and INET correspondent nodes consult the Domain Name 2684 System (DNS) the same as for any Internetworking node. When 2685 correspondent nodes and Client MNs use different IP protocol versions 2686 (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain 2687 A records for IPv4 address mappings to MNs which must then be 2688 populated in Gateway NAT64 mapping caches. In that way, an IPv4 2689 correspondent node can send packets to the IPv4 address mapping of 2690 the target MN, and the Gateway will translate the IPv4 header and 2691 destination address into an IPv6 header and IPv6 destination address 2692 of the MN. 2694 When an AERO Client registers with an AERO Server, the Server returns 2695 the address(es) of DNS servers in RDNSS options [RFC6106]. The DNS 2696 Server provides the IP addresses of other MNs and correspondent nodes 2697 in AAAA records for IPv6 or A records for IPv4. 2699 11. Transition Considerations 2701 The SPAN ensures that dissimilar INET segments can be joined into a 2702 single unified AERO link, even though the INET segments themselves 2703 may have differing protocol versions and/or incompatible addressing 2704 plans. However, a commonality can be achieved by incrementally 2705 distributing MNP prefixes to eventually reach all nodes (both mobile 2706 and fixed) in all segments. This can be accomplished by 2707 incrementally deploying AERO Gateways on each INET segment, with each 2708 Gateway distributing its MNPs to its downstream-attached INET links. 2710 This gives rise to the opportunity to eventually distribute MNP-based 2711 addresses to all nodes, and to present a unified AERO link view 2712 (bridged by the SPAN) even if the INET segments remain in their 2713 current protocol and addressing plans. In that way, the AERO link 2714 can serve the dual purpose of providing a mobility service and a 2715 transition service. Or, if an INET segment is transitioned to a 2716 protocol version and addressing scheme that is compatible with the 2717 AERO link MNP-based addressing scheme, the NET segment and AERO link 2718 can be joined by standard routers. 2720 12. Implementation Status 2722 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2723 announced on the v6ops mailing list on January 10, 2018. The latest 2724 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2725 2.0.tgz. 2727 An initial public release of the AERO proof-of-concept source code 2728 was announced on the intarea mailing list on August 21, 2015. The 2729 latest version is available at: http://linkupnetworks.net/aero/aero- 2730 4.0.0.tgz. 2732 A survey of public domain and commercial SEND implementations is 2733 available at https://www.ietf.org/mail-archive/web/its/current/ 2734 msg02758.html. 2736 13. IANA Considerations 2738 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2739 AERO in the "enterprise-numbers" registry. 2741 The IANA has assigned the UDP port number "8060" for an earlier 2742 experimental version of AERO [RFC6706]. This document obsoletes 2743 [RFC6706] and claims the UDP port number "8060" for all future use. 2745 No further IANA actions are required. 2747 14. Security Considerations 2749 AERO link security considerations include considerations for both the 2750 data plane and the control plane. 2752 Data plane security considerations are the same as for ordinary 2753 Internet communications. Application endpoints in AERO Clients and 2754 their EUNs SHOULD use application-layer security services such as 2755 TLS/SSL [RFC8446], DTLS [RFC6347] or SSH [RFC4251] to assure the same 2756 level of protection as for critical secured Internet services. AERO 2757 Clients that require host-based VPN services SHOULD use symmetric 2758 network and/or transport layer security services such as TLS/SSL, 2759 DTLS, IPsec [RFC4301], etc. AERO Proxies and Servers can also 2760 provide a network-based VPN service on behalf of the Client, e.g., if 2761 the Client is located within a secured enclave and cannot establish a 2762 VPN on its own behalf. 2764 Control plane security considerations are the same as for standard 2765 IPv6 Neighbor Discovery [RFC4861]. As fixed infrastructure elements, 2766 AERO Servers/Gateways and Proxies SHOULD pre-configure security 2767 associations for one or more Relays on their SPAN segments (e.g., 2768 using pre-placed keys) and use symmetric network and/or transport 2769 layer security services such as IPsec, TLS/SSL or DTLS to secure ND 2770 messages. The AERO Relays of all SPAN segments in turn SHOULD pre- 2771 configure security associations for their neighboring AERO Relays. 2772 AERO Clients that connect to secured enclaves need not apply security 2773 to their ND messages, since the messages will be intercepted by an 2774 enclave perimeter Proxy. AERO Clients located outside of secured 2775 enclaves SHOULD use symmetric network and/or transport layer security 2776 to secure their ND exchanges with Servers, but when there are many 2777 prospective neighbors with dynamically changing connectivity an 2778 asymmetric security service such as SEND may be needed (see: 2779 Section 8). 2781 AERO Servers/Gateways and Relays present targets for traffic 2782 amplification Denial of Service (DoS) attacks. This concern is no 2783 different than for widely-deployed VPN security gateways in the 2784 Internet, where attackers could send spoofed packets to the gateways 2785 at high data rates. This can be mitigated by connecting Servers/ 2786 Gateways and Relays over dedicated links with no connections to the 2787 Internet and/or when connections to the Internet are only permitted 2788 through well-managed firewalls. Traffic amplification DoS attacks 2789 can also target an AERO Client's low data rate links. This is a 2790 concern not only for Clients located on the open Internet but also 2791 for Clients in secured enclaves. AERO Servers/Gateways and Proxies 2792 can institute rate limits that protect Clients from receiving packet 2793 floods that could DoS low data rate links. 2795 AERO Relays must implement ingress filtering to avoid a spoofing 2796 attack in which spurious SPAN messages are injected into an AERO link 2797 from an outside attacker. Restricting access to the link can be 2798 achieved by having Internetwork border routers implement ingress 2799 filtering to discard encapsulated packets injected into the link by 2800 an outside agent. 2802 AERO Clients MUST ensure that their connectivity is not used by 2803 unauthorized nodes on their EUNs to gain access to a protected 2804 network, i.e., AERO Clients that act as routers MUST NOT provide 2805 routing services for unauthorized nodes. (This concern is no 2806 different than for ordinary hosts that receive an IP address 2807 delegation but then "share" the address with other nodes via some 2808 form of Internet connection sharing such as tethering.) 2810 The MAP list MUST be well-managed and secured from unauthorized 2811 tampering, even though the list contains only public information. 2812 The MAP list can be conveyed to the Client, e.g., through secure 2813 upload of a static file, through DNS lookups, etc. 2815 Although public domain and commercial SEND implementations exist, 2816 concerns regarding the strength of the cryptographic hash algorithm 2817 have been documented [RFC6273] [RFC4982]. 2819 Security considerations for accepting link-layer ICMP messages and 2820 reflected packets are discussed throughout the document. 2822 15. Acknowledgements 2824 Discussions in the IETF, aviation standards communities and private 2825 exchanges helped shape some of the concepts in this work. 2826 Individuals who contributed insights include Mikael Abrahamsson, Mark 2827 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2828 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2829 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2830 Hlusiak, Lee Howard, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy 2831 Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru 2832 Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, 2833 Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members 2834 of the IESG also provided valuable input during their review process 2835 that greatly improved the document. Special thanks go to Stewart 2836 Bryant, Joel Halpern and Brian Haberman for their shepherding 2837 guidance during the publication of the AERO first edition. 2839 This work has further been encouraged and supported by Boeing 2840 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2841 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2842 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2843 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Greg 2844 Saccone, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan 2845 Williams, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 2846 BR&T and BIT mobile networking teams. Kyle Bae, Wayne Benson and 2847 Eric Yeh are especially acknowledged for implementing the AERO 2848 functions as extensions to the public domain OpenVPN distribution. 2850 Earlier works on NBMA tunneling approaches are found in 2851 [RFC2529][RFC5214][RFC5569]. 2853 Many of the constructs presented in this second edition of AERO are 2854 based on the author's earlier works, including: 2856 o The Internet Routing Overlay Network (IRON) 2857 [RFC6179][I-D.templin-ironbis] 2859 o Virtual Enterprise Traversal (VET) 2860 [RFC5558][I-D.templin-intarea-vet] 2862 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2863 [RFC5320][I-D.templin-intarea-seal] 2865 o AERO, First Edition [RFC6706] 2867 Note that these works cite numerous earlier efforts that are not also 2868 cited here due to space limitations. The authors of those earlier 2869 works are acknowledged for their insights. 2871 This work is aligned with the NASA Safe Autonomous Systems Operation 2872 (SASO) program under NASA contract number NNA16BD84C. 2874 This work is aligned with the FAA as per the SE2025 contract number 2875 DTFAWA-15-D-00030. 2877 This work is aligned with the Boeing Information Technology (BIT) 2878 MobileNet program. 2880 This work is aligned with the Boeing autonomy program. 2882 16. References 2884 16.1. Normative References 2886 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2887 DOI 10.17487/RFC0791, September 1981, 2888 . 2890 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2891 RFC 792, DOI 10.17487/RFC0792, September 1981, 2892 . 2894 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2895 Requirement Levels", BCP 14, RFC 2119, 2896 DOI 10.17487/RFC2119, March 1997, 2897 . 2899 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2900 "Definition of the Differentiated Services Field (DS 2901 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2902 DOI 10.17487/RFC2474, December 1998, 2903 . 2905 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2906 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2907 DOI 10.17487/RFC3971, March 2005, 2908 . 2910 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2911 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2912 . 2914 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2915 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2916 November 2005, . 2918 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2919 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2920 DOI 10.17487/RFC4861, September 2007, 2921 . 2923 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2924 Address Autoconfiguration", RFC 4862, 2925 DOI 10.17487/RFC4862, September 2007, 2926 . 2928 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2929 (IPv6) Specification", STD 86, RFC 8200, 2930 DOI 10.17487/RFC8200, July 2017, 2931 . 2933 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2934 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2935 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2936 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2937 . 2939 16.2. Informative References 2941 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2942 2016. 2944 [I-D.ietf-dmm-distributed-mobility-anchoring] 2945 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 2946 "Distributed Mobility Anchoring", draft-ietf-dmm- 2947 distributed-mobility-anchoring-13 (work in progress), 2948 March 2019. 2950 [I-D.ietf-intarea-gue] 2951 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2952 Encapsulation", draft-ietf-intarea-gue-07 (work in 2953 progress), March 2019. 2955 [I-D.ietf-intarea-gue-extensions] 2956 Herbert, T., Yong, L., and F. Templin, "Extensions for 2957 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2958 extensions-06 (work in progress), March 2019. 2960 [I-D.ietf-intarea-tunnels] 2961 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2962 Architecture", draft-ietf-intarea-tunnels-09 (work in 2963 progress), July 2018. 2965 [I-D.ietf-rtgwg-atn-bgp] 2966 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2967 Moreno, "A Simple BGP-based Mobile Routing System for the 2968 Aeronautical Telecommunications Network", draft-ietf- 2969 rtgwg-atn-bgp-01 (work in progress), January 2019. 2971 [I-D.templin-6man-dhcpv6-ndopt] 2972 Templin, F., "A Unified Stateful/Stateless Configuration 2973 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07 2974 (work in progress), December 2018. 2976 [I-D.templin-intarea-grefrag] 2977 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2978 templin-intarea-grefrag-04 (work in progress), July 2016. 2980 [I-D.templin-intarea-seal] 2981 Templin, F., "The Subnetwork Encapsulation and Adaptation 2982 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2983 progress), January 2014. 2985 [I-D.templin-intarea-vet] 2986 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2987 templin-intarea-vet-40 (work in progress), May 2013. 2989 [I-D.templin-ironbis] 2990 Templin, F., "The Interior Routing Overlay Network 2991 (IRON)", draft-templin-ironbis-16 (work in progress), 2992 March 2014. 2994 [I-D.templin-v6ops-pdhost] 2995 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 2996 Models", draft-templin-v6ops-pdhost-23 (work in progress), 2997 December 2018. 2999 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 3001 [RFC1035] Mockapetris, P., "Domain names - implementation and 3002 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3003 November 1987, . 3005 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3006 Communication Layers", STD 3, RFC 1122, 3007 DOI 10.17487/RFC1122, October 1989, 3008 . 3010 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3011 DOI 10.17487/RFC1191, November 1990, 3012 . 3014 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 3015 RFC 1812, DOI 10.17487/RFC1812, June 1995, 3016 . 3018 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 3019 DOI 10.17487/RFC2003, October 1996, 3020 . 3022 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3023 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 3024 . 3026 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3027 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 3028 December 1998, . 3030 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3031 Domains without Explicit Tunnels", RFC 2529, 3032 DOI 10.17487/RFC2529, March 1999, 3033 . 3035 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 3036 Malis, "A Framework for IP Based Virtual Private 3037 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 3038 . 3040 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 3041 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 3042 DOI 10.17487/RFC2784, March 2000, 3043 . 3045 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 3046 RFC 2890, DOI 10.17487/RFC2890, September 2000, 3047 . 3049 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 3050 RFC 2923, DOI 10.17487/RFC2923, September 2000, 3051 . 3053 [RFC2983] Black, D., "Differentiated Services and Tunnels", 3054 RFC 2983, DOI 10.17487/RFC2983, October 2000, 3055 . 3057 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3058 of Explicit Congestion Notification (ECN) to IP", 3059 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3060 . 3062 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 3063 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 3064 DOI 10.17487/RFC3810, June 2004, 3065 . 3067 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 3068 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 3069 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 3070 RFC 3819, DOI 10.17487/RFC3819, July 2004, 3071 . 3073 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 3074 for IPv6 Hosts and Routers", RFC 4213, 3075 DOI 10.17487/RFC4213, October 2005, 3076 . 3078 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 3079 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 3080 January 2006, . 3082 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 3083 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3084 DOI 10.17487/RFC4271, January 2006, 3085 . 3087 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3088 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3089 2006, . 3091 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3092 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3093 December 2005, . 3095 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 3096 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 3097 2006, . 3099 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3100 Control Message Protocol (ICMPv6) for the Internet 3101 Protocol Version 6 (IPv6) Specification", STD 89, 3102 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3103 . 3105 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3106 Protocol (LDAP): The Protocol", RFC 4511, 3107 DOI 10.17487/RFC4511, June 2006, 3108 . 3110 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 3111 "Considerations for Internet Group Management Protocol 3112 (IGMP) and Multicast Listener Discovery (MLD) Snooping 3113 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 3114 . 3116 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3117 "Internet Group Management Protocol (IGMP) / Multicast 3118 Listener Discovery (MLD)-Based Multicast Forwarding 3119 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 3120 August 2006, . 3122 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3123 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 3124 . 3126 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3127 Errors at High Data Rates", RFC 4963, 3128 DOI 10.17487/RFC4963, July 2007, 3129 . 3131 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 3132 Algorithms in Cryptographically Generated Addresses 3133 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 3134 . 3136 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3137 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3138 DOI 10.17487/RFC5214, March 2008, 3139 . 3141 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 3142 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 3143 February 2010, . 3145 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 3146 Route Optimization Requirements for Operational Use in 3147 Aeronautics and Space Exploration Mobile Networks", 3148 RFC 5522, DOI 10.17487/RFC5522, October 2009, 3149 . 3151 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 3152 RFC 5558, DOI 10.17487/RFC5558, February 2010, 3153 . 3155 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 3156 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 3157 January 2010, . 3159 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 3160 "IPv6 Router Advertisement Options for DNS Configuration", 3161 RFC 6106, DOI 10.17487/RFC6106, November 2010, 3162 . 3164 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 3165 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 3166 . 3168 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 3169 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 3170 DOI 10.17487/RFC6221, May 2011, 3171 . 3173 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 3174 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 3175 DOI 10.17487/RFC6273, June 2011, 3176 . 3178 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3179 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3180 January 2012, . 3182 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 3183 for Equal Cost Multipath Routing and Link Aggregation in 3184 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3185 . 3187 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3188 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3189 . 3191 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 3192 RFC 6864, DOI 10.17487/RFC6864, February 2013, 3193 . 3195 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 3196 Deployment Options and Experience", RFC 7269, 3197 DOI 10.17487/RFC7269, June 2014, 3198 . 3200 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 3201 Korhonen, "Requirements for Distributed Mobility 3202 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 3203 . 3205 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 3206 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 3207 Multicast - Sparse Mode (PIM-SM): Protocol Specification 3208 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 3209 2016, . 3211 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 3212 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 3213 March 2017, . 3215 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 3216 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 3217 DOI 10.17487/RFC8201, July 2017, 3218 . 3220 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3221 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3222 . 3224 Appendix A. AERO Alternate Encapsulations 3226 When GUE encapsulation is not needed, AERO can use common 3227 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 3228 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 3229 encapsulation is therefore only differentiated from non-AERO tunnels 3230 through the application of AERO control messaging and not through, 3231 e.g., a well-known UDP port number. 3233 As for GUE encapsulation, alternate AERO encapsulation formats may 3234 require encapsulation layer fragmentation. For simple IP-in-IP 3235 encapsulation, an IPv6 fragment header is inserted directly between 3236 the inner and outer IP headers when needed, i.e., even if the outer 3237 header is IPv4. The IPv6 Fragment Header is identified to the outer 3238 IP layer by its IP protocol number, and the Next Header field in the 3239 IPv6 Fragment Header identifies the inner IP header version. For GRE 3240 encapsulation, a GRE fragment header is inserted within the GRE 3241 header [I-D.templin-intarea-grefrag]. 3243 Figure 6 shows the AERO IP-in-IP encapsulation format before any 3244 fragmentation is applied: 3246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3247 | Outer IPv4 Header | | Outer IPv6 Header | 3248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3249 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 | Inner IP Header | | Inner IP Header | 3252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3253 | | | | 3254 ~ ~ ~ ~ 3255 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 3256 ~ ~ ~ ~ 3257 | | | | 3258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 3262 Figure 6: Minimal Encapsulation Format using IP-in-IP 3264 Figure 7 shows the AERO GRE encapsulation format before any 3265 fragmentation is applied: 3267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3268 | Outer IP Header | 3269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3270 | GRE Header | 3271 | (with checksum, key, etc..) | 3272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3273 | GRE Fragment Header (optional)| 3274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3275 | Inner IP Header | 3276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3277 | | 3278 ~ ~ 3279 ~ Inner Packet Body ~ 3280 ~ ~ 3281 | | 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 Figure 7: Minimal Encapsulation Using GRE 3286 Alternate encapsulation may be preferred in environments where GUE 3287 encapsulation would add unnecessary overhead. For example, certain 3288 low-bandwidth wireless data links may benefit from a reduced 3289 encapsulation overhead. 3291 GUE encapsulation can traverse network paths that are inaccessible to 3292 non-UDP encapsulations, e.g., for crossing Network Address 3293 Translators (NATs). More and more, network middleboxes are also 3294 being configured to discard packets that include anything other than 3295 a well-known IP protocol such as UDP and TCP. It may therefore be 3296 necessary to determine the potential for middlebox filtering before 3297 enabling alternate encapsulation in a given environment. 3299 In addition to IP-in-IP, GRE and GUE, AERO can also use security 3300 encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO 3301 control messaging and route determination occur before security 3302 encapsulation is applied for outgoing packets and after security 3303 decapsulation is applied for incoming packets. 3305 AERO is especially well suited for use with VPN system encapsulations 3306 such as OpenVPN [OVPN]. 3308 Appendix B. S/TLLAO Extensions for Special-Purpose Links 3310 The AERO S/TLLAO format specified in Section 3.6 includes a Length 3311 value of 5 (i.e., 5 units of 8 octets). However, special-purpose 3312 links may extend the basic format to include additional fields and a 3313 Length value larger than 5. 3315 For example, adaptation of AERO to the Aeronautical 3316 Telecommunications Network with Internet Protocol Services (ATN/IPS) 3317 includes link selection preferences based on transport port numbers 3318 in addition to the existing DSCP-based preferences. ATN/IPS nodes 3319 maintain a map of transport port numbers to 64 possible preference 3320 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 3321 maps to preference field 20, UDP port 8060 maps to preference field 3322 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 3323 Figure 8, where the Length value is 7 and the 'Q(i)' fields provide 3324 link preferences for the corresponding transport port number. 3326 0 1 2 3 3327 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 3328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3329 | Type | Length = 7 | Prefix Length | Reserved | 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | Interface ID | Port Number | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | | 3334 + + 3335 | | 3336 + Link-Layer Address + 3337 | | 3338 + + 3339 | | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 3350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3353 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 3354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3355 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 3356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3358 Figure 8: ATN/IPS Extended S/TLLAO Format 3360 Appendix C. Change Log 3362 << RFC Editor - remove prior to publication >> 3364 Changes from draft-templin-intarea-6706bis-11 to draft-templin- 3365 intrea-6706bis-12: 3367 o Introduced Gateways as a new AERO element for connecting 3368 Correspondent Nodes on INET links 3370 o Introduced terms "Access Network (ANET)" and "Internetwork (INET)" 3372 o Changed "ASP" to "MSP", and "ACP" to "MNP" 3374 o New figure on the relation of Segments to the SPAN and AERO link 3376 o New "S" bit in S/TLLAO to indicate the "Source" S/TLLAO as opposed 3377 to additional S/TLLAOs 3379 o Changed Interface ID for Servers from 255 to 0xffff 3381 o Significant updates to Route Optimization, NUD, and Mobility 3382 Management 3384 o New Section on Multicast 3386 o New Section on AERO Clients in the open Internetwork 3388 o New Section on Operation over multiple AERO links (VLANs over the 3389 SPAN) 3391 o New Sections on DNS considerations and Transition considerations 3393 o 3395 Changes from draft-templin-intarea-6706bis-10 to draft-templin- 3396 intrea-6706bis-11: 3398 o Added The SPAN 3400 Changes from draft-templin-intarea-6706bis-09 to draft-templin- 3401 intrea-6706bis-10: 3403 o Orphaned packets in flight (e.g., when a neighbor cache entry is 3404 in the DEPARTED state) are now forwarded at the link layer instead 3405 of at the network layer. Forwarding at the network layer can 3406 result in routing loops and/or excessive delays of forwarded 3407 packets while the routing system is still reconverging. 3409 o Update route optimization to clarify the unsecured nature of the 3410 first NS used for route discovery 3412 o Many cleanups and clarifications on ND messaging parameters 3414 Changes from draft-templin-intarea-6706bis-08 to draft-templin- 3415 intrea-6706bis-09: 3417 o Changed PRL to "MAP list" 3419 o For neighbor cache entries, changed "static" to "symmetric", and 3420 "dynamic" to "asymmetric" 3422 o Specified Proxy RS/RA exchanges with Servers on behalf of Clients 3424 o Added discussion of unsolicited NAs in Section 3.16, and included 3425 forward reference to Section 3.18 3427 o Added discussion of AERO Clients used as critical infrastructure 3428 elements to connect fixed networks. 3430 o Added network-based VPN under security considerations 3432 Changes from draft-templin-intarea-6706bis-07 to draft-templin- 3433 intrea-6706bis-08: 3435 o New section on AERO-Aware Access Router 3437 Changes from draft-templin-intarea-6706bis-06 to draft-templin- 3438 intrea-6706bis-07: 3440 o Added "R" bit for release of PDs. Now have a full RS/RA service 3441 that can do PD without requiring DHCPv6 messaging over-the-air 3443 o Clarifications on solicited vs unsolicited NAs 3445 o Clarified use of MAX_NEIGHBOR_ADVERTISEMENTS for the purpose of 3446 increase reliability 3448 Changes from draft-templin-intarea-6706bis-05 to draft-templin- 3449 intrea-6706bis-06: 3451 o Major re-work and simplification of Route Optimization function 3453 o Added Distributed Mobility Management (DMM) and Mobility Anchor 3454 Point (MAP) terminology 3456 o New section on "AERO Critical Infrastructure Element 3457 Considerations" demonstrating low overall cost for the service 3459 o minor text revisions and deletions 3461 o removed extraneous appendices 3463 Changes from draft-templin-intarea-6706bis-04 to draft-templin- 3464 intrea-6706bis-05: 3466 o New Appendix E on S/TLLAO Extensions for special-purpose links. 3467 Discussed ATN/IPS as example. 3469 o New sentence in introduction to declare appendices as non- 3470 normative. 3472 Changes from draft-templin-intarea-6706bis-03 to draft-templin- 3473 intrea-6706bis-04: 3475 o Added definitions for Potential Router List (PRL) and secure 3476 enclave 3478 o Included text on mapping transport layer port numbers to network 3479 layer DSCP values 3481 o Added reference to DTLS and DMM Distributed Mobility Anchoring 3482 working group document 3484 o Reworked Security Considerations 3486 o Updated references. 3488 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 3489 intrea-6706bis-03: 3491 o Added new section on SEND. 3493 o Clarifications on "AERO Address" section. 3495 o Updated references and added new reference for RFC8086. 3497 o Security considerations updates. 3499 o General text clarifications and cleanup. 3501 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 3502 intrea-6706bis-02: 3504 o Note on encapsulation avoidance in Section 4. 3506 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 3507 intrea-6706bis-01: 3509 o Remove DHCPv6 Server Release procedures that leveraged the old way 3510 Relays used to "route" between Server link-local addresses 3512 o Remove all text relating to Relays needing to do any AERO-specific 3513 operations 3515 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 3516 as source addresses, and destination address of RA reply is to the 3517 AERO address corresponding to the Client's ACP. 3519 o Proxy uses SEND to protect RS and authenticate RA (Client does not 3520 use SEND, but rather relies on subnetwork security. When the 3521 Proxy receives an RS from the Client, it creates a new RS using 3522 its own addresses as the source and uses SEND with CGAs to send a 3523 new RS to the Server. 3525 o Emphasize distributed mobility management 3527 o AERO address-based RS injection of ACP into underlying routing 3528 system. 3530 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 3531 6706bis-00: 3533 o Document use of NUD (NS/NA) for reliable link-layer address 3534 updates as an alternative to unreliable unsolicited NA. 3535 Consistent with Section 7.2.6 of RFC4861. 3537 o Server adds additional layer of encapsulation between outer and 3538 inner headers of NS/NA messages for transmission through Relays 3539 that act as vanilla IPv6 routers. The messages include the AERO 3540 Server Subnet Router Anycast address as the source and the Subnet 3541 Router Anycast address corresponding to the Client's ACP as the 3542 destination. 3544 o Clients use Subnet Router Anycast address as the encapsulation 3545 source address when the access network does not provide a 3546 topologically-fixed address. 3548 Author's Address 3550 Fred L. Templin (editor) 3551 Boeing Research & Technology 3552 P.O. Box 3707 3553 Seattle, WA 98124 3554 USA 3556 Email: fltemplin@acm.org