idnits 2.17.00 (12 Aug 2021) /tmp/idnits23717/draft-ietf-rtgwg-atn-bgp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (14 February 2022) is 96 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ULA' is mentioned on line 829, but not defined == Unused Reference: 'RFC2784' is defined on line 1035, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-46) exists of draft-templin-6man-aero-38 == Outdated reference: A later version (-61) exists of draft-templin-6man-omni-52 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. L. Templin, Ed. 3 Internet-Draft G. Saccone 4 Intended status: Informational Boeing Research & Technology 5 Expires: 18 August 2022 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 14 February 2022 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-14 16 Abstract 18 The International Civil Aviation Organization (ICAO) is investigating 19 mobile routing solutions for a worldwide Aeronautical 20 Telecommunications Network with Internet Protocol Services (ATN/IPS). 21 The ATN/IPS will eventually replace existing communication services 22 with an IP-based service supporting pervasive Air Traffic Management 23 (ATM) for Air Traffic Controllers (ATC), Airline Operations 24 Controllers (AOC), and all commercial aircraft worldwide. This 25 informational document describes a simple and extensible mobile 26 routing service based on industry-standard BGP to address the ATN/IPS 27 requirements. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 18 August 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 9 65 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 14 66 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 16 67 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 19 68 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 21 69 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 10.1. Public Key Infrastructure (PKI) Considerations . . . . . 22 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 76 12.2. Informative References . . . . . . . . . . . . . . . . . 24 77 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 26 78 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 81 1. Introduction 83 The worldwide Air Traffic Management (ATM) system today uses a 84 service known as Aeronautical Telecommunications Network based on 85 Open Systems Interconnection (ATN/OSI). The service is used to 86 augment controller to pilot voice communications with rudimentary 87 short text command and control messages. The service has seen 88 successful deployment in a limited set of worldwide ATM domains. 90 The International Civil Aviation Organization (ICAO) is now 91 undertaking the development of a next-generation replacement for ATN/ 92 OSI known as Aeronautical Telecommunications Network with Internet 93 Protocol Services (ATN/IPS) [ATN][ATN-IPS]. ATN/IPS will eventually 94 provide an IPv6-based [RFC8200] service supporting pervasive ATM for 95 Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), 96 and all commercial aircraft worldwide. As part of the ATN/IPS 97 undertaking, a new mobile routing service will be needed. This 98 document presents an approach based on the Border Gateway Protocol 99 (BGP) [RFC4271]. 101 Aircraft communicate via wireless aviation data links that typically 102 support much lower data rates than terrestrial wireless and wired- 103 line communications. For example, some Very High Frequency (VHF)- 104 based data links only support data rates on the order of 32Kbps and 105 an emerging L-Band data link that is expected to play a key role in 106 future aeronautical communications only supports rates on the order 107 of 1Mbps. Although satellite data links can provide much higher data 108 rates during optimal conditions, like any other aviation data link 109 they are subject to errors, delay, disruption, signal intermittence, 110 degradation due to atmospheric conditions, etc. The well-connected 111 ground domain ATN/IPS network should therefore treat each safety-of- 112 flight critical packet produced by (or destined to) an aircraft as a 113 precious commodity and strive for an optimized service that provides 114 the highest possible degree of reliability. Furthermore, continuous 115 performance-intensive control messaging services such as BGP peering 116 sessions must be carried only over the well-connected ground domain 117 ATN/IPS network and never over low-end aviation data links. 119 The ATN/IPS is an IP-based overlay network configured over one or 120 more Internetworking underlays ("INETs") maintained by aeronautical 121 network service providers such as ARINC, SITA and Inmarsat. The 122 Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] 123 uses an adaptation layer encapsulation to create a Non-Broadcast, 124 Multiple Access (NBMA) virtual link spanning the entire ATN/IPS. 125 Each aircraft connects to the OMNI link via an OMNI interface 126 configured over the aircraft's underlying physical and/or virtual 127 access network interfaces. 129 Each underlying INET comprises one or more "partitions" where all 130 nodes within a partition can exchange packets with all other nodes, 131 i.e., the partition is connected internally. There is no requirement 132 that each INET partition uses the same IP protocol version nor has 133 consistent IP addressing plans in comparison with other partitions. 134 Instead, the OMNI link sees each partition as a "segment" of a link- 135 layer topology concatenated by a service known as the OMNI Adaptation 136 Layer (OAL) [I-D.templin-6man-omni] based on IPv6 encapsulation 137 [RFC2473]. 139 The IPv6 addressing architecture provides different classes of 140 addresses, including Global Unicast Addresses (GUAs), Unique Local 141 Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. 143 The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from 144 an Internet assigned numbers authority, and each aircraft will 145 receive a Mobile Network Prefix (MNP) delegation from the MSP that 146 accompanies the aircraft wherever it travels. ATCs and AOCs will 147 likewise receive MNPs, but they would typically appear in static (not 148 mobile) deployments such as air traffic control towers, airline 149 headquarters, etc. (Note that while IPv6 GUAs are assumed for ATN/ 150 IPS, IPv4 with public/private address could also be used.) 152 The adaptation layer uses ULAs in the source and destination 153 addresses of adaptation layer IPv6 encapsulation headers. Each ULA 154 includes an MNP in the interface identifier ("MNP-ULA"), as discussed 155 in [I-D.templin-6man-omni]. Due to MNP delegation policies and 156 random node mobility properties, MNP-ULAs are generally not 157 aggregatable in the BGP routing service and are represented as many 158 more-specific prefixes instead of a smaller number of aggregated 159 prefixes. 161 In addition, BGP routing service infrastructure nodes configure 162 administratively-assigned ULAs ("ADM-ULA") that are statically- 163 assigned and derived from a shorter ADM-ULA prefix assigned to their 164 BGP network partitions. Unlike MNP-ULAs, the ADM-ULAs are 165 persistently present and unchanging in the routing system. The BGP 166 routing services therefore establish forwarding table entries based 167 on these MNP-ULAs and ADM-ULAs instead of based on the GUA MNPs 168 themselves. Both ADM-ULAs and MNP-ULAs are used by the OAL for 169 nested encapsulation where the inner IPv6 packet is encapsulated in 170 an IPv6 adaptation layer header with ULA source and destination 171 addresses, which is then encapsulated in an IP header specific to the 172 underlying Internetwork that will carry the actual packet 173 transmission. A high level ATN/IPS network diagram is shown in 174 Figure 1: 176 +------------+ +------------+ +------------+ 177 | Aircraft 1 | | Aircraft 2 | .... | Aircraft N | 178 +------------+ +------------+ +------------+ 179 (OMNI Interface) (OMNI Interface) (OMNI Interface) 180 / \ / \ / \ 181 / \ Aviation / \ Data Links / \ 182 ........................................................... 183 . . 184 . (:::)-. . 185 . .-(::::::::) . 186 . .-(:::: INET 1 ::)-. . 187 . (:::: e.g., IPv6 :::) . 188 . ATN/IPS `-(:::::::::::::)-' IPv6-based . 189 . `-(:::::::-' . 190 . OMNI Adaptation BGP Mobile . 191 . (:::)-. . 192 . Layer Overlay .-(::::::::) Routing Service . 193 . .-(:::: INET 2 ::)-. . 194 . (IPv6 GUAs) (:::: e.g., IPv4 :::) (IPv6 ULAs) . 195 . `-(:::::::::::::)-' . 196 . `-(:::::::-' . 197 . . 198 ............................................................. 199 | Fixed | Data Links | 200 | | | 201 (OMNI Interface) (OMNI Interface) (OMNI Interface) 202 +------------+ +------------+ +------------+ 203 | ATC/AOC 1 | | ATC/AOC 2 | .... | ATC/AOC M | 204 +------------+ +------------+ +------------+ 206 Figure 1: ATN/IPS Network Diagram 208 Connexion By Boeing [CBB] was an early aviation mobile routing 209 service based on dynamic updates in the global public Internet BGP 210 routing system. Practical experience with the approach has shown 211 that frequent injections and withdrawals of prefixes in the Internet 212 routing system can result in excessive BGP update messaging, slow 213 routing table convergence times, and extended outages when no route 214 is available. This is due to both conservative default BGP protocol 215 timing parameters (see Section 6) and the complex peering 216 interconnections of BGP routers within the global Internet 217 infrastructure. The situation is further exacerbated by frequent 218 aircraft mobility events that each result in BGP updates that must be 219 propagated to all BGP routers in the Internet that carry a full 220 routing table. 222 We therefore consider an approach using a BGP overlay network routing 223 system where a private BGP routing protocol instance is maintained 224 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 225 private BGP instance does not interact with the native BGP routing 226 systems in underlying INETs, and BGP updates are unidirectional from 227 "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a 228 hub-and-spokes topology. No extensions to the BGP protocol are 229 necessary, and BGP routing is based on (intermediate-layer) ULAs 230 instead of upper- or lower-layer public/private IP prefixes. This 231 allows ASBRs to perform adaptation layer forwarding based on 232 intermediate layer IPv6 header information instead of network layer 233 forwarding based on upper layer IP header information or link layer 234 forwarding based on lower layer IP header information. 236 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 237 dedicated high speed links and/or secured tunnels (e.g., IPsec 238 [RFC4301], WireGuard [WG], etc.) over the underlying INET. 239 Neighboring ASBRs should use also such IP layer security 240 encapsulations over direct physical links to ensure INET layer 241 security. 243 The s-ASBRs engage in external BGP (eBGP) peerings with their 244 respective c-ASBRs, and only maintain routing table entries for the 245 MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP 246 updates for MNP-ULA injections or withdrawals to c-ASBRs but do not 247 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 248 default routes with their c-ASBRs as the next hop, and therefore hold 249 only partial topology information. 251 The c-ASBRs connect to other c-ASBRs within the same partition using 252 internal BGP (iBGP) peerings over which they collaboratively maintain 253 a full routing table for all active MNP-ULAs currently in service 254 within the partition. Therefore, only the c-ASBRs maintain a full 255 BGP routing table and never send any BGP updates to s-ASBRs. This 256 simple routing model therefore greatly reduces the number of BGP 257 updates that need to be synchronized among peers, and the number is 258 reduced further still when intradomain routing changes within stub 259 ASes are processed within the AS instead of being propagated to the 260 core. BGP Route Reflectors (RRs) [RFC4456] can also be used to 261 support increased scaling properties. 263 When there are multiple INET partitions, the c-ASBRs of each 264 partition use eBGP to peer with the c-ASBRs of other partitions so 265 that the full set of ULAs for all partitions are known globally among 266 all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA 267 which is taken from an ADM-ULA prefix assigned to each partition, as 268 well as static forwarding table entries for all other OMNI link 269 partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL 270 for nested encapsulation where the inner IPv6 packet is encapsulated 271 in an IPv6 OAL header with ULA source and destination addresses, 272 which is then encapsulated in an IP header specific to the INET 273 partition. 275 With these intra- and inter-INET BGP peerings in place, a forwarding 276 plane spanning tree is established that properly covers the entire 277 operating domain. All nodes in the network can be visited using 278 strict spanning tree hops, but in many instances this may result in 279 longer paths than are necessary. AERO [I-D.templin-6man-aero] 280 provides an example service for discovering and utilizing (route- 281 optimized) shortcuts that do not always follow strict spanning tree 282 paths. 284 The remainder of this document discusses the proposed BGP-based ATN/ 285 IPS mobile routing service. 287 2. Terminology 289 The terms Autonomous System (AS) and Autonomous System Border Router 290 (ASBR) are the same as defined in [RFC4271]. 292 The following terms are defined for the purposes of this document: 294 Air Traffic Management (ATM) 295 The worldwide service for coordinating safe aviation operations. 297 Air Traffic Controller (ATC) 298 A government agent responsible for coordinating with aircraft 299 within a defined operational region via voice and/or data Command 300 and Control messaging. 302 Airline Operations Controller (AOC) 303 An airline agent responsible for tracking and coordinating with 304 aircraft within their fleet. 306 Aeronautical Telecommunications Network with Internet Protocol 307 Services (ATN/IPS) 308 A future aviation network for ATCs and AOCs to coordinate with all 309 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 310 overlay network service that connects access networks via 311 tunneling over one or more Internetworking underlays. 313 Internetworking underlay ("INET") 314 A wide-area network that supports overlay network tunneling and 315 connects Radio Access Networks to the rest of the ATN/IPS. 316 Example INET service providers for civil aviation include ARINC, 317 SITA and Inmarsat. 319 (Radio) Access Network ("ANET") 320 An aviation radio data link service provider's network, including 321 radio transmitters and receivers as well as supporting ground- 322 domain infrastructure needed to convey a customer's data packets 323 to outside INETs. The term ANET is intended in the same spirit as 324 for radio-based Internet service provider networks (e.g., cellular 325 operators), but can also refer to ground-domain networks that 326 connect AOCs and ATCs. 328 partition (or "segment") 329 A fully-connected internal subnetwork of an INET in which all 330 nodes can communicate with all other nodes within the same 331 partition using the same IP protocol version and addressing plan. 332 Each INET consists of one or more partitions. 334 Overlay Multilink Network Interface (OMNI) 335 A virtual layer 2 bridging service that presents an ATN/IPS 336 overlay unified link view even though the underlay may consist of 337 multiple INET partitions. The OMNI virtual link is manifested 338 through nested encapsulation in which original IP packets from the 339 ATN/IPS are first encapsulated in ULA-addressed IPv6 headers which 340 are then forwarded to the next hop using INET encapsulation if 341 necessary. Forwarding over the OMNI virtual link is therefore 342 based on ULAs instead of the original IP addresses. In this way, 343 packets sent from a source can be conveyed over the OMNI virtual 344 link even though there may be many underlying INET partitions in 345 the path to the destination. 347 OMNI Adaptation Layer (OAL) 348 A middle layer below the IP layer but above the INET layer that 349 applies IP-in-IPv6 encapsulation prior to INET encapsulation. The 350 IPv6 encapsulation header inserted by the OAL uses ULAs instead of 351 GUAs. End systems that configure OMNI interfaces act as OAL 352 ingress and egress points, while intermediate systems with OMNI 353 interfaces act as OAL forwarding nodes. There may be zero, one or 354 many intermediate nodes between the OAL ingress and egress, but 355 the upper layer IPv6 Hop Limit is not decremented during (OAL 356 layer) forwarding. Further details on OMNI and the OAL are found 357 in [I-D.templin-6man-omni]. 359 OAL Autonomous System (OAL AS) 360 A "hub-of-hubs" autonomous system maintained through peerings 361 between the core autonomous systems of different OMNI virtual link 362 partitions. 364 Core Autonomous System Border Router (c-ASBR) 365 A BGP router located in the hub of the INET partition hub-and- 366 spokes overlay network topology. 368 Core Autonomous System (Core AS) 369 The "hub" autonomous system maintained by all c-ASBRs within the 370 same partition. 372 Stub Autonomous System Border Router (s-ASBR) 373 A BGP router configured as a spoke in the INET partition hub-and- 374 spokes overlay network topology. 376 Stub Autonomous System (Stub AS) 377 A logical grouping that includes all Clients currently associated 378 with a given s-ASBR. 380 Client 381 An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf 382 node. The Client could be a singleton host, or a router that 383 connects a mobile or fixed network. 385 Proxy/Server 386 An ANET/INET border node that acts as a transparent intermediary 387 between Clients and s-ASBRs. From the Client's perspective, the 388 Proxy/Server presents the appearance that the Client is 389 communicating directly with the s-ASBR. From the s-ASBR's 390 perspective, the Proxy/Server presents the appearance that the 391 s-ASBR is communicating directly with the Client. 393 Mobile Network Prefix (MNP) 394 An IPv6 prefix that is delegated to any ATN/IPS end system, 395 including ATCs, AOCs, and aircraft. 397 Mobility Service Prefix (MSP) 398 An aggregated IP prefix assigned to the ATN/IPS by an Internet 399 assigned numbers authority, and from which all MNPs are delegated 400 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 401 MSP). 403 3. ATN/IPS Routing System 405 The ATN/IPS routing system comprises a private BGP instance 406 coordinated in an overlay network via tunnels between neighboring 407 ASBRs over one or more underlying INETs. The ATN/IPS routing system 408 interacts with underlying INET BGP routing systems only through the 409 static advertisement of a small and unchanging set of MSPs instead of 410 the full dynamically changing set of MNPs. 412 Within each INET partition, each s-ASBR connects a stub AS to the 413 INET partition core using a distinct stub AS Number (ASN). Each 414 s-ASBR further uses eBGP to peer with one or more c-ASBRs. All 415 c-ASBRs are members of the INET partition core AS, and use a shared 416 core ASN. Unique ASNs are assigned according to the standard 32-bit 417 ASN format [RFC4271][RFC6793]. Since the BGP instance does not 418 connect with any INET BGP routing systems, the ASNs can be assigned 419 from the [RFC6996] 32-bit ASN space which reserves 94,967,295 numbers 420 for private use. The ASNs must be allocated and managed by an ATN/ 421 IPS assigned numbers authority established by ICAO, which must ensure 422 that ASNs are responsibly distributed without duplication and/or 423 overlap. 425 The c-ASBRs use iBGP to maintain a synchronized consistent view of 426 all active MNP-ULAs currently in service within the INET partition. 427 Figure 2 below represents the reference INET partition deployment. 428 (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and 429 s-ASBR2) due to space constraints, but the other s-ASBRs should be 430 understood to have similar Stub AS, MNP and eBGP peering 431 arrangements.) The solution described in this document is flexible 432 enough to extend to these topologies. 434 ........................................................... 435 . . 436 . (:::)-. <- Stub ASes -> (:::)-. . 437 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 438 . `-(::::)-' `-(::::)-' . 439 . +-------+ +-------+ . 440 . |s-ASBR1+-----+ +-----+s-ASBR2| . 441 . +--+----+ eBGP \ / eBGP +-----+-+ . 442 . \ \/ / . 443 . \eBGP / \ /eBGP . 444 . \ / \ / . 445 . +-------+ +-------+ . 446 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 447 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 448 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 449 . +-------+ .-(::::::::) +-------+ . 450 . . .-(::::::::::::::)-. . . 451 . . (:::: Core AS :::) . . 452 . +-------+ `-(:::::::::::::)-' +-------+ . 453 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 454 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 455 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 456 . +-------+ +-------+ . 457 . / \ . 458 . /eBGP \eBGP . 459 . / \ . 460 . +---+---+ +-----+-+ . 461 . |s-ASBR | |s-ASBR | . 462 . +-------+ +-------+ . 463 . . 464 . . 465 . <----------------- INET Partition -------------------> . 466 ............................................................ 468 Figure 2: INET Partition Reference Deployment 470 In the reference deployment, each s-ASBR maintains routes for active 471 MNP-ULAs that currently belong to its stub AS. In response to 472 "Inter-domain" mobility events, each s-ASBR dynamically announces new 473 MNP-ULAs and withdraws departed MNP-ULAs in its eBGP updates to 474 c-ASBRs. Since ATN/IPS end systems are expected to remain within the 475 same stub AS for extended timeframes, however, intra-domain mobility 476 events (such as an aircraft handing off between cell towers) are 477 handled within the stub AS instead of being propagated as inter- 478 domain eBGP updates. 480 Each c-ASBR configures a black-hole route for each of its MSPs. By 481 black-holing the MSPs, the c-ASBR maintains forwarding table entries 482 only for the MNP-ULAs that are currently active. If an arriving 483 packet matches a black-hole route without matching an MNP-ULA, the 484 c-ASBR should drop the packet and may also generate an ICMPv6 485 Destination Unreachable message [RFC4443], i.e., without forwarding 486 the packet outside of the ATN/IPS overlay based on a less-specific 487 route. 489 The c-ASBRs do not send BGP updates for MNP-ULAs to s-ASBRs, but 490 instead originate a default route. In this way, s-ASBRs have only 491 partial topology knowledge (i.e., they know only about the active 492 MNP-ULAs currently within their stub ASes) and they forward all other 493 packets to c-ASBRs which have full topology knowledge. 495 Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable 496 within an INET partition, and each partition configures a unique ADM- 497 ULA prefix that is permanently announced into the routing system. 498 The core ASes of each INET partition are joined together through 499 external BGP peerings. The c-ASBRs of each partition establish 500 external peerings with the c-ASBRs of other partitions to form a 501 "core-of-cores" OMNI link AS. The OMNI link AS contains the global 502 knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS 503 overlay communications between nodes located in different INET 504 partitions by virtue of OAL encapsulation. OMNI link nodes can then 505 navigate to ASBRs by including an ADM-ULA or directly to an end 506 system by including an MNP-ULA in the destination address of an OAL- 507 encapsulated packet (see: [I-D.templin-6man-aero]). Figure 3 shows a 508 reference OAL topology. 510 . . . . . . . . . . . . . . . . . . . . . . . . . 511 . . 512 . .-(::::::::) . 513 . .-(::::::::::::)-. +------+ . 514 . (::: Partition 1 ::)--|c-ASBR|---+ . 515 . `-(::::::::::::)-' +------+ | . 516 . `-(::::::)-' | . 517 . | . 518 . .-(::::::::) | . 519 . .-(::::::::::::)-. +------+ | . 520 . (::: Partition 2 ::)--|c-ASBR|---+ . 521 . `-(::::::::::::)-' +------+ | . 522 . `-(::::::)-' | . 523 . | . 524 . .-(::::::::) | . 525 . .-(::::::::::::)-. +------+ | . 526 . (::: Partition 3 ::)--|c-ASBR|---+ . 527 . `-(::::::::::::)-' +------+ | . 528 . `-(::::::)-' | . 529 . | . 530 . ..(etc).. x . 531 . . 532 . . 533 . <- ATN/IPS Overlay Bridged by the OAL AS -> . 534 . . . . . . . . . . . . . .. . . . . . . . . . . . 536 Figure 3: Spanning Partitions with the OAL 538 Scaling properties of this ATN/IPS routing system are limited by the 539 number of BGP routes that can be carried by the c-ASBRs. A 2015 540 study showed that BGP routers in the global public Internet at that 541 time carried more than 500K routes with linear growth and no signs of 542 router resource exhaustion [BGP]. A more recent network emulation 543 study also showed that a single c-ASBR can accommodate at least 1M 544 dynamically changing BGP routes even on a lightweight virtual 545 machine. Commercially-available high-performance dedicated router 546 hardware can support many millions of routes. 548 Therefore, assuming each c-ASBR can carry 1M or more routes, this 549 means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by 550 a single set of c-ASBRs and that number could be further increased by 551 using RRs and/or more powerful routers. Another means of increasing 552 scale would be to assign a different set of c-ASBRs for each set of 553 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 554 from each set of c-ASBRs, but the s-ASBR institutes route filters so 555 that it only sends BGP updates to the specific set of c-ASBRs that 556 aggregate the MSP. In this way, each set of c-ASBRs maintains 557 separate routing and forwarding tables so that scaling is distributed 558 across multiple c-ASBR sets instead of concentrated in a single 559 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 560 segment A::/32, a second set could aggregate B::/32, a third could 561 aggregate C::/32, etc. The union of all MSP segments would then 562 constitute the collective MSP(s) for the entire ATN/IPS, with 563 potential for supporting many millions of mobile networks or more. 565 In this way, each set of c-ASBRs services a specific set of MSPs, and 566 each s-ASBR configures MSP-specific routes that list the correct set 567 of c-ASBRs as next hops. This design also allows for natural 568 incremental deployment, and can support initial medium-scale 569 deployments followed by dynamic deployment of additional ATN/IPS 570 infrastructure elements without disturbing the already-deployed base. 571 For example, a few more c-ASBRs could be added if the MNP service 572 demand ever outgrows the initial deployment. For larger-scale 573 applications (such as unmanned air vehicles and terrestrial vehicles) 574 even larger scales can be accommodated by adding more c-ASBRs. 576 4. ATN/IPS (Radio) Access Network (ANET) Model 578 (Radio) Access Networks (ANETs) connect end system Clients such as 579 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 580 connect to multiple ANETs at once, for example, when they have both 581 satellite and cellular data links activated simultaneously. Clients 582 configure an Overlay Multilink Network (OMNI) Interface 583 [I-D.templin-6man-omni] over their underlying ANET interfaces as a 584 connection to an NBMA virtual link (manifested by the OAL) that spans 585 the entire ATN/IPS. Clients may further move between ANETs in a 586 manner that is perceived as a network layer mobility event. Clients 587 could therefore employ a multilink/mobility routing service such as 588 those discussed in Section 7. 590 Clients register all of their active data link connections with their 591 serving s-ASBRs as discussed in Section 3. Clients may connect to 592 s-ASBRs either directly, or via a Proxy/Server at the ANET/INET 593 boundary. 595 Figure 4 shows the ATN/IPS ANET model where Clients connect to ANETs 596 via aviation data links. Clients register their ANET addresses with 597 a nearby s-ASBR, where the registration process may be brokered by a 598 Proxy/Server at the edge of the ANET. 600 +-----------------+ 601 | Client | 602 Data Link "A" +-----------------+ Data Link "B" 603 +----- | OMNI Interface |--------+ 604 / +-----------------+ \ 605 / \ 606 / \ 607 (:::)-. (:::)-. 608 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 609 `-(::::)-' `-(::::)-' 610 +-------+ +-------+ 611 ... | P/S | ............................ | P/S | ... 612 . +-------+ +-------+ . 613 . ^^ ^^ . 614 . || || . 615 . || +--------+ || . 616 . ++============> | s-ASBR | <============++ . 617 . +--------+ . 618 . | eBGP . 619 . (:::)-. . 620 . .-(::::::::) . 621 . .-(::: ATN/IPS :::)-. . 622 . (::::: BGP Routing ::::) . 623 . `-(:: System ::::)-' . 624 . `-(:::::::-' . 625 . . 626 . . 627 . <------- OMNI virtual link bridged by the OAL --------> . 628 ............................................................ 630 Figure 4: ATN/IPS ANET Architecture 632 When a Client connects to an ANET it specifies a nearby s-ASBR that 633 it has selected to connect to the ATN/IPS. The login process is 634 transparently brokered by a Proxy/Server at the border of the ANET 635 which then conveys the connection request to the s-ASBR via tunneling 636 across the OMNI virtual link. Each ANET border Proxy/Server is also 637 equally capable of serving in the s-ASBR role so that a first on-link 638 Proxy/Server can be selected as the s-ASBR while all others perform 639 the Proxy/Server role in a hub-and-spokes arrangement. An on-link 640 Proxy/Server is selected to serve the s-ASBR role when it receives a 641 control message from a Client requesting that service. 643 The Client can coordinate with a network-based s-ASBR over additional 644 ANETs after it has already coordinated with a first-hop Proxy/Server 645 over a first ANET. If the Client connects to multiple ANETs, the 646 s-ASBR will register the individual ANET Proxy/Servers as conduits 647 through which the Client can be reached. The Client then sees the 648 s-ASBR as the "hub" in a "hub-and-spokes" arrangement with the first- 649 hop Proxy/Servers as spokes. Selection of a network-based s-ASBR is 650 through the discovery methods specified in relevant mobility and 651 virtual link coordination specifications (e.g., see AERO 652 [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni]). 654 The s-ASBR represents all of its active Clients as MNP-ULA routes in 655 the ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore 656 used only to advertise the set of MNPs of all its active Clients to 657 its BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the 658 stub AS is a logical construct and not a physical one). The s-ASBR 659 injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs 660 of its departed Clients via BGP updates to c-ASBRs, which further 661 propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since 662 Clients are expected to remain associated with their current s-ASBR 663 for extended periods, the level of MNP-ULA injections and withdrawals 664 in the BGP routing system will be on the order of the numbers of 665 network joins, leaves and s-ASBR handovers for aircraft operations 666 (see: Section 6). It is important to observe that fine-grained 667 events such as Client mobility and Quality of Service (QoS) signaling 668 are coordinated only by Proxies and the Client's current s-ASBRs, and 669 do not involve other ASBRs in the routing system. In this way, 670 intradomain routing changes within the stub AS are not propagated 671 into the rest of the ATN/IPS BGP routing system. 673 5. ATN/IPS Route Optimization 675 ATN/IPS end systems will frequently need to communicate with 676 correspondents associated with other s-ASBRs. In the BGP peering 677 topology discussed in Section 3, this can initially only be 678 accommodated by including multiple extraneous hops and/or spanning 679 tree segments in the forwarding path. In many cases, it would be 680 desirable to establish a "short cut" around this "dogleg" route so 681 that packets can traverse a minimum number of tunneling hops across 682 the OMNI virtual link. ATN/IPS end systems could therefore employ a 683 route optimization service according to the mobility service employed 684 (see: Section 7). 686 Each s-ASBR provides designated routing services for only a subset of 687 all active Clients, and instead acts as a simple Proxy/Server for 688 other Clients. As a designated router, the s-ASBR advertises the 689 MNPs of each of its active Clients into the ATN/IPS routing system 690 and provides basic (unoptimized) forwarding services when necessary. 691 An s-ASBR could be the first-hop ATN/IPS service access point for 692 some, all or none of a Client's underlying interfaces, while the 693 Client's other underlying interfaces employ the Proxy/Server function 694 of other s-ASBRs. Route optimization allows Client-to-Client 695 communications while bypassing s-ASBR designated routing services 696 whenever possible. 698 A route optimization example is shown in Figure 5 and Figure 6 below. 699 In the first figure, multiple spanning tree segments between Proxy/ 700 Servers and ASBRs are necessary to convey packets between Clients 701 associated with different s-ASBRs. In the second figure, the 702 optimized route tunnels packets directly between Proxy/Servers 703 without involving the ASBRs. 705 These route optimized paths are established through secured control 706 plane messaging (i.e., over secured tunnels and/or using higher-layer 707 control message authentications) but do not provide lower-layer 708 security for the data plane. Data communications over these route 709 optimized paths should therefore employ higher-layer security. 711 +---------+ +---------+ 712 | Client1 | | Client2 | 713 +---v-----+ +-----^---+ 714 * * 715 * * 716 (:::)-. (:::)-. 717 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 718 `-(::::)-' `-(::::)-' 719 +--------+ +--------+ 720 ... | P/S-1 | .......................... | P/S-2 | ... 721 . +--------+ +--------+ . 722 . ** ** . 723 . ** ** . 724 . ** ** . 725 . +---------+ +---------+ . 726 . | s-ASBR1 | | s-ASBR2 | . 727 . +--+------+ +-----+---+ . 728 . \ ** Dogleg ** / . 729 . eBGP\ ** Route ** /eBGP . 730 . \ **==============** / . 731 . +---------+ +---------+ . 732 . | c-ASBR1 | | c-ASBR2 | . 733 . +---+-----+ +----+----+ . 734 . +--------------+ . 735 . iBGP . 736 . . 737 . <------- OMNI virtual link bridged by the OAL --------> . 738 ............................................................ 740 Figure 5: Dogleg Route Before Optimization 742 +---------+ +---------+ 743 | Client1 | | Client2 | 744 +---v-----+ +-----^---+ 745 * * 746 * * 747 (:::)-. (:::)-. 748 .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) 749 `-(::::)-' `-(::::)-' 750 +--------+ +--------+ 751 ... | P/S-1 | .......................... | P/S-2 | ... 752 . +------v-+ +--^-----+ . 753 . * * . 754 . *================================* . 755 . . 756 . +---------+ +---------+ . 757 . | s-ASBR1 | | s-ASBR2 | . 758 . +--+------+ +-----+---+ . 759 . \ / . 760 . eBGP\ /eBGP . 761 . \ / . 762 . +---------+ +---------+ . 763 . | c-ASBR1 | | c-ASBR2 | . 764 . +---+-----+ +----+----+ . 765 . +--------------+ . 766 . iBGP . 767 . . 768 . <------- OMNI virtual link bridged by the OAL --------> . 769 ............................................................ 771 Figure 6: Optimized Route 773 6. BGP Protocol Considerations 775 The number of eBGP peering sessions that each c-ASBR must service is 776 proportional to the number of s-ASBRs in its local partition. 777 Network emulations with lightweight virtual machines have shown that 778 a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs 779 that each advertise 10K MNP-ULA routes (i.e., 1M total). It is 780 expected that robust c-ASBRs can service many more peerings than this 781 - possibly by multiple orders of magnitude. But even assuming a 782 conservative limit, the number of s-ASBRs could be increased by also 783 increasing the number of c-ASBRs. Since c-ASBRs also peer with each 784 other using iBGP, however, larger-scale c-ASBR deployments may need 785 to employ an adjunct facility such as BGP Route Reflectors 786 (RRs)[RFC4456]. 788 The number of aircraft in operation at a given time worldwide is 789 likely to be significantly less than 1M, but we will assume this 790 number for a worst-case analysis. Assuming a worst-case average 1 791 hour flight profile from gate-to-gate with 10 service region 792 transitions per flight, the entire system will need to service at 793 most 10M BGP updates per hour (2778 updates per second). This number 794 is within the realm of the peak BGP update messaging seen in the 795 global public Internet today [BGP2]. Assuming a BGP update message 796 size of 100 bytes (800bits), the total amount of BGP control message 797 traffic to a single c-ASBR will be less than 2.5Mbps which is a 798 nominal rate for modern data links. 800 Industry standard BGP routers provide configurable parameters with 801 conservative default values. For example, the default hold time is 802 90 seconds, the default keepalive time is 1/3 of the hold time, and 803 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 804 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 805 For the simple mobile routing system described herein, these 806 parameters can be set to more aggressive values to support faster 807 neighbor/link failure detection and faster routing protocol 808 convergence times. For example, a hold time of 3 seconds and a 809 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 811 Instead of adjusting BGP default time values, BGP routers can use the 812 Bidirectional Forwarding Detection (BFD) protocol [RFC5880] to 813 quickly detect link failures that don't result in interface state 814 changes, BGP peer failures, and administrative state changes. BFD is 815 important in environments where rapid response to failures is 816 required for routing reconvergence and, hence, communications 817 continuity. 819 Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with 820 the ATN/IPS unicast IPv6 routes resolving over INET routes. 821 Consequently, c-ASBRs and potentially s-ASBRs will need to support 822 separate local ASes for the two BGP routing domains and routing 823 policy or assure routes are not propagated between the two BGP 824 routing domains. From a conceptual, operational and correctness 825 standpoint, the implementation should provide isolation between the 826 two BGP routing domains (e.g., separate BGP instances). 828 ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random 829 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 830 OMNI link identifier '*' to form the prefix [ULA*]::/64. Each 831 individual address taken from [ULA*]::/64 includes additional routing 832 information in the interface identifier. For example, for the MNP 833 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 834 and for the administrative address 1001:2002/16 the ADM-ULA is 835 [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further 836 details). This gives rise to a BGP routing system that must 837 accommodate large numbers of long and non-aggregatable MNP-ULA 838 prefixes as well as moderate numbers of long and semi-aggregatable 839 ADM-ULA prefixes. The system is kept stable and scalable through the 840 s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- 841 related churn is not exposed to the core. 843 7. Stub AS Mobile Routing Services 845 Stub ASes maintain intradomain routing information for mobile node 846 clients, and are responsible for all localized mobility signaling 847 without disturbing the BGP routing system. Clients can enlist the 848 services of a candidate mobility service such as Mobile IPv6 (MIPv6) 849 [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] or AERO 850 [I-D.templin-6man-aero] according to the service offered by the stub 851 AS. Further details of mobile routing services are out of scope for 852 this document. 854 8. Implementation Status 856 The BGP routing topology described in this document has been modeled 857 in realistic network emulations showing that at least 1 million MNP- 858 ULAs can be propagated to each c-ASBR even on lightweight virtual 859 machines. No BGP routing protocol extensions need to be adopted. 861 9. IANA Considerations 863 This document does not introduce any IANA considerations. 865 10. Security Considerations 867 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 868 profiles as for any Internet nodes. For this reason, ASBRs should 869 employ physical security and/or IP securing mechanisms such as IPsec 870 [RFC4301], WireGuard [WG], etc. 872 ATN/IPS ASBRs present targets for Distributed Denial of Service 873 (DDoS) attacks. This concern is no different than for any node on 874 the open Internet, where attackers could send spoofed packets to the 875 node at high data rates. This can be mitigated by connecting ATN/IPS 876 ASBRs over dedicated links with no connections to the Internet and/or 877 when ASBR connections to the Internet are only permitted through 878 well-managed firewalls. 880 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 881 aviation data links from receiving DDoS packet floods. 883 BGP protocol message exchanges and control message exchanges used for 884 route optimization must be secured to ensure the integrity of the 885 system-wide routing information base. Security is based on IP layer 886 security associations between peers which ensure confidentiality, 887 integrity and authentication over secured tunnels (see above). 888 Higher layer security protection such as TCP-AO [RFC5926] is 889 therefore optional, since it would be redundant with the security 890 provided at lower layers. 892 Data communications over route optimized paths should employ end-to- 893 end higher-layer security since only the control plane and 894 unoptimized paths are protected by lower-layer security. End-to-end 895 higher-layer security mechanisms include QUIC-TLS [RFC9001], TLS 896 [RFC8446], DTLS [RFC6347], SSH [RFC4251], etc. applied in a manner 897 outside the scope of this document. 899 This document does not include any new specific requirements for 900 mitigation of DDoS. 902 10.1. Public Key Infrastructure (PKI) Considerations 904 In development of the overall ATN/IPS operational concept, ICAO 905 addressed the security concerns in multiple ways to ensure 906 coordination and consistency across the various groups. This also 907 avoided potential duplicative work. Technical provisions related 908 specifically to the operation of ATN/IPS are specified in supporting 909 ATN/IPS standards. However, other considerations such as the 910 establishment of a PKI, were determined to have an impact beyond ATN/ 911 IPS. ICAO created a Trust Framework Study Group (TFSG) to define 912 various governance, policy, procedures and overall technical 913 performance requirements for system connectivity and 914 interoperability. 916 As part of their charter, the TSFG is specifically developing a 917 concept of operations for a common aviation digital trust framework 918 and principles to facilitate an interoperable secure, cyber resilient 919 and seamless exchange of information in a digitally connected 920 environment. They are also developing governance principles, policy, 921 procedures and requirements for establishing digital identity for a 922 global trust framework that will consider any exchange of information 923 among users of the aviation ecosystem, and to promote these concepts 924 with all relevant stakeholders. 926 ATN/IPS will take advantage of the developments of TFSG within the 927 overall ATN/IPS operational concept. As such, this will include the 928 usage of the PKI specification resulting from the TFSG. 930 11. Acknowledgements 932 This work is aligned with the FAA as per the SE2025 contract number 933 DTFAWA-15-D-00030. 935 This work is aligned with the NASA Safe Autonomous Systems Operation 936 (SASO) program under NASA contract number NNA16BD84C. 938 This work is aligned with the Boeing Commercial Airplanes (BCA) 939 Internet of Things (IoT) and autonomy programs. 941 This work is aligned with the Boeing Information Technology (BIT) 942 MobileNet program. 944 The following individuals contributed insights that have improved the 945 document: Ahmad Amin, Mach Chen, Russ Housley, Erik Kline, Hubert 946 Kuenig, Tony Li, Gyan Mishra, Alexandre Petrescu, Dave Thaler, Pascal 947 Thubert, Michael Tuxen, Tony Whyman. 949 12. References 951 12.1. Normative References 953 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 954 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 955 December 1998, . 957 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 958 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 959 . 961 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 962 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 963 DOI 10.17487/RFC4271, January 2006, 964 . 966 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 967 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 968 2006, . 970 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 971 Control Message Protocol (ICMPv6) for the Internet 972 Protocol Version 6 (IPv6) Specification", STD 89, 973 RFC 4443, DOI 10.17487/RFC4443, March 2006, 974 . 976 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 977 Reflection: An Alternative to Full Mesh Internal BGP 978 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 979 . 981 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 982 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 983 . 985 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 986 (IPv6) Specification", STD 86, RFC 8200, 987 DOI 10.17487/RFC8200, July 2017, 988 . 990 12.2. Informative References 992 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 993 Interface for Civil Aviation, IETF Liaison Statement 994 #1676, https://datatracker.ietf.org/liaison/1676/", 3 995 March 2020. 997 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 998 Aeronautical Telecommunication Network (ATN) using 999 Internet Protocol Suite (IPS) Standards and Protocol), 1000 Draft Edition 3 (work-in-progress)", 10 December 2020. 1002 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 1003 2016. 1005 [BGP2] Huston, G., "BGP Instability Report, 1006 http://bgpupdates.potaroo.net/instability/bgpupd.html", 1007 May 2017. 1009 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 1010 Protocol (BGP), http://www.quark.net/docs/ 1011 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 1013 [I-D.ietf-lisp-rfc6830bis] 1014 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1015 Cabellos, "The Locator/ID Separation Protocol (LISP)", 1016 Work in Progress, Internet-Draft, draft-ietf-lisp- 1017 rfc6830bis-36, 18 November 2020, 1018 . 1021 [I-D.templin-6man-aero] 1022 Templin, F. L., "Automatic Extended Route Optimization 1023 (AERO)", Work in Progress, Internet-Draft, draft-templin- 1024 6man-aero-38, 31 December 2021, 1025 . 1028 [I-D.templin-6man-omni] 1029 Templin, F. L. and T. Whyman, "Transmission of IP Packets 1030 over Overlay Multilink Network (OMNI) Interfaces", Work in 1031 Progress, Internet-Draft, draft-templin-6man-omni-52, 31 1032 December 2021, . 1035 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1036 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1037 DOI 10.17487/RFC2784, March 2000, 1038 . 1040 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1041 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 1042 January 2006, . 1044 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1045 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1046 December 2005, . 1048 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 1049 for the TCP Authentication Option (TCP-AO)", RFC 5926, 1050 DOI 10.17487/RFC5926, June 2010, 1051 . 1053 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1054 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1055 2011, . 1057 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1058 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1059 January 2012, . 1061 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1062 Autonomous System (AS) Number Space", RFC 6793, 1063 DOI 10.17487/RFC6793, December 2012, 1064 . 1066 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 1067 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 1068 2013, . 1070 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1071 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1072 . 1074 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1075 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1076 . 1078 [WG] Donenfeld, J., "WireGuard: Fast, Modern, Secure VPN 1079 Tunnel, https://www.wireguard.com/", February 2022. 1081 Appendix A. BGP Convergence Considerations 1083 Experimental evidence has shown that BGP convergence time required 1084 after an MNP-ULA is asserted at a new location or withdrawn from an 1085 old location can be several hundred milliseconds even under optimal 1086 AS peering arrangements. This means that packets in flight destined 1087 to an MNP-ULA route that has recently been changed can be 1088 (mis)delivered to an old s-ASBR after a Client has moved to a new 1089 s-ASBR. 1091 To address this issue, the old s-ASBR can maintain temporary state 1092 for a "departed" Client that includes an OAL address for the new 1093 s-ASBR. The OAL address never changes since ASBRs are fixed 1094 infrastructure elements that never move. Hence, packets arriving at 1095 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 1096 routing system is still undergoing reconvergence. Therefore, as long 1097 as the Client associates with the new s-ASBR before it departs from 1098 the old s-ASBR (while informing the old s-ASBR of its new location) 1099 packets in flight during the BGP reconvergence window are 1100 accommodated without loss. 1102 Appendix B. Change Log 1104 << RFC Editor - remove prior to publication >> 1106 Differences from earlier versions: 1108 * Submit for RFC publication. 1110 Authors' Addresses 1112 Fred L. Templin (editor) 1113 Boeing Research & Technology 1114 P.O. Box 3707 1115 Seattle, WA 98124 1116 United States of America 1117 Email: fltemplin@acm.org 1119 Greg Saccone 1120 Boeing Research & Technology 1121 P.O. Box 3707 1122 Seattle, WA 98124 1123 United States of America 1125 Email: gregory.t.saccone@boeing.com 1127 Gaurav Dawra 1128 LinkedIn 1129 United States of America 1131 Email: gdawra.ietf@gmail.com 1133 Acee Lindem 1134 Cisco Systems, Inc. 1135 United States of America 1137 Email: acee@cisco.com 1139 Victor Moreno 1140 Cisco Systems, Inc. 1141 United States of America 1143 Email: vimoreno@cisco.com