< draft-templin-intarea-6706bis-10.txt   draft-templin-intarea-6706bis-11.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology Internet-Draft Boeing Research & Technology
Obsoletes: rfc5320, rfc5558, rfc5720, March 25, 2019 Obsoletes: rfc5320, rfc5558, rfc5720, April 4, 2019
rfc6179, rfc6706 (if rfc6179, rfc6706 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 26, 2019 Expires: October 6, 2019
Asymmetric Extended Route Optimization (AERO) Asymmetric Extended Route Optimization (AERO)
draft-templin-intarea-6706bis-10.txt draft-templin-intarea-6706bis-11.txt
Abstract Abstract
This document specifies the operation of IP over tunnel virtual links This document specifies the operation of IP over tunnel virtual links
using Asymmetric Extended Route Optimization (AERO). Nodes attached using Asymmetric Extended Route Optimization (AERO). Nodes attached
to AERO links can exchange packets via trusted intermediate routers to AERO links can exchange packets via trusted intermediate routers
that provide forwarding services to reach off-link destinations and that provide forwarding services to reach off-link destinations and
route optimization services for improved performance. AERO provides route optimization services for improved performance. AERO provides
an IPv6 link-local address format that supports operation of the IPv6 an IPv6 link-local address format that supports operation of the IPv6
Neighbor Discovery (ND) protocol and links ND to IP forwarding. Neighbor Discovery (ND) protocol and links ND to IP forwarding.
Prefix delegation services are employed to manage the routing system.
Dynamic link selection, mobility management, quality of service (QoS) Dynamic link selection, mobility management, quality of service (QoS)
signaling and route optimization are naturally supported through signaling and route optimization are naturally supported through
dynamic neighbor cache updates, while IPv6 Prefix Delegation (PD) is dynamic neighbor cache updates. AERO is a widely-applicable
supported by network services such as the Dynamic Host Configuration tunneling solution especially well-suited to aviation services,
Protocol for IPv6 (DHCPv6). AERO is a widely-applicable tunneling mobile Virtual Private Networks (VPNs) and other applications as
solution especially well-suited to aviation services, mobile Virtual described in this document.
Private Networks (VPNs) and other applications as described in this
document.
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 September 26, 2019. This Internet-Draft will expire on October 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 7 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 8
3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 8 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 8
3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 10
3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 11
3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 12 3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 13
3.5. AERO Interface Characteristics . . . . . . . . . . . . . 14 3.5. Spanning Partitioned AERO Networks (SPAN) . . . . . . . . 15
3.6. AERO Interface Initialization . . . . . . . . . . . . . . 18 3.6. AERO Interface Characteristics . . . . . . . . . . . . . 17
3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 18 3.7. AERO Interface Initialization . . . . . . . . . . . . . . 21
3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 18 3.7.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 21
3.6.3. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 19 3.7.2. AERO Server Behavior . . . . . . . . . . . . . . . . 21
3.6.4. AERO Client Behavior . . . . . . . . . . . . . . . . 19 3.7.3. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 22
3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 20 3.7.4. AERO Client Behavior . . . . . . . . . . . . . . . . 22
3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 22 3.8. AERO Interface Neighbor Cache Maintenance . . . . . . . . 23
3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 22 3.9. AERO Interface Forwarding Algorithm . . . . . . . . . . . 25
3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 23 3.9.1. Client Forwarding Algorithm . . . . . . . . . . . . . 26
3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 23 3.9.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 26
3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 24 3.9.3. Server Forwarding Algorithm . . . . . . . . . . . . . 27
3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 25 3.9.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 27
3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 26 3.10. AERO Interface Encapsulation and Re-encapsulation . . . . 28
3.11. AERO Interface Data Origin Authentication . . . . . . . . 26 3.11. AERO Interface Decapsulation . . . . . . . . . . . . . . 29
3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 27 3.12. AERO Interface Data Origin Authentication . . . . . . . . 29
3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 29 3.13. AERO Interface Packet Size Issues . . . . . . . . . . . . 30
3.14. AERO Router Discovery, Prefix Delegation and 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 32
Autoconfiguration . . . . . . . . . . . . . . . . . . . . 32 3.15. AERO Router Discovery, Prefix Delegation and
3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 32 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 35
3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 33 3.15.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 35
3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 35 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 36
3.15. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . 37 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 38
3.15.1. The AERO-Aware Access Router . . . . . . . . . . . . 39 3.16. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . 40
3.16.1. The AERO-Aware Access Router . . . . . . . . . . . . 42
3.16. AERO Route Optimization . . . . . . . . . . . . . . . . . 39 3.17. AERO Route Optimization . . . . . . . . . . . . . . . . . 43
3.17. Neighbor Unreachability Detection (NUD) . . . . . . . . . 42 3.17.1. Route Optimization Initiation . . . . . . . . . . . 43
3.18. Mobility Management and Quality of Service (QoS) . . . . 43 3.17.2. Relaying the NS . . . . . . . . . . . . . . . . . . 43
3.18.1. Mobility Update Messaging . . . . . . . . . . . . . 43 3.17.3. Processing the NS and Sending the NA . . . . . . . . 44
3.18.2. Forwarding Packets on Behalf of Departed Clients . . 44 3.17.4. Relaying the NA . . . . . . . . . . . . . . . . . . 44
3.18.3. Announcing Link-Layer Address and/or QoS Preference 3.17.5. Processing the NA . . . . . . . . . . . . . . . . . 44
Changes . . . . . . . . . . . . . . . . . . . . . . 45 3.17.6. Route Optimization Maintenance . . . . . . . . . . . 45
3.18.4. Bringing New Links Into Service . . . . . . . . . . 45 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 46
3.18.5. Removing Existing Links from Service . . . . . . . . 46 3.19. Mobility Management and Quality of Service (QoS) . . . . 46
3.18.6. Implicit Mobility Management . . . . . . . . . . . . 46 3.19.1. Mobility Update Messaging . . . . . . . . . . . . . 47
3.18.7. Moving to a New Server . . . . . . . . . . . . . . . 46 3.19.2. Forwarding Packets on Behalf of Departed Clients . . 48
3.19. Multicast Considerations . . . . . . . . . . . . . . . . 47 3.19.3. Announcing Link-Layer Address and/or QoS Preference
4. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 47 Changes . . . . . . . . . . . . . . . . . . . . . . 48
5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 48 3.19.4. Bringing New Links Into Service . . . . . . . . . . 49
6. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 48 3.19.5. Removing Existing Links from Service . . . . . . . . 49
7. AERO Critical Infrastructure Considerations . . . . . . . . . 49 3.19.6. Implicit Mobility Management . . . . . . . . . . . . 49
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 3.19.7. Moving to a New Server . . . . . . . . . . . . . . . 50
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 3.20. Multicast Considerations . . . . . . . . . . . . . . . . 50
10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 4. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 7. AERO Critical Infrastructure Considerations . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 55 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 53
Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 54
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 64 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 63
Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 65
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
This document specifies the operation of IP over tunnel virtual links This document specifies the operation of IP over tunnel virtual links
using Asymmetric Extended Route Optimization (AERO). The AERO link using Asymmetric Extended Route Optimization (AERO). The AERO link
can be used for tunneling between neighboring nodes over either IPv6 can be used for tunneling between neighboring nodes over either IPv6
or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as
equivalent links for tunneling. Nodes attached to AERO links can equivalent links for tunneling. Nodes attached to AERO links can
exchange packets via trusted intermediate routers that provide exchange packets via trusted intermediate routers that provide
forwarding services to reach off-link destinations and route forwarding services to reach off-link destinations and route
skipping to change at page 5, line 36 skipping to change at page 5, line 43
Server on a different AERO interface. Server on a different AERO interface.
AERO Server ("Server") AERO Server ("Server")
a node that configures an AERO interface to provide default a node that configures an AERO interface to provide default
forwarding services and a Mobility Anchor Point (MAP) for AERO forwarding services and a Mobility Anchor Point (MAP) for AERO
Clients. The Server assigns an administratively-provisioned AERO Clients. The Server assigns an administratively-provisioned AERO
address to the AERO interface to support the operation of the ND/ address to the AERO interface to support the operation of the ND/
PD services. An AERO Server can also act as an AERO Relay. PD services. An AERO Server can also act as an AERO Relay.
AERO Relay ("Relay") AERO Relay ("Relay")
an IP router that can relay IP packets between AERO Servers and/or a node that provides both layer-3 routing and layer-2 bridging
forward IP packets between the AERO link and the native services (as well as a security trust anchor) for nodes on an AERO
Internetwork. AERO Relays are standard IP routers that do not link. As a router, the Relay forwards data packets using standard
require any AERO-specific functions. IP forwarding. As a bridge, the Relay securely forwards control
messages between Proxies and Servers both within the same
partition and between disjoint partitions.
AERO Proxy ("Proxy") AERO Proxy ("Proxy")
a node that provides proxying services, e.g., when the Client is a node that provides proxying services, e.g., when the Client is
located in a secured internal enclave and the Server is located in located in a secured internal enclave and the Server is located in
the external Internetwork. The AERO Proxy is a conduit between the external Internetwork. The AERO Proxy is a conduit between
the secured enclave and the external Internetwork in the same the secured enclave and the external Internetwork in the same
manner as for common web proxies, and behaves in a similar fashion manner as for common web proxies, and behaves in a similar fashion
as for ND proxies [RFC4389]. as for ND proxies [RFC4389].
ingress tunnel endpoint (ITE) ingress tunnel endpoint (ITE)
skipping to change at page 6, line 40 skipping to change at page 6, line 48
end user network (EUN) end user network (EUN)
an internal virtual or external edge IP network that an AERO an internal virtual or external edge IP network that an AERO
Client connects to the rest of the network via the AERO interface. Client connects to the rest of the network via the AERO interface.
The Client sees each EUN as a "downstream" network and sees the The Client sees each EUN as a "downstream" network and sees the
AERO interface as its point of attachment to the "upstream" AERO interface as its point of attachment to the "upstream"
network. network.
AERO Service Prefix (ASP) AERO Service Prefix (ASP)
an IP prefix associated with the AERO link and from which more- an IP prefix associated with the AERO link and from which more-
specific AERO Client Prefixes (ACPs) are derived. specific AERO Client Prefixes (ACPs) are derived. The term ASP is
equivalent to "Mobility Service Prefix (MSP)" that appears in
other contexts.
AERO Client Prefix (ACP) AERO Client Prefix (ACP)
an IP prefix derived from an ASP and delegated to a Client, where an IP prefix derived from an ASP and delegated to a Client, where
the ACP prefix length must be no shorter than the ASP prefix the ACP prefix length must be no shorter than the ASP prefix
length. length. The term ACP is equivalent to "Mobile Network Prefix
(MNP)" that appears in other contexts.
base AERO address base AERO address
the lowest-numbered AERO address from the first ACP delegated to the lowest-numbered AERO address from the first ACP delegated to
the Client (see Section 3.4). the Client (see Section 3.4).
secured enclave secured enclave
a private access network (e.g., a corporate enterprise network, a private access network (e.g., a corporate enterprise network,
radio access network, cellular service provider network, etc.) radio access network, cellular service provider network, etc.)
with secured links and perimeters. Link-layer security services with secured links and perimeters. Link-layer security services
such as IEEE 802.1X and physical-layer security such as campus such as IEEE 802.1X and physical-layer security such as campus
wired LANs prevent unauthorized access from within the enclave, wired LANs prevent unauthorized access from within the enclave,
while border network-layer security services such as firewalls and while border network-layer security services such as firewalls and
proxies prevent unauthorized access from the external proxies prevent unauthorized access from the external
Internetwork. Internetwork.
Potential Router List (PRL)
a geographically and/or topologically referenced list of IP
addresses of Servers for the AERO link.
Mobility Anchor Point (MAP) Mobility Anchor Point (MAP)
an AERO Server that is currently tracking and reporting the an AERO Server that is currently tracking and reporting the
mobility events of its associated Clients. mobility events of its associated Clients.
MAP List
a geographically and/or topologically referenced list of IP
addresses of Servers for the AERO link.
Distributed Mobility Management (DMM) Distributed Mobility Management (DMM)
an overlay routing service coordinated by Servers and Relays that a BGP-based overlay routing service coordinated by Servers and
tracks all MAP-to-Client associations. Relays that tracks all MAP-to-Client associations.
Route Optimization Source (ROS)
the AERO node nearest the source Client that initiates route
optimization. The ROS may be one of the Client's Servers, Proxies
or in some cases even the Client itself.
Route Optimization Responder (ROR)
a Server of the target Client to which a route optimization
request is directed. The ROR (acting as a MAP) returns the most
current information about the target Client's underlying interface
connections.
Spanning Partitioned AERO Networks (SPAN)
a means for bridging disjoint segments of a partitioned AERO link,
i.e., the same as for a bridged campus LAN. The SPAN is an
underlay encapsulation service in the AERO routing system, and
provides a unified link view for all partitions.
SPAN Service Prefix (SSP)
a global or unique local /96 IPv6 prefix assigned to the AERO link
to support SPAN services.
SPAN Partition Prefix (SPP)
a sub-prefix of the SPAN Service Prefix uniquely assigned to a
single partition of the SPAN.
SPAN Address
a global or unique local IPv6 address taken from a SPAN Partition
Prefix.
Throughout the document, the simple terms "Client", "Server", "Relay" Throughout the document, the simple terms "Client", "Server", "Relay"
and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and
"AERO Proxy", respectively. Capitalization is used to distinguish "AERO Proxy", respectively. Capitalization is used to distinguish
these terms from DHCPv6 client/server/relay [RFC8415]. these terms from DHCPv6 client/server/relay [RFC8415].
The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including
the names of node variables, messages and protocol constants) is used the names of node variables, messages and protocol constants) is used
throughout this document. Also, the term "IP" is used to generically throughout this document. Also, the term "IP" is used to generically
refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or
skipping to change at page 8, line 41 skipping to change at page 9, line 38
.-(_ IP )-. +-------+ +-------+ .-(_ IP )-. .-(_ IP )-. +-------+ +-------+ .-(_ IP )-.
(__ EUN )--|Host H1| |Host H2|--(__ EUN ) (__ EUN )--|Host H1| |Host H2|--(__ EUN )
`-(______)-' +-------+ +-------+ `-(______)-' `-(______)-' +-------+ +-------+ `-(______)-'
Figure 1: AERO Link Reference Model Figure 1: AERO Link Reference Model
Figure 1 presents the AERO link reference model. In this model: Figure 1 presents the AERO link reference model. In this model:
o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a
default router for its associated Servers (S1 and S2), and default router for its associated Servers (S1 and S2), and
connects the AERO link to the rest of the Internetwork. connects the AERO link to the rest of the Internetwork. AERO
Relays also bridge disjoint segments of a partitioned AERO link.
o AERO Servers S1 and S2 associate with Relay R1 and also act as o AERO Servers S1 and S2 associate with Relay R1 and also act as
Mobility Anchor Points (MAPs) and default routers for their Mobility Anchor Points (MAPs) and default routers for their
associated Clients C1 and C2. associated Clients C1 and C2.
o AERO Clients C1 and C2 associate with Servers S1 and S2, o AERO Clients C1 and C2 associate with Servers S1 and S2,
respectively. They receive AERO Client Prefix (ACP) delegations respectively. They receive AERO Client Prefix (ACP) delegations
X1 and X2, and also act as default routers for their associated X1 and X2, and also act as default routers for their associated
physical or internal virtual EUNs. Simple hosts H1 and H2 attach physical or internal virtual EUNs. Simple hosts H1 and H2 attach
to the EUNs served by Clients C1 and C2, respectively. to the EUNs served by Clients C1 and C2, respectively.
o AERO Proxy P1 provides proxy services for AERO Clients in secured o AERO Proxy P1 provides proxy services for AERO Clients in secured
enclaves that cannot associate directly with other AERO link enclaves that cannot associate directly with other AERO link
neighbors. neighbors.
Each node on the AERO link maintains an AERO interface neighbor cache Each node on the AERO link maintains an AERO interface neighbor cache
and an IP forwarding table the same as for any link. Although the and an IP forwarding table the same as for any link. Although the
figure shows a limited deployment, in common operational practice figure shows a limited deployment, in common operational practice
there may be many additional Relays, Servers, Clients and Proxies. there will normally be many additional Relays, Servers, Clients and
Proxies.
3.2. AERO Node Types 3.2. AERO Node Types
AERO Relays are standard IP routers that provide default forwarding AERO Relays provide both layer-3 routing and layer-2 bridging
services for AERO Servers. Each Relay also peers with Servers and services (as well as a security trust anchor) for nodes on an AERO
other Relays in a dynamic routing protocol instance to provide a link. As a router, the Relay forwards data packets using standard IP
forwarding. As a bridge, the Relay securely forwards control
messages between Proxies and Servers both within the same partition
and between disjoint partitions. Each Relay also peers with Servers
and other Relays in a dynamic routing protocol instance to provide a
Distributed Mobility Management (DMM) service for the list of active Distributed Mobility Management (DMM) service for the list of active
ACPs (see Section 3.3). Relays forward packets between neighbors ACPs (see Section 3.3). Relays forward packets between neighbors
connected to the same AERO link and also forward packets between the connected to the same AERO link and also forward packets between the
AERO link and the native Internetwork. Relays present the AERO link AERO link and the native Internetwork. Relays present the AERO link
to the native Internetwork as a set of one or more AERO Service to the native Internetwork as a set of one or more AERO Service
Prefixes (ASPs) and serve as a gateway between the AERO link and the Prefixes (ASPs) and serve as a gateway between the AERO link and the
Internetwork. Relays maintain tunnels with neighboring Servers, and Internetwork. Relays maintain neighbor cache entries for Servers and
maintain an IP forwarding table entry for each AERO Client Prefix Proxies, and maintain an IP forwarding table entry for each AERO
(ACP). Client Prefix (ACP).
AERO Servers provide default forwarding services and a Mobility AERO Servers provide default forwarding services and a Mobility
Anchor Point (MAP) for AERO Clients. Each Server also peers with Anchor Point (MAP) for AERO Clients. Each Server also peers with
Relays in a dynamic routing protocol instance to advertise its list Relays in a dynamic routing protocol instance to advertise its list
of associated ACPs (see Section 3.3). Servers facilitate PD of associated ACPs (see Section 3.3). Servers facilitate PD
exchanges with Clients, where each delegated prefix becomes an ACP exchanges with Clients, where each delegated prefix becomes an ACP
taken from an ASP. Servers forward packets between AERO interface taken from an ASP. Servers forward packets between AERO interface
neighbors, and maintain AERO interface neighbor cache entries for neighbors, and maintain neighbor cache entries for Relays. They also
Relays. They also maintain both neighbor cache entries and IP maintain both neighbor cache entries and IP forwarding table entries
forwarding table entries for each of their associated Clients, and for each of their associated Clients, and track each Client's
track each Client's mobility profiles. mobility profiles.
AERO Clients act as requesting routers to receive ACPs through PD AERO Clients act as requesting routers to receive ACPs through PD
exchanges with AERO Servers over the AERO link. Each Client can exchanges with AERO Servers over the AERO link. Each Client can
associate with a single Server or with multiple Servers, e.g., for associate with a single Server or with multiple Servers, e.g., for
fault tolerance, load balancing, etc. Each IPv6 Client receives at fault tolerance, load balancing, etc. Each IPv6 Client receives at
least a /64 IPv6 ACP, and may receive even shorter prefixes. least a /64 IPv6 ACP, and may receive even shorter prefixes.
Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a
singleton IPv4 address), and may receive even shorter prefixes. singleton IPv4 address), and may receive even shorter prefixes.
Clients maintain an AERO interface neighbor cache entry for each of Clients maintain an AERO interface neighbor cache entry for each of
their associated Servers as well as for each of their correspondent their associated Servers as well as for each of their correspondent
Clients. Clients.
AERO Proxies provide a conduit for AERO Clients in secured enclaves AERO Proxies provide a conduit for AERO Clients in secured enclaves
to associate with AERO Servers. The Client sends all of its control to associate with AERO Servers. The Client sends all of its control
plane messages to the Server's link-layer address and the Proxy plane messages to the Server via the Proxy, which intercepts them
intercepts them before they leave the secured enclave. The Proxy before they leave the secured enclave. The Proxy forwards the
forwards the Client's control and data plane messages to and from the Client's control and data plane messages to and from the Client's
Client's current Server(s). The Proxy may also discover a more current Server(s). The Proxy may also discover a better route toward
direct route toward a target destination via AERO route optimization, a target destination via AERO route optimization, in which case
in which case future outbound data packets would be forwarded via the future outbound data packets would be forwarded via the more direct
more direct route. The Proxy function is specified in Section 3.15. route. Proxies maintain AERO interface neighbor cache entries for
Relays, i.e., the same as Servers. The Proxy function is specified
in Section 3.16.
AERO Relays, Servers and Proxies are critical infrastructure elements AERO Relays, Servers and Proxies are critical infrastructure elements
in fixed (i.e., non-mobile) deployments. Relays, Servers and Proxies in fixed (i.e., non-mobile) deployments. Relays, Servers and Proxies
must use public link-layer addresses that do not change and can be must use link-layer addresses that do not change and can be reached
reached from any correspondent in the underlying Internetwork (i.e., from any correspondent in the underlying Internetwork (i.e., in the
in the same fashion as for popular Internet services). AERO Clients same fashion as for popular Internet services). AERO Clients may be
may be mobile, and may not have any public link-layer addresses, mobile, and may not have any public link-layer addresses, e.g., if
e.g., if they are located behind NATs or Proxies. they are located behind NATs or Proxies.
3.3. AERO Routing System 3.3. AERO Routing System
The AERO routing system comprises a private instance of the Border The AERO routing system comprises a private instance of the Border
Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays
and Servers and does not interact with either the public Internet BGP and Servers and does not interact with either the public Internet BGP
routing system or the native Internetwork routing system. Relays routing system or the native Internetwork routing system. Relays
advertise only a small and unchanging set of ASPs to the native advertise only a small and unchanging set of ASPs to the native
Internetwork routing system instead of the full dynamically changing Internetwork routing system instead of the full dynamically changing
set of ACPs. set of ACPs.
In a reference deployment, each Server is configured as an Autonomous In a reference deployment, each Server is configured as an Autonomous
System Border Router (ASBR) for a stub Autonomous System (AS) using System Border Router (ASBR) for a stub Autonomous System (AS) using
an AS Number (ASN) that is unique within the BGP instance, and each an AS Number (ASN) that is unique within the BGP instance, and each
Server further uses eBGP to peer with one or more Relays but does not Server further uses eBGP to peer with one or more Relays but does not
peer with other Servers. All Relays are members of the same hub AS peer with other Servers. Each segment of a multi-segment AERO link
using a common ASN, and use iBGP to maintain a consistent view of all must include one or more Relays, which peer with the Servers and
active ACPs currently in service. Proxies within that segment. All Relays within the same segment are
members of the same hub AS using a common ASN, and use iBGP to
maintain a consistent view of all active ACPs currently in service.
The Relays of different segments peer with one another using eBGP.
Each Server maintains a working set of associated ACPs, and Each Server maintains a working set of associated ACPs, and
dynamically announces new ACPs and withdraws departed ACPs in its dynamically announces new ACPs and withdraws departed ACPs in its
eBGP updates to Relays. Clients are expected to remain associated eBGP updates to Relays. Clients are expected to remain associated
with their current Servers for extended timeframes, however Servers with their current Servers for extended timeframes, however Servers
SHOULD selectively suppress updates for impatient Clients that SHOULD selectively suppress updates for impatient Clients that
repeatedly associate and disassociate with them in order to dampen repeatedly associate and disassociate with them in order to dampen
routing churn. routing churn.
Each Relay configures a black-hole route for each of its ASPs. By Each Relay configures a black-hole route for each of its ASPs. By
skipping to change at page 13, line 4 skipping to change at page 14, line 14
The Client then constructs its AERO addresses with the prefix The Client then constructs its AERO addresses with the prefix
fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address
in the interface identifier as: in the interface identifier as:
fe80::FFFF:192.0.2.16 fe80::FFFF:192.0.2.16
fe80::FFFF:192.0.2.17 fe80::FFFF:192.0.2.17
fe80::FFFF:192.0.2.18 fe80::FFFF:192.0.2.18
... etc. ... ... etc. ...
fe80:FFFF:192.0.2.31 fe80:FFFF:192.0.2.31
Relay, Server and Proxy AERO addresses are allocated from the range Relay, Server and Proxy AERO addresses are allocated from the range
fe80::/96, and MUST be managed for uniqueness by the administrative fe80::/96, and MUST be managed for uniqueness. The lower 32 bits of
authority for the link. For interfaces that assign static IPv4 the AERO address includes a unique integer value (e.g., fe80::1,
addresses, the lower 32 bits of the AERO address includes the IPv4 fe80::2, fe80::3, etc.) as assigned by the administrative authority
address, e.g., for the IPv4 address 192.0.2.1 the corresponding AERO for the link. If the link comprises multiple segments, the AERO
address is fe80::192.0.2.1. For other interfaces, the lower 32 bits addresses are assigned to each segment in correspondence with the
of the AERO address includes a unique integer value, e.g., fe80::1, SPAN addresses assigned to the segment (see: Section 3.5). The
fe80::2, fe80::3, etc. The address fe80:: is reserved as the IPv6 address fe80:: is reserved as the IPv6 link-local Subnet Router
link-local Subnet Router Anycast address [RFC4291], and the address Anycast address [RFC4291], and the address fe80::ffff:ffff is
fe80::ffff:ffff is reserved as the unspecified AERO address; hence, reserved as the unspecified AERO address; hence, these values are not
these values are not available for administrative assignment. (Note available general assignment.
that this special link-local-format unspecified address is defined
for AERO to satisfy PD services that require a link-local source
address.)
When the Server delegates ACPs to the Client, the lowest-numbered When the Server delegates ACPs to the Client, the lowest-numbered
AERO address from the first ACP delegation serves as the "base" AERO AERO address from the first ACP delegation serves as the "base" AERO
address (for example, for the ACP 2001:db8:1000:2000::/56 the base address (for example, for the ACP 2001:db8:1000:2000::/56 the base
AERO address is fe80::2001:db8:1000:2000). The Client then assigns AERO address is fe80::2001:db8:1000:2000). The Client then assigns
the base AERO address to the AERO interface and uses it for the the base AERO address to the AERO interface and uses it for the
purpose of maintaining the neighbor cache entry. The Server likewise purpose of maintaining the neighbor cache entry. The Server likewise
uses the AERO address as its index into the neighbor cache for this uses the AERO address as its index into the neighbor cache for this
Client. Client.
skipping to change at page 13, line 50 skipping to change at page 15, line 9
AERO addresses that embed an IPv6 prefix can be statelessly AERO addresses that embed an IPv6 prefix can be statelessly
transformed into an IPv6 Subnet Router Anycast address and vice- transformed into an IPv6 Subnet Router Anycast address and vice-
versa. For example, for the AERO address fe80::2001:db8:2000:3000 versa. For example, for the AERO address fe80::2001:db8:2000:3000
the corresponding Subnet Router Anycast address is the corresponding Subnet Router Anycast address is
2001:db8:2000:3000::. In the same way, for the IPv6 Subnet Router 2001:db8:2000:3000::. In the same way, for the IPv6 Subnet Router
Anycast address 2001:db8:1:2:: the corresponding AERO address is Anycast address 2001:db8:1:2:: the corresponding AERO address is
fe80::2001:db8:1:2. In other words, the low-order 64 bits of an AERO fe80::2001:db8:1:2. In other words, the low-order 64 bits of an AERO
address can be used as the high-order 64 bits of a Subnet Router address can be used as the high-order 64 bits of a Subnet Router
Anycast address, and vice-versa. Anycast address, and vice-versa.
AERO links additionally require a reserved IPv6 prefix to support 3.5. Spanning Partitioned AERO Networks (SPAN)
encapsulated forwarding of IPv6 ND messages between Servers on the
link. Although any non-link-local IPv6 prefix could be reserved for
this purpose, a Unique Local Address (ULA) prefix [RFC4389] would be
preferred since packets with ULAs cannot be forwarded into the AERO
link by an external IPv6 node. For example, if the reserved (ULA)
prefix is fd00:db8::/64 the AERO Server Subnet Router Anycast Address
is fd00:db8::.
A full discussion of the AERO addressing service is found in In the simplest case, an AERO link configured over a single
[I-D.templin-6man-aeroaddr]. administrative domain (e.g., an enterprise network) appears as a
single unified link with a consistent underlying network addressing
plan. In that case, all nodes on the link can exchange packets
directly since the underlying network is connected.
3.5. AERO Interface Characteristics In a more complex case, an AERO link may be partitioned into multiple
"segments", where each segment is configured over a different
administrative domain (e.g., as for regional aviation networks). In
that case, the underlying network addressing plan of each segment is
consistent internally but will often bear no relation to the
addressing plans of other segments. Each segment is also likely to
be separated from other segments by network security devices (e.g.,
firewalls, proxies, packet filtering gateways, etc.), and in many
cases disjoint segments may not even have any common physical link
connections at all. Therefore, the nodes within each segment can
only be assured of exchanging packets directly with nodes in the same
segment, and not with nodes in other segments. The only means for
joining the segments therefore is through inter-domain peerings
between segment border routers.
AERO interfaces use encapsulation (see: Section 3.9) to exchange The same as for traditional campus LANs, multiple AERO link segments
can be joined into a single unified link via bridging in an underlay
network termed "The SPAN". The SPAN performs link-layer packet
forwarding between segments so that nodes on segment A can exchange
packets with nodes on segment B via bridging without decrementing the
network-layer TTL/Hop Limit. To support the SPAN, AERO links require
a reserved /96 IPv6 "SPAN Service Prefix (SSP)". Although any
routable IPv6 prefix can be reserved, use of a Unique Local Address
(ULA) prefix (e.g., fd00::/96) [RFC4389] is RECOMMENDED since packets
with ULAs cannot be injected into the AERO link by an external IPv6
node and cannot leak out of the AERO link to the outside world.
Each partition in the SPAN assigns a unique sub-prefix of the SSP,
i.e., a "SPAN Partition Prefix (SPP)". For example, a first
partition could assign fd00::/116, a second partition could assign
fd00::1000/116, a third could assign fd00::2000/116, etc. The
administrative authorities for each partition must therefore
coordinate to assure mutually-exclusive SPP assignments, but internal
provisioning of the SPP is a local consideration for each
administrative authority.
A "SPAN address" is an address taken from a SPP and assigned to a
Relay, Server or Proxy AERO interface. SPAN addresses are formed by
simply replacing the upper portion of an administratively-assigned
AERO address with the SPP. For example, if the SPP is fd00::/116,
the SPAN address formed from the AERO address fe80::1 is simply
fd00::1. (As with AERO addresses, the values ::0 and ::ffff:ffff are
reserved and not available for general assignment.)
AERO Relays serve as bridges to join multiple segments into a unified
AERO link over multiple diverse administrative domains. They support
the bridging function by first exchanging their SPPs via standard BGP
routing. For example, if three Relays (Relays 'A', 'B' and 'C') from
different administrative domains advertised the SPPs fd00::1000/116,
fd00::2000/116 and fd00::3000/116 respectively, then the forwarding
tables in each Relay are as follows:
A: fd00::1000/116->local, fd00::2000/116->B, fd00::3000/116->C
B: fd00::1000/116->A, fd00::2000/116->local, fd00::3000/116->C
C: fd00::1000/116->A, fd00::2000/116->B, fd00::3000/116->local
These forwarding table entries remain in place indefinitely and never
change, since they correspond to fixed infrastructure elements in
their respective partitions. This point is of critical importance,
since it provides the basis for a link-layer forwarding service that
cannot be disrupted by routing updates due to node mobility.
With the SPPs in place in each Relay's forwarding table, control and
data packets sent between AERO nodes in different partitions can
therefore be carried over the SPAN via encapsulation. For example,
when a node in partition A forwards a packet with IPv6 address
2001:db8:1:2::1 to a node in partition C with IPv6 address
2001:db8:1000:2000::1, it first encapsulates the packet in a SPAN
header with source address from fd00::1000/116 (e.g., fd00::1001) and
destination address from fd00::3000/116 (e.g., fd00::3001).
SPAN encapsulation is based on Generic Packet Tunneling in IPv6
[RFC2473]; the encapsulation format in this example is shown
inFigure 2:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Header(s) |
| src = L2(X) |
| dst = L2(Y) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPAN Header (RFC2473) |
| src = fd00::1001 |
| dst = fd00::3001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner IP Header |
| src = 2001:db8:1:2::1 |
| dst = 2001:db8:1000:2000::1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Inner Packet Body ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SPAN Encapsulation
In this format, the inner IP header and packet body are the original
IP packet, the SPAN header is an IPv6 header prepared according to
[RFC2473], and the outer header is added by the same node ('X') that
added the SPAN header according to Section 3.10. The source and
destination addresses of the outer header are the link-layer
addresses of nodes 'X' and 'Y' (where 'Y' is a Relay connected to the
SPAN).
An (inner) IP packet is said to be "sent into the SPAN" or "sent via
the SPAN" when it is encapsulated as described above then forwarded
to a neighboring Relay. This terminology appears throughout the
remaining sections of the document.
This gives rise to a routing system that contains both ACP routes
that may change dynamically due to regional node mobility and SPAN
routes that never change. The Relays can therefore provide link-
layer bridging by sending packets via the SPAN instead of network-
layer routing according to ACP routes. As a result, opportunities
for packet loss due to node mobility are mitigated.
3.6. AERO Interface Characteristics
AERO interfaces use encapsulation (see: Section 3.10) to exchange
packets with neighbors attached to the AERO link. packets with neighbors attached to the AERO link.
AERO interfaces maintain a neighbor cache for tracking per-neighbor AERO interfaces maintain a neighbor cache for tracking per-neighbor
state the same as for any interface. AERO interfaces use ND messages state the same as for any interface. AERO interfaces use ND messages
including Router Solicitation (RS), Router Advertisement (RA), including Router Solicitation (RS), Router Advertisement (RA),
Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for
neighbor cache management. neighbor cache management.
AERO interface ND messages include one or more Source/Target Link- AERO interface ND messages include one or more Source/Target Link-
Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: Layer Address Options (S/TLLAOs) formatted as shown in Figure 3:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 5 | Prefix Length |R|D|X|N| Resvd | | Type | Length = 5 | Prefix Length |R|D|X|T| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | UDP Port Number | | Interface ID | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ IP Address + + Link Layer Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) Figure 3: AERO Source/Target Link-Layer Address Option (S/TLLAO)
Format Format
In this format: In this format:
o Type is set to '1' for SLLAO or '2' for TLLAO. o Type is set to '1' for SLLAO or '2' for TLLAO.
o Length is set to the constant value '5' (i.e., 5 units of 8 o Length is set to the constant value '5' (i.e., 5 units of 8
octets). octets).
o Prefix Length is set to the ACP prefix length in an ND message for o Prefix Length is set to the ACP prefix length in an ND message for
skipping to change at page 15, line 51 skipping to change at page 19, line 11
or target (NA) address; otherwise set to 0 if the message is not or target (NA) address; otherwise set to 0 if the message is not
being used for PD or neighbor prefix discovery. If the message being used for PD or neighbor prefix discovery. If the message
contains multiple SLLAOs, only the Prefix Length value in the contains multiple SLLAOs, only the Prefix Length value in the
first SLLAO is consulted and the values in other SLLAOs are first SLLAO is consulted and the values in other SLLAOs are
ignored. ignored.
o R (the "Release" bit) is set to '1' in the SLLAO of an RS message o R (the "Release" bit) is set to '1' in the SLLAO of an RS message
sent for the purpose of departing from a Server; otherwise, set to sent for the purpose of departing from a Server; otherwise, set to
'0'. If the message contains multiple SLLAOs, only the R value in '0'. If the message contains multiple SLLAOs, only the R value in
the first SLLAO is consulted and the values in other SLLAOs are the first SLLAO is consulted and the values in other SLLAOs are
ignored. The Server places the correponsing neighbor cache entry ignored. The Server places the corresponding neighbor cache entry
in the DEPARTED state and releases the corresponding PD, then in the DEPARTED state and releases the corresponding PD, then
returns an RA with Router Lifetime set to '0'. returns an RA with Router Lifetime set to '0'.
o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA
message for each Interface ID that is to be disabled in the message for each Interface ID that is to be disabled in the
neighbor cache entry; otherwise, set to '0'. If the message neighbor cache entry; otherwise, set to '0'. If the message
contains an S/TLLAO with Interface ID 255, the node places the contains an S/TLLAO with Interface ID 255, the node places the
corresponding neighbor cache entry in the DEPARTED state. If the corresponding neighbor cache entry in the DEPARTED state. If the
message contains multiple S/TLLAOs the D value in each S/TLLAO is message contains multiple S/TLLAOs the D value in each S/TLLAO is
honored. consulted.
o X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA message o X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA message
by the Proxy when there is a Proxy in the path; otherwise, set to by the Proxy when there is a Proxy in the path; otherwise, set to
'0'. If the message contains multiple SLLAOs, only the X value in '0'. If the message contains multiple SLLAOs, only the X value in
the first SLLAO is consulted and the values in other SLLAOs are the first SLLAO is consulted and the values in other SLLAOs are
ignored. ignored.
o N (the "NAT" bit) is set to '1' in the SLLAO of an RA message by o T (the "Translator" bit) is set to '1' in the SLLAO of an RA
the Server if there is a NAT in the path; otherwise, set to '0'. message by the Server if there is a link-layer address translator
If the message contains multiple SLLAOs, only the N value in the in the path; otherwise, set to '0'. If the message contains
first SLLAO is consulted and the values in other SLLAOs are multiple SLLAOs, only the N value in the first SLLAO is consulted
ignored. and the values in other SLLAOs are ignored.
o Resvd is set to the value '0' on transmission and ignored on o Resvd is set to the value '0' on transmission and ignored on
receipt. receipt.
o Interface ID is set to a 16-bit integer value corresponding to an o Interface ID is set to a 16-bit integer value corresponding to an
underlying interface of the AERO node. Once the node has assigned underlying interface of the AERO node. Once the node has assigned
an Interface ID to an underlying interface, the assignment must an Interface ID to an underlying interface, the assignment must
remain unchanged until the node fully detaches from the AERO link. remain unchanged until the node fully detaches from the AERO link.
The value '255' is reserved as the AERO Server interface ID, i.e., The value '255' is reserved as the AERO Server interface ID, i.e.,
Servers MUST use Interface ID '255', and Clients MUST number their Servers MUST use Interface ID '255', and Clients MUST number their
Interface IDs with values in the range of 0-254. Interface IDs with values in the range of 0-254.
o UDP Port Number and IP Address are set to the addresses used by o Port Number and Link Layer Address are set to the addresses used
the AERO node when it sends encapsulated packets over the by the AERO node when it sends encapsulated packets over the
specified underlying interface (or to '0' when the addresses are specified underlying interface (or to '0' when the addresses are
left unspecified). When UDP is not used as part of the left unspecified). When UDP is not used as part of the
encapsulation, UDP Port Number is set to '0'. When the encapsulation, Port Number is set to '0'. When the encapsulation
encapsulation IP address family is IPv4, IP Address is formed as IP address family is IPv4, IP Address is formed as an IPv4-mapped
an IPv4-mapped IPv6 address as specified in Section 3.4. IPv6 address as specified in Section 3.4.
o P(i) is a set of Preferences that correspond to the 64 o P(i) is a set of Preferences that correspond to the 64
Differentiated Service Code Point (DSCP) values [RFC2474]. Each Differentiated Service Code Point (DSCP) values [RFC2474]. Each
P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' P(i) is set to the value '0' ("disabled"), '1' ("low"), '2'
("medium") or '3' ("high") to indicate a QoS preference level for ("medium") or '3' ("high") to indicate a QoS preference level for
packet forwarding purposes. packet forwarding purposes.
AERO interfaces may be configured over multiple underlying interface AERO interfaces may be configured over multiple underlying interface
connections to underlying links. For example, common mobile handheld connections to underlying links. For example, common mobile handheld
devices have both wireless local area network ("WLAN") and cellular devices have both wireless local area network ("WLAN") and cellular
skipping to change at page 17, line 21 skipping to change at page 20, line 29
wireless data link types (e.g. satellite-based, cellular, wireless data link types (e.g. satellite-based, cellular,
terrestrial, air-to-air directional, etc.) with diverse performance terrestrial, air-to-air directional, etc.) with diverse performance
and cost properties. and cost properties.
A Client's underlying interfaces are classified as follows: A Client's underlying interfaces are classified as follows:
o Native interfaces connect to the open Internetwork, and have a o Native interfaces connect to the open Internetwork, and have a
global IP address that is reachable from any open Internetwork global IP address that is reachable from any open Internetwork
correspondent. correspondent.
o NATed interfaces connect to a closed network that is separated o NATed interfaces connect to a private network behind a Network
from the open Internetwork by a Network Address Translator (NAT). Address Translator (NAT). The NAT does not participate in any
The NAT does not participate in any AERO control message AERO control message signaling, but the AERO Server can issue
signaling, but the AERO Server can issue control messages on control messages on behalf of the Client. Clients that are behind
behalf of the Client. a NAT are required to send periodic keepalive messages to keep NAT
state alive when there are no data packets flowing.
o VPNed interfaces use security encapsulation over the Internetwork o VPNed interfaces use security encapsulation over the Internetwork
to a Virtual Private Network (VPN) gateway that also acts as an to a Virtual Private Network (VPN) gateway that also acts as an
AERO Server. As with NATed links, the AERO Server can issue AERO Server. As with NATed links, the AERO Server can issue
control messages on behalf of the Client. control messages on behalf of the Client, but the Client need not
send periodic keepalives in addition to those already used to
maintain the VPN connection.
o Proxyed interfaces connect to a closed network that is separated o Proxyed interfaces connect to a closed network that is separated
from the open Internetwork by an AERO Proxy. Unlike NATed and from the open Internetwork by an AERO Proxy. Unlike NATed and
VPNed interfaces, the AERO Proxy can also issue control messages VPNed interfaces, the AERO Proxy can also issue control messages
on behalf of the Client. on behalf of the Client.
o Direct interfaces connect the Client directly to a neighbor o Direct interfaces connect the Client directly to a neighbor
without crossing any networked paths. An example is a line-of- without crossing any networked paths. An example is a line-of-
sight link between a remote pilot and an unmanned aircraft. sight link between a remote pilot and an unmanned aircraft.
skipping to change at page 18, line 6 skipping to change at page 21, line 19
appear to have a single underlying interface but with a dynamically appear to have a single underlying interface but with a dynamically
changing link-layer address. changing link-layer address.
If the Client has multiple active underlying interfaces, then from If the Client has multiple active underlying interfaces, then from
the perspective of ND it would appear to have multiple link-layer the perspective of ND it would appear to have multiple link-layer
addresses. In that case, ND messages MAY include multiple S/TLLAOs addresses. In that case, ND messages MAY include multiple S/TLLAOs
-- each with an Interface ID that corresponds to a specific -- each with an Interface ID that corresponds to a specific
underlying interface of the AERO node. underlying interface of the AERO node.
When the Client includes an S/TLLAO for an underlying interface for When the Client includes an S/TLLAO for an underlying interface for
which it is aware that there is a NAT or Proxy on the path to the which it is aware that there is a Translator on the path to the
Server, or when a node includes an S/TLLAO solely for the purpose of Server, or when a node includes an S/TLLAO solely for the purpose of
announcing new QoS preferences, the node sets both UDP Port Number announcing new QoS preferences, the node MAY set both Port Number and
and IP Address to 0 to indicate that the addresses are unspecified at Link-Layer Address to 0 to indicate that the addresses are
the network layer and must instead be derived from the link-layer unspecified at the network layer and must instead be derived from the
encapsulation headers. link-layer encapsulation headers.
When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST
correspond to the AERO node's underlying interface used to transmit correspond to the AERO node's underlying interface used to transmit
the message. the message.
3.6. AERO Interface Initialization 3.7. AERO Interface Initialization
3.6.1. AERO Relay Behavior 3.7.1. AERO Relay Behavior
When a Relay enables an AERO interface, it first assigns an When a Relay enables an AERO interface, it first assigns an
administratively-provisioned AERO address fe80::ID to the interface. administratively-provisioned AERO address (e.g., fe80::1) and its
Each fe80::ID address MUST be unique among all AERO nodes on the companion SPAN address (e.g., fd00::1) to the interface, where each
link. The Relay then engages in a dynamic routing protocol session address MUST be unique among all AERO nodes on the link. The Relay
with one or more Servers and all other Relays on the link (see: also configures a neighbor cache entry for Servers and Proxys on the
Section 3.3), and advertises its assigned ASPs into the native local segment. The Relay then engages in a BGP routing protocol
Internetwork. Each Relay subsequently maintains an IP forwarding session with Servers on the local segment and other Relays on the
table entry for each active ACP covered by its ASP(s). link (see: Section 3.3), and advertises its assigned ASPs into the
native Internetwork. Each Relay subsequently maintains an IP
forwarding table entry for each active ACP covered by its ASP(s) as
well as for each SPAN prefix.
3.6.2. AERO Server Behavior 3.7.2. AERO Server Behavior
When a Server enables an AERO interface, it assigns an When a Server enables an AERO interface, it assigns AERO and SPAN
administratively-provisioned AERO address fe80::ID the same as for addresses the same as for Relays. The Server further configures a
Relays. The Server further configures a service to facilitate ND/PD service to facilitate ND/PD exchanges with AERO Clients. The Server
exchanges with AERO Clients. The Server maintains neighbor cache maintains neighbor cache entries for one or more Relays on the link,
entries for one or more Relays on the link, and manages per-Client and manages per-Client neighbor cache entries and IP forwarding table
neighbor cache entries and IP forwarding table entries based on entries based on control message exchanges. The Server also engages
control message exchanges. The Server also engages in a dynamic in a BGP routing protocol session with its neighboring Relays (see:
routing protocol with its neighboring Relays (see: Section 3.3). Section 3.3).
When the Server receives an NS/RS message on the AERO interface it When the Server receives an NS/RS message on the AERO interface it
authenticates the message and returns a solicited NA/RA message. authenticates the message and returns a solicited NA/RA message.
(When the Server receives an unsolicited NA message, it likewise (When the Server receives an unsolicited NA message, it likewise
authenticates the message and processes it locally.) The Server authenticates the message and processes it locally.) The Server
further provides a simple link-layer conduit between AERO interface further provides a simple link-layer conduit between AERO interface
neighbors. In particular, when a packet sent by a source Client neighbors. In particular, when a packet sent by a source Client
arrives on the Server's AERO interface and is destined to another arrives on the Server's AERO interface and is destined to another
AERO node, the Server forwards the packet from within the AERO AERO node, the Server forwards the packet from within the AERO
interface at the link layer without ever disturbing the network interface at the link layer without ever disturbing the network
layer. layer.
3.6.3. AERO Proxy Behavior 3.7.3. AERO Proxy Behavior
When a Proxy enables an AERO interface, it assigns an When a Proxy enables an AERO interface, it assigns AERO and SPAN
administratively-provisioned address fe80::ID the same as for Relays addresses the same as for Relays and Servers, and maintains neighbor
and Servers. The Proxy further maintains per-Client proxy neighbor cache entires for one or more Relays. The Proxy further maintains
cache entries based on control message exchanges. Proxies forward per-Client neighbor cache entries based on control message exchanges.
packets between their associated Clients and each Client's associated Proxies forward packets between each Client and their associated
Servers. Servers and neighbors.
When the Proxy receives an RS message from a Client in the secured When the Proxy receives an RS message from a Client in the secured
enclave, it creates an incomplete proxy neighbor cache entry and enclave, it creates an incomplete neighbor cache entry and sends a
sends a proxyed RS message to a Server selected by the Client while proxyed RS message to a Server via the SPAN while using its own link-
using its own link-layer address as the source address. When the layer address as the source address. When the Server returns an RA
Server returns an RA message, the Proxy completes the proxy neighbor message, the Proxy completes the proxy neighbor cache entry based on
cache entry based on autoconfiguration information in the RA and autoconfiguration information in the RA and sends a proxyed RA to the
sends a proxyed RA to the Client while using its own link-layer Client while using its own link-layer address as the source address.
address as the source address. The Client, Server and Proxy will The Client, Server and Proxy will then have the necessary state for
then have the necessary state for managing the proxy neighbor managing the proxy neighbor association.
association.
3.6.4. AERO Client Behavior 3.7.4. AERO Client Behavior
When a Client enables an AERO interface, it sends RS messages with When a Client enables an AERO interface, it sends RS messages with
ND/PD parameters over an underlying interface to one or more AERO ND/PD parameters over an underlying interface to one or more AERO
Servers, which return RA messages with corresponding PD parameters. Servers, which return RA messages with corresponding PD parameters.
(The RS/RA messages may pass through a Proxy on the path in the case (The RS/RA messages may pass through a Proxy on the path in the case
of a Client's Proxyed interface.) See of a Client's Proxyed interface.) See
[I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters
that can be included in the RS/RA message exchanges. that can be included in the RS/RA message exchanges.
After the initial ND/PD message exchange, the Client assigns AERO After the initial ND/PD message exchange, the Client assigns AERO
skipping to change at page 20, line 5 skipping to change at page 23, line 19
The Client maintains a neighbor cache entry for each of its Servers The Client maintains a neighbor cache entry for each of its Servers
and each of its active target Clients. When the Client receives ND and each of its active target Clients. When the Client receives ND
messages on the AERO interface it updates or creates neighbor cache messages on the AERO interface it updates or creates neighbor cache
entries, including link-layer address and QoS preferences. entries, including link-layer address and QoS preferences.
When there is a NAT on the path, the Client must send periodic When there is a NAT on the path, the Client must send periodic
messages to keep NAT state alive. If no other periodic messaging messages to keep NAT state alive. If no other periodic messaging
service is available, the Client can send RS messages to receive RA service is available, the Client can send RS messages to receive RA
replies from its Server(s). replies from its Server(s).
3.7. AERO Interface Neighbor Cache Maintenance 3.8. AERO Interface Neighbor Cache Maintenance
Each AERO interface maintains a conceptual neighbor cache that Each AERO interface maintains a conceptual neighbor cache that
includes an entry for each neighbor it communicates with on the AERO includes an entry for each neighbor it communicates with on the AERO
link per [RFC4861]. AERO interface neighbor cache entries are said link per [RFC4861]. AERO interface neighbor cache entries are said
to be one of "permanent", "symmetric", "asymmetric" or "proxy". to be one of "permanent", "symmetric", "asymmetric" or "proxy".
Permanent neighbor cache entries are created through explicit Permanent neighbor cache entries are created through explicit
administrative action; they have no timeout values and remain in administrative action; they have no timeout values and remain in
place until explicitly deleted. AERO Relays maintain permanent place until explicitly deleted. AERO Relays maintain permanent
neighbor cache entries for their associated Relays and Servers on the neighbor cache entries for their associated Relays, Servers and
link, and AERO Servers maintain permanent neighbor cache entries for Proxys, and AERO Servers and Proxys maintain permanent neighbor cache
their associated Relays. Each entry maintains the mapping between entries for their associated Relays. Each entry maintains the
the neighbor's fe80::ID network-layer address and corresponding link- mapping between the neighbor's network-layer AERO address and
layer address. corresponding link-layer address.
Symmetric neighbor cache entries are created and maintained through Symmetric neighbor cache entries are created and maintained through
ND/PD exchanges as specified in Section 3.14, and remain in place for ND/PD exchanges as specified in Section 3.15, and remain in place for
durations bounded by ND/PD lifetimes. AERO Servers maintain durations bounded by ND/PD lifetimes. AERO Servers maintain
symmetric neighbor cache entries for each of their associated symmetric neighbor cache entries for each of their associated
Clients, and AERO Clients maintain symmetric neighbor cache entries Clients, and AERO Clients maintain symmetric neighbor cache entries
for each of their associated Servers. for each of their associated Servers.
Asymmetric neighbor cache entries are created or updated based on Asymmetric neighbor cache entries are created or updated based on
route optimization messaging as specified in Section 3.16, and are route optimization messaging as specified in Section 3.17, and are
garbage-collected when keepalive timers expire. AERO route garbage-collected when keepalive timers expire. AERO route
optimization sources maintain asymmetric neighbor cache entries for optimization sources (ROSs) maintain asymmetric neighbor cache
each of their active target Clients with lifetimes based on ND entries for each of their active target Clients with lifetimes based
messaging constants. Asymmetric neighbor cache entries are on ND messaging constants. Asymmetric neighbor cache entries are
unidirectional since only the route optimization source (i.e., and unidirectional since only the ROS (i.e., and not the route
not the target) creates an entry. optimization responder (ROR)) creates an entry.
Proxy neighbor cache entries are created and maintained by AERO Proxy neighbor cache entries are created and maintained by AERO
Proxies when they process Client/Server ND/PD exchanges, and remain Proxies when they process Client/Server ND/PD exchanges, and remain
in place for durations bounded by ND/PD lifetimes. AERO Proxies in place for durations bounded by ND/PD lifetimes. AERO Proxies
maintain proxy neighbor cache entries for each of their associated maintain proxy neighbor cache entries for each of their associated
Clients. Proxy neighbor cache entries track the Client state and the Clients. Proxy neighbor cache entries track the Client state and the
state of each of the Client's associated Servers. state of each of the Client's associated Servers.
To the list of neighbor cache entry states in Section 7.3.2 of To the list of neighbor cache entry states in Section 7.3.2 of
[RFC4861], AERO interfaces add an additional state DEPARTED that [RFC4861], AERO interfaces add an additional state DEPARTED that
applies to symmetric and proxy neighbor cache entries for Clients applies to symmetric and proxy neighbor cache entries for Clients
that have recently departed. The interface sets a "DepartTime" that have recently departed. The interface sets a "DepartTime"
varibale for the neighbor cache entry to "DEPARTTIME" seconds. variable for the neighbor cache entry to "DEPARTTIME" seconds.
DepartTime is decremented unless a new ND message causes the state to DepartTime is decremented unless a new ND message causes the state to
return to REACHABLE. While a neighbor cache entry is in the DEPARTED return to REACHABLE. While a neighbor cache entry is in the DEPARTED
state, packets destined to the target Client are forwarded according state, packets destined to the target Client are forwarded to the
to the remaining underlying interface state instead of being dropped. Client's new location instead of being dropped. When DepartTime
decrements to 0, the neighbor cache entry is deleted. It is
When DepartTime decrements to 0, the neighbor cache entry is deleted. RECOMMENDED that DEPARTTIME be set to the default constant value 40
It is RECOMMENDED that DEPARTTIME be set to the default constant seconds to allow for packets in flight to be delivered while stale
value 40 seconds to allow for packets in flight to be delivered while route optimization state may be present.
stale route optimization state may be present.
When a target AERO Server (acting as a Mobility Anchor Point (MAP)) When a target AERO Server (acting as a Mobility Anchor Point (MAP))
receives a valid NS message used for route optimization, it searches receives a valid NS message used for route optimization, it searches
for a symmetric neighbor cache entry for the target Client. The for a symmetric neighbor cache entry for the target Client. The
Server then returns a solicited NA message without creating a Server then acts as an ROR and returns a solicited NA message without
neighbor cache entry for the route optimization source, but maintains creating a neighbor cache entry for the ROS, but maintains a "Report
a "Report List" for the Client's symmetric neighbor cache entry. List" for the Client's symmetric neighbor cache entry. When the ROR
When the Server receives an authentic NS message it adds a Report receives an authentic NS message it adds a Report list entry for the
list entry for the NS source and sets a "ReportTime" variable for the ROS and sets a "ReportTime" variable for the entry to REPORTTIME
entry to REPORTTIME seconds. The Server resets ReportTime when it seconds. The ROR resets ReportTime when it receives a new authentic
receives a new authentic NS message, and otherwise decrements NS message, and otherwise decrements ReportTime while no NS messages
ReportTime while no NS messages have been received. It is have been received. It is RECOMMENDED that REPORTTIME be set to the
RECOMMENDED that REPORTTIME be set to the default constant value 40 default constant value 40 seconds to allow a 10 second window so that
seconds to allow a 10 second window so that route optimization can route optimization can converege before ReportTime decrements below
converege before ReportTime decrements below REACHABLETIME. REACHABLETIME.
When the route optimization source receives a solicited NA message
response to its NS message, it creates or updates an asymmetric
neighbor cache entry for the target network-layer and link-layer
addresses. The node then (re)sets ReachableTime for the neighbor
cache entry to REACHABLETIME seconds and uses this value to determine
whether packets can be forwarded directly to the target, i.e.,
instead of via a default route. The node otherwise decrements
ReachableTime while no further solicited NA messages arrive. It is
RECOMMENDED that REACHABLETIME be set to the default constant value
30 seconds as specified in [RFC4861].
The route optimization source also uses the value MAX_UNICAST_SOLICIT When the ROS receives a solicited NA message response to its NS
to limit the number of NS keepalives sent when a correspondent may message, it creates or updates an asymmetric neighbor cache entry for
have gone unreachable, the value MAX_RTR_SOLICITATIONS to limit the the target network-layer and link-layer addresses. The ROS then
number of RS messages sent without receiving an RA and the value (re)sets ReachableTime for the neighbor cache entry to REACHABLETIME
MAX_NEIGHBOR_ADVERTISEMENT to limit the number of unsolicited NAs seconds and uses this value to determine whether packets can be
that can be sent based on a single event. It is RECOMMENDED that forwarded directly to the target, i.e., instead of via a default
MAX_UNICAST_SOLICIT, MAX_RTR_SOLICITATIONS and route. The ROS otherwise decrements ReachableTime while no further
MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the same as specified in solicited NA messages arrive. It is RECOMMENDED that REACHABLETIME
be set to the default constant value 30 seconds as specified in
[RFC4861]. [RFC4861].
The ROS also uses the value MAX_UNICAST_SOLICIT to limit the number
of NS keepalives sent when a correspondent may have gone unreachable,
the value MAX_RTR_SOLICITATIONS to limit the number of RS messages
sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT
to limit the number of unsolicited NAs that can be sent based on a
single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT,
MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the
same as specified in [RFC4861].
Different values for DEPARTTIME, REPORTTIME, REACHABLETIME, Different values for DEPARTTIME, REPORTTIME, REACHABLETIME,
MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and
MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if
different values are chosen, all nodes on the link MUST consistently different values are chosen, all nodes on the link MUST consistently
configure the same values. Most importantly, DEPARTTIME and configure the same values. Most importantly, DEPARTTIME and
REPORTTIME SHOULD be set to a value that is sufficiently longer than REPORTTIME SHOULD be set to a value that is sufficiently longer than
REACHABLETIME to avoid packet loss due to stale route optimization REACHABLETIME to avoid packet loss due to stale route optimization
state. state.
3.8. AERO Interface Forwarding Algorithm 3.9. AERO Interface Forwarding Algorithm
IP packets enter a node's AERO interface either from the network IP packets enter a node's AERO interface either from the network
layer (i.e., from a local application or the IP forwarding system) or layer (i.e., from a local application or the IP forwarding system) or
from the link layer (i.e., from the AERO tunnel virtual link). from the link layer (i.e., from the AERO tunnel virtual link).
Packets that enter the AERO interface from the network layer are Packets that enter the AERO interface from the network layer are
encapsulated and forwarded into the AERO link, i.e., they are encapsulated and forwarded into the AERO link, i.e., they are
tunneled to an AERO interface neighbor. Packets that enter the AERO tunneled to an AERO interface neighbor. Packets that enter the AERO
interface from the link layer are either re-admitted into the AERO interface from the link layer are either re-admitted into the AERO
link or forwarded to the network layer where they are subject to link or forwarded to the network layer where they are subject to
either local delivery or IP forwarding. In all cases, the AERO either local delivery or IP forwarding. In all cases, the AERO
interface itself MUST NOT decrement the network layer TTL/Hop-count interface itself MUST NOT decrement the network layer TTL/Hop-count
since its forwarding actions occur below the network layer. since its forwarding actions occur below the network layer.
AERO interfaces may have multiple underlying interfaces and/or AERO interfaces may have multiple underlying interfaces and/or
neighbor cache entries for neighbors with multiple Interface ID neighbor cache entries for neighbors with multiple Interface ID
registrations (see Section 3.5). The AERO node uses each packet's registrations (see Section 3.6). The AERO node uses each packet's
DSCP value to select an outgoing underlying interface based on the DSCP value (and/or port number) to select an outgoing underlying
node's own QoS preferences, and also to select a destination link- interface based on the node's own QoS preferences, and also to select
layer address based on the neighbor's underlying interface with the a destination link-layer address based on the neighbor's underlying
highest preference. AERO implementations SHOULD allow for QoS interface with the highest preference. AERO implementations SHOULD
preference values to be modified at runtime through network allow for QoS preference values to be modified at runtime through
management. network management.
If multiple outgoing interfaces and/or neighbor interfaces have a If multiple outgoing interfaces and/or neighbor interfaces have a
preference of "high", the AERO node sends one copy of the packet via preference of "high", the AERO node sends one copy of the packet via
each of the (outgoing / neighbor) interface pairs; otherwise, the each of the (outgoing / neighbor) interface pairs; otherwise, the
node sends a single copy of the packet via the interface with the node sends a single copy of the packet via the interface with the
highest preference. AERO nodes keep track of which underlying highest preference. AERO nodes keep track of which underlying
interfaces are currently "reachable" or "unreachable", and only use interfaces are currently "reachable" or "unreachable", and only use
"reachable" interfaces for forwarding purposes. "reachable" interfaces for forwarding purposes.
The following sections discuss the AERO interface forwarding The following sections discuss the AERO interface forwarding
algorithms for Clients, Proxies, Servers and Relays. In the algorithms for Clients, Proxies, Servers and Relays. In the
following discussion, a packet's destination address is said to following discussion, a packet's destination address is said to
"match" if it is a non-link-local address with a prefix covered by an "match" if it is a non-link-local address with a prefix covered by an
ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is
the same as an administratively-provisioned AERO address. the same as an administratively-provisioned AERO address.
3.8.1. Client Forwarding Algorithm 3.9.1. Client Forwarding Algorithm
When an IP packet enters a Client's AERO interface from the network When an IP packet enters a Client's AERO interface from the network
layer the Client searches for an asymmetric neighbor cache entry that layer the Client searches for an asymmetric neighbor cache entry that
matches the destination. If there is a match, the Client uses one or matches the destination. If there is a match, the Client uses one or
more "reachable" link-layer addresses in the entry as the link-layer more "reachable" link-layer addresses in the entry as the link-layer
addresses for encapsulation and admits the packet into the AERO link. addresses for encapsulation and admits the packet into the AERO link
Otherwise, the Client uses the link-layer address in a symmetric (if the link-layer address is a SPAN address, the Client instead
neighbor cache entry as the encapsulation address. forwards the packet into the SPAN). If there is no asymmetric
neighbor cache entry, the Client instead uses the link-layer address
in a symmetric neighbor cache entry as the encapsulation address for
interfaces other than Proxyed interfaces. For Proxyed interfaces,
the Client simply forwards the unencapsulated packet to the first-hop
access router.
When an IP packet enters a Client's AERO interface from the link- When an IP packet enters a Client's AERO interface from the link-
layer, if the destination matches one of the Client's ACPs or link- layer, if the destination matches one of the Client's ACPs or link-
local addresses the Client decapsulates the packet and delivers it to local addresses the Client decapsulates the packet and delivers it to
the network layer. Otherwise, the Client drops the packet and MAY the network layer. Otherwise, the Client drops the packet and MAY
return a network-layer ICMP Destination Unreachable message subject return a network-layer ICMP Destination Unreachable message subject
to rate limiting (see: Section 3.13). to rate limiting (see: Section 3.14).
3.8.2. Proxy Forwarding Algorithm 3.9.2. Proxy Forwarding Algorithm
When the Proxy receives a packet from a Client within the secured When the Proxy receives a packet from a Client within the secured
enclave, the Proxy searches for an asymmetric neighbor cache entry enclave, the Proxy searches for an asymmetric neighbor cache entry
that matches the network-layer destination. If there is a match, the that matches the network-layer destination. If there is a match, the
Proxy uses one or more "reachable" link-layer addresses in the entry Proxy uses one or more "reachable" link-layer addresses in the entry
as the destination link-layer addresses for encapsulation and admits as the destination link-layer addresses for encapsulation and admits
the packet into the AERO link. Otherwise, the Proxy uses the link- the packet into the AERO link (if the link-layer address is a SPAN
layer address for one of the Client's Servers as the encapsulation address, the Proxy instead forwards the packet into the SPAN).
address. Otherwise, the Proxy uses the link-layer address for one of the
Client's Servers as the encapsulation address.
When the Proxy receives an encapsulated data packet from outside of When the Proxy receives an encapsulated data packet from outside of
the secured enclave, it searches for a proxy neighbor cache entry the secured enclave, it searches for a proxy neighbor cache entry
that matches the destination. If there is a proxy neighbor cache that matches the destination. If there is a proxy neighbor cache
entry for the target Client, the Proxy forwards the packet according entry for the target Client, the Proxy forwards the packet according
to the cached link-layer address. If the proxy neighbor cache entry to the cached link-layer address. If the proxy neighbor cache entry
is in the DEPARTED state, the Proxy instead forwards the packet to is in the DEPARTED state, the Proxy instead forwards the packet to
the Client's Server and may return an unsolicited NA message as the Client's Server and may return an unsolicited NA message as
discussed in Section 3.18. If there is no neighbor cache entry, the discussed in Section 3.19. If there is no neighbor cache entry, the
Proxy discards the packet. Proxy discards the packet.
3.8.3. Server Forwarding Algorithm 3.9.3. Server Forwarding Algorithm
When an IP packet enters a Server's AERO interface from the network
layer, the Server searches for a symmetric neighbor cache entry for a
Client that matches the destination. If there is a symmetric
neighbor cache entry, the Server uses one or more link-layer
addresses in the entry as the link-layer addresses for encapsulation
and admits the packet into the AERO link. Otherwise, the Server uses
the link-layer address in a permanent neighbor cache entry for a
Relay (selected through longest-prefix match) as the link-layer
address for encapsulation.
When an IP packet enters a Server's AERO interface from the link When an IP packet enters a Server's AERO interface from the link-
layer, the Server processes the packet according to the network-layer layer, it decapsulates the packet and processes it the same as if it
destination address as follows: entered from ethe network layer. The Server then processes the
packet according to the network-layer destination address as follows:
o if the destination matches one of the Server's own addresses the o if the destination matches one of the Server's own addresses the
Server decapsulates the packet and forwards it to the network Server forwards it to the network layer for local delivery.
layer for local delivery.
o else, if the destination matches a symmetric neighbor cache entry o else, if the destination matches a symmetric neighbor cache entry
the Server first determines whether the packet originated from the the Server first determines whether the packet originated from the
same Client. If so, the Server drops the packet silently to avoid same Client. If so, the Server drops the packet silently to avoid
looping. Otherwise, the Server uses the neighbor's link-layer looping. Otherwise, the Server uses the neighboring Client's
address(es) as the destination for encapsulation and re-admits the link-layer address(es) as the destination for encapsulation,
packet into the AERO link. If the neighbor cache entry is in the (re)encapsulates the packet the packet and forwards the packet to
DEPARTED state, the Server continues to forward packets according the Client. If the neighbor cache entry is in the DEPARTED state,
to its most recent underlying interface state and may return an the Server instead continues to forward packets to the Client's
unsolicited NA message as discussed in Section 3.18. new Server (either directly of via the SPAN according to the link-
layer address) as discussed in Section 3.19.
o else, if the destination matches an asymmetric neighbor cache o else, if the destination matches an asymmetric neighbor cache
entry for a target Client, the Server forwards the packet entry for a target Client, the Server forwards the packet
according to the interface ID settings in the asymmetric neighbor according to the link-layer information in the asymmetric neighbor
cache entry. cache entry (either directly or via the SPAN according to the
link-layer address).
o else, the Server uses the link-layer address in a neighbor cache o else, the Server uses the link-layer address in a permanent
entry for a Relay (selected through longest-prefix match) as the neighbor cache entry for a Relay (selected through longest-prefix
link-layer address for encapsulation. match) as the link-layer address for encapsulation.
3.8.4. Relay Forwarding Algorithm 3.9.4. Relay Forwarding Algorithm
Relays forward packets the same as any IP router. When the Relay Relays forward packets the same as any IP router. When the Relay
receives an encapsulated packet from a Server via the AERO link, it receives an encapsulated packet from a Server via the AERO link, it
removes the encapsulation header and searches for a forwarding table removes the encapsulation header and searches for a forwarding table
entry that matches the network layer destination address. When the entry that matches the network layer destination address. When the
Relay receives an unencapsulated packet from a node outside the AERO Relay receives an unencapsulated packet from a node outside the AERO
link, it performs the same forwarding table lookup. The Relay then link, it performs the same forwarding table lookup. The Relay then
processes the packet as follows: processes the packet as follows:
o if the destination does not match an ASP, or if the destination o if the destination does not match an ASP or the SSP, or if the
matches one of the Relay's own addresses, the Relay submits the destination matches one of the Relay's own addresses, the Relay
packet for either IP forwarding or local delivery. submits the packet for either IP forwarding or local delivery.
o else, if the destination matches an ACP entry in the IP forwarding o else, if the destination matches an ASP/SSP entry in the IP
table the Relay first determines whether the neighbor is the same forwarding table the Relay first determines whether the neighbor
as the one it received the packet from. If so the Relay MUST drop is the same as the one it received the packet from. If so the
the packet silently to avoid looping; otherwise, the Relay Relay MUST drop the packet silently to avoid looping; otherwise,
encapsulates and forwards the packet using the neighbor's link- the Relay encapsulates and forwards the packet using the
layer address as the destination for encapsulation. neighbor's link-layer address as the destination for
encapsulation.
o else, the Relay drops the packet and returns an ICMP Destination o else, the Relay drops the packet and returns an ICMP Destination
Unreachable message subject to rate limiting (see: Section 3.13). Unreachable message subject to rate limiting (see: Section 3.14).
As for any IP router, the Relay decrements the TTL/Hop Count when it As for any IP router, the Relay decrements the TTL/Hop Count when it
forwards the packet. forwards the packet.
3.9. AERO Interface Encapsulation and Re-encapsulation 3.10. AERO Interface Encapsulation and Re-encapsulation
AERO interfaces encapsulate IP packets according to whether they are AERO interfaces encapsulate IP packets according to whether they are
entering the AERO interface from the network layer or if they are entering the AERO interface from the network layer or if they are
being re-admitted into the same AERO link they arrived on. This being re-admitted into the same AERO link they arrived on. This
latter form of encapsulation is known as "re-encapsulation". latter form of encapsulation is known as "re-encapsulation".
The AERO interface encapsulates packets per the Generic UDP The AERO interface encapsulates packets per the Generic UDP
Encapsulation (GUE) procedures in Encapsulation (GUE) procedures in
[I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through
an alternate encapsulation format (e.g., see: Appendix A, [RFC2784], an alternate encapsulation format (e.g., see: Appendix A, [RFC2784],
skipping to change at page 25, line 32 skipping to change at page 28, line 47
Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168] Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168]
values in the packet's IP header into the corresponding fields in the values in the packet's IP header into the corresponding fields in the
encapsulation IP header. For packets undergoing re-encapsulation, encapsulation IP header. For packets undergoing re-encapsulation,
the AERO interface instead copies these values from the original the AERO interface instead copies these values from the original
encapsulation IP header into the new encapsulation header, i.e., the encapsulation IP header into the new encapsulation header, i.e., the
values are transferred between encapsulation headers and *not* copied values are transferred between encapsulation headers and *not* copied
from the encapsulated packet's network-layer header. (Note from the encapsulated packet's network-layer header. (Note
especially that by copying the TTL/Hop Limit between encapsulation especially that by copying the TTL/Hop Limit between encapsulation
headers the value will eventually decrement to 0 if there is a headers the value will eventually decrement to 0 if there is a
(temporary) routing loop.) For IPv4 encapsulation/re-encapsulation, (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation,
the AERO interface sets the DF bit as discussed in Section 3.12. the AERO interface sets the DF bit as discussed in Section 3.13.
When GUE encapsulation is used, the AERO interface next sets the UDP When GUE encapsulation is used, the AERO interface next sets the UDP
source port to a constant value that it will use in each successive source port to a constant value that it will use in each successive
packet it sends, and sets the UDP length field to the length of the packet it sends, and sets the UDP length field to the length of the
encapsulated packet plus 8 bytes for the UDP header itself plus the encapsulated packet plus 8 bytes for the UDP header itself plus the
length of the GUE header (or 0 if GUE direct IP encapsulation is length of the GUE header (or 0 if GUE direct IP encapsulation is
used). For packets sent to a Server or Relay, the AERO interface used). For packets sent to a Server or Relay, the AERO interface
sets the UDP destination port to 8060, i.e., the IANA-registered port sets the UDP destination port to 8060, i.e., the IANA-registered port
number for AERO. For packets sent to a Client, the AERO interface number for AERO. For packets sent to a Client, the AERO interface
sets the UDP destination port to the port value stored in the sets the UDP destination port to the port value stored in the
neighbor cache entry for this Client. The AERO interface then either neighbor cache entry for this Client. The AERO interface then either
includes or omits the UDP checksum according to the GUE includes or omits the UDP checksum according to the GUE
specification. specification.
Clients normally use the IP address of the underlying interface as
the encapsulation source address. If the underlying interface does
not have an IP address, however, the Client uses an IP address taken
from an ACP as the encapsulation source address (assuming the node
has some way of injecting the ACP into the underlying network routing
system). For IPv6 addresses, the Client normally uses the ACP Subnet
Router Anycast address [RFC4291].
When GUE encapsulation is not available, encapsulation between When GUE encapsulation is not available, encapsulation between
Servers and Relays can use standard mechanisms such as Generic Servers and Relays can use standard mechanisms such as Generic
Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec
[RFC4301] so that Relays can be standard IP routers with no AERO- [RFC4301] so that Relays can be standard IP routers with no AERO-
specific mechanisms. specific mechanisms.
3.10. AERO Interface Decapsulation 3.11. AERO Interface Decapsulation
AERO interfaces decapsulate packets destined either to the AERO node AERO interfaces decapsulate packets destined either to the AERO node
itself or to a destination reached via an interface other than the itself or to a destination reached via an interface other than the
AERO interface the packet was received on. Decapsulation is per the AERO interface the packet was received on. Decapsulation is per the
procedures specified for the appropriate encapsulation format. procedures specified for the appropriate encapsulation format.
3.11. AERO Interface Data Origin Authentication 3.12. AERO Interface Data Origin Authentication
AERO nodes employ simple data origin authentication procedures for AERO nodes employ simple data origin authentication procedures for
encapsulated packets they receive from other nodes on the AERO link. encapsulated packets they receive from other nodes on the AERO link.
In particular: In particular:
o AERO Relays and Servers accept encapsulated packets with a link- o AERO Relays and Servers accept encapsulated packets with a link-
layer source address that matches a permanent neighbor cache layer source address that matches a permanent neighbor cache
entry. entry.
o AERO Servers accept authentic encapsulated ND messages from o AERO Servers accept authentic encapsulated ND messages from
skipping to change at page 27, line 5 skipping to change at page 30, line 7
o AERO Proxies accept encapsulated packets if there is a proxy o AERO Proxies accept encapsulated packets if there is a proxy
neighbor cache entry that matches the packet's network-layer neighbor cache entry that matches the packet's network-layer
address. address.
Each packet should include a signature that the recipient can use to Each packet should include a signature that the recipient can use to
authenticate the message origin, e.g., as for common VPN systems such authenticate the message origin, e.g., as for common VPN systems such
as OpenVPN [OVPN]. In some environments, however, it may be as OpenVPN [OVPN]. In some environments, however, it may be
sufficient to require signatures only for ND control plane messages sufficient to require signatures only for ND control plane messages
(see: Section 10) and omit signatures for data plane messages. (see: Section 10) and omit signatures for data plane messages.
3.12. AERO Interface Packet Size Issues 3.13. AERO Interface Packet Size Issues
The AERO interface is the node's attachment to the AERO link. The The AERO interface is the node's attachment to the AERO link. The
AERO interface acts as a tunnel ingress when it sends a packet to an AERO interface acts as a tunnel ingress when it sends a packet to an
AERO link neighbor and as a tunnel egress when it receives a packet AERO link neighbor and as a tunnel egress when it receives a packet
from an AERO link neighbor. AERO interfaces observe the packet from an AERO link neighbor. AERO interfaces observe the packet
sizing considerations for tunnels discussed in sizing considerations for tunnels discussed in
[I-D.ietf-intarea-tunnels] and as specified below. [I-D.ietf-intarea-tunnels] and as specified below.
The Internet Protocol expects that IP packets will either be The Internet Protocol expects that IP packets will either be
delivered to the destination or a suitable Packet Too Big (PTB) delivered to the destination or a suitable Packet Too Big (PTB)
message returned to support the process known as IP Path MTU message returned to support the process known as IP Path MTU
Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be Discovery (PMTUD) [RFC1191][RFC8201]. However, PTB messages may be
crafted for malicious purposes such as denial of service, or lost in crafted for malicious purposes such as denial of service, or lost in
the network [RFC2923]. This can be especially problematic for the network [RFC2923]. This can be especially problematic for
tunnels, where a condition known as a PMTUD "black hole" can result. tunnels, where a condition known as a PMTUD "black hole" can result.
For these reasons, AERO interfaces employ operational procedures that For these reasons, AERO interfaces employ operational procedures that
avoid interactions with PMTUD, including the use of fragmentation avoid interactions with PMTUD, including the use of fragmentation
when necessary. when necessary.
AERO interfaces observe two different types of fragmentation. Source AERO interfaces observe two different types of fragmentation. Source
fragmentation occurs when the AERO interface (acting as a tunnel fragmentation occurs when the AERO interface (acting as a tunnel
ingress) fragments the encapsulated packet into multiple fragments ingress) fragments the encapsulated packet into multiple fragments
before admitting each fragment into the tunnel. Network before admitting each fragment into the tunnel. Network
fragmentation occurs when an encapsulated packet admitted into the fragmentation occurs when an encapsulated packet admitted into the
tunnel by the ingress is fragmented by an IPv4 router on the path to tunnel by the ingress is fragmented by an IPv4 router on the path to
the egress. Note that a packet that incurs source fragmentation may the egress. Note that an IPv4 packet that incurs source
also incur network fragmentation. fragmentation may also incur network fragmentation.
IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280
bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU
of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum
for IPv4 even if encapsulated packets may incur network for IPv4 even if encapsulated packets may incur network
fragmentation. fragmentation.
IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes
[RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122]
(note that common IPv6 over IPv4 tunnels already assume a larger MRU (but, note that many standard IPv6 over IPv4 tunnel types already
than the IPv4 minimum). assume a larger MRU than the IPv4 minimum).
AERO interfaces therefore configure an MTU that MUST NOT be smaller AERO interfaces therefore configure an MTU that MUST NOT be smaller
than 1280 bytes, MUST NOT be larger than the minimum MRU among all than 1280 bytes, MUST NOT be larger than the minimum MRU among all
nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), nodes on the AERO link minus the encapsulation overhead ("ENCAPS"),
and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also
configure a Maximum Segment Unit (MSU) as the maximum-sized configure a Maximum Segment Unit (MSU) as the maximum-sized
encapsulated packet that the ingress can inject into the tunnel encapsulated packet that the ingress can inject into the tunnel
without source fragmentation. The MSU value MUST NOT be larger than without source fragmentation. The MSU value MUST NOT be larger than
(MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is
operational assurance that a larger size can traverse the link along operational assurance that a larger size can traverse the link along
all paths. all paths.
All AERO nodes MUST configure the same MTU/MSU values for reasons All AERO nodes MUST configure the same MTU value for reasons cited in
cited in [RFC3819][RFC4861]; in particular, multicast support [RFC3819][RFC4861]; in particular, multicast support requires a
requires a common MTU value among all nodes on the link. All AERO common MTU value among all nodes on the link. All AERO nodes MUST
nodes MUST configure an MRU large enough to reassemble packets up to configure an MRU large enough to reassemble packets up to
(MTU+ENCAPS) bytes in length; nodes that cannot configure a large- (MTU+ENCAPS) bytes in length; nodes that cannot configure a large-
enough MRU MUST NOT enable an AERO interface. enough MRU MUST NOT enable an AERO interface.
The network layer proceeds as follow when it presents an IP packet to The network layer proceeds as follow when it presents an IP packet to
the AERO interface. For each IPv4 packet that is larger than the the AERO interface. For each IPv4 packet that is larger than the
AERO interface MTU and with the DF bit set to 0, the network layer AERO interface MTU and with the DF bit set to 0, the network layer
uses IPv4 fragmentation to break the packet into a minimum number of uses IPv4 fragmentation to break the packet into a minimum number of
non-overlapping fragments where the first fragment is no larger than non-overlapping fragments where the first fragment is no larger than
the MTU and the remaining fragments are no larger than the first. the MTU and the remaining fragments are no larger than the first.
For all other IP packets, if the packet is larger than the AERO For all other IP packets, if the packet is larger than the AERO
skipping to change at page 28, line 40 skipping to change at page 31, line 43
the MSU and the remaining fragments are no larger than the first. the MSU and the remaining fragments are no larger than the first.
The ingress then admits each encapsulated packet or fragment into the The ingress then admits each encapsulated packet or fragment into the
tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation
header in case any network fragmentation is necessary. The header in case any network fragmentation is necessary. The
encapsulated packets will be delivered to the egress, which encapsulated packets will be delivered to the egress, which
reassembles them into a whole packet if necessary. reassembles them into a whole packet if necessary.
Several factors must be considered when fragmentation is needed. For Several factors must be considered when fragmentation is needed. For
AERO links over IPv4, the IP ID field is only 16 bits in length, AERO links over IPv4, the IP ID field is only 16 bits in length,
meaning that fragmentation at high data rates could result in data meaning that fragmentation at high data rates could result in data
corruption due to reassembly misassociations [RFC6864][RFC4963]. For corruption due to reassembly misassociations [RFC6864][RFC4963]. In
AERO links over both IPv4 and IPv6, studies have also shown that IP environments where IP fragmentation issues could result in
fragments are dropped unconditionally over some network paths [I- operational problems, the ingress SHOULD employ intermediate-layer
D.taylor-v6ops-fragdrop]. In environments where IP fragmentation source fragmentation (see: [RFC2764] and
issues could result in operational problems, the ingress SHOULD
employ intermediate-layer source fragmentation (see: [RFC2764] and
[I-D.ietf-intarea-gue-extensions]) before appending the outer [I-D.ietf-intarea-gue-extensions]) before appending the outer
encapsulation headers to each fragment. Since the encapsulation encapsulation headers to each fragment. Since the encapsulation
fragment header reduces the room available for packet data, but the fragment header reduces the room available for packet data, but the
original source has no way to control its insertion, the ingress MUST original source has no way to control its insertion, the ingress MUST
include the fragment header length in the ENCAPS length even for include the fragment header length in the ENCAPS length even for
packets in which the header is absent. packets in which the header is absent.
3.13. AERO Interface Error Handling 3.14. AERO Interface Error Handling
When an AERO node admits encapsulated packets into the AERO When an AERO node admits encapsulated packets into the AERO
interface, it may receive link-layer or network-layer error interface, it may receive link-layer or network-layer error
indications. indications.
A link-layer error indication is an ICMP error message generated by a A link-layer error indication is an ICMP error message generated by a
router in the underlying network on the path to the neighbor or by router in the underlying network on the path to the neighbor or by
the neighbor itself. The message includes an IP header with the the neighbor itself. The message includes an IP header with the
address of the node that generated the error as the source address address of the node that generated the error as the source address
and with the link-layer address of the AERO node as the destination and with the link-layer address of the AERO node as the destination
address. address.
The IP header is followed by an ICMP header that includes an error The IP header is followed by an ICMP header that includes an error
Type, Code and Checksum. Valid type values include "Destination Type, Code and Checksum. Valid type values include "Destination
Unreachable", "Time Exceeded" and "Parameter Problem" Unreachable", "Time Exceeded" and "Parameter Problem"
[RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4
"Fragmentation Needed" and IPv6 "Packet Too Big" messages since they "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they
only emit packets that are guaranteed to be no larger than the IP only emit packets that are guaranteed to be no larger than the IP
minimum link MTU as discussed in Section 3.12.) minimum link MTU as discussed in Section 3.13.)
The ICMP header is followed by the leading portion of the packet that The ICMP header is followed by the leading portion of the packet that
generated the error, also known as the "packet-in-error". For generated the error, also known as the "packet-in-error". For
ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As
much of invoking packet as possible without the ICMPv6 packet much of invoking packet as possible without the ICMPv6 packet
exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For
ICMPv4, [RFC0792] specifies that the packet-in-error includes: ICMPv4, [RFC0792] specifies that the packet-in-error includes:
"Internet Header + 64 bits of Original Data Datagram", however "Internet Header + 64 bits of Original Data Datagram", however
[RFC1812] Section 4.3.2.3 updates this specification by stating: "the [RFC1812] Section 4.3.2.3 updates this specification by stating: "the
ICMP datagram SHOULD contain as much of the original datagram as ICMP datagram SHOULD contain as much of the original datagram as
possible without the length of the ICMP datagram exceeding 576 possible without the length of the ICMP datagram exceeding 576
bytes". bytes".
The link-layer error message format is shown in Figure 3 (where, "L2" The link-layer error message format is shown in Figure 4 (where, "L2"
and "L3" refer to link-layer and network-layer, respectively): and "L3" refer to link-layer and network-layer, respectively):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| L2 IP Header of | | L2 IP Header of |
| error message | | error message |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2 ICMP Header | | L2 ICMP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
skipping to change at page 30, line 30 skipping to change at page 33, line 30
| original L3 packet | i | original L3 packet | i
~ ~ n ~ ~ n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ e ~ ~ e
| Upper layer headers and | r | Upper layer headers and | r
| leading portion of body | r | leading portion of body | r
| of the original L3 packet | o | of the original L3 packet | o
~ ~ r ~ ~ r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 3: AERO Interface Link-Layer Error Message Format Figure 4: AERO Interface Link-Layer Error Message Format
The AERO node rules for processing these link-layer error messages The AERO node rules for processing these link-layer error messages
are as follows: are as follows:
o When an AERO node receives a link-layer Parameter Problem message, o When an AERO node receives a link-layer Parameter Problem message,
it processes the message the same as described as for ordinary it processes the message the same as described as for ordinary
ICMP errors in the normative references [RFC0792][RFC4443]. ICMP errors in the normative references [RFC0792][RFC4443].
o When an AERO node receives persistent link-layer Time Exceeded o When an AERO node receives persistent link-layer Time Exceeded
messages, the IP ID field may be wrapping before earlier fragments messages, the IP ID field may be wrapping before earlier fragments
skipping to change at page 31, line 13 skipping to change at page 34, line 13
SHOULD set ReachableTime for the corresponding asymmetric neighbor SHOULD set ReachableTime for the corresponding asymmetric neighbor
cache entry to 0 and allow future packets destined to the cache entry to 0 and allow future packets destined to the
correspondent to flow through a default route. correspondent to flow through a default route.
o When an AERO Client receives persistent link-layer Destination o When an AERO Client receives persistent link-layer Destination
Unreachable messages in response to encapsulated packets that it Unreachable messages in response to encapsulated packets that it
sends to one of its symmetric neighbor Servers, the Client SHOULD sends to one of its symmetric neighbor Servers, the Client SHOULD
mark the path as unusable and use another path. If it receives mark the path as unusable and use another path. If it receives
Destination Unreachable messages on many or all paths, the Client Destination Unreachable messages on many or all paths, the Client
SHOULD associate with a new Server and release its association SHOULD associate with a new Server and release its association
with the old Server as specified in Section 3.18.7. with the old Server as specified in Section 3.19.7.
o When an AERO Server receives persistent link-layer Destination o When an AERO Server receives persistent link-layer Destination
Unreachable messages in response to encapsulated packets that it Unreachable messages in response to encapsulated packets that it
sends to one of its symmetric neighbor Clients, the Server SHOULD sends to one of its symmetric neighbor Clients, the Server SHOULD
mark the underlying path as unusable and use another underlying mark the underlying path as unusable and use another underlying
path. If it receives Destination Unreachable messages on multiple path. If it receives Destination Unreachable messages on multiple
paths, the Server should take no further actions unless it paths, the Server should take no further actions unless it
receives an explicit ND/PD release message or if the PD lifetime receives an explicit ND/PD release message or if the PD lifetime
expires. In that case, the Server MUST release the Client's expires. In that case, the Server MUST release the Client's
delegated ACP, withdraw the ACP from the AERO routing system and delegated ACP, withdraw the ACP from the AERO routing system and
skipping to change at page 32, line 5 skipping to change at page 35, line 5
message. message.
When an AERO node receives an encapsulated packet for which the When an AERO node receives an encapsulated packet for which the
reassembly buffer it too small, it drops the packet and returns a reassembly buffer it too small, it drops the packet and returns a
network-layer Packet Too Big (PTB) message. The node first writes network-layer Packet Too Big (PTB) message. The node first writes
the MRU value into the PTB message MTU field, writes the network- the MRU value into the PTB message MTU field, writes the network-
layer source address of the original packet as the destination layer source address of the original packet as the destination
address and writes one of its non link-local addresses as the source address and writes one of its non link-local addresses as the source
address. address.
3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 3.15. AERO Router Discovery, Prefix Delegation and Autoconfiguration
AERO Router Discovery, Prefix Delegation and Autoconfiguration are AERO Router Discovery, Prefix Delegation and Autoconfiguration are
coordinated as discussed in the following Sections. coordinated as discussed in the following Sections.
3.14.1. AERO ND/PD Service Model 3.15.1. AERO ND/PD Service Model
Each AERO Server configures a PD service to facilitate Client Each AERO Server configures a PD service to facilitate Client
requests. Each Server is provisioned with a database of ACP-to- requests. Each Server is provisioned with a database of ACP-to-
Client ID mappings for all Clients enrolled in the AERO system, as Client ID mappings for all Clients enrolled in the AERO system, as
well as any information necessary to authenticate each Client. The well as any information necessary to authenticate each Client. The
Client database is maintained by a central administrative authority Client database is maintained by a central administrative authority
for the AERO link and securely distributed to all Servers, e.g., via for the AERO link and securely distributed to all Servers, e.g., via
the Lightweight Directory Access Protocol (LDAP) [RFC4511], via the Lightweight Directory Access Protocol (LDAP) [RFC4511], via
static configuration, etc. Therefore, no Server-to-Server PD state static configuration, etc. Therefore, no Server-to-Server PD state
synchronization is necessary, and Clients can optionally hold synchronization is necessary, and Clients can optionally hold
skipping to change at page 33, line 10 skipping to change at page 36, line 10
those cases, AERO nodes can use simple RS/RA message exchanges with those cases, AERO nodes can use simple RS/RA message exchanges with
no PD options. In other cases, the RS/RA messages can use AERO no PD options. In other cases, the RS/RA messages can use AERO
addresses as a means of representing the delegated prefixes, e.g., if addresses as a means of representing the delegated prefixes, e.g., if
a message includes a source address of "fe80::2001:db8:1:2" then the a message includes a source address of "fe80::2001:db8:1:2" then the
recipient can infer that the sender holds the prefix delegation recipient can infer that the sender holds the prefix delegation
"2001:db8:1:2::/N" (where 'N' is the Prefix Length included in the "2001:db8:1:2::/N" (where 'N' is the Prefix Length included in the
first SLLAO in the message). first SLLAO in the message).
The following sections specify the Client and Server behavior. The following sections specify the Client and Server behavior.
3.14.2. AERO Client Behavior 3.15.2. AERO Client Behavior
AERO Clients discover the link-layer addresses of AERO Servers in the AERO Clients can discover the link-layer and AERO addresses of AERO
MAP list via static configuration (e.g., from a flat-file map of Servers in the MAP list via static configuration (e.g., from a flat-
Server addresses and locations), or through an automated means such file map of Server addresses and locations), or through an automated
as Domain Name System (DNS) name resolution [RFC1035]. In the means such as Domain Name System (DNS) name resolution [RFC1035]. In
absence of other information, the Client resolves the DNS Fully- the absence of other information, the Client resolves the DNS Fully-
Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" where Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" where
"linkupnetworks" is a constant text string and "[domainname]" is a "linkupnetworks" is a constant text string and "[domainname]" is a
DNS suffix for the Client's underlying interface (e.g., DNS suffix for the Client's underlying interface (e.g.,
"example.com"). After discovering the link-layer addresses, the "example.com"). After discovering the link-layer addresses, the
Client associates with one or more of the corresponding Servers. Client associates with one or more of the corresponding Servers.
To associate with a Server, the Client acts as a requesting router to To associate with a Server, the Client acts as a requesting router to
request ACPs. The Client prepares an RS message with PD parameters request ACPs. The Client prepares an RS message with PD parameters
(e.g., with an SLLAO with non-zero Prefix Length), the address of the (e.g., with an SLLAO with non-zero Prefix Length), the address of the
Client's underlying interface as the link-layer source address and Client's underlying interface as the link-layer source address and
the link-layer address of the Server as the link-layer destination the link-layer address of the Server as the link-layer destination
address. If the Client already knows its own AERO address, it uses address. If the Client already knows the Server's AERO address, it
the AERO address as the network-layer source address; otherwise, it includes the AERO address as the network-layer destination address;
uses the unspecified AERO address (fe80::ffff:ffff) as the network- otherwise, it includes all-routers multicast (ff02::2) as the
layer source address. If the Client's underlying interface connects network-layer destination address. If the Client already knows its
to a subnetwork that supports ACP injection, the Client can use the own AERO address, it uses the AERO address as the network-layer
ACP's Subnet Router Anycast address as the link-layer source address. source address; otherwise, it uses the unspecified AERO address
(fe80::ffff:ffff) as the network-layer source address.
The Client next includes an SLLAO in the RS message formatted as The Client next includes an SLLAO in the RS message formatted as
described in Section 3.5 to register its link-layer address with the described in Section 3.6 to register its link-layer address with the
Server. The first SLLAO MUST correspond to the underlying interface Server. The first SLLAO MUST correspond to the underlying interface
over which the Client will send the RS message. The Client MAY over which the Client will send the RS message. The Client MAY
include additional SLLAOs specific to other underlying interfaces, include additional SLLAOs specific to other underlying interfaces,
but if so it sets their UDP Port Number and IP Address fields to 0. but if so it sets their Port Number and Link Layer Address fields to
0.
The Client then sends the RS message to the AERO Server and waits for The Client then sends the RS message (either via a VPN for VPNed
an RA message reply (see Section 3.14.3) while retrying up to interfaces, via a Proxy for proxyed interfaces or via the SPAN for
MAX_RTR_SOLICITATIONS times until an RA is received. If the Client native interfaces) and waits for an RA message reply (see
receives no RAs, or if it receives an RA with Router Lifetime set to Section 3.15.3) while retrying up to MAX_RTR_SOLICITATIONS times
0, the Client SHOULD abandon this Server and try another Server. until an RA is received. If the Client receives no RAs, or if it
Otherwise, the Client processes the PD information found in the RA receives an RA with Router Lifetime set to 0, the Client SHOULD
message. abandon this Server and try another Server. Otherwise, the Client
processes the PD information found in the RA message.
Next, the Client creates a symmetric neighbor cache entry with the Next, the Client creates a symmetric neighbor cache entry with the
Server's link-local address as the network-layer address and the Server's AERO address as the network-layer address and the address in
address in the first SLLAO as the link-layer address. The Client the first SLLAO as the link-layer address. The Client records the RA
records the RA Router Lifetime field value in the cache entry as the Router Lifetime field value in the cache entry as the time for which
time for which the Server has committed to maintaining the ACP in the the Server has committed to maintaining the ACP in the routing
routing system. The Client then autoconfigures AERO addresses for system. The Client then autoconfigures AERO addresses for each of
each of the delegated ACPs and assigns them to the AERO interface. the delegated ACPs and assigns them to the AERO interface. The
The Client also caches any ASPs included in Route Information Options Client also caches any ASPs included in Route Information Options
(RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns
the MTU/MSU values in the MTU options to its AERO interface while the MTU value in the MTU option to its AERO interface while
configuring an appropriate MRU. This configuration information configuring an appropriate MRU. This configuration information
applies to the AERO link as a whole, and all AERO nodes will receive applies to the AERO link as a whole, and all AERO nodes will receive
the same values. the same values.
The Client then registers additional link-layer addresses with the The Client then registers additional link-layer addresses with the
Server by sending additional RS messages including SLLAOs via other Server by sending additional RS messages including SLLAOs via other
underlying interfaces after the initial RS/RA exchange. The Client underlying interfaces after the initial RS/RA exchange. The Client
omits PD parameters from these additional messages, since the initial sends the RS messages to the Server's AERO address (discovered in the
RS/RA exchange has already established PD state. The Client examines initial RS/RA exchange), but omits PD parameters since the initial
the X and N bits in the first SLLAO of each RA message. If the X bit RS/RA exchange has already established PD state.
value is '1' the Client infers that there is a Proxy on the path via
the interface over which it sent the RS message, and if the N bit The Client examines the X and N bits in the first SLLAO of each RA
value is '1' the Client infers that there is a NAT on the path. If N message it receives. If the X bit value is '1' the Client infers
is '1', the Client SHOULD set UDP Port Number and IP Address to 0 in that there is a Proxy on the path via the interface over which it
the first S/TLLAO of any subsequent ND messages it sends to the sent the RS message, and if the N bit value is '1' the Client infers
Server over that link. that there is a NAT on the path. If N is '1', the Client SHOULD set
Port Number and Link-Layer Address to 0 in the first S/TLLAO of any
subsequent ND messages it sends to the Server over that link.
Following autoconfiguration, the Client sub-delegates the ACPs to its Following autoconfiguration, the Client sub-delegates the ACPs to its
attached EUNs and/or the Client's own internal virtual interfaces as attached EUNs and/or the Client's own internal virtual interfaces as
described in [I-D.templin-v6ops-pdhost] to support the Client's described in [I-D.templin-v6ops-pdhost] to support the Client's
downstream attached "Internet of Things (IoT)". The Client downstream attached "Internet of Things (IoT)". The Client
subsequently maintains its ACP delegations through each of its subsequently maintains its ACP delegations through each of its
Servers by sending additional RS messages with PD parameters before Servers by sending additional RS messages with PD parameters before
Router Lifetime expires. Router Lifetime expires.
After the Client registers its Interface IDs and their associated After the Client registers its Interface IDs and their associated
UDP/IP addresses and 'P(i)' values, it may wish to change one or more port numbers, link-layer addresses and 'P(i)' values, it may wish to
Interface ID registrations, e.g., if an underlying interface changes change one or more Interface ID registrations, e.g., if an underlying
address or becomes unavailable, if QoS preferences change, etc. To interface changes address or becomes unavailable, if QoS preferences
do so, the Client prepares an RS message to send over any available change, etc. To do so, the Client prepares an RS message to send
underlying interface. The RS MUST include an SLLAO specific to the over any available underlying interface. The RS MUST include an
selected available underlying interface as the first SLLAO and MAY SLLAO specific to the selected available underlying interface as the
include any additional SLLAOs specific to other underlying first SLLAO and MAY include any additional SLLAOs specific to other
interfaces. The Client includes fresh 'P(i)' values in each SLLAO to underlying interfaces. The Client includes fresh 'P(i)' values in
update the Server's neighbor cache entry. If the Client wishes to each SLLAO to update the Server's neighbor cache entry. If the
update 'P(i)' values without updating the link-layer address, it sets Client wishes to update 'P(i)' values without updating the link-layer
the UDP Port Number and IP Address fields to 0. If the Client wishes address, it sets the Port Number and Link-Layer Address fields to 0.
to disable the underlying interface, it sets the 'D' bit to 1. When If the Client wishes to disable the underlying interface, it sets the
the Client receives the Server's RA response, it has assurance that 'D' bit to 1. When the Client receives the Server's RA response, it
the Server has been updated with the new information. has assurance that the Server has been updated with the new
information.
If the Client wishes to associate with multiple Servers, it repeats If the Client wishes to associate with multiple Servers, it repeats
the same procedures above for each additional Server. If the Client the same procedures above for each additional Server. If the Client
wishes to discontinue use of a Server it issues an RS message over wishes to discontinue use of a Server it issues an RS message over
any underlying interface with the 'R' bit set to 1 in the first any underlying interface with the 'R' bit set to 1 in the first
SLLAO. When the Server processes the message, it releases the ACP, SLLAO. When the Server processes the message, it releases the ACP,
sets the symmetric neighbor cache entry state for the Client to sets the symmetric neighbor cache entry state for the Client to
DEPARTED, withdraws the IP route from the routing system and returns DEPARTED, withdraws the IP route from the routing system and returns
RA replies with Router Lifetime set to 0. an RA reply with Router Lifetime set to 0.
3.14.3. AERO Server Behavior 3.15.3. AERO Server Behavior
AERO Servers act as IPv6 routers and support a PD service for AERO Servers act as IPv6 routers and support a PD service for
Clients. AERO Servers arrange to add their encapsulation layer IP Clients. AERO Servers arrange to add their link-layer and AERO
addresses (i.e., their link-layer addresses) to a static map of address to a static map of Server addresses for the link and/or the
Server addresses for the link and/or the DNS resource records for the DNS resource records for the FQDN "linkupnetworks.[domainname]"
FQDN "linkupnetworks.[domainname]" before entering service. The list before entering service. The list of Server addresses should be
of Server addresses should be geographically and/or topologically geographically and/or topologically referenced, and forms the MAP
referenced, and forms the MAP list for the AERO link. list for the AERO link.
When an AERO Server receives a prospective Client's RS message with When an AERO Server receives a prospective Client's RS message with
PD parameters on its AERO interface, it SHOULD return an immediate RA PD parameters on its AERO interface, it SHOULD return an immediate RA
reply with Router Lifetime set to 0 if it is currently too busy or reply with Router Lifetime set to 0 if it is currently too busy or
otherwise unable to service the Client. Otherwise, the Server otherwise unable to service the Client. Otherwise, the Server
authenticates the RS message and processes the PD parameters. The authenticates the RS message and processes the PD parameters. The
Server first determines the correct ACPs to delegate to the Client by Server first determines the correct ACPs to delegate to the Client by
searching the Client database. When the Server delegates the ACPs, searching the Client database. When the Server delegates the ACPs,
it also creates an IP forwarding table entry for each ACP so that the it also creates an IP forwarding table entry for each ACP so that the
AERO BGP-based routing system will propagate the ACPs to the Relays AERO BGP-based routing system will propagate the ACPs to the Relays
that aggregate the corresponding ASP (see: Section 3.3). that aggregate the corresponding ASP (see: Section 3.3).
The Server next creates a symmetric neighbor cache entry for the The Server next creates a symmetric neighbor cache entry for the
Client using the base AERO address as the network-layer address and Client using the base AERO address as the network-layer address and
with lifetime set to no more than the smallest PD lifetime. Next, with lifetime set to no more than the smallest PD lifetime. Next,
the Server updates the neighbor cache entry link-layer address(es) by the Server updates the neighbor cache entry link-layer address(es) by
recording the information in each SLLAO in the RS indexed by the recording the information in each SLLAO in the RS indexed by the
Interface ID and including the UDP port number, IP address and P(i) Interface ID and including the Port Number, Link Layer Address and
values. For the first SLLAO in the list, however, the Server records P(i) values. For the first SLLAO in the list, however, the Server
the actual encapsulation source UDP and IP addresses instead of those records the actual encapsulation source addresses instead of those
that appear in the SLLAO in case there was a NAT in the path. The that appear in the SLLAO in case there was a NAT in the path. The
Server also records the value of the X bit to indicate whether there Server also records the value of the X bit to indicate whether there
is a Proxy on the path. is a Proxy on the path.
Next, the Server prepares an RA message that includes the delegated Next, the Server prepares an RA message that includes the delegated
ACPs, any other PD parameters and an SLLAO with the Server's link- ACPs, any other PD parameters and an SLLAO with the Server's link-
layer address and with Interface ID set to 255. The Server uses its layer address and with Interface ID set to 255. The Server uses its
link-local address as the network-layer source address, the network- AERO address as the network-layer source address, the network-layer
layer source address of the RS message as the network-layer source address of the RS message as the network-layer destination
destination address, the Server's link-layer address as the source address, the Server's link-layer address as the source link-layer
link-layer address, and the source link-layer address of the RS address, and the source link-layer address of the RS message as the
message as the destination link-layer address. The Server next sets destination link-layer address. The Server next sets the N flag to 1
the N flag to 1 if the source link-layer address in the RS message if the source link-layer address in the RS message was different than
was different than the address in the first SLLAO to indicate that the address in the first SLLAO to indicate that there is a NAT on the
there is a NAT on the path. The Server then includes one or more path. The Server then includes one or more RIOs that encode the ASPs
RIOs that encode the ASPs for the AERO link. The Server also for the AERO link. The Server also includes an MTU option for the
includes two MTU options - the first MTU option includes the MTU for MTU for the link (see Section 3.13). The Server finally sends the RA
the link and the second MTU option includes the MSU for the link (see message to the Client via the SPAN.
Section 3.12). The Server finally sends the RA message to the
Client.
After the initial RS/RA exchange, the AERO Server maintains the After the initial RS/RA exchange, the AERO Server maintains the
symmetric neighbor cache entry for the Client. If the Client (or symmetric neighbor cache entry for the Client. If the Client (or
Proxy) issues additional NS/RS messages, the Server resets Proxy) issues additional NS/RS messages, the Server resets
ReachableTime. If the Client (or Proxy) issues an RS with PD release ReachableTime. If the Client (or Proxy) issues an RS with PD release
parameters (e.g., by including an SLLAO with R set to 1), or if the parameters (e.g., by including an SLLAO with R set to 1), or if the
Client becomes unreachable, the Server sets the Client's symmetric Client becomes unreachable, the Server sets the Client's symmetric
neighbor cache entry to the DEPARTED state and withdraws the IP neighbor cache entry to the DEPARTED state and withdraws the IP
routes from the AERO routing system. routes from the AERO routing system.
The Server processes these and any other Client ND/PD messages, and The Server processes these and any other Client ND/PD messages, and
returns an NA/RA reply. The Server may also issue an unsolicited RA returns an NA/RA reply. The Server may also issue an unsolicited RA
message with PD reconfigure parameters to cause the Client to message with PD reconfigure parameters to cause the Client to
renegotiate its PDs, and may issue an unsolicited RA message with renegotiate its PDs, and may issue an unsolicited RA message with
Router Lifetime set to 0 if it can no longer service this Client. Router Lifetime set to 0 if it can no longer service this Client.
Finally, If the symmetric neighbor cache entry is in the DEPARTED Finally, If the symmetric neighbor cache entry is in the DEPARTED
state, the Server deletes the entry after DepartTime expires. state, the Server deletes the entry after DepartTime expires.
3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA)
When DHCPv6 is used as the ND/PD service back end, AERO Clients and When DHCPv6 is used as the ND/PD service back end, AERO Clients and
Servers are always on the same link (i.e., the AERO link) from the Servers are always on the same link (i.e., the AERO link) from the
perspective of DHCPv6. However, in some implementations the DHCPv6 perspective of DHCPv6. However, in some implementations the DHCPv6
server and ND function may be located in separate modules. In that server and ND function may be located in separate modules. In that
case, the Server's AERO interface module can act as a Lightweight case, the Server's AERO interface module can act as a Lightweight
DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from
the DHCPv6 server module. the DHCPv6 server module.
When the LDRA receives an authentic RS message, it extracts the PD When the LDRA receives an authentic RS message, it extracts the PD
skipping to change at page 37, line 18 skipping to change at page 40, line 22
When the DHCPv6 server prepares a Reply message, it wraps the message When the DHCPv6 server prepares a Reply message, it wraps the message
in a 'Relay-Reply' message and echoes the Interface-Id option. The in a 'Relay-Reply' message and echoes the Interface-Id option. The
DHCPv6 server then delivers the Relay-Reply message to the LDRA, DHCPv6 server then delivers the Relay-Reply message to the LDRA,
which discards the Relay-Reply wrapper and IPv6/UDP headers, then which discards the Relay-Reply wrapper and IPv6/UDP headers, then
uses the DHCPv6 message to construct an RA response to the Client. uses the DHCPv6 message to construct an RA response to the Client.
The Server uses the information in the Interface-Id option to prepare The Server uses the information in the Interface-Id option to prepare
the RA message and to cache the link-layer addresses taken from the the RA message and to cache the link-layer addresses taken from the
SLLAOs echoed in the Interface-Id option. SLLAOs echoed in the Interface-Id option.
3.15. The AERO Proxy 3.16. The AERO Proxy
In some environments, Clients may be located in secured subnetwork In some environments, Clients may be located in secured enclaves that
enclaves that do not allow direct communications from the Client to a do not allow direct communications from the Client to a Server in the
Server in the outside Internetwork. In that case, the secured outside Internetwork. In that case, the secured enclave can employ
enclave can employ an AERO Proxy. an AERO Proxy.
The Proxy is located at the secured enclave perimeter and listens for The Proxy is located at the secured enclave perimeter and listens for
encapsulated RS messages originating from or RA messages destined to encapsulated RS messages originating from or RA messages destined to
Clients located within the enclave. The Proxy acts on these control Clients located within the enclave. The Proxy acts on these control
messages as follows: messages as follows:
o when the Proxy receives an RS message from a new Client within the o when the Proxy receives an RS message from a new Client within the
secured enclave, it first authenticates the message then creates a secured enclave, it first authenticates the message then examines
proxy neighbor cache entry and caches the Client and Server link- the RS message network-layer destination address. If the
layer addresses along with any identifying information including destination address is a Server's AERO address, the Proxy proceeds
to the next step. Otherwise, if the destination is all-routers
multicast the Proxy selects a "nearby" Server that is likely to be
a good candidate to serve the Client and replaces the RS
destination address with the AERO address of the Server.
(Otherwise, the Proxy discards the RS.) Next, the Proxy creates a
proxy neighbor cache entry and caches the Client and Server
addresses along with any identifying information including
Transaction IDs, Client Identifiers, Nonce values, etc. The Proxy Transaction IDs, Client Identifiers, Nonce values, etc. The Proxy
then examines the address in the first SLLAO of the RS message. then examines the address in the first SLLAO of the RS message.
If the address is different than the Client link-layer address, If the address is different than the Client link-layer address,
the Proxy notes that the Client is behind a NAT. The Proxy then the Proxy notes that the Client is behind a NAT. The Proxy then
re-encapsulates the RS message using its own external address as re-encapsulates the RS message using its own external address as
the source link-layer address, sets the X flag in the first SLLAO the source link-layer address, sets the X flag in the first SLLAO
to '1', changes the address in the first SLLAO to its own external to '1', changes the address in the first SLLAO to its own external
address, and forwards the message to the Server. address, and forwards the message to the Server via the SPAN.
o when the Server receives the RS message, it authenticates the o when the Server receives the RS message, it authenticates the
message then creates or updates a symmetric neighbor cache entry message then creates or updates a symmetric neighbor cache entry
for the Client with the Proxy's address as the link-layer address. for the Client with the Proxy's address as the link-layer address.
The Server then sends an RA message back to the Proxy. The Server then sends an RA message back to the Proxy via the
SPAN.
o when the Proxy receives the RA message, it matches the message o when the Proxy receives the RA message, it matches the message
with the RS that created the proxy neighbor cache entry. The with the RS that created the proxy neighbor cache entry. The
Proxy then caches the route information in the message as a Proxy then caches the route information in the message as a
mapping from the Client's ACPs to the Client's address within the mapping from the Client's ACPs to the Client's address within the
secured enclave, and sets the neighbor cache entry state to secured enclave, and sets the neighbor cache entry state to
REACHABLE. The Proxy then re-encapsulates the RA message using REACHABLE. The Proxy then re-encapsulates the RA message using
its own internal address as the source link-layer address, sets its own internal address as the source link-layer address, sets
the X flag in the first SLLAO to '1', sets the N flag in the first the X flag in the first SLLAO to '1', sets the N flag in the first
SLLAO to '1' if the Client is behind a NAT, and forwards the SLLAO to '1' if the Client is behind a NAT, and forwards the
skipping to change at page 38, line 20 skipping to change at page 41, line 31
After the initial RS/RA exchange, the Proxy forwards any Client data After the initial RS/RA exchange, the Proxy forwards any Client data
packets for which there is no matching asymmetric neighbor cache packets for which there is no matching asymmetric neighbor cache
entry to the "eldest" of the Client's Servers, i.e., the first among entry to the "eldest" of the Client's Servers, i.e., the first among
possibly multiple Servers selected by the Client. If the eldest possibly multiple Servers selected by the Client. If the eldest
Server becomes unreachable, the Proxy sends future data packets via Server becomes unreachable, the Proxy sends future data packets via
the next-eldest Server, etc. Finally, the Proxy forwards any Client the next-eldest Server, etc. Finally, the Proxy forwards any Client
data destined to an asymmetric neighbor cache target directly to the data destined to an asymmetric neighbor cache target directly to the
target according to the link-layer information - the process of target according to the link-layer information - the process of
establishing asymmetric neighbor cache entries is specified in establishing asymmetric neighbor cache entries is specified in
Section 3.16. Section 3.17.
While the Client is still active, the Proxy continues to send NS/RS While the Client is still active, the Proxy continues to send NS/RS
messages to update each Server's symmetric neighbor cache entries on messages to update each Server's symmetric neighbor cache entries on
behalf of the Client according to Neighbor Unreachability Detection behalf of the Client and/or to convey QoS updates. If the Server
(NUD) and/or to convey QoS updates. If the Server ceases to send ceases to send solicited NA/RA responses, the Proxy marks the Server
solicited NA/RA responses, the Proxy marks the Server as unreachable as unreachable and sends an unsolicited RA to the Client with Router
and sends an unsolicited RA to the Client with Router Lifetime set to Lifetime set to zero so that the Client knows that this Server is no
zero so that the Client knows that this Server is no longer able to longer able to provide Service. If the Client becomes unreachable,
provide Service. If the Client becomes unreachable, the Proxy sets the Proxy sets the neighbor cache entry state to DEPARTED and sends
the neighbor cache entry state to DEPARTED and sends an RS message to an RS message to each Server with an SLLAO with the 'D' bit set to 1
each Server with an SLLAO with the 'D' bit set to 1 and with and with Interface ID set to the Client's interface ID so that the
Interface ID set to the Client's interface ID so that the Server will Server will de-register this Interface ID. Although the Proxy
de-register this Interface ID. Although the Proxy engages in these engages in these ND exchanges on behalf of the Client, the Client can
ND exchanges on behalf of the Client, the Client can also send ND also send ND messages on its own behalf, e.g., if it is in a better
messages on its own behalf, e.g., if it is in a better position than position than the Proxy to convey QoS changes, etc.
the Proxy to convey QoS changes, etc.
In some subnetworks that employ a Proxy, the Client's ACP can be In some subnetworks that employ a Proxy, the Client's ACP can be
injected into the underlying network routing system. In that case, injected into the underlying network routing system. In that case,
the Client can send data messages without encapsulation so that the the Client can send data messages without encapsulation so that the
native underlying network routing system transports the native underlying network routing system transports the
unencapsulated packets to the Proxy. This can be very beneficial, unencapsulated packets to the Proxy. This can be very beneficial,
e.g., if the Client connects to the network via low-end data links e.g., if the Client connects to the network via low-end data links
such as some aviation wireless links. In that case, however, the such as some aviation wireless links. In that case, however, the
Client's control messages are still sent encapsulated so as to supply Client's control messages are still sent encapsulated so as to supply
the Proxy with the address of the Server and to transport IPv6 ND the Proxy with the address of the Server and to transport IPv6 ND
messages without decrementing the hop-count. In summary, the messages without decrementing the hop-count. In summary, the
interface becomes one where control messages are encapsulated while interface becomes one where control messages are encapsulated while
data messages are either unencapsulated or encapsulated according to data messages are either unencapsulated or encapsulated according to
the specific use case. This encapsulation avoidance represents a the specific use case. This encapsulation avoidance represents a
form of "header compression", meaning that the MTU should be sized form of "header compression", meaning that the MTU should be sized
based on the size of full encapsulated messages even if most messages based on the size of full encapsulated messages even if most messages
are sent unencapsulated. are sent unencapsulated.
3.15.1. The AERO-Aware Access Router 3.16.1. The AERO-Aware Access Router
If the Client is aware that its data link interface connects to a If the Client is aware that its data link interface connects to a
Proxyed domain with an AERO-aware Access Router as the first-hop secured enclave with an AERO-aware Access Router as the first-hop
router, it can avoid encapsulation for its control messages as well router, it can avoid encapsulation for its control messages as well
as its data messages. When the Client comes onto the link, it can as its data messages. When the Client comes onto the link, it can
send an unencapsulated RS message with source address set to its AERO send an unencapsulated RS message with source address set to its AERO
address and with destination address set to the link-layer address of address and with destination address set to the AERO address of the
the Client's selected Server. If the Server is on an IPv6 network, Client's selected Server or to all-routers multicast.
the destination address is set to the Server's public IPv6 address.
If the Server is on an IPv4 network, the destination address is set
to the IPv4-mapped AERO address (For example, if the Server's address
is 192.0.2.1 then the IPv4-mapped AERO address is
fe80::FFFF:192.0.2.1.)
The Client includes an SLLAO with Interface ID, Prefix Length and The Client includes an SLLAO with Interface ID, Prefix Length and
P(i) information but with UDP Port Number and IP Address set to 0. P(i) information but with Port Number and Link-Layer Address set to
The Client then sends the unencapsulated RS message, which will be 0. The Client then sends the unencapsulated RS message, which will
intercepted by the on-link AERO-Aware Access Router. The Access be intercepted by the on-link AERO-Aware Access Router. The Access
Router then encapsulates the RS message in an outer header with its Router then encapsulates the RS message in an outer header with its
own address as the source address and the address of a Proxy as the own address as the source address and the address of a Proxy as the
destination address. The Access Router further remembers the address destination address. The Access Router further remembers the address
of the Proxy so that it can encapsulate future data packets from the of the Proxy so that it can encapsulate future data packets from the
Client via the same Proxy. If the Access Router needs to change to a Client via the same Proxy. If the Access Router needs to change to a
new Proxy, it simply sends another RS message toward the Server via new Proxy, it simply sends another RS message toward the Server via
the new Proxy on behalf of the Client. the new Proxy on behalf of the Client.
In this arrangement, the only control messages that would ever be In this arrangement, the only control messages that would ever be
sent by the Client are unencapsulated RS messages with its AERO sent by the Client are unencapsulated RS messages with its AERO
address as the source address and the address of the Server as the address as the source address and the AERO address of the Server as
destination address. The Client will also receive unencapsulated RA the destination address. The Client will also receive unencapsulated
messages from the Server via both the Proxy and Access Router. RA messages from the Server via both the Proxy and Access Router.
3.16. AERO Route Optimization In some cases, the Access Router and AERO Proxy may be one and the
same node. In that case, the node would be located on the same
physical link as the Client, but its messages exchanges with the
Server would need to pass through a security gateway at the secured
enclave ingress/egress. The method for deploying Access Routers and
Proxys (i.e. as a single node or multiple nodes) is a subnetwork-
local administrative consideration.
While data packets are flowing from a source Client to a target 3.17. AERO Route Optimization
Client that are both holders of ACPs belonging to the same AERO link,
route optimization SHOULD be used to avoid sending traffic through
sub-optimal routes that consume expensive resources. Route
optimization is conducted on a per-interface basis based on the
source Client's available underlying interfaces, and may need to
involve Proxies and Servers in the process.
Route optimization is initiated by the first eligible AERO node While data packets are flowing from a source Client to a target
closest to the source Client (i.e., the route optimization source) as Client that are both holders of ACPs belonging to the same ASP, route
follows: optimization SHOULD be used to establish the best path(s). Route
optimization is initiated by the first eligible Route Optimization
Source (ROS) closest to the source Client as follows:
o For VPNed, NATed and Direct underlying interfaces, the Server is o For VPNed, NATed and Direct underlying interfaces, the Server is
the route optimization source. the ROS.
o For Proxyed underlying interfaces, the Proxy is the route o For Proxyed underlying interfaces, the Proxy is the ROS.
optimization source.
o For native underlying interfaces, the Client itself is the route o For native underlying interfaces, the Client itself is the ROS.
optimization source.
While the source Client sends data packets toward a target Client, The route optimization procedure is conducted between the ROS and a
the route optimization source also sends an NS message to receive a Route Optimization Responder (ROR) in the same manner as for IPv6 ND
solicited NA message from a target Server acting as a Mobility Anchor Address Resolution, and using the same NS/NA messaging. The
Point (MAP) for the target Client. The route optimization process is procedures are specified in the following sections.
conducted in the same manner as IPv6 ND Address Resolution, and using
the same NS/NA messaging.
The NS includes the AERO address of the route optimization source as 3.17.1. Route Optimization Initiation
the network-layer source address, the AERO address corresponding to
the data packet's destination address as the network-layer
destination address, and the route optimization source address as the
link-layer source address. For Clients and Proxies as the route
optimization source, the address of the Client's Server is used as
the link-layer destination address. For Servers as the route
optimization source, the address of a Relay is used as the link-layer
destination address. The NS message also includes a single SLLAO
with the route optimization source address in the UDP Port Number and
IP address fields. Finally, the NS message includes a Timestamp and
Nonce option that can be used to match against the corresponding
solicited NA but does not include any other security codes since the
identity of the target Server is not yet known.
When the source Server forwards or originates the NS message, it While the data packets are flowing from the source Client toward a
inserts an additional mid-layer IP encapsulation header between the target Client, the ROS also sends an NS message to receive a
NS message link-layer and network-layer headers. This mid-layer IP solicited NA message from an ROR acting as a Mobility Anchor Point
header uses the AERO Server Subnet Router Anycast address as the (MAP).
source address and the Subnet Router Anycast address corresponding to
the target AERO address as the destination address. The source
Server then changes the link-layer source address to its own address
and the link-layer destination address to the address of a Relay.
The source Server finally forwards the message to the Relay without
decrementing the network-layer TTL/Hop Limit field.
When the Relay receives the double-encapsulated NS message from the When the ROS sends an NS, it includes the AERO address of the ROS as
source Server, it discards the link-layer header(s) and determines the source address and the AERO address corresponding to the data
that the target Server is the next hop toward the target Client by packet's destination address as the destination address (for example,
consulting its standard IP forwarding table for the Client Subnet if the destination address is 2001:db8:1:2::1 then the target AERO
Router Anycast destination address. The Relay then encapsulates and address is fe80::2001:db8:1:2). The NS message includes no SLLAOs,
forwards the message to the target Server the same as for any IP but SHOULD include a Timestamp and Nonce option.
router.
When the target Server receives the (unsecured) NS message from the The ROS then sends the message into the SPAN (but with SPAN
Relay, it removes the link-layer and mid-layer headers and examines destination set to the inner packet destination) without decrementing
the network-layer destination address to determine whether the target the network-layer TTL/Hop Limit field.
Client is one of its symmetric neighbors in the REACHABLE state. If
the target Client is not a symmetric neighbor in the REACHABLE state,
the target Server discards the NS. Otherwise, it prepares a
solicited NA message to send back to the route optimization source
but does not create a neighbor cache entry. The solicited NA message
includes a first TLLAO with the target Server's address in the IP
address and UDP Port Number, with Interface ID set to 255, with all
P(i) values set to "low" and with "Prefix Length" set to the prefix
length of the target Client's ACP. The solicited NA message then
includes additional TLLAOs for all of the target Client's underlying
interfaces. For NATed, VPNed and Direct interfaces, the TLLAO
addresses are the address of the target Server. For Proxyed
interfaces, the TLLAO addresses are the addresses of the target
Proxies, and for native interfaces the TLLAO addresses are the
addresses of the target Client. The target Server then encapsulates
the solicited NA message, sets the link-layer source address to its
own address and sets the link-layer destination address to the
address found in the NS SLLAO. The target Server finally includes
the Nonce value received in the NS plus the current Timestamp,
applies security according to the route optmization source security
association, then sends the solicited NA message directly to the
route optimization source.
When the route optimization source receives the (secured) solicited 3.17.2. Relaying the NS
NA message, it first verifies the Nonce and Timestamp values. It
then creates an asymmetric neighbor cache entry for the target Client When the Relay receives the (double-encapsulated) NS message from the
and caches all address, Interface ID, P(i) and Prefix Length ROS, it discards the outer IP header and determines that the ROR is
information found in the solicited NA TLLAOs. The route optimization the next hop by consulting its standard IP forwarding table for the
source then forwards future data packets directly to the target SPAN header destination address. The Relay then forwards the SPAN
Client instead of through a dogleg route involving unnecessary message toward the ROR the same as for any IP router. The final-hop
Servers and/or Relays. The route optimization further is shared by Relay in the SPAN will encapsulate the message in an outer IP header
all sources that send packets to the target Client, i.e., and not when it delivers the message to the ROR.
just the original source Client.
3.17.3. Processing the NS and Sending the NA
When the ROR receives the (double-encapsulated) NS message, it
discards the outer IP and SPAN headers. The ROR next examines the
AERO destination address to determine whether the target Client is
one of its symmetric neighbors in the REACHABLE state. If so, the
ROR adds the AERO source address to the target Client's symmetric
neighbor cache entry Report list with time set to ReportTime.
Next, the ROR prepares a solicited NA message to send back to the ROS
but does not create a neighbor cache entry. The ROR sets the NA
source address to its own AERO address and sets the destination
address to the AERO address of the ROS. The NA message includes the
Nonce value received in the NS, the current Timestamp, and a first
TLLAO with Interface ID set to 255, with all P(i) values set to "low"
and with "Prefix Length" set to the prefix length of the target
Client's ACP. If the ROR and ROS are on the same segment, the ROR
sets the TLLAO Link Layer address to the ROR's own link-layer
address; otherwise, set to the ROR's SPAN address.
If the ROS and ROR are on the same segment, the ROR next includes
additional TLLAOs for all of the target Client's Interface IDs. For
NATed, VPNed and Direct interfaces, the TLLAO addresses are the
address of the ROR. For Proxyed interfaces, the TLLAO addresses are
the addresses of the target Client's Proxies, and for native
interfaces the TLLAO addresses are the addresses of the target
Client.
The ROR then sends the message into the SPAN without decrementing the
network-layer TTL/Hop Limit field.
3.17.4. Relaying the NA
When the Relay receives the (double-encapsulated) NA message from the
ROR, it discards the outer IP header and determines that the ROS is
the next hop by consulting its standard IP forwarding table for the
SPAN header destination address. The Relay then forwards the SPAN
message toward the ROS the same as for any IP router. The final-hop
Relay in the SPAN will encapsulate the message in an outer IP header
when it delivers the message to the ROS.
3.17.5. Processing the NA
When the ROS receives the (double-encapsulated) solicited NA message,
it discards the outer IP and SPAN headers. The ROS next verifies the
Nonce and Timestamp values, then creates an asymmetric neighbor cache
entry for the target Client and caches all information found in the
solicited NA TLLAOs. The ROS finally sets the asymmetric neighbor
cache entry lifetime to ReachableTime seconds.
3.17.6. Route Optimization Maintenance
Following route optimization, if the ROS and ROR are on the same SPAN
segment the ROS forwards future data packets directly to the target
Client using the cached link-layer information instead of through a
dogleg route involving unnecessary Servers and/or Relays. Otherwise,
the ROS forwards future data packets into the SPAN using the ROS's
SPAN address as the source address and the ROR's SPAN address as the
destination address. In both cases, the route optimization is shared
by all sources that send packets to the target Client via the ROS,
i.e., and not just the original source Client.
While new data packets destined to the target are flowing through the While new data packets destined to the target are flowing through the
route optimization source, it sends additional secured NS messages to ROS, it sends additional NS messages to the ROR before ReachableTime
the target Server before ReachableTime expires to receive a fresh expires to receive a fresh solicited NA message the same as described
secured solicited NA message. The route optimization source then in the previous sections. The ROS then updates the asymmetric
updates the asymmetric neighbor cache entry to refresh ReachableTime, neighbor cache entry to refresh ReachableTime, while the ROR adds or
while the target Server adds or updates the route optimization source updates the ROS address to the target Client's symmetric neighbor
address to the target Client's symmetric neighbor cache entry Report cache entry Report list and with time set to ReportTime. While no
list, with time set to ReportTime. While no data packets are data packets are flowing, the ROS instead allows ReachableTime for
flowing, the route optimization source instead allows ReachableTime the asymmetric neighbor cache entry to expire. When ReachableTime
for the asymmetric neighbor cache entry to expire. When expires, the ROS deletes the asymmetric neighbor cache entry. Future
ReachableTime expires, the route optimization source deletes the data packets flowing through the ROS will again trigger a new route
asymmetric neighbor cache entry. Future data packets flowing through
the route optimization source will again trigger a new route
optimization exchange while initial data packets travel over a optimization exchange while initial data packets travel over a
suboptimal route via Servers and/or Relays. suboptimal route via Servers and/or Relays.
The route optimization source may also receive unsolicited NA The ROS may also receive unsolicited NA messages from the ROR at any
messages from the target at any time. If there is an asymmetric time. If there is an asymmetric neighbor cache entry for the target,
neighbor cache entry for the target, the route optimization source the ROS updates the link-layer information but does not update
updates the link-layer information but does not update ReachableTime ReachableTime since the receipt of an unsolicited NA does not confirm
since the receipt of an unsolicited NA does not confirm that the that the forward path is still working. If there is no asymmetric
forward path is still working. If there is no asymmetric neighbor neighbor cache entry, the route optimization source simply discards
cache entry, the route optimization source simply discards the the unsolicited NA. Cases in which unsolicited NA messages are
unsolicited NA. Cases in which unsolicited NA messages are generated generated are specified in Section 3.19.
are specified in Section 3.18.
In this arrangement, the route optimization source holds an In this arrangement, the ROS holds an asymmetric neighbor cache entry
asymmetric neighbor cache entry for the target, but the target does for the ROR, but the ROR does not hold an asymmetric neighbor cache
not hold an asymmetric neighbor cache entry for the route entry for the ROS. The route optimization neighbor relationship is
optimization source. The route optimization neighbor relationship is
therefore asymmetric and unidirectional. If the target Client also therefore asymmetric and unidirectional. If the target Client also
has packets to send back to the source Client, then a separate route has packets to send back to the source Client, then a separate route
optimization procedure is required in the reverse direction. But, optimization procedure is required in the reverse direction. But,
there is no requirement that the forward and reverse paths be there is no requirement that the forward and reverse paths be
symmetric. symmetric.
3.17. Neighbor Unreachability Detection (NUD) 3.18. Neighbor Unreachability Detection (NUD)
AERO nodes perform Neighbor Unreachability Detection (NUD) by sending AERO nodes perform Neighbor Unreachability Detection (NUD) the same
NS messages to elicit solicited NA messages from the target node the as described in [RFC4861]. NUD is performed either reactively in
same as described in [RFC4861]. NUD is performed either reactively response to persistent link-layer errors (see Section 3.14) or
in response to persistent link-layer errors (see Section 3.13) or proactively to confirm bi-directional reachability. The NUD
proactively to confirm reachability in the forward direction. The algorithm may further be seeded by neighbor discovery hints of
NUD algorithm may further be seeded by neighbor discovery hints of
forward progress, but care must be taken to avoid inferring forward progress, but care must be taken to avoid inferring
reachability based on spoofed information. reachability based on spoofed information.
When an AERO node sends an NS/NA message, it uses one of its link- When an AERO node sends an NS/NA message used for NUD, it uses one of
local addresses as the IPv6 source address and a link-local address its AERO addresses as the IPv6 source address and an AERO address of
of the neighbor as the IPv6 destination address. When route the neighbor as the IPv6 destination address, but does not include S/
optimization directs a route optimization source to one or more TLLAOs. When an ROR directs an ROS to one or more target addresses,
target addresses, the source SHOULD proactively test the direct path the ROS SHOULD proactively test the direct path to each target
to each target address by sending an initial NS message to elicit a address by sending an initial NS message to elicit a solicited NA
solicited NA response. While testing the path, the source node can response. While testing the path, the source node can optionally
optionally continue sending packets via its default router, maintain continue sending packets via its default router, maintain a small
a small queue of packets until target reachability is confirmed, or queue of packets until target reachability is confirmed, or
(optimistically) allow packets to flow directly to the target. (optimistically) allow packets to flow directly to the target.
Note that AERO nodes may have multiple underlying interface paths Note that AERO nodes may have multiple underlying interface paths
toward the target neighbor. In that case, NUD SHOULD be performed toward the target neighbor. In that case, NUD SHOULD be performed
over each underlying interface individually and the node should only over each underlying interface individually and the node should only
consider the neighbor unreachable if NUD fails over multiple consider the neighbor unreachable if NUD fails over multiple
underlying interface paths. underlying interface paths.
Underlying interface paths that pass NUD tests are marked as Underlying interface paths that pass NUD tests are marked as
"reachable", while those that do not are marked as "unreachable". "reachable", while those that do not are marked as "unreachable".
These markings inform the AERO interface forwarding algorithm These markings inform the AERO interface forwarding algorithm
specified in Section 3.8. specified in Section 3.9.
Proxies can perform NUD to verify Server reachability on behalf of Proxies can perform NUD to verify Server reachability on behalf of
their proxyed Clients so that the Clients need not engage in NUD their proxyed Clients so that the Clients need not engage in NUD
messaging themselves. messaging themselves.
3.18. Mobility Management and Quality of Service (QoS) 3.19. Mobility Management and Quality of Service (QoS)
AERO is an example of a Distributed Mobility Management (DMM) AERO is an example of a Distributed Mobility Management (DMM)
service. Each Server is responsible for only a subset of the Clients service. Each Server is responsible for only a subset of the Clients
on the AERO link, as opposed to a Centralized Mobility Management on the AERO link, as opposed to a Centralized Mobility Management
(CMM) service where there is a single network mobility service for (CMM) service where there is a single network mobility service for
all Clients. Clients coordinate with their associated Servers via all Clients. Clients coordinate with their associated Servers via
RS/RA exchanges to maintain the DMM profile, and the AERO routing RS/RA exchanges to maintain the DMM profile, and the AERO routing
system tracks all current Client/Server peering relationships. system tracks all current Client/Server peering relationships.
Servers provide a Mobility Anchor Point (MAP) for their dependent Servers provide a Mobility Anchor Point (MAP) for their dependent
skipping to change at page 43, line 46 skipping to change at page 47, line 14
relationships with their Servers through periodic RS/RA exchanges, relationships with their Servers through periodic RS/RA exchanges,
which also serves to confirm neighbor reachability. When a Client's which also serves to confirm neighbor reachability. When a Client's
underlying interface address and/or QoS information changes, the underlying interface address and/or QoS information changes, the
Client is responsible for updating the Server with this new Client is responsible for updating the Server with this new
information. Note that for Proxyed interfaces, however, the Proxy information. Note that for Proxyed interfaces, however, the Proxy
can perform the RS/RA exchanges on the Client's behalf. can perform the RS/RA exchanges on the Client's behalf.
Mobility management considerations are specified in the following Mobility management considerations are specified in the following
sections. sections.
3.18.1. Mobility Update Messaging 3.19.1. Mobility Update Messaging
AERO Servers (acting as MAPs) accommodate mobility and/or QoS change RORs (acting as MAPs) accommodate mobility and/or QoS change events
events by sending unsolicited NA messages to all route optimization by sending an unsolicited NA message to each ROS in the target
sources for the target Client. When a Server sends an unsolicited NA Client's Report list. When an ROR sends an unsolicited NA message,
message, it sets the IPv6 source address to the Client's AERO it sets the IPv6 source address to the Client's AERO address and sets
address, sets the IPv6 destination address to all-nodes multicast, the IPv6 destination address to all-nodes multicast (ff02::1). The
sets the link-layer source address to its own address and sets the ROR also includes a first TLLAO for Interface ID 255 with Link Layer
link-layer destination address to either a multicast address or the address set to the ROR link-layer address if the ROR and ROS are on
unicast link-layer address of a route optimization source in the the same segment; otherwise, set to the ROR SPAN address. If the ROS
Client's Report list. The Server also includes a first TLLAO for and ROR are on the same segment the ROR next includes additional
Interface ID 255, and includes additional TLLAOs for all of the TLLAOs for all of the target Client's Interface IDs. The ROR then
target Client's Interface IDs. If there are multiple route finally sends the message into the SPAN.
optimization sources, the node sends an identical unicast copy of the
unsolicited NA to each source.
As for the hot-swap of interface cards discussed in Section 7.2.6 of As for the hot-swap of interface cards discussed in Section 7.2.6 of
[RFC4861], the transmission and reception of unsolicited NA messages [RFC4861], the transmission and reception of unsolicited NA messages
is unreliable but provides a useful optimization. In well-connected is unreliable but provides a useful optimization. In well-connected
Internetworks with robust data links unsolicited NA messages will be Internetworks with robust data links unsolicited NA messages will be
delivered with high probability, but in any case the Server can delivered with high probability, but in any case the ROR can
optionally send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to optionally send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to
each route optimization source to increase the likelihood that at each ROS to increase the likelihood that at least one will be
least one will be received. received.
When a route optimization source receives an unsolicited NA message, When an ROS receives an unsolicited NA message, it ignores the
it ignores the message if there is no existing neighbor cache entry message if there is no existing neighbor cache entry for the Client.
for the Client. Otherwise, it uses the included TLLAOs to update the Otherwise, it uses the included TLLAOs to update the address and QoS
address and QoS information in the neighbor cache entry, but does not information in the neighbor cache entry, but does not reset
reset ReachableTime since the receipt of an unsolicited NA message ReachableTime since the receipt of an unsolicited NA message from the
from the target Server does not provide confirmation that any forward target Server does not provide confirmation that any forward paths to
paths to the target Client are working. the target Client are working.
If unsolicited NA messages are lost, the route optimization source If unsolicited NA messages are lost, the ROS may be left with stale
may be left with stale address and/or QoS information for the Client address and/or QoS information for the Client for up to ReachableTime
for up to ReachableTime seconds. During this time, the route seconds. During this time, the ROS can continue sending packets to
optimization source can continue sending packets to the target Client the target Client according to its current neighbor cache information
according to its current neighbor cache information but may receive but may receive persistent unsolicited NA messages as discussed in
persistent unsolicited NA messages as discussed in Section 3.18.2. Section 3.19.2.
3.18.2. Forwarding Packets on Behalf of Departed Clients 3.19.2. Forwarding Packets on Behalf of Departed Clients
When a Server receives packets with destination addresses that match When a Server receives packets with destination addresses that match
a symmetric neighbor cache entry in the DEPARTED state, it forwards a symmetric neighbor cache entry in the DEPARTED state, it forwards
the packets according to the Client's cached link layer address the packets according to the Client's cached link layer address
information, noting that the information may be stale. If the source information, noting that the information may be stale. If the
is not a Relay or a symmetric neighbor Client, the Server also encapsulation source is in the Report list (i.e., if it is an ROS),
returns an unsolicited NA message (subject to rate limiting) with a the Server also sends an unsolicited NA message via the SPAN (subject
first TLLAO with Interface ID 255 and with D set to 1. The (route to rate limiting) with a TLLAO with Interface ID 255 and with D set
optimization) source will then realize that it needs to set its to 1. The ROS will then realize that it needs to set its asymmetric
asymmetric neighbor cache entry state for the target to DEPARTED, and neighbor cache entry state for the target to DEPARTED, and SHOULD re-
SHOULD re-initiate route optimization after a short delay. (Note initiate route optimization after a short delay.
that if the NA includes additional TLLAOs with D set to 1, the route
optimization source marks the corresponding neighbor cache interface
IDs as "unreachable".)
When a Proxy receives packets with destination addresses that match a When a Proxy receives packets with destination addresses that match a
proxy neighbor cache entry in the DEPARTED state, if forwards the proxy neighbor cache entry in the DEPARTED state, it forwards the
packets to one of the target Client's Servers. If the source is packets to one of the target Client's Servers. If the encapsulation
neither one of target Client's Servers nor one of its proxy neighbor source is neither one of the target Client's Servers nor one of its
Clients, the Proxy also returns an unsolicited NA message (subject to proxy neighbor Clients, the Proxy also returns an unsolicited NA
rate limiting) with a single TLLAO with the target Client's Interface message via the SPAN (subject to rate limiting) with a single TLLAO
ID and with D set to 1. The (route optimization) source will then with the target Client's Interface ID and with D set to 1. The
realize that it needs to mark its neighbor cache entry Interface ID source will then realize that it needs to mark its neighbor cache
for the Proxy as "unreachable", and SHOULD re-initiate route entry Interface ID for the Proxy as "unreachable", and SHOULD re-
optimization while continuing to forward according to the remaining initiate route optimization while continuing to forward packets
neighbor cache entry state. according to the remaining neighbor cache entry state.
When a Server receives packets from a symmteric neighbor Client that When a Server receives packets from a symmetric neighbor Client that
are destined to the same Client, the Server marks the neighbor cache are destined to the same Client, the Server marks the neighbor cache
entry Interface ID for this path as "unreachable", and forwards the entry Interface ID for this path as "unreachable", and forwards the
packets via a "reachable" Interface ID. If there are no "reachable" packets via a "reachable" Interface ID. If there are no "reachable"
Interface IDs, the Server drops the packet. Interface IDs, the Server drops the packet.
When a Client receives packets with destination addresses that do not When a Client receives packets with destination addresses that do not
match one of its ACPs, it drops the packets silently. match one of its ACPs, it drops the packets silently.
3.18.3. Announcing Link-Layer Address and/or QoS Preference Changes 3.19.3. Announcing Link-Layer Address and/or QoS Preference Changes
When a Client needs to change its link-layer addresses and/or QoS When a Client needs to change its link-layer addresses and/or QoS
preferences (e.g., due to a mobility event), either the Client or preferences (e.g., due to a mobility event), either the Client or
Proxy sends RS messages to its Servers using the new link-layer Proxy sends RS messages to its Servers via the SPAN using the new
address as the source address and with TLLAOs that include the new link-layer address as the source address and with SLLAOs that include
Client UDP Port Number, IP Address and P(i) values. If the RS the new Client Port Number, Link-Layer Address and P(i) values. If
messages are sent solely for the purpose of updating QoS preferences the RS messages are sent solely for the purpose of updating QoS
without updating the link-layer address, the UDP Port Number and IP preferences without updating the link-layer address, the Port Number
Address are set to 0. If the RS message is not sent for the purpose and Link-Layer Address are set to 0. If the RS message is not sent
of asserting a PD, the Prefix Length is set to 0. for the purpose of asserting a PD, the Prefix Length is set to 0.
Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with
sending actual data packets in case one or more RAs are lost. If all sending actual data packets in case one or more RAs are lost. If all
RAs are lost, the Client SHOULD re-associate with a new Server. RAs are lost, the Client SHOULD re-associate with a new Server.
3.18.4. Bringing New Links Into Service 3.19.4. Bringing New Links Into Service
When a Client needs to bring new underlying interfaces into service When a Client needs to bring new underlying interfaces into service
(e.g., when it activates a new data link), it sends RS messages to (e.g., when it activates a new data link), it sends RS messages to
its Servers using the new link-layer address as the source address its Servers using the new link-layer address as the source address
and with TLLAOs that include the new Client link-layer information. and with SLLAOs that include the new Client link-layer information.
If the RS message is not sent for the purpose of asserting a PD, the If the RS message is not sent for the purpose of asserting a PD, the
Prefix Length is set to 0. Prefix Length is set to 0.
3.18.5. Removing Existing Links from Service 3.19.5. Removing Existing Links from Service
When a Client needs to remove existing underlying interfaces from When a Client needs to remove existing underlying interfaces from
service (e.g., when it de-activates an existing data link), it sends service (e.g., when it de-activates an existing data link), it sends
RS messages to its Servers with SLLAOs with the D flag set to 1. RS messages to its Servers with SLLAOs with the D flag set to 1.
If the Client needs to send RS messages over an underlying interface If the Client needs to send RS messages over an underlying interface
other than the one being removed from service, it MUST include a other than the one being removed from service, it MUST include a
current SLLAO for the sending interface as the first SLLAO and current SLLAO for the sending interface as the first SLLAO and
include SLLAOs for any underlying interfaces being removed from include SLLAOs for any underlying interfaces being removed from
service as additional SLLAOs. service as additional SLLAOs.
3.18.6. Implicit Mobility Management 3.19.6. Implicit Mobility Management
AERO interface neighbors MAY provide a configuration option that AERO interface neighbors MAY provide a configuration option that
allows them to perform implicit mobility management in which no ND allows them to perform implicit mobility management in which no ND
messaging is used. In that case, the Client only transmits packets messaging is used. In that case, the Client only transmits packets
over a single interface at a time, and the neighbor always observes over a single interface at a time, and the neighbor always observes
packets arriving from the Client from the same link-layer source packets arriving from the Client from the same link-layer source
address. address.
If the Client's underlying interface address changes (either due to a If the Client's underlying interface address changes (either due to a
readdressing of the original interface or switching to a new readdressing of the original interface or switching to a new
interface) the neighbor immediately updates the neighbor cache entry interface) the neighbor immediately updates the neighbor cache entry
for the Client and begins accepting and sending packets to the for the Client and begins accepting and sending packets to the
Client's new link-layer address. This implicit mobility method Client's new link-layer address. This implicit mobility method
applies to use cases such as cellphones with both WiFi and Cellular applies to use cases such as cellphones with both WiFi and Cellular
interfaces where only one of the interfaces is active at a given interfaces where only one of the interfaces is active at a given
time, and the Client automatically switches over to the backup time, and the Client automatically switches over to the backup
interface if the primary interface fails. interface if the primary interface fails.
3.18.7. Moving to a New Server 3.19.7. Moving to a New Server
When a Client associates with a new Server, it performs the Client When a Client associates with a new Server, it performs the Client
procedures specified in Section 3.14.2. The Client then sends an RS procedures specified in Section 3.15.2. The Client then sends an RS
message with R set to 1 in the first SLLAO and with PD parameters message with R set to 1 in the first SLLAO and with PD parameters
over any working underlying interface to fully release itself from over any working underlying interface to fully release itself from
the old Server. If the Client does not receive an RA reply after the old Server. The SLLAO also includes the link-layer address of
MAX_RTR_SOLICITATIONS attempts over multiple underlying interfaces, the new Server if the new and old Servers are on the same segment;
the old Server may have failed and the Client should discontinue its otherwise, it includes the SPAN address of the new Server. If the
release attempts. Client does not receive an RA reply after MAX_RTR_SOLICITATIONS
attempts over multiple underlying interfaces, the old Server may have
failed and the Client should discontinue its release attempts.
When the old Server processes the RS, it sends unsolicited NA When the old Server processes the RS, it sends unsolicited NA
messages with a single TLLAO with Interface ID set to 255 and with D messages with a single TLLAO with Interface ID set to 255 and with D
set to 1 to all route optimization sources in the Client's Report set to 1 to all route optimization sources in the Client's Report
list. The Server also changes the symmetric neighbor cache entry list. The Server also changes the symmetric neighbor cache entry
state to DEPARTED and sets a timer to DepartTime seconds. The Server state to DEPARTED, sets the link-layer address of the Client to the
then returns an RA message to the Client with Router Lifetime set to address found in the RS SLLAO, and sets a timer to DepartTime
0. After DepartTime seconds expires, the Server deletes the seconds. The Server then returns an RA message to the Client with
symmetric neighbor cache entry. Router Lifetime set to 0. After DepartTime seconds expires, the
Server deletes the symmetric neighbor cache entry.
When the Client receives the RA message with Router Lifetime set to When the Client receives the RA message with Router Lifetime set to
0, it still must inform each of its remaining Proxies that it has 0, it still must inform each of its remaining Proxies that it has
released this Server from service. To do so, it sends an RS over released the old Server from service. To do so, it sends an RS over
each remaining proxyed underlying interface with destination set to each remaining proxyed underlying interface with destination set to
the released Server's address and with R set to 1 in the first SLLAO the old Server's AERO address and with R set to 1 in the first SLLAO
but with no PD parameters. The Proxy will mark this Server as but with no PD parameters. The Proxy will mark this Server as
DEAPARTED and return an immediate RA without first performing an RS/ DEAPARTED and return an immediate RA without first performing an RS/
RA exchange with the Server. RA exchange with the old Server.
Clients SHOULD NOT move rapidly between Servers in order to avoid Clients SHOULD NOT move rapidly between Servers in order to avoid
causing excessive oscillations in the AERO routing system. Such causing excessive oscillations in the AERO routing system. Examples
oscillations could result in intermittent reachability for the Client of when a Client might wish to change to a different Server include a
itself, while causing no harm to the network. Examples of when a Server that has gone unreachable, topological movements of
Client might wish to change to a different Server include a Server significant distance, movement to a new geographic region, movement
that has gone unreachable, topological movements of significant to a new segment, etc.
distance, movement to a new geographic region, etc.
3.19. Multicast Considerations 3.20. Multicast Considerations
When the underlying network does not support multicast, AERO Clients When the underlying network does not support multicast, AERO Clients
map link-scoped multicast addresses to the link-layer address of a map link-scoped multicast addresses to the link-layer address of a
Server, which acts as a multicast forwarding agent. The AERO Client Server, which acts as a multicast forwarding agent. The AERO Client
also serves as an IGMP/MLD Proxy for its EUNs and/or hosted also serves as an IGMP/MLD Proxy for its EUNs and/or hosted
applications per [RFC4605] while using the link-layer address of the applications per [RFC4605] while using the link-layer address of the
Server as the link-layer address for all multicast packets. Server as the link-layer address for all multicast packets.
When the underlying network supports multicast, AERO nodes use the When the underlying network supports multicast, AERO nodes use the
multicast address mapping specification found in [RFC2529] for IPv4 multicast address mapping specification found in [RFC2529] for IPv4
skipping to change at page 48, line 33 skipping to change at page 52, line 5
/64 prefix (i.e., the upper 64 bits). /64 prefix (i.e., the upper 64 bits).
For example, if the ASP for the host-only IPv6 AERO link is For example, if the ASP for the host-only IPv6 AERO link is
2001:db8:1000:2000::/64, each Client will receive one or more /128 2001:db8:1000:2000::/64, each Client will receive one or more /128
IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, IPv6 prefix delegations such as 2001:db8:1000:2000::1/128,
2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix
delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to
the AERO interface, and assigns the global IPv6 addresses (i.e., the the AERO interface, and assigns the global IPv6 addresses (i.e., the
/128s) to either the AERO interface or an internal virtual interface /128s) to either the AERO interface or an internal virtual interface
such as a loopback. In this arrangement, the Client conducts route such as a loopback. In this arrangement, the Client conducts route
optimization in the same sense as discussed in Section 3.16. optimization in the same sense as discussed in Section 3.17.
This specification has applicability for nodes that act as a Client This specification has applicability for nodes that act as a Client
on an "upstream" AERO link, but also act as a Server on "downstream" on an "upstream" AERO link, but also act as a Server on "downstream"
AERO links. More specifically, if the node acts as a Client to AERO links. More specifically, if the node acts as a Client to
receive a /64 prefix from the upstream AERO link it can then act as a receive a /64 prefix from the upstream AERO link it can then act as a
Server to provision /128s to Clients on downstream AERO links. Server to provision /128s to Clients on downstream AERO links.
6. AERO Adaptations for SEcure Neighbor Discovery (SEND) 6. AERO Adaptations for SEcure Neighbor Discovery (SEND)
SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically
skipping to change at page 50, line 40 skipping to change at page 54, line 13
No further IANA actions are required. No further IANA actions are required.
10. Security Considerations 10. Security Considerations
AERO link security considerations include considerations for both the AERO link security considerations include considerations for both the
data plane and the control plane. data plane and the control plane.
Data plane security considerations are the same as for ordinary Data plane security considerations are the same as for ordinary
Internet communications. Application endpoints in AERO Clients and Internet communications. Application endpoints in AERO Clients and
their EUNs SHOULD use application-layer security services such as their EUNs SHOULD use application-layer security services such as
TLS/SSL [RFC5246], DTLS [RFC6347] or SSH [RFC4251] to assure the same TLS/SSL [RFC8446], DTLS [RFC6347] or SSH [RFC4251] to assure the same
level of protection as for critical secured Internet services such as level of protection as for critical secured Internet services. AERO
online banking. AERO Clients that require host-based VPN services Clients that require host-based VPN services SHOULD use symmetric
SHOULD use symmetric network and/or transport layer security services network and/or transport layer security services such as TLS/SSL,
such as TLS/SSL, DTLS, IPsec [RFC4301], etc. AERO Proxies and DTLS, IPsec [RFC4301], etc. AERO Proxies and Servers can also
Servers can also provide a network-based VPN service on behalf of the provide a network-based VPN service on behalf of the Client, e.g., if
Client, e.g., if the Client is located within a secured enclave and the Client is located within a secured enclave and cannot establish a
cannot establish a VPN on its own behalf. VPN on its own behalf.
Control plane security considerations are the same as for standard Control plane security considerations are the same as for standard
IPv6 Neighbor Discovery [RFC4861], except that the MAP list also IPv6 Neighbor Discovery [RFC4861], except that the MAP list also
improves security by providing AERO Clients with an authentic list of improves security by providing AERO Clients with an authentic list of
trusted Servers. As fixed infrastructure elements, AERO Proxies and trusted Servers. As fixed infrastructure elements, AERO Proxies and
Servers SHOULD pre-configure security associations for one another Servers SHOULD pre-configure security associations for one or more
(e.g., using pre-placed keys) and use symmetric network and/or Relays on their SPAN segments (e.g., using pre-placed keys) and use
transport layer security services such as IPsec, TLS/SSL or DTLS to symmetric network and/or transport layer security services such as
secure ND messages. AERO Relays do not maintain security IPsec, TLS/SSL or DTLS to secure ND messages. The AERO Relays of all
associations since the only ND messages they accommodate are SPAN segments in turn SHOULD pre-configure security associations for
unprotected NS messages used for route optimization. AERO Clients their neighboring AERO Relays. AERO Clients that connect to secured
that connect to secured enclaves need not apply security to their ND enclaves need not apply security to their ND messages, since the
messages, since the messages will be intercepted by an enclave messages will be intercepted by an enclave perimeter Proxy. AERO
perimeter Proxy. AERO Clients located outside of secured enclaves Clients located outside of secured enclaves SHOULD use symmetric
SHOULD use symmetric network and/or transport layer security to network and/or transport layer security to secure their ND exchanges
secure their ND exchanges with Servers, but when there are many with Servers, but when there are many prospective neighbors with
prospective neighbors with dynamically changing connectivity an dynamically changing connectivity an asymmetric security service such
asymmetric security service such as SEND may be needed (see: as SEND may be needed (see: Section 6).
Section 6).
AERO Servers and Relays present targets for traffic amplification AERO Servers and Relays present targets for traffic amplification
Denial of Service (DoS) attacks. This concern is no different than Denial of Service (DoS) attacks. This concern is no different than
for widely-deployed VPN security gateways in the Internet, where for widely-deployed VPN security gateways in the Internet, where
attackers could send spoofed packets to the gateways at high data attackers could send spoofed packets to the gateways at high data
rates. This can be mitigated by connecting Relays and Servers over rates. This can be mitigated by connecting Relays and Servers over
dedicated links with no connections to the Internet and/or when dedicated links with no connections to the Internet and/or when
connections to the Internet are only permitted through well-managed connections to the Internet are only permitted through well-managed
firewalls. Traffic amplification DoS attacks can also target an AERO firewalls. Traffic amplification DoS attacks can also target an AERO
Client's low data rate links. This is a concern not only for Clients Client's low data rate links. This is a concern not only for Clients
located on the open Internet but also for Clients in secured located on the open Internet but also for Clients in secured
enclaves. AERO Servers and Proxies can institute rate limits that enclaves. AERO Servers and Proxies can institute rate limits that
protect Clients from receiving packet floods that could DoS low data protect Clients from receiving packet floods that could DoS low data
rate links. rate links.
AERO Relays must implement ingress filtering to discard packets with AERO Relays must implement ingress filtering to avoid a spoofing
the AERO Server Subent Router Anycast address to avoid a spoofing attack in which spurious SPAN messages are injected into an AERO link
attack in which spurious packets are injected into an AERO link from from an outside attacker. Also, since an AERO link spans one or
an outside attacker. Also, since an AERO link spans an entire Internetwork segments, restricting access to the link can be achieved
Internetwork restricting access to the link can be achieved by having by having Internetwork border routers implement ingress filtering to
Internetwork border routers implement ingress filtering to discard discard encapsulated packets injected into the link by an outside
encapsulted packets injected into the link by an outside agent. agent.
AERO Clients MUST ensure that their connectivity is not used by AERO Clients MUST ensure that their connectivity is not used by
unauthorized nodes on their EUNs to gain access to a protected unauthorized nodes on their EUNs to gain access to a protected
network, i.e., AERO Clients that act as routers MUST NOT provide network, i.e., AERO Clients that act as routers MUST NOT provide
routing services for unauthorized nodes. (This concern is no routing services for unauthorized nodes. (This concern is no
different than for ordinary hosts that receive an IP address different than for ordinary hosts that receive an IP address
delegation but then "share" the address with other nodes via some delegation but then "share" the address with other nodes via some
form of Internet connection sharing such as tethering.) form of Internet connection sharing such as tethering.)
The MAP list MUST be well-managed and secured from unauthorized The MAP list MUST be well-managed and secured from unauthorized
skipping to change at page 53, line 32 skipping to change at page 56, line 48
This work is aligned with the Boeing Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program. MobileNet program.
This work is aligned with the Boeing autonomy program. This work is aligned with the Boeing autonomy program.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 54, line 24 skipping to change at page 57, line 33
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router
Advertisement Flags Option", RFC 5175,
DOI 10.17487/RFC5175, March 2008,
<https://www.rfc-editor.org/info/rfc5175>.
[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>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
12.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.
[I-D.ietf-dmm-distributed-mobility-anchoring] [I-D.ietf-dmm-distributed-mobility-anchoring]
Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos,
"Distributed Mobility Anchoring", draft-ietf-dmm- "Distributed Mobility Anchoring", draft-ietf-dmm-
distributed-mobility-anchoring-12 (work in progress), distributed-mobility-anchoring-13 (work in progress),
January 2019. March 2019.
[I-D.ietf-intarea-gue] [I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-intarea-gue-07 (work in Encapsulation", draft-ietf-intarea-gue-07 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-intarea-gue-extensions] [I-D.ietf-intarea-gue-extensions]
Herbert, T., Yong, L., and F. Templin, "Extensions for Herbert, T., Yong, L., and F. Templin, "Extensions for
Generic UDP Encapsulation", draft-ietf-intarea-gue- Generic UDP Encapsulation", draft-ietf-intarea-gue-
extensions-06 (work in progress), March 2019. extensions-06 (work in progress), March 2019.
skipping to change at page 55, line 37 skipping to change at page 58, line 37
Touch, J. and M. Townsley, "IP Tunnels in the Internet Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-09 (work in Architecture", draft-ietf-intarea-tunnels-09 (work in
progress), July 2018. progress), July 2018.
[I-D.ietf-rtgwg-atn-bgp] [I-D.ietf-rtgwg-atn-bgp]
Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. Templin, F., Saccone, G., Dawra, G., Lindem, A., and V.
Moreno, "A Simple BGP-based Mobile Routing System for the Moreno, "A Simple BGP-based Mobile Routing System for the
Aeronautical Telecommunications Network", draft-ietf- Aeronautical Telecommunications Network", draft-ietf-
rtgwg-atn-bgp-01 (work in progress), January 2019. rtgwg-atn-bgp-01 (work in progress), January 2019.
[I-D.templin-6man-aeroaddr]
Templin, F., "The AERO Address", draft-templin-6man-
aeroaddr-04 (work in progress), December 2018.
[I-D.templin-6man-dhcpv6-ndopt] [I-D.templin-6man-dhcpv6-ndopt]
Templin, F., "A Unified Stateful/Stateless Configuration Templin, F., "A Unified Stateful/Stateless Configuration
Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07
(work in progress), December 2018. (work in progress), December 2018.
[I-D.templin-6man-rio-redirect]
Templin, F. and j. woodyatt, "Route Information Options in
IPv6 Neighbor Discovery", draft-templin-6man-rio-
redirect-07 (work in progress), December 2018.
[I-D.templin-intarea-grefrag] [I-D.templin-intarea-grefrag]
Templin, F., "GRE Tunnel Level Fragmentation", draft- Templin, F., "GRE Tunnel Level Fragmentation", draft-
templin-intarea-grefrag-04 (work in progress), July 2016. templin-intarea-grefrag-04 (work in progress), July 2016.
[I-D.templin-intarea-seal] [I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-68 (work in Layer (SEAL)", draft-templin-intarea-seal-68 (work in
progress), January 2014. progress), January 2014.
[I-D.templin-intarea-vet] [I-D.templin-intarea-vet]
skipping to change at page 56, line 47 skipping to change at page 59, line 38
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <https://www.rfc-editor.org/info/rfc1981>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996, DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/info/rfc2003>. <https://www.rfc-editor.org/info/rfc2003>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[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>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, Domains without Explicit Tunnels", RFC 2529,
DOI 10.17487/RFC2529, March 1999, DOI 10.17487/RFC2529, March 1999,
<https://www.rfc-editor.org/info/rfc2529>. <https://www.rfc-editor.org/info/rfc2529>.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
skipping to change at page 59, line 20 skipping to change at page 61, line 49
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,
<https://www.rfc-editor.org/info/rfc4982>. <https://www.rfc-editor.org/info/rfc4982>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008, DOI 10.17487/RFC5214, March 2008,
<https://www.rfc-editor.org/info/rfc5214>. <https://www.rfc-editor.org/info/rfc5214>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320,
February 2010, <https://www.rfc-editor.org/info/rfc5320>. February 2010, <https://www.rfc-editor.org/info/rfc5320>.
[RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
Route Optimization Requirements for Operational Use in Route Optimization Requirements for Operational Use in
Aeronautics and Space Exploration Mobile Networks", Aeronautics and Space Exploration Mobile Networks",
RFC 5522, DOI 10.17487/RFC5522, October 2009, RFC 5522, DOI 10.17487/RFC5522, October 2009,
<https://www.rfc-editor.org/info/rfc5522>. <https://www.rfc-editor.org/info/rfc5522>.
[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
RFC 5558, DOI 10.17487/RFC5558, February 2010, RFC 5558, DOI 10.17487/RFC5558, February 2010,
<https://www.rfc-editor.org/info/rfc5558>. <https://www.rfc-editor.org/info/rfc5558>.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
January 2010, <https://www.rfc-editor.org/info/rfc5569>. January 2010, <https://www.rfc-editor.org/info/rfc5569>.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
DOI 10.17487/RFC5720, February 2010,
<https://www.rfc-editor.org/info/rfc5720>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<https://www.rfc-editor.org/info/rfc5996>.
[RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network
(IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011,
<https://www.rfc-editor.org/info/rfc6179>. <https://www.rfc-editor.org/info/rfc6179>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
DOI 10.17487/RFC6221, May 2011, DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/info/rfc6221>. <https://www.rfc-editor.org/info/rfc6221>.
[RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure
Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273,
DOI 10.17487/RFC6273, June 2011, DOI 10.17487/RFC6273, June 2011,
<https://www.rfc-editor.org/info/rfc6273>. <https://www.rfc-editor.org/info/rfc6273>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
RFC 6422, DOI 10.17487/RFC6422, December 2011,
<https://www.rfc-editor.org/info/rfc6422>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>. <https://www.rfc-editor.org/info/rfc6438>.
[RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization
(AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012,
<https://www.rfc-editor.org/info/rfc6706>. <https://www.rfc-editor.org/info/rfc6706>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013, RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>. <https://www.rfc-editor.org/info/rfc6864>.
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
March 2017, <https://www.rfc-editor.org/info/rfc8086>. March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
October 2014. "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[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>.
Appendix A. AERO Alternate Encapsulations Appendix A. AERO Alternate Encapsulations
When GUE encapsulation is not needed, AERO can use common When GUE encapsulation is not needed, AERO can use common
encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic
Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The
encapsulation is therefore only differentiated from non-AERO tunnels encapsulation is therefore only differentiated from non-AERO tunnels
through the application of AERO control messaging and not through, through the application of AERO control messaging and not through,
e.g., a well-known UDP port number. e.g., a well-known UDP port number.
As for GUE encapsulation, alternate AERO encapsulation formats may As for GUE encapsulation, alternate AERO encapsulation formats may
require encapsulation layer fragmentation. For simple IP-in-IP require encapsulation layer fragmentation. For simple IP-in-IP
encapsulation, an IPv6 fragment header is inserted directly between encapsulation, an IPv6 fragment header is inserted directly between
the inner and outer IP headers when needed, i.e., even if the outer the inner and outer IP headers when needed, i.e., even if the outer
header is IPv4. The IPv6 Fragment Header is identified to the outer header is IPv4. The IPv6 Fragment Header is identified to the outer
IP layer by its IP protocol number, and the Next Header field in the IP layer by its IP protocol number, and the Next Header field in the
IPv6 Fragment Header identifies the inner IP header version. For GRE IPv6 Fragment Header identifies the inner IP header version. For GRE
encapsulation, a GRE fragment header is inserted within the GRE encapsulation, a GRE fragment header is inserted within the GRE
header [I-D.templin-intarea-grefrag]. header [I-D.templin-intarea-grefrag].
Figure 4 shows the AERO IP-in-IP encapsulation format before any Figure 5 shows the AERO IP-in-IP encapsulation format before any
fragmentation is applied: fragmentation is applied:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer IPv4 Header | | Outer IPv6 Header | | Outer IPv4 Header | | Outer IPv6 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner IP Header | | Inner IP Header | | Inner IP Header | | Inner IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
~ Inner Packet Body ~ ~ Inner Packet Body ~ ~ Inner Packet Body ~ ~ Inner Packet Body ~
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6
Figure 4: Minimal Encapsulation Format using IP-in-IP Figure 5: Minimal Encapsulation Format using IP-in-IP
Figure 5 shows the AERO GRE encapsulation format before any Figure 6 shows the AERO GRE encapsulation format before any
fragmentation is applied: fragmentation is applied:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer IP Header | | Outer IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Header | | GRE Header |
| (with checksum, key, etc..) | | (with checksum, key, etc..) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Fragment Header (optional)| | GRE Fragment Header (optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner IP Header | | Inner IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Inner Packet Body ~ ~ Inner Packet Body ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Minimal Encapsulation Using GRE Figure 6: Minimal Encapsulation Using GRE
Alternate encapsulation may be preferred in environments where GUE Alternate encapsulation may be preferred in environments where GUE
encapsulation would add unnecessary overhead. For example, certain encapsulation would add unnecessary overhead. For example, certain
low-bandwidth wireless data links may benefit from a reduced low-bandwidth wireless data links may benefit from a reduced
encapsulation overhead. encapsulation overhead.
GUE encapsulation can traverse network paths that are inaccessible to GUE encapsulation can traverse network paths that are inaccessible to
non-UDP encapsulations, e.g., for crossing Network Address non-UDP encapsulations, e.g., for crossing Network Address
Translators (NATs). More and more, network middleboxes are also Translators (NATs). More and more, network middleboxes are also
being configured to discard packets that include anything other than being configured to discard packets that include anything other than
skipping to change at page 62, line 48 skipping to change at page 65, line 24
encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO
control messaging and route determination occur before security control messaging and route determination occur before security
encapsulation is applied for outgoing packets and after security encapsulation is applied for outgoing packets and after security
decapsulation is applied for incoming packets. decapsulation is applied for incoming packets.
AERO is especially well suited for use with VPN system encapsulations AERO is especially well suited for use with VPN system encapsulations
such as OpenVPN [OVPN]. such as OpenVPN [OVPN].
Appendix B. S/TLLAO Extensions for Special-Purpose Links Appendix B. S/TLLAO Extensions for Special-Purpose Links
The AERO S/TLLAO format specified in Section 3.5 includes a Length The AERO S/TLLAO format specified in Section 3.6 includes a Length
value of 5 (i.e., 5 units of 8 octets). However, special-purpose value of 5 (i.e., 5 units of 8 octets). However, special-purpose
links may extend the basic format to include additional fields and a links may extend the basic format to include additional fields and a
Length value larger than 5. Length value larger than 5.
For example, adaptation of AERO to the Aeronautical For example, adaptation of AERO to the Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS) Telecommunications Network with Internet Protocol Services (ATN/IPS)
includes link selection preferences based on transport port numbers includes link selection preferences based on transport port numbers
in addition to the existing DSCP-based preferences. ATN/IPS nodes in addition to the existing DSCP-based preferences. ATN/IPS nodes
maintain a map of transport port numbers to 64 possible preference maintain a map of transport port numbers to 64 possible preference
fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443
maps to preference field 20, UDP port 8060 maps to preference field maps to preference field 20, UDP port 8060 maps to preference field
34, etc. The extended S/TLLAO format for ATN/IPS is shown in 34, etc. The extended S/TLLAO format for ATN/IPS is shown in
Figure 6, where the Length value is 7 and the 'Q(i)' fields provide Figure 7, where the Length value is 7 and the 'Q(i)' fields provide
link preferences for the corresponding transport port number. link preferences for the corresponding transport port number.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 7 | Prefix Length | Reserved | | Type | Length = 7 | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | UDP Port Number | | Interface ID | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ IP Address + + Link-Layer Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 63, line 48 skipping to change at page 66, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ATN/IPS Extended S/TLLAO Format Figure 7: ATN/IPS Extended S/TLLAO Format
Appendix C. Change Log Appendix C. Change Log
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from draft-templin-intarea-6706bis-10 to draft-templin-
intrea-6706bis-11:
o Added The SPAN
Changes from draft-templin-intarea-6706bis-09 to draft-templin- Changes from draft-templin-intarea-6706bis-09 to draft-templin-
intrea-6706bis-10: intrea-6706bis-10:
o Orphaned packets in flight (e.g., when a neighbor cache entry is o Orphaned packets in flight (e.g., when a neighbor cache entry is
in the DEPARTED state) are now forwarded at the link layer instead in the DEPARTED state) are now forwarded at the link layer instead
of at the network layer. Forwarding at the network layer can of at the network layer. Forwarding at the network layer can
result in routing loops and/or excessive delays of forwarded result in routing loops and/or excessive delays of forwarded
packets while the routing system is still reconverging. packets while the routing system is still reconverging.
o Update route optimization to calrify the unsecured nature of the o Update route optimization to clarify the unsecured nature of the
first NS used for route discovery first NS used for route discovery
o Many cleanups and clarifcations on ND messaging parameters o Many cleanups and clarifications on ND messaging parameters
Changes from draft-templin-intarea-6706bis-08 to draft-templin- Changes from draft-templin-intarea-6706bis-08 to draft-templin-
intrea-6706bis-09: intrea-6706bis-09:
o Changed PRL to "MAP list" o Changed PRL to "MAP list"
o For neighbor cache entries, changed "static" to "symmetric", and o For neighbor cache entries, changed "static" to "symmetric", and
"dynamic" to "asymmetric" "dynamic" to "asymmetric"
o Specified Proxy RS/RA exchanges with Servers on behalf of Clients o Specified Proxy RS/RA exchanges with Servers on behalf of Clients
 End of changes. 198 change blocks. 
760 lines changed or deleted 891 lines changed or added

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