idnits 2.17.00 (12 Aug 2021) /tmp/idnits7036/draft-ietf-rtgwg-atn-bgp-12.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 (1 January 2022) is 140 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ULA' is mentioned on line 750, but not defined == Unused Reference: 'RFC2784' is defined on line 915, 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-37 == Outdated reference: A later version (-61) exists of draft-templin-6man-omni-51 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) 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: 5 July 2022 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 1 January 2022 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-12 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 IPv6-based service supporting pervasive Air Traffic 23 Management (ATM) for Air Traffic Controllers (ATC), Airline 24 Operations Controllers (AOC), and all commercial aircraft worldwide. 25 This 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 5 July 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 65 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12 66 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14 67 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16 68 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18 69 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 75 12.2. Informative References . . . . . . . . . . . . . . . . . 20 76 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 22 77 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 The worldwide Air Traffic Management (ATM) system today uses a 83 service known as Aeronautical Telecommunications Network based on 84 Open Systems Interconnection (ATN/OSI). The service is used to 85 augment controller to pilot voice communications with rudimentary 86 short text command and control messages. The service has seen 87 successful deployment in a limited set of worldwide ATM domains. 89 The International Civil Aviation Organization (ICAO) is now 90 undertaking the development of a next-generation replacement for ATN/ 91 OSI known as Aeronautical Telecommunications Network with Internet 92 Protocol Services (ATN/IPS) [ATN][ATN-IPS]. ATN/IPS will eventually 93 provide an IPv6-based [RFC8200] service supporting pervasive ATM for 94 Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), 95 and all commercial aircraft worldwide. As part of the ATN/IPS 96 undertaking, a new mobile routing service will be needed. This 97 document presents an approach based on the Border Gateway Protocol 98 (BGP) [RFC4271]. 100 Aircraft communicate via wireless aviation data links that typically 101 support much lower data rates than terrestrial wireless and wired- 102 line communications. For example, some Very High Frequency (VHF)- 103 based data links only support data rates on the order of 32Kbps and 104 an emerging L-Band data link that is expected to play a key role in 105 future aeronautical communications only supports rates on the order 106 of 1Mbps. Although satellite data links can provide much higher data 107 rates during optimal conditions, like any other aviation data link 108 they are subject to errors, delay, disruption, signal intermittence, 109 degradation due to atmospheric conditions, etc. The well-connected 110 ground domain ATN/IPS network should therefore treat each safety-of- 111 flight critical packet produced by (or destined to) an aircraft as a 112 precious commodity and strive for an optimized service that provides 113 the highest possible degree of reliability. 115 The ATN/IPS is an IPv6-based overlay network configured over one or 116 more Internetworking underlays ("INETs") maintained by aeronautical 117 network service providers such as ARINC, SITA and Inmarsat. The 118 Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] 119 provides a Non-Broadcast, Multiple Access (NBMA) virtual link that 120 spans the entire ATN/IPS. Each aircraft connects to the OMNI link 121 via an OMNI interface configured over the aircraft's underlying 122 physical and/or virtual access network interfaces. 124 Each underlying INET comprises one or more "partitions" where all 125 nodes within a partition can exchange packets with all other nodes, 126 i.e., the partition is connected internally. There is no requirement 127 that any two INET partitions use the same IP protocol version nor 128 have consistent IP addressing plans in comparison with other 129 partitions. Instead, the OMNI link sees each partition as a 130 "segment" of a link-layer topology concatenated by a service known as 131 the OMNI Adaptation Layer (OAL) 132 [I-D.templin-6man-omni][I-D.templin-6man-aero] based on IPv6 133 encapsulation [RFC2473]. 135 The IPv6 addressing architecture provides different classes of 136 addresses, including Global Unicast Addresses (GUAs), Unique Local 137 Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. 138 The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from 139 an Internet assigned numbers authority, and each aircraft will 140 receive a Mobile Network Prefix (MNP) delegation from the MSP that 141 accompanies the aircraft wherever it travels. ATCs and AOCs will 142 likewise receive MNPs, but they would typically appear in static (not 143 mobile) deployments such as air traffic control towers, airline 144 headquarters, etc. 146 The OAL uses ULAs in the source and destination addresses of IPv6 147 encapsulation headers. Each ULA includes an MNP in the interface 148 identifier ("MNP-ULA") as discussed in [I-D.templin-6man-omni]. Due 149 to MNP delegation policies and random MN mobility properties, MNP- 150 ULAs are generally not aggregatable in the BGP routing service and 151 are represented as many more-specific prefixes instead of a smaller 152 number of aggregated prefixes. In addition, OMNI link service nodes 153 configure administratively-assigned ULAs ("ADM-ULA") that are 154 statically-assigned and derived from a shorter ADM-ULA prefix 155 assigned to their OMNI link partition [I-D.templin-6man-omni]. 156 Unlike MNP-ULAs, the ADM-ULAs are persistently present and unchanging 157 in the routing system. The BGP routing services therefore perform 158 forwarding based on these MNP-ULAs and ADM-ULAs instead of based on 159 the GUA MNPs themselves. 161 Connexion By Boeing [CBB] was an early aviation mobile routing 162 service based on dynamic updates in the global public Internet BGP 163 routing system. Practical experience with the approach has shown 164 that frequent injections and withdrawals of prefixes in the Internet 165 routing system can result in excessive BGP update messaging, slow 166 routing table convergence times, and extended outages when no route 167 is available. This is due to both conservative default BGP protocol 168 timing parameters (see Section 6) and the complex peering 169 interconnections of BGP routers within the global Internet 170 infrastructure. The situation is further exacerbated by frequent 171 aircraft mobility events that each result in BGP updates that must be 172 propagated to all BGP routers in the Internet that carry a full 173 routing table. 175 We therefore consider an approach using a BGP overlay network routing 176 system where a private BGP routing protocol instance is maintained 177 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 178 private BGP instance does not interact with the native BGP routing 179 systems in underlying INETs, and BGP updates are unidirectional from 180 "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a 181 hub-and-spokes topology. No extensions to the BGP protocol are 182 necessary. BGP routing is based on the ULAs found in OAL headers, 183 i.e., it provides an adaptation layer forwarding service instead of a 184 networking layer routing service. 186 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 187 dedicated high speed links and/or tunnels across the INET using 188 industry-standard secured encapsulations (e.g., IPsec [RFC4301], 189 Wireguard, etc.). In particular, tunneling must be used when 190 neighboring ASBRs are separated by multiple INET hops. 192 The s-ASBRs engage in external BGP (eBGP) peerings with their 193 respective c-ASBRs, and only maintain routing table entries for the 194 MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP 195 updates for MNP-ULA injections or withdrawals to c-ASBRs but do not 196 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 197 default routes with their c-ASBRs as the next hop, and therefore hold 198 only partial topology information. 200 The c-ASBRs connect to other c-ASBRs within the same partition using 201 internal BGP (iBGP) peerings over which they collaboratively maintain 202 a full routing table for all active MNP-ULAs currently in service 203 within the partition. Therefore, only the c-ASBRs maintain a full 204 BGP routing table and never send any BGP updates to s-ASBRs. This 205 simple routing model therefore greatly reduces the number of BGP 206 updates that need to be synchronized among peers, and the number is 207 reduced further still when intradomain routing changes within stub 208 ASes are processed within the AS instead of being propagated to the 209 core. BGP Route Reflectors (RRs) [RFC4456] can also be used to 210 support increased scaling properties. 212 When there are multiple INET partitions, the c-ASBRs of each 213 partition use eBGP to peer with the c-ASBRs of other partitions so 214 that the full set of ULAs for all partitions are known globally among 215 all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA 216 which is taken from an ADM-ULA prefix assigned to each partition, as 217 well as static forwarding table entries for all other OMNI link 218 partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL 219 for nested encapsulation where the inner IPv6 packet is encapsulated 220 in an IPv6 OAL header with ULA source and destination addresses, 221 which is then encapsulated in an IP header specific to the INET 222 partition. 224 With these intra- and inter-INET BGP peerings in place, a forwarding 225 plane spanning tree is established that properly covers the entire 226 operating domain. All nodes in the network can be visited using 227 strict spanning tree hops, but in many instances this may result in 228 longer paths than are necessary. The AERO and OMNI services 229 [I-D.templin-6man-aero][I-D.templin-6man-omni] provide mechanisms for 230 discovering and utilizing (route-optimized) shortcuts that do not 231 always follow strict spanning tree paths. 233 The remainder of this document discusses the proposed BGP-based ATN/ 234 IPS mobile routing service. 236 2. Terminology 238 The terms Autonomous System (AS) and Autonomous System Border Router 239 (ASBR) are the same as defined in [RFC4271]. 241 The following terms are defined for the purposes of this document: 243 Air Traffic Management (ATM) 244 The worldwide service for coordinating safe aviation operations. 246 Air Traffic Controller (ATC) 247 A government agent responsible for coordinating with aircraft 248 within a defined operational region via voice and/or data Command 249 and Control messaging. 251 Airline Operations Controller (AOC) 252 An airline agent responsible for tracking and coordinating with 253 aircraft within their fleet. 255 Aeronautical Telecommunications Network with Internet Protocol 256 Services (ATN/IPS) 257 A future aviation network for ATCs and AOCs to coordinate with all 258 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 259 overlay network service that connects access networks via 260 tunneling over one or more Internetworking underlays. 262 Internetworking underlay ("INET") 263 A wide-area network that supports overlay network tunneling and 264 connects Radio Access Networks to the rest of the ATN/IPS. 265 Example INET service providers for civil aviation include ARINC, 266 SITA and Inmarsat. 268 (Radio) Access Network ("ANET") 269 An aviation radio data link service provider's network, including 270 radio transmitters and receivers as well as supporting ground- 271 domain infrastructure needed to convey a customer's data packets 272 to outside INETs. The term ANET is intended in the same spirit as 273 for radio-based Internet service provider networks (e.g., cellular 274 operators), but can also refer to ground-domain networks that 275 connect AOCs and ATCs. 277 partition (or "segment") 278 A fully-connected internal subnetwork of an INET in which all 279 nodes can communicate with all other nodes within the same 280 partition using the same IP protocol version and addressing plan. 281 Each INET consists of one or more partitions. 283 Overlay Multilink Network Interface (OMNI) 284 A virtual layer 2 bridging service that presents an ATN/IPS 285 overlay unified link view even though the underlay may consist of 286 multiple INET partitions. The OMNI virtual link is manifested 287 through nested encapsulation in which GUA-addressed IPv6 packets 288 from the ATN/IPS are first encapsulated in ULA-addressed IPv6 289 headers which are then forwarded to the next hop using INET 290 encapsulation if necessary. Forwarding over the OMNI virtual link 291 is therefore based on ULAs instead of GUAs. In this way, packets 292 sent from a source can be conveyed over the OMNI virtual link even 293 though there may be many underlying INET partitions in the path to 294 the destination. 296 OMNI Adaptation Layer (OAL) 297 A middle layer below the IPv6 layer but above the INET layer that 298 applies IPv6-in-IPv6 encapsulation prior to INET encapsulation. 299 The IPv6 encapsulation header inserted by the OAL uses ULAs 300 instead of GUAs. Further details on OMNI and the OAL are found in 301 [I-D.templin-6man-omni]. 303 OAL Autonomous System 304 A "hub-of-hubs" autonomous system maintained through peerings 305 between the core autonomous systems of different OMNI virtual link 306 partitions. 308 Core Autonomous System Border Router (c-ASBR) 309 A BGP router located in the hub of the INET partition hub-and- 310 spokes overlay network topology. 312 Core Autonomous System 313 The "hub" autonomous system maintained by all c-ASBRs within the 314 same partition. 316 Stub Autonomous System Border Router (s-ASBR) 317 A BGP router configured as a spoke in the INET partition hub-and- 318 spokes overlay network topology. 320 Stub Autonomous System 321 A logical grouping that includes all Clients currently associated 322 with a given s-ASBR. 324 Client 325 An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf 326 node. The Client could be a singleton host, or a router that 327 connects a mobile or fixed network. 329 Proxy/Server 330 An ANET/INET border node that acts as a transparent intermediary 331 between Clients and s-ASBRs. From the Client's perspective, the 332 Proxy/Server presents the appearance that the Client is 333 communicating directly with the s-ASBR. From the s-ASBR's 334 perspective, the Proxy/Server presents the appearance that the 335 s-ASBR is communicating directly with the Client. 337 Mobile Network Prefix (MNP) 338 An IPv6 prefix that is delegated to any ATN/IPS end system, 339 including ATCs, AOCs, and aircraft. 341 Mobility Service Prefix (MSP) 342 An aggregated prefix assigned to the ATN/IPS by an Internet 343 assigned numbers authority, and from which all MNPs are delegated 344 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 345 MSP). 347 3. ATN/IPS Routing System 349 The ATN/IPS routing system comprises a private BGP instance 350 coordinated in an overlay network via tunnels between neighboring 351 ASBRs over one or more underlying INETs. The overlay does not 352 interact with the underlying INET BGP routing systems, and only a 353 small and unchanging set of MSPs are advertised externally instead of 354 the full dynamically changing set of MNPs. 356 Within each INET partition, each s-ASBRs connects a stub AS to the 357 INET partition core using a distinct stub AS Number (ASN). Each 358 s-ASBR further uses eBGP to peer with one or more c-ASBRs. All 359 c-ASBRs are members of the INET partition core AS, and use a shared 360 core ASN. Unique ASNs are assigned according to the standard 32-bit 361 ASN format [RFC4271][RFC6793]. Since the BGP instance does not 362 connect with any INET BGP routing systems, the ASNs assigned need not 363 be coordinated with IANA and can in fact coincide with values that 364 are assigned in other domains. The only requirement is that ASNs 365 must not be duplicated within the ATN/IPS routing system itself. 367 The c-ASBRs use iBGP to maintain a synchronized consistent view of 368 all active MNP-ULAs currently in service within the INET partition. 369 Figure 1 below represents the reference INET partition deployment. 370 (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and 371 s-ASBR2) due to space constraints, but the other s-ASBRs should be 372 understood to have similar Stub AS, MNP and eBGP peering 373 arrangements.) The solution described in this document is flexible 374 enough to extend to these topologies. 376 ........................................................... 377 . . 378 . (:::)-. <- Stub ASes -> (:::)-. . 379 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 380 . `-(::::)-' `-(::::)-' . 381 . +-------+ +-------+ . 382 . |s-ASBR1+-----+ +-----+s-ASBR2| . 383 . +--+----+ eBGP \ / eBGP +-----+-+ . 384 . \ \/ / . 385 . \eBGP / \ /eBGP . 386 . \ / \ / . 387 . +-------+ +-------+ . 388 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 389 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 390 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 391 . +-------+ .-(::::::::) +-------+ . 392 . . .-(::::::::::::::)-. . . 393 . . (:::: Core AS :::) . . 394 . +-------+ `-(:::::::::::::)-' +-------+ . 395 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 396 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 397 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 398 . +-------+ +-------+ . 399 . / \ . 400 . /eBGP \eBGP . 401 . / \ . 402 . +---+---+ +-----+-+ . 403 . |s-ASBR | |s-ASBR | . 404 . +-------+ +-------+ . 405 . . 406 . . 407 . <----------------- INET Partition -------------------> . 408 ............................................................ 410 Figure 1: INET Partition Reference Deployment 412 In the reference deployment, each s-ASBR maintains routes for active 413 MNP-ULAs that currently belong to its stub AS. In response to 414 "Inter-domain" mobility events, each s-ASBR will dynamically 415 announces new MNP-ULAs and withdraws departed MNP-ULAs in its eBGP 416 updates to c-ASBRs. Since ATN/IPS end systems are expected to remain 417 within the same stub AS for extended timeframes, however, intra- 418 domain mobility events (such as an aircraft handing off between cell 419 towers) are handled within the stub AS instead of being propagated as 420 inter-domain eBGP updates. 422 Each c-ASBR configures a black-hole route for each of its MSPs. By 423 black-holing the MSPs, the c-ASBR will maintain forwarding table 424 entries only for the MNP-ULAs that are currently active, and packets 425 destined to all other MNP-ULAs will correctly incur ICMPv6 426 Destination Unreachable messages [RFC4443] due to the black hole 427 route. (This is the same behavior as for ordinary BGP routers in the 428 Internet when they receive packets for which there is no route 429 available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to 430 s-ASBRs, but instead originate a default route. In this way, s-ASBRs 431 have only partial topology knowledge (i.e., they know only about the 432 active MNP-ULAs currently within their stub ASes) and they forward 433 all other packets to c-ASBRs which have full topology knowledge. 435 Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable 436 within an INET partition, and each partition configures a unique ADM- 437 ULA prefix that is permanently announced into the routing system. 438 The core ASes of each INET partition are joined together through 439 external BGP peerings. The c-ASBRs of each partition establish 440 external peerings with the c-ASBRs of other partitions to form a 441 "core-of-cores" OMNI link AS. The OMNI link AS contains the global 442 knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS 443 overlay communications between nodes located in different INET 444 partitions by virtue of OAL encapsulation. OMNI link nodes can then 445 navigate to ASBRs by including an ADM-ULA or directly to an end 446 system by including an MNP-ULA in the destination address of an OAL- 447 encapsulated packet (see: [I-D.templin-6man-aero]). Figure 2 shows a 448 reference OAL topology. 450 . . . . . . . . . . . . . . . . . . . . . . . . . 451 . . 452 . .-(::::::::) . 453 . .-(::::::::::::)-. +------+ . 454 . (::: Partition 1 ::)--|c-ASBR|---+ . 455 . `-(::::::::::::)-' +------+ | . 456 . `-(::::::)-' | . 457 . | . 458 . .-(::::::::) | . 459 . .-(::::::::::::)-. +------+ | . 460 . (::: Partition 2 ::)--|c-ASBR|---+ . 461 . `-(::::::::::::)-' +------+ | . 462 . `-(::::::)-' | . 463 . | . 464 . .-(::::::::) | . 465 . .-(::::::::::::)-. +------+ | . 466 . (::: Partition 3 ::)--|c-ASBR|---+ . 467 . `-(::::::::::::)-' +------+ | . 468 . `-(::::::)-' | . 469 . | . 470 . ..(etc).. x . 471 . . 472 . . 473 . <- ATN/IPS Overlay Bridged by the OAL AS -> . 474 . . . . . . . . . . . . . .. . . . . . . . . . . . 476 Figure 2: Spanning Partitions with the OAL 478 Scaling properties of this ATN/IPS routing system are limited by the 479 number of BGP routes that can be carried by the c-ASBRs. A 2015 480 study showed that BGP routers in the global public Internet at that 481 time carried more than 500K routes with linear growth and no signs of 482 router resource exhaustion [BGP]. A more recent network emulation 483 study also showed that a single c-ASBR can accommodate at least 1M 484 dynamically changing BGP routes even on a lightweight virtual 485 machine. Commercially-available high-performance dedicated router 486 hardware can support many millions of routes. 488 Therefore, assuming each c-ASBR can carry 1M or more routes, this 489 means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by 490 a single set of c-ASBRs and that number could be further increased by 491 using RRs and/or more powerful routers. Another means of increasing 492 scale would be to assign a different set of c-ASBRs for each set of 493 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 494 from each set of c-ASBRs, but the s-ASBR institutes route filters so 495 that it only sends BGP updates to the specific set of c-ASBRs that 496 aggregate the MSP. In this way, each set of c-ASBRs maintains 497 separate routing and forwarding tables so that scaling is distributed 498 across multiple c-ASBR sets instead of concentrated in a single 499 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 500 segment A::/32, a second set could aggregate B::/32, a third could 501 aggregate C::/32, etc. The union of all MSP segments would then 502 constitute the collective MSP(s) for the entire ATN/IPS, with 503 potential for supporting many millions of mobile networks or more. 505 In this way, each set of c-ASBRs services a specific set of MSPs, and 506 each s-ASBR configures MSP-specific routes that list the correct set 507 of c-ASBRs as next hops. This design also allows for natural 508 incremental deployment, and can support initial medium-scale 509 deployments followed by dynamic deployment of additional ATN/IPS 510 infrastructure elements without disturbing the already-deployed base. 511 For example, a few more c-ASBRs could be added if the MNP service 512 demand ever outgrows the initial deployment. For larger-scale 513 applications (such as unmanned air vehicles and terrestrial vehicles) 514 even larger scales can be accommodated by adding more c-ASBRs. 516 4. ATN/IPS (Radio) Access Network (ANET) Model 518 (Radio) Access Networks (ANETs) connect end system Clients such as 519 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 520 connect to multiple ANETs at once, for example, when they have both 521 satellite and cellular data links activated simultaneously. Clients 522 configure an Overlay Multilink Network (OMNI) Interface 523 [I-D.templin-6man-omni] over their underlying ANET interfaces as a 524 connection to an NBMA virtual link (manifested by the OAL) that spans 525 the entire ATN/IPS. Clients may further move between ANETs in a 526 manner that is perceived as a network layer mobility event. Clients 527 could therefore employ a multilink/mobility routing service such as 528 those discussed in Section 7. 530 Clients register all of their active data link connections with their 531 serving s-ASBRs as discussed in Section 3. Clients may connect to 532 s-ASBRs either directly, or via a Proxy/Server at the ANET/INET 533 boundary. 535 Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs 536 via aviation data links. Clients register their ANET addresses with 537 a nearby s-ASBR, where the registration process may be brokered by a 538 Proxy/Server at the edge of the ANET. 540 +-----------------+ 541 | Client | 542 Data Link "A" +-----------------+ Data Link "B" 543 +----- | OMNI Interface |--------+ 544 / +-----------------+ \ 545 / \ 546 / \ 547 (:::)-. (:::)-. 548 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 549 `-(::::)-' `-(::::)-' 550 +-------+ +-------+ 551 ... | P/S | ............................ | P/S | ... 552 . +-------+ +-------+ . 553 . ^^ ^^ . 554 . || || . 555 . || +--------+ || . 556 . ++============> | s-ASBR | <============++ . 557 . +--------+ . 558 . | eBGP . 559 . (:::)-. . 560 . .-(::::::::) . 561 . .-(::: ATN/IPS :::)-. . 562 . (::::: BGP Routing ::::) . 563 . `-(:: System ::::)-' . 564 . `-(:::::::-' . 565 . . 566 . . 567 . <------- OMNI virtual link bridged by the OAL --------> . 568 ............................................................ 570 Figure 3: ATN/IPS ANET Architecture 572 When a Client logs into an ANET it specifies a nearby s-ASBR that it 573 has selected to connect to the ATN/IPS. The login process is 574 transparently brokered by a Proxy/Server at the border of the ANET 575 which then conveys the connection request to the s-ASBR via tunneling 576 across the OMNI virtual link. Each ANET border Proxy/Server is also 577 equally capable of serving in the s-ASBR role so that a first on-link 578 Proxy/Server can be selected as the s-ASBR while all others perform 579 the Proxy/Server role in a hub-and-spokes arrangement. An on-link 580 Proxy/Server is selected to serve the s-ASBR role when it receives a 581 control message from a Client requesting that service. 583 The Client can coordinate with a network-based s-ASBR over additional 584 ANETs after it has already coordinated with a first-hop Proxy/Server 585 over a first ANET. Selection of a network-based s-ASBR could be 586 through an address discovered through a first ANET Proxy/Server, 587 through consulting a geographically-keyed static host file, through a 588 DNS lookup, through a network query response, etc. The s-ASBR then 589 registers the addresses of the additional ANET Proxy/Server as the 590 address for the Client over each distinct Client interface. If the 591 Client connects to multiple ANETs, the s-ASBR will register the 592 addresses of all Proxy/Servers as addresses through which the Client 593 can be reached. 595 The s-ASBR represents all of its active Clients as MNP-ULA routes in 596 the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore 597 consists of the set of all of its active Clients (i.e., the stub AS 598 is a logical construct and not a physical construct). The s-ASBR 599 injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs 600 of its departed Clients via BGP updates to c-ASBRs, which further 601 propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since 602 Clients are expected to remain associated with their current s-ASBR 603 for extended periods, the level of MNP-ULA injections and withdrawals 604 in the BGP routing system will be on the order of the numbers of 605 network joins, leaves and s-ASBR handovers for aircraft operations 606 (see: Section 6). It is important to observe that fine-grained 607 events such as Client mobility and Quality of Service (QoS) signaling 608 are coordinated only by Proxies and the Client's current s-ASBRs, and 609 do not involve other ASBRs in the routing system. In this way, 610 intradomain routing changes within the stub AS are not propagated 611 into the rest of the ATN/IPS BGP routing system. 613 5. ATN/IPS Route Optimization 615 ATN/IPS end systems will frequently need to communicate with 616 correspondents associated with other s-ASBRs. In the BGP peering 617 topology discussed in Section 3, this can initially only be 618 accommodated by including multiple spanning tree segments in the 619 forwarding path. In many cases, it would be desirable to eliminate 620 extraneous spanning tree segments from this "dogleg" route so that 621 packets can traverse a minimum number of tunneling hops across the 622 OMNI virtual link. ATN/IPS end systems could therefore employ a 623 route optimization service according to the mobility service employed 624 (see: Section 7). 626 A route optimization example is shown in Figure 4 and Figure 5 below. 627 In the first figure, multiple spanning tree segments between Proxys 628 and ASBRs are necessary to convey packets between Clients associated 629 with different s-ASBRs. In the second figure, the optimized route 630 tunnels packets directly between Proxys without involving the ASBRs. 632 +---------+ +---------+ 633 | Client1 | | Client2 | 634 +---v-----+ +-----^---+ 635 * * 636 * * 637 (:::)-. (:::)-. 638 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 639 `-(::::)-' `-(::::)-' 640 +--------+ +--------+ 641 ... | P/S-1 | .......................... | P/S-2 | ... 642 . +--------+ +--------+ . 643 . ** ** . 644 . ** ** . 645 . ** ** . 646 . +---------+ +---------+ . 647 . | s-ASBR1 | | s-ASBR2 | . 648 . +--+------+ +-----+---+ . 649 . \ ** Dogleg ** / . 650 . eBGP\ ** Route ** /eBGP . 651 . \ **==============** / . 652 . +---------+ +---------+ . 653 . | c-ASBR1 | | c-ASBR2 | . 654 . +---+-----+ +----+----+ . 655 . +--------------+ . 656 . iBGP . 657 . . 658 . <------- OMNI virtual link bridged by the OAL --------> . 659 ............................................................ 661 Figure 4: Dogleg Route Before Optimization 663 +---------+ +---------+ 664 | Client1 | | Client2 | 665 +---v-----+ +-----^---+ 666 * * 667 * * 668 (:::)-. (:::)-. 669 .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) 670 `-(::::)-' `-(::::)-' 671 +--------+ +--------+ 672 ... | P/S-1 | .......................... | P/S-2 | ... 673 . +------v-+ +--^-----+ . 674 . * * . 675 . *================================* . 676 . . 677 . +---------+ +---------+ . 678 . | s-ASBR1 | | s-ASBR2 | . 679 . +--+------+ +-----+---+ . 680 . \ / . 681 . eBGP\ /eBGP . 682 . \ / . 683 . +---------+ +---------+ . 684 . | c-ASBR1 | | c-ASBR2 | . 685 . +---+-----+ +----+----+ . 686 . +--------------+ . 687 . iBGP . 688 . . 689 . <------- OMNI virtual link bridged by the OAL --------> . 690 ............................................................ 692 Figure 5: Optimized Route 694 6. BGP Protocol Considerations 696 The number of eBGP peering sessions that each c-ASBR must service is 697 proportional to the number of s-ASBRs in its local partition. 698 Network emulations with lightweight virtual machines have shown that 699 a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs 700 that each advertise 10K MNP-ULA routes (i.e., 1M total). It is 701 expected that robust c-ASBRs can service many more peerings than this 702 - possibly by multiple orders of magnitude. But even assuming a 703 conservative limit, the number of s-ASBRs could be increased by also 704 increasing the number of c-ASBRs. Since c-ASBRs also peer with each 705 other using iBGP, however, larger-scale c-ASBR deployments may need 706 to employ an adjunct facility such as BGP Route Reflectors 707 (RRs)[RFC4456]. 709 The number of aircraft in operation at a given time worldwide is 710 likely to be significantly less than 1M, but we will assume this 711 number for a worst-case analysis. Assuming a worst-case average 1 712 hour flight profile from gate-to-gate with 10 service region 713 transitions per flight, the entire system will need to service at 714 most 10M BGP updates per hour (2778 updates per second). This number 715 is within the realm of the peak BGP update messaging seen in the 716 global public Internet today [BGP2]. Assuming a BGP update message 717 size of 100 bytes (800bits), the total amount of BGP control message 718 traffic to a single c-ASBR will be less than 2.5Mbps which is a 719 nominal rate for modern data links. 721 Industry standard BGP routers provide configurable parameters with 722 conservative default values. For example, the default hold time is 723 90 seconds, the default keepalive time is 1/3 of the hold time, and 724 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 725 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 726 For the simple mobile routing system described herein, these 727 parameters can be set to more aggressive values to support faster 728 neighbor/link failure detection and faster routing protocol 729 convergence times. For example, a hold time of 3 seconds and a 730 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 732 Instead of adjusting BGP default time values, BGP routers can use the 733 Bidirectional Forwarding Detection (BFD) protocol [RFC5880] to 734 quickly detect link failures that don't result in interface state 735 changes, BGP peer failures, and administrative state changes. BFD is 736 important in environments where rapid response to failures is 737 required for routing reconvergence and, hence, communications 738 continuity. 740 Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with 741 the ATN/IPS unicast IPv6 routes resolving over INET routes. 742 Consequently, c-ASBRs and potentially s-ASBRs will need to support 743 separate local ASes for the two BGP routing domains and routing 744 policy or assure routes are not propagated between the two BGP 745 routing domains. From a conceptual and operational standpoint, the 746 implementation should provide isolation between the two BGP routing 747 domains (e.g., separate BGP instances). 749 ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random 750 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 751 OMNI link identifier '*' to form the prefix [ULA*]::/64. Each 752 individual address taken from [ULA*]::/64 includes additional routing 753 information in the interface identifier. For example, for the MNP 754 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 755 and for the administrative address 1001:2002/16 the ADM-ULA is 756 [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further 757 details). This gives rise to a BGP routing system that must 758 accommodate large numbers of long and non-aggregatable MNP-ULA 759 prefixes as well as moderate numbers of long and semi-aggregatable 760 ADM-ULA prefixes. The system is kept stable and scalable through the 761 s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- 762 related churn is not exposed to the core. 764 7. Stub AS Mobile Routing Services 766 Stub ASes maintain intradomain routing information for mobile node 767 clients, and are responsible for all localized mobility signaling 768 without disturbing the BGP routing system. Clients can enlist the 769 services of a candidate mobility service such as Mobile IPv6 (MIPv6) 770 [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO 771 [I-D.templin-6man-aero] according to the service offered by the stub 772 AS. Further details of mobile routing services are out of scope for 773 this document. 775 8. Implementation Status 777 The BGP routing topology described in this document has been modeled 778 in realistic network emulations showing that at least 1 million MNP- 779 ULAs can be propagated to each c-ASBR even on lightweight virtual 780 machines. No BGP routing protocol extensions need to be adopted. 782 9. IANA Considerations 784 This document does not introduce any IANA considerations. 786 10. Security Considerations 788 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 789 profiles as for any Internet nodes. For this reason, ASBRs should 790 employ physical security and/or IP securing mechanisms such as IPsec 791 [RFC4301], TLS [RFC5246], WireGuard, etc. 793 ATN/IPS ASBRs present targets for Distributed Denial of Service 794 (DDoS) attacks. This concern is no different than for any node on 795 the open Internet, where attackers could send spoofed packets to the 796 node at high data rates. This can be mitigated by connecting ATN/IPS 797 ASBRs over dedicated links with no connections to the Internet and/or 798 when ASBR connections to the Internet are only permitted through 799 well-managed firewalls. 801 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 802 aviation data links from receiving DDoS packet floods. 804 BGP protocol message exchanges and control message exchanges used for 805 route optimization must be secured to ensure the integrity of the 806 system-wide routing information base. 808 This document does not include any new specific requirements for 809 mitigation of DDoS. 811 11. Acknowledgements 813 This work is aligned with the FAA as per the SE2025 contract number 814 DTFAWA-15-D-00030. 816 This work is aligned with the NASA Safe Autonomous Systems Operation 817 (SASO) program under NASA contract number NNA16BD84C. 819 This work is aligned with the Boeing Commercial Airplanes (BCA) 820 Internet of Things (IoT) and autonomy programs. 822 This work is aligned with the Boeing Information Technology (BIT) 823 MobileNet program. 825 The following individuals contributed insights that have improved the 826 document: Ahmad Amin, Erik Kline, Hubert Kuenig, Tony Li, Alexandre 827 Petrescu, Pascal Thubert, Tony Whyman. 829 12. References 831 12.1. Normative References 833 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 834 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 835 December 1998, . 837 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 838 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 839 . 841 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 842 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 843 DOI 10.17487/RFC4271, January 2006, 844 . 846 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 847 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 848 2006, . 850 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 851 Control Message Protocol (ICMPv6) for the Internet 852 Protocol Version 6 (IPv6) Specification", STD 89, 853 RFC 4443, DOI 10.17487/RFC4443, March 2006, 854 . 856 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 857 Reflection: An Alternative to Full Mesh Internal BGP 858 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 859 . 861 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 862 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 863 . 865 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 866 (IPv6) Specification", STD 86, RFC 8200, 867 DOI 10.17487/RFC8200, July 2017, 868 . 870 12.2. Informative References 872 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 873 Interface for Civil Aviation, IETF Liaison Statement 874 #1676, https://datatracker.ietf.org/liaison/1676/", 3 875 March 2020. 877 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 878 Aeronautical Telecommunication Network (ATN) using 879 Internet Protocol Suite (IPS) Standards and Protocol), 880 Draft Edition 3 (work-in-progress)", 10 December 2020. 882 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 883 2016. 885 [BGP2] Huston, G., "BGP Instability Report, 886 http://bgpupdates.potaroo.net/instability/bgpupd.html", 887 May 2017. 889 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 890 Protocol (BGP), http://www.quark.net/docs/ 891 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 893 [I-D.ietf-lisp-rfc6830bis] 894 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 895 Cabellos, "The Locator/ID Separation Protocol (LISP)", 896 Work in Progress, Internet-Draft, draft-ietf-lisp- 897 rfc6830bis-36, 18 November 2020, 898 . 901 [I-D.templin-6man-aero] 902 Templin, F. L., "Automatic Extended Route Optimization 903 (AERO)", Work in Progress, Internet-Draft, draft-templin- 904 6man-aero-37, 15 November 2021, 905 . 908 [I-D.templin-6man-omni] 909 Templin, F. L. and T. Whyman, "Transmission of IP Packets 910 over Overlay Multilink Network (OMNI) Interfaces", Work in 911 Progress, Internet-Draft, draft-templin-6man-omni-51, 15 912 November 2021, . 915 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 916 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 917 DOI 10.17487/RFC2784, March 2000, 918 . 920 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 921 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 922 December 2005, . 924 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 925 (TLS) Protocol Version 1.2", RFC 5246, 926 DOI 10.17487/RFC5246, August 2008, 927 . 929 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 930 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 931 2011, . 933 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 934 Autonomous System (AS) Number Space", RFC 6793, 935 DOI 10.17487/RFC6793, December 2012, 936 . 938 Appendix A. BGP Convergence Considerations 940 Experimental evidence has shown that BGP convergence time required 941 for when an MNP-ULA is asserted at a new location or withdrawn from 942 an old location can be several hundred milliseconds even under 943 optimal AS peering arrangements. This means that packets in flight 944 destined to an MNP-ULA route that has recently been changed can be 945 (mis)delivered to an old s-ASBR after a Client has moved to a new 946 s-ASBR. 948 To address this issue, the old s-ASBR can maintain temporary state 949 for a "departed" Client that includes an OAL address for the new 950 s-ASBR. The OAL address never changes since ASBRs are fixed 951 infrastructure elements that never move. Hence, packets arriving at 952 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 953 routing system is still undergoing reconvergence. Therefore, as long 954 as the Client associates with the new s-ASBR before it departs from 955 the old s-ASBR (while informing the old s-ASBR of its new location) 956 packets in flight during the BGP reconvergence window are 957 accommodated without loss. 959 Appendix B. Change Log 961 << RFC Editor - remove prior to publication >> 963 Differences from earlier versions: 965 * Submit for RFC publication. 967 Authors' Addresses 969 Fred L. Templin (editor) 970 Boeing Research & Technology 971 P.O. Box 3707 972 Seattle, WA 98124 973 United States of America 975 Email: fltemplin@acm.org 977 Greg Saccone 978 Boeing Research & Technology 979 P.O. Box 3707 980 Seattle, WA 98124 981 United States of America 983 Email: gregory.t.saccone@boeing.com 984 Gaurav Dawra 985 LinkedIn 986 United States of America 988 Email: gdawra.ietf@gmail.com 990 Acee Lindem 991 Cisco Systems, Inc. 992 United States of America 994 Email: acee@cisco.com 996 Victor Moreno 997 Cisco Systems, Inc. 998 United States of America 1000 Email: vimoreno@cisco.com