< draft-templin-intarea-6706bis-02.txt   draft-templin-intarea-6706bis-03.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, October 5, 2018 Obsoletes: rfc5320, rfc5558, rfc5720, December 17, 2018
rfc6179, rfc6706 (if rfc6179, rfc6706 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 8, 2019 Expires: June 20, 2019
Asymmetric Extended Route Optimization (AERO) Asymmetric Extended Route Optimization (AERO)
draft-templin-intarea-6706bis-02.txt draft-templin-intarea-6706bis-03.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.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 April 8, 2019. This Internet-Draft will expire on June 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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) . . . . . . . . 7
3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 7 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 7
3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9
3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10
3.4. AERO Interface Addresses . . . . . . . . . . . . . . . . 11 3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 11
3.5. AERO Interface Characteristics . . . . . . . . . . . . . 13 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 13
3.6. AERO Interface Initialization . . . . . . . . . . . . . . 16 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 16
3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 16 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 16
3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 16 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 16
3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 17 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 17
3.6.4. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 17 3.6.4. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 17
3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 18 3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 18
3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 19 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 19
3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 20 3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 20
3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 20 3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 20
3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 21 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 21
3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 21 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 21
3.8.5. Processing Return Packets . . . . . . . . . . . . . . 22 3.8.5. Processing Return Packets . . . . . . . . . . . . . . 22
3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 23 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 23
3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 24 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 24
3.11. AERO Interface Data Origin Authentication . . . . . . . . 24 3.11. AERO Interface Data Origin Authentication . . . . . . . . 24
3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 24 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 25
3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 26 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 27
3.14. AERO Router Discovery, Prefix Delegation and 3.14. AERO Router Discovery, Prefix Delegation and
Autoconfiguration . . . . . . . . . . . . . . . . . . . . 30 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 30
3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 30 3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 30
3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 31 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 31
3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 33 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 33
3.15. AERO Interface Route Optimization . . . . . . . . . . . . 35 3.15. AERO Route Optimization . . . . . . . . . . . . . . . . . 35
3.15.1. Reference Operational Scenario . . . . . . . . . . . 35 3.15.1. Reference Operational Scenario . . . . . . . . . . . 35
3.15.2. Concept of Operations . . . . . . . . . . . . . . . 37 3.15.2. Concept of Operations . . . . . . . . . . . . . . . 37
3.15.3. Sending NS Messages . . . . . . . . . . . . . . . . 37 3.15.3. Sending NS Messages . . . . . . . . . . . . . . . . 37
3.15.4. Re-encapsulating and Relaying the NS . . . . . . . . 38 3.15.4. Re-encapsulating and Relaying the NS . . . . . . . . 38
3.15.5. Processing NSs and Sending NAs . . . . . . . . . . . 39 3.15.5. Processing NSs and Sending NAs . . . . . . . . . . . 39
3.15.6. Processing NAs . . . . . . . . . . . . . . . . . . . 40 3.15.6. Processing NAs . . . . . . . . . . . . . . . . . . . 40
3.15.7. Server-Based Route Optimization . . . . . . . . . . 40 3.15.7. Server-Based Route Optimization . . . . . . . . . . 40
3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 42 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 42
3.17. Mobility Management and Quality of Service (QoS) . . . . 43 3.17. Mobility Management and Quality of Service (QoS) . . . . 43
3.17.1. Forwarding Packets on Behalf of Departed Clients . . 44 3.17.1. Forwarding Packets on Behalf of Departed Clients . . 44
3.17.2. Announcing Link-Layer Address and QoS Preference 3.17.2. Announcing Link-Layer Address and/or QoS Preference
Changes . . . . . . . . . . . . . . . . . . . . . . 44 Changes . . . . . . . . . . . . . . . . . . . . . . 44
3.17.3. Bringing New Links Into Service . . . . . . . . . . 44 3.17.3. Bringing New Links Into Service . . . . . . . . . . 44
3.17.4. Removing Existing Links from Service . . . . . . . . 45 3.17.4. Removing Existing Links from Service . . . . . . . . 45
3.17.5. Implicit Mobility Management . . . . . . . . . . . . 45 3.17.5. Implicit Mobility Management . . . . . . . . . . . . 45
3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 45 3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 45
3.18. Multicast Considerations . . . . . . . . . . . . . . . . 46 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 46
4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 46 4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 46
5. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 48 5. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 48
6. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 48 6. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 48
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 7. SEcure Neighbor Discovery (SEND) . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Normative References . . . . . . . . . . . . . . . . . . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.2. Informative References . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 59 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 59
Appendix B. When to Insert an Encapsulation Fragment Header . . 61 Appendix B. When to Insert an Encapsulation Fragment Header . . 61
Appendix C. Autoconfiguration for Constrained Platforms . . . . 61 Appendix C. Autoconfiguration for Constrained Platforms . . . . 62
Appendix D. Operational Deployment Alternatives . . . . . . . . 62 Appendix D. Operational Deployment Alternatives . . . . . . . . 62
D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 62 D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 62
D.2. Operation on Server-less AERO Links . . . . . . . . . . . 62 D.2. Operation on Server-less AERO Links . . . . . . . . . . . 63
D.3. Operation on Client-less AERO Links . . . . . . . . . . . 63 D.3. Operation on Client-less AERO Links . . . . . . . . . . . 63
D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 63 D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 63
D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 63 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 64
D.6. Encapsulation Protocol Version Considerations . . . . . . 63 D.6. Encapsulation Protocol Version Considerations . . . . . . 64
D.7. Extending AERO Links Through Security Gateways . . . . . 64 D.7. Extending AERO Links Through Security Gateways . . . . . 64
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 65 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67
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 4, line 34 skipping to change at page 4, line 35
AERO is applicable to a wide variety of use cases. For example, it AERO is applicable to a wide variety of use cases. For example, it
can be used to coordinate the Virtual Private Network (VPN) links of can be used to coordinate the Virtual Private Network (VPN) links of
mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that
connect into a home enterprise network via public access networks connect into a home enterprise network via public access networks
using services such as OpenVPN [OVPN]. AERO is also applicable to using services such as OpenVPN [OVPN]. AERO is also applicable to
aviation services for both manned and unmanned aircraft where the aviation services for both manned and unmanned aircraft where the
aircraft is treated as a mobile node that can connect an Internet of aircraft is treated as a mobile node that can connect an Internet of
Things (IoT). Other applicable use cases are also in scope. Things (IoT). Other applicable use cases are also in scope.
The remainder of this document presents the AERO specification. The following sections present the AERO specification.
2. Terminology 2. Terminology
The terminology in the normative references applies; the following The terminology in the normative references applies; the following
terms are defined within the scope of this document: terms are defined within the scope of this document:
IPv6 Neighbor Discovery (ND) IPv6 Neighbor Discovery (ND)
an IPv6 control message service for coordinating neighbor an IPv6 control message service for coordinating neighbor
relationships between nodes connected to a common link. The ND relationships between nodes connected to a common link. The ND
service used by AERO is specified in [RFC4861]. service used by AERO is specified in [RFC4861].
skipping to change at page 5, line 13 skipping to change at page 5, line 15
[I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt]. [I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt].
(native) Internetwork (native) Internetwork
a connected IP network topology over which the AERO link virtual a connected IP network topology over which the AERO link virtual
overlay is configured and native peer-to-peer communications are overlay is configured and native peer-to-peer communications are
supported. Example Internetworks include the global public supported. Example Internetworks include the global public
Internet, private enterprise networks, aviation networks, etc. Internet, private enterprise networks, aviation networks, etc.
AERO link AERO link
a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay
configured over an underlying Internetwork. All nodes on the AERO configured over an underlying Internetwork. Nodes on the AERO
link appear as single-hop neighbors from the perspective of the link appear as single-hop neighbors from the perspective of the
virtual overlay even though they may be separated by many virtual overlay even though they may be separated by many
underlying Internetwork hops. The AERO mechanisms can also underlying Internetwork hops. The AERO mechanisms can also
operate over native link types (e.g., Ethernet, WiFi etc.) when a operate over native link types (e.g., Ethernet, WiFi etc.) when
tunnel virtual overlay is not needed. tunneling is not needed.
AERO interface AERO interface
a node's attachment to an AERO link. Since the addresses assigned a node's attachment to an AERO link. Since the addresses assigned
to an AERO interface are managed for uniqueness, AERO interfaces to an AERO interface are managed for uniqueness, AERO interfaces
do not require Duplicate Address Detection (DAD) and therefore set do not require Duplicate Address Detection (DAD) and therefore set
the administrative variable DupAddrDetectTransmits to zero the administrative variable 'DupAddrDetectTransmits' to zero
[RFC4862]. [RFC4862].
AERO address AERO address
an IPv6 link-local address constructed as specified in an IPv6 link-local address constructed as specified in
Section 3.4. Section 3.4.
AERO node AERO node
a node that is connected to an AERO link. a node that is connected to an AERO link.
AERO Client ("Client") AERO Client ("Client")
a node that requests IP PDs from one or more AERO Servers. a node that requests PDs from one or more AERO Servers. Following
Following PD, the Client assigns an AERO address to the AERO PD, the Client assigns a Client AERO address to the AERO interface
interface for use in ND exchanges with other AERO nodes. A node for use in ND exchanges with other AERO nodes. A node that acts
that acts as an AERO Client on one AERO interface can also act as as an AERO Client on one AERO interface can also act as an AERO
an AERO 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 for AERO Clients. The Server assigns an forwarding services for AERO Clients. The Server assigns an
administratively-provisioned IPv6 link-local address to the AERO administratively-provisioned AERO address to the AERO interface to
interface to support the operation of the ND/PD services. An AERO support the operation of the ND/PD services. An AERO Server can
Server can also act as an AERO Relay. 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 an IP router that can relay IP packets between AERO Servers and/or
forward IP packets between the AERO link and the native forward IP packets between the AERO link and the native
Internetwork. Relays are standard IP routers that can be Internetwork. AERO Relays are standard IP routers that do not
purchased from any major network equipment supplier. require any AERO-specific functions.
AERO Proxy ("Proxy") AERO Proxy ("Proxy")
a node that provides proxying services for Clients that cannot a node that provides proxying services, e.g., when the Client is
associate directly with Servers, e.g., when the Client is located located in a secured internal enclave and the Server is located in
in a secured internal enclave and the Server is located in the the external Internetwork. The AERO Proxy is a conduit between
external Internetwork. The AERO Proxy is a conduit between the the secured enclave and the external Internetwork in the same
secured enclave and the external Internetwork in the same manner manner as for common web proxies, and behaves in a similar fashion
as for common web proxies, and behaves in a similar fashion as for as for ND proxies [RFC4389].
ND proxies [RFC4389].
ingress tunnel endpoint (ITE) ingress tunnel endpoint (ITE)
an AERO interface endpoint that injects encapsulated packets into an AERO interface endpoint that injects encapsulated packets into
an AERO link. an AERO link.
egress tunnel endpoint (ETE) egress tunnel endpoint (ETE)
an AERO interface endpoint that receives encapsulated packets from an AERO interface endpoint that receives encapsulated packets from
an AERO link. an AERO link.
underlying network underlying network
skipping to change at page 7, line 10 skipping to change at page 7, line 14
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.
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 and must be no longer than 64 for IPv6 or 32 for IPv4. length.
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).
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 [RFC3315]. these terms from DHCPv6 client/server/relay [RFC3315].
skipping to change at page 11, line 29 skipping to change at page 11, line 29
and Relays (for example, it should be possible to service 1B /64 ACPs and Relays (for example, it should be possible to service 1B /64 ACPs
taken from a /34 ASP and even more for shorter prefixes). In this taken from a /34 ASP and even more for shorter prefixes). In this
way, each set of Relays services a specific set of ASPs that they way, each set of Relays services a specific set of ASPs that they
advertise to the native Internetwork routing system, and each Server advertise to the native Internetwork routing system, and each Server
configures ASP-specific routes that list the correct set of Relays as configures ASP-specific routes that list the correct set of Relays as
next hops. This arrangement also allows for natural incremental next hops. This arrangement also allows for natural incremental
deployment, and can support small scale initial deployments followed deployment, and can support small scale initial deployments followed
by dynamic deployment of additional Clients, Servers and Relays by dynamic deployment of additional Clients, Servers and Relays
without disturbing the already-deployed base. without disturbing the already-deployed base.
Note that in an alternate routing arrangement each set of Relays In an alternate routing arrangement, each set of Relays could
could advertise an aggregated ASP for the link into the native advertise an aggregated ASP for the link into the native Internetwork
Internetwork routing system even though each Relay services only routing system even though each Relay services only smaller segments
smaller segments of the ASP. In that case, a Relay upon receiving a of the ASP. In that case, a Relay upon receiving a packet with a
packet with a destination address covered by the ASP segment of destination address covered by the ASP segment of another Relay can
another Relay can simply tunnel the packet to the other Relay. The simply tunnel the packet to the other Relay. The tradeoff then is
tradeoff then is the penalty for Relay-to-Relay tunneling compared the penalty for Relay-to-Relay tunneling compared with reduced
with reduced routing information in the native routing system. routing information in the native routing system.
A full discussion of the BGP-based routing system used by AERO is A full discussion of the BGP-based routing system used by AERO is
found in [I-D.templin-atn-bgp]. found in [I-D.ietf-rtgwg-atn-bgp].
3.4. AERO Interface Addresses
AERO interface link-local address types include administratively-
provisioned addresses and AERO addresses.
Administratively-provisioned addresses are allocated from the range 3.4. AERO Addresses
fe80::/96 and assigned to Relay and Server AERO interfaces.
Administratively-provisioned addresses MUST be managed for uniqueness
by the administrative authority for the AERO link. The address
fe80:: is reserved as the IPv6 link-local Subnet Router Anycast
address (i.e., the same as for any IPv6 link), and the address
fe80::ffff:ffff is reserved as the "prefix-solicitation" address used
by Clients to bootstrap AERO address autoconfiguration. These
reserved addresses are therefore not available for general
assignment.
An AERO address is an IPv6 link-local address with an embedded prefix A Client's AERO address is an IPv6 link-local address with an
based on an ACP and associated with a Client's AERO interface. AERO interface identifier based on the Client's delegated ACP. Relay and
addresses remain stable as the Client moves between topological Server AERO addresses are assigned from the range fe80::/96 and
locations, i.e., even if its link-layer addresses change. include an administratively-provisioned value in the lower 32 bits.
For IPv6, AERO addresses begin with the prefix fe80::/64 and include For IPv6, Client AERO addresses begin with the prefix fe80::/64 and
in the interface identifier (i.e., the lower 64 bits) a 64-bit prefix include in the interface identifier (i.e., the lower 64 bits) a
taken from one of the Client's IPv6 ACPs. For example, if the AERO 64-bit prefix taken from one of the Client's IPv6 ACPs. For example,
Client receives the IPv6 ACP: if the AERO Client receives the IPv6 ACP:
2001:db8:1000:2000::/56 2001:db8:1000:2000::/56
it constructs its corresponding AERO addresses as: it constructs its corresponding AERO addresses as:
fe80::2001:db8:1000:2000 fe80::2001:db8:1000:2000
fe80::2001:db8:1000:2001 fe80::2001:db8:1000:2001
fe80::2001:db8:1000:2002 fe80::2001:db8:1000:2002
... etc. ... ... etc. ...
fe80::2001:db8:1000:20ff fe80::2001:db8:1000:20ff
For IPv4, AERO addresses are based on an IPv4-mapped IPv6 address For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6
formed from an IPv4 ACP and with a Prefix Length of 96 plus the ACP address formed from an IPv4 ACP and with a Prefix Length of 96 plus
prefix length. For example, for the IPv4 ACP 192.0.2.32/28 the the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28
IPv4-mapped IPv6 ACP is: the IPv4-mapped IPv6 ACP is:
0:0:0:0:0:FFFF:192.0.2.16/124 0:0:0:0:0:FFFF:192.0.2.16/124
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
When the Server delegates ACPs to the Client, both the Server and Relay and Server AERO addresses are allocated from the range
Client use the lowest-numbered AERO address from the first ACP fe80::/96, and MUST be managed for uniqueness by the administrative
delegation as the "base" AERO address (for example, for the ACP authority for the link. For interfaces that assign static IPv4
2001:db8:1000:2000::/56 the base AERO address is addresses, the lower 32 bits of the AERO address includes the IPv4
fe80::2001:db8:1000:2000). The Client then assigns the base AERO address, e.g., for the IPv4 address 192.0.2.1 the corresponding AERO
address to the AERO interface and uses it for the purpose of address is fe80::192.0.2.1. For other interfaces, the lower 32 bits
maintaining the neighbor cache entry. The Server likewise uses the of the AERO address includes a unique integer value, e.g., fe80::1,
AERO address as its index into the neighbor cache for this Client. fe80::2, fe80::3, etc. (Note that the address fe80:: is reserved as
the IPv6 link-local Subnet Router Anycast address [RFC4291], and the
address fe80::ffff:ffff is reserved as the prefix solicitation
address; hence, these values are not available for administrative
assignment.)
When the Server delegates ACPs to the Client, the lowest-numbered
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
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
purpose of maintaining the neighbor cache entry. The Server likewise
uses the AERO address as its index into the neighbor cache for this
Client.
If the Client has multiple AERO addresses (i.e., when there are If the Client has multiple AERO addresses (i.e., when there are
multiple ACPs and/or ACPs with short prefix lengths), the Client multiple ACPs and/or ACPs with prefix lengths shorter than /64), the
originates ND messages using the base AERO address as the source Client originates ND messages using the base AERO address as the
address and accepts and responds to ND messages destined to any of source address and accepts and responds to ND messages destined to
its AERO addresses as equivalent to the base AERO address. In this any of its AERO addresses as equivalent to the base AERO address. In
way, the Client maintains a single neighbor cache entry that may be this way, the Client maintains a single neighbor cache entry that may
indexed by multiple AERO addresses. be indexed by multiple AERO addresses.
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 interfaces additionally reserve an IPv6 prefix to support IPv6 AERO links additionally reserve an IPv6 prefix to support IPv6 ND
ND message exchanges between Servers. A Unique Local Address (ULA) message exchanges between Servers on the link. Although any non-
prefix [RFC4389] would be a good candidate for the reserved prefix, link-local IPv6 prefix could be reserved for this purpose, a Unique
since it is not routable outside of the AERO link. An address with Local Address (ULA) prefix [RFC4389] would be a good candidate since
interface identifier set to 0 taken from the reserved prefix is used it is not routable outside of the AERO link. For example, if the
as the AERO Server Subnet Router Anycast address. For example, if reserved (ULA) prefix is fd00:db8::/64 the AERO Server Subnet Router
the reserved prefix is the ULA prefix fd00:db8::/64 the AERO Server Anycast Address is fd00:db8::.
Subnet Router Anycast Address is fd00:db8::.
A full discussion of the AERO addressing service is found in
[I-D.templin-6man-aeroaddr].
3.5. AERO Interface Characteristics 3.5. AERO Interface Characteristics
AERO interfaces use encapsulation (see: Section 3.9) to exchange AERO interfaces use encapsulation (see: Section 3.9) 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), Neighbor Advertisement (NA) and Redirect
neighbor cache management. for 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 2:
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 | Reserved | | Type | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | UDP Port Number | | Interface ID | UDP Port Number |
skipping to change at page 14, line 46 skipping to change at page 14, line 46
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 Reserved is set to the value '0' on transmission and ignored on o Reserved 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. underlying interface of the AERO node. Once the node has assigned
an Interface ID to an underlyng interface, the assignment must
remain unchanged until the node fully detaches from the AERO link.
o UDP Port Number and IP Address are set to the addresses used by o UDP Port Number and IP Address are set to the addresses used by
the AERO node when it sends encapsulated packets over the 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, UDP Port Number is set to '0'. When the
encapsulation IP address family is IPv4, IP Address is formed as encapsulation IP address family is IPv4, IP Address is formed as
an IPv4-mapped IPv6 address as specified in Section 3.4. an IPv4-mapped IPv6 address as specified in Section 3.4.
o P(i) is a set of 64 Preference values 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
wireless links. These links are typically used "one at a time" with wireless links. These links are typically used "one at a time" with
low-cost WLAN preferred and highly-available cellular wireless as a low-cost WLAN preferred and highly-available cellular wireless as a
skipping to change at page 15, line 32 skipping to change at page 15, line 34
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 closed network that is separated
from the open Internetwork by a Network Address Translator (NAT). from the open Internetwork by a Network Address Translator (NAT).
The NAT does not participate in any AERO control message The NAT does not participate in any AERO control message
signaling, but the AERO Server can issue AERO control messages on signaling, but the AERO Server can issue control messages on
behalf of the Client. behalf of the Client.
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.
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 (rather than the Server) can VPNed interfaces, the AERO Proxy can also issue control messages
issue control message 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.
If a Client's multiple underlying interfaces are used "one at a time" If a Client's multiple underlying interfaces are used "one at a time"
(i.e., all other interfaces are in standby mode while one interface (i.e., all other interfaces are in standby mode while one interface
is active), then ND messages include only a single S/TLLAO with is active), then ND messages include only a single S/TLLAO with
Interface ID set to a constant value. In that case, the Client would Interface ID set to a constant value. In that case, the Client would
appear to have a single underlying interface but with a dynamically appear to have a single underlying interface but with a dynamically
skipping to change at page 16, line 18 skipping to change at page 16, line 22
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 NAT or Proxy 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 sets both UDP Port Number
and IP Address to 0 to indicate that the addresses are unspecified. and IP Address to 0 to indicate that the addresses are unspecified at
the network layer and must instead be derived from the 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.6. AERO Interface Initialization
3.6.1. AERO Relay Behavior 3.6.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 link-local address fe80::ID to the administratively-provisioned AERO address fe80::ID to the interface.
interface. Each fe80::ID address MUST be unique among all AERO nodes Each fe80::ID address MUST be unique among all AERO nodes on the
on the link. The Relay then engages in a dynamic routing protocol link. The Relay then engages in a dynamic routing protocol session
session with one or more Servers and all other Relays on the link with one or more Servers and all other Relays on the link (see:
(see: Section 3.3), and advertises its assigned ASPs into the native Section 3.3), and advertises its assigned ASPs into the native
Internetwork. Each Relay subsequently maintains an IP forwarding Internetwork. Each Relay subsequently maintains an IP forwarding
table entry for each active ACP covered by its ASP(s). table entry for each active ACP covered by its ASP(s).
3.6.2. AERO Server Behavior 3.6.2. AERO Server Behavior
When a Server enables an AERO interface, it assigns an When a Server enables an AERO interface, it assigns an
administratively-provisioned link-local address fe80::ID the same as administratively-provisioned AERO address fe80::ID the same as for
for Relays. The Server further configures a service to facilitate Relays. The Server further configures a service to facilitate ND/PD
ND/PD exchanges with AERO Clients. The Server maintains neighbor exchanges with AERO Clients. The Server maintains neighbor cache
cache entries for one or more Relays on the link, and manages per- entries for one or more Relays on the link, and manages per-Client
Client neighbor cache entries and IP forwarding table entries based neighbor cache entries and IP forwarding table entries based on
on control message exchanges. Each Server also engages in a dynamic control message exchanges. The Server also engages in a dynamic
routing protocol with their neighboring Relays (see: Section 3.3). routing protocol with its neighboring Relays (see: 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 an NA/RA message. The Server authenticates the message and returns an NA/RA message. (When the
further provides a simple link-layer conduit between AERO interface Server receives an unsolicited NA message, it likewise authenticates
neighbors. In particular, when a packet sent by a source Client the message and processes it locally.) The Server further provides a
arrives on the Server's AERO interface and is destined to another simple link-layer conduit between AERO interface neighbors. In
AERO node, the Server forwards the packet from within the AERO particular, when a packet sent by a source Client arrives on the
interface driver at the link layer without ever disturbing the Server's AERO interface and is destined to another AERO node, the
network layer. Server forwards the packet from within the AERO interface at the link
layer without ever disturbing the network layer.
3.6.3. AERO Client Behavior 3.6.3. 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.
See [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters See [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 can register After the initial ND/PD message exchange, the Client assigns AERO
additional underlying interfaces with the Server by sending a simple addresses to the AERO interface based on the delegated prefix(es).
RS message (i.e., one with no PD parameters) over each underlying The Client can then register additional underlying interfaces with
interface using its base AERO address as the source network layer the Server by sending a simple RS message (i.e., one with no PD
address. The Server will update its neighbor cache entry for the parameters) over each underlying interface using its base AERO
Client and return a simple RA message. address as the source network layer address. The Server will update
its neighbor cache entry for the Client and return a simple RA
message.
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 correspondent Clients. When the Client and each of its active correspondent Clients. When the Client
receives ND messages on the AERO interface it updates or creates receives ND messages on the AERO interface it updates or creates
neighbor cache entries, including link-layer address and QoS neighbor cache entries, including link-layer address and QoS
preferences. preferences.
3.6.4. AERO Proxy Behavior 3.6.4. AERO Proxy Behavior
When a Proxy enables an AERO interface, it maintains per-Client proxy When a Proxy enables an AERO interface, it maintains per-Client proxy
neighbor cache entries based on control message exchanges. Proxies neighbor cache entries based on control message exchanges. Proxies
forward packets between their associated Clients and the Clients' forward packets between their associated Clients and each Client's
associated Servers. associated Servers.
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 proxy neighbor cache entry and
sends a corresponding RS message to a Server selected by the Client sends a proxyed RS message to a Server selected by the Client while
while using its own link-layer address as the source address. When using its own link-layer address as the source address. When the
the Server returns an RA message, the Proxy completes the proxy Server returns an RA message, the Proxy completes the proxy neighbor
neighbor cache entry based on autoconfiguration information in the RA cache entry based on autoconfiguration information in the RA and
and sends a corresponding RA to the Client while using its own link- sends a proxyed RA to the Client while using its own link-layer
layer address as the source address. The Client, Server and Proxy address as the source address. The Client, Server and Proxy will
will then have the necessary state for managing the proxy neighbor then have the necessary state for managing the proxy neighbor
association. association.
3.7. AERO Interface Neighbor Cache Maintenance 3.7. 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, the same as for any IPv6 interface [RFC4861]. AERO interface link, the same as for any IPv6 interface [RFC4861]. AERO interface
neighbor cache entries are said to be one of "permanent", "static", neighbor cache entries are said to be one of "permanent", "static",
"proxy" or "dynamic". "proxy" or "dynamic".
skipping to change at page 19, line 5 skipping to change at page 19, line 7
dynamic neighbor cache entry for the source network-layer and link- dynamic neighbor cache entry for the source network-layer and link-
layer addresses. The node then sets a "ReportTime" variable in the layer addresses. The node then sets a "ReportTime" variable in the
neighbor cache entry to REPORT_TIME seconds. The node resets neighbor cache entry to REPORT_TIME seconds. The node resets
ReportTime when it receives a new NS message, and otherwise ReportTime when it receives a new NS message, and otherwise
decrements ReportTime while no NS messages have been received. It is decrements ReportTime while no NS messages have been received. It is
RECOMMENDED that REPORT_TIME be set to the default constant value 40 RECOMMENDED that REPORT_TIME be set to the default constant value 40
seconds to allow a 10 second window so that the AERO route seconds to allow a 10 second window so that the AERO route
optimization procedure can converge before ReportTime decrements optimization procedure can converge before ReportTime decrements
below FORWARD_TIME (see below). below FORWARD_TIME (see below).
When a source AERO node receives a valid NA message that matches its When a source AERO node receives a valid NA message response to its
NS message, it creates or updates a dynamic neighbor cache entry for NS message, it creates or updates a dynamic neighbor cache entry for
the target network-layer and link-layer addresses. The node then the target network-layer and link-layer addresses. The node then
sets a "ForwardTime" variable in the neighbor cache entry to sets a "ForwardTime" variable in the neighbor cache entry to
FORWARD_TIME seconds and uses this value to determine whether packets FORWARD_TIME seconds and uses this value to determine whether packets
can be forwarded directly to the correspondent, i.e., instead of via can be forwarded directly to the correspondent, i.e., instead of via
a default route. The node resets ForwardTime when it receives a new a default route. The node resets ForwardTime when it receives a new
NA, and otherwise decrements ForwardTime while no further NA messages NA, and otherwise decrements ForwardTime while no further NA messages
arrive. It is RECOMMENDED that FORWARD_TIME be set to the default arrive. It is RECOMMENDED that FORWARD_TIME be set to the default
constant value 30 seconds to match the default REACHABLE_TIME value constant value 30 seconds to match the default REACHABLE_TIME value
specified in [RFC4861]. specified in [RFC4861].
skipping to change at page 20, line 21 skipping to change at page 20, line 25
interface with the highest preference. AERO nodes keep track of interface with the highest preference. AERO nodes keep track of
which underlying interfaces are currently "reachable" or which underlying interfaces are currently "reachable" or
"unreachable", and only use "reachable" interfaces for forwarding "unreachable", and only use "reachable" interfaces for forwarding
purposes. 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 link-local address. the same as an administratively-provisioned AERO address.
3.8.1. Client Forwarding Algorithm 3.8.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 a dynamic neighbor cache entry that layer the Client searches for a dynamic 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 static Otherwise, the Client uses the link-layer address in a static
neighbor cache entry for a Server as the encapsulation address neighbor cache entry for a Server as the encapsulation address
skipping to change at page 22, line 8 skipping to change at page 22, line 10
layer, the Relay searches its IP forwarding table for an ACP entry layer, the Relay searches its IP forwarding table for an ACP entry
that matches the destination the same as for any IP router. If there that matches the destination the same as for any IP router. If there
is a match, the Relay uses the link-layer address in the is a match, the Relay uses the link-layer address in the
corresponding neighbor cache entry as the link-layer address for corresponding neighbor cache entry as the link-layer address for
encapsulation and forwards the packet to the AERO neighbor. encapsulation and forwards the packet to the AERO neighbor.
Otherwise, the Relay drops the packet and returns a network-layer Otherwise, the Relay drops the packet and returns a network-layer
ICMP Destination Unreachable message subject to rate limiting (see: ICMP Destination Unreachable message subject to rate limiting (see:
Section 3.13). Section 3.13).
When an IP packet enters a Relay's AERO interface from the link- When an IP packet enters a Relay's AERO interface from the link-
layer, (i.e., when it receives a packet from a Server via a tunnel) layer, (i.e., when it receives an encapsulated packet from a Server)
the Relay processes the packet as follows: the Relay 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 if the destination
matches one of the Relay's own addresses, the Relay decapsulates matches one of the Relay's own addresses, the Relay decapsulates
the packet and forwards it to the network layer where it will be the packet and forwards it to the network layer where it will be
subject to either IP forwarding or local delivery. subject to 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 ACP entry in the IP forwarding
table the Relay first determines whether the neighbor is the same table the Relay first determines whether the neighbor is the same
as the one it received the packet from. If so the Relay MUST drop as the one it received the packet from. If so the Relay MUST drop
skipping to change at page 23, line 15 skipping to change at page 23, line 17
3.9. AERO Interface Encapsulation and Re-encapsulation 3.9. 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). For an alternate encapsulation format (e.g., see: Appendix A, [RFC2784],
packets entering the AERO interface from the network layer, the AERO [RFC8086], [RFC4301], etc.). For packets entering the AERO interface
interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" from the network layer, the AERO interface copies the "TTL/Hop
[RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion Limit", "Type of Service/Traffic Class" [RFC2983], "Flow
Experienced" [RFC3168] values in the packet's IP header into the Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168]
corresponding fields in the encapsulation IP header. For packets values in the packet's IP header into the corresponding fields in the
undergoing re-encapsulation, the AERO interface instead copies these encapsulation IP header. For packets undergoing re-encapsulation,
values from the original encapsulation IP header into the new the AERO interface instead copies these values from the original
encapsulation header, i.e., the values are transferred between encapsulation IP header into the new encapsulation header, i.e., the
encapsulation headers and *not* copied from the encapsulated packet's values are transferred between encapsulation headers and *not* copied
network-layer header. (Note especially that by copying the TTL/Hop from the encapsulated packet's network-layer header. (Note
Limit between encapsulation headers the value will eventually especially that by copying the TTL/Hop Limit between encapsulation
decrement to 0 if there is a (temporary) routing loop.) For IPv4 headers the value will eventually decrement to 0 if there is a
encapsulation/re-encapsulation, the AERO interface sets the DF bit as (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation,
discussed in Section 3.12. the AERO interface sets the DF bit as discussed in Section 3.12.
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
skipping to change at page 24, line 5 skipping to change at page 24, line 7
specification. specification.
Clients normally use the IP address of the underlying interface as Clients normally use the IP address of the underlying interface as
the encapsulation source address. If the underlying interface does the encapsulation source address. If the underlying interface does
not have an IP address, however, the Client uses an IP address taken not have an IP address, however, the Client uses an IP address taken
from an ACP as the encapsulation source address (assuming the node from an ACP as the encapsulation source address (assuming the node
has some way of injecting the ACP into the underlying network routing has some way of injecting the ACP into the underlying network routing
system). For IPv6 addresses, the Client normally uses the ACP Subnet system). For IPv6 addresses, the Client normally uses the ACP Subnet
Router Anycast address [RFC4291]. Router Anycast address [RFC4291].
Encapsulation between Servers and Relays can use standard mechanisms When GUE encapsulation is not available, encapsulation between
such as Generic Routing Encapsulation (GRE) [RFC2784] and IPSec Servers and Relays can use standard mechanisms such as Generic
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.10. 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.
skipping to change at page 24, line 42 skipping to change at page 24, line 45
o AERO Clients and Servers accept encapsulated packets if there is a o AERO Clients and Servers accept encapsulated packets if there is a
static neighbor cache entry with a link-layer address that matches static neighbor cache entry with a link-layer address that matches
the packet's link-layer source address. the packet's link-layer source address.
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 environments where source address spoofing is as OpenVPN [OVPN]. In some environments, however, it may be
not considered a threat, however, it may be sufficient to require sufficient to require signatures only for ND control plane messages
signatures only for ND control plane messages and omit signatures for (see: Section 10) and omit signatures for data plane messages.
data plane messages.
3.12. AERO Interface Packet Size Issues 3.12. 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.
skipping to change at page 29, line 21 skipping to change at page 29, line 21
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.17.6. with the old Server as specified in Section 3.17.6.
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 static neighbor Clients, the Server SHOULD sends to one of its static 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 a receives an explicit ND/PD release message or if the PD receives an explicit ND/PD release message or if the PD lifetime
lifetime expires. In that case, the Server MUST release the expires. In that case, the Server MUST release the Client's
Client's delegated ACP, withdraw the ACP from the AERO routing delegated ACP, withdraw the ACP from the AERO routing system and
system and delete the neighbor cache entry. delete the neighbor cache entry.
o When an AERO Relay or Server receives link-layer Destination o When an AERO Relay or Server receives link-layer Destination
Unreachable messages in response to an encapsulated packet that it Unreachable messages in response to an encapsulated packet that it
sends to one of its permanent neighbors, it treats the messages as sends to one of its permanent neighbors, it treats the messages as
an indication that the path to the neighbor may be failing. an indication that the path to the neighbor may be failing.
However, the dynamic routing protocol should soon reconverge and However, the dynamic routing protocol should soon reconverge and
correct the temporary outage. correct the temporary outage.
When an AERO Relay receives a packet for which the network-layer When an AERO Relay receives a packet for which the network-layer
destination address is covered by an ASP, if there is no more- destination address is covered by an ASP, if there is no more-
skipping to change at page 31, line 36 skipping to change at page 31, line 36
address as the source address. If the Client's underlying interface address as the source address. If the Client's underlying interface
connects to a subnetwork that supports ACP injection, the Client can connects to a subnetwork that supports ACP injection, the Client can
use the ACP's Subnet Router Anycast address as the link-layer source use the ACP's Subnet Router Anycast address as the link-layer source
address. address.
The Client next includes one or more SLLAOs in the RS message The Client next includes one or more SLLAOs in the RS message
formatted as described in Section 3.5 to register its link-layer formatted as described in Section 3.5 to register its link-layer
address(es) with the Server. The first SLLAO MUST correspond to the address(es) with the Server. The first SLLAO MUST correspond to the
underlying interface over which the Client will send the RS message. underlying interface over which the Client will send the RS message.
The Client MAY include additional SLLAOs specific to other underlying The Client MAY include additional SLLAOs specific to other underlying
interfaces, but if so it sets the UDP Port Number and IP Address interfaces, but if so it sets their UDP Port Number and IP Address
fields to 0. The Client can instead register additional link-layer fields to 0. The Client can instead register additional link-layer
addresses with the Server by sending additional RS messages including addresses with the Server by sending additional RS messages including
SLLAOs via other underlying interfaces after the initial RS/RA SLLAOs via other underlying interfaces after the initial RS/RA
exchange. exchange.
The Client then sends the RS message to the AERO Server and waits for The Client then sends the RS message to the AERO Server and waits for
an RA message reply (see Section 3.14.3) while retrying MAX_RETRY an RA message reply (see Section 3.14.3) while retrying MAX_RETRY
times until an RA is received. If the Client receives no RAs, or if times until an RA is received. If the Client receives no RAs, or if
it receives an RA with Router Lifetime set to 0 and/or with no ACP PD it receives an RA with Router Lifetime set to 0 and/or with no ACP PD
parameters, the Client SHOULD discontinue autoconfiguration attempts parameters, the Client SHOULD discontinue autoconfiguration attempts
skipping to change at page 34, line 23 skipping to change at page 34, line 23
Client PD messages, and returns an RA reply. The Server may also Client PD messages, and returns an RA reply. The Server may also
issue an unsolicited RA message with PD reconfigure parameters to issue an unsolicited RA message with PD reconfigure parameters to
inform the Client that it needs to renegotiate its PDs. inform the Client that it needs to renegotiate its PDs.
3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 3.14.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 driver module can act as a case, the Server's AERO interface module can act as a Lightweight
Lightweight DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from
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
message parameters and uses them to fabricate an IPv6/UDP/DHCPv6 message parameters and uses them to fabricate an IPv6/UDP/DHCPv6
message. It sets the IPv6 source address to the source address of message. It sets the IPv6 source address to the source address of
the RS message, sets the IPv6 destination address to the RS message, sets the IPv6 destination address to
'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values
that will be understood by the DHCPv6 server. that will be understood by the DHCPv6 server.
The LDRA then wraps the message in a Relay-Forward message header and The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message
includes an Interface-ID option that includes enough information to header and includes an 'Interface-Id' option that includes enough
allow the LDRA to forward the resulting Reply message back to the information to allow the LDRA to forward the resulting Reply message
Client (e.g., the Client's link-layer addresses, a security back to the Client (e.g., the Client's link-layer addresses, a
association identifier, etc.). The LDRA also wraps the information security association identifier, etc.). The LDRA also wraps the
in all of the SLLAO options from the RS message into the Interface-ID information in all of the SLLAO options from the RS message into the
option, then forwards the message to the DHCPv6 server. Interface-Id option, then forwards the message to the DHCPv6 server.
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 fabricate an RA response to the Client. uses the DHCPv6 message to fabricate 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. AERO Interface Route Optimization 3.15. AERO Route Optimization
When a source Client forwards packets to a prospective correspondent When a source Client forwards packets to a prospective correspondent
Client within the same AERO link domain (i.e., one for which the Client within the same AERO link domain (i.e., one for which the
packet's destination address is covered by an ASP), the source Client packet's destination address is covered by an ASP), the source Client
MAY initiate an AERO link route optimization procedure. The MAY initiate an AERO link route optimization procedure. The
procedure is based on an exchange of IPv6 ND messages using a chain procedure is based on an exchange of IPv6 ND messages using a chain
of AERO Servers and Relays as a trust basis. of AERO Servers and Relays as a trust basis.
Although the Client is responsible for initiating route optimization, Although the Client is responsible for initiating route optimization,
the Server is the policy enforcement point that determines whether the Server is the policy enforcement point that determines whether
route optimization is permitted. For example, on some AERO links route optimization is permitted. For example, on some AERO links
route optimization would allow traffic to circumvent critical route optimization would allow traffic to circumvent critical
network-based traffic inspection points. In those cases, the Server network-based traffic inspection points. In those cases, the Server
can simply discard any route optimization messages instead of can simply discard any route optimization messages instead of
forwarding them. forwarding them.
The following sections specify the AERO link route optimization The following sections specify the AERO route optimization procedure.
procedure.
3.15.1. Reference Operational Scenario 3.15.1. Reference Operational Scenario
Figure 4 depicts the AERO link route optimization reference Figure 4 depicts the AERO route optimization reference operational
operational scenario, using IPv6 addressing as the example (while not scenario, using IPv6 addressing as the example (while not shown, a
shown, a corresponding example for IPv4 addressing can be easily corresponding example for IPv4 addressing can be easily constructed).
constructed). The figure shows an AERO Relay ('R1'), two AERO The figure shows an AERO Relay ('R1'), two AERO Servers ('S1', 'S2'),
Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary two AERO Clients ('C1', 'C2') and two ordinary IPv6 hosts ('H1',
IPv6 hosts ('H1', 'H2'): 'H2'):
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
| Server S1 | | Relay R1 | | Server S2 | | Server S1 | | Relay R1 | | Server S2 |
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
fe80::2 fe80::1 fe80::3 fe80::2 fe80::1 fe80::3
L2(S1) L2(R1) L2(S2) L2(S1) L2(R1) L2(S2)
| | | | | |
X-----+-----+------------------+-----------------+----+----X X-----+-----+------------------+-----------------+----+----X
| AERO Link | | AERO Link |
L2(C1) L2(C2) L2(C1) L2(C2)
skipping to change at page 36, line 29 skipping to change at page 36, line 29
| | | |
.-. .-. .-. .-.
,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-.
.-(_ IP )-. +-------+ +-------+ .-(_ IP )-. .-(_ IP )-. +-------+ +-------+ .-(_ IP )-.
(__ EUN )--|Host H1| |Host H2|--(__ EUN ) (__ EUN )--|Host H1| |Host H2|--(__ EUN )
`-(______)-' +-------+ +-------+ `-(______)-' `-(______)-' +-------+ +-------+ `-(______)-'
Figure 4: AERO Reference Operational Scenario Figure 4: AERO Reference Operational Scenario
In Figure 4, Relay ('R1') assigns the administratively-provisioned In Figure 4, Relay ('R1') assigns the administratively-provisioned
link-local address fe80::1 to its AERO interface with link-layer AERO address fe80::1 to its AERO interface with link-layer address
address L2(R1), Server ('S1') assigns the address fe80::2 with link- L2(R1), Server ('S1') assigns the address fe80::2 with link-layer
layer address L2(S1), and Server ('S2') assigns the address fe80::3 address L2(S1), and Server ('S2') assigns the address fe80::3 with
with link-layer address L2(S2). Servers ('S1') and ('S2') next link-layer address L2(S2). Servers ('S1') and ('S2') next arrange to
arrange to add their link-layer addresses to a published list of add their link-layer addresses to a published list of valid Servers
valid Servers for the AERO link. for the AERO link.
AERO Client ('C1') receives the ACP 2001:db8:0::/48 in an ND/PD AERO Client ('C1') receives the ACP 2001:db8:0::/48 in an ND/PD
exchange via AERO Server ('S1') then assigns the address exchange via AERO Server ('S1') then assigns the address
fe80::2001:db8:0:0 to its AERO interface with link-layer address fe80::2001:db8:0:0 to its AERO interface with link-layer address
L2(C1). Client ('C1') configures a default route and neighbor cache L2(C1). Client ('C1') configures a default route and neighbor cache
entry via the AERO interface with next-hop address fe80::2 and link- entry via the AERO interface with next-hop address fe80::2 and link-
layer address L2(S1), then sub-delegates the ACP to its attached layer address L2(S1), then sub-delegates the ACP to its attached
EUNs. IPv6 host ('H1') connects to the EUN, and configures the EUNs. IPv6 host ('H1') connects to the EUN, and configures the
address 2001:db8:0::1. address 2001:db8:0::1.
skipping to change at page 38, line 43 skipping to change at page 38, line 43
When Server ('S1') receives an NS message from Client ('C1'), it When Server ('S1') receives an NS message from Client ('C1'), it
first verifies that the SLLAOs in the NS are a proper subset of the first verifies that the SLLAOs in the NS are a proper subset of the
link-layer addresses in Client ('C1')'s neighbor cache entry. If the link-layer addresses in Client ('C1')'s neighbor cache entry. If the
Client's SLLAOs are not acceptable, Server ('S1') discards the Client's SLLAOs are not acceptable, Server ('S1') discards the
message. message.
Server ('S1') then examines the network-layer destination address of Server ('S1') then examines the network-layer destination address of
the NS to determine the next hop toward Client ('C2') by searching the NS to determine the next hop toward Client ('C2') by searching
for the AERO address in the neighbor cache. Since Client ('C2') is for the AERO address in the neighbor cache. Since Client ('C2') is
not one of its neighbors, Server ('S1') then inserts an additional not one of its neighbors, Server ('S1') then inserts an additional
layer of encapsulation between the outer IP header and the NS message layer of encapsulation between the outer IP header and the NS
proper. This mid-layer IP header uses the AERO Server Subnet Router message. This mid-layer IP header uses the AERO Server Subnet Router
Anycast address as the source address and the Subnet Router Anycast Anycast address as the source address and the Subnet Router Anycast
address corresponding to Client ("C2")'s AERO address as the address corresponding to Client ("C2")'s AERO address as the
destination address (in this case, C2's Subnet Router Anycast address destination address (in this case, C2's Subnet Router Anycast address
is 2001:db8:1:0::). The Server then forwards this double- is 2001:db8:1:0::). The Server then forwards this double-
encapsulated NS message to Relay ('R1') by changing the link-layer encapsulated NS message to Relay ('R1') by changing the link-layer
source address of the message to 'L2(S1)' and changing the link-layer source address of the message to 'L2(S1)' and changing the link-layer
destination address to 'L2(R1)'. Server ('S1') finally forwards the destination address to 'L2(R1)'. Server ('S1') finally forwards the
message to Relay ('R1') without decrementing the network-layer TTL/ message to Relay ('R1') without decrementing the network-layer TTL/
Hop Limit field. Hop Limit field.
skipping to change at page 40, line 7 skipping to change at page 40, line 7
link-layer address of Client ('C1')). link-layer address of Client ('C1')).
o the network-layer source address is set to fe80::2001:db8:1:0 o the network-layer source address is set to fe80::2001:db8:1:0
(i.e., the base AERO address of Client ('C2')). (i.e., the base AERO address of Client ('C2')).
o the network-layer destination address is set to fe80::2001:db8:0:0 o the network-layer destination address is set to fe80::2001:db8:0:0
(i.e., the base AERO address of Client ('C1')). (i.e., the base AERO address of Client ('C1')).
o the Type is set to 136. o the Type is set to 136.
o The Target Address is set to the Target Address field in the NS o the Target Address is set to the Target Address field in the NS
message. message.
o the message includes one or more TLLAOs set to appropriate values o the message includes one or more TLLAOs set to appropriate values
for Client ('C2')'s native underlying interfaces. for Client ('C2')'s native underlying interfaces.
o the message includes one or more RIOs that include Client ('C2')'s o the message includes one or more RIOs that include Client ('C2')'s
ACPs [I-D.templin-6man-rio-redirect]. ACPs [I-D.templin-6man-rio-redirect].
o the message SHOULD include a Timestamp option and MUST echo the o the message SHOULD include a Timestamp option and MUST echo the
Nonce option received in the NS (i.e., if a Nonce option was Nonce option received in the NS (i.e., if a Nonce option was
skipping to change at page 41, line 14 skipping to change at page 41, line 14
SLLAO with a "Report-To" address in the route optimization NS SLLAO with a "Report-To" address in the route optimization NS
messages it sends. The "Report-To" address must be one of the source messages it sends. The "Report-To" address must be one of the source
Server's globally routable IP addresses. Server's globally routable IP addresses.
In the same way, the target Client may serve as a route optimization In the same way, the target Client may serve as a route optimization
target if it has only native interfaces. If some or all of the target if it has only native interfaces. If some or all of the
target Client's underlying interfaces are Direct, NATed, Proxyed or target Client's underlying interfaces are Direct, NATed, Proxyed or
VPNed the target Server must instead serve as the route optimization VPNed the target Server must instead serve as the route optimization
target. In that case, when the source Server sends an NS message the target. In that case, when the source Server sends an NS message the
target Server prepares an NA response the same as if it were the target Server prepares an NA response the same as if it were the
target Client (see: Section 3.15.5). target Client (see: Section 3.15.5) and does not forward the NS.
When the target Server sends an NA response to a route optimization When the target Server sends an NA response to a route optimization
NS, it includes a Timestamp option, any necessary security options, NS, it includes a Timestamp option, any necessary security options,
and TLLAOs corresponding to the target Client's underlying and TLLAOs corresponding to the target Client's underlying
interfaces. The target Server writes the link-layer address of the interfaces. The target Server writes the link-layer address of the
Client in TLLAOs corresponding to native underlying interfaces, Client in TLLAOs corresponding to native underlying interfaces,
writes the link-layer address of the Proxy in TLLAOs corresponding to writes the link-layer address of the Proxy in TLLAOs corresponding to
Proxyed underlying interfaces and writes its own link-layer address Proxyed underlying interfaces and writes its own link-layer address
in TLLAOs corresponding to other interfaces. The Interface ID and in TLLAOs corresponding to other interfaces. The Interface ID and
QoS Preference values in the TLLAOs are those supplied by the target QoS Preference values in the TLLAOs are those supplied by the target
Client during ND exchanges with the target Server. The target Server Client during ND exchanges with the target Server. The target Server
then establishes a dynamic neighbor cache entry for the source with then establishes a dynamic neighbor cache entry for the source with
ReportTime set to REPORT_TIME seconds and with a "Report-To" address ReportTime set to REPORT_TIME seconds and with a "Report-To" address
set to the address of the source. set to the address of the source.
When the source Server receives the NA response, it creates or When the source Server receives the NA response, it creates or
updates a dynamic neighbor cache entry for the target with updates a dynamic neighbor cache entry for the target with
ForwardTime set to FORWARD_TIME seconds and with the information ForwardTime set to FORWARD_TIME seconds and with the information
provided in the TLLAOs as the link-layer addresses and preference provided in the TLLAOs as the link-layer addresses and preference
values for the Client. The source Server then translates the values for the target. The source Server then translates the
solicited NA message into an unsolicited NA message by changing the solicited NA message into an unsolicited NA message by changing the
source address to its own link-local address, changing the source address to its own link-local address, changing the
destination address to all-nodes multicast, recalculating checksums destination address to all-nodes multicast, recalculating checksums
and any security options, and including the Timestamp option as it and any security options, and including the Timestamp option as it
appeared in the original solicited NA. The source Server then appeared in the original solicited NA. The source Server then
retains this message for subsequent transmission to any source retains this message for subsequent on-demand transmission to any
neighbors that send packets to the target within the current source neighbors that send packets to the target within the current
ForwardTime window. ForwardTime window.
While ForwardTime is greater than 0, the source Server sends While ForwardTime is greater than 0, the source Server sends
unsolicited NA messages (subject to rate limiting) in response to unsolicited NA messages (subject to rate limiting) in response to
data packets from source Clients or Proxies that are destined to the data packets from source Clients or Proxies that are destined to the
target Client. The unsolicited NA messages update source Client and target Client. The unsolicited NA messages update source Client and
Proxy dynamic neighbor cache entries with ForwardTime set to Proxy dynamic neighbor cache entries with ForwardTime set to
FORWARD_TIME minus the difference between the current time and the NA FORWARD_TIME minus the difference between the current time and the NA
Timestamp. Subsequent packets from the source destined to the target Timestamp. Subsequent packets from the source destined to the target
Client then travel via the route-optimized path instead of through Client then travel via the route-optimized path instead of through
skipping to change at page 43, line 30 skipping to change at page 43, line 30
source node resumes sending any subsequent packets via a Server (or source node resumes sending any subsequent packets via a Server (or
Relay) and may (eventually) attempt to re-initiate the AERO route Relay) and may (eventually) attempt to re-initiate the AERO route
optimization process. When ReportTime for a dynamic neighbor cache optimization process. When ReportTime for a dynamic neighbor cache
entry expires, the target node ceases to send dynamic mobility and entry expires, the target node ceases to send dynamic mobility and
QoS updates to the source node. When both ForwardTime and ReportTime QoS updates to the source node. When both ForwardTime and ReportTime
for a dynamic neighbor cache entry expire, the node deletes the for a dynamic neighbor cache entry expire, the node deletes the
neighbor cache entry. neighbor cache entry.
Note that an AERO node may have multiple underlying interface paths Note that an AERO node may have multiple underlying interface paths
toward the target neighbor. In that case, the node SHOULD perform toward the target neighbor. In that case, the node SHOULD perform
NUD over each underlying interface and only consider the neighbor NUD over each underlying interface individually and only consider the
unreachable if NUD fails over multiple underlying interface paths. neighbor unreachable if NUD fails over multiple underlying interface
paths.
3.17. Mobility Management and Quality of Service (QoS) 3.17. 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 AERO Server is responsible for only a subset of the service. Each AERO Server is responsible for only a subset of the
Clients on the AERO link, as opposed to a Centralized Mobility Clients on the AERO link, as opposed to a Centralized Mobility
Management (CMM) service where there is a single network mobility Management (CMM) service where there is a single network mobility
service for all Clients. AERO Clients coordinate with their regional service for all Clients. AERO Clients coordinate with their
Servers via RS/RA exchanges to maintain the DMM profile, and the AERO associated AERO Servers via RS/RA exchanges to maintain the DMM
routing system tracks the current AERO Client/Server peering profile, and the AERO routing system tracks the current AERO Client/
relationships. Server peering relationships.
AERO interfaces accommodate mobility management by sending AERO interfaces accommodate mobility management by sending
unsolicited NA messages the same as for announcing link-layer address unsolicited NA messages the same as for announcing link-layer address
changes for any interface that implements IPv6 ND [RFC4861]. (In changes for any interface that implements IPv6 ND [RFC4861]. (In
environments where reliability is a concern, AERO interfaces can send environments where reliability is a concern, AERO interfaces can send
immediate NS messages to receive solicited NA messages, i.e., they immediate NS messages to receive solicited NA messages, i.e., they
can skip the unreliable unsolicited NA messaging step and move can skip the unreliable unsolicited NA messaging step and move
directly to a reliable NS/NA exchange. This comes at a penalty of at directly to a reliable NS/NA exchange.)
least one round trip.)
When a node sends an unsolicited NA message, it sets the IPv6 source When a node sends an unsolicited NA message, it sets the IPv6 source
to its own link-local address, sets the IPv6 destination address to to its own link-local address, sets the IPv6 destination address to
all-nodes multicast, sets the link-layer source address to its own all-nodes multicast, sets the link-layer source address to its own
address and sets the link-layer destination address to either a address and sets the link-layer destination address to either a
multicast address or the unicast link-layer address of a neighbor. multicast address or the unicast link-layer address of a neighbor.
If the unsolicited NA message must be received by multiple neighbors, In the latter case, if the unsolicited NA message must be received by
the node sends multiple copies of the NA using a different unicast multiple neighbors, the node sends multiple copies of the NA using a
link-layer destination address for each neighbor. Mobility different unicast link-layer destination address for each neighbor.
management considerations are specified in the following sections. Mobility management considerations are specified in the following
sections.
3.17.1. Forwarding Packets on Behalf of Departed Clients 3.17.1. Forwarding Packets on Behalf of Departed Clients
When a Server receives packets with destination addresses that do not When a Server receives packets with destination addresses that do not
match one of its static neighbor cache Clients, it forwards the match one of its static neighbor cache Clients, it forwards the
packets to a Relay and also returns an unsolicited NA message to the packets to a Relay which delivers them to the target Client's current
sender with no TLLAOs. The packets will be delivered to the target location. If the source is not one of its static neighbor Clients,
Client's new location, and the sender will realize that it needs to the Server also returns an unsolicited NA message to the sender with
delete its routing information that associated the target with this no TLLAOs - the sender will then realize that it needs to delete its
Server. neighbor cache entry that associated the target with this Server.
3.17.2. Announcing Link-Layer Address and QoS Preference Changes 3.17.2. Announcing Link-Layer Address and/or QoS Preference Changes
When a Client needs to change its link-layer addresses, e.g., due to When a Client needs to change its link-layer addresses, e.g., due to
a mobility event, it sends unsolicited NAs to its neighbors using the a mobility event, it sends unsolicited NAs to its neighbors using the
new link-layer address as the source address and with TLLAOs that new link-layer address as the source address and with TLLAOs that
include the new Client UDP Port Number, IP Address and P(i) values. include the new Client UDP Port Number, IP Address and P(i) values.
(For neighbors that are Servers, the Client can instead initiate an (For neighbors that are Servers, the Client can instead initiate an
RS/RA exchange.) If the Client sends the NA solely for the purpose RS/RA exchange.) If the Client sends the NA solely for the purpose
of updating QoS preferences without updating the link-layer address, of updating QoS preferences without updating the link-layer address,
the Client sets the UDP Port Number and IP Address to 0. the Client sets the UDP Port Number and IP Address to 0.
skipping to change at page 46, line 5 skipping to change at page 46, line 5
itself from that Server's domain. If the Client does not receive an itself from that Server's domain. If the Client does not receive an
RA reply after MaxRetry attempts, the old Server may have failed and RA reply after MaxRetry attempts, the old Server may have failed and
the Client should discontinue its release attempts. the Client should discontinue its release attempts.
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. Such
oscillations could result in intermittent reachability for the Client oscillations could result in intermittent reachability for the Client
itself, while causing no harm to the network. Examples of when a itself, while causing no harm to the network. Examples of when a
Client might wish to change to a different Server include a Server Client might wish to change to a different Server include a Server
that has gone unreachable, topological movements of significant that has gone unreachable, topological movements of significant
distance, etc. distance, movement to a new geographic region, etc.
3.18. Multicast Considerations 3.18. 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.
skipping to change at page 46, line 33 skipping to change at page 46, line 33
4. The AERO Proxy 4. The AERO Proxy
In some environments, AERO Clients may be located in secured In some environments, AERO Clients may be located in secured
subnetwork enclaves (e.g., corporate enterprise networks, radio subnetwork enclaves (e.g., corporate enterprise networks, radio
access networks, cellular service provider networks, etc.) that do access networks, cellular service provider networks, etc.) that do
not allow direct communications from the Client to a Server in the not allow direct communications from the Client to a Server in the
outside Internetwork. In that case, the secured enclave can employ outside Internetwork. In that case, the secured enclave can employ
an AERO Proxy. an AERO Proxy.
The AERO Proxy is located at the secured enclave perimeter and The AERO Proxy is located at the secured enclave perimeter and
listens for RS messages originating from or RA messages destined to listens for encapsulated RS messages originating from or RA messages
AERO Clients located within the enclave. The Proxy acts on these destined to AERO Clients located within the enclave. The Proxy acts
control messages as follows: on these control messages as follows:
o when the Proxy receives an RS message from a Client within the o when the Proxy receives an RS message from a Client within the
secured enclave, it first authenticates the message then creates a secured enclave, it first authenticates the message then creates a
proxy neighbor cache entry for the Client in the INCOMPLETE State proxy neighbor cache entry for the Client in the INCOMPLETE State
and caches the Client and Server link-layer address along with any and caches the Client and Server link-layer addresses along with
identifying information including Transaction IDs, Client any identifying information including Transaction IDs, Client
Identifiers, Nonce values, etc. The Proxy then creates a new RS Identifiers, Nonce values, etc. The Proxy then re-encapsulates
message using its own link-local address as the source and with an the RS message using its own external address as the source link-
RIO that includes the Client's ACP. The Proxy then forwards the layer address and forwards the message to the Server.
message to the Server indicated by the destination link-layer
address in the original RS while using its own external address as
the source link-layer address.
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 a static neighbor cache entry for the Client message then creates a static neighbor cache entry for the Client
with the Proxy's address as the link-layer address. The Server with the Proxy's address as the link-layer address. The Server
then sends an RA message back to the Proxy. then sends an RA message back to the Proxy.
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 (INCOMPLETE) proxy neighbor cache with the RS that created the (INCOMPLETE) proxy neighbor cache
entry. The Proxy then caches the route information in the message entry. The Proxy then caches the route information in the message
as a mapping from the Client's ACPs to the Client's address within as a mapping from the Client's ACPs to the Client's address within
the secured enclave, and sets the neighbor cache entry state to the secured enclave, and sets the neighbor cache entry state to
REACHABLE. The Proxy then creates a new RA message using the REACHABLE. The Proxy then re-encapsulates the RA message using
cached Client information and forwards it to the Client. its own internal address as the source link-layer address and
forwards the message to the Client.
After the initial RS/RA handshake, the Proxy forwards data packets After the initial RS/RA handshake, the Proxy forwards data packets
between the Client and Server with the Server acting as the Client's between the Client and Server with the Server acting as the Client's
default router. The Proxy can send ND messages to the Client's default router. The Proxy can send ND messages to the Client's
Server(s) to update Server neighbor cache entries on behalf of the Server(s) to update Server neighbor cache entries on behalf of the
Client. (For example, the Proxy can send unsolicited NA messages Client. (For example, the Proxy can send unsolicited NA messages
with a TLLAO with UDP Port Number and IP Address set to 0 and with with a TLLAO with UDP Port Number and IP Address set to 0 and with
valid P(i) values to update the Server(s) with the Client's new QoS valid P(i) values to update the Server(s) with the Client's new QoS
preferences for that link). The Proxy also forwards any control and preferences for the path that traverses the Proxy). The Proxy also
data messages originating from the Client to the Client's primary forwards any control and data messages originating from the Client to
Server. the Client's primary Server.
At some time after data packets have been flowing from the Client to At some time after data packets have been flowing from the Client to
the Server, the Proxy may receive unsolicited NA messages from the the Server, the Proxy may receive unsolicited NA messages from the
Server with TLLAOs corresponding to a target Client. The Proxy Server with TLLAOs corresponding to a target Client. The Proxy
establishes a dynamic neighbor cache entry for the target with establishes a dynamic neighbor cache entry for the target with
ForwardTime set to FORWARD_TIME and allows future data packets ForwardTime set to FORWARD_TIME and allows future data packets
destined to the target to flow directly according to the link-layer destined to the target to flow directly according to the link-layer
address information instead of through the Server. The Proxy may at address information instead of through the Server. The Proxy may at
some later point receive additional NA messages with TLLAOs, and if some later point receive additional NA messages with TLLAOs, and if
so resets ForwardTime and updates its cached link-layer address so resets ForwardTime and updates its cached link-layer address
skipping to change at page 47, line 46 skipping to change at page 47, line 45
receives NA messages with no TLLAOs, it deletes the dynamic neighbor receives NA messages with no TLLAOs, it deletes the dynamic neighbor
cache entry. cache entry.
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 message 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 can be seen as 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.
5. Direct Underlying Interfaces 5. Direct Underlying Interfaces
When a Client's AERO interface is configured over a Direct underlying When a Client's AERO interface is configured over a Direct underlying
interface, the neighbor at the other end of the Direct link can interface, the neighbor at the other end of the Direct link can
receive packets without any encapsulation. In that case, the Client receive packets without any encapsulation. In that case, the Client
sends packets over the Direct link according to the QoS preferences sends packets over the Direct link according to the QoS preferences
skipping to change at page 49, line 11 skipping to change at page 49, line 8
/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.15. optimization in the same sense as discussed in Section 3.15.
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.
7. Implementation Status 7. SEcure Neighbor Discovery (SEND)
In environments where ND message spoofing is considered a threat,
AERO nodes SHOULD employ SEcure Neighbor Discovery (SEND) [RFC3971]
with Cryptographically Generated Addresses (CGAs) [RFC3972]. SEND
also protects the PD information embedded in RS/RA message options.
When the source AERO node computes the CGA, it writes the interface
identifier of the AERO address (i.e., instead of fe80::/64) in the
CGA parameters Subnet Prefix field. When the neighbor receives the
ND message, it first verifies the message checksum and CGA/SEND
parameters while using the value fe80::/64 (i.e., instead of the
value in the Subnet Prefix field) to match against the IPv6 source
address of the ND message.
The neighbor then derives the AERO address of the source by using the
value in the Subnet Prefix field as the interface identifier of an
AERO link-local address. For example, if the Subnet Prefix field
contains 2001:db8:1:2, the neighbor constructs the AERO address as
fe80::2001:db8:1:2. The neighbor then caches the AERO address in the
neighbor cache entry it creates for the source, and uses the AERO
address as the IPv6 destination address of any ND message replies.
8. Implementation Status
An AERO implementation based on OpenVPN (https://openvpn.net/) was An AERO implementation based on OpenVPN (https://openvpn.net/) was
announced on the v6ops mailing list on January 10, 2018. The latest announced on the v6ops mailing list on January 10, 2018. The latest
version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN-
1.2.tgz. 2.0.tgz.
An initial public release of the AERO proof-of-concept source code An initial public release of the AERO proof-of-concept source code
was announced on the intarea mailing list on August 21, 2015. The was announced on the intarea mailing list on August 21, 2015. The
latest version is available at: http://linkupnetworks.net/aero/aero- latest version is available at: http://linkupnetworks.net/aero/aero-
4.0.0.tgz. 4.0.0.tgz.
8. IANA Considerations A survey of public domain and commercial SEND implementations is
available at https://www.ietf.org/mail-archive/web/its/current/
msg02758.html.
9. IANA Considerations
The IANA has assigned a 4-octet Private Enterprise Number "45282" for The IANA has assigned a 4-octet Private Enterprise Number "45282" for
AERO in the "enterprise-numbers" registry. AERO in the "enterprise-numbers" registry.
The IANA has assigned the UDP port number "8060" for an earlier The IANA has assigned the UDP port number "8060" for an earlier
experimental version of AERO [RFC6706]. This document obsoletes experimental version of AERO [RFC6706]. This document obsoletes
[RFC6706] and claims the UDP port number "8060" for all future use. [RFC6706] and claims the UDP port number "8060" for all future use.
No further IANA actions are required. No further IANA actions are required.
9. Security Considerations 10. Security Considerations
AERO link security considerations are the same as for standard IPv6 AERO link security considerations are the same as for standard IPv6
Neighbor Discovery [RFC4861] except that AERO improves on some Neighbor Discovery [RFC4861] except that AERO improves on some
aspects. In particular, AERO uses a trust basis between Clients and aspects. In particular, AERO uses a trust basis between Clients and
Servers, where the Clients only engage in the AERO mechanism when it Servers, where the Clients only engage in the AERO mechanism when it
is facilitated by a trusted Server. is facilitated by a trusted Server.
NS and NA messages SHOULD include a Timestamp option (see Section 5.3 AERO links must be protected against spoofing attacks in which an
of [RFC3971]) that other AERO nodes can use to verify the message attacker on the link pretends to be a trusted neighbor. Links that
time of origin. NS and RS messages SHOULD include a Nonce option provide link-layer securing mechanisms (e.g., IEEE 802.1X WLANs) and
(see Section 5.3 of [RFC3971]) that recipients echo back in links that provide physical security (e.g., enterprise network wired
corresponding NA and RA responses. LANs) provide a first line of defense. In environments where link-
layer security alone is insufficient to address all spoofing threats,
In cases where spoofing cannot be mitigated through other means, AERO AERO nodes SHOULD employ SEND/CGA as discussed in Section 7.
IPv6 ND messages should employ SEcure Neighbor Discovery (SEND)
[RFC3971], which also protects the PD information embedded in RS/RA
message options. In order to apply SEND, AERO nodes use
Cryptographically Generated Addresses (CGAs) [RFC3972] as the source
addresses of secured ND messages.
AERO links must be protected against link-layer address spoofing Regardless of whether the full SEND protocol is used, AERO nodes
attacks in which an attacker on the link pretends to be a trusted SHOULD include Timestamp and Nonce options in ND messages where
neighbor. Links that provide link-layer securing mechanisms (e.g., appropriate. The Nonce option sent in RS/NS messages can then serve
IEEE 802.1X WLANs) and links that provide physical security (e.g., as a transaction ID for matching corresponding RA/NA messsages.
enterprise network wired LANs) provide a first line of defense,
however AERO nodes SHOULD also use securing services such as SEND for
authentication and network admission control.
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.)
AERO Clients, Servers and Relays on the open Internet are susceptible AERO Clients, Servers and Relays on the open Internet are susceptible
to the same attack profiles as for any Internet nodes. For this to the same attack profiles as for any Internet nodes. For this
reason, IP security SHOULD be used when AERO is employed over reason, IP security SHOULD be used when AERO is employed over
unmanaged/unsecured links using securing mechanisms such as IPsec unmanaged/unsecured links using securing mechanisms such as IPsec
[RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments,
however, the use of application-layer security from Clients to however, the use of application-layer security from Clients to
correspondent nodes (i.e., other Clients and/or Internet nodes) could correspondent nodes (i.e., other Clients and/or Internet nodes) could
obviate the need for IP security between AERO Clients, Servers and obviate the need for IP security between AERO Clients, Servers and
Relays. Relays.
AERO Servers and Relays present targets for traffic amplification DoS AERO Servers and Relays present targets for traffic amplification
attacks. This concern is no different than for widely-deployed VPN Denial of Service (DoS) attacks. This concern is no different than
security gateways in the Internet, where attackers could send spoofed for widely-deployed VPN security gateways in the Internet, where
packets to the gateways at high data rates. This can be mitigated by attackers could send spoofed packets to the gateways at high data
connecting Relays and Servers over dedicated links with no rates. This can be mitigated by connecting Relays and Servers over
connections to the Internet and/or when connections to the Internet dedicated links with no connections to the Internet and/or when
are only permitted through well-managed firewalls. connections to the Internet are only permitted through well-managed
firewalls.
Traffic amplification DoS attacks can also target an AERO Client's Traffic amplification DoS attacks can also target an AERO Client's
low data rate links. This is a concern not only for Clients located low data rate links. This is a concern not only for Clients located
on the open Internet but also for Clients in secured enclaves. AERO on the open Internet but also for Clients in secured enclaves. AERO
Servers can institute rate limits that protect Clients from receiving Servers can institute rate limits that protect Clients from receiving
packet floods that could DoS low data rate links. packet floods that could DoS low data rate links.
AERO Relays and Servers MUST discard packets with AERO Server Subnet AERO Relays and Servers MUST discard packets with AERO Server Subnet
Router Anycast as the source address originating from any node other Router Anycast as the source address originating from any node other
than a permanent neighbor. This is to avoid a message injection than a permanent neighbor. This is to avoid a message injection
spoofing attack from an off-link attacker. spoofing attack from an off-link attacker.
Security considerations for accepting link-layer ICMP messages and Security considerations for accepting link-layer ICMP messages and
reflected packets are discussed throughout the document. reflected packets are discussed throughout the document.
10. Acknowledgements 11. Acknowledgements
Discussions in the IETF, aviation standards communities and private Discussions in the IETF, aviation standards communities and private
exchanges helped shape some of the concepts in this work. exchanges helped shape some of the concepts in this work.
Individuals who contributed insights include Mikael Abrahamsson, Mark Individuals who contributed insights include Mikael Abrahamsson, Mark
Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter,
Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli,
Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha
Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, Satoru Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, Satoru
Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet Saikaya, Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet Saikaya,
Michal Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, Michal Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman,
Lloyd Wood and James Woodyatt. Members of the IESG also provided Lloyd Wood and James Woodyatt. Members of the IESG also provided
valuable input during their review process that greatly improved the valuable input during their review process that greatly improved the
document. Special thanks go to Stewart Bryant, Joel Halpern and document. Special thanks go to Stewart Bryant, Joel Halpern and
Brian Haberman for their shepherding guidance during the publication Brian Haberman for their shepherding guidance during the publication
of the AERO first edition. of the AERO first edition.
This work has further been encouraged and supported by Boeing This work has further been encouraged and supported by Boeing
colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam
Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu
Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gene Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed
MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey,
Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie Wulff, Brian Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie
Yueli Yang, Eric Yeh and other members of the BR&T and BIT mobile Wulff, Yueli Yang, Eric Yeh and other members of the BR&T and BIT
networking teams. Kyle Bae, Wayne Benson and Eric Yeh are especially mobile networking teams. Kyle Bae, Wayne Benson and Eric Yeh are
acknowledged for implementing the AERO functions as extensions to the especially acknowledged for implementing the AERO functions as
public domain OpenVPN distribution. extensions to the public domain OpenVPN distribution.
Earlier works on NBMA tunneling approaches are found in Earlier works on NBMA tunneling approaches are found in
[RFC2529][RFC5214][RFC5569]. [RFC2529][RFC5214][RFC5569].
Many of the constructs presented in this second edition of AERO are Many of the constructs presented in this second edition of AERO are
based on the author's earlier works, including: based on the author's earlier works, including:
o The Internet Routing Overlay Network (IRON) o The Internet Routing Overlay Network (IRON)
[RFC6179][I-D.templin-ironbis] [RFC6179][I-D.templin-ironbis]
skipping to change at page 52, line 4 skipping to change at page 52, line 21
o The Internet Routing Overlay Network (IRON) o The Internet Routing Overlay Network (IRON)
[RFC6179][I-D.templin-ironbis] [RFC6179][I-D.templin-ironbis]
o Virtual Enterprise Traversal (VET) o Virtual Enterprise Traversal (VET)
[RFC5558][I-D.templin-intarea-vet] [RFC5558][I-D.templin-intarea-vet]
o The Subnetwork Encapsulation and Adaptation Layer (SEAL) o The Subnetwork Encapsulation and Adaptation Layer (SEAL)
[RFC5320][I-D.templin-intarea-seal] [RFC5320][I-D.templin-intarea-seal]
o AERO, First Edition [RFC6706] o AERO, First Edition [RFC6706]
Note that these works cite numerous earlier efforts that are not also Note that these works cite numerous earlier efforts that are not also
cited here due to space limitations. The authors of those earlier cited here due to space limitations. The authors of those earlier
works are acknowledged for their insights. works are acknowledged for their insights.
This work is aligned with the NASA Safe Autonomous Systems Operation This work is aligned with the NASA Safe Autonomous Systems Operation
(SASO) program under NASA contract number NNA16BD84C. (SASO) program under NASA contract number NNA16BD84C.
This work is aligned with the FAA as per the SE2025 contract number This work is aligned with the FAA as per the SE2025 contract number
DTFAWA-15-D-00030. DTFAWA-15-D-00030.
This work is aligned with the 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 Research and Technology (BR&T) This work is aligned with the Boeing Research and Technology (BR&T)
autonomous systems networking program. autonomous systems networking program.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <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,
skipping to change at page 53, line 47 skipping to change at page 54, line 15
[RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router
Advertisement Flags Option", RFC 5175, Advertisement Flags Option", RFC 5175,
DOI 10.17487/RFC5175, March 2008, DOI 10.17487/RFC5175, March 2008,
<https://www.rfc-editor.org/info/rfc5175>. <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>.
11.2. Informative References 12.2. Informative References
[BGP] Huston, G., "BGP in 2015, http://potaroo.net", January [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January
2016. 2016.
[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-06 (work in Encapsulation", draft-ietf-intarea-gue-06 (work in
progress), August 2018. progress), August 2018.
[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-05 (work in progress), August 2018. extensions-05 (work in progress), August 2018.
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
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]
Templin, F., Saccone, G., Dawra, G., Lindem, A., and V.
Moreno, "A Simple BGP-based Mobile Routing System for the
Aeronautical Telecommunications Network", draft-ietf-
rtgwg-atn-bgp-00 (work in progress), August 2018.
[I-D.templin-6man-aeroaddr]
Templin, F., "The AERO Address", draft-templin-6man-
aeroaddr-03 (work in progress), November 2018.
[I-D.templin-6man-dhcpv6-ndopt] [I-D.templin-6man-dhcpv6-ndopt]
Templin, F., "A Unified Stateful/Stateless Templin, F., "A Unified Stateful/Stateless
Autoconfiguration Service for IPv6", draft-templin-6man- Autoconfiguration Service for IPv6", draft-templin-6man-
dhcpv6-ndopt-06 (work in progress), September 2018. dhcpv6-ndopt-06 (work in progress), September 2018.
[I-D.templin-6man-rio-redirect] [I-D.templin-6man-rio-redirect]
Templin, F. and j. woodyatt, "Route Information Options in Templin, F. and j. woodyatt, "Route Information Options in
IPv6 Neighbor Discovery", draft-templin-6man-rio- IPv6 Neighbor Discovery", draft-templin-6man-rio-
redirect-06 (work in progress), May 2018. redirect-06 (work in progress), May 2018.
[I-D.templin-atn-bgp]
Templin, F., Saccone, G., Dawra, G., Lindem, A., and V.
Moreno, "A Simple BGP-based Mobile Routing System for the
Aeronautical Telecommunications Network", draft-templin-
atn-bgp-08 (work in progress), August 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 59, line 9 skipping to change at page 59, line 27
<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-
in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP",
October 2014. October 2014.
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,
skipping to change at page 63, line 33 skipping to change at page 63, line 49
mobile nodes with the understanding that the information must be mobile nodes with the understanding that the information must be
propagated to all routers in the system. Operational experience has propagated to all routers in the system. Operational experience has
shown that this kind of routing system "churn" can lead to overall shown that this kind of routing system "churn" can lead to overall
instability and routing system inconsistency. instability and routing system inconsistency.
D.4. Manually-Configured AERO Tunnels D.4. Manually-Configured AERO Tunnels
In addition to the dynamic neighbor discovery procedures for AERO In addition to the dynamic neighbor discovery procedures for AERO
link neighbors described above, AERO encapsulation can be applied to link neighbors described above, AERO encapsulation can be applied to
manually-configured tunnels. In that case, the tunnel endpoints use manually-configured tunnels. In that case, the tunnel endpoints use
an administratively-provisioned link-local address and exchange NS/NA an administratively-provisioned AERO address and exchange NS/NA
messages the same as for dynamically-established tunnels. messages the same as for dynamically-established tunnels.
D.5. Encapsulation Avoidance on Relay-Server Dedicated Links D.5. Encapsulation Avoidance on Relay-Server Dedicated Links
In some environments, AERO Servers and Relays may be connected by In some environments, AERO Servers and Relays may be connected by
dedicated point-to-point links, e.g., high speed fiberoptic leased dedicated point-to-point links, e.g., high speed fiberoptic leased
lines. In that case, the Servers and Relays can participate in the lines. In that case, the Servers and Relays can participate in the
AERO link the same as specified above but can avoid encapsulation AERO link the same as specified above but can avoid encapsulation
over the dedicated links. In that case, however, the links would be over the dedicated links. In that case, however, the links would be
dedicated for AERO and could not be multiplexed for both AERO and dedicated for AERO and could not be multiplexed for both AERO and
skipping to change at page 65, line 36 skipping to change at page 66, line 7
Conversely, the enterprise-internal AERO Server has only enterprise- Conversely, the enterprise-internal AERO Server has only enterprise-
internal physical interfaces. For this reason security gateway internal physical interfaces. For this reason security gateway
proxying is needed to ensure that the public Internet link-layer proxying is needed to ensure that the public Internet link-layer
addressing space is kept separate from the enterprise-internal link- addressing space is kept separate from the enterprise-internal link-
layer addressing space. This is afforded through a natural extension layer addressing space. This is afforded through a natural extension
of the security association caching already performed for each VPN of the security association caching already performed for each VPN
client by the security gateway. client by the security gateway.
Appendix E. Change Log Appendix E. Change Log
<< RFC Editor - remove prior to publication >>
Changes from draft-templin-intarea-6706bis-02 to draft-templin-
intrea-6706bis-03:
o Added new section on SEND.
o Clarifications on "AERO Address" section.
o Updated references and added new reference for RFC8086.
o Security considerations updates.
o General text clarifications and cleanup.
Changes from draft-templin-intarea-6706bis-01 to draft-templin- Changes from draft-templin-intarea-6706bis-01 to draft-templin-
intrea-6706bis-02: intrea-6706bis-02:
o Note on encapsulation avoidance in Section 4. o Note on encapsulation avoidance in Section 4.
Changes from draft-templin-intarea-6706bis-00 to draft-templin- Changes from draft-templin-intarea-6706bis-00 to draft-templin-
intrea-6706bis-01: intrea-6706bis-01:
o Remove DHCPv6 Server Release procedures that leveraged the old way o Remove DHCPv6 Server Release procedures that leveraged the old way
Relays used to "route" between Server link-local addresses Relays used to "route" between Server link-local addresses
skipping to change at page 66, line 34 skipping to change at page 67, line 16
updates as an alternative to unreliable unsolicited NA. updates as an alternative to unreliable unsolicited NA.
Consistent with Section 7.2.6 of RFC4861. Consistent with Section 7.2.6 of RFC4861.
o Server adds additional layer of encapsulation between outer and o Server adds additional layer of encapsulation between outer and
inner headers of NS/NA messages for transmission through Relays inner headers of NS/NA messages for transmission through Relays
that act as vanilla IPv6 routers. The messages include the AERO that act as vanilla IPv6 routers. The messages include the AERO
Server Subnet Router Anycast address as the source and the Subnet Server Subnet Router Anycast address as the source and the Subnet
Router Anycast address corresponding to the Client's ACP as the Router Anycast address corresponding to the Client's ACP as the
destination. destination.
o Clients use Subnet Router Anycsat address as the encapsulation o Clients use Subnet Router Anycast address as the encapsulation
source address when the access network does not provide a source address when the access network does not provide a
topologically-fixed address. topologically-fixed address.
o
Author's Address Author's Address
Fred L. Templin (editor) Fred L. Templin (editor)
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
USA USA
Email: fltemplin@acm.org Email: fltemplin@acm.org
 End of changes. 98 change blocks. 
296 lines changed or deleted 343 lines changed or added

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