idnits 2.17.00 (12 Aug 2021) /tmp/idnits13635/draft-ietf-rtgwg-atn-bgp-15.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 (5 April 2022) is 46 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ULA' is mentioned on line 833, 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: 7 October 2022 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 5 April 2022 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-15 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 7 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 . . . . . . . . . . . . . . . . . . . . . 26 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 154 aircraft ULA includes an MNP in the interface identifier ("MNP-ULA"), 155 as discussed in [I-D.templin-6man-omni]. Due to MNP delegation 156 policies and random node mobility properties, MNPs 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. The ADM-ULA consists of a 64-bit ULA prefix 165 followed by 32 zero bits followed by the 32-bit ADM suffix. The ADM 166 route injected into the BGP routing service is therefore 0:0:{ADM- 167 Suffix}::/N. Unlike MNPs, ADM-based routes are persistently present 168 and unchanging in the routing system. 170 Both ADM-ULAs and MNP-ULAs are used by the OAL for nested 171 encapsulation where the inner IPv6 packet is encapsulated in an IPv6 172 adaptation layer header with ULA source and destination addresses, 173 which is then encapsulated in an IP header specific to the underlying 174 Internetwork that will carry the actual packet transmission. 175 However, the forwarding table entries established by the BGP routing 176 system will include MNP and/or ADM-Suffix based routes. ATN/IPS 177 infrastructure elements therefore institute a special form of 178 forwarding that matches the 64-bit suffix of the OAL destination 179 address with the forwarding table entry (i.e., and not the 64-bit 180 prefix). 182 A high level ATN/IPS network diagram is shown in Figure 1: 184 +------------+ +------------+ +------------+ 185 | Aircraft 1 | | Aircraft 2 | .... | Aircraft N | 186 +------------+ +------------+ +------------+ 187 (OMNI Interface) (OMNI Interface) (OMNI Interface) 188 / \ / \ / \ 189 / \ Aviation / \ Data Links / \ 190 ........................................................... 191 . . 192 . (:::)-. . 193 . .-(::::::::) . 194 . .-(:::: INET 1 ::)-. . 195 . (:::: e.g., IPv6 :::) . 196 . ATN/IPS `-(:::::::::::::)-' IPv6-based . 197 . `-(:::::::-' . 198 . OMNI Adaptation BGP Mobile . 199 . (:::)-. . 200 . Layer Overlay .-(::::::::) Routing Service . 201 . .-(:::: INET 2 ::)-. . 202 . (IPv6 GUAs) (:::: e.g., IPv4 :::) (IPv6 ULAs) . 203 . `-(:::::::::::::)-' . 204 . `-(:::::::-' . 205 . . 206 ............................................................. 207 | Fixed | Data Links | 208 | | | 209 (OMNI Interface) (OMNI Interface) (OMNI Interface) 210 +------------+ +------------+ +------------+ 211 | ATC/AOC 1 | | ATC/AOC 2 | .... | ATC/AOC M | 212 +------------+ +------------+ +------------+ 214 Figure 1: ATN/IPS Network Diagram 216 Connexion By Boeing [CBB] was an early aviation mobile routing 217 service based on dynamic updates in the global public Internet BGP 218 routing system. Practical experience with the approach has shown 219 that frequent injections and withdrawals of prefixes in the Internet 220 routing system can result in excessive BGP update messaging, slow 221 routing table convergence times, and extended outages when no route 222 is available. This is due to both conservative default BGP protocol 223 timing parameters (see Section 6) and the complex peering 224 interconnections of BGP routers within the global Internet 225 infrastructure. The situation is further exacerbated by frequent 226 aircraft mobility events that each result in BGP updates that must be 227 propagated to all BGP routers in the Internet that carry a full 228 routing table. 230 We therefore consider an approach using a BGP overlay network routing 231 system where a private BGP routing protocol instance is maintained 232 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 233 private BGP instance does not interact with the native BGP routing 234 systems in underlying INETs, and BGP updates are unidirectional from 235 "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a 236 hub-and-spokes topology. No extensions to the BGP protocol are 237 necessary, and BGP routing is based on (intermediate-layer) MNP and 238 ADM routes. This allows ASBRs to perform adaptation layer forwarding 239 based on intermediate layer IPv6 header information instead of 240 network layer forwarding based on upper layer IP header information 241 or link layer forwarding based on lower layer IP header information. 243 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 244 dedicated high speed links and/or secured tunnels (e.g., IPsec 245 [RFC4301], WireGuard [WG], etc.) over the underlying INET. 246 Neighboring ASBRs should use also such IP layer security 247 encapsulations over direct physical links to ensure INET layer 248 security. 250 The s-ASBRs engage in external BGP (eBGP) peerings with their 251 respective c-ASBRs, and only maintain routing table entries for the 252 MNPs currently active within the stub AS. The s-ASBRs send BGP 253 updates for MNP injections or withdrawals to c-ASBRs but do not 254 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 255 default routes with their c-ASBRs as the next hop, and therefore hold 256 only partial topology information. 258 The c-ASBRs connect to other c-ASBRs within the same partition using 259 internal BGP (iBGP) peerings over which they collaboratively maintain 260 a full routing table for all active MNPs currently in service within 261 the partition. Therefore, only the c-ASBRs maintain a full BGP 262 routing table and never send any BGP updates to s-ASBRs. This simple 263 routing model therefore greatly reduces the number of BGP updates 264 that need to be synchronized among peers, and the number is reduced 265 further still when intradomain routing changes within stub ASes are 266 processed within the AS instead of being propagated to the core. BGP 267 Route Reflectors (RRs) [RFC4456] can also be used to support 268 increased scaling properties. 270 When there are multiple INET partitions, the c-ASBRs of each 271 partition use eBGP to peer with the c-ASBRs of other partitions so 272 that the full set of routes for all partitions are known globally 273 among all of the c-ASBRs. Each c/s-ASBR further configures an ADM- 274 ULA which is taken from an ADM-ULA prefix assigned to each partition, 275 as well as static forwarding table entries for all other OMNI link 276 partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL 277 for nested encapsulation where the inner IPv6 packet is encapsulated 278 in an IPv6 OAL header with ULA source and destination addresses, 279 which is then encapsulated in an IP header specific to the INET 280 partition. 282 With these intra- and inter-INET BGP peerings in place, a forwarding 283 plane spanning tree is established that properly covers the entire 284 operating domain. All nodes in the network can be visited using 285 strict spanning tree hops, but in many instances this may result in 286 longer paths than are necessary. AERO [I-D.templin-6man-aero] 287 provides an example service for discovering and utilizing (route- 288 optimized) shortcuts that do not always follow strict spanning tree 289 paths. 291 The remainder of this document discusses the proposed BGP-based ATN/ 292 IPS mobile routing service. 294 2. Terminology 296 The terms Autonomous System (AS) and Autonomous System Border Router 297 (ASBR) are the same as defined in [RFC4271]. 299 The following terms are defined for the purposes of this document: 301 Air Traffic Management (ATM) 302 The worldwide service for coordinating safe aviation operations. 304 Air Traffic Controller (ATC) 305 A government agent responsible for coordinating with aircraft 306 within a defined operational region via voice and/or data Command 307 and Control messaging. 309 Airline Operations Controller (AOC) 310 An airline agent responsible for tracking and coordinating with 311 aircraft within their fleet. 313 Aeronautical Telecommunications Network with Internet Protocol 314 Services (ATN/IPS) 315 A future aviation network for ATCs and AOCs to coordinate with all 316 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 317 overlay network service that connects access networks via 318 tunneling over one or more Internetworking underlays. 320 Internetworking underlay ("INET") 321 A wide-area network that supports overlay network tunneling and 322 connects Radio Access Networks to the rest of the ATN/IPS. 323 Example INET service providers for civil aviation include ARINC, 324 SITA and Inmarsat. 326 (Radio) Access Network ("ANET") 327 An aviation radio data link service provider's network, including 328 radio transmitters and receivers as well as supporting ground- 329 domain infrastructure needed to convey a customer's data packets 330 to outside INETs. The term ANET is intended in the same spirit as 331 for radio-based Internet service provider networks (e.g., cellular 332 operators), but can also refer to ground-domain networks that 333 connect AOCs and ATCs. 335 partition (or "segment") 336 A fully-connected internal subnetwork of an INET in which all 337 nodes can communicate with all other nodes within the same 338 partition using the same IP protocol version and addressing plan. 339 Each INET consists of one or more partitions. 341 Overlay Multilink Network Interface (OMNI) 342 A virtual layer 2 bridging service that presents an ATN/IPS 343 overlay unified link view even though the underlay may consist of 344 multiple INET partitions. The OMNI virtual link is manifested 345 through nested encapsulation in which original IP packets from the 346 ATN/IPS are first encapsulated in ULA-addressed IPv6 headers which 347 are then forwarded to the next hop using INET encapsulation if 348 necessary. Forwarding over the OMNI virtual link is therefore 349 based on ULAs instead of the original IP addresses. In this way, 350 packets sent from a source can be conveyed over the OMNI virtual 351 link even though there may be many underlying INET partitions in 352 the path to the destination. 354 OMNI Adaptation Layer (OAL) 355 A middle layer below the IP layer but above the INET layer that 356 applies IP-in-IPv6 encapsulation prior to INET encapsulation. The 357 IPv6 encapsulation header inserted by the OAL uses ULAs instead of 358 GUAs. End systems that configure OMNI interfaces act as OAL 359 ingress and egress points, while intermediate systems with OMNI 360 interfaces act as OAL forwarding nodes. There may be zero, one or 361 many intermediate nodes between the OAL ingress and egress, but 362 the upper layer IPv6 Hop Limit is not decremented during (OAL 363 layer) forwarding. Further details on OMNI and the OAL are found 364 in [I-D.templin-6man-omni]. 366 OAL Autonomous System (OAL AS) 367 A "hub-of-hubs" autonomous system maintained through peerings 368 between the core autonomous systems of different OMNI virtual link 369 partitions. 371 Core Autonomous System Border Router (c-ASBR) 372 A BGP router located in the hub of the INET partition hub-and- 373 spokes overlay network topology. 375 Core Autonomous System (Core AS) 376 The "hub" autonomous system maintained by all c-ASBRs within the 377 same partition. 379 Stub Autonomous System Border Router (s-ASBR) 380 A BGP router configured as a spoke in the INET partition hub-and- 381 spokes overlay network topology. 383 Stub Autonomous System (Stub AS) 384 A logical grouping that includes all Clients currently associated 385 with a given s-ASBR. 387 Client 388 An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf 389 node. The Client could be a singleton host, or a router that 390 connects a mobile or fixed network. 392 Proxy/Server 393 An ANET/INET border node that acts as a transparent intermediary 394 between Clients and s-ASBRs. From the Client's perspective, the 395 Proxy/Server presents the appearance that the Client is 396 communicating directly with the s-ASBR. From the s-ASBR's 397 perspective, the Proxy/Server presents the appearance that the 398 s-ASBR is communicating directly with the Client. 400 Mobile Network Prefix (MNP) 401 An IPv6 prefix that is delegated to any ATN/IPS end system, 402 including ATCs, AOCs, and aircraft. 404 Mobility Service Prefix (MSP) 405 An aggregated IP prefix assigned to the ATN/IPS by an Internet 406 assigned numbers authority, and from which all MNPs are delegated 407 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 408 MSP). 410 3. ATN/IPS Routing System 412 The ATN/IPS routing system comprises a private BGP instance 413 coordinated in an overlay network via tunnels between neighboring 414 ASBRs over one or more underlying INETs. The ATN/IPS routing system 415 interacts with underlying INET BGP routing systems only through the 416 static advertisement of a small and unchanging set of MSPs instead of 417 the full dynamically changing set of MNPs. 419 Within each INET partition, each s-ASBR connects a stub AS to the 420 INET partition core using a distinct stub AS Number (ASN). Each 421 s-ASBR further uses eBGP to peer with one or more c-ASBRs. All 422 c-ASBRs are members of the INET partition core AS, and use a shared 423 core ASN. Unique ASNs are assigned according to the standard 32-bit 424 ASN format [RFC4271][RFC6793]. Since the BGP instance does not 425 connect with any INET BGP routing systems, the ASNs can be assigned 426 from the [RFC6996] 32-bit ASN space which reserves 94,967,295 numbers 427 for private use. The ASNs must be allocated and managed by an ATN/ 428 IPS assigned numbers authority established by ICAO, which must ensure 429 that ASNs are responsibly distributed without duplication and/or 430 overlap. 432 The c-ASBRs use iBGP to maintain a synchronized consistent view of 433 all active MNPs currently in service within the INET partition. 434 Figure 2 below represents the reference INET partition deployment. 435 (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and 436 s-ASBR2) due to space constraints, but the other s-ASBRs should be 437 understood to have similar Stub AS, MNP and eBGP peering 438 arrangements.) The solution described in this document is flexible 439 enough to extend to these topologies. 441 ........................................................... 442 . . 443 . (:::)-. <- Stub ASes -> (:::)-. . 444 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 445 . `-(::::)-' `-(::::)-' . 446 . +-------+ +-------+ . 447 . |s-ASBR1+-----+ +-----+s-ASBR2| . 448 . +--+----+ eBGP \ / eBGP +-----+-+ . 449 . \ \/ / . 450 . \eBGP / \ /eBGP . 451 . \ / \ / . 452 . +-------+ +-------+ . 453 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 454 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 455 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 456 . +-------+ .-(::::::::) +-------+ . 457 . . .-(::::::::::::::)-. . . 458 . . (:::: Core AS :::) . . 459 . +-------+ `-(:::::::::::::)-' +-------+ . 460 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 461 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 462 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 463 . +-------+ +-------+ . 464 . / \ . 465 . /eBGP \eBGP . 466 . / \ . 467 . +---+---+ +-----+-+ . 468 . |s-ASBR | |s-ASBR | . 469 . +-------+ +-------+ . 470 . . 471 . . 472 . <----------------- INET Partition -------------------> . 473 ............................................................ 475 Figure 2: INET Partition Reference Deployment 477 In the reference deployment, each s-ASBR maintains routes for active 478 MNPs that currently belong to its stub AS. In response to "Inter- 479 domain" mobility events, each s-ASBR dynamically announces new MNPs 480 and withdraws departed MNPs in its eBGP updates to c-ASBRs. Since 481 ATN/IPS end systems are expected to remain within the same stub AS 482 for extended timeframes, however, intra-domain mobility events (such 483 as an aircraft handing off between cell towers) are handled within 484 the stub AS instead of being propagated as inter-domain eBGP updates. 486 Each c-ASBR configures a black-hole route for each of its MSPs. By 487 black-holing the MSPs, the c-ASBR maintains forwarding table entries 488 only for the MNPs that are currently active. If an arriving packet 489 has an adaptation layer destination address that matches a black-hole 490 route without matching an MNP, the c-ASBR should drop the packet and 491 may also generate an ICMPv6 Destination Unreachable message 492 [RFC4443], i.e., without forwarding the packet outside of the ATN/IPS 493 overlay based on a less-specific route. 495 The c-ASBRs do not send BGP updates for MNPs to s-ASBRs, but instead 496 originate a default route. In this way, s-ASBRs have only partial 497 topology knowledge (i.e., they know only about the active MNPs 498 currently within their stub ASes) and they forward all other packets 499 to c-ASBRs which have full topology knowledge. 501 Each s-ASBR and c-ASBR configures an ADM-ULA with a 32-bit ADM suffix 502 that is unique within the OMNI link, and the core ASes of each INET 503 partition are joined together through external BGP peerings. The 504 c-ASBRs of each partition establish external peerings with the 505 c-ASBRs of other partitions to form a "core-of-cores" OMNI link AS. 506 The OMNI link AS contains the global knowledge of all MNPs deployed 507 worldwide, and supports ATN/IPS overlay communications between nodes 508 located in different INET partitions by virtue of OAL encapsulation. 509 OMNI link nodes can then navigate to ASBRs by including an ADM-ULA or 510 directly to an end system by including an MNP-ULA in the destination 511 address of an OAL-encapsulated packet (see: [I-D.templin-6man-aero]). 512 Figure 3 shows a reference OAL topology. 514 . . . . . . . . . . . . . . . . . . . . . . . . . 515 . . 516 . .-(::::::::) . 517 . .-(::::::::::::)-. +------+ . 518 . (::: Partition 1 ::)--|c-ASBR|---+ . 519 . `-(::::::::::::)-' +------+ | . 520 . `-(::::::)-' | . 521 . | . 522 . .-(::::::::) | . 523 . .-(::::::::::::)-. +------+ | . 524 . (::: Partition 2 ::)--|c-ASBR|---+ . 525 . `-(::::::::::::)-' +------+ | . 526 . `-(::::::)-' | . 527 . | . 528 . .-(::::::::) | . 529 . .-(::::::::::::)-. +------+ | . 530 . (::: Partition 3 ::)--|c-ASBR|---+ . 531 . `-(::::::::::::)-' +------+ | . 532 . `-(::::::)-' | . 533 . | . 534 . ..(etc).. x . 535 . . 536 . . 537 . <- ATN/IPS Overlay Bridged by the OAL AS -> . 538 . . . . . . . . . . . . . .. . . . . . . . . . . . 540 Figure 3: Spanning Partitions with the OAL 542 Scaling properties of this ATN/IPS routing system are limited by the 543 number of BGP routes that can be carried by the c-ASBRs. A 2015 544 study showed that BGP routers in the global public Internet at that 545 time carried more than 500K routes with linear growth and no signs of 546 router resource exhaustion [BGP]. A more recent network emulation 547 study also showed that a single c-ASBR can accommodate at least 1M 548 dynamically changing BGP routes even on a lightweight virtual 549 machine. Commercially-available high-performance dedicated router 550 hardware can support many millions of routes. 552 Therefore, assuming each c-ASBR can carry 1M or more routes, this 553 means that at least 1M ATN/IPS end system MNPs can be serviced by a 554 single set of c-ASBRs and that number could be further increased by 555 using RRs and/or more powerful routers. Another means of increasing 556 scale would be to assign a different set of c-ASBRs for each set of 557 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 558 from each set of c-ASBRs, but the s-ASBR institutes route filters so 559 that it only sends BGP updates to the specific set of c-ASBRs that 560 aggregate the MSP. In this way, each set of c-ASBRs maintains 561 separate routing and forwarding tables so that scaling is distributed 562 across multiple c-ASBR sets instead of concentrated in a single 563 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 564 segment A::/32, a second set could aggregate B::/32, a third could 565 aggregate C::/32, etc. The union of all MSP segments would then 566 constitute the collective MSP(s) for the entire ATN/IPS, with 567 potential for supporting many millions of mobile networks or more. 569 In this way, each set of c-ASBRs services a specific set of MSPs, and 570 each s-ASBR configures MSP-specific routes that list the correct set 571 of c-ASBRs as next hops. This design also allows for natural 572 incremental deployment, and can support initial medium-scale 573 deployments followed by dynamic deployment of additional ATN/IPS 574 infrastructure elements without disturbing the already-deployed base. 575 For example, a few more c-ASBRs could be added if the MNP service 576 demand ever outgrows the initial deployment. For larger-scale 577 applications (such as unmanned air vehicles and terrestrial vehicles) 578 even larger scales can be accommodated by adding more c-ASBRs. 580 4. ATN/IPS (Radio) Access Network (ANET) Model 582 (Radio) Access Networks (ANETs) connect end system Clients such as 583 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 584 connect to multiple ANETs at once, for example, when they have both 585 satellite and cellular data links activated simultaneously. Clients 586 configure an Overlay Multilink Network (OMNI) Interface 587 [I-D.templin-6man-omni] over their underlying ANET interfaces as a 588 connection to an NBMA virtual link (manifested by the OAL) that spans 589 the entire ATN/IPS. Clients may further move between ANETs in a 590 manner that is perceived as a network layer mobility event. Clients 591 could therefore employ a multilink/mobility routing service such as 592 those discussed in Section 7. 594 Clients register all of their active data link connections with their 595 serving s-ASBRs as discussed in Section 3. Clients may connect to 596 s-ASBRs either directly, or via a Proxy/Server at the ANET/INET 597 boundary. 599 Figure 4 shows the ATN/IPS ANET model where Clients connect to ANETs 600 via aviation data links. Clients register their ANET addresses with 601 a nearby s-ASBR, where the registration process may be brokered by a 602 Proxy/Server at the edge of the ANET. 604 +-----------------+ 605 | Client | 606 Data Link "A" +-----------------+ Data Link "B" 607 +----- | OMNI Interface |--------+ 608 / +-----------------+ \ 609 / \ 610 / \ 611 (:::)-. (:::)-. 612 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 613 `-(::::)-' `-(::::)-' 614 +-------+ +-------+ 615 ... | P/S | ............................ | P/S | ... 616 . +-------+ +-------+ . 617 . ^^ ^^ . 618 . || || . 619 . || +--------+ || . 620 . ++============> | s-ASBR | <============++ . 621 . +--------+ . 622 . | eBGP . 623 . (:::)-. . 624 . .-(::::::::) . 625 . .-(::: ATN/IPS :::)-. . 626 . (::::: BGP Routing ::::) . 627 . `-(:: System ::::)-' . 628 . `-(:::::::-' . 629 . . 630 . . 631 . <------- OMNI virtual link bridged by the OAL --------> . 632 ............................................................ 634 Figure 4: ATN/IPS ANET Architecture 636 When a Client connects to an ANET it specifies a nearby s-ASBR that 637 it has selected to connect to the ATN/IPS. The login process is 638 transparently brokered by a Proxy/Server at the border of the ANET 639 which then conveys the connection request to the s-ASBR via tunneling 640 across the OMNI virtual link. Each ANET border Proxy/Server is also 641 equally capable of serving in the s-ASBR role so that a first on-link 642 Proxy/Server can be selected as the s-ASBR while all others perform 643 the Proxy/Server role in a hub-and-spokes arrangement. An on-link 644 Proxy/Server is selected to serve the s-ASBR role when it receives a 645 control message from a Client requesting that service. 647 The Client can coordinate with a network-based s-ASBR over additional 648 ANETs after it has already coordinated with a first-hop Proxy/Server 649 over a first ANET. If the Client connects to multiple ANETs, the 650 s-ASBR will register the individual ANET Proxy/Servers as conduits 651 through which the Client can be reached. The Client then sees the 652 s-ASBR as the "hub" in a "hub-and-spokes" arrangement with the first- 653 hop Proxy/Servers as spokes. Selection of a network-based s-ASBR is 654 through the discovery methods specified in relevant mobility and 655 virtual link coordination specifications (e.g., see AERO 656 [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni]). 658 The s-ASBR represents all of its active Clients as MNP routes in the 659 ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore used 660 only to advertise the set of MNPs of all its active Clients to its 661 BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the stub 662 AS is a logical construct and not a physical one). The s-ASBR 663 injects the MNPs of its active Clients and withdraws the MNPs of its 664 departed Clients via BGP updates to c-ASBRs, which further propagate 665 the MNPs to other c-ASBRs within the OAL AS. Since Clients are 666 expected to remain associated with their current s-ASBR for extended 667 periods, the level of MNP injections and withdrawals in the BGP 668 routing system will be on the order of the numbers of network joins, 669 leaves and s-ASBR handovers for aircraft operations (see: Section 6). 670 It is important to observe that fine-grained events such as Client 671 mobility and Quality of Service (QoS) signaling are coordinated only 672 by Proxies and the Client's current s-ASBRs, and do not involve other 673 ASBRs in the routing system. In this way, intradomain routing 674 changes within the stub AS are not propagated into the rest of the 675 ATN/IPS BGP routing system. 677 5. ATN/IPS Route Optimization 679 ATN/IPS end systems will frequently need to communicate with 680 correspondents associated with other s-ASBRs. In the BGP peering 681 topology discussed in Section 3, this can initially only be 682 accommodated by including multiple extraneous hops and/or spanning 683 tree segments in the forwarding path. In many cases, it would be 684 desirable to establish a "short cut" around this "dogleg" route so 685 that packets can traverse a minimum number of tunneling hops across 686 the OMNI virtual link. ATN/IPS end systems could therefore employ a 687 route optimization service according to the mobility service employed 688 (see: Section 7). 690 Each s-ASBR provides designated routing services for only a subset of 691 all active Clients, and instead acts as a simple Proxy/Server for 692 other Clients. As a designated router, the s-ASBR advertises the 693 MNPs of each of its active Clients into the ATN/IPS routing system 694 and provides basic (unoptimized) forwarding services when necessary. 695 An s-ASBR could be the first-hop ATN/IPS service access point for 696 some, all or none of a Client's underlying interfaces, while the 697 Client's other underlying interfaces employ the Proxy/Server function 698 of other s-ASBRs. Route optimization allows Client-to-Client 699 communications while bypassing s-ASBR designated routing services 700 whenever possible. 702 A route optimization example is shown in Figure 5 and Figure 6 below. 703 In the first figure, multiple spanning tree segments between Proxy/ 704 Servers and ASBRs are necessary to convey packets between Clients 705 associated with different s-ASBRs. In the second figure, the 706 optimized route tunnels packets directly between Proxy/Servers 707 without involving the ASBRs. 709 These route optimized paths are established through secured control 710 plane messaging (i.e., over secured tunnels and/or using higher-layer 711 control message authentications) but do not provide lower-layer 712 security for the data plane. Data communications over these route 713 optimized paths should therefore employ higher-layer security. 715 +---------+ +---------+ 716 | Client1 | | Client2 | 717 +---v-----+ +-----^---+ 718 * * 719 * * 720 (:::)-. (:::)-. 721 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 722 `-(::::)-' `-(::::)-' 723 +--------+ +--------+ 724 ... | P/S-1 | .......................... | P/S-2 | ... 725 . +--------+ +--------+ . 726 . ** ** . 727 . ** ** . 728 . ** ** . 729 . +---------+ +---------+ . 730 . | s-ASBR1 | | s-ASBR2 | . 731 . +--+------+ +-----+---+ . 732 . \ ** Dogleg ** / . 733 . eBGP\ ** Route ** /eBGP . 734 . \ **==============** / . 735 . +---------+ +---------+ . 736 . | c-ASBR1 | | c-ASBR2 | . 737 . +---+-----+ +----+----+ . 738 . +--------------+ . 739 . iBGP . 740 . . 741 . <------- OMNI virtual link bridged by the OAL --------> . 742 ............................................................ 744 Figure 5: Dogleg Route Before Optimization 746 +---------+ +---------+ 747 | Client1 | | Client2 | 748 +---v-----+ +-----^---+ 749 * * 750 * * 751 (:::)-. (:::)-. 752 .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) 753 `-(::::)-' `-(::::)-' 754 +--------+ +--------+ 755 ... | P/S-1 | .......................... | P/S-2 | ... 756 . +------v-+ +--^-----+ . 757 . * * . 758 . *================================* . 759 . . 760 . +---------+ +---------+ . 761 . | s-ASBR1 | | s-ASBR2 | . 762 . +--+------+ +-----+---+ . 763 . \ / . 764 . eBGP\ /eBGP . 765 . \ / . 766 . +---------+ +---------+ . 767 . | c-ASBR1 | | c-ASBR2 | . 768 . +---+-----+ +----+----+ . 769 . +--------------+ . 770 . iBGP . 771 . . 772 . <------- OMNI virtual link bridged by the OAL --------> . 773 ............................................................ 775 Figure 6: Optimized Route 777 6. BGP Protocol Considerations 779 The number of eBGP peering sessions that each c-ASBR must service is 780 proportional to the number of s-ASBRs in its local partition. 781 Network emulations with lightweight virtual machines have shown that 782 a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs 783 that each advertise 10K MNP routes (i.e., 1M total). It is expected 784 that robust c-ASBRs can service many more peerings than this - 785 possibly by multiple orders of magnitude. But even assuming a 786 conservative limit, the number of s-ASBRs could be increased by also 787 increasing the number of c-ASBRs. Since c-ASBRs also peer with each 788 other using iBGP, however, larger-scale c-ASBR deployments may need 789 to employ an adjunct facility such as BGP Route Reflectors 790 (RRs)[RFC4456]. 792 The number of aircraft in operation at a given time worldwide is 793 likely to be significantly less than 1M, but we will assume this 794 number for a worst-case analysis. Assuming a worst-case average 1 795 hour flight profile from gate-to-gate with 10 service region 796 transitions per flight, the entire system will need to service at 797 most 10M BGP updates per hour (2778 updates per second). This number 798 is within the realm of the peak BGP update messaging seen in the 799 global public Internet today [BGP2]. Assuming a BGP update message 800 size of 100 bytes (800bits), the total amount of BGP control message 801 traffic to a single c-ASBR will be less than 2.5Mbps which is a 802 nominal rate for modern data links. 804 Industry standard BGP routers provide configurable parameters with 805 conservative default values. For example, the default hold time is 806 90 seconds, the default keepalive time is 1/3 of the hold time, and 807 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 808 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 809 For the simple mobile routing system described herein, these 810 parameters can be set to more aggressive values to support faster 811 neighbor/link failure detection and faster routing protocol 812 convergence times. For example, a hold time of 3 seconds and a 813 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 815 Instead of adjusting BGP default time values, BGP routers can use the 816 Bidirectional Forwarding Detection (BFD) protocol [RFC5880] to 817 quickly detect link failures that don't result in interface state 818 changes, BGP peer failures, and administrative state changes. BFD is 819 important in environments where rapid response to failures is 820 required for routing reconvergence and, hence, communications 821 continuity. 823 Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with 824 the ATN/IPS unicast IPv6 routes resolving over INET routes. 825 Consequently, c-ASBRs and potentially s-ASBRs will need to support 826 separate local ASes for the two BGP routing domains and routing 827 policy or assure routes are not propagated between the two BGP 828 routing domains. From a conceptual, operational and correctness 829 standpoint, the implementation should provide isolation between the 830 two BGP routing domains (e.g., separate BGP instances). 832 ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random 833 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 834 OMNI link identifier '*' to form the prefix [ULA*]::/64. Each 835 individual address taken from [ULA*]::/64 includes additional routing 836 information in the interface identifier. For example, for the MNP 837 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 838 and for the administrative address 1001:2002/16 the ADM-ULA is 839 [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further 840 details). But, the routes injected into the routing system are 841 configured from the 64-bit MNP/ADM suffix (along with a prefix length 842 of /64 or shorter), and not from the ULA prefix itself. 844 This gives rise to a BGP routing system that must accommodate large 845 numbers of long and non-aggregable MNPs as well as moderate numbers 846 of long and semi-aggregable ADM-based routes. Meanwhile, in the 847 forwarding plane the 64-bit suffixes of ULA destination addresses 848 (i.e., and not the 64-bit prefixes) are matched against the MNP and 849 ADM-based forwarding table entries established by the routing system. 850 The system is kept stable and scalable through the s-ASBR / c-ASBR 851 hub-and-spokes topology which ensures that mobility-related churn is 852 not exposed to the core. 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 MNPs 869 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 is asserted at a new location or withdrawn from an old 1096 location can be several hundred milliseconds even under optimal AS 1097 peering arrangements. This means that packets in flight destined to 1098 an MNP route that has recently been changed can be (mis)delivered to 1099 an old s-ASBR after a Client has moved to a new s-ASBR. 1101 To address this issue, the old s-ASBR can maintain temporary state 1102 for a "departed" Client that includes an OAL address for the new 1103 s-ASBR. The OAL address never changes since ASBRs are fixed 1104 infrastructure elements that never move. Hence, packets arriving at 1105 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 1106 routing system is still undergoing reconvergence. Therefore, as long 1107 as the Client associates with the new s-ASBR before it departs from 1108 the old s-ASBR (while informing the old s-ASBR of its new location) 1109 packets in flight during the BGP reconvergence window are 1110 accommodated without loss. 1112 Appendix B. Change Log 1114 << RFC Editor - remove prior to publication >> 1116 Differences from earlier versions: 1118 * Submit for RFC publication. 1120 Authors' Addresses 1122 Fred L. Templin (editor) 1123 Boeing Research & Technology 1124 P.O. Box 3707 1125 Seattle, WA 98124 1126 United States of America 1127 Email: fltemplin@acm.org 1129 Greg Saccone 1130 Boeing Research & Technology 1131 P.O. Box 3707 1132 Seattle, WA 98124 1133 United States of America 1134 Email: gregory.t.saccone@boeing.com 1136 Gaurav Dawra 1137 LinkedIn 1138 United States of America 1139 Email: gdawra.ietf@gmail.com 1141 Acee Lindem 1142 Cisco Systems, Inc. 1143 United States of America 1144 Email: acee@cisco.com 1146 Victor Moreno 1147 Cisco Systems, Inc. 1148 United States of America 1149 Email: vimoreno@cisco.com