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