< draft-ietf-rtgwg-atn-bgp-00.txt   draft-ietf-rtgwg-atn-bgp-01.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: March 3, 2019 G. Dawra Expires: July 15, 2019 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
August 30, 2018 January 11, 2019
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-00.txt draft-ietf-rtgwg-atn-bgp-01.txt
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 IPv6-based service supporting pervasive Air Traffic
Management (ATM) for Air Traffic Controllers (ATC), Airline Management (ATM) for Air Traffic Controllers (ATC), Airline
Operations Controllers (AOC), and all commercial aircraft worldwide. Operations Controllers (AOC), and all commercial aircraft worldwide.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 March 3, 2019. This Internet-Draft will expire on July 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 6 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 6
4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9 4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 3, line 50 skipping to change at page 4, line 4
travels. ICAO is further proposing to assign each aircraft an entire travels. ICAO is further proposing to assign each aircraft an entire
/56 MNP for numbering its on-board networks. ATCs and AOCs will /56 MNP for numbering its on-board networks. ATCs and AOCs will
likewise receive IPv6 prefixes, but they would typically appear in likewise receive IPv6 prefixes, but they would typically appear in
static (not mobile) deployments such as air traffic control towers, static (not mobile) deployments such as air traffic control towers,
airline headquarters, etc. Throughout the rest of this document, we airline headquarters, etc. Throughout the rest of this document, we
therefore use the term "MNP" when discussing an IPv6 prefix that is therefore use the term "MNP" when discussing an IPv6 prefix that is
delegated to any ATN/IPS end system, including ATCs, AOCs, and delegated to any ATN/IPS end system, including ATCs, AOCs, and
aircraft. We also use the term Mobility Service Prefix (MSP) to aircraft. We also use the term Mobility Service Prefix (MSP) to
refer to an aggregated prefix assigned to the ATN/IPS by an Internet refer to 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 an IPv6 /24 (e.g., up to 2^32 IPv6 /56 MNPs could be delegated from an IPv6 /24
MSP). MSP).
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 MNPs in the Internet that frequent injections and withdrawals of MNPs 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
skipping to change at page 4, line 33 skipping to change at page 4, line 35
system in the connected Internetworking underlay, and BGP updates are system in the connected Internetworking underlay, and BGP updates are
unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core"
ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the
BGP protocol are necessary. BGP protocol are necessary.
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 Internetworking dedicated high speed links and/or tunnels across the Internetworking
underlay using industry-standard encapsulations (e.g., Generic underlay using industry-standard encapsulations (e.g., Generic
Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In
particular, tunneling must be used when neighboring ASBRs are particular, tunneling must be used when neighboring ASBRs are
separated by many Internetworking underlay hops. separated by multiple Internetworking underlay hops.
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
MNPs currently active within the stub AS. The s-ASBRs send BGP MNPs currently active within the stub AS. The s-ASBRs send BGP
updates for MNP injections or withdrawals to c-ASBRs but do not updates for MNP 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 using internal BGP (iBGP) The c-ASBRs connect to other c-ASBRs using internal BGP (iBGP)
skipping to change at page 6, line 16 skipping to change at page 6, line 22
configured as a spoke in the ATN/IPS hub-and-spokes overlay configured as a spoke in the ATN/IPS hub-and-spokes overlay
network topology. network topology.
Stub Autonomous System A logical grouping that includes all Clients Stub Autonomous System A logical grouping that includes all Clients
currently associated with a given s-ASBR. currently associated with a given s-ASBR.
Client An ATC, AOC or aircraft that connects to the ATN/IPS as a Client 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 leaf node. The Client could be a singleton host, or a router that
connects a mobile network. connects a mobile network.
Proxy A node at the edge of a RAN that acts as an intermediary Proxy A node at the edge of a RAN that acts as a transparent
between Clients and s-ASBRs. From the Client's perspective, the intermediary between Clients and s-ASBRs. From the Client's
Proxy presents the appearance that the Client is communicating perspective, the Proxy presents the appearance that the Client is
directly with the s-ASBR. From the s-ASBR's perspective, the communicating directly with the s-ASBR. From the s-ASBR's
Proxy presents the appearance that the s-ASBR is communicating perspective, the Proxy presents the appearance that the s-ASBR is
directly with the Client. communicating directly with the Client.
Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any
ATN/IPS end system, including ATCs, AOCs, and aircraft. ATN/IPS end system, including ATCs, AOCs, and aircraft.
Mobility Service Prefix (MSP) An aggregated prefix assigned to the Mobility Service Prefix (MSP) An aggregated prefix assigned to the
ATN/IPS by an Internet assigned numbers authority, and from which ATN/IPS by an Internet assigned numbers authority, and from which
all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be
delegated from a /24 MSP). delegated from a /24 MSP).
3. ATN/IPS Routing System 3. ATN/IPS Routing System
skipping to change at page 9, line 9 skipping to change at page 9, line 13
constitute the collective MSP(s) for the entire ATN/IPS. constitute the collective MSP(s) for the entire ATN/IPS.
In this way, each set of c-ASBRs services a specific set of MSPs that In this way, each set of c-ASBRs services a specific set of MSPs that
they inject into the Internetworking underlay native routing system, they inject into the Internetworking underlay native routing system,
and each s-ASBR configures MSP-specific routes that list the correct and each s-ASBR configures MSP-specific routes that list the correct
set of c-ASBRs as next hops. This design also allows for natural set of c-ASBRs as next hops. This design also allows for natural
incremental deployment, and can support initial medium-scale incremental deployment, and can support initial medium-scale
deployments followed by dynamic deployment of additional ATN/IPS deployments followed by dynamic deployment of additional ATN/IPS
infrastructure elements without disturbing the already-deployed base. infrastructure elements without disturbing the already-deployed base.
For example, a few more c-ASBRs could be added if the MNP service For example, a few more c-ASBRs could be added if the MNP service
demand ever outgrows the initial deployment. demand ever outgrows the initial deployment. For larger-scale
applications (such as unmanned air vehicles and terrestrial vehicles)
even larger scales can be accommodated by adding more c-ASBRs.
4. ATN/IPS Radio Access Network (RAN) Model 4. ATN/IPS Radio Access Network (RAN) Model
Radio Access Networks (RANs) connect end system Clients such as Radio Access Networks (RANs) connect end system Clients such as
aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may
connect to multiple RANs at once, for example, when they have both connect to multiple RANs at once, for example, when they have both
satellite and cellular data links activated simultaneously. Clients satellite and cellular data links activated simultaneously. Clients
may further move between RANs in a manner that is perceived as a may further move between RANs in a manner that is perceived as a
network layer mobility event. Clients could therefore employ a network layer mobility event. Clients could therefore employ a
multilink/mobility routing service such as that discussed in multilink/mobility routing service such as those discussed in
[I-D.templin-aerolink]. Section 7.
Clients register all of their active data link connections with their Clients register all of their active data link connections with their
serving s-ASBRs as discussed in Section 3. Clients may connect to serving s-ASBRs as discussed in Section 3. Clients may connect to
s-ASBRs either directly, or via a Proxy at the edge of the RAN. s-ASBRs either directly, or via a Proxy at the edge of the RAN.
Figure 2 shows the ATN/IPS RAN model where Clients connect to RANs Figure 2 shows the ATN/IPS RAN model where Clients connect to RANs
via aviation data links. Clients register their RAN addresses with a via aviation data links. Clients register their RAN addresses with a
nearby s-ASBR, where the registration process may be brokered by a nearby s-ASBR, where the registration process may be brokered by a
Proxy at the edge of the RAN. Proxy at the edge of the RAN.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------------- Internetworking Underlay -------------> . . <------------- Internetworking Underlay -------------> .
............................................................ ............................................................
Figure 2: ATN/IPS RAN Architecture Figure 2: ATN/IPS RAN Architecture
When a Client logs into a RAN, it specifies a nearby s-ASBR that it When a Client logs into a RAN, it specifies a nearby s-ASBR that it
has selected to connect to the ATN/IPS. The login process is has selected to connect to the ATN/IPS. (Selection of a nearby
s-ASBR could be through consulting a geographically-keyed static host
file, through a DNS lookup, etc.) The login process is transparently
brokered by a Proxy at the border of the RAN, which then conveys the brokered by a Proxy at the border of the RAN, which then conveys the
connection request to the s-ASBR via tunneling across the connection request to the s-ASBR via tunneling across the
Internetworking underlay. The s-ASBR then registers the address of Internetworking underlay. The s-ASBR then registers the address of
the Proxy as the address for the Client, and the Proxy forwards the the Proxy as the address for the Client, and the Proxy forwards the
s-ASBR's reply to the Client. If the Client connects to multiple s-ASBR's reply to the Client. If the Client connects to multiple
RANs, the s-ASBR will register the addresses of all Proxies as RANs, the s-ASBR will register the addresses of all Proxies as
addresses through which the Client can be reached. addresses through which the Client can be reached.
The s-ASBR represents all of its active Clients as MNP routes in the The s-ASBR represents all of its active Clients as MNP routes in the
ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists
skipping to change at page 11, line 23 skipping to change at page 11, line 25
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 tunnel segments in the forwarding accommodated by including multiple tunnel segments in the forwarding
path. In many cases, it would be desirable to eliminate extraneous path. In many cases, it would be desirable to eliminate extraneous
tunnel segments from this "dogleg" route so that packets can traverse tunnel segments from this "dogleg" route so that packets can traverse
a minimum number of tunneling hops across the Internetworking a minimum number of tunneling hops across the Internetworking
underlay. ATN/IPS end systems could therefore employ a route underlay. ATN/IPS end systems could therefore employ a route
optimization service such as that discussed in optimization service according to the mobility service employed (see:
[I-D.templin-aerolink]. Section 7).
A route optimization example is shown in Figure 3 and Figure 4 below. A route optimization example is shown in Figure 3 and Figure 4 below.
In the first figure, multiple tunneled segments between Proxys and In the first figure, multiple tunneled segments between Proxys and
ASBRs are necessary to convey packets between Clients associated with ASBRs are necessary to convey packets between Clients associated with
different s-ASBRs. In the second figure, the optimized route tunnels different s-ASBRs. In the second figure, the optimized route tunnels
packets directly between Proxys without involving the ASBRs. packets directly between Proxys without involving the ASBRs.
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
skipping to change at page 14, line 34 skipping to change at page 14, line 34
Each c-ASBR will be using eBGP both in the ATN/IPS and the Each c-ASBR will be using eBGP both in the ATN/IPS and the
Internetworking Underlay with the ATN/IPS unicast IPv6 routes Internetworking Underlay with the ATN/IPS unicast IPv6 routes
resolving over Internetworking Underlay routes. Consequently, resolving over Internetworking Underlay routes. Consequently,
c-ASBRs and potentially s-ASBRs will need to support separate local c-ASBRs and potentially s-ASBRs will need to support separate local
ASes for the two BGP routing domains and routing policy or assure ASes for the two BGP routing domains and routing policy or assure
routes are not propagated between the two BGP routing domains. From routes are not propagated between the two BGP routing domains. From
a conceptual and operational standpoint, the implementation should a conceptual and operational standpoint, the implementation should
provide isolation between the two BGP routing domains (e.g., separate provide isolation between the two BGP routing domains (e.g., separate
BGP instances). BGP instances).
7. Implementation Status 7. Stub AS Mobile Routing Services
Stub ASes maintain intradomain routing information for mobile node
clients, and are responsible for all localized mobility signaling
without disturbing the BGP routing system. Clients can enlist the
services of a candidate mobility service such as Mobile IPv6 (MIPv6)
[RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO
[I-D.templin-intarea-6706bis] according to the service offered by the
stub AS. Further details of mobile routing services are out of scope
for this document.
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 MNPs in realistic network emulations showing that at least 1 million MNPs
can be propagated to each c-ASBR even on lightweight virtual 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.
8. IANA Considerations 9. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
9. 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], etc. [RFC4301], TLS [RFC5246], 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.
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. 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 Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program. MobileNet program.
11. References The following individuals contributed insights that have improved the
document: Erik Kline, Tony Li, Alexandre Petrescu, Pascal Thubert.
11.1. Normative References 12. References
12.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
skipping to change at page 16, line 10 skipping to change at page 16, line 21
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References 12.2. Informative References
[BGP] Huston, G., "BGP in 2015, http://potaroo.net", January [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January
2016. 2016.
[BGP2] Huston, G., "BGP Instability Report, [BGP2] Huston, G., "BGP Instability Report,
http://bgpupdates.potaroo.net/instability/bgpupd.html", http://bgpupdates.potaroo.net/instability/bgpupd.html",
May 2017. May 2017.
[CBB] Dul, A., "Global IP Network Mobility using Border Gateway [CBB] Dul, A., "Global IP Network Mobility using Border Gateway
Protocol (BGP), http://www.quark.net/docs/ Protocol (BGP), http://www.quark.net/docs/
Global_IP_Network_Mobility_using_BGP.pdf", March 2006. Global_IP_Network_Mobility_using_BGP.pdf", March 2006.
[I-D.templin-aerolink] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress),
November 2018.
[I-D.templin-intarea-6706bis]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-aerolink-82 (work in progress), May (AERO)", draft-templin-intarea-6706bis-03 (work in
2018. progress), December 2018.
[ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx",
February 2017. February 2017.
[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>.
[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 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[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>.
Appendix A. Change Log Appendix A. Change Log
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from -00 to -01:
o incorporated clarifications due to list comments and questions.
o new section 7 on Stub AS Mobile Routing Services
o updated references, and included new reference for MIPv6 and LISP
Status as of 08/30/2018: Status as of 08/30/2018:
o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp'
Authors' Addresses Authors' Addresses
Fred L. Templin (editor) Fred L. Templin (editor)
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
 End of changes. 24 change blocks. 
36 lines changed or deleted 73 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/