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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = 2   |   Length = 3  |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Link ID    |   Preference  |     UDP Port Number (or 0)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +--                                                           --+
     |                                                               |
     +--                        IP Address                         --+
     |                                                               |
     +--                                                           --+
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: AERO Target Link-Layer Address Option (TLLAO) Format

In this format, Link ID is an integer value between 0 and 255 corresponding to an underlying interface of the target node, and Preference is an integer value between 0 and 255 indicating the node's preference for this underlying interface, with 0 being highest preference and 255 being lowest. UDP Port Number and IP Address are set to the addresses used by the target node when it sends encapsulated packets over the underlying interface. When no UDP encapsulation is used, UDP Port Number is set to 0. When the encapsulation IP address family is IPv4, IP Address is formed as an IPv4-mapped IPv6 address [RFC4291].

When a Relay enables an AERO interface, it applies an administratively assigned link-local address fe80::ID to the interface for communicating with Servers on the link. Each fe80::ID address MUST be unique among all Relays and Servers on the link, and MUST NOT collide with any potential AERO addresses, e.g., the addresses could be assigned as fe80::1, fe80::2, fe80::3, etc. The Relay also maintains an IP forwarding table entry for each Client-Server association and maintains a neighbor cache entry for each Server on the link. Relays do not require the use of IPv6 ND messaging for reachability determination since Relays and Servers engage in a dynamic routing protocol over the AERO interface. At a minimum, however, Relays respond to NS messages by returning an NA.

When a Server enables an AERO interface, it applies the address fe80:: to the interface as a link-local Subnet Router Anycast address, and also applies an administratively assigned link-local address fe80::ID to support the operation of DHCPv6 and the IPv6 ND protocol, as well as to communicate with Relays on the link. The Server configures a DHCPv6 server function to facilitate DHCPv6 PD exchanges with AERO Clients. The Server also maintains a neighbor cache entry for each Relay on the link, and also creates per-Client neighbor cache entries whenever it discovers a new Client. At a minimum, when the Server receives an NS/RS messages on the AERO interface it returns an NA/RA message. When the Server receives an IPv6 ND message, it also update timers in existing neighbor cache entries but does not create new neighbor cache entries nor update cached link-layer addresses. Servers also engage in a dynamic routing protocol with all Relays on the link. Finally, the Server provides a simple conduit between Clients and Relays, or between Clients and other Clients. Therefore, packets enter the Server's AERO interface from the link layer and are forwarded back out the link layer without ever leaving the AERO interface and therefore without ever disturbing the network layer.

When a Client enables an AERO interface, it invokes DHCPv6 PD to receive an ACP from an AERO Server. Next, it applies the corresponding AERO address to the AERO interface, i.e., the prefix delegation bootstraps the provisioning of a unique link-local address. The Client maintains a neighbor cache entry for each of its Servers and each of its active peer Clients. When the Client receives Redirect/Predirect messages on the AERO interface it updates or creates neighbor cache entries, including link-layer address information. Unsolicited NA messages update the cached link-layer address for the neighbor Client (e.g., following a link-layer address change due to node mobility) but do not create new neighbor cache entries. RA messages as well as NS/NA messages used for Neighbor Unreachability Detection (NUD) update timers in existing neighbor cache entires but do not update link-layer addresses nor create new neighbor cache entries. Redirect, Predirect and unsolicited NA messages SHOULD include a Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes can use to verify the message time of origin. Predirect, NS and RS messages SHOULD include a Nonce option (see Section 5.3 of [RFC3971]) that recipients echo back in corresponding responses. Finally, the Client need not maintain any IP forwarding table entries for neighboring Clients. Instead, it can set a single "route-to-interface" default route in the IP forwarding table pointing to the AERO interface, and all forwarding decisions can be made within the AERO interface based on neighbor cache entries.

3.4.1. Coordination of Multiple Underlying Interfaces

AERO interfaces may be configured over multiple underlying interfaces. For example, common mobile handheld devices have both wireless local area network ("WLAN") and cellular wireless links. These links are typically used "one at a time" with low-cost WLAN preferred and highly-available cellular wireless as a standby. In a more complex example, aircraft frequently have many wireless data link types (e.g. satellite-based, terrestrial, air-to-air directional, etc.) with diverse performance and cost properties.

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 is active), then Redirect, Predirect and unsolicited NA messages include only a single TLLAO with Link ID set to 0.

If the Client has multiple active underlying interfaces, then from the perspective of IPv6 ND it would appear to have a single link-local address with multiple link-layer addresses. In that case, Redirect, Predirect and unsolicited NA messages MAY include multiple TLLAOs -- each with a different Link ID that corresponds to a specific underlying interface of the Client. Further details on coordination of multiple active underlying interfaces are outside the scope of this specification.

3.5. AERO Interface Neighbor Cache Maintenace

Each AERO interface maintains a conceptual neighbor cache that includes an entry for each neighbor it communicates with on the AERO link, the same as for any IPv6 interface [RFC4861]. Neighbor cache entries are created and maintained as follows:

AERO Relays maintain a permanent neighbor cache entry for each Server on the link, and AERO Servers maintain a permanent neighbor cache entry for each Relay on the link. AERO Clients maintain a neighbor cache entry for each of their associated Servers, and AERO Servers maintain a neighbor cache for each of their associated Clients with a lifetime based on the DHCPv6 lease lifetime. AERO Clients maintain neighbor cache entries for each of their active correspondent Clients with lifetimes based on IPv6 ND messaging constants.

When an AERO Server sends a DHCPv6 Reply message to an AERO Client containing a prefix delegation, it creates or updates a neighbor cache entry for the Client based on the AERO address corresponding to the Client's ACP as the network-layer address and with the Client's encapsulation IP address and UDP port number as the link-layer address. The Server also records the ACP's lease lifetime and prefix length in the neighbor cache entry.

When an AERO Client receives a DHCPv6 Reply message from an AERO Server, it creates or updates a neighbor cache entry for the Server based on the Reply message link-local source address as the network-layer address, the lease lifetime as the neighbor cache entry lifetime, and the encapsulation IP source address and UDP source port number as the link-layer address.

When an AERO Client receives a valid Predirect message it creates or updates a neighbor cache entry for the Predirect target network-layer and link-layer addresses plus prefix length. The node then sets an "AcceptTime" variable for the neighbor and uses this value to determine whether packets received from the predirected neighbor can be accepted.

When an AERO Client receives a valid Redirect message it creates or updates a neighbor cache entry for the Redirect target network-layer and link-layer addresses plus prefix length. The node then sets a "ForwardTime" variable for the neighbor and uses this value to determine whether packets can be sent directly to the redirected neighbor. The node also maintains a "Retry" variable to limit the number of keepalives sent when a neighbor may have gone unreachable.

When an AERO Client receives a valid NS message corresponding to a neighbor cache entry for another Client, it (re)sets AcceptTime for the neighbor to ACCEPT_TIME.

When an AERO Client receives a valid solicited NA message corresponding to a neighbor cache entry for another Client, it (re)sets ForwardTime for the neighbor to FORWARD_TIME and sets Retry to MAX_RETRY. (When an AERO Client receives a valid unsolicited NA message, it updates the neighbor's link-layer address but DOES NOT reset ForwardTime or Retries.)

It is RECOMMENDED that FORWARD_TIME be set to the default constant value 30 seconds to match the default REACHABLE_TIME value specified for IPv6 ND [RFC4861].

It is RECOMMENDED that ACCEPT_TIME be set to the default constant value 40 seconds to allow a 10 second window so that the AERO redirection procedure can converge before AcceptTime decrements below FORWARD_TIME.

It is RECOMMENDED that MAX_RETRY be set to 3 the same as described for IPv6 ND address resolution in Section 7.3.3 of [RFC4861].

Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be administratively set, if necessary, to better match the AERO link's performance characteristics; however, if different values are chosen, all nodes on the link MUST consistently configure the same values. Most importantly, ACCEPT_TIME SHOULD be set to a value that is sufficiently longer than FORWARD_TIME to allow the AERO redirection procedure to converge.

For AERO Client<->Server neighbor cache entries, AcceptTime and ForwardTime are set based on the DHCPv6 lease lifetime and may be modified based on the Router Lifetime advertised in the Server's RA messages.

3.6. AERO Interface Sending Algorithm

When an IP packet enters a Client's AERO interface from the network layer, the Client searches its neighbor cache for an entry with an AERO address that matches the packet's destination address. If there is a match, the Client uses the link-layer address in the neighbor cache entry as the link-layer address for encapsulation then admits the packet into the tunnel. If there is no match, the Client instead uses the link-layer address of a neighboring Server as the link-layer address for encapsulation. (Note that the Client caches the ASPs for the AERO link and can thus search the neighbor cache only for destination addresses that are covered by an ASP.)

When an IP packet enters a Server's AERO interface from the link layer, the Server searches for a neighbor cache match the same as for a Client. If there is a match, the Server uses the link-layer address in the neighbor cache entry as the link-layer address for re-encapsulation. If there is no match, the Server instead uses the link-layer address of a neighboring Relay as the link-layer address for encapsulation. Servers also relay Predirect, Redirect and unsolicited Neighbor Advertisement messages received from a Client and with an AERO destination address. If the AERO destination address is the address of a neighbor, the Server changes the link-layer source address to its own address, changes the link-layer destination address to the address of the neighbor and forwards the message to the neighbor. If the AERO destination address is not a neighbor, the Server instead forwards the message to a Relay. When an AERO Relay forwards either a data packet or an IPv6 ND message to an AERO Server, the Server MUST NOT forward the packet back to the same or a different Relay.

When an IP packet enters a Relay's AERO interface from the network layer, the Relay searches its IP forwarding table for an entry that is covered by an ASP and also matches the destination. If there is a match, the Relay uses the link-layer address in the neighbor cache entry for the next-hop Server as the link-layer address for encapsulation. When an IP packet enters a Relay's AERO interface from the link-layer, if the destination is not covered by an ASP the Relay forwards the packet to another IP link as indicated by the IP forwarding table. If the destination is covered by an ASP, and there is a more-specific forwarding table entry that matches the destination, the Relay uses the link-layer address in the neighbor cache entry for the next-hop Server as the link-layer address for encapsulation. If there is no more-specific entry, the Relay instead drops the packet. Relays also relay Predirect, Redirect and unsolicited Neighbor Advertisement messages by searching for an IP forwarding table entry that matches the message's AERO destination address. If there is a match, the Relay proxies the packet in the same manner as described for Servers above; otherwise, the Relay drops the packet. When an AERO Server forwards either a data packet or an IPv6 ND message to an AERO Relay, the Relay MUST NOT forward the packet back to the same Server.

Note that in the above this tunnel exit determination is often based on consulting the neighbor cache instead of the IP forwarding table. IP forwarding is therefore linked to IPv6 ND via the AERO address.

When an AERO node forwards a packet back out the same AERO interface the packet arrived on, the node MUST NOT decrement the network layer TTL/Hop-count.

3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation

AERO interfaces encapsulate IP packets according to whether they are entering the AERO interface from the network layer or if they are being forwarded out the same AERO interface that they arrived on. This latter form of encapsulation is known as "re-encapsulation".

AERO interfaces encapsulate packets per the specifications in [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246] (etc.) except that the interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion Experienced" values in the packet's IP header into the corresponding fields in the encapsulation header. For packets undergoing re-encapsulation, the AERO interface instead copies the "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion Experienced" values in the original encapsulation header into the corresponding fields in the new encapsulation header (i.e., the values are transferred between encapsulation headers and *not* copied from the encapsulated packet's network-layer header).

When AERO UDP encapsulation is used, the AERO interface encapsulates the packet per the above tunneling specifications except that it inserts a UDP header between the encapsulation header and the packet's IP header. The AERO interface sets the UDP source port to a constant value that it will use in each successive packet it sends, sets the UDP checksum field to zero (see: [RFC6935][RFC6936]) and sets the UDP length field to the length of the IP packet plus 8 bytes for the UDP header itself. For packets sent via a Server, the AERO interface sets the UDP destination port to 8060 (i.e., the IANA-registered port number for AERO) when AERO-only encapsulation is used. For packets sent to a neighboring Client, the AERO interface sets the UDP destination port to the port value stored in the neighbor cache entry for this neighbor.

The AERO interface next sets the IP protocol number in the encapsulation header to the appropriate value for the first protocol layer within the encapsulation (e.g., IPv4, IPv6, UDP, IPsec, etc.). When IPv6 is used as the encapsulation protocol, the interface then sets the flow label value in the encapsulation header the same as described in [RFC6438]. When IPv4 is used as the encapsulation protocol, the AERO interface sets the DF bit as discussed in Section 3.7.

AERO interfaces decapsulate packets destined either to the node itself or to a destination reached via an interface other than the AERO interface the packet was received on. When AERO UDP encapsulation is used (i.e., when a UDP header with destination port 8060 is present) the interface examines the first octet of the encapsulated packet. If the most significant four bits of the first octet encode the value '0110' (i.e., the version number value for IPv6) or the value '0100' (i.e., the version number value for IPv4), the packet is accepted and the encapsulating UDP header is discarded; otherwise, the packet is discarded.

Further decapsulation then proceeds according to the appropriate tunnel type per the above specifications.

3.8. AERO Interface Data Origin Authentication

AERO nodes employ simple data origin authentication procedures for encapsulated packets they receive from other nodes. In particular, AERO Clients accept encapsulated packets with a link-layer source address belonging to one of their current AERO Servers, and AERO Clients and Servers accept encapsulated packets with a link-layer source address that is correct for the network-layer source address.

The AERO node considers the link-layer source address correct for the network-layer source address if there is an AERO interface neighbor cache entry with an AERO address that matches the packet's network-layer source address prefix, with a link-layer address that matches the packet's link-layer source address, and AcceptTime is non-zero.

An AERO Server also accepts packets with a link-layer source address that matches one of its associated Relays, and an AERO Relay accepts packets with a source address that matches one of its associated Servers.

Note that this simple data origin authentication only applies to environments in which link-layer addresses cannot be spoofed. Additional security mitigations may be necessary in other environments.

3.9. AERO Interface MTU Considerations

The AERO link Maximum Transmission Unit (MTU) is 64KB minus the encapsulation overhead for IPv4 as the link-layer [RFC0791] and 4GB minus the encapsulation overhead for IPv6 as the link layer [RFC2675]. This is the most that IPv4 and IPv6 (respectively) can convey within the constraints of protocol constants, but actual sizes available for tunneling will frequently be much smaller.

The base tunneling specifications for IPv4 and IPv6 typically set a static MTU on the tunnel interface to 1500 bytes minus the encapsulation overhead or smaller still if the tunnel is likely to incur additional encapsulations on the path. This can result in path MTU related black holes when packets that are too large to be accommodated over the AERO link are dropped, but the resulting ICMP Packet Too Big (PTB) messages are lost on the return path. As a result, AERO nodes use the following MTU mitigations to accommodate larger packets.

AERO nodes set their AERO interface MTU to the larger of the underlying interface MTU minus the encapsulation overhead, and 1500 bytes. (If there are multiple underlying interfaces, the node sets the AERO interface MTU according to the largest underlying interface MTU, or 64KB /4G minus the encapsulation overhead if the largest MTU cannot be determined.) AERO nodes optionally cache other per-neighbor MTU values in the underlying IP path MTU discovery cache initialized to the underlying interface MTU.

AERO nodes admit packets that are no larger than 1280 bytes minus the encapsulation overhead (*) as well as packets that are larger than 1500 bytes into the tunnel without fragmentation, i.e., as long as they are no larger than the AERO interface MTU before encapsulation and also no larger than the cached per-neighbor MTU following encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit to 0 for packets no larger than 1280 bytes minus the encapsulation overhead (*) and sets the DF bit to 1 for packets larger than 1500 bytes. If a large packet is lost in the path, the node may optionally cache the MTU reported in the resulting PTB message or may ignore the message, e.g., if there is a possibility that the message is spurious.

For packets destined to an AERO node that are larger than 1280 bytes minus the encapsulation overhead (*) but no larger than 1500 bytes, the node uses IP fragmentation to fragment the encapsulated packet into two pieces (where the first fragment contains 1024 bytes of the original IP packet) then admits the fragments into the tunnel. If the link-layer protocol is IPv4, the node admits each fragment into the tunnel with DF set to 0 and subject to rate limiting to avoid reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the node also sends a 1500 byte probe message (**) to the neighbor, subject to rate limiting.

To construct a probe, the node prepares an NS message with a Nonce option plus trailing padding octets added to a length of 1500 bytes without including the length of the padding in the IPv6 Payload Length field. The node then encapsulates the NS in the encapsulation headers (while including the length of the padding in the encapsulation header length fields), sets DF to 1 (for IPv4) and sends the padded NS message to the neighbor. If the neighbor returns an NA message with a correct Nonce value, the node may then send whole packets within this size range and (for IPv4) relax the rate limiting requirement. (Note that the trailing padding SHOULD NOT be included within the Nonce option itself but rather as padding beyond the last option in the NS message; otherwise, the (large) Nonce option would be echoed back in the solicited NA message and may be lost at a link with a small MTU along the reverse path.)

AERO nodes MUST be capable of reassembling packets up to 1500 bytes plus the encapsulation overhead length. It is therefore RECOMMENDED that AERO nodes be capable of reassembling at least 2KB.

(*) Note that if it is known without probing that the minimum Path MTU to an AERO node is MINMTU bytes (where 1280 < MINMTU < 1500) then MINMTU can be used instead of 1280 in the fragmentation threshold considerations listed above.

(**) It is RECOMMENDED that no probes smaller than 1500 bytes be used for MTU probing purposes, since smaller probes may be fragmented if there is a nested tunnel somewhere on the path to the neighbor. Probe sizes larger than 1500 bytes MAY be used, but may be unnecessary since original sources are expected to implement [RFC4821] when sending large packets.

3.10. AERO Router Discovery, Prefix Delegation and Address Configuration

3.10.1. AERO DHCPv6 Service Model

Each AERO Server configures a DHCPv6 server function to facilitate PD requests from Clients. Each Server is pre-configured with an identical list of ACP-to-Client ID mappings for all Clients enrolled in the AERO system, as well as any information necessary to authenticate Clients. The configuration information is maintained by a central administrative authority for the AERO link and securely propagated to all Servers whenever a new Client is enrolled or an existing Client is deprecated.

With these identical configurations, each Server can function independently of all other Servers, including the maintenance of active leases. Therefore, no Server-to-Server DHCPv6 state synchronization is necessary, and Clients can potentially hold separate leases for the same ACP from multiple Servers.

In this way, Clients can easily associate with multiple Servers, and can receive new leases from new Servers before deprecating leases held through old Servers. This gives way to a graceful "make-before-break" capability.

3.10.2. AERO Client Behavior

AERO Clients discover the link-layer addresses of AERO Servers via static configuration, or through an automated means such as DNS name resolution. In the absence of other information, the Client resolves the Fully-Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" where "linkupnetworks" is a constant text string and "[domainname]" is the connection-specific DNS suffix for the Client's underlying network connection. After discovering the link-layer addresses, the Client associates with one or more of the corresponding Servers.

To associate with a Server, the Client acts as a requesting router to request an ACP through DHCPv6 PD [RFC3315][RFC3633][RFC6355] using 'fe80::ffff:ffff:ffff:ffff' as the IPv6 source address, 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address and the link-layer address of the Server as the link-layer destination address. The Client includes a DHCPv6 Unique Identifier (DUID) in the Client Identifier option of its DHCPv6 messages (as well as a DHCPv6 authentication option if necessary) to identify itself to the DHCPv6 server. If the Client is pre-provisioned with an ACP associated with the AERO service, it MAY also include the ACP in its DHCPv6 PD Request to indicate its preferred ACP to the DHCPv6 server. The Client then sends the encapsulated DHCPv6 Solicit/Request message via an underlying interface.

When the Client receives its ACP and the set of ASPs via a DHCPv6 Reply from the AERO Server, it creates a neighbor cache entry with the Server's link-local address (i.e., fe80::ID) as the network-layer address and the Server's encapsulation address as the link-layer address. The Client then records the lifetime for the ACP in the neighbor cache entry and marks the neighbor cache entry as "default", i.e., the Client considers the Server as a default router. If the Reply message contains a Vendor-Specific Information Option (see: Section 3.10.3) the Client also caches each ASP in the option.

The Client then applies the AERO address to the AERO interface and sub-delegates the ACP to nodes and links within its attached EUNs (the AERO address thereafter remains stable as the Client moves). The Client also assigns a default IP route to the AERO interface as a route-to-interface, i.e., with no explicit next-hop. The next hop will then be determined after a packet has been submitted to the AERO interface by inspecting the neighbor cache (see above).

The Client subsequently renews its ACP delegation through each of its Servers by performing DHCPv6 Renew/Reply exchanges with its AERO address as the IPv6 source address, 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address, the link-layer address of a Server as the link-layer destination address and the same DUID and authentication information.

Since the Client's AERO address is configured from the unique ACP delegation it receives, there is no need for Duplicate Address Detection (DAD) on AERO links. Other nodes maliciously attempting to hijack an authorized Client's AERO address will be denied access to the network by the DHCPv6 server due to an unacceptable link-layer address and/or security parameters (see: Security Considerations).

AERO Clients ignore the IP address and UDP port number in any S/TLLAO options in ND messages they receive directly from another AERO Client, but examine the Link ID and Preference values to match the message with the correct link-layer address information.

When a source Client forwards a packet to a prospective destination Client (i.e., one for which the packet's destination address is covered by an ASP), the source Client initiates an AERO route optimization procedure as specified in Section 3.12.

3.10.3. AERO Server Behavior

AERO Servers configure a DHCPv6 server function on their AERO links. AERO Servers arrange to add their encapsulation layer IP addresses (i.e., their link-layer addresses) to the DNS resource records for the FQDN "linkupnetworks.[domainname]" before entering service.

When an AERO Server receives a prospective Client's DHCPv6 PD Solicit/Request message, it first authenticates the Client and ignores the request if authentication fails. Otherwise, the Server delegates the ACP then creates a neighbor cache entry for the Client's AERO address with the Client's link-layer address as the link-layer address and with lifetime set to no more than the lease lifetime. The Server then injects the ACP as an IP route into the inter-Server/Relay routing system (see: Section 3.11). Finally, the Server sends a DHCPv6 Reply message to the Client while using fe80::ID as the IPv6 source address, the Client's link-local address as the IPv6 destination address, and the Client's link-layer address as the destination link-layer address.

When the Server sends the DHCPv6 Reply message, it also includes a DHCPv6 Vendor-Specific Information Option with 'enterprise-number' set to "TBD" (see: IANA Considerations). The option is formatted as shown in[RFC3315] and with the AERO enterprise-specific format shown in Figure 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_VENDOR_OPTS       |           option-len          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   enterprise-number ("TBD")                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reserved                 | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                            ASP (1)                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reserved                 | Prefix Length | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                             ASP (2)                           +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reserved                 | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                             ASP (3)                           +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                             (etc.)                            .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         +--------------+  +--------------+  +--------------+
         |   Server S1  |  |    Relay R   |  |   Server S2  |
         |    Nbr: A    |  |(C->S1; D->S2)|  |    Nbr: B    |
         +--------------+  +--------------+  +--------------+
             fe80::2            fe80::1           fe80::3
              L2(S1)             L2(R)             L2(S2) 
                |                  |                 |
    X-----+-----+------------------+-----------------+----+----X
          |       AERO Link                               |
         L2(A)                                          L2(B)
  fe80::2001:db8:0:0                              fe80::2001:db8:1:0
  +--------------+                                 +--------------+
  | AERO Client A|                                 | AERO Client B|
  | (default->S1)|                                 | (default->S2)|
  +--------------+                                 +--------------+
  2001:DB8:0::/48                                  2001:DB8:1::/48
          |                                                |
         .-.                                              .-.
      ,-(  _)-.   2001:db8:0::1      2001:db8:1::1     ,-(  _)-.
   .-(_  IP   )-.   +---------+      +---------+    .-(_  IP   )-.
 (__    EUN      )--|  Host C |      |  Host D |--(__    EUN      )
    `-(______)-'    +---------+      +---------+     `-(______)-'

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (=137)  |  Code (=0/1)  |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Reserved                    | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Destination Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-