< draft-ietf-rtgwg-atn-bgp-12.txt   draft-ietf-rtgwg-atn-bgp-13.txt >
Network Working Group F. L. Templin, Ed. Network Working Group F. L. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: 5 July 2022 G. Dawra Expires: 11 August 2022 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
1 January 2022 7 February 2022
A Simple BGP-based Mobile Routing System for the Aeronautical A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network Telecommunications Network
draft-ietf-rtgwg-atn-bgp-12 draft-ietf-rtgwg-atn-bgp-13
Abstract Abstract
The International Civil Aviation Organization (ICAO) is investigating The International Civil Aviation Organization (ICAO) is investigating
mobile routing solutions for a worldwide Aeronautical mobile routing solutions for a worldwide Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS). Telecommunications Network with Internet Protocol Services (ATN/IPS).
The ATN/IPS will eventually replace existing communication services The ATN/IPS will eventually replace existing communication services
with an IPv6-based service supporting pervasive Air Traffic with an IP-based service supporting pervasive Air Traffic Management
Management (ATM) for Air Traffic Controllers (ATC), Airline (ATM) for Air Traffic Controllers (ATC), Airline Operations
Operations Controllers (AOC), and all commercial aircraft worldwide. Controllers (AOC), and all commercial aircraft worldwide. This
This informational document describes a simple and extensible mobile informational document describes a simple and extensible mobile
routing service based on industry-standard BGP to address the ATN/IPS routing service based on industry-standard BGP to address the ATN/IPS
requirements. requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 July 2022. This Internet-Draft will expire on 11 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 26 skipping to change at page 2, line 26
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 17
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 19
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Public Key Infrastructure (PKI) Considerations . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The worldwide Air Traffic Management (ATM) system today uses a The worldwide Air Traffic Management (ATM) system today uses a
service known as Aeronautical Telecommunications Network based on service known as Aeronautical Telecommunications Network based on
Open Systems Interconnection (ATN/OSI). The service is used to Open Systems Interconnection (ATN/OSI). The service is used to
augment controller to pilot voice communications with rudimentary augment controller to pilot voice communications with rudimentary
short text command and control messages. The service has seen short text command and control messages. The service has seen
successful deployment in a limited set of worldwide ATM domains. successful deployment in a limited set of worldwide ATM domains.
skipping to change at page 3, line 29 skipping to change at page 3, line 30
degradation due to atmospheric conditions, etc. The well-connected degradation due to atmospheric conditions, etc. The well-connected
ground domain ATN/IPS network should therefore treat each safety-of- ground domain ATN/IPS network should therefore treat each safety-of-
flight critical packet produced by (or destined to) an aircraft as a flight critical packet produced by (or destined to) an aircraft as a
precious commodity and strive for an optimized service that provides precious commodity and strive for an optimized service that provides
the highest possible degree of reliability. the highest possible degree of reliability.
The ATN/IPS is an IPv6-based overlay network configured over one or The ATN/IPS is an IPv6-based overlay network configured over one or
more Internetworking underlays ("INETs") maintained by aeronautical more Internetworking underlays ("INETs") maintained by aeronautical
network service providers such as ARINC, SITA and Inmarsat. The network service providers such as ARINC, SITA and Inmarsat. The
Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni]
provides a Non-Broadcast, Multiple Access (NBMA) virtual link that uses an adaptation layer encapsulation to create a Non-Broadcast,
spans the entire ATN/IPS. Each aircraft connects to the OMNI link Multiple Access (NBMA) virtual link spanning the entire ATN/IPS.
via an OMNI interface configured over the aircraft's underlying Each aircraft connects to the OMNI link via an OMNI interface
physical and/or virtual access network interfaces. configured over the aircraft's underlying physical and/or virtual
access network interfaces.
Each underlying INET comprises one or more "partitions" where all Each underlying INET comprises one or more "partitions" where all
nodes within a partition can exchange packets with all other nodes, nodes within a partition can exchange packets with all other nodes,
i.e., the partition is connected internally. There is no requirement i.e., the partition is connected internally. There is no requirement
that any two INET partitions use the same IP protocol version nor that any two INET partitions use the same IP protocol version nor
have consistent IP addressing plans in comparison with other have consistent IP addressing plans in comparison with other
partitions. Instead, the OMNI link sees each partition as a partitions. Instead, the OMNI link sees each partition as a
"segment" of a link-layer topology concatenated by a service known as "segment" of a link-layer topology concatenated by a service known as
the OMNI Adaptation Layer (OAL) the OMNI Adaptation Layer (OAL) [I-D.templin-6man-omni] based on IPv6
[I-D.templin-6man-omni][I-D.templin-6man-aero] based on IPv6
encapsulation [RFC2473]. encapsulation [RFC2473].
The IPv6 addressing architecture provides different classes of The IPv6 addressing architecture provides different classes of
addresses, including Global Unicast Addresses (GUAs), Unique Local addresses, including Global Unicast Addresses (GUAs), Unique Local
Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193].
The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from
an Internet assigned numbers authority, and each aircraft will an Internet assigned numbers authority, and each aircraft will
receive a Mobile Network Prefix (MNP) delegation from the MSP that receive a Mobile Network Prefix (MNP) delegation from the MSP that
accompanies the aircraft wherever it travels. ATCs and AOCs will accompanies the aircraft wherever it travels. ATCs and AOCs will
likewise receive MNPs, but they would typically appear in static (not likewise receive MNPs, but they would typically appear in static (not
mobile) deployments such as air traffic control towers, airline mobile) deployments such as air traffic control towers, airline
headquarters, etc. headquarters, etc. (Note that while IPv6 GUAs are assumed for ATN/
IPS, IPv4 with public/private address could also be used.)
The OAL uses ULAs in the source and destination addresses of IPv6 The adaptation layer uses ULAs in the source and destination
encapsulation headers. Each ULA includes an MNP in the interface addresses of adaptation layer IPv6 encapsulation headers. Each ULA
identifier ("MNP-ULA") as discussed in [I-D.templin-6man-omni]. Due includes an MNP in the interface identifier ("MNP-ULA"), as discussed
to MNP delegation policies and random MN mobility properties, MNP- in [I-D.templin-6man-omni]. Due to MNP delegation policies and
ULAs are generally not aggregatable in the BGP routing service and random node mobility properties, MNP-ULAs are generally not
are represented as many more-specific prefixes instead of a smaller aggregatable in the BGP routing service and are represented as many
number of aggregated prefixes. In addition, OMNI link service nodes more-specific prefixes instead of a smaller number of aggregated
configure administratively-assigned ULAs ("ADM-ULA") that are prefixes.
statically-assigned and derived from a shorter ADM-ULA prefix
assigned to their OMNI link partition [I-D.templin-6man-omni]. In addition, BGP routing service infrastructure nodes configure
Unlike MNP-ULAs, the ADM-ULAs are persistently present and unchanging administratively-assigned ULAs ("ADM-ULA") that are statically-
in the routing system. The BGP routing services therefore perform assigned and derived from a shorter ADM-ULA prefix assigned to their
forwarding based on these MNP-ULAs and ADM-ULAs instead of based on BGP network partitions. Unlike MNP-ULAs, the ADM-ULAs are
the GUA MNPs themselves. persistently present and unchanging in the routing system. The BGP
routing services therefore perform forwarding based on these MNP-ULAs
and ADM-ULAs instead of based on the GUA MNPs themselves. Both ADM-
ULAs and MNP-ULAs are used by the OAL for nested encapsulation where
the inner IPv6 packet is encapsulated in an IPv6 adaptation layer
header with ULA source and destination addresses, which is then
encapsulated in an IP header specific to the underlying Internetwork
that will carry the actual packet transmission.
Connexion By Boeing [CBB] was an early aviation mobile routing Connexion By Boeing [CBB] was an early aviation mobile routing
service based on dynamic updates in the global public Internet BGP service based on dynamic updates in the global public Internet BGP
routing system. Practical experience with the approach has shown routing system. Practical experience with the approach has shown
that frequent injections and withdrawals of prefixes in the Internet that frequent injections and withdrawals of prefixes in the Internet
routing system can result in excessive BGP update messaging, slow routing system can result in excessive BGP update messaging, slow
routing table convergence times, and extended outages when no route routing table convergence times, and extended outages when no route
is available. This is due to both conservative default BGP protocol is available. This is due to both conservative default BGP protocol
timing parameters (see Section 6) and the complex peering timing parameters (see Section 6) and the complex peering
interconnections of BGP routers within the global Internet interconnections of BGP routers within the global Internet
skipping to change at page 4, line 44 skipping to change at page 5, line 5
propagated to all BGP routers in the Internet that carry a full propagated to all BGP routers in the Internet that carry a full
routing table. routing table.
We therefore consider an approach using a BGP overlay network routing We therefore consider an approach using a BGP overlay network routing
system where a private BGP routing protocol instance is maintained system where a private BGP routing protocol instance is maintained
between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The
private BGP instance does not interact with the native BGP routing private BGP instance does not interact with the native BGP routing
systems in underlying INETs, and BGP updates are unidirectional from systems in underlying INETs, and BGP updates are unidirectional from
"stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a
hub-and-spokes topology. No extensions to the BGP protocol are hub-and-spokes topology. No extensions to the BGP protocol are
necessary. BGP routing is based on the ULAs found in OAL headers, necessary, and BGP routing is based on (intermediate-layer) ULAs
i.e., it provides an adaptation layer forwarding service instead of a instead of upper- or lower-layer public/private IP prefixes. This
networking layer routing service. allows ASBRs to perform adaptation layer forwarding based on
intermediate layer IPv6 header information instead of network layer
forwarding based on upper layer IP header information or link layer
forwarding based on lower layer IP header information.
The s-ASBRs for each stub AS connect to a small number of c-ASBRs via The s-ASBRs for each stub AS connect to a small number of c-ASBRs via
dedicated high speed links and/or tunnels across the INET using dedicated high speed links and/or secured tunnels (e.g., IPsec
industry-standard secured encapsulations (e.g., IPsec [RFC4301], [RFC4301], WireGuard [WG], etc.) over the underlying INET.
Wireguard, etc.). In particular, tunneling must be used when Neighboring ASBRs should use also such IP layer security
neighboring ASBRs are separated by multiple INET hops. encapsulations over direct physical links to ensure INET layer
security.
The s-ASBRs engage in external BGP (eBGP) peerings with their The s-ASBRs engage in external BGP (eBGP) peerings with their
respective c-ASBRs, and only maintain routing table entries for the respective c-ASBRs, and only maintain routing table entries for the
MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP
updates for MNP-ULA injections or withdrawals to c-ASBRs but do not updates for MNP-ULA injections or withdrawals to c-ASBRs but do not
receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain
default routes with their c-ASBRs as the next hop, and therefore hold default routes with their c-ASBRs as the next hop, and therefore hold
only partial topology information. only partial topology information.
The c-ASBRs connect to other c-ASBRs within the same partition using The c-ASBRs connect to other c-ASBRs within the same partition using
skipping to change at page 5, line 47 skipping to change at page 6, line 9
partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL
for nested encapsulation where the inner IPv6 packet is encapsulated for nested encapsulation where the inner IPv6 packet is encapsulated
in an IPv6 OAL header with ULA source and destination addresses, in an IPv6 OAL header with ULA source and destination addresses,
which is then encapsulated in an IP header specific to the INET which is then encapsulated in an IP header specific to the INET
partition. partition.
With these intra- and inter-INET BGP peerings in place, a forwarding With these intra- and inter-INET BGP peerings in place, a forwarding
plane spanning tree is established that properly covers the entire plane spanning tree is established that properly covers the entire
operating domain. All nodes in the network can be visited using operating domain. All nodes in the network can be visited using
strict spanning tree hops, but in many instances this may result in strict spanning tree hops, but in many instances this may result in
longer paths than are necessary. The AERO and OMNI services longer paths than are necessary. AERO [I-D.templin-6man-aero]
[I-D.templin-6man-aero][I-D.templin-6man-omni] provide mechanisms for provides an example service for discovering and utilizing (route-
discovering and utilizing (route-optimized) shortcuts that do not optimized) shortcuts that do not always follow strict spanning tree
always follow strict spanning tree paths. paths.
The remainder of this document discusses the proposed BGP-based ATN/ The remainder of this document discusses the proposed BGP-based ATN/
IPS mobile routing service. IPS mobile routing service.
2. Terminology 2. Terminology
The terms Autonomous System (AS) and Autonomous System Border Router The terms Autonomous System (AS) and Autonomous System Border Router
(ASBR) are the same as defined in [RFC4271]. (ASBR) are the same as defined in [RFC4271].
The following terms are defined for the purposes of this document: The following terms are defined for the purposes of this document:
skipping to change at page 7, line 28 skipping to change at page 7, line 32
encapsulation if necessary. Forwarding over the OMNI virtual link encapsulation if necessary. Forwarding over the OMNI virtual link
is therefore based on ULAs instead of GUAs. In this way, packets is therefore based on ULAs instead of GUAs. In this way, packets
sent from a source can be conveyed over the OMNI virtual link even sent from a source can be conveyed over the OMNI virtual link even
though there may be many underlying INET partitions in the path to though there may be many underlying INET partitions in the path to
the destination. the destination.
OMNI Adaptation Layer (OAL) OMNI Adaptation Layer (OAL)
A middle layer below the IPv6 layer but above the INET layer that A middle layer below the IPv6 layer but above the INET layer that
applies IPv6-in-IPv6 encapsulation prior to INET encapsulation. applies IPv6-in-IPv6 encapsulation prior to INET encapsulation.
The IPv6 encapsulation header inserted by the OAL uses ULAs The IPv6 encapsulation header inserted by the OAL uses ULAs
instead of GUAs. Further details on OMNI and the OAL are found in instead of GUAs. End systems that configure OMNI interfaces act
[I-D.templin-6man-omni]. as OAL ingress and egress points, while intermediate systems with
OMNI interfaces act as OAL forwarding nodes. There may be zero,
one or many intermediate nodes between the OAL ingress and egress,
but the upper layer IPv6 Hop Limit is not decremented during (OAL
layer) forwarding. Further details on OMNI and the OAL are found
in [I-D.templin-6man-omni].
OAL Autonomous System OAL Autonomous System (OAL AS)
A "hub-of-hubs" autonomous system maintained through peerings A "hub-of-hubs" autonomous system maintained through peerings
between the core autonomous systems of different OMNI virtual link between the core autonomous systems of different OMNI virtual link
partitions. partitions.
Core Autonomous System Border Router (c-ASBR) Core Autonomous System Border Router (c-ASBR)
A BGP router located in the hub of the INET partition hub-and- A BGP router located in the hub of the INET partition hub-and-
spokes overlay network topology. spokes overlay network topology.
Core Autonomous System Core Autonomous System (Core AS)
The "hub" autonomous system maintained by all c-ASBRs within the The "hub" autonomous system maintained by all c-ASBRs within the
same partition. same partition.
Stub Autonomous System Border Router (s-ASBR) Stub Autonomous System Border Router (s-ASBR)
A BGP router configured as a spoke in the INET partition hub-and- A BGP router configured as a spoke in the INET partition hub-and-
spokes overlay network topology. spokes overlay network topology.
Stub Autonomous System Stub Autonomous System (Stub AS)
A logical grouping that includes all Clients currently associated A logical grouping that includes all Clients currently associated
with a given s-ASBR. with a given s-ASBR.
Client Client
An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf
node. The Client could be a singleton host, or a router that node. The Client could be a singleton host, or a router that
connects a mobile or fixed network. connects a mobile or fixed network.
Proxy/Server Proxy/Server
An ANET/INET border node that acts as a transparent intermediary An ANET/INET border node that acts as a transparent intermediary
skipping to change at page 8, line 32 skipping to change at page 8, line 40
Mobility Service Prefix (MSP) Mobility Service Prefix (MSP)
An aggregated prefix assigned to the ATN/IPS by an Internet An aggregated prefix assigned to the ATN/IPS by an Internet
assigned numbers authority, and from which all MNPs are delegated assigned numbers authority, and from which all MNPs are delegated
(e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24
MSP). MSP).
3. ATN/IPS Routing System 3. ATN/IPS Routing System
The ATN/IPS routing system comprises a private BGP instance The ATN/IPS routing system comprises a private BGP instance
coordinated in an overlay network via tunnels between neighboring coordinated in an overlay network via tunnels between neighboring
ASBRs over one or more underlying INETs. The overlay does not ASBRs over one or more underlying INETs. The ATN/IPS routing system
interact with the underlying INET BGP routing systems, and only a interacts with underlying INET BGP routing systems only through the
small and unchanging set of MSPs are advertised externally instead of static advertisement of a small and unchanging set of MSPs instead of
the full dynamically changing set of MNPs. the full dynamically changing set of MNPs.
Within each INET partition, each s-ASBRs connects a stub AS to the Within each INET partition, each s-ASBR connects a stub AS to the
INET partition core using a distinct stub AS Number (ASN). Each INET partition core using a distinct stub AS Number (ASN). Each
s-ASBR further uses eBGP to peer with one or more c-ASBRs. All s-ASBR further uses eBGP to peer with one or more c-ASBRs. All
c-ASBRs are members of the INET partition core AS, and use a shared c-ASBRs are members of the INET partition core AS, and use a shared
core ASN. Unique ASNs are assigned according to the standard 32-bit core ASN. Unique ASNs are assigned according to the standard 32-bit
ASN format [RFC4271][RFC6793]. Since the BGP instance does not ASN format [RFC4271][RFC6793]. Since the BGP instance does not
connect with any INET BGP routing systems, the ASNs assigned need not connect with any INET BGP routing systems, the ASNs can be assigned
be coordinated with IANA and can in fact coincide with values that from the [RFC6996] 32-bit ASN space which reserves 94,967,295 numbers
are assigned in other domains. The only requirement is that ASNs for private use. The ASNs must be allocated and managed by an ATN/
must not be duplicated within the ATN/IPS routing system itself. IPS assigned numbers authority established by ICAO, which must ensure
that ASNs are responsibly distributed without duplication and/or
overlap.
The c-ASBRs use iBGP to maintain a synchronized consistent view of The c-ASBRs use iBGP to maintain a synchronized consistent view of
all active MNP-ULAs currently in service within the INET partition. all active MNP-ULAs currently in service within the INET partition.
Figure 1 below represents the reference INET partition deployment. Figure 1 below represents the reference INET partition deployment.
(Note that the figure shows details for only two s-ASBRs (s-ASBR1 and (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and
s-ASBR2) due to space constraints, but the other s-ASBRs should be s-ASBR2) due to space constraints, but the other s-ASBRs should be
understood to have similar Stub AS, MNP and eBGP peering understood to have similar Stub AS, MNP and eBGP peering
arrangements.) The solution described in this document is flexible arrangements.) The solution described in this document is flexible
enough to extend to these topologies. enough to extend to these topologies.
skipping to change at page 10, line 7 skipping to change at page 10, line 9
. +-------+ +-------+ . . +-------+ +-------+ .
. . . .
. . . .
. <----------------- INET Partition -------------------> . . <----------------- INET Partition -------------------> .
............................................................ ............................................................
Figure 1: INET Partition Reference Deployment Figure 1: INET Partition Reference Deployment
In the reference deployment, each s-ASBR maintains routes for active In the reference deployment, each s-ASBR maintains routes for active
MNP-ULAs that currently belong to its stub AS. In response to MNP-ULAs that currently belong to its stub AS. In response to
"Inter-domain" mobility events, each s-ASBR will dynamically "Inter-domain" mobility events, each s-ASBR dynamically announces new
announces new MNP-ULAs and withdraws departed MNP-ULAs in its eBGP MNP-ULAs and withdraws departed MNP-ULAs in its eBGP updates to
updates to c-ASBRs. Since ATN/IPS end systems are expected to remain c-ASBRs. Since ATN/IPS end systems are expected to remain within the
within the same stub AS for extended timeframes, however, intra- same stub AS for extended timeframes, however, intra-domain mobility
domain mobility events (such as an aircraft handing off between cell events (such as an aircraft handing off between cell towers) are
towers) are handled within the stub AS instead of being propagated as handled within the stub AS instead of being propagated as inter-
inter-domain eBGP updates. domain eBGP updates.
Each c-ASBR configures a black-hole route for each of its MSPs. By Each c-ASBR configures a black-hole route for each of its MSPs. By
black-holing the MSPs, the c-ASBR will maintain forwarding table black-holing the MSPs, the c-ASBR maintains forwarding table entries
entries only for the MNP-ULAs that are currently active, and packets only for the MNP-ULAs that are currently active. If an arriving
destined to all other MNP-ULAs will correctly incur ICMPv6 packet matches a black-hole route without matching an MNP-ULA, the
Destination Unreachable messages [RFC4443] due to the black hole c-ASBR should drop the packet and generate an ICMPv6 Destination
route. (This is the same behavior as for ordinary BGP routers in the Unreachable message [RFC4443], i.e., without forwarding the packet
Internet when they receive packets for which there is no route outside of the ATN/IPS overlay based on a less-specific route.
available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to
s-ASBRs, but instead originate a default route. In this way, s-ASBRs The c-ASBRs do not send BGP updates for MNP-ULAs to s-ASBRs, but
have only partial topology knowledge (i.e., they know only about the instead originate a default route. In this way, s-ASBRs have only
active MNP-ULAs currently within their stub ASes) and they forward partial topology knowledge (i.e., they know only about the active
all other packets to c-ASBRs which have full topology knowledge. MNP-ULAs currently within their stub ASes) and they forward all other
packets to c-ASBRs which have full topology knowledge.
Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable
within an INET partition, and each partition configures a unique ADM- within an INET partition, and each partition configures a unique ADM-
ULA prefix that is permanently announced into the routing system. ULA prefix that is permanently announced into the routing system.
The core ASes of each INET partition are joined together through The core ASes of each INET partition are joined together through
external BGP peerings. The c-ASBRs of each partition establish external BGP peerings. The c-ASBRs of each partition establish
external peerings with the c-ASBRs of other partitions to form a external peerings with the c-ASBRs of other partitions to form a
"core-of-cores" OMNI link AS. The OMNI link AS contains the global "core-of-cores" OMNI link AS. The OMNI link AS contains the global
knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS
overlay communications between nodes located in different INET overlay communications between nodes located in different INET
skipping to change at page 13, line 37 skipping to change at page 13, line 37
. (::::: BGP Routing ::::) . . (::::: BGP Routing ::::) .
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 3: ATN/IPS ANET Architecture Figure 3: ATN/IPS ANET Architecture
When a Client logs into an ANET it specifies a nearby s-ASBR that it When a Client connects to an ANET it specifies a nearby s-ASBR that
has selected to connect to the ATN/IPS. The login process is it has selected to connect to the ATN/IPS. The login process is
transparently brokered by a Proxy/Server at the border of the ANET transparently brokered by a Proxy/Server at the border of the ANET
which then conveys the connection request to the s-ASBR via tunneling which then conveys the connection request to the s-ASBR via tunneling
across the OMNI virtual link. Each ANET border Proxy/Server is also across the OMNI virtual link. Each ANET border Proxy/Server is also
equally capable of serving in the s-ASBR role so that a first on-link equally capable of serving in the s-ASBR role so that a first on-link
Proxy/Server can be selected as the s-ASBR while all others perform Proxy/Server can be selected as the s-ASBR while all others perform
the Proxy/Server role in a hub-and-spokes arrangement. An on-link the Proxy/Server role in a hub-and-spokes arrangement. An on-link
Proxy/Server is selected to serve the s-ASBR role when it receives a Proxy/Server is selected to serve the s-ASBR role when it receives a
control message from a Client requesting that service. control message from a Client requesting that service.
The Client can coordinate with a network-based s-ASBR over additional The Client can coordinate with a network-based s-ASBR over additional
ANETs after it has already coordinated with a first-hop Proxy/Server ANETs after it has already coordinated with a first-hop Proxy/Server
over a first ANET. Selection of a network-based s-ASBR could be over a first ANET. If the Client connects to multiple ANETs, the
through an address discovered through a first ANET Proxy/Server, s-ASBR will register the individual ANET Proxy/Servers as conduits
through consulting a geographically-keyed static host file, through a through which the Client can be reached. The Client then sees the
DNS lookup, through a network query response, etc. The s-ASBR then s-ASBR as the "hub" in a "hub-and-spokes" arrangement with the first-
registers the addresses of the additional ANET Proxy/Server as the hop Proxy/Servers as spokes. Selection of a network-based s-ASBR is
address for the Client over each distinct Client interface. If the through the discovery methods specified in relevant mobility and
Client connects to multiple ANETs, the s-ASBR will register the virtual link coordination specifications (e.g., see AERO
addresses of all Proxy/Servers as addresses through which the Client [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni]).
can be reached.
The s-ASBR represents all of its active Clients as MNP-ULA routes in The s-ASBR represents all of its active Clients as MNP-ULA routes in
the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore the ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore
consists of the set of all of its active Clients (i.e., the stub AS used only to advertise the set of MNPs of all its active Clients to
is a logical construct and not a physical construct). The s-ASBR its BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the
stub AS is a logical construct and not a physical one). The s-ASBR
injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs
of its departed Clients via BGP updates to c-ASBRs, which further of its departed Clients via BGP updates to c-ASBRs, which further
propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since
Clients are expected to remain associated with their current s-ASBR Clients are expected to remain associated with their current s-ASBR
for extended periods, the level of MNP-ULA injections and withdrawals for extended periods, the level of MNP-ULA injections and withdrawals
in the BGP routing system will be on the order of the numbers of in the BGP routing system will be on the order of the numbers of
network joins, leaves and s-ASBR handovers for aircraft operations network joins, leaves and s-ASBR handovers for aircraft operations
(see: Section 6). It is important to observe that fine-grained (see: Section 6). It is important to observe that fine-grained
events such as Client mobility and Quality of Service (QoS) signaling events such as Client mobility and Quality of Service (QoS) signaling
are coordinated only by Proxies and the Client's current s-ASBRs, and are coordinated only by Proxies and the Client's current s-ASBRs, and
do not involve other ASBRs in the routing system. In this way, do not involve other ASBRs in the routing system. In this way,
intradomain routing changes within the stub AS are not propagated intradomain routing changes within the stub AS are not propagated
into the rest of the ATN/IPS BGP routing system. into the rest of the ATN/IPS BGP routing system.
5. ATN/IPS Route Optimization 5. ATN/IPS Route Optimization
ATN/IPS end systems will frequently need to communicate with ATN/IPS end systems will frequently need to communicate with
correspondents associated with other s-ASBRs. In the BGP peering correspondents associated with other s-ASBRs. In the BGP peering
topology discussed in Section 3, this can initially only be topology discussed in Section 3, this can initially only be
accommodated by including multiple spanning tree segments in the accommodated by including multiple extraneous hops and/or spanning
forwarding path. In many cases, it would be desirable to eliminate tree segments in the forwarding path. In many cases, it would be
extraneous spanning tree segments from this "dogleg" route so that desirable to establish a "short cut" around this "dogleg" route so
packets can traverse a minimum number of tunneling hops across the that packets can traverse a minimum number of tunneling hops across
OMNI virtual link. ATN/IPS end systems could therefore employ a the OMNI virtual link. ATN/IPS end systems could therefore employ a
route optimization service according to the mobility service employed route optimization service according to the mobility service employed
(see: Section 7). (see: Section 7).
Each s-ASBR provides designated routing services for only a subset of
all active Clients, and instead acts as a simple Proxy/Server for
other Clients. As a designated router, the s-ASBR advertises the
MNPs of each of its active Clients into the ATN/IPS routing system
and provides basic (unoptimized) forwarding services when necessary.
An s-ASBR could be the first-hop ATN/IPS service access point for
some, all or none of a Client's underlying interfaces, while the
Client's other underlying interfaces employ the Proxy/Server function
of other s-ASBRs. Route optimization allows Client-to-Client
communications while bypassing s-ASBR designated routing services
whenever possible.
A route optimization example is shown in Figure 4 and Figure 5 below. A route optimization example is shown in Figure 4 and Figure 5 below.
In the first figure, multiple spanning tree segments between Proxys In the first figure, multiple spanning tree segments between Proxy/
and ASBRs are necessary to convey packets between Clients associated Servers and ASBRs are necessary to convey packets between Clients
with different s-ASBRs. In the second figure, the optimized route associated with different s-ASBRs. In the second figure, the
tunnels packets directly between Proxys without involving the ASBRs. optimized route tunnels packets directly between Proxy/Servers
without involving the ASBRs.
These route optimized paths are established through secured control
plane messaging (i.e., over secured tunnels and/or using higher-layer
control message authentications) but do not provide lower-layer
security for the data plane. Data communications over these route
optimized paths should therefore employ higher-layer security.
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
skipping to change at page 17, line 41 skipping to change at page 18, line 41
changes, BGP peer failures, and administrative state changes. BFD is changes, BGP peer failures, and administrative state changes. BFD is
important in environments where rapid response to failures is important in environments where rapid response to failures is
required for routing reconvergence and, hence, communications required for routing reconvergence and, hence, communications
continuity. continuity.
Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with
the ATN/IPS unicast IPv6 routes resolving over INET routes. the ATN/IPS unicast IPv6 routes resolving over INET routes.
Consequently, c-ASBRs and potentially s-ASBRs will need to support Consequently, c-ASBRs and potentially s-ASBRs will need to support
separate local ASes for the two BGP routing domains and routing separate local ASes for the two BGP routing domains and routing
policy or assure routes are not propagated between the two BGP policy or assure routes are not propagated between the two BGP
routing domains. From a conceptual and operational standpoint, the routing domains. From a conceptual, operational and correctness
implementation should provide isolation between the two BGP routing standpoint, the implementation should provide isolation between the
domains (e.g., separate BGP instances). two BGP routing domains (e.g., separate BGP instances).
ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random
40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit
OMNI link identifier '*' to form the prefix [ULA*]::/64. Each OMNI link identifier '*' to form the prefix [ULA*]::/64. Each
individual address taken from [ULA*]::/64 includes additional routing individual address taken from [ULA*]::/64 includes additional routing
information in the interface identifier. For example, for the MNP information in the interface identifier. For example, for the MNP
2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120,
and for the administrative address 1001:2002/16 the ADM-ULA is and for the administrative address 1001:2002/16 the ADM-ULA is
[ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further
details). This gives rise to a BGP routing system that must details). This gives rise to a BGP routing system that must
skipping to change at page 18, line 17 skipping to change at page 19, line 17
ADM-ULA prefixes. The system is kept stable and scalable through the ADM-ULA prefixes. The system is kept stable and scalable through the
s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility-
related churn is not exposed to the core. related churn is not exposed to the core.
7. Stub AS Mobile Routing Services 7. Stub AS Mobile Routing Services
Stub ASes maintain intradomain routing information for mobile node Stub ASes maintain intradomain routing information for mobile node
clients, and are responsible for all localized mobility signaling clients, and are responsible for all localized mobility signaling
without disturbing the BGP routing system. Clients can enlist the without disturbing the BGP routing system. Clients can enlist the
services of a candidate mobility service such as Mobile IPv6 (MIPv6) services of a candidate mobility service such as Mobile IPv6 (MIPv6)
[RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] or AERO
[I-D.templin-6man-aero] according to the service offered by the stub [I-D.templin-6man-aero] according to the service offered by the stub
AS. Further details of mobile routing services are out of scope for AS. Further details of mobile routing services are out of scope for
this document. this document.
8. Implementation Status 8. Implementation Status
The BGP routing topology described in this document has been modeled The BGP routing topology described in this document has been modeled
in realistic network emulations showing that at least 1 million MNP- in realistic network emulations showing that at least 1 million MNP-
ULAs can be propagated to each c-ASBR even on lightweight virtual ULAs can be propagated to each c-ASBR even on lightweight virtual
machines. No BGP routing protocol extensions need to be adopted. machines. No BGP routing protocol extensions need to be adopted.
9. IANA Considerations 9. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
10. Security Considerations 10. Security Considerations
ATN/IPS ASBRs on the open Internet are susceptible to the same attack ATN/IPS ASBRs on the open Internet are susceptible to the same attack
profiles as for any Internet nodes. For this reason, ASBRs should profiles as for any Internet nodes. For this reason, ASBRs should
employ physical security and/or IP securing mechanisms such as IPsec employ physical security and/or IP securing mechanisms such as IPsec
[RFC4301], TLS [RFC5246], WireGuard, etc. [RFC4301], WireGuard [WG], etc.
ATN/IPS ASBRs present targets for Distributed Denial of Service ATN/IPS ASBRs present targets for Distributed Denial of Service
(DDoS) attacks. This concern is no different than for any node on (DDoS) attacks. This concern is no different than for any node on
the open Internet, where attackers could send spoofed packets to the the open Internet, where attackers could send spoofed packets to the
node at high data rates. This can be mitigated by connecting ATN/IPS node at high data rates. This can be mitigated by connecting ATN/IPS
ASBRs over dedicated links with no connections to the Internet and/or ASBRs over dedicated links with no connections to the Internet and/or
when ASBR connections to the Internet are only permitted through when ASBR connections to the Internet are only permitted through
well-managed firewalls. well-managed firewalls.
ATN/IPS s-ASBRs should institute rate limits to protect low data rate ATN/IPS s-ASBRs should institute rate limits to protect low data rate
aviation data links from receiving DDoS packet floods. aviation data links from receiving DDoS packet floods.
BGP protocol message exchanges and control message exchanges used for BGP protocol message exchanges and control message exchanges used for
route optimization must be secured to ensure the integrity of the route optimization must be secured to ensure the integrity of the
system-wide routing information base. system-wide routing information base. Security is based on IP layer
security associations between peers which ensure confidentiality,
integrity and authentication over secured tunnels (see above).
Higher layer security protection such as TCP-AO [RFC5926] is
therefore optional, since it would be redundant with the security
provided at lower layers.
Data communications over route optimized paths should employ end-to-
end higher-layer security since only the control plane and
unoptimized paths are protected by lower-layer security. End-to-end
higher-layer security mechanisms include QUIC-TLS [RFC9001], TLS
[RFC8446], DTLS [RFC6347], SSH [RFC4251], etc. applied in a manner
outside the scope of this document.
This document does not include any new specific requirements for This document does not include any new specific requirements for
mitigation of DDoS. mitigation of DDoS.
10.1. Public Key Infrastructure (PKI) Considerations
In development of the overall ATN/IPS operational concept, ICAO
addressed the security concerns in multiple ways to ensure
coordination and consistency across the various groups. This also
avoided potential duplicative work. Technical provisions related
specifically to the operation of ATN/IPS are specified in supporting
ATN/IPS standards. However, other considerations such as the
establishment of a PKI, were determined to have an impact beyond ATN/
IPS. ICAO created a Trust Framework Study Group (TFSG) to define
various governance, policy, procedures and overall technical
performance requirements for system connectivity and
interoperability.
As part of their charter, the TSFG is specifically developing a
concept of operations for a common aviation digital trust framework
and principles to facilitate an interoperable secure, cyber resilient
and seamless exchange of information in a digitally connected
environment. They are also developing governance principles, policy,
procedures and requirements for establishing digital identity for a
global trust framework that will consider any exchange of information
among users of the aviation ecosystem, and to promote these concepts
with all relevant stakeholders.
ATN/IPS will take advantage of the developments of TFSG within the
overall ATN/IPS operational concept. As such, this will include the
usage of the PKI specification resulting from the TFSG.
11. Acknowledgements 11. Acknowledgements
This work is aligned with the FAA as per the SE2025 contract number This work is aligned with the FAA as per the SE2025 contract number
DTFAWA-15-D-00030. DTFAWA-15-D-00030.
This work is aligned with the NASA Safe Autonomous Systems Operation This work is aligned with the NASA Safe Autonomous Systems Operation
(SASO) program under NASA contract number NNA16BD84C. (SASO) program under NASA contract number NNA16BD84C.
This work is aligned with the Boeing Commercial Airplanes (BCA) This work is aligned with the Boeing Commercial Airplanes (BCA)
Internet of Things (IoT) and autonomy programs. Internet of Things (IoT) and autonomy programs.
This work is aligned with the Boeing Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program. MobileNet program.
The following individuals contributed insights that have improved the The following individuals contributed insights that have improved the
document: Ahmad Amin, Erik Kline, Hubert Kuenig, Tony Li, Alexandre document: Ahmad Amin, Mach Chen, Russ Housley, Erik Kline, Hubert
Petrescu, Pascal Thubert, Tony Whyman. Kuenig, Tony Li, Gyan Mishra, Alexandre Petrescu, Dave Thaler, Pascal
Thubert, Tony Whyman.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
skipping to change at page 21, line 16 skipping to change at page 23, line 4
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, "The Locator/ID Separation Protocol (LISP)", Cabellos, "The Locator/ID Separation Protocol (LISP)",
Work in Progress, Internet-Draft, draft-ietf-lisp- Work in Progress, Internet-Draft, draft-ietf-lisp-
rfc6830bis-36, 18 November 2020, rfc6830bis-36, 18 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-lisp- <https://www.ietf.org/archive/id/draft-ietf-lisp-
rfc6830bis-36.txt>. rfc6830bis-36.txt>.
[I-D.templin-6man-aero] [I-D.templin-6man-aero]
Templin, F. L., "Automatic Extended Route Optimization Templin, F. L., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin- (AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero-37, 15 November 2021, 6man-aero-38, 31 December 2021,
<https://www.ietf.org/archive/id/draft-templin-6man-aero- <https://www.ietf.org/archive/id/draft-templin-6man-aero-
37.txt>. 38.txt>.
[I-D.templin-6man-omni] [I-D.templin-6man-omni]
Templin, F. L. and T. Whyman, "Transmission of IP Packets Templin, F. L. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", Work in over Overlay Multilink Network (OMNI) Interfaces", Work in
Progress, Internet-Draft, draft-templin-6man-omni-51, 15 Progress, Internet-Draft, draft-templin-6man-omni-52, 31
November 2021, <https://www.ietf.org/archive/id/draft- December 2021, <https://www.ietf.org/archive/id/draft-
templin-6man-omni-51.txt>. templin-6man-omni-52.txt>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
(TLS) Protocol Version 1.2", RFC 5246, for the TCP Authentication Option (TCP-AO)", RFC 5926,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5926, June 2010,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5926>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>. <https://www.rfc-editor.org/info/rfc6793>.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
2013, <https://www.rfc-editor.org/info/rfc6996>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[WG] Donenfeld, J., "WireGuard: Fast, Modern, Secure VPN
Tunnel, https://www.wireguard.com/", February 2022.
Appendix A. BGP Convergence Considerations Appendix A. BGP Convergence Considerations
Experimental evidence has shown that BGP convergence time required Experimental evidence has shown that BGP convergence time required
for when an MNP-ULA is asserted at a new location or withdrawn from after an MNP-ULA is asserted at a new location or withdrawn from an
an old location can be several hundred milliseconds even under old location can be several hundred milliseconds even under optimal
optimal AS peering arrangements. This means that packets in flight AS peering arrangements. This means that packets in flight destined
destined to an MNP-ULA route that has recently been changed can be to an MNP-ULA route that has recently been changed can be
(mis)delivered to an old s-ASBR after a Client has moved to a new (mis)delivered to an old s-ASBR after a Client has moved to a new
s-ASBR. s-ASBR.
To address this issue, the old s-ASBR can maintain temporary state To address this issue, the old s-ASBR can maintain temporary state
for a "departed" Client that includes an OAL address for the new for a "departed" Client that includes an OAL address for the new
s-ASBR. The OAL address never changes since ASBRs are fixed s-ASBR. The OAL address never changes since ASBRs are fixed
infrastructure elements that never move. Hence, packets arriving at infrastructure elements that never move. Hence, packets arriving at
the old s-ASBR can be forwarded to the new s-ASBR while the BGP the old s-ASBR can be forwarded to the new s-ASBR while the BGP
routing system is still undergoing reconvergence. Therefore, as long routing system is still undergoing reconvergence. Therefore, as long
as the Client associates with the new s-ASBR before it departs from as the Client associates with the new s-ASBR before it departs from
 End of changes. 42 change blocks. 
127 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/