idnits 2.17.1 draft-templin-aerolink-63.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 (August 14, 2015) is 3171 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) == Missing Reference: 'I-D.taylor-v6ops-fragdrop' is mentioned on line 978, but not defined == Unused Reference: 'RFC0768' is defined on line 2815, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 2827, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 2865, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 2875, but no explicit reference was found in the text == Unused Reference: 'I-D.vandevelde-idr-remote-next-hop' is defined on line 2915, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2920, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 2936, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 2963, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 3033, but no explicit reference was found in the text == Unused Reference: 'RFC5494' is defined on line 3057, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 3076, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 3095, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 3104, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 3114, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 3123, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 3137, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 3149, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 3154, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 3163, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 3168, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-02) exists of draft-herbert-gue-fragmentation-00 == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-08 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-01 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 26 warnings (==), 7 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, August 14, 2015 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: February 15, 2016 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-63.txt 13 Abstract 15 This document specifies the operation of IP over tunnel virtual links 16 using Asymmetric Extended Route Optimization (AERO). Nodes attached 17 to AERO links can exchange packets via trusted intermediate routers 18 that provide forwarding services to reach off-link destinations and 19 redirection services for route optimization. AERO provides an IPv6 20 link-local address format known as the AERO address that supports 21 operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 22 ND to IP forwarding. Admission control, provisioning and mobility 23 are supported by the Dynamic Host Configuration Protocol for IPv6 24 (DHCPv6), and route optimization is naturally supported through 25 dynamic neighbor cache updates. Although DHCPv6 and IPv6 ND 26 messaging are used in the control plane, both IPv4 and IPv6 are 27 supported in the data plane. AERO is a widely-applicable tunneling 28 solution using standard control messaging exchanges as described in 29 this document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 15, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 6 68 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 6 69 3.2. AERO Link Node Types . . . . . . . . . . . . . . . . . . 8 70 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 9 71 3.4. AERO Interface Characteristics . . . . . . . . . . . . . 10 72 3.5. AERO Link Registration . . . . . . . . . . . . . . . . . 11 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 12 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 12 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 12 76 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 13 77 3.6.4. AERO Forwarding Agent Behavior . . . . . . . . . . . 13 78 3.7. AERO Link Routing System . . . . . . . . . . . . . . . . 13 79 3.8. AERO Interface Neighbor Cache Maintenace . . . . . . . . 15 80 3.9. AERO Interface Sending Algorithm . . . . . . . . . . . . 16 81 3.10. AERO Interface Encapsulation and Re-encapsulation . . . . 18 82 3.11. AERO Interface Decapsulation . . . . . . . . . . . . . . 19 83 3.12. AERO Interface Data Origin Authentication . . . . . . . . 19 84 3.13. AERO Interface MTU and Fragmentation . . . . . . . . . . 20 85 3.13.1. All Elements in Same Administrative Domain . . . . . 20 86 3.13.2. Not All Elements in Same Administrative Domain . . . 21 87 3.13.3. Accommodating Large Control Messages . . . . . . . . 23 88 3.13.4. Integrity . . . . . . . . . . . . . . . . . . . . . 24 89 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 25 90 3.15. AERO Router Discovery, Prefix Delegation and Address 91 Configuration . . . . . . . . . . . . . . . . . . . . . . 29 92 3.15.1. AERO DHCPv6 Service Model . . . . . . . . . . . . . 29 93 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 29 94 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 33 95 3.15.4. Deleting Link Registrations . . . . . . . . . . . . 36 97 3.16. AERO Forwarding Agent Behavior . . . . . . . . . . . . . 36 98 3.17. AERO Intradomain Route Optimization . . . . . . . . . . . 37 99 3.17.1. Reference Operational Scenario . . . . . . . . . . . 37 100 3.17.2. Concept of Operations . . . . . . . . . . . . . . . 39 101 3.17.3. Message Format . . . . . . . . . . . . . . . . . . . 39 102 3.17.4. Sending Predirects . . . . . . . . . . . . . . . . . 40 103 3.17.5. Re-encapsulating and Relaying Predirects . . . . . . 41 104 3.17.6. Processing Predirects and Sending Redirects . . . . 42 105 3.17.7. Re-encapsulating and Relaying Redirects . . . . . . 44 106 3.17.8. Processing Redirects . . . . . . . . . . . . . . . . 45 107 3.17.9. Server-Oriented Redirection . . . . . . . . . . . . 45 108 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 45 109 3.19. Mobility Management . . . . . . . . . . . . . . . . . . . 47 110 3.19.1. Announcing Link-Layer Address Changes . . . . . . . 47 111 3.19.2. Bringing New Links Into Service . . . . . . . . . . 47 112 3.19.3. Removing Existing Links from Service . . . . . . . . 47 113 3.19.4. Moving to a New Server . . . . . . . . . . . . . . . 48 114 3.20. Proxy AERO . . . . . . . . . . . . . . . . . . . . . . . 48 115 3.21. Extending AERO Links Through Security Gateways . . . . . 51 116 3.22. Extending IPv6 AERO Links to the Internet . . . . . . . . 53 117 3.23. Encapsulation Protocol Version Considerations . . . . . . 56 118 3.24. Multicast Considerations . . . . . . . . . . . . . . . . 56 119 3.25. Operation on AERO Links Without DHCPv6 Services . . . . . 57 120 3.26. Operation on Server-less AERO Links . . . . . . . . . . . 57 121 3.27. Manually-Configured AERO Tunnels . . . . . . . . . . . . 57 122 3.28. Intradomain Routing . . . . . . . . . . . . . . . . . . . 57 123 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 57 124 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 58 125 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 126 7. Security Considerations . . . . . . . . . . . . . . . . . . . 58 127 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 128 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 129 9.1. Normative References . . . . . . . . . . . . . . . . . . 60 130 9.2. Informative References . . . . . . . . . . . . . . . . . 62 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 68 133 1. Introduction 135 This document specifies the operation of IP over tunnel virtual links 136 using Asymmetric Extended Route Optimization (AERO). The AERO link 137 can be used for tunneling to neighboring nodes over either IPv6 or 138 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 139 equivalent links for tunneling. Nodes attached to AERO links can 140 exchange packets via trusted intermediate routers that provide 141 forwarding services to reach off-link destinations and redirection 142 services for route optimization that addresses the requirements 143 outlined in [RFC5522]. 145 AERO provides an IPv6 link-local address format known as the AERO 146 address that supports operation of the IPv6 Neighbor Discovery (ND) 147 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 148 control, provisioning and mobility are supported by the Dynamic Host 149 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and route 150 optimization is naturally supported through dynamic neighbor cache 151 updates. Although DHCPv6 and IPv6 ND messaging are used in the 152 control plane, both IPv4 and IPv6 can be used in the data plane. 153 AERO is a widely-applicable tunneling solution using standard control 154 messaging exchanges as described in this document. The remainder of 155 this document presents the AERO specification. 157 2. Terminology 159 The terminology in the normative references applies; the following 160 terms are defined within the scope of this document: 162 AERO link 163 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 164 configured over a node's attached IPv6 and/or IPv4 networks. All 165 nodes on the AERO link appear as single-hop neighbors from the 166 perspective of the virtual overlay. 168 AERO interface 169 a node's attachment to an AERO link. Nodes typically have a 170 single AERO interface; support for multiple AERO interfaces is 171 also possible but out of scope for this document. 173 AERO address 174 an IPv6 link-local address constructed as specified in Section 3.3 175 and assigned to a Client's AERO interface. 177 AERO node 178 a node that is connected to an AERO link and that participates in 179 IPv6 ND and DHCPv6 messaging over the link. 181 AERO Client ("Client") 182 a node that issues DHCPv6 messages using the special IPv6 link- 183 local address 'fe80::ffff:ffff:ffff:ffff' to receive IP Prefix 184 Delegations (PD) from one or more AERO Servers. Following PD, the 185 Client assigns an AERO address to the AERO interface which it uses 186 in IPv6 ND messaging to coordinate with other AERO nodes. 188 AERO Server ("Server") 189 a node that configures an AERO interface to provide default 190 forwarding and DHCPv6 services for AERO Clients. The Server 191 assigns an administratively provisioned IPv6 link-local unicast 192 address to support the operation of DHCPv6 and the IPv6 ND 193 protocol. An AERO Server can also act as an AERO Relay. 195 AERO Relay ("Relay") 196 a node that configures an AERO interface to relay IP packets 197 between nodes on the same AERO link and/or forward IP packets 198 between the AERO link and the native Internetwork. The Relay 199 assigns an administratively provisioned IPv6 link-local unicast 200 address to the AERO interface the same as for a Server. An AERO 201 Relay can also act as an AERO Server. 203 AERO Forwarding Agent ("Forwarding Agent") 204 a node that performs data plane forwarding services as a companion 205 to an AERO Server. 207 ingress tunnel endpoint (ITE) 208 an AERO interface endpoint that injects tunneled packets into an 209 AERO link. 211 egress tunnel endpoint (ETE) 212 an AERO interface endpoint that receives tunneled packets from an 213 AERO link. 215 underlying network 216 a connected IPv6 or IPv4 network routing region over which the 217 tunnel virtual overlay is configured. A typical example is an 218 enterprise network. 220 underlying interface 221 an AERO node's interface point of attachment to an underlying 222 network. 224 link-layer address 225 an IP address assigned to an AERO node's underlying interface. 226 When UDP encapsulation is used, the UDP port number is also 227 considered as part of the link-layer address. Link-layer 228 addresses are used as the encapsulation header source and 229 destination addresses. 231 network layer address 232 the source or destination address of the encapsulated IP packet. 234 end user network (EUN) 235 an internal virtual or external edge IP network that an AERO 236 Client connects to the rest of the network via the AERO interface. 238 AERO Service Prefix (ASP) 239 an IP prefix associated with the AERO link and from which AERO 240 Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 241 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 243 AERO Client Prefix (ACP) 244 a more-specific IP prefix taken from an ASP and delegated to a 245 Client. 247 Throughout the document, the simple terms "Client", "Server" and 248 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 249 respectively. Capitalization is used to distinguish these terms from 250 DHCPv6 client/server/relay [RFC3315]. 252 The terminology of [RFC4861] (including the names of node variables 253 and protocol constants) applies to this document. Also throughout 254 the document, the term "IP" is used to generically refer to either 255 Internet Protocol version (i.e., IPv4 or IPv6). 257 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 258 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 259 document are to be interpreted as described in [RFC2119]. Lower case 260 uses of these words are not to be interpreted as carrying RFC2119 261 significance. 263 3. Asymmetric Extended Route Optimization (AERO) 265 The following sections specify the operation of IP over Asymmetric 266 Extended Route Optimization (AERO) links: 268 3.1. AERO Link Reference Model 269 .-(::::::::) 270 .-(:::: IP ::::)-. 271 (:: Internetwork ::) 272 `-(::::::::::::)-' 273 `-(::::::)-' 274 | 275 +--------------+ +--------+-------+ +--------------+ 276 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 277 | Nbr: C1; R1 | | Nbr: S1; S2 | | Nbr: C2; R1 | 278 | default->R1 | |(H1->S1; H2->S2)| | default->R1 | 279 | H1->C1 | +--------+-------+ | H2->C2 | 280 +-------+------+ | +------+-------+ 281 | | | 282 X---+---+-------------------+------------------+---+---X 283 | AERO Link | 284 +-----+--------+ +--------+-----+ 285 |AERO Client C1| |AERO Client C2| 286 | Nbr: S1 | | Nbr: S2 | 287 | default->S1 | | default->S2 | 288 +--------------+ +--------------+ 289 .-. .-. 290 ,-( _)-. ,-( _)-. 291 .-(_ IP )-. .-(_ IP )-. 292 (__ EUN ) (__ EUN ) 293 `-(______)-' `-(______)-' 294 | | 295 +--------+ +--------+ 296 | Host H1| | Host H2| 297 +--------+ +--------+ 299 Figure 1: AERO Link Reference Model 301 Figure 1 presents the AERO link reference model. In this model: 303 o Relay R1 acts as a default router for its associated Servers S1 304 and S2, and connects the AERO link to the rest of the IP 305 Internetwork 307 o Servers S1 and S2 associate with Relay R1 and also act as default 308 routers for their associated Clients C1 and C2. 310 o Clients C1 and C2 associate with Servers S1 and S2, respectively 311 and also act as default routers for their associated EUNs 313 o Hosts H1 and H2 attach to the EUNs served by Clients C1 and C2, 314 respectively 316 Each node maintains a neighbor cache and IP forwarding table. (For 317 example, AERO Relay R1 in the diagram has neighbor cache entries for 318 Servers S1 and S2 and IP forwarding table entries for the ACPs 319 delegated to Clients C1 and C2.) In common operational practice, 320 there may be many additional Relays, Servers and Clients. (Although 321 not shown in the figure, AERO Forwarding Agents may also be provided 322 for data plane forwarding offload services.) 324 3.2. AERO Link Node Types 326 AERO Relays provide default forwarding services to AERO Servers. 327 Relays forward packets between Servers connected to the same AERO 328 link and also forward packets between the AERO link and the native IP 329 Internetwork. Relays present the AERO link to the native 330 Internetwork as a set of one or more AERO Service Prefixes (ASPs) and 331 serve as a gateway between the AERO link and the Internetwork. AERO 332 Relays maintain an AERO interface neighbor cache entry for each AERO 333 Server, and maintain an IP forwarding table entry for each AERO 334 Client Prefix (ACP). AERO Relays can also be configured to act as 335 AERO Servers. 337 AERO Servers provide default forwarding services to AERO Clients. 338 Each Server also peers with each Relay in a dynamic routing protocol 339 instance to advertise its list of associated ACPs. Servers configure 340 a DHCPv6 server function to facilitate Prefix Delegation (PD) 341 exchanges with Clients. Each delegated prefix becomes an ACP taken 342 from an ASP. Servers forward packets between AERO interface 343 neighbors only, i.e., and not between the AERO link and the native IP 344 Internetwork. AERO Servers maintain an AERO interface neighbor cache 345 entry for each AERO Relay. They also maintain both a neighbor cache 346 entry and an IP forwarding table entry for each of their associated 347 Clients. AERO Servers can also be configured to act as AERO Relays. 349 AERO Clients act as requesting routers to receive ACPs through DHCPv6 350 PD exchanges with AERO Servers over the AERO link and sub-delegate 351 portions of their ACPs to EUN interfaces. (Each Client MAY associate 352 with a single Server or with multiple Servers, e.g., for fault 353 tolerance, load balancing, etc.) Each IPv6 Client receives at least 354 a /64 IPv6 ACP, and may receive even shorter prefixes. Similarly, 355 each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a singleton 356 IPv4 address), and may receive even shorter prefixes. AERO Clients 357 maintain an AERO interface neighbor cache entry for each of their 358 associated Servers as well as for each of their correspondent 359 Clients. 361 AERO Clients typically configure a TUN/TAP interface [TUNTAP] as a 362 point-to-point linkage between the IP layer and the AERO interface. 363 The IP layer therefore sees only the TUN/TAP interface, while the 364 AERO interface provides an intermediate conduit between the TUN/TAP 365 interface and the underlying interfaces. AERO Clients that act as 366 hosts assign one or more IP addresses from their ACPs to the TUN/TAP 367 interface, i.e., and not to the AERO interface. 369 AERO Forwarding Agents provide data plane forwarding services as 370 companions to AERO Servers. Note that while Servers are required to 371 perform both control and data plane operations on their own behalf, 372 they may optionally enlist the services of special-purpose Forwarding 373 Agents to offload data plane traffic. 375 3.3. AERO Addresses 377 An AERO address is an IPv6 link-local address with an embedded ACP 378 and assigned to a Client's AERO interface. The AERO address is 379 formed as follows: 381 fe80::[ACP] 383 For IPv6, the AERO address begins with the prefix fe80::/64 and 384 includes in its interface identifier the base prefix taken from the 385 Client's IPv6 ACP. The base prefix is determined by masking the ACP 386 with the prefix length. For example, if the AERO Client receives the 387 IPv6 ACP: 389 2001:db8:1000:2000::/56 391 it constructs its AERO address as: 393 fe80::2001:db8:1000:2000 395 For IPv4, the AERO address is formed from the lower 64 bits of an 396 IPv4-mapped IPv6 address [RFC4291] that includes the base prefix 397 taken from the Client's IPv4 ACP. For example, if the AERO Client 398 receives the IPv4 ACP: 400 192.0.2.32/28 402 it constructs its AERO address as: 404 fe80::FFFF:192.0.2.32 406 The AERO address remains stable as the Client moves between 407 topological locations, i.e., even if its link-layer addresses change. 409 NOTE: In some cases, prospective neighbors may not have advanced 410 knowledge of the Client's ACP length and may therefore send initial 411 IPv6 ND messages with an AERO destination address that matches the 412 ACP but does not correspond to the base prefix. In that case, the 413 Client MUST accept the address as equivalent to the base address, but 414 then use the base address as the source address of any IPv6 ND 415 message replies. For example, if the Client receives the IPv6 ACP 416 2001:db8:1000:2000::/56 then subsequently receives an IPv6 ND message 417 with destination address fe80::2001:db8:1000:2001, it accepts the 418 message but uses fe80::2001:db8:1000:2000 as the source address of 419 any IPv6 ND replies. 421 3.4. AERO Interface Characteristics 423 AERO interfaces use encapsulation (see Section 3.10) to exchange 424 packets with neighbors attached to the AERO link. AERO interfaces 425 maintain a neighbor cache, and AERO Clients and Servers use unicast 426 IPv6 ND messaging. AERO interfaces use unicast Neighbor Solicitation 427 (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and 428 Router Advertisement (RA) messages the same as for any IPv6 link. 429 AERO interfaces use two redirection message types -- the first known 430 as a Predirect message and the second being the standard Redirect 431 message (see Section 3.17). AERO links further use link-local-only 432 addressing; hence, AERO nodes ignore any Prefix Information Options 433 (PIOs) they may receive in RA messages over an AERO interface. 435 AERO interface ND messages include one or more Source/Target Link- 436 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type = 2 | Length = 3 | Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Link ID | NDSCPs | DSCP #1 |Prf| DSCP #2 |Prf| 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | DSCP #3 |Prf| DSCP #4 |Prf| .... 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | UDP Port Number | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 449 | | 450 + + 451 | IP Address | 452 + + 453 | | 454 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 459 Format 461 In this format, Link ID is an integer value between 0 and 255 462 corresponding to an underlying interface of the target node, NDSCPs 463 encodes an integer value between 1 and 64 indicating the number of 464 Differentiated Services Code Point (DSCP) octets that follow. Each 465 DSCP octet is a 6-bit integer DSCP value followed by a 2-bit 466 Preference ("Prf") value. Each DSCP value encodes an integer between 467 0 and 63 associated with this Link ID, where the value 0 means 468 "default" and other values are interpreted as specified in [RFC2474]. 469 The 'Prf' qualifier for each DSCP value is set to the value 0 470 ("deprecated'), 1 ("low"), 2 ("medium"), or 3 ("high") to indicate a 471 preference level for packet forwarding purposes. UDP Port Number and 472 IP Address are set to the addresses used by the target node when it 473 sends encapsulated packets over the underlying interface. When the 474 encapsulation IP address family is IPv4, IP Address is formed as an 475 IPv4-mapped IPv6 address [RFC4291]. 477 AERO interfaces may be configured over multiple underlying 478 interfaces. For example, common mobile handheld devices have both 479 wireless local area network ("WLAN") and cellular wireless links. 480 These links are typically used "one at a time" with low-cost WLAN 481 preferred and highly-available cellular wireless as a standby. In a 482 more complex example, aircraft frequently have many wireless data 483 link types (e.g. satellite-based, terrestrial, air-to-air 484 directional, etc.) with diverse performance and cost properties. 486 If a Client's multiple underlying interfaces are used "one at a time" 487 (i.e., all other interfaces are in standby mode while one interface 488 is active), then Redirect, Predirect and unsolicited NA messages 489 include only a single TLLAO with Link ID set to a constant value. 491 If the Client has multiple active underlying interfaces, then from 492 the perspective of IPv6 ND it would appear to have a single link- 493 local address with multiple link-layer addresses. In that case, 494 Redirect, Predirect and unsolicited NA messages MAY include multiple 495 TLLAOs -- each with a different Link ID that corresponds to a 496 specific underlying interface of the Client. 498 3.5. AERO Link Registration 500 When an administrative authority first deploys a set of AERO Relays 501 and Servers that comprise an AERO link, they also assign a unique 502 domain name for the link, e.g., "linkupnetworks.example.com". Next, 503 if administrative policy permits Clients within the domain to serve 504 as correspondent nodes for Internet mobile nodes, the administrative 505 authority adds a Fully Qualified Domain Name (FQDN) for each of the 506 AERO link's ASPs to the Domain Name System (DNS) [RFC1035]. The FQDN 507 is based on the suffix "aero.linkupnetworks.net" with a prefix formed 508 from the wildcard-terminated reverse mapping of the ASP 510 [RFC3596][RFC4592], and resolves to a DNS PTR resource record. For 511 example, for the ASP '2001:db8:1::/48' within the domain name 512 "linkupnetworks.example.com", the DNS database contains: 514 '*.1.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net. PTR 515 linkupnetworks.example.com' 517 This DNS registration advertises the AERO link's ASPs to prospective 518 correspondent nodes. 520 3.6. AERO Interface Initialization 522 3.6.1. AERO Relay Behavior 524 When a Relay enables an AERO interface, it first assigns an 525 administratively provisioned link-local address fe80::ID to the 526 interface. Each fe80::ID address MUST be unique among all AERO nodes 527 on the link, and MUST NOT collide with any potential AERO addresses 528 nor the special addresses fe80:: and fe80::ffff:ffff:ffff:ffff. (The 529 fe80::ID addresses are typically taken from the available range 530 fe80::/96, e.g., as fe80::1, fe80::2, fe80::3, etc.) The Relay then 531 engages in a dynamic routing protocol session with all Servers on the 532 link (see: Section 3.7), and advertises its assigned ASP prefixes 533 into the native IP Internetwork. 535 Each Relay subsequently maintains an IP forwarding table entry for 536 each Client-Server association, and maintains a neighbor cache entry 537 for each Server on the link. Relays exchange NS/NA messages with 538 AERO link neighbors the same as for any AERO node, however they 539 typically do not perform explicit Neighbor Unreachability Detection 540 (NUD) (see: Section 3.18) since the dynamic routing protocol already 541 provides reachability confirmation. 543 3.6.2. AERO Server Behavior 545 When a Server enables an AERO interface, it assigns an 546 administratively provisioned link-local address fe80::ID the same as 547 for Relays. The Server further configures a DHCPv6 server function 548 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 549 maintains a neighbor cache entry for each Relay on the link, and 550 manages per-Client neighbor cache entries and IP forwarding table 551 entries based on control message exchanges. Each Server also engages 552 in a dynamic routing protocol with each Relay on the link (see: 553 Section 3.7). 555 When the Server receives an NS/RS message from a Client on the AERO 556 interface it returns an NA/RA message but does not update the 557 neighbor cache. The Server further provides a simple conduit between 558 AERO interface neighbors. Therefore, packets enter the Server's AERO 559 interface from the link layer and are forwarded back out the link 560 layer without ever leaving the AERO interface and therefore without 561 ever disturbing the network layer. 563 3.6.3. AERO Client Behavior 565 When a Client enables an AERO interface, it uses the special address 566 fe80::ffff:ffff:ffff:ffff to obtain an ACP from an AERO Server via 567 DHCPv6 PD. Next, it assigns the corresponding AERO address to the 568 AERO interface and creates a neighbor cache entry for the Server, 569 i.e., the PD exchange bootstraps autoconfiguration of a unique link- 570 local address. The Client maintains a neighbor cache entry for each 571 of its Servers and each of its active correspondent Clients. When 572 the Client receives Redirect/Predirect messages on the AERO interface 573 it updates or creates neighbor cache entries, including link-layer 574 address information. Unsolicited NA messages update the cached link- 575 layer addresses for correspondent Clients (e.g., following a link- 576 layer address change due to node mobility) but do not create new 577 neighbor cache entries. NS/NA messages used for NUD update timers in 578 existing neighbor cache entires but do not update link-layer 579 addresses nor create new neighbor cache entries. 581 Finally, the Client need not maintain any IP forwarding table entries 582 for its Servers or correspondent Clients. Instead, it can set a 583 single "route-to-interface" default route in the IP forwarding table, 584 and all forwarding decisions can be made within the AERO interface 585 based on neighbor cache entries. (On systems in which adding a 586 default route would violate security policy, the default route could 587 instead be installed via a "synthesized RA", e.g., as discussed in 588 Section 3.15.2.) 590 3.6.4. AERO Forwarding Agent Behavior 592 When a Forwarding Agent enables an AERO interface, it assigns the 593 same link-local address(es) as the companion AERO Server. The 594 Forwarding Agent thereafter provides data plane forwarding services 595 based solely on the forwarding information assigned to it by the 596 companion AERO Server. 598 3.7. AERO Link Routing System 600 Relays require full topology knowledge of all ACP/Server associations 601 for the ASPs they service, while individual Servers at a minimum only 602 need to know the ACPs for their current set of associated Clients. 603 This is accomplished through the use of an internal instance of the 604 Border Gateway Protocol (BGP) [RFC4271] coordinated between Servers 605 and Relays. This internal BGP instance does not interact with the 606 public Internet BGP instance; therefore, the AERO link is presented 607 to the IP Internetwork as a small set of ASPs as opposed to the full 608 set of individual ACPs. 610 In a reference BGP arrangement, each AERO Server is configured as an 611 Autonomous System Border Router (ASBR) for a stub Autonomous System 612 (AS) using an AS Number (ASN) that is unique within the BGP instance, 613 and each Server further peers with each Relay but does not peer with 614 other Servers. Similarly, Relays do not peer with each other, since 615 they will reliably receive all updates from all Servers and will 616 therefore have a consistent view of the AERO link ACP delegations. 618 Each Server maintains a working set of associated ACPs, and 619 dynamically announces new ACPs and withdraws departed ACPs in its BGP 620 updates to Relays. Clients are expected to remain associated with 621 their current Servers for extended timeframes, however Servers SHOULD 622 selectively suppress BGP updates for impatient Clients that 623 repeatedly associate and disassociate with them in order to dampen 624 routing churn. 626 Each Relay configures a black-hole route for each ASP associated with 627 the AERO link. By black-holing the ASPs, the Relay will maintain 628 active forwarding table entries only for the ACPs that are currently 629 active, and all other ACPs will correctly result in destination 630 unreachable failures due to the black hole route. 632 Scaling properties of the AERO routing system are limited by the 633 number of BGP routes that can be carried by Relays. Assuming O(10^6) 634 as a reasonable maximum number of BGP routes, this means that O(10^6) 635 Clients can be serviced by a single set of Relays. A means of 636 increasing scaling would be to assign a different set of Relays for 637 each set of ASPs. In that case, each Server still peers with each 638 Relay, but the Server institutes route filters so that each set of 639 Relays only receives BGP updates for the ACPs they aggregate. For 640 example, if the ASP for the AERO link is 2001:db8::/32, a first set 641 of Relays could service the ASP segment 2001:db8::/40, a second set 642 of Relays could service 2001:db8:0100::/40, a third set could service 643 2001:db8:0200::/40, etc. 645 Assuming up to O(10^3) sets of Relays, the system can then 646 accommodate O(10^9) Clients with no additional overhead for Servers 647 and Relays. In this way, each set of Relays services a specific set 648 of ASPs that they advertise to the native routing system outside of 649 the AERO link, and each Server configures ASP-specific routes that 650 list the correct set of Relays as next hops. This arrangement also 651 allows for natural incremental deployment, and can support small 652 scale initial deployments followed by dynamic deployment of 653 additional Clients, Servers and Relays without disturbing the 654 already-deployed base. 656 3.8. AERO Interface Neighbor Cache Maintenace 658 Each AERO interface maintains a conceptual neighbor cache that 659 includes an entry for each neighbor it communicates with on the AERO 660 link, the same as for any IPv6 interface [RFC4861]. AERO interface 661 neighbor cache entires are said to be one of "permanent", "static" or 662 "dynamic". 664 Permanent neighbor cache entries are created through explicit 665 administrative action; they have no timeout values and remain in 666 place until explicitly deleted. AERO Relays maintain a permanent 667 neighbor cache entry for each Server on the link, and AERO Servers 668 maintain a permanent neighbor cache entry for each Relay. Each entry 669 maintains the mapping between the neighbor's fe80::ID network-layer 670 address and corresponding link-layer address. 672 Static neighbor cache entries are created though DHCPv6 PD exchanges 673 and remain in place for durations bounded by prefix lifetimes. AERO 674 Servers maintain static neighbor cache entries for the ACPs of each 675 of their associated Clients, and AERO Clients maintain a static 676 neighbor cache entry for each of their associated Servers. When an 677 AERO Server sends a DHCPv6 Reply message response to a Client's 678 DHCPv6 Solicit/Request, Rebind or Renew message, it creates or 679 updates a static neighbor cache entry based on the AERO address 680 corresponding to the Client's ACP as the network-layer address, the 681 prefix lifetime as the neighbor cache entry lifetime, the Client's 682 encapsulation IP address and UDP port number as the link-layer 683 address and the prefix length as the length to apply to the AERO 684 address. When an AERO Client receives a DHCPv6 Reply message from a 685 Server, it creates or updates a static neighbor cache entry based on 686 the Reply message link-local source address as the network-layer 687 address, the prefix lifetime as the neighbor cache entry lifetime, 688 and the encapsulation IP source address and UDP source port number as 689 the link-layer address. 691 Dynamic neighbor cache entries are created or updated based on 692 receipt of an IPv6 ND message, and are garbage-collected if not used 693 within a bounded timescale. AERO Clients maintain dynamic neighbor 694 cache entries for each of their active correspondent Client ACPs with 695 lifetimes based on IPv6 ND messaging constants. When an AERO Client 696 receives a valid Predirect message it creates or updates a dynamic 697 neighbor cache entry for the Predirect target network-layer and link- 698 layer addresses plus prefix length. The node then sets an 699 "AcceptTime" variable in the neighbor cache entry to ACCEPT_TIME 700 seconds and uses this value to determine whether packets received 701 from the correspondent can be accepted. When an AERO Client receives 702 a valid Redirect message it creates or updates a dynamic neighbor 703 cache entry for the Redirect target network-layer and link-layer 704 addresses plus prefix length. The Client then sets a "ForwardTime" 705 variable in the neighbor cache entry to FORWARD_TIME seconds and uses 706 this value to determine whether packets can be sent directly to the 707 correspondent. The Client also sets a "MaxRetry" variable to 708 MAX_RETRY to limit the number of keepalives sent when a correspondent 709 may have gone unreachable. 711 For dynamic neighbor cache entries, when an AERO Client receives a 712 valid NS message it (re)sets AcceptTime for the neighbor to 713 ACCEPT_TIME. When an AERO Client receives a valid solicited NA 714 message, it (re)sets ForwardTime for the neighbor to FORWARD_TIME and 715 sets MaxRetry to MAX_RETRY. When an AERO Client receives a valid 716 unsolicited NA message, it updates the correspondent's link-layer 717 addresses but DOES NOT reset AcceptTime, ForwardTime or MaxRetry. 719 It is RECOMMENDED that FORWARD_TIME be set to the default constant 720 value 30 seconds to match the default REACHABLE_TIME value specified 721 for IPv6 ND [RFC4861]. 723 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 724 value 40 seconds to allow a 10 second window so that the AERO 725 redirection procedure can converge before AcceptTime decrements below 726 FORWARD_TIME. 728 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 729 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 731 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 732 administratively set, if necessary, to better match the AERO link's 733 performance characteristics; however, if different values are chosen, 734 all nodes on the link MUST consistently configure the same values. 735 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 736 sufficiently longer than FORWARD_TIME to allow the AERO redirection 737 procedure to converge. 739 3.9. AERO Interface Sending Algorithm 741 IP packets enter a node's AERO interface either from the network 742 layer (i.e., from a local application or the IP forwarding system), 743 or from the link layer (i.e., from the AERO tunnel virtual link). 744 Packets that enter the AERO interface from the network layer are 745 encapsulated and admitted into the AERO link, i.e., they are 746 tunnelled to an AERO interface neighbor. Packets that enter the AERO 747 interface from the link layer are either re-admitted into the AERO 748 link or delivered to the network layer where they are subject to 749 either local delivery or IP forwarding. Since each AERO node may 750 have only partial information about neighbors on the link, AERO 751 interfaces may forward packets with link-local destination addresses 752 at a layer below the network layer. This means that AERO nodes act 753 as both IP routers and sub-IP layer forwarding agents. AERO 754 interface sending considerations for Clients, Servers and Relays are 755 given below. 757 When an IP packet enters a Client's AERO interface from the network 758 layer, if the destination is covered by an ASP the Client searches 759 for a dynamic neighbor cache entry with a non-zero ForwardTime and an 760 AERO address that matches the packet's destination address. (The 761 destination address may be either an address covered by the 762 neighbor's ACP or the (link-local) AERO address itself.) If there is 763 a match, the Client uses a link-layer address in the entry as the 764 link-layer address for encapsulation then admits the packet into the 765 AERO link. If there is no match, the Client instead uses the link- 766 layer address of a neighboring Server as the link-layer address for 767 encapsulation. 769 When an IP packet enters a Server's AERO interface from the link 770 layer, if the destination is covered by an ASP the Server searches 771 for a neighbor cache entry with an AERO address that matches the 772 packet's destination address. (The destination address may be either 773 an address covered by the neighbor's ACP or the AERO address itself.) 774 If there is a match, the Server uses a link-layer address in the 775 entry as the link-layer address for encapsulation and re-admits the 776 packet into the AERO link. If there is no match, the Server instead 777 uses the link-layer address in a permanent neighbor cache entry for a 778 Relay as the link-layer address for encapsulation. 780 When an IP packet enters a Relay's AERO interface from the network 781 layer, the Relay searches its IP forwarding table for an entry that 782 is covered by an ASP and also matches the destination. If there is a 783 match, the Relay uses the link-layer address in a permanent neighbor 784 cache entry for a Server as the link-layer address for encapsulation 785 and admits the packet into the AERO link. When an IP packet enters a 786 Relay's AERO interface from the link-layer, if the destination is not 787 a link-local address and does not match an ASP the Relay removes the 788 packet from the AERO interface and uses IP forwarding to forward the 789 packet to the Internetwork. If the destination address is a link- 790 local address or a non-link-local address that matches an ASP, and 791 there is a more-specific ACP entry in the IP forwarding table, the 792 Relay uses the link-layer address in the corresponding neighbor cache 793 entry as the link-layer address for encapsulation and re-admits the 794 packet into the AERO link. When an IP packet enters a Relay's AERO 795 interface from either the network layer or link-layer, and the 796 packet's destination address matches an ASP but there is no more- 797 specific ACP entry, the Relay drops the packet and returns an ICMP 798 Destination Unreachable message (see: Section 3.14). 800 When an AERO Server receives a packet from a Relay via the AERO 801 interface, the Server MUST NOT forward the packet back to the same or 802 a different Relay. 804 When an AERO Relay receives a packet from a Server via the AERO 805 interface, the Relay MUST NOT forward the packet back to the same 806 Server. 808 When an AERO node re-admits a packet into the AERO link without 809 involving the network layer, the node MUST NOT decrement the network 810 layer TTL/Hop-count. 812 When an AERO node forwards a data packet to the primary link-layer 813 address of a Server, it may receive Redirect messages with an SLLAO 814 that include the link-layer address of an AERO Forwarding Agent. The 815 AERO node SHOULD record the link-layer address in the neighbor cache 816 entry for the neighbor and send subsequent data packets via this 817 address instead of the Server's primary address (see: Section 3.16). 819 3.10. AERO Interface Encapsulation and Re-encapsulation 821 AERO interfaces encapsulate IP packets according to whether they are 822 entering the AERO interface from the network layer or if they are 823 being re-admitted into the same AERO link they arrived on. This 824 latter form of encapsulation is known as "re-encapsulation". 826 The AERO interface encapsulates packets per the Generic UDP 827 Encapsulation (GUE) encapsulation procedures in 828 [I-D.ietf-nvo3-gue][I-D.herbert-gue-fragmentation]. During 829 encapsulation, the AERO interface copies the "TTL/Hop Limit", "Type 830 of Service/Traffic Class" [RFC2983], "Flow Label"[RFC6438].(for IPv6) 831 and "Congestion Experienced" [RFC3168] values in the packet's IP 832 header into the corresponding fields in the encapsulation IP header. 833 For packets undergoing re-encapsulation, the AERO interface instead 834 copies the "TTL/Hop Limit", "Type of Service/Traffic Class", "Flow 835 Label" and "Congestion Experienced" values in the original 836 encapsulation IP header into the corresponding fields in the new 837 encapsulation IP header, i.e., the values are transferred between 838 encapsulation headers and *not* copied from the encapsulated packet's 839 network-layer header. 841 The AERO interface next sets the UDP source port to a constant value 842 that it will use in each successive packet it sends, and sets the UDP 843 length field to the length of the encapsulated packet plus 8 bytes 844 for the UDP header itself, plus the length of the GUE header. For 845 packets sent via a Server, the AERO interface sets the UDP 846 destination port to 8060, i.e., the IANA-registered port number for 847 AERO. For packets sent to a correspondent Client, the AERO interface 848 sets the UDP destination port to the port value stored in the 849 neighbor cache entry for this correspondent. The AERO interface also 850 sets the UDP checksum field per the procedures specified in 851 [I-D.ietf-nvo3-gue]. 853 The AERO interface next sets the IP protocol number in the 854 encapsulation header to 17 (i.e., the IP protocol number for UDP). 855 When IPv4 is used as the encapsulation protocol, the AERO interface 856 sets the DF bit as discussed in Section 3.13. 858 3.11. AERO Interface Decapsulation 860 AERO interfaces decapsulate packets destined either to the node 861 itself or to a destination reached via an interface other than the 862 AERO interface the packet was received on. Decapsulation is per the 863 procedures specified in [I-D.ietf-nvo3-gue]. 865 3.12. AERO Interface Data Origin Authentication 867 AERO nodes employ simple data origin authentication procedures for 868 encapsulated packets they receive from other nodes on the AERO link. 869 In particular: 871 o AERO Relays and Servers accept encapsulated packets with a link- 872 layer source address that matches a permanent neighbor cache 873 entry. 875 o AERO Servers accept authentic encapsulated DHCPv6 messages from 876 Clients, and create or update a static neighbor cache entry for 877 the source based on the specific message type. 879 o AERO Servers accept encapsulated packets if there is a neighbor 880 cache entry with an AERO address that matches the packet's 881 network-layer source address and with a link-layer address that 882 matches the packet's link-layer source address. 884 o AERO Clients accept encapsulated packets if there is a static 885 neighbor cache entry with a link-layer source address that matches 886 the packet's link-layer source address. 888 o AERO Clients and Servers accept encapsulated packets if there is a 889 dynamic neighbor cache entry with an AERO address that matches the 890 packet's network-layer source address, with a link-layer address 891 that matches the packet's link-layer source address, and with a 892 non-zero AcceptTime. 894 Note that this simple data origin authentication is effective in 895 environments in which link-layer addresses cannot be spoofed. In 896 other environments, each AERO message must include a signature that 897 the recipient can use to authenticate the message origin. 899 3.13. AERO Interface MTU and Fragmentation 901 The AERO interface is the node's point of attachment to the AERO link 902 and the tunnel ingress. AERO links over IP networks have a maximum 903 link MTU of 64KB minus the encapsulation overhead (i.e., 64KB- 904 ENCAPS), since the maximum packet size in the base IP specifications 905 is 64KB [RFC0791][RFC2460]. While IPv6 jumbograms can be up to 4GB 906 [RFC2675], they are considered optional for IPv6 nodes [RFC6434] and 907 therefore out of scope for this document. 909 The AERO interface is considered to have an indefinite MTU , i.e., 910 instead of clamping the MTU to a fixed size. The MTU for each AERO 911 interface neighbor (i.e., each tunnel egress) is therefore 912 constrained by the minimum of 64KB, the MTU of the underlying 913 interface used for tunneling, and the path MTU within the tunnel 914 (minus ENCAPS in each case). 916 IPv6 specifies a minimum link MTU of 1280 bytes [RFC2460]. This is 917 the minimum packet size the AERO interface MUST admit without 918 returning an ICMP Packet Too Big (PTB) message. Although IPv4 919 specifies a smaller minimum link MTU of 68 bytes [RFC0791], AERO 920 interfaces also observe a 1280 byte minimum for IPv4 even if some 921 fragmentation is needed. 923 The vast majority of links in the Internet configure an MTU of at 924 least 1500 bytes. Original source hosts have therefore become 925 conditioned to expect that IP packets up to 1500 bytes in length will 926 either be delivered to the final destination or a suitable PTB 927 message returned. However, PTB messages may be crafted for malicious 928 purposes such as denial of service, or lost in the network [RFC2923] 929 resulting in failure of the IP Path MTU Discovery (PMTUD) mechanisms 930 [RFC1191][RFC1981]. For these reasons, the tunnel ingress sends 931 encapsulated packets to the tunnel egress subject to whether standard 932 PMTUD can be leveraged within the specific deployment model. The two 933 cases for consideration are as follows: 935 3.13.1. All Elements in Same Administrative Domain 937 When the original source, ingress and egress are all within the same 938 well-managed administrative domain, the ingress admits a packet into 939 the tunnel if it is no larger than the current path MTU estimate for 940 this egress (initially set to the MTU of the underlying link to be 941 used for tunneling minus ENCAPS). Otherwise, the ingress drops the 942 packet and sends a network layer (L3) PTB message back to the 943 original source. Additionally, the ingress SHOULD translate any 944 link-layer (L2) PTB messages it receives from a router on the path to 945 the egress into an L3 PTB message to return to the original source if 946 possible, and cache the MTU value as a new path MTU 947 estimate.(Thereafter, the ingress SHOULD periodically reset the path 948 MTU estimate to the MTU of the underlying link minus ENCAPS to detect 949 path MTU increases.) 951 These procedures apply when the path MTU for this egress is no 952 smaller than (1280+ENCAPS) bytes. Otherwise, the ingress can either 953 shut down the tunnel or begin fragmenting packets that are no larger 954 than 1280 bytes but larger than the path MTU minus ENCAPS as 955 specified in Section 3.13.2. This parallels the standard behavior 956 specified in [RFC2473] except that, when the original packet is an 957 IPv4 packet with DF=0, the ingress uses IPv4 fragmentation to 958 fragment the original packet when necessary before encapsulation as 959 specified in Section 3.13.2. 961 3.13.2. Not All Elements in Same Administrative Domain 963 When the original source, ingress and egress are not all within the 964 same well-managed administrative domain, the ingress admits all 965 packets up to 1500 bytes in length even if some fragmentation is 966 needed, and admits larger packets without fragmentation in case they 967 are able to traverse the tunnel in one piece. Also, the ingress 968 SHOULD process any L2 PTB messages it receives with an MTU size 969 larger than (1500+HLEN) bytes as a new path MTU estimate the same as 970 described in Section 3.13.1. 972 Several factors must be considered when fragmentation is needed. For 973 AERO links over IPv4, the IP ID field is only 16 bits in length, 974 meaning that fragmentation at high data rates could result in data 975 corruption due to reassembly misassociations [RFC6864][RFC4963] (see: 976 Section 3.13.4). For AERO links over both IPv4 and IPv6, studies 977 have also shown that IP fragments are dropped unconditionally over 978 some network paths [I-D.taylor-v6ops-fragdrop]. For these reasons, 979 when fragmentation is needed the ingress inserts a GUE fragment 980 header [I-D.herbert-gue-fragmentation] and applies tunnel 981 fragmentation as described in Section 3.1.7 of [RFC2764] instead of 982 IP fragmentation. Since the fragment header reduces the room 983 available for packet data, but the original source has no way to 984 control its insertion, the ingress MUST include the fragment header 985 length in the ENCAPS length even for packets in which the header does 986 not appear. 988 The ingress therefore sends encapsulated packets to the egress 989 according to the following algorithm: 991 o For IP packets that are no larger than (1280-ENCAPS) bytes, the 992 ingress encapsulates the packet and admits it into the tunnel 993 without fragmentation. For IPv4 AERO links, the ingress sets the 994 Don't Fragment (DF) bit to 0 so that these packets will be 995 delivered to the egress even if there is a restricting link in the 996 path, i.e., unless lost due to congestion or routing errors. 998 o For IP packets that are larger than (1280-ENCAPS) bytes but no 999 larger than 1500 bytes, the ingress encapsulates the packet and 1000 inserts a GUE fragment header. Next, the ingress fragments the 1001 packet into two non-overlapping fragments where the first fragment 1002 (including ENCAPS) is no larger than 1024 bytes and the second is 1003 no larger than the first. Each fragment consists of identical 1004 IP/UDP/GUE encapsulation headers followed by the fragment of the 1005 encapsulated packet itself. The ingress then admits both 1006 fragments into the tunnel, and for IPv4 sets the DF bit to 0 in 1007 the IP encapsulation header. These fragmented encapsulated 1008 packets will be delivered to the egress, which reassembles them 1009 into a whole packet. The egress therefore MUST be capable of 1010 reassembling packets up to (1500+ENCAPS) bytes in length; hence, 1011 it is RECOMMENDED that the egress be capable of reassembling at 1012 least 2KB. 1014 o For IPv4 packets that are larger than 1500 bytes and with the DF 1015 bit set to 0, the ingress uses ordinary IPv4 fragmentation to 1016 break the unencapsulated packet into a minimum number of non- 1017 overlapping fragments where the first fragment (including ENCAPS) 1018 is no larger than 1024 bytes and all other fragments are no larger 1019 than the first fragment. The ingress then encapsulates each 1020 fragment (and for IPv4 sets the DF bit to 0) then admits them into 1021 the tunnel. These fragments will be delivered to the final 1022 destination via the egress. 1024 o For all other IP packets, if the packet is larger than the current 1025 path MTU estimate for this egress, the ingress drops the packet 1026 and returns an L3 PTB message to the original source with MTU set 1027 to the larger of 1500 bytes or the current path MTU estimate. 1028 Otherwise, the ingress encapsulates the packet and admits it into 1029 the tunnel without fragmentation (and for IPv4 sets the DF bit to 1030 1). Additionally, the ingress SHOULD translate any link-layer 1031 (L2) PTB messages it receives from a router on the path to the 1032 egress with an MTU size larger than (1500+HLEN) into an L3 PTB 1033 message to return to the original source if possible, and cache 1034 the MTU value as a new path MTU estimate. (Thereafter, the 1035 ingress SHOULD periodically reset the path MTU estimate to the MTU 1036 of the underlying link minus ENCAPS to detect path MTU increases.) 1037 Since PTB messages may either be lost or contain insufficient 1038 information, however, it is RECOMMENDED that original sources that 1039 send unfragmentable IP packets larger than 1500 bytes use 1040 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821]. 1042 A first exception to these procedures occurs when the ingress and 1043 egress are both within the same well-managed administrative domain. 1044 In that case, the ingress MAY initially admit all packets into the 1045 tunnel without fragmentation. If the ingress subsequently receives 1046 an L2 PTB message reporting a size smaller than (1500+ENCAPS) it can 1047 commence fragmentation per the above algorithm. 1049 A second exception occurs when the original source and ingress are 1050 both within the same well-managed administrative domain. In that 1051 case, if the underlying interface used by the ingress for tunneling 1052 configures an MTU smaller than (1500+HLEN) bytes, the ingress MAY 1053 drop packets that are larger than 1280 bytes and larger than the 1054 underlying interface MTU following encapsulation, and return an L3 1055 PTB message to the original source. 1057 3.13.3. Accommodating Large Control Messages 1059 Control messages (i.e., IPv6 ND, DHCPv6, etc.) MUST be accommodated 1060 even if some fragmentation is necessary. These packets are therefore 1061 accommodated through a modification of the second rule in the above 1062 algorithm as follows: 1064 o For control messages that are larger than (1280-ENCAPS) bytes, the 1065 ingress encapsulates the packet and inserts a GUE fragment header. 1066 Next, the ingress uses GUE fragmentation 1067 [I-D.herbert-gue-fragmentation] to break the packet into a minimum 1068 number of non-overlapping fragments where the first fragment 1069 (including ENCAPS) is no larger than 1024 bytes and the remaining 1070 fragments are no larger than the first. The ingress then 1071 encapsulates each fragment (and for IPv4 sets the DF bit to 0) 1072 then admits them into the tunnel. 1074 Control messages that exceed the 2KB minimum reassembly size rarely 1075 occur in the modern era, however the egress SHOULD be able to 1076 reassemble them if they do. This means that the egress SHOULD 1077 include a configuration knob allowing the operator to set a larger 1078 reassembly buffer size if large control messages become more common 1079 in the future. 1081 The ingress MAY send large control messages without fragmentation if 1082 there is assurance that large packets can traverse the tunnel without 1083 fragmentation. 1085 3.13.4. Integrity 1087 When fragmentation is needed, there must be assurance that reassembly 1088 can be safely conducted without incurring data corruption. Sources 1089 of corruption can include implementation errors, memory errors and 1090 misassociations of fragments from a first datagram with fragments of 1091 another datagram. The first two conditions (implementation and 1092 memory errors) are mitigated by modern systems and implementations 1093 that have demonstrated integrity through decades of operational 1094 practice. The third condition (reassembly misassociations) must be 1095 accounted for by AERO. 1097 The fragmentation procedure described in the above algorithms can 1098 reuse standard IPv6 fragmentation and reassembly code. Since the GUE 1099 fragment header includes a 32-bit ID field, there would need to be 1100 2^32 packets alive in the network before a second packet with a 1101 duplicate ID enters the system with the (remote) possibility for a 1102 reassembly misassociation. For 1280 byte packets, and for a maximum 1103 network lifetime value of 60 seconds[RFC2460], this means that the 1104 ingress would need to produce ~(7 *10^12) bits/sec in order for a 1105 duplication event to be possible. This exceeds the bandwidth of data 1106 link technologies of the modern era, but not necessarily so going 1107 forward into the future. Although wireless data links commonly used 1108 by AERO Clients support vastly lower data rates, the aggregate data 1109 rates between AERO Servers and Relays may be substantial. However, 1110 high speed data links in the network core are expected to configure 1111 larger MTUs, e.g., 4KB, 8KB or even larger such that unfragmented 1112 packets can be used. Hence, no integrity check is included to cover 1113 fragmentation and reassembly procedures. 1115 When the ingress sends an IPv4-encapsulated packet with the DF bit 1116 set to 0 in the above algorithms, there is a chance that the packet 1117 may be fragmented by an IPv4 router somewhere within the tunnel. 1118 Since the largest such packet is only 1280 bytes, however, it is very 1119 likely that the packet will traverse the tunnel without incurring a 1120 restricting link. Even when a link within the tunnel configures an 1121 MTU smaller than 1280 bytes, it is very likely that it does so due to 1122 limited performance characteristics [RFC3819]. This means that the 1123 tunnel would not be able to convey fragmented IPv4-encapsulated 1124 packets fast enough to produce reassembly misassociations, as 1125 discussed above. However, AERO must also account for the possibility 1126 of tunnel paths that include "poorly managed" IPv4 link MTUs due to 1127 misconfigurations. 1129 Since the IPv4 header includes only a 16-bit ID field, there would 1130 only need to be 2^16 packets alive in the network before a second 1131 packet with a duplicate ID enters the system. For 1280 byte packets, 1132 and for a maximum network lifetime value of 120 seconds[RFC0791], 1133 this means that the ingress would only need to produce ~(5 *10^6) 1134 bits/sec in order for a duplication event to be possible - a value 1135 that is well within range for many modern wired and wireless data 1136 link technologies. 1138 Therefore, if there is strong operational assurance that no IPv4 1139 links capable of supporting data rates of 5Mbps or more configure an 1140 MTU smaller than 1280 the ingress MAY omit an integrity check for the 1141 IPv4 fragmentation and reassembly procedures; otherwise, the ingress 1142 SHOULD include an integrity check. When an upper layer encapsulation 1143 (e.g., IPsec) already includes an integrity check, the ingress need 1144 not include an additional check. Otherwise, the ingress calculates 1145 the UDP checksum over the encapsulated packet and writes the value 1146 into the UDP encapsulation header, i.e., instead of writing the value 1147 0. The egress will then verify the UDP checksum and discard the 1148 packet if the checksum is incorrect. 1150 3.14. AERO Interface Error Handling 1152 When an AERO node admits encapsulated packets into the AERO 1153 interface, it may receive link-layer (L2) or network-layer (L3) error 1154 indications. 1156 An L2 error indication is an ICMP error message generated by a router 1157 on the path to the neighbor or by the neighbor itself. The message 1158 includes an IP header with the address of the node that generated the 1159 error as the source address and with the link-layer address of the 1160 AERO node as the destination address. 1162 The IP header is followed by an ICMP header that includes an error 1163 Type, Code and Checksum. For ICMPv6 [RFC4443], the error Types 1164 include "Destination Unreachable", "Packet Too Big (PTB)", "Time 1165 Exceeded" and "Parameter Problem". For ICMPv4 [RFC0792], the error 1166 Types include "Destination Unreachable", "Fragmentation Needed" (a 1167 Destination Unreachable Code that is analogous to the ICMPv6 PTB), 1168 "Time Exceeded" and "Parameter Problem". 1170 The ICMP header is followed by the leading portion of the packet that 1171 generated the error, also known as the "packet-in-error". For 1172 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1173 much of invoking packet as possible without the ICMPv6 packet 1174 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1175 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1176 "Internet Header + 64 bits of Original Data Datagram", however 1177 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1178 ICMP datagram SHOULD contain as much of the original datagram as 1179 possible without the length of the ICMP datagram exceeding 576 1180 bytes". 1182 The L2 error message format is shown in Figure 3: 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 ~ ~ 1186 | L2 IP Header of | 1187 | error message | 1188 ~ ~ 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | L2 ICMP Header | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1192 ~ ~ P 1193 | IP and other encapsulation | a 1194 | headers of original L3 packet | c 1195 ~ ~ k 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1197 ~ ~ t 1198 | IP header of | 1199 | original L3 packet | i 1200 ~ ~ n 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 ~ ~ e 1203 | Upper layer headers and | r 1204 | leading portion of body | r 1205 | of the original L3 packet | o 1206 ~ ~ r 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1209 Figure 3: AERO Interface L2 Error Message Format 1211 The AERO node rules for processing these L2 error messages is as 1212 follows: 1214 o When an AERO node receives an L2 Parameter Problem message, it 1215 processes the message the same as described as for ordinary ICMP 1216 errors in the normative references [RFC0792][RFC4443]. 1218 o When an AERO node receives persistent L2 IPv4 Time Exceeded 1219 messages, the IP ID field may be wrapping before earlier fragments 1220 have been processed. In that case, the node SHOULD begin 1221 including IPv4 integrity checks (see: Section 3.13.4). 1223 o When an AERO Client receives persistent L2 Destination Unreachable 1224 messages in response to tunneled packets that it sends to one of 1225 its dynamic neighbor correspondents, the Client SHOULD test the 1226 path to the correspondent using Neighbor Unreachability Detection 1227 (NUD) (see Section 3.18). If NUD fails, the Client SHOULD set 1228 ForwardTime for the corresponding dynamic neighbor cache entry to 1229 0 and allow future packets destined to the correspondent to flow 1230 through a Server. 1232 o When an AERO Client receives persistent L2 Destination Unreachable 1233 messages in response to tunneled packets that it sends to one of 1234 its static neighbor Servers, the Client SHOULD test the path to 1235 the Server using NUD. If NUD fails, the Client SHOULD delete the 1236 neighbor cache entry and attempt to associate with a new Server. 1238 o When an AERO Server receives persistent L2 Destination Unreachable 1239 messages in response to tunneled packets that it sends to one of 1240 its static neighbor Clients, the Server SHOULD test the path to 1241 the Client using NUD. If NUD fails, the Server SHOULD cancel the 1242 DHCPv6 PD for the Client's ACP, withdraw its route for the ACP 1243 from the AERO routing system and delete the neighbor cache entry 1244 (see Section 3.18 and Section 3.19). 1246 o When an AERO Relay or Server receives an L2 Destination 1247 Unreachable message in response to a tunneled packet that it sends 1248 to one of its permanent neighbors, it discards the message since 1249 the routing system is likely in a temporary transitional state 1250 that will soon re-converge. 1252 o When an AERO node receives an L2 PTB message, it translates the 1253 message into an L3 PTB message if possible (*) and forwards the 1254 message toward the original source as described below. 1256 To translate an L2 PTB message to an L3 PTB message, the AERO node 1257 first caches the MTU field value of the L2 ICMP header. The node 1258 next discards the L2 IP and ICMP headers, and also discards the 1259 encapsulation headers of the original L3 packet. Next the node 1260 encapsulates the included segment of the original L3 packet in an L3 1261 IP and ICMP header, and sets the ICMP header Type and Code values to 1262 appropriate values for the L3 IP protocol. In the process, the node 1263 writes the maximum of 1500 bytes and (L2 MTU - ENCAPS) into the MTU 1264 field of the L3 ICMP header. 1266 The node next writes the IP source address of the original L3 packet 1267 as the destination address of the L3 PTB message and determines the 1268 next hop to the destination. If the next hop is reached via the AERO 1269 interface, the node uses the IPv6 address "::" or the IPv4 address 1270 "0.0.0.0" as the IP source address of the L3 PTB message. Otherwise, 1271 the node uses one of its non link-local addresses as the source 1272 address of the L3 PTB message. The node finally calculates the ICMP 1273 checksum over the L3 PTB message and writes the Checksum in the 1274 corresponding field of the L3 ICMP header. The L3 PTB message 1275 therefore is formatted as follows: 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 ~ ~ 1279 | L3 IP Header of | 1280 | error message | 1281 ~ ~ 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | L3 ICMP Header | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1285 ~ ~ p 1286 | IP header of | k 1287 | original L3 packet | t 1288 ~ ~ 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1290 ~ ~ n 1291 | Upper layer headers and | 1292 | leading portion of body | e 1293 | of the original L3 packet | r 1294 ~ ~ r 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1297 Figure 4: AERO Interface L3 Error Message Format 1299 After the node has prepared the L3 PTB message, it either forwards 1300 the message via a link outside of the AERO interface without 1301 encapsulation, or encapsulates and forwards the message to the next 1302 hop via the AERO interface. 1304 When an AERO Relay receives an L3 packet for which the destination 1305 address is covered by an ASP, if there is no more-specific routing 1306 information for the destination the Relay drops the packet and 1307 returns an L3 Destination Unreachable message. The Relay first 1308 writes the IP source address of the original L3 packet as the 1309 destination address of the L3 Destination Unreachable message and 1310 determines the next hop to the destination. If the next hop is 1311 reached via the AERO interface, the Relay uses the IPv6 address "::" 1312 or the IPv4 address "0.0.0.0" as the IP source address of the L3 1313 Destination Unreachable message and forwards the message to the next 1314 hop within the AERO interface. Otherwise, the Relay uses one of its 1315 non link-local addresses as the source address of the L3 Destination 1316 Unreachable message and forwards the message via a link outside the 1317 AERO interface. 1319 When an AERO node receives any L3 error message via the AERO 1320 interface, it examines the destination address in the L3 IP header of 1321 the message. If the next hop toward the destination address of the 1322 error message is via the AERO interface, the node re-encapsulates and 1323 forwards the message to the next hop within the AERO interface. 1324 Otherwise, if the source address in the L3 IP header of the message 1325 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1326 writes one of its non link-local addresses as the source address of 1327 the L3 message and recalculates the IP and/or ICMP checksums. The 1328 node finally forwards the message via a link outside of the AERO 1329 interface. 1331 (*) Note that in some instances the packet-in-error field of an L2 1332 PTB message may not include enough information for translation to an 1333 L3 PTB message. In that case, the AERO interface simply discards the 1334 L2 PTB message. It can therefore be said that translation of L2 PTB 1335 messages to L3 PTB messages can provide a useful optimization when 1336 possible, but is not critical for sources that correctly use PLPMTUD. 1338 3.15. AERO Router Discovery, Prefix Delegation and Address 1339 Configuration 1341 3.15.1. AERO DHCPv6 Service Model 1343 Each AERO Server configures a DHCPv6 server function to facilitate PD 1344 requests from Clients. Each Server is provisioned with a database of 1345 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1346 system, as well as any information necessary to authenticate each 1347 Client. The Client database is maintained by a central 1348 administrative authority for the AERO link and securely distributed 1349 to all Servers, e.g., via the Lightweight Directory Access Protocol 1350 (LDAP) [RFC4511] or a similar distributed database service. 1352 Therefore, no Server-to-Server DHCPv6 PD delegation state 1353 synchronization is necessary, and Clients can optionally hold 1354 separate delegations for the same ACP from multiple Servers. In this 1355 way, Clients can associate with multiple Servers, and can receive new 1356 delegations from new Servers before deprecating delegations received 1357 from existing Servers. 1359 AERO Clients and Servers exchange Client link-layer address 1360 information using an option format similar to the Client Link Layer 1361 Address Option (CLLAO) defined in [RFC6939]. Due to practical 1362 limitations of CLLAO, however, AERO interfaces instead use Vendor- 1363 Specific Information Options as described in the following sections. 1365 3.15.2. AERO Client Behavior 1367 AERO Clients discover the link-layer addresses of AERO Servers via 1368 static configuration, or through an automated means such as DNS name 1369 resolution. In the absence of other information, the Client resolves 1370 the FQDN "linkupnetworks.[domainname]" where "linkupnetworks" is a 1371 constant text string and "[domainname]" is the connection-specific 1372 DNS suffix for the Client's underlying network connection (e.g., 1373 "example.com"). After discovering the link-layer addresses, the 1374 Client associates with one or more of the corresponding Servers. 1376 To associate with a Server, the Client acts as a requesting router to 1377 request an ACP through a two-message (i.e., Solicit/Reply) or four- 1378 message (i.e., Solicit/Advertise/Request/Reply) DHCPv6 PD exchange 1379 [RFC3315][RFC3633]. The Client's Solicit/Request message includes 1380 fe80::ffff:ffff:ffff:ffff as the IPv6 source address, 1381 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 1382 and the link-layer address of the Server as the link-layer 1383 destination address. The Solicit/Request message also includes a 1384 Rapid Commit option, a Client Identifier option with a DHCP Unique 1385 Identifier (DUID) and an Identity Association for Prefix Delegation 1386 (IA_PD) option. If the Client is pre-provisioned with an ACP 1387 associated with the AERO service, it MAY also include the ACP in the 1388 IA_PD to indicate its preference to the DHCPv6 server. 1390 The Client also SHOULD include an AERO Link-registration Request 1391 (ALREQ) option to register one or more links with the Server. The 1392 Server will include an AERO Link-registration Reply (ALREP) option in 1393 the corresponding DHCPv6 Reply message as specified in 1394 Section 3.15.3. (The Client MAY omit the ALREQ option, in which case 1395 the Server will still include an ALREP option in its Reply with "Link 1396 ID" set to 0, "DSCP" set to 0, and "Prf" set to 3.) 1398 The format for the ALREQ option is shown in Figure 5: 1400 0 1 2 3 1401 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 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | OPTION_VENDOR_OPTS | option-len (1) | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | enterprise-number = 45282 | 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | opt-code = OPTION_ALREQ (0) | option-len (2) | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Link ID | DSCP #1 |Prf| DSCP #2 |Prf| ... 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1412 Figure 5: AERO Link-registration Request (ALREQ) Option 1414 In the above format, the Client sets 'option-code' to 1415 OPTION_VENDOR_OPTS, sets 'option-len (1)' to the length of the option 1416 following this field, sets 'enterprise-number' to 45282 (see: "IANA 1417 Considerations"), sets opt-code to the value 0 ("OPTION_ALREQ") and 1418 sets 'option-len (2)' to the length of the remainder of the option. 1419 The Client includes appropriate 'Link ID, 'DSCP' and 'Prf' values for 1420 the underlying interface over which the DHCPv6 PD Solicit/Request 1421 message will be issued the same as specified for an S/TLLAO 1422 Section 3.4. The Client MAY include multiple (DSCP, Prf) values with 1423 this Link ID, with the number of values indicated by option-len (2). 1424 The Server will register each value with the Link ID in the Client's 1425 neighbor cache entry. The Client finally includes any necessary 1426 authentication options to identify itself to the DHCPv6 server, and 1427 sends the encapsulated DHCPv6 PD Solicit/Request message via the 1428 underlying interface corresponding to Link ID. (Note that this 1429 implies that the Client must perform additional Rebind/Reply DHCPv6 1430 exchanges with the server following the initial PD exchange using 1431 different underlying interfaces and their corresponding Link IDs if 1432 it wishes to register additional link-layer addresses and their 1433 associated DSCPs.) 1435 When the Client receives its ACP via a DHCPv6 Reply from the AERO 1436 Server, it creates a static neighbor cache entry with the Server's 1437 link-local address as the network-layer address and the Server's 1438 encapsulation address as the link-layer address. The Client then 1439 considers the link-layer address of the Server as the primary default 1440 encapsulation address for forwarding packets for which no more- 1441 specific forwarding information is available. The Client further 1442 caches any ASPs included in the ALREP option as ASPs to apply to the 1443 AERO link. 1445 Next, the Client autoconfigures an AERO address from the delegated 1446 ACP, assigns the AERO address to the AERO interface and sub-delegates 1447 the ACP to its attached EUNs and/or the Client's own internal virtual 1448 interfaces. The Client also assigns a default IP route to the AERO 1449 interface as a route-to-interface, i.e., with no explicit next-hop. 1450 The Client can then determine the correct next hops for packets 1451 submitted to the AERO interface by inspecting the neighbor cache. 1453 The Client subsequently renews its ACP delegation through each of its 1454 Servers by performing DHCPv6 Renew/Reply exchanges with the link- 1455 layer address of a Server as the link-layer destination address and 1456 the same options that were used in the initial PD request. Note that 1457 if the Client does not issue a DHCPv6 Renew before the delegation 1458 expires (e.g., if the Client has been out of touch with the Server 1459 for a considerable amount of time) it must re-initiate the DHCPv6 PD 1460 procedure. 1462 Since the Client's AERO address is obtained from the unique ACP 1463 delegation it receives, there is no need for Duplicate Address 1464 Detection (DAD) on AERO links. Other nodes maliciously attempting to 1465 hijack an authorized Client's AERO address will be denied access to 1466 the network by the DHCPv6 server due to an unacceptable link-layer 1467 address and/or security parameters (see: Security Considerations). 1469 When a Client attempts to perform a DHCPv6 PD exchange with a Server 1470 that is too busy to service the request, the Client may receive a 1471 "NoPrefixAvail" status code in the Server's Reply per [RFC3633]. In 1472 that case, the Client SHOULD discontinue DHCPv6 PD attempts through 1473 this Server and try another Server. 1475 3.15.2.1. Autoconfiguration for Constrained Platforms 1477 On some platforms (e.g., popular cell phone operating systems), the 1478 act of assigning a default IPv6 route and/or assigning an address to 1479 an interface may not be permitted from a user application due to 1480 security policy. Typically, those platforms include a TUN/TAP 1481 interface that acts as a point-to-point conduit between user 1482 applications and the AERO interface. In that case, the Client can 1483 instead generate a "synthesized RA" message. The message conforms to 1484 [RFC4861] and is prepared as follows: 1486 o the IPv6 source address is the Client's AERO address 1488 o the IPv6 destination address is all-nodes multicast 1490 o the Router Lifetime is set to a time that is no longer than the 1491 ACP DHCPv6 lifetime 1493 o the message does not include a Source Link Layer Address Option 1494 (SLLAO) 1496 o the message includes a Prefix Information Option (PIO) with a /64 1497 prefix taken from the ACP as the prefix for autoconfiguration 1499 The Client then sends the synthesized RA message via the TUN/TAP 1500 interface, where the operating system kernel will interpret it as 1501 though it were generated by an actual router. The operating system 1502 will then install a default route and use StateLess Address 1503 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 1504 interface. Methods for similarly installing an IPv4 default route 1505 and IPv4 address on the TUN/TAP interface are based on synthesized 1506 DHCPv4 messages [RFC2131]. 1508 3.15.2.2. Client DHCPv6 Message Source Address 1510 In the initial DHCPv6 PD message exchanges, AERO Clients use the 1511 special IPv6 source address 'fe80::ffff:ffff:ffff:ffff' since their 1512 AERO addresses are not yet configured. After AERO address 1513 autoconfiguration, however, AERO Clients can either continue to use 1514 'fe80::ffff:ffff:ffff:ffff' as the source address for further DHCPv6 1515 messaging or begin using their AERO address as the source address. 1517 3.15.3. AERO Server Behavior 1519 AERO Servers configure a DHCPv6 server function on their AERO links. 1520 AERO Servers arrange to add their encapsulation layer IP addresses 1521 (i.e., their link-layer addresses) to the DNS resource records for 1522 the FQDN "linkupnetworks.[domainname]" before entering service. 1524 When an AERO Server receives a prospective Client's DHCPv6 PD 1525 Solicit/Request on its AERO interface, and the Server is too busy to 1526 service the message, it returns a Reply with status code 1527 "NoPrefixAvail" per [RFC3633]. Otherwise, the Server authenticates 1528 the message. 1530 If authentication succeeds, the Server determines the correct ACP to 1531 delegate to the Client by searching the Client database. In 1532 environments where spoofing is not considered a threat, the Server 1533 MAY use the Client's DUID as the identification value. Otherwise, 1534 the Server SHOULD use a signed certificate provided by the Client. 1536 When the Server delegates the ACP, it also creates an IP forwarding 1537 table entry so that the AERO routing system will propagate the ACP to 1538 all Relays that aggregate the corresponding ASP (see: Section 3.7). 1539 Next, the Server prepares a DHCPv6 Reply message to send to the 1540 Client while using fe80::ID as the IPv6 source address, the link- 1541 local address taken from the Client's Solicit/Request as the IPv6 1542 destination address, the Server's link-layer address as the source 1543 link-layer address, and the Client's link-layer address as the 1544 destination link-layer address. The server also includes an IA_PD 1545 option with the delegated ACP. Since the Client may experience a 1546 fault that prevents it from issuing a DHCPv6 Release before departing 1547 from the network, Servers should set a short prefix lifetime (e.g., 1548 40 seconds) so that stale prefix delegation state can be flushed out 1549 of the network. 1551 The Server also includes an ALREP option that includes the UDP Port 1552 Number and IP Address values it observed when it received the ALREQ 1553 in the Client's original DHCPv6 message (if present) followed by the 1554 ASP(s) for the AERO link. The ALREP option is formatted as shown in 1555 Figure 6: 1557 0 1 2 3 1558 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 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | OPTION_VENDOR_OPTS | option-len (1) | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | enterprise-number = 45282 | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | opt-code = OPTION_ALREP (1) | option-len (2) | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Link ID | Reserved | UDP Port Number | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | | 1569 + + 1570 | | 1571 + IP Address + 1572 | | 1573 + + 1574 | | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | | 1577 + AERO Service Prefix (ASP) #1 +-+-+-+-+-+-+-+-+ 1578 | | Prefix Len | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | | 1581 + AERO Service Prefix (ASP) #2 +-+-+-+-+-+-+-+-+ 1582 | | Prefix Len | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 ~ ~ 1585 ~ ~ 1587 Figure 6: AERO Link-registration Reply (ALREP) Option 1589 In the ALREP, the Server sets 'option-code' to OPTION_VENDOR_OPTS, 1590 sets 'option-length (1)' to the length of the option, sets 1591 'enterprise-number' to 45282 (see: "IANA Considerations"), sets opt- 1592 code to OPTION_ALREP (1), and sets 'option-len (2)' to the length of 1593 the remainder of the option. Next, the Server sets 'Link ID' to the 1594 same value that appeared in the ALREQ, sets Reserved to 0 and sets 1595 'UDP Port Number' and 'IP address' to the Client's link-layer 1596 address. The Server next includes one or more ASP with the IP prefix 1597 as it would appear in the interface identifier portion of the 1598 corresponding AERO address (see: Section 3.3), except that the low- 1599 order 8 bits of the ASP field encode the prefix length instead of the 1600 low-order 8 bits of the prefix. The longest prefix that can 1601 therefore appear as an ASP is /56 for IPv6 or /24 for IPv4. (Note 1602 that if the Client did not include an ALREQ option in its DHCPv6 1603 message, the Server MUST still include an ALREP option in the 1604 corresponding reply with 'Link ID' set to 0.) 1606 When the Server admits the DHCPv6 Reply message into the AERO 1607 interface, it creates a static neighbor cache entry for the Client's 1608 AERO address with lifetime set to no more than the delegation 1609 lifetime and the Client's link-layer address as the link-layer 1610 address for the Link ID specified in the ALREQ. The Server then uses 1611 the Client link-layer address information in the ALREQ option as the 1612 link-layer address for encapsulation based on the (DSCP, Prf) 1613 information. 1615 After the initial DHCPv6 PD exchange, the AERO Server maintains the 1616 neighbor cache entry for the Client until the delegation lifetime 1617 expires. If the Client issues a Renew/Reply exchange, the Server 1618 extends the lifetime. If the Client issues a Release/Reply, or if 1619 the Client does not issue a Renew/Reply before the lifetime expires, 1620 the Server deletes the neighbor cache entry for the Client and 1621 withdraws the IP route from the AERO routing system. 1623 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1625 AERO Clients and Servers are always on the same link (i.e., the AERO 1626 link) from the perspective of DHCPv6. However, in some 1627 implementations the DHCPv6 server and AERO interface driver may be 1628 located in separate modules. In that case, the Server's AERO 1629 interface driver module acts as a Lightweight DHCPv6 Relay Agent 1630 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1631 server module. 1633 When the LDRA receives a DHCPv6 message from a client, it prepares an 1634 ALREP option the same as described above then wraps the option in a 1635 Relay-Supplied DHCP Option option (RSOO) [RFC6422]. The LDRA then 1636 incorporates the option into the Relay-Forward message and forwards 1637 the message to the DHCPv6 server. 1639 When the DHCPv6 server receives the Relay-Forward message, it caches 1640 the ALREP option and authenticates the encapsulated DHCPv6 message. 1641 The DHCPv6 server subsequently ignores the ALREQ option itself, since 1642 the relay has already included the ALREP option. 1644 When the DHCPv6 server prepares a Reply message, it then includes the 1645 ALREP option in the body of the message along with any other options, 1646 then wraps the message in a Relay-Reply message. The DHCPv6 server 1647 then delivers the Relay-Reply message to the LDRA, which discards the 1648 Relay-Reply wrapper and delivers the DHCPv6 message to the Client. 1650 3.15.4. Deleting Link Registrations 1652 After an AERO Client registers its Link IDs and their associated 1653 (DSCP,Prf) values with the AERO Server, the Client may wish to delete 1654 one or more Link registrations, e.g., if an underlying link becomes 1655 unavailable. To do so, the Client prepares a DHCPv6 Rebind message 1656 that includes an AERO Link-registration Delete (ALDEL) option and 1657 sends the Rebind message to the Server over any available underlying 1658 link. The ALDEL option is formatted as shown in Figure 7: 1660 0 1 2 3 1661 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 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | OPTION_VENDOR_OPTS | option-len (1) | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | enterprise-number = 45282 | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | opt-code = OPTION_ALDEL (2) | option-len (2) | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Link ID #1 | Link ID #2 | Link ID #3 | ... 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1672 Figure 7: AERO Link-registration Delete (ALDEL) Option 1674 In the ALDEL, the Client sets 'option-code' to OPTION_VENDOR_OPTS, 1675 sets 'option-length (1)' to the length of the option, sets 1676 'enterprise-number' to 45282 (see: "IANA Considerations"), sets 1677 optcode to OPTION_ALDEL (2), and sets 'option-len (2)' to the length 1678 of the remainder of the option. Next, the Server includes each 'Link 1679 ID' value that it wishes to delete. 1681 If the Client wishes to discontinue use of a Server and thereby 1682 delete all of its Link ID associations, it must use a DHCPv6 Release/ 1683 Reply exchange to delete the entire neighbor cache entry, i.e., 1684 instead of using a DHCPv6 Rebind/Reply exchange with one or more 1685 ALDEL options. 1687 3.16. AERO Forwarding Agent Behavior 1689 AERO Servers MAY associate with one or more companion AERO Forwarding 1690 Agents as platforms for offloading high-speed data plane traffic. 1691 When an AERO Server receives a Client's DHCPv6 1692 Solicit/Request/Renew/Rebind/Release message, it services the message 1693 then forwards the corresponding Reply message to the Forwarding 1694 Agent. When the Forwarding Agent receives the Reply message, it 1695 creates, updates or deletes a neighbor cache entry with the Client's 1696 AERO address and link-layer information included in the Reply 1697 message. The Forwarding Agent then forwards the Reply message back 1698 to the AERO Server, which forwards the message to the Client. In 1699 this way, Forwarding Agent state is managed in conjunction with 1700 Server state, with the Client responsible for reliability. If the 1701 Client subsequently disappears without issuing a Release, the Server 1702 is responsible for purging stale state by sending synthesized Reply 1703 messages to the Forwarding Agent. 1705 When an AERO Server receives a data packet on an AERO interface with 1706 a network layer destination address for which it has distributed 1707 forwarding information to a Forwarding Agent, the Server returns a 1708 Redirect message to the source neighbor (subject to rate limiting) 1709 then forwards the data packet as usual. The Redirect message 1710 includes a TLLAO with the link-layer address of the Forwarding 1711 Engine. 1713 When the source neighbor receives the Redirect message, it SHOULD 1714 record the link-layer address in the TLLAO as the encapsulation 1715 addresses to use for sending subsequent data packets. However, the 1716 source MUST continue to use the primary link-layer address of the 1717 Server as the encapsulation address for sending control messages. 1719 3.17. AERO Intradomain Route Optimization 1721 When a source Client forwards packets to a prospective correspondent 1722 Client within the same AERO link domain (i.e., one for which the 1723 packet's destination address is covered by an ASP), the source Client 1724 initiates an intra-domain AERO route optimization procedure. It is 1725 important to note that this procedure is initiated by the Client; if 1726 the procedure were initiated by the Server, the Server would have no 1727 way of knowing whether the Client was actually able to contact the 1728 correspondent over the route-optimized path. 1730 The procedure is based on an exchange of IPv6 ND messages using a 1731 chain of AERO Servers and Relays as a trust basis. This procedure is 1732 in contrast to the Return Routability procedure required for route 1733 optimization to a correspondent Client located in the Internet as 1734 described in Section 3.22. The following sections specify the AERO 1735 intradomain route optimization procedure. 1737 3.17.1. Reference Operational Scenario 1739 Figure 8 depicts the AERO intradomain route optimization reference 1740 operational scenario, using IPv6 addressing as the example (while not 1741 shown, a corresponding example for IPv4 addressing can be easily 1742 constructed). The figure shows an AERO Relay ('R1'), two AERO 1743 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1744 IPv6 hosts ('H1', 'H2'): 1746 +--------------+ +--------------+ +--------------+ 1747 | Server S1 | | Relay R1 | | Server S2 | 1748 +--------------+ +--------------+ +--------------+ 1749 fe80::2 fe80::1 fe80::3 1750 L2(S1) L2(R1) L2(S2) 1751 | | | 1752 X-----+-----+------------------+-----------------+----+----X 1753 | AERO Link | 1754 L2(A) L2(B) 1755 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1756 +--------------+ +--------------+ 1757 |AERO Client C1| |AERO Client C2| 1758 +--------------+ +--------------+ 1759 2001:DB8:0::/48 2001:DB8:1::/48 1760 | | 1761 .-. .-. 1762 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1763 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1764 (__ EUN )--| Host H1 | | Host H2 |--(__ EUN ) 1765 `-(______)-' +---------+ +---------+ `-(______)-' 1767 Figure 8: AERO Reference Operational Scenario 1769 In Figure 8, Relay ('R1') assigns the address fe80::1 to its AERO 1770 interface with link-layer address L2(R1), Server ('S1') assigns the 1771 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1772 assigns the address fe80::3 with link-layer address L2(S2). Servers 1773 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1774 published list of valid Servers for the AERO link. 1776 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1777 exchange via AERO Server ('S1') then assigns the address 1778 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1779 L2(C1). Client ('C1') configures a default route and neighbor cache 1780 entry via the AERO interface with next-hop address fe80::2 and link- 1781 layer address L2(S1), then sub-delegates the ACP to its attached 1782 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1783 address 2001:db8:0::1. 1785 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1786 exchange via AERO Server ('S2') then assigns the address 1787 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1788 L2(C2). Client ('C2') configures a default route and neighbor cache 1789 entry via the AERO interface with next-hop address fe80::3 and link- 1790 layer address L2(S2), then sub-delegates the ACP to its attached 1791 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1792 address 2001:db8:1::1. 1794 3.17.2. Concept of Operations 1796 Again, with reference to Figure 8, when source host ('H1') sends a 1797 packet to destination host ('H2'), the packet is first forwarded over 1798 the source host's attached EUN to Client ('C1'). Client ('C1') then 1799 forwards the packet via its AERO interface to Server ('S1') and also 1800 sends a Predirect message toward Client ('C2') via Server ('S1'). 1801 Server ('S1') then re-encapsulates and forwards both the packet and 1802 the Predirect message out the same AERO interface toward Client 1803 ('C2') via Relay ('R1'). 1805 When Relay ('R1') receives the packet and Predirect message, it 1806 consults its forwarding table to discover Server ('S2') as the next 1807 hop toward Client ('C2'). Relay ('R1') then forwards both the packet 1808 and the Predirect message to Server ('S2'), which then forwards them 1809 to Client ('C2'). 1811 After Client ('C2') receives the Predirect message, it process the 1812 message and returns a Redirect message toward Client ('C1') via 1813 Server ('S2'). During the process, Client ('C2') also creates or 1814 updates a dynamic neighbor cache entry for Client ('C1'). 1816 When Server ('S2') receives the Redirect message, it re-encapsulates 1817 the message and forwards it on to Relay ('R1'), which forwards the 1818 message on to Server ('S1') which forwards the message on to Client 1819 ('C1'). After Client ('C1') receives the Redirect message, it 1820 processes the message and creates or updates a dynamic neighbor cache 1821 entry for Client ('C2'). 1823 Following the above Predirect/Redirect message exchange, forwarding 1824 of packets from Client ('C1') to Client ('C2') without involving any 1825 intermediate nodes is enabled. The mechanisms that support this 1826 exchange are specified in the following sections. 1828 3.17.3. Message Format 1830 AERO Redirect/Predirect messages use the same format as for ICMPv6 1831 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1832 include a new "Prefix Length" field taken from the low-order 8 bits 1833 of the Redirect message Reserved field. For IPv6, valid values for 1834 the Prefix Length field are 0 through 64; for IPv4, valid values are 1835 0 through 32. The Redirect/Predirect messages are formatted as shown 1836 in Figure 9: 1838 0 1 2 3 1839 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 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | Type (=137) | Code (=0/1) | Checksum | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Reserved | Prefix Length | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | | 1846 + + 1847 | | 1848 + Target Address + 1849 | | 1850 + + 1851 | | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | | 1854 + + 1855 | | 1856 + Destination Address + 1857 | | 1858 + + 1859 | | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Options ... 1862 +-+-+-+-+-+-+-+-+-+-+-+- 1864 Figure 9: AERO Redirect/Predirect Message Format 1866 3.17.4. Sending Predirects 1868 When a Client forwards a packet with a source address from one of its 1869 ACPs toward a destination address covered by an ASP (i.e., toward 1870 another AERO Client connected to the same AERO link), the source 1871 Client MAY send a Predirect message forward toward the destination 1872 Client via the Server. 1874 In the reference operational scenario, when Client ('C1') forwards a 1875 packet toward Client ('C2'), it MAY also send a Predirect message 1876 forward toward Client ('C2'), subject to rate limiting (see 1877 Section 8.2 of [RFC4861]). Client ('C1') prepares the Predirect 1878 message as follows: 1880 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1881 layer address of Client ('C1')). 1883 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1884 link-layer address of Server ('S1')). 1886 o the network-layer source address is set to fe80::2001:db8:0:0 1887 (i.e., the AERO address of Client ('C1')). 1889 o the network-layer destination address is set to fe80::2001:db8:1:0 1890 (i.e., the AERO address of Client ('C2')). 1892 o the Type is set to 137. 1894 o the Code is set to 1 to indicate "Predirect". 1896 o the Prefix Length is set to the length of the prefix to be 1897 assigned to the Target Address. 1899 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1900 address of Client ('C1')). 1902 o the Destination Address is set to the source address of the 1903 originating packet that triggered the Predirection event. (If the 1904 originating packet is an IPv4 packet, the address is constructed 1905 in IPv4-compatible IPv6 address format). 1907 o the message includes one or more TLLAOs with Link ID and DSCPs set 1908 to appropriate values for Client ('C1')'s underlying interfaces, 1909 and with UDP Port Number and IP Address set to 0'. 1911 o the message SHOULD include a Timestamp option and a Nonce option. 1913 o the message includes a Redirected Header Option (RHO) that 1914 contains the originating packet truncated if necessary to ensure 1915 that at least the network-layer header is included but the size of 1916 the message does not exceed 1280 bytes. 1918 Note that the act of sending Predirect messages is cited as "MAY", 1919 since Client ('C1') may have advanced knowledge that the direct path 1920 to Client ('C2') would be unusable or otherwise undesirable. If the 1921 direct path later becomes unusable after the initial route 1922 optimization, Client ('C1') simply allows packets to again flow 1923 through Server ('S1'). 1925 3.17.5. Re-encapsulating and Relaying Predirects 1927 When Server ('S1') receives a Predirect message from Client ('C1'), 1928 it first verifies that the TLLAOs in the Predirect are a proper 1929 subset of the Link IDs in Client ('C1')'s neighbor cache entry. If 1930 the Client's TLLAOs are not acceptable, Server ('S1') discards the 1931 message. Otherwise, Server ('S1') validates the message according to 1932 the ICMPv6 Redirect message validation rules in Section 8.1 of 1933 [RFC4861], except that the Predirect has Code=1. Server ('S1') also 1934 verifies that Client ('C1') is authorized to use the Prefix Length in 1935 the Predirect when applied to the AERO address in the network-layer 1936 source address by searching for the AERO address in the neighbor 1937 cache. If validation fails, Server ('S1') discards the Predirect; 1938 otherwise, it copies the correct UDP Port numbers and IP Addresses 1939 for Client ('C1')'s links into the (previously empty) TLLAOs. 1941 Server ('S1') then examines the network-layer destination address of 1942 the Predirect to determine the next hop toward Client ('C2') by 1943 searching for the AERO address in the neighbor cache. Since Client 1944 ('C2') is not one of its neighbors, Server ('S1') re-encapsulates the 1945 Predirect and relays it via Relay ('R1') by changing the link-layer 1946 source address of the message to 'L2(S1)' and changing the link-layer 1947 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1948 re-encapsulated message to Relay ('R1') without decrementing the 1949 network-layer TTL/Hop Limit field. 1951 When Relay ('R1') receives the Predirect message from Server ('S1') 1952 it determines that Server ('S2') is the next hop toward Client ('C2') 1953 by consulting its forwarding table. Relay ('R1') then re- 1954 encapsulates the Predirect while changing the link-layer source 1955 address to 'L2(R1)' and changing the link-layer destination address 1956 to 'L2(S2)'. Relay ('R1') then relays the Predirect via Server 1957 ('S2'). 1959 When Server ('S2') receives the Predirect message from Relay ('R1') 1960 it determines that Client ('C2') is a neighbor by consulting its 1961 neighbor cache. Server ('S2') then re-encapsulates the Predirect 1962 while changing the link-layer source address to 'L2(S2)' and changing 1963 the link-layer destination address to 'L2(C2)'. Server ('S2') then 1964 forwards the message to Client ('C2'). 1966 3.17.6. Processing Predirects and Sending Redirects 1968 When Client ('C2') receives the Predirect message, it accepts the 1969 Predirect only if the message has a link-layer source address of one 1970 of its Servers (e.g., L2(S2)). Client ('C2') further accepts the 1971 message only if it is willing to serve as a redirection target. 1972 Next, Client ('C2') validates the message according to the ICMPv6 1973 Redirect message validation rules in Section 8.1 of [RFC4861], except 1974 that it accepts the message even though Code=1 and even though the 1975 network-layer source address is not that of it's current first-hop 1976 router. 1978 In the reference operational scenario, when Client ('C2') receives a 1979 valid Predirect message, it either creates or updates a dynamic 1980 neighbor cache entry that stores the Target Address of the message as 1981 the network-layer address of Client ('C1') , stores the link-layer 1982 addresses found in the TLLAOs as the link-layer addresses of Client 1983 ('C1') and stores the Prefix Length as the length to be applied to 1984 the network-layer address for forwarding purposes. Client ('C2') 1985 then sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1987 After processing the message, Client ('C2') prepares a Redirect 1988 message response as follows: 1990 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1991 layer address of Client ('C2')). 1993 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1994 link-layer address of Server ('S2')). 1996 o the network-layer source address is set to fe80::2001:db8:1:0 1997 (i.e., the AERO address of Client ('C2')). 1999 o the network-layer destination address is set to fe80::2001:db8:0:0 2000 (i.e., the AERO address of Client ('C1')). 2002 o the Type is set to 137. 2004 o the Code is set to 0 to indicate "Redirect". 2006 o the Prefix Length is set to the length of the prefix to be applied 2007 to the Target Address. 2009 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 2010 address of Client ('C2')). 2012 o the Destination Address is set to the destination address of the 2013 originating packet that triggered the Redirection event. (If the 2014 originating packet is an IPv4 packet, the address is constructed 2015 in IPv4-compatible IPv6 address format). 2017 o the message includes one or more TLLAOs with Link ID and DSCPs set 2018 to appropriate values for Client ('C2')'s underlying interfaces, 2019 and with UDP Port Number and IP Address set to '0'. 2021 o the message SHOULD include a Timestamp option and MUST echo the 2022 Nonce option received in the Predirect (i.e., if a Nonce option is 2023 included). 2025 o the message includes as much of the RHO copied from the 2026 corresponding AERO Predirect message as possible such that at 2027 least the network-layer header is included but the size of the 2028 message does not exceed 1280 bytes. 2030 After Client ('C2') prepares the Redirect message, it sends the 2031 message to Server ('S2'). 2033 3.17.7. Re-encapsulating and Relaying Redirects 2035 When Server ('S2') receives a Redirect message from Client ('C2'), it 2036 first verifies that the TLLAOs in the Redirect are a proper subset of 2037 the Link IDs in Client ('C2')'s neighbor cache entry. If the 2038 Client's TLLAOs are not acceptable, Server ('S2') discards the 2039 message. Otherwise, Server ('S2') validates the message according to 2040 the ICMPv6 Redirect message validation rules in Section 8.1 of 2041 [RFC4861]. Server ('S2') also verifies that Client ('C2') is 2042 authorized to use the Prefix Length in the Redirect when applied to 2043 the AERO address in the network-layer source address by searching for 2044 the AERO address in the neighbor cache. If validation fails, Server 2045 ('S2') discards the Predirect; otherwise, it copies the correct UDP 2046 Port numbers and IP Addresses for Client ('C2')'s links into the 2047 (previously empty) TLLAOs. 2049 Server ('S2') then examines the network-layer destination address of 2050 the Predirect to determine the next hop toward Client ('C2') by 2051 searching for the AERO address in the neighbor cache. Since Client 2052 ('C2') is not a neighbor, Server ('S2') re-encapsulates the Predirect 2053 and relays it via Relay ('R1') by changing the link-layer source 2054 address of the message to 'L2(S2)' and changing the link-layer 2055 destination address to 'L2(R1)'. Server ('S2') finally forwards the 2056 re-encapsulated message to Relay ('R1') without decrementing the 2057 network-layer TTL/Hop Limit field. 2059 When Relay ('R1') receives the Predirect message from Server ('S2') 2060 it determines that Server ('S1') is the next hop toward Client ('C1') 2061 by consulting its forwarding table. Relay ('R1') then re- 2062 encapsulates the Predirect while changing the link-layer source 2063 address to 'L2(R1)' and changing the link-layer destination address 2064 to 'L2(S1)'. Relay ('R1') then relays the Predirect via Server 2065 ('S1'). 2067 When Server ('S1') receives the Predirect message from Relay ('R1') 2068 it determines that Client ('C1') is a neighbor by consulting its 2069 neighbor cache. Server ('S1') then re-encapsulates the Predirect 2070 while changing the link-layer source address to 'L2(S1)' and changing 2071 the link-layer destination address to 'L2(C1)'. Server ('S1') then 2072 forwards the message to Client ('C1'). 2074 3.17.8. Processing Redirects 2076 When Client ('C1') receives the Redirect message, it accepts the 2077 message only if it has a link-layer source address of one of its 2078 Servers (e.g., ''L2(S1)'). Next, Client ('C1') validates the message 2079 according to the ICMPv6 Redirect message validation rules in 2080 Section 8.1 of [RFC4861], except that it accepts the message even 2081 though the network-layer source address is not that of it's current 2082 first-hop router. Following validation, Client ('C1') then processes 2083 the message as follows. 2085 In the reference operational scenario, when Client ('C1') receives 2086 the Redirect message, it either creates or updates a dynamic neighbor 2087 cache entry that stores the Target Address of the message as the 2088 network-layer address of Client ('C2'), stores the link-layer 2089 addresses found in the TLLAOs as the link-layer addresses of Client 2090 ('C2') and stores the Prefix Length as the length to be applied to 2091 the network-layer address for forwarding purposes. Client ('C1') 2092 then sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 2094 Now, Client ('C1') has a neighbor cache entry with a valid 2095 ForwardTime value, while Client ('C2') has a neighbor cache entry 2096 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 2097 ordinary network-layer data packets directly to Client ('C2') without 2098 involving any intermediate nodes, and Client ('C2') can verify that 2099 the packets came from an acceptable source. (In order for Client 2100 ('C2') to forward packets to Client ('C1'), a corresponding 2101 Predirect/Redirect message exchange is required in the reverse 2102 direction; hence, the mechanism is asymmetric.) 2104 3.17.9. Server-Oriented Redirection 2106 In some environments, the Server nearest the target Client may need 2107 to serve as the redirection target, e.g., if direct Client-to-Client 2108 communications are not possible. In that case, the Server prepares 2109 the Redirect message the same as if it were the destination Client 2110 (see: Section 3.17.6), except that it writes its own link-layer 2111 address in the TLLAO option. The Server must then maintain a dynamic 2112 neighbor cache entry for the redirected source Client. 2114 3.18. Neighbor Unreachability Detection (NUD) 2116 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 2117 unicast NS messages to elicit solicited NA messages from neighbors 2118 the same as described in [RFC4861]. NUD is performed either 2119 reactively in response to persistent L2 errors (see Section 3.14) or 2120 proactively to refresh existing neighbor cache entries. 2122 When an AERO node sends an NS/NA message, it MUST use its link-local 2123 address as the IPv6 source address and the link-local address of the 2124 neighbor as the IPv6 destination address. When an AERO node receives 2125 an NS message or a solicited NA message, it accepts the message if it 2126 has a neighbor cache entry for the neighbor; otherwise, it ignores 2127 the message. 2129 When a source Client is redirected to a target Client it SHOULD 2130 proactively test the direct path by sending an initial NS message to 2131 elicit a solicited NA response. While testing the path, the source 2132 Client can optionally continue sending packets via the Server, 2133 maintain a small queue of packets until target reachability is 2134 confirmed, or (optimistically) allow packets to flow directly to the 2135 target. The source Client SHOULD thereafter continue to proactively 2136 test the direct path to the target Client (see Section 7.3 of 2137 [RFC4861]) periodically in order to keep dynamic neighbor cache 2138 entries alive. 2140 In particular, while the source Client is actively sending packets to 2141 the target Client it SHOULD also send NS messages separated by 2142 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 2143 If the source Client is unable to elicit a solicited NA response from 2144 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 2145 to 0 and resume sending packets via one of its Servers. Otherwise, 2146 the source Client considers the path usable and SHOULD thereafter 2147 process any link-layer errors as a hint that the direct path to the 2148 target Client has either failed or has become intermittent. 2150 When a target Client receives an NS message from a source Client, it 2151 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 2152 otherwise, it discards the NS message. If ForwardTime is non-zero, 2153 the target Client then sends a solicited NA message to the link-layer 2154 address of the source Client; otherwise, it sends the solicited NA 2155 message to the link-layer address of one of its Servers. 2157 When a source Client receives a solicited NA message from a target 2158 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 2159 entry exists; otherwise, it discards the NA message. 2161 When ForwardTime for a dynamic neighbor cache entry expires, the 2162 source Client resumes sending any subsequent packets via a Server and 2163 may (eventually) attempt to re-initiate the AERO redirection process. 2164 When AcceptTime for a dynamic neighbor cache entry expires, the 2165 target Client discards any subsequent packets received directly from 2166 the source Client. When both ForwardTime and AcceptTime for a 2167 dynamic neighbor cache entry expire, the Client deletes the neighbor 2168 cache entry. 2170 3.19. Mobility Management 2172 3.19.1. Announcing Link-Layer Address Changes 2174 When a Client needs to change its link-layer address, e.g., due to a 2175 mobility event, it performs an immediate DHCPv6 Rebind/Reply exchange 2176 via each of its Servers using the new link-layer address as the 2177 source address and with an ALREQ that includes the correct Link ID 2178 and DSCP values. If authentication succeeds, the Server then update 2179 its neighbor cache and sends a DHCPv6 Reply. Note that if the Client 2180 does not issue a DHCPv6 Rebind before the prefix delegation lifetime 2181 expires (e.g., if the Client has been out of touch with the Server 2182 for a considerable amount of time), the Server's Reply will report 2183 NoBinding and the Client must re-initiate the DHCPv6 PD procedure. 2185 Next, the Client sends Predirect messages to each of its 2186 correspondent Client neighbors using the same procedures as specified 2187 in Section 3.17.4. The Client sends the Predirect messages via a 2188 Server the same as if it was performing the initial route 2189 optimization procedure with the correspondent. The Predirect message 2190 will update the correspondent' link layer address mapping for the 2191 Client. 2193 3.19.2. Bringing New Links Into Service 2195 When a Client needs to bring a new underlying interface into service 2196 (e.g., when it activates a new data link), it performs an immediate 2197 Rebind/Reply exchange via each of its Servers using the new link- 2198 layer address as the source address and with an ALREQ that includes 2199 the new Link ID and DSCP values. If authentication succeeds, the 2200 Server then updates its neighbor cache and sends a DHCPv6 Reply. The 2201 Client MAY then send unsolicited NA messages to each of its 2202 correspondent Clients to inform them of the new link-layer address as 2203 described in Section 3.19.1. 2205 3.19.3. Removing Existing Links from Service 2207 When a Client needs to remove an existing underlying interface from 2208 service (e.g., when it de-activates an existing data link), it 2209 performs an immediate Rebind/Reply exchange via each of its Servers 2210 over any available link with an ALDEL that includes the deprecated 2211 Link ID. If authentication succeeds, the Server then updates its 2212 neighbor cache and sends a DHCPv6 Reply. The Client SHOULD then send 2213 unsolicited NA messages to each of its correspondent Clients to 2214 inform them of the deprecated link-layer address as described in 2215 Section 3.19.1. 2217 3.19.4. Moving to a New Server 2219 When a Client associates with a new Server, it performs the Client 2220 procedures specified in Section 3.15.2. 2222 When a Client disassociates with an existing Server, it sends a 2223 DHCPv6 Release message via a new Server to the unicast link-local 2224 network layer address of the old Server. The new Server then writes 2225 its own link-layer address in the DHCPv6 Release message IP source 2226 address and forwards the message to the old Server. 2228 When the old Server receives the DHCPv6 Release, first authenticates 2229 the message. Next, it resets the Client's neighbor cache entry 2230 lifetime to 3 seconds, rewrites the link-layer address in the 2231 neighbor cache entry to the address of the new Server, then returns a 2232 DHCPv6 Reply message to the Client via the old Server. When the 2233 lifetime expires, the old Server withdraws the IP route from the AERO 2234 routing system and deletes the neighbor cache entry for the Client. 2235 The Client can then use the Reply message to verify that the 2236 termination signal has been processed, and can delete both the 2237 default route and the neighbor cache entry for the old Server. (Note 2238 that since Release/Reply messages may be lost in the network the 2239 Client MUST retry until it gets a Reply indicating that the Release 2240 was successful.) 2242 Clients SHOULD NOT move rapidly between Servers in order to avoid 2243 causing excessive oscillations in the AERO routing system. Such 2244 oscillations could result in intermittent reachability for the Client 2245 itself, while causing little harm to the network. Examples of when a 2246 Client might wish to change to a different Server include a Server 2247 that has gone unreachable, topological movements of significant 2248 distance, etc. 2250 3.20. Proxy AERO 2252 Proxy Mobile IPv6 (PMIPv6) [RFC5213][RFC5844][RFC5949] presents a 2253 localized mobility management scheme for use within an access network 2254 domain. It is typically used in WiFi and cellular wireless access 2255 networks, and allows Mobile Nodes (MNs) to receive and retain an IP 2256 address that remains stable within the access network domain without 2257 needing to implement any special mobility protocols. In the PMIPv6 2258 architecture, access network devices known as Mobility Access 2259 Gateways (MAGs) provide MNs with an access link abstraction and 2260 receive prefixes for the MNs from a Local Mobility Anchor (LMA). 2262 In a proxy AERO domain, a proxy AERO Client (acting as a MAG) can 2263 similarly provide proxy services for MNs that do not participate in 2264 AERO messaging. The proxy Client presents an access link abstraction 2265 to MNs, and performs DHCPv6 PD exchanges over the AERO interface with 2266 an AERO Server (acting as an LMA) to receive ACPs for address 2267 provisioning of new MNs that come onto an access link. This scheme 2268 assumes that proxy Clients act as fixed (non-mobile) infrastructure 2269 elements under the same administrative trust basis as for Relays and 2270 Servers. 2272 When an MN comes onto an access link within a proxy AERO domain for 2273 the first time, the proxy Client authenticates the MN and obtains a 2274 unique identifier that it can use as a DHCPv6 DUID then issues a 2275 DHCPv6 PD Solicit/Request to its Server. When the Server delegates 2276 an ACP, the proxy Client creates an AERO address for the MN and 2277 assigns the ACP to the MN's access link. The proxy Client then 2278 configures itself as a default router for the MN and provides address 2279 autoconfiguration services (e.g., SLAAC, DHCPv6, DHCPv4, etc.) for 2280 provisioning MN addresses from the ACP over the access link. Since 2281 the proxy Client may serve many such MNs simultaneously, it may 2282 receive multiple ACP prefix delegations and configure multiple AERO 2283 addresses, i.e., one for each MN. 2285 When two MNs are associated with the same proxy Client, the Client 2286 can forward traffic between the MNs without involving a Server since 2287 it configures the AERO addresses of both MNs and therefore also has 2288 the necessary routing information. When two MNs are associated with 2289 different proxy Clients, the source MN's Client can initiate standard 2290 AERO route optimization to discover a direct path to the target MN's 2291 Client through the exchange of Predirect/Redirect messages. 2293 When an MN in a proxy AERO domain leaves an access link provided by 2294 an old proxy Client, the MN issues an access link-specific "leave" 2295 message that informs the old Client of the link-layer address of a 2296 new Client on the planned new access link. This is known as a 2297 "predictive handover". When an MN comes onto an access link provided 2298 by a new proxy Client, the MN issues an access link-specific "join" 2299 message that informs the new Client of the link-layer address of the 2300 old Client on the actual old access link. This is known as a 2301 "reactive handover". 2303 Upon receiving a predictive handover indication, the old proxy Client 2304 sends a DHCPv6 PD Solicit/Request message directly to the new Client 2305 and queues any arriving data packets addressed to the departed MN. 2306 The Solicit/Request message includes the MN's ID as the DUID, the ACP 2307 in an IA_PD option, the old Client's address as the link-layer source 2308 address and the new Client's address as the link-layer destination 2309 address. When the new Client receives the Solicit/Request message, 2310 it changes the link-layer source address to its own address, changes 2311 the link-layer destination address to the address of its Server, and 2312 forwards the message to the Server. At the same time, the new Client 2313 creates access link state for the ACP in anticipation of the MN's 2314 arrival (while queuing any data packets until the MN arrives), 2315 creates a neighbor cache entry for the old Client with AcceptTime set 2316 to ACCEPT_TIME, then sends a Redirect message back to the old Client. 2317 When the old Client receives the Redirect message, it creates a 2318 neighbor cache entry for the new Client with ForwardTime set to 2319 FORWARD_TIME, then forwards any queued data packets to the new 2320 Client. At the same time, the old Client sends a DHCPv6 PD Release 2321 message to its Server. Finally, the old Client sends unsolicited NA 2322 messages to any of the ACP's correspondents with a TLLAO containing 2323 the link-layer address of the new Client. This follows the procedure 2324 specified in Section 3.19.1, except that it is the old Client and not 2325 the Server that supplies the link-layer address. 2327 Upon receiving a reactive handover indication, the new proxy Client 2328 creates access link state for the MN's ACP, sends a DHCPv6 PD 2329 Solicit/Request message to its Server, and sends a DHCPv6 PD Release 2330 message directly to the old Client. The Release message includes the 2331 MN's ID as the DUID, the ACP in an IA_PD option, the new Client's 2332 address as the link-layer source address and the old Client's address 2333 as the link-layer destination address. When the old Client receives 2334 the Release message, it changes the link-layer source address to its 2335 own address, changes the link-layer destination address to the 2336 address of its Server, and forwards the message to the Server. At 2337 the same time, the old Client sends a Predirect message back to the 2338 new Client and queues any arriving data packets addressed to the 2339 departed MN. When the new Client receives the Predirect, it creates 2340 a neighbor cache entry for the old Client with AcceptTime set to 2341 ACCEPT_TIME, then sends a Redirect message back to the old Client. 2342 When the old Client receives the Redirect message, it creates a 2343 neighbor cache entry for the new Client with ForwardTime set to 2344 FORWARD_TIME, then forwards any queued data packets to the new 2345 Client. Finally, the old Client sends unsolicited NA messages to 2346 correspondents the same as for the predictive case. 2348 When a Server processes a DHCPv6 Solicit/Request message, it creates 2349 a neighbor cache entry for this ACP if none currently exists. If a 2350 neighbor cache entry already exists, however, the Server changes the 2351 link-layer address to the address of the new proxy Client (this 2352 satisfies the case of both the old Client and new Client using the 2353 same Server). 2355 When a Server processes a DHCPv6 Release message, it resets the 2356 neighbor cache entry lifetime for this ACP to 5 seconds if the cached 2357 link-layer address matches the old proxy Client's address. 2358 Otherwise, the Server ignores the Release message (this satisfies the 2359 case of both the old Client and new Client using the same Server). 2361 When a correspondent Client receives an unsolicited NA message, it 2362 changes the link-layer address for the ACP's neighbor cache entry to 2363 the address of the new proxy Client. The correspondent Client then 2364 issues a Predirect/Redirect exchange to establish a new neighbor 2365 cache entry in the new Client. 2367 From an architectural perspective, in addition to the use of DHCPv6 2368 PD and IPv6 ND signaling the AERO approach differs from PMIPv6 in its 2369 use of the NBMA virtual link model instead of point-to-point tunnels. 2370 This provides a more agile interface for Client/Server and Client/ 2371 Client coordinations, and also facilitates simple route optimization. 2372 The AERO routing system is also arranged in such a fashion that 2373 Clients get the same service from any Server they happen to associate 2374 with. This provides a natural fault tolerance and load balancing 2375 capability such as desired for distributed mobility management. 2377 3.21. Extending AERO Links Through Security Gateways 2379 When an enterprise mobile device moves from a campus LAN connection 2380 to a public Internet link, it must re-enter the enterprise via a 2381 security gateway that has both a physical interface connection to the 2382 Internet and a physical interface connection to the enterprise 2383 internetwork. This most often entails the establishment of a Virtual 2384 Private Network (VPN) link over the public Internet from the mobile 2385 device to the security gateway. During this process, the mobile 2386 device supplies the security gateway with its public Internet address 2387 as the link-layer address for the VPN. The mobile device then acts 2388 as an AERO Client to negotiate with the security gateway to obtain 2389 its ACP. 2391 In order to satisfy this need, the security gateway also operates as 2392 an AERO Server with support for AERO Client proxying. In particular, 2393 when a mobile device (i.e., the Client) connects via the security 2394 gateway (i.e., the Server), the Server provides the Client with an 2395 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2396 enterprise campus access link. The Server then replaces the Client's 2397 link-layer source address with the Server's enterprise-facing link- 2398 layer address in all AERO messages the Client sends toward neighbors 2399 on the AERO link. The AERO messages are then delivered to other 2400 devices on the AERO link as if they were originated by the security 2401 gateway instead of by the AERO Client. In the reverse direction, the 2402 AERO messages sourced by devices within the enterprise network can be 2403 forwarded to the security gateway, which then replaces the link-layer 2404 destination address with the Client's link-layer address and replaces 2405 the link-layer source address with its own (Internet-facing) link- 2406 layer address. 2408 After receiving the ACP, the Client can send IP packets that use an 2409 address taken from the ACP as the network layer source address, the 2410 Client's link-layer address as the link-layer source address, and the 2411 Server's Internet-facing link-layer address as the link-layer 2412 destination address. The Server will then rewrite the link-layer 2413 source address with the Server's own enterprise-facing link-layer 2414 address and rewrite the link-layer destination address with the 2415 target AERO node's link-layer address, and the packets will enter the 2416 enterprise network as though they were sourced from a device located 2417 within the enterprise. In the reverse direction, when a packet 2418 sourced by a node within the enterprise network uses a destination 2419 address from the Client's ACP, the packet will be delivered to the 2420 security gateway which then rewrites the link-layer destination 2421 address to the Client's link-layer address and rewrites the link- 2422 layer source address to the Server's Internet-facing link-layer 2423 address. The Server then delivers the packet across the VPN to the 2424 AERO Client. In this way, the AERO virtual link is essentially 2425 extended *through* the security gateway to the point at which the VPN 2426 link and AERO link are effectively grafted together by the link-layer 2427 address rewriting performed by the security gateway. All AERO 2428 messaging services (including route optimization and mobility 2429 signaling) are therefore extended to the Client. 2431 In order to support this virtual link grafting, the security gateway 2432 (acting as an AERO Server) must keep static neighbor cache entries 2433 for all of its associated Clients located on the public Internet. 2434 The neighbor cache entry is keyed by the AERO Client's AERO address 2435 the same as if the Client were located within the enterprise 2436 internetwork. The neighbor cache is then managed in all ways as 2437 though the Client were an ordinary AERO Client. This includes the 2438 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2439 Unreachability Detection. 2441 Note that the main difference between a security gateway acting as an 2442 AERO Server and an enterprise-internal AERO Server is that the 2443 security gateway has at least one enterprise-internal physical 2444 interface and at least one public Internet physical interface. 2445 Conversely, the enterprise-internal AERO Server has only enterprise- 2446 internal physical interfaces. For this reason security gateway 2447 proxying is needed to ensure that the public Internet link-layer 2448 addressing space is kept separate from the enterprise-internal link- 2449 layer addressing space. This is afforded through a natural extension 2450 of the security association caching already performed for each VPN 2451 client by the security gateway. 2453 3.22. Extending IPv6 AERO Links to the Internet 2455 When an IPv6 host ('H1') with an address from an ACP owned by AERO 2456 Client ('C1') sends packets to a correspondent IPv6 host ('H2'), the 2457 packets eventually arrive at the IPv6 router that owns ('H2')s 2458 prefix. This IPv6 router may or may not be an AERO Client ('C2') 2459 either within the same home network as ('C1') or in a different home 2460 network. 2462 If Client ('C1') is currently located outside the boundaries of its 2463 home network, it will connect back into the home network via a 2464 security gateway acting as an AERO Server. The packets sent by 2465 ('H1') via ('C1') will then be forwarded through the security gateway 2466 then through the home network and finally to ('C2') where they will 2467 be delivered to ('H2'). This could lead to sub-optimal performance 2468 when ('C2') could instead be reached via a more direct route without 2469 involving the security gateway. 2471 Consider the case when host ('H1') has the IPv6 address 2472 2001:db8:1::1, and Client ('C1') has the ACP 2001:db8:1::/64 with 2473 underlying IPv6 Internet address of 2001:db8:1000::1. Also, host 2474 ('H2') has the IPv6 address 2001:db8:2::1, and Client ('C2') has the 2475 ACP 2001:db8:2::/64 with underlying IPv6 address of 2001:db8:2000::1. 2476 Client ('C1') can determine whether 'C2' is indeed also an AERO 2477 Client willing to serve as a route optimization correspondent by 2478 resolving the AAAA records for the DNS FQDN that matches ('H2')s 2479 prefix, i.e.: 2481 '0.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net' 2483 If ('C2') is indeed a candidate correspondent, the FQDN lookup will 2484 return a PTR resource record that contains the domain name for the 2485 AERO link that manages ('C2')s ASP. Client ('C1') can then attempt 2486 route optimization using an approach similar to the Return 2487 Routability procedure specified for Mobile IPv6 (MIPv6) [RFC6275]. 2488 In order to support this process, both Clients MUST intercept and 2489 decapsulate packets that have a subnet router anycast address 2490 corresponding to any of the /64 prefixes covered by their respective 2491 ACPs. 2493 To initiate the process, Client ('C1') creates a specially-crafted 2494 encapsulated AERO Predirect message that will be routed through its 2495 home network then through ('C2')s home network and finally to ('C2') 2496 itself. Client ('C1') prepares the initial message in the exchange 2497 as follows: 2499 o The encapsulating IPv6 header source address is set to 2500 2001:db8:1:: (i.e., the IPv6 subnet router anycast address for 2501 ('C1')s ACP) 2503 o The encapsulating IPv6 header destination address is set to 2504 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2505 ('C2')s ACP) 2507 o The encapsulating IPv6 header is followed by a UDP header with 2508 source and destination port set to 8060 2510 o The encapsulated IPv6 header source address is set to 2511 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2513 o The encapsulated IPv6 header destination address is set to 2514 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2516 o The encapsulated AERO Predirect message includes all of the 2517 securing information that would occur in a MIPv6 "Home Test Init" 2518 message (format TBD) 2520 Client ('C1') then further encapsulates the message in the 2521 encapsulating headers necessary to convey the packet to the security 2522 gateway (e.g., through IPsec encapsulation) so that the message now 2523 appears "double-encapsulated". ('C1') then sends the message to the 2524 security gateway, which re-encapsulates and forwards it over the home 2525 network from where it will eventually reach ('C2'). 2527 At the same time, ('C1') creates and sends a second encapsulated AERO 2528 Predirect message that will be routed through the IPv6 Internet 2529 without involving the security gateway. Client ('C1') prepares the 2530 message as follows: 2532 o The encapsulating IPv6 header source address is set to 2533 2001:db8:1000:1 (i.e., the Internet IPv6 address of ('C1')) 2535 o The encapsulating IPv6 header destination address is set to 2536 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2537 ('C2')s ACP) 2539 o The encapsulating IPv6 header is followed by a UDP header with 2540 source and destination port set to 8060 2542 o The encapsulated IPv6 header source address is set to 2543 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2545 o The encapsulated IPv6 header destination address is set to 2546 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2548 o The encapsulated AERO Predirect message includes all of the 2549 securing information that would occur in a MIPv6 "Care-of Test 2550 Init" message (format TBD) 2552 ('C2') will receive both Predirect messages through its home network 2553 then return a corresponding Redirect for each of the Predirect 2554 messages with the source and destination addresses in the inner and 2555 outer headers reversed. The first message includes all of the 2556 securing information that would occur in a MIPv6 "Home Test" message, 2557 while the second message includes all of the securing information 2558 that would occur in a MIPv6 "Care-of Test" message (formats TBD). 2560 When ('C1') receives the Redirect messages, it performs the necessary 2561 security procedures per the MIPv6 specification. It then prepares an 2562 encapsulated NS message that includes the same source and destination 2563 addresses as for the "Care-of Test Init" Predirect message, and 2564 includes all of the securing information that would occur in a MIPv6 2565 "Binding Update" message (format TBD) and sends the message to 2566 ('C2'). 2568 When ('C2') receives the NS message, if the securing information is 2569 correct it creates or updates a neighbor cache entry for ('C1') with 2570 fe80::2001:db8:1:0 as the network-layer address, 2001:db8:1000::1 as 2571 the link-layer address and with AcceptTime set to ACCEPT_TIME. 2572 ('C2') then sends an encapsulated NA message back to ('C1') that 2573 includes the same source and destination addresses as for the "Care- 2574 of Test" Redirect message, and includes all of the securing 2575 information that would occur in a MIPv6 "Binding Acknowledgement" 2576 message (format TBD) and sends the message to ('C1'). 2578 When ('C1') receives the NA message, it creates or updates a neighbor 2579 cache entry for ('C2') with fe80::2001:db8:2:0 as the network-layer 2580 address and 2001:db8:2:: as the link-layer address and with 2581 ForwardTime set to FORWARD_TIME, thus completing the route 2582 optimization in the forward direction. 2584 ('C1') subsequently forwards encapsulated packets with outer source 2585 address 2001:db8:1000::1, with outer destination address 2586 2001:db8:2::, with inner source address taken from the 2001:db8:1::, 2587 and with inner destination address taken from 2001:db8:2:: due to the 2588 fact that it has a securely-established neighbor cache entry with 2589 non-zero ForwardTime. ('C2') subsequently accepts any such 2590 encapsulated packets due to the fact that it has a securely- 2591 established neighbor cache entry with non-zero AcceptTime. 2593 In order to keep neighbor cache entries alive, ('C1') periodically 2594 sends additional NS messages to ('C2') and receives any NA responses. 2595 If ('C1') moves to a different point of attachment after the initial 2596 route optimization, it sends a new secured NS message to ('C2') as 2597 above to update ('C2')s neighbor cache. 2599 If ('C2') has packets to send to ('C1'), it performs a corresponding 2600 route optimization in the opposite direction following the same 2601 procedures described above. In the process, the already-established 2602 unidirectional neighbor cache entries within ('C1') and ('C2') are 2603 updated to include the now-bidirectional information. In particular, 2604 the AcceptTime and ForwardTime variables for both neighbor cache 2605 entries are updated to non-zero values, and the link-layer address 2606 for ('C1')s neighbor cache entry for ('C2') is reset to 2607 2001:db8:2000::1. 2609 Note that two AERO Clients can use full security protocol messaging 2610 instead of Return Routability, e.g., if strong authentication and/or 2611 confidentiality are desired. In that case, security protocol key 2612 exchanges such as specified for MOBIKE [RFC4555] would be used to 2613 establish security associations and neighbor cache entries between 2614 the AERO clients. Thereafter, AERO NS/NA messaging can be used to 2615 maintain neighbor cache entries, test reachability, and to announce 2616 mobility events. If reachability testing fails, e.g., if both 2617 Clients move at roughly the same time, the Clients can tear down the 2618 security association and neighbor cache entries and again allow 2619 packets to flow through their home network. 2621 3.23. Encapsulation Protocol Version Considerations 2623 A source Client may connect only to an IPvX underlying network, while 2624 the target Client connects only to an IPvY underlying network. In 2625 that case, the target and source Clients have no means for reaching 2626 each other directly (since they connect to underlying networks of 2627 different IP protocol versions) and so must ignore any redirection 2628 messages and continue to send packets via the Server. 2630 3.24. Multicast Considerations 2632 When the underlying network does not support multicast, AERO nodes 2633 map IPv6 link-scoped multicast addresses (including 2634 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 2635 Server. 2637 When the underlying network supports multicast, AERO nodes use the 2638 multicast address mapping specification found in [RFC2529] for IPv4 2639 underlying networks and use a direct multicast mapping for IPv6 2640 underlying networks. (In the latter case, "direct multicast mapping" 2641 means that if the IPv6 multicast destination address of the 2642 encapsulated packet is "M", then the IPv6 multicast destination 2643 address of the encapsulating header is also "M".) 2645 3.25. Operation on AERO Links Without DHCPv6 Services 2647 When Servers on the AERO link do not provide DHCPv6 services, 2648 operation can still be accommodated through administrative 2649 configuration of ACPs on AERO Clients. In that case, administrative 2650 configurations of AERO interface neighbor cache entries on both the 2651 Server and Client are also necessary. However, this may interfere 2652 with the ability for Clients to dynamically change to new Servers, 2653 and can expose the AERO link to misconfigurations unless the 2654 administrative configurations are carefully coordinated. 2656 3.26. Operation on Server-less AERO Links 2658 In some AERO link scenarios, there may be no Servers on the link and/ 2659 or no need for Clients to use a Server as an intermediary trust 2660 anchor. In that case, each Client acts as a Server unto itself to 2661 establish neighbor cache entries by performing direct Client-to- 2662 Client IPv6 ND message exchanges, and some other form of trust basis 2663 must be applied so that each Client can verify that the prospective 2664 neighbor is authorized to use its claimed ACP. 2666 When there is no Server on the link, Clients must arrange to receive 2667 ACPs and publish them via a secure alternate prefix delegation 2668 authority through some means outside the scope of this document. 2670 3.27. Manually-Configured AERO Tunnels 2672 In addition to the dynamic neighbor discovery procedures for AERO 2673 link neighbors described above, AERO encapsulation can be applied to 2674 manually-configured tunnels. In that case, the tunnel endpoints use 2675 an administratively-assigned link-local address and exchange NS/NA 2676 messages the same as for dynamically-established tunnels. 2678 3.28. Intradomain Routing 2680 After a tunnel neighbor relationship has been established, neighbors 2681 can use a traditional dynamic routing protocol over the tunnel to 2682 exchange routing information without having to inject the routes into 2683 the AERO routing system. 2685 4. Implementation Status 2687 User-level and kernel-level AERO implementations have been developed 2688 and are undergoing internal testing within Boeing. 2690 5. Next Steps 2692 A new Generic UDP Encapsulation (GUE) format has been specified in 2693 [I-D.herbert-gue-fragmentation] [I-D.ietf-nvo3-gue]. The GUE 2694 encapsulation format will eventually supplant the native AERO UDP 2695 encapsulation format. 2697 Future versions of the spec will explore the subject of DSCP marking 2698 in more detail. 2700 6. IANA Considerations 2702 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2703 AERO in the "enterprise-numbers" registry. 2705 The IANA has assigned the UDP port number "8060" for an earlier 2706 experimental version of AERO [RFC6706]. This document obsoletes 2707 [RFC6706] and claims the UDP port number "8060" for all future use. 2709 No further IANA actions are required. 2711 7. Security Considerations 2713 AERO link security considerations are the same as for standard IPv6 2714 Neighbor Discovery [RFC4861] except that AERO improves on some 2715 aspects. In particular, AERO uses a trust basis between Clients and 2716 Servers, where the Clients only engage in the AERO mechanism when it 2717 is facilitated by a trust anchor. Unless there is some other means 2718 of authenticating the Client's identity (e.g., link-layer security), 2719 AERO nodes SHOULD also use DHCPv6 securing services (e.g., DHCPv6 2720 authentication, Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6], etc.) for 2721 Client authentication and network admission control. In particular, 2722 Clients SHOULD include authenticating information on each 2723 Solicit/Request/Rebind/Release message they send, but omit 2724 authenticating information on Renew messages. Renew messages are 2725 exempt due to the fact that the Renew must already be checked for 2726 having a correct link-layer address and does not update any link- 2727 layer addresses. Therefore, asking the Server to also authenticate 2728 the Renew message would be unnecessary and could result in excessive 2729 processing overhead. 2731 AERO Redirect, Predirect and unsolicited NA messages SHOULD include a 2732 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2733 can use to verify the message time of origin. AERO Predirect, NS and 2734 RS messages SHOULD include a Nonce option (see Section 5.3 of 2735 [RFC3971]) that recipients echo back in corresponding responses. 2737 AERO links must be protected against link-layer address spoofing 2738 attacks in which an attacker on the link pretends to be a trusted 2739 neighbor. Links that provide link-layer securing mechanisms (e.g., 2740 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2741 enterprise network wired LANs) provide a first line of defense that 2742 is often sufficient. In other instances, additional securing 2743 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 2744 [RFC4301] or TLS [RFC5246] may be necessary. 2746 AERO Clients MUST ensure that their connectivity is not used by 2747 unauthorized nodes on their EUNs to gain access to a protected 2748 network, i.e., AERO Clients that act as routers MUST NOT provide 2749 routing services for unauthorized nodes. (This concern is no 2750 different than for ordinary hosts that receive an IP address 2751 delegation but then "share" the address with unauthorized nodes via a 2752 NAT function.) 2754 On some AERO links, establishment and maintenance of a direct path 2755 between neighbors requires secured coordination such as through the 2756 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 2757 security association. 2759 An AERO Client's link-layer address could be rewritten by a link- 2760 layer switching element on the path from the Client to the Server and 2761 not detected by the DHCPv6 security mechanism. However, such a 2762 condition would only be a matter of concern on unmanaged/unsecured 2763 links where the link-layer switching elements themselves present a 2764 man-in-the-middle attack threat. For this reason, IP security MUST 2765 be used when AERO is employed over unmanaged/unsecured links. 2767 8. Acknowledgements 2769 Discussions both on IETF lists and in private exchanges helped shape 2770 some of the concepts in this work. Individuals who contributed 2771 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, 2772 Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, Adrian 2773 Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom Herbert, 2774 Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, 2775 Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2776 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. 2777 Members of the IESG also provided valuable input during their review 2778 process that greatly improved the document. Special thanks go to 2779 Stewart Bryant, Joel Halpern and Brian Haberman for their shepherding 2780 guidance. 2782 This work has further been encouraged and supported by Boeing 2783 colleagues including Dave Bernhardt, Cam Brodie, Balaguruna 2784 Chidambaram, Bruce Cornish, Claudiu Danilov, Wen Fang, Anthony 2785 Gregory, Jeff Holland, Ed King, Gen MacLean, Rob Muszkiewicz, Sean 2786 O'Sullivan, Kent Shuey, Brian Skeen, Mike Slane, Brendan Williams, 2787 Julie Wulff, Yueli Yang, and other members of the BR&T and BIT mobile 2788 networking teams. 2790 Earlier works on NBMA tunneling approaches are found in 2791 [RFC2529][RFC5214][RFC5569]. 2793 Many of the constructs presented in this second edition of AERO are 2794 based on the author's earlier works, including: 2796 o The Internet Routing Overlay Network (IRON) 2797 [RFC6179][I-D.templin-ironbis] 2799 o Virtual Enterprise Traversal (VET) 2800 [RFC5558][I-D.templin-intarea-vet] 2802 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2803 [RFC5320][I-D.templin-intarea-seal] 2805 o AERO, First Edition [RFC6706] 2807 Note that these works cite numerous earlier efforts that are not also 2808 cited here due to space limitations. The authors of those earlier 2809 works are acknowledged for their insights. 2811 9. References 2813 9.1. Normative References 2815 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2816 DOI 10.17487/RFC0768, August 1980, 2817 . 2819 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2820 DOI 10.17487/RFC0791, September 1981, 2821 . 2823 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2824 RFC 792, DOI 10.17487/RFC0792, September 1981, 2825 . 2827 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2828 DOI 10.17487/RFC2003, October 1996, 2829 . 2831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2832 Requirement Levels", BCP 14, RFC 2119, 2833 DOI 10.17487/RFC2119, March 1997, 2834 . 2836 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2837 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2838 December 1998, . 2840 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2841 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2842 December 1998, . 2844 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2845 "Definition of the Differentiated Services Field (DS 2846 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2847 DOI 10.17487/RFC2474, December 1998, 2848 . 2850 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2851 C., and M. Carney, "Dynamic Host Configuration Protocol 2852 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2853 2003, . 2855 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2856 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2857 DOI 10.17487/RFC3633, December 2003, 2858 . 2860 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2861 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2862 DOI 10.17487/RFC3971, March 2005, 2863 . 2865 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2866 for IPv6 Hosts and Routers", RFC 4213, 2867 DOI 10.17487/RFC4213, October 2005, 2868 . 2870 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2871 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2872 DOI 10.17487/RFC4861, September 2007, 2873 . 2875 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2876 Address Autoconfiguration", RFC 4862, 2877 DOI 10.17487/RFC4862, September 2007, 2878 . 2880 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2881 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2882 2011, . 2884 9.2. Informative References 2886 [I-D.herbert-gue-fragmentation] 2887 Herbert, T. and F. Templin, "Fragmentation option for 2888 Generic UDP Encapsulation", draft-herbert-gue- 2889 fragmentation-00 (work in progress), March 2015. 2891 [I-D.ietf-dhc-sedhcpv6] 2892 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 2893 DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress), 2894 June 2015. 2896 [I-D.ietf-nvo3-gue] 2897 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2898 Encapsulation", draft-ietf-nvo3-gue-01 (work in progress), 2899 June 2015. 2901 [I-D.templin-intarea-seal] 2902 Templin, F., "The Subnetwork Encapsulation and Adaptation 2903 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2904 progress), January 2014. 2906 [I-D.templin-intarea-vet] 2907 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2908 templin-intarea-vet-40 (work in progress), May 2013. 2910 [I-D.templin-ironbis] 2911 Templin, F., "The Interior Routing Overlay Network 2912 (IRON)", draft-templin-ironbis-16 (work in progress), 2913 March 2014. 2915 [I-D.vandevelde-idr-remote-next-hop] 2916 Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, 2917 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 2918 hop-09 (work in progress), March 2015. 2920 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 2921 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 2922 . 2924 [RFC1035] Mockapetris, P., "Domain names - implementation and 2925 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2926 November 1987, . 2928 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2929 DOI 10.17487/RFC1191, November 1990, 2930 . 2932 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2933 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2934 . 2936 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2937 selection, and registration of an Autonomous System (AS)", 2938 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 2939 . 2941 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2942 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2943 1996, . 2945 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2946 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2947 . 2949 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2950 Domains without Explicit Tunnels", RFC 2529, 2951 DOI 10.17487/RFC2529, March 1999, 2952 . 2954 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2955 RFC 2675, DOI 10.17487/RFC2675, August 1999, 2956 . 2958 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2959 Malis, "A Framework for IP Based Virtual Private 2960 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2961 . 2963 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2964 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2965 DOI 10.17487/RFC2784, March 2000, 2966 . 2968 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2969 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2970 . 2972 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2973 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2974 . 2976 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2977 of Explicit Congestion Notification (ECN) to IP", 2978 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2979 . 2981 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2982 "DNS Extensions to Support IP Version 6", RFC 3596, 2983 DOI 10.17487/RFC3596, October 2003, 2984 . 2986 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2987 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2988 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2989 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2990 . 2992 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2993 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2994 DOI 10.17487/RFC4271, January 2006, 2995 . 2997 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2998 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2999 2006, . 3001 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3002 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3003 December 2005, . 3005 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3006 Control Message Protocol (ICMPv6) for the Internet 3007 Protocol Version 6 (IPv6) Specification", RFC 4443, 3008 DOI 10.17487/RFC4443, March 2006, 3009 . 3011 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3012 Protocol (LDAP): The Protocol", RFC 4511, 3013 DOI 10.17487/RFC4511, June 2006, 3014 . 3016 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3017 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 3018 . 3020 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 3021 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 3022 . 3024 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3025 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 3026 . 3028 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3029 Errors at High Data Rates", RFC 4963, 3030 DOI 10.17487/RFC4963, July 2007, 3031 . 3033 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 3034 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 3035 DOI 10.17487/RFC4994, September 2007, 3036 . 3038 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 3039 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 3040 RFC 5213, DOI 10.17487/RFC5213, August 2008, 3041 . 3043 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3044 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3045 DOI 10.17487/RFC5214, March 2008, 3046 . 3048 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3049 (TLS) Protocol Version 1.2", RFC 5246, 3050 DOI 10.17487/RFC5246, August 2008, 3051 . 3053 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 3054 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 3055 February 2010, . 3057 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 3058 for the Address Resolution Protocol (ARP)", RFC 5494, 3059 DOI 10.17487/RFC5494, April 2009, 3060 . 3062 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 3063 Route Optimization Requirements for Operational Use in 3064 Aeronautics and Space Exploration Mobile Networks", 3065 RFC 5522, DOI 10.17487/RFC5522, October 2009, 3066 . 3068 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 3069 RFC 5558, DOI 10.17487/RFC5558, February 2010, 3070 . 3072 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 3073 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 3074 January 2010, . 3076 [RFC5720] Templin, F., "Routing and Addressing in Networks with 3077 Global Enterprise Recursion (RANGER)", RFC 5720, 3078 DOI 10.17487/RFC5720, February 2010, 3079 . 3081 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 3082 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 3083 . 3085 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 3086 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 3087 DOI 10.17487/RFC5949, September 2010, 3088 . 3090 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 3091 "Internet Key Exchange Protocol Version 2 (IKEv2)", 3092 RFC 5996, DOI 10.17487/RFC5996, September 2010, 3093 . 3095 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3096 NAT64: Network Address and Protocol Translation from IPv6 3097 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3098 April 2011, . 3100 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 3101 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 3102 . 3104 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 3105 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 3106 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 3107 . 3109 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 3110 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 3111 DOI 10.17487/RFC6221, May 2011, 3112 . 3114 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3115 and A. Bierman, Ed., "Network Configuration Protocol 3116 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3117 . 3119 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 3120 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 3121 2011, . 3123 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 3124 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 3125 DOI 10.17487/RFC6355, August 2011, 3126 . 3128 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 3129 RFC 6422, DOI 10.17487/RFC6422, December 2011, 3130 . 3132 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 3133 for Equal Cost Multipath Routing and Link Aggregation in 3134 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3135 . 3137 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 3138 RFC 6691, DOI 10.17487/RFC6691, July 2012, 3139 . 3141 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3142 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3143 . 3145 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 3146 RFC 6864, DOI 10.17487/RFC6864, February 2013, 3147 . 3149 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3150 UDP Checksums for Tunneled Packets", RFC 6935, 3151 DOI 10.17487/RFC6935, April 2013, 3152 . 3154 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3155 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3156 RFC 6936, DOI 10.17487/RFC6936, April 2013, 3157 . 3159 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 3160 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 3161 May 2013, . 3163 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 3164 with IPv6 Neighbor Discovery", RFC 6980, 3165 DOI 10.17487/RFC6980, August 2013, 3166 . 3168 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 3169 Address Selection Policy Using DHCPv6", RFC 7078, 3170 DOI 10.17487/RFC7078, January 2014, 3171 . 3173 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 3174 October 2014. 3176 Author's Address 3178 Fred L. Templin (editor) 3179 Boeing Research & Technology 3180 P.O. Box 3707 3181 Seattle, WA 98124 3182 USA 3184 Email: fltemplin@acm.org