idnits 2.17.1 draft-ietf-rtgwg-atn-bgp-11.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2021) is 1025 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 909, 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 (-63) exists of draft-templin-6man-aero-01 == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-03 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft G. Saccone 4 Intended status: Informational Boeing Research & Technology 5 Expires: January 7, 2022 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 July 6, 2021 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-11 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 January 7, 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 66 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12 67 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14 68 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16 69 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18 70 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 76 12.2. Informative References . . . . . . . . . . . . . . . . . 20 77 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 21 78 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 81 1. Introduction 83 The worldwide Air Traffic Management (ATM) system today uses a 84 service known as Aeronautical Telecommunications Network based on 85 Open Systems Interconnection (ATN/OSI). The service is used to 86 augment controller to pilot voice communications with rudimentary 87 short text command and control messages. The service has seen 88 successful deployment in a limited set of worldwide ATM domains. 90 The International Civil Aviation Organization (ICAO) is now 91 undertaking the development of a next-generation replacement for ATN/ 92 OSI known as Aeronautical Telecommunications Network with Internet 93 Protocol Services (ATN/IPS) [ATN][ATN-IPS]. ATN/IPS will eventually 94 provide an IPv6-based [RFC8200] service supporting pervasive ATM for 95 Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), 96 and all commercial aircraft worldwide. As part of the ATN/IPS 97 undertaking, a new mobile routing service will be needed. This 98 document presents an approach based on the Border Gateway Protocol 99 (BGP) [RFC4271]. 101 Aircraft communicate via wireless aviation data links that typically 102 support much lower data rates than terrestrial wireless and wired- 103 line communications. For example, some Very High Frequency (VHF)- 104 based data links only support data rates on the order of 32Kbps and 105 an emerging L-Band data link that is expected to play a key role in 106 future aeronautical communications only supports rates on the order 107 of 1Mbps. Although satellite data links can provide much higher data 108 rates during optimal conditions, like any other aviation data link 109 they are subject to errors, delay, disruption, signal intermittence, 110 degradation due to atmospheric conditions, etc. The well-connected 111 ground domain ATN/IPS network should therefore treat each safety-of- 112 flight critical packet produced by (or destined to) an aircraft as a 113 precious commodity and strive for an optimized service that provides 114 the highest possible degree of reliability. 116 The ATN/IPS is an IPv6-based overlay network configured over one or 117 more Internetworking underlays ("INETs") maintained by aeronautical 118 network service providers such as ARINC, SITA and Inmarsat. The 119 overlay provides an Overlay Multilink Network Interface (OMNI) 120 virtual link layer [I-D.templin-6man-omni] as a Non-Broadcast, 121 Multiple Access (NBMA) virtual link that spans the entire ATN/IPS. 122 Each aircraft connects to the OMNI link via an OMNI interface 123 configured over the aircraft's underlying physical and/or virtual 124 access network interfaces. 126 Each underlying INET comprises one or more "partitions" where all 127 nodes within a partition can exchange packets with all other nodes, 128 i.e., the partition is connected internally. There is no requirement 129 that any two INET partitions use the same IP protocol version nor 130 have consistent IP addressing plans in comparison with other 131 partitions. Instead, the OMNI link sees each partition as a 132 "segment" of a link-layer topology manifested through a (virtual) 133 bridging service based on IPv6 encapsulation [RFC2473] known as the 134 OMNI Adaptation Layer (OAL) 135 [I-D.templin-6man-omni][I-D.templin-6man-aero]. 137 The IPv6 addressing architecture provides different classes of 138 addresses, including Global Unicast Addresses (GUAs), Unique Local 139 Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. 140 The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from 141 an Internet assigned numbers authority, and each aircraft will 142 receive a Mobile Network Prefix (MNP) delegation from the MSP that 143 accompanies the aircraft wherever it travels. ATCs and AOCs will 144 likewise receive MNPs, but they would typically appear in static (not 145 mobile) deployments such as air traffic control towers, airline 146 headquarters, etc. 148 The OAL uses ULAs in the source and destination addresses of IPv6 149 encapsulation headers. Each ULA includes an MNP in the interface 150 identifier ("MNP-ULA") as discussed in [I-D.templin-6man-omni]. Due 151 to MNP delegation policies and random MN mobility properties, MNP- 152 ULAs are generally not aggregatable in the BGP routing service and 153 are represented as many more-specific prefixes instead of a smaller 154 number of aggregated prefixes. In addition, OMNI link service nodes 155 configure administratively-assigned ULAs ("ADM-ULA") that are 156 statically-assigned and derived from a shorter ADM-ULA prefix 157 assigned to their OMNI link partition [I-D.templin-6man-omni]. 158 Unlike MNP-ULAs, the ADM-ULAs are persistently present and unchanging 159 in the routing system. The BGP routing services therefore perform 160 forwarding based on these MNP-ULAs and ADM-ULAs instead of based on 161 the GUA MNPs themselves. 163 Connexion By Boeing [CBB] was an early aviation mobile routing 164 service based on dynamic updates in the global public Internet BGP 165 routing system. Practical experience with the approach has shown 166 that frequent injections and withdrawals of prefixes in the Internet 167 routing system can result in excessive BGP update messaging, slow 168 routing table convergence times, and extended outages when no route 169 is available. This is due to both conservative default BGP protocol 170 timing parameters (see Section 6) and the complex peering 171 interconnections of BGP routers within the global Internet 172 infrastructure. The situation is further exacerbated by frequent 173 aircraft mobility events that each result in BGP updates that must be 174 propagated to all BGP routers in the Internet that carry a full 175 routing table. 177 We therefore consider an approach using a BGP overlay network routing 178 system where a private BGP routing protocol instance is maintained 179 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 180 private BGP instance does not interact with the native BGP routing 181 systems in underlying INETs, and BGP updates are unidirectional from 182 "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a 183 hub-and-spokes topology. No extensions to the BGP protocol are 184 necessary. BGP routing is based on the ULAs found in OAL headers, 185 i.e., it provides an adaptation layer forwarding service instead of a 186 networking layer routing service. 188 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 189 dedicated high speed links and/or tunnels across the INET using 190 industry-standard secured encapsulations (e.g., IPsec [RFC4301], 191 Wireguard, etc.). In particular, tunneling must be used when 192 neighboring ASBRs are separated by multiple INET hops. 194 The s-ASBRs engage in external BGP (eBGP) peerings with their 195 respective c-ASBRs, and only maintain routing table entries for the 196 MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP 197 updates for MNP-ULA injections or withdrawals to c-ASBRs but do not 198 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 199 default routes with their c-ASBRs as the next hop, and therefore hold 200 only partial topology information. 202 The c-ASBRs connect to other c-ASBRs within the same partition using 203 internal BGP (iBGP) peerings over which they collaboratively maintain 204 a full routing table for all active MNP-ULAs currently in service 205 within the partition. Therefore, only the c-ASBRs maintain a full 206 BGP routing table and never send any BGP updates to s-ASBRs. This 207 simple routing model therefore greatly reduces the number of BGP 208 updates that need to be synchronized among peers, and the number is 209 reduced further still when intradomain routing changes within stub 210 ASes are processed within the AS instead of being propagated to the 211 core. BGP Route Reflectors (RRs) [RFC4456] can also be used to 212 support increased scaling properties. 214 When there are multiple INET partitions, the c-ASBRs of each 215 partition use eBGP to peer with the c-ASBRs of other partitions so 216 that the full set of ULAs for all partitions are known globally among 217 all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA 218 which is taken from an ADM-ULA prefix assigned to each partition, as 219 well as static forwarding table entries for all other OMNI link 220 partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL 221 for nested encapsulation where the inner IPv6 packet is encapsulated 222 in an IPv6 OAL header with ULA source and destination addresses, 223 which is then encapsulated in an IP header specific to the INET 224 partition. 226 With these intra- and inter-INET BGP peerings in place, a forwarding 227 plane spanning tree is established that properly covers the entire 228 operating domain. All nodes in the network can be visited using 229 strict spanning tree hops, but in many instances this may result in 230 longer paths than are necessary. The AERO and OMNI services 231 [I-D.templin-6man-aero][I-D.templin-6man-omni] provide mechanisms for 232 discovering and utilizing (route-optimized) shortcuts that do not 233 always follow strict spanning tree paths. 235 The remainder of this document discusses the proposed BGP-based ATN/ 236 IPS mobile routing service. 238 2. Terminology 240 The terms Autonomous System (AS) and Autonomous System Border Router 241 (ASBR) are the same as defined in [RFC4271]. 243 The following terms are defined for the purposes of this document: 245 Air Traffic Management (ATM) 246 The worldwide service for coordinating safe aviation operations. 248 Air Traffic Controller (ATC) 249 A government agent responsible for coordinating with aircraft 250 within a defined operational region via voice and/or data Command 251 and Control messaging. 253 Airline Operations Controller (AOC) 254 An airline agent responsible for tracking and coordinating with 255 aircraft within their fleet. 257 Aeronautical Telecommunications Network with Internet Protocol 258 Services (ATN/IPS) 259 A future aviation network for ATCs and AOCs to coordinate with all 260 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 261 overlay network service that connects access networks via 262 tunneling over one or more Internetworking underlays. 264 Internetworking underlay ("INET") 265 A wide-area network that supports overlay network tunneling and 266 connects Radio Access Networks to the rest of the ATN/IPS. 267 Example INET service providers for civil aviation include ARINC, 268 SITA and Inmarsat. 270 (Radio) Access Network ("ANET") 271 An aviation radio data link service provider's network, including 272 radio transmitters and receivers as well as supporting ground- 273 domain infrastructure needed to convey a customer's data packets 274 to outside INETs. The term ANET is intended in the same spirit as 275 for radio-based Internet service provider networks (e.g., cellular 276 operators), but can also refer to ground-domain networks that 277 connect AOCs and ATCs. 279 partition (or "segment") 280 A fully-connected internal subnetwork of an INET in which all 281 nodes can communicate with all other nodes within the same 282 partition using the same IP protocol version and addressing plan. 283 Each INET consists of one or more partitions. 285 Overlay Multilink Network Interface (OMNI) 286 A virtual layer 2 bridging service that presents an ATN/IPS 287 overlay unified link view even though the underlay may consist of 288 multiple INET partitions. The OMNI virtual link is manifested 289 through nested encapsulation in which GUA-addressed IPv6 packets 290 from the ATN/IPS are first encapsulated in ULA-addressed IPv6 291 headers which are then forwarded to the next hop using INET 292 encapsulation if necessary. Forwarding over the OMNI virtual link 293 is therefore based on ULAs instead of GUAs. In this way, packets 294 sent from a source can be conveyed over the OMNI virtual link even 295 though there may be many underlying INET partitions in the path to 296 the destination. 298 OMNI Adaptation Layer (OAL) 299 A middle layer below the IPv6 layer but above the INET layer that 300 applies IPv6-in-IPv6 encapsulation prior to INET encapsulation. 301 The IPv6 encapsulation header inserted by the OAL uses ULAs 302 instead of GUAs. Further details on OMNI and the OAL are found in 303 [I-D.templin-6man-omni]. 305 OAL Autonomous System 306 A "hub-of-hubs" autonomous system maintained through peerings 307 between the core autonomous systems of different OMNI virtual link 308 partitions. 310 Core Autonomous System Border Router (c-ASBR) 311 A BGP router located in the hub of the INET partition hub-and- 312 spokes overlay network topology. 314 Core Autonomous System 315 The "hub" autonomous system maintained by all c-ASBRs within the 316 same partition. 318 Stub Autonomous System Border Router (s-ASBR) 319 A BGP router configured as a spoke in the INET partition hub-and- 320 spokes overlay network topology. 322 Stub Autonomous System 323 A logical grouping that includes all Clients currently associated 324 with a given s-ASBR. 326 Client 327 An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf 328 node. The Client could be a singleton host, or a router that 329 connects a mobile or fixed network. 331 Proxy 332 An ANET/INET border node that acts as a transparent intermediary 333 between Clients and s-ASBRs. From the Client's perspective, the 334 Proxy presents the appearance that the Client is communicating 335 directly with the s-ASBR. From the s-ASBR's perspective, the 336 Proxy presents the appearance that the s-ASBR is communicating 337 directly with the Client. 339 Mobile Network Prefix (MNP) 340 An IPv6 prefix that is delegated to any ATN/IPS end system, 341 including ATCs, AOCs, and aircraft. 343 Mobility Service Prefix (MSP) 344 An aggregated prefix assigned to the ATN/IPS by an Internet 345 assigned numbers authority, and from which all MNPs are delegated 346 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 347 MSP). 349 3. ATN/IPS Routing System 351 The ATN/IPS routing system comprises a private BGP instance 352 coordinated in an overlay network via tunnels between neighboring 353 ASBRs over one or more underlying INETs. The overlay does not 354 interact with the underlying INET BGP routing systems, and only a 355 small and unchanging set of MSPs are advertised externally instead of 356 the full dynamically changing set of MNPs. 358 Within each INET partition, each s-ASBRs connects a stub AS to the 359 INET partition core using a distinct stub AS Number (ASN). Each 360 s-ASBR further uses eBGP to peer with one or more c-ASBRs. All 361 c-ASBRs are members of the INET partition core AS, and use a shared 362 core ASN. Unique ASNs are assigned according to the standard 32-bit 363 ASN format [RFC4271][RFC6793]. Since the BGP instance does not 364 connect with any INET BGP routing systems, the ASNs assigned need not 365 be coordinated with IANA and can in fact coincide with values that 366 are assigned in other domains. The only requirement is that ASNs 367 must not be duplicated within the ATN/IPS routing system itself. 369 The c-ASBRs use iBGP to maintain a synchronized consistent view of 370 all active MNP-ULAs currently in service within the INET partition. 371 Figure 1 below represents the reference INET partition deployment. 372 (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and 373 s-ASBR2) due to space constraints, but the other s-ASBRs should be 374 understood to have similar Stub AS, MNP and eBGP peering 375 arrangements.) The solution described in this document is flexible 376 enough to extend to these topologies. 378 ........................................................... 379 . . 380 . (:::)-. <- Stub ASes -> (:::)-. . 381 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 382 . `-(::::)-' `-(::::)-' . 383 . +-------+ +-------+ . 384 . |s-ASBR1+-----+ +-----+s-ASBR2| . 385 . +--+----+ eBGP \ / eBGP +-----+-+ . 386 . \ \/ / . 387 . \eBGP / \ /eBGP . 388 . \ / \ / . 389 . +-------+ +-------+ . 390 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 391 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 392 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 393 . +-------+ .-(::::::::) +-------+ . 394 . . .-(::::::::::::::)-. . . 395 . . (:::: Core AS :::) . . 396 . +-------+ `-(:::::::::::::)-' +-------+ . 397 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 398 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 399 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 400 . +-------+ +-------+ . 401 . / \ . 402 . /eBGP \eBGP . 403 . / \ . 404 . +---+---+ +-----+-+ . 405 . |s-ASBR | |s-ASBR | . 406 . +-------+ +-------+ . 407 . . 408 . . 409 . <----------------- INET Partition -------------------> . 410 ............................................................ 412 Figure 1: INET Partition Reference Deployment 414 In the reference deployment, each s-ASBR maintains routes for active 415 MNP-ULAs that currently belong to its stub AS. In response to 416 "Inter-domain" mobility events, each s-ASBR will dynamically 417 announces new MNP-ULAs and withdraws departed MNP-ULAs in its eBGP 418 updates to c-ASBRs. Since ATN/IPS end systems are expected to remain 419 within the same stub AS for extended timeframes, however, intra- 420 domain mobility events (such as an aircraft handing off between cell 421 towers) are handled within the stub AS instead of being propagated as 422 inter-domain eBGP updates. 424 Each c-ASBR configures a black-hole route for each of its MSPs. By 425 black-holing the MSPs, the c-ASBR will maintain forwarding table 426 entries only for the MNP-ULAs that are currently active, and packets 427 destined to all other MNP-ULAs will correctly incur ICMPv6 428 Destination Unreachable messages [RFC4443] due to the black hole 429 route. (This is the same behavior as for ordinary BGP routers in the 430 Internet when they receive packets for which there is no route 431 available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to 432 s-ASBRs, but instead originate a default route. In this way, s-ASBRs 433 have only partial topology knowledge (i.e., they know only about the 434 active MNP-ULAs currently within their stub ASes) and they forward 435 all other packets to c-ASBRs which have full topology knowledge. 437 Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable 438 within an INET partition, and each partition configures a unique ADM- 439 ULA prefix that is permanently announced into the routing system. 440 The core ASes of each INET partition are joined together through 441 external BGP peerings. The c-ASBRs of each partition establish 442 external peerings with the c-ASBRs of other partitions to form a 443 "core-of-cores" OMNI link AS. The OMNI link AS contains the global 444 knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS 445 overlay communications between nodes located in different INET 446 partitions by virtue of OAL encapsulation. OMNI link nodes can then 447 navigate to ASBRs by including an ADM-ULA or directly to an end 448 system by including an MNP-ULA in the destination address of an OAL- 449 encapsulated packet (see: [I-D.templin-6man-aero]). Figure 2 shows a 450 reference OAL topology. 452 . . . . . . . . . . . . . . . . . . . . . . . . . 453 . . 454 . .-(::::::::) . 455 . .-(::::::::::::)-. +------+ . 456 . (::: Partition 1 ::)--|c-ASBR|---+ . 457 . `-(::::::::::::)-' +------+ | . 458 . `-(::::::)-' | . 459 . | . 460 . .-(::::::::) | . 461 . .-(::::::::::::)-. +------+ | . 462 . (::: Partition 2 ::)--|c-ASBR|---+ . 463 . `-(::::::::::::)-' +------+ | . 464 . `-(::::::)-' | . 465 . | . 466 . .-(::::::::) | . 467 . .-(::::::::::::)-. +------+ | . 468 . (::: Partition 3 ::)--|c-ASBR|---+ . 469 . `-(::::::::::::)-' +------+ | . 470 . `-(::::::)-' | . 471 . | . 472 . ..(etc).. x . 473 . . 474 . . 475 . <- ATN/IPS Overlay Bridged by the OAL AS -> . 476 . . . . . . . . . . . . . .. . . . . . . . . . . . 478 Figure 2: Spanning Partitions with the OAL 480 Scaling properties of this ATN/IPS routing system are limited by the 481 number of BGP routes that can be carried by the c-ASBRs. A 2015 482 study showed that BGP routers in the global public Internet at that 483 time carried more than 500K routes with linear growth and no signs of 484 router resource exhaustion [BGP]. A more recent network emulation 485 study also showed that a single c-ASBR can accommodate at least 1M 486 dynamically changing BGP routes even on a lightweight virtual 487 machine. Commercially-available high-performance dedicated router 488 hardware can support many millions of routes. 490 Therefore, assuming each c-ASBR can carry 1M or more routes, this 491 means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by 492 a single set of c-ASBRs and that number could be further increased by 493 using RRs and/or more powerful routers. Another means of increasing 494 scale would be to assign a different set of c-ASBRs for each set of 495 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 496 from each set of c-ASBRs, but the s-ASBR institutes route filters so 497 that it only sends BGP updates to the specific set of c-ASBRs that 498 aggregate the MSP. In this way, each set of c-ASBRs maintains 499 separate routing and forwarding tables so that scaling is distributed 500 across multiple c-ASBR sets instead of concentrated in a single 501 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 502 segment A::/32, a second set could aggregate B::/32, a third could 503 aggregate C::/32, etc. The union of all MSP segments would then 504 constitute the collective MSP(s) for the entire ATN/IPS, with 505 potential for supporting many millions of mobile networks or more. 507 In this way, each set of c-ASBRs services a specific set of MSPs, and 508 each s-ASBR configures MSP-specific routes that list the correct set 509 of c-ASBRs as next hops. This design also allows for natural 510 incremental deployment, and can support initial medium-scale 511 deployments followed by dynamic deployment of additional ATN/IPS 512 infrastructure elements without disturbing the already-deployed base. 513 For example, a few more c-ASBRs could be added if the MNP service 514 demand ever outgrows the initial deployment. For larger-scale 515 applications (such as unmanned air vehicles and terrestrial vehicles) 516 even larger scales can be accommodated by adding more c-ASBRs. 518 4. ATN/IPS (Radio) Access Network (ANET) Model 520 (Radio) Access Networks (ANETs) connect end system Clients such as 521 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 522 connect to multiple ANETs at once, for example, when they have both 523 satellite and cellular data links activated simultaneously. Clients 524 configure an Overlay Multilink Network (OMNI) Interface 525 [I-D.templin-6man-omni] over their underlying ANET interfaces as a 526 connection to an NBMA virtual link (manifested by the OAL) that spans 527 the entire ATN/IPS. Clients may further move between ANETs in a 528 manner that is perceived as a network layer mobility event. Clients 529 could therefore employ a multilink/mobility routing service such as 530 those discussed in Section 7. 532 Clients register all of their active data link connections with their 533 serving s-ASBRs as discussed in Section 3. Clients may connect to 534 s-ASBRs either directly, or via a Proxy at the ANET/INET boundary. 536 Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs 537 via aviation data links. Clients register their ANET addresses with 538 a nearby s-ASBR, where the registration process may be brokered by a 539 Proxy at the edge of the ANET. 541 +-----------------+ 542 | Client | 543 Data Link "A" +-----------------+ Data Link "B" 544 +----- | OMNI Interface |--------+ 545 / +-----------------+ \ 546 / \ 547 / \ 548 (:::)-. (:::)-. 549 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 550 `-(::::)-' `-(::::)-' 551 +-------+ +-------+ 552 ... | Proxy | ............................ | Proxy | ... 553 . +-------+ +-------+ . 554 . ^^ ^^ . 555 . || || . 556 . || +--------+ || . 557 . ++============> | s-ASBR | <============++ . 558 . +--------+ . 559 . | eBGP . 560 . (:::)-. . 561 . .-(::::::::) . 562 . .-(::: ATN/IPS :::)-. . 563 . (::::: BGP Routing ::::) . 564 . `-(:: System ::::)-' . 565 . `-(:::::::-' . 566 . . 567 . . 568 . <------- OMNI virtual link bridged by the OAL --------> . 569 ............................................................ 571 Figure 3: ATN/IPS ANET Architecture 573 When a Client logs into an ANET it specifies a nearby s-ASBR that it 574 has selected to connect to the ATN/IPS. The login process is 575 transparently brokered by a Proxy at the border of the ANET which 576 then conveys the connection request to the s-ASBR via tunneling 577 across the OMNI virtual link. Each ANET border Proxy is also equally 578 capable of serving in the s-ASBR role so that a first on-link Proxy 579 can be selected as the s-ASBR while all others perform the Proxy role 580 in a hub-and-spokes arrangement. An on-link Proxy is selected to 581 serve the s-ASBR role when it receives a control message from a 582 Client requesting that service. 584 A network-based s-ASBR can also be selected when the ANET does not 585 provide a Proxy, or when a different ANET Proxy has already been 586 selected. Selection of a network-based s-ASBR could be through an 587 address discovered through a first ANET Proxy, through consulting a 588 geographically-keyed static host file, through a DNS lookup, through 589 a network query response, etc. The s-ASBR then registers the address 590 of the Proxy as the address for the Client, and the Proxy forwards 591 the s-ASBR's reply to the Client. If the Client connects to multiple 592 ANETs, the s-ASBR will register the addresses of all Proxies as 593 addresses through which the Client 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 ... | Proxy1 | .......................... | Proxy2 | ... 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 ... | Proxy1 | .......................... | Proxy2 | ... 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/", March 875 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)", 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 draft-ietf-lisp-rfc6830bis-36 (work in progress), November 897 2020. 899 [I-D.templin-6man-aero] 900 Templin, F. L., "Automatic Extended Route Optimization 901 (AERO)", draft-templin-6man-aero-01 (work in progress), 902 April 2021. 904 [I-D.templin-6man-omni] 905 Templin, F. L. and T. Whyman, "Transmission of IP Packets 906 over Overlay Multilink Network (OMNI) Interfaces", draft- 907 templin-6man-omni-03 (work in progress), April 2021. 909 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 910 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 911 DOI 10.17487/RFC2784, March 2000, 912 . 914 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 915 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 916 December 2005, . 918 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 919 (TLS) Protocol Version 1.2", RFC 5246, 920 DOI 10.17487/RFC5246, August 2008, 921 . 923 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 924 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 925 2011, . 927 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 928 Autonomous System (AS) Number Space", RFC 6793, 929 DOI 10.17487/RFC6793, December 2012, 930 . 932 Appendix A. BGP Convergence Considerations 934 Experimental evidence has shown that BGP convergence time required 935 for when an MNP-ULA is asserted at a new location or withdrawn from 936 an old location can be several hundred milliseconds even under 937 optimal AS peering arrangements. This means that packets in flight 938 destined to an MNP-ULA route that has recently been changed can be 939 (mis)delivered to an old s-ASBR after a Client has moved to a new 940 s-ASBR. 942 To address this issue, the old s-ASBR can maintain temporary state 943 for a "departed" Client that includes an OAL address for the new 944 s-ASBR. The OAL address never changes since ASBRs are fixed 945 infrastructure elements that never move. Hence, packets arriving at 946 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 947 routing system is still undergoing reconvergence. Therefore, as long 948 as the Client associates with the new s-ASBR before it departs from 949 the old s-ASBR (while informing the old s-ASBR of its new location) 950 packets in flight during the BGP reconvergence window are 951 accommodated without loss. 953 Appendix B. Change Log 955 << RFC Editor - remove prior to publication >> 957 Changes from -10 to -11: 959 o Introduced notion of the spanning tree 961 o Discussed Proxy/s-ASBR arrangement options. 963 Changes from -05 to -06: 965 o OMNI interface introduced 967 o Version and reference update. 969 Changes from -04 to -05: 971 o Version and reference update. 973 Changes from -03 to -04: 975 o added discussion of Bidirectional Forwarding Detection (BFD). 977 Changes from -02 to -03: 979 o added reference to ICAO A/G interface specification. 981 Changes from -01 to -02: 983 o introduced the SPAN and the concept of Internetwork partitioning 985 o new terms "ANET" (for (Radio) Access Network) and "INET" (for 986 Internetworking underlay) 988 o new appendix on BGP convergence considerations 990 Changes from -00 to -01: 992 o incorporated clarifications due to list comments and questions. 994 o new section 7 on Stub AS Mobile Routing Services 996 o updated references, and included new reference for MIPv6 and LISP 998 Status as of 08/30/2018: 1000 o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' 1002 Authors' Addresses 1004 Fred L. Templin (editor) 1005 Boeing Research & Technology 1006 P.O. Box 3707 1007 Seattle, WA 98124 1008 USA 1010 Email: fltemplin@acm.org 1012 Greg Saccone 1013 Boeing Research & Technology 1014 P.O. Box 3707 1015 Seattle, WA 98124 1016 USA 1018 Email: gregory.t.saccone@boeing.com 1020 Gaurav Dawra 1021 LinkedIn 1022 USA 1024 Email: gdawra.ietf@gmail.com 1026 Acee Lindem 1027 Cisco Systems, Inc. 1028 USA 1030 Email: acee@cisco.com 1032 Victor Moreno 1033 Cisco Systems, Inc. 1034 USA 1036 Email: vimoreno@cisco.com