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