This post is the second in a series on a new layer in the Internet architecture known as the Adaptation Layer. The first post examined the basic architectural principles behind the Overlay Multilink Network Interface (OMNI) Adaptation Layer (OAL), including using encapsulation, fragmentation, reassembly and fragment retransmission. In this post, we discuss further implications including integrity, efficiency and security.
The Overlay Multilink Network Interface (OMNI) connects the IP layer to a new layer in the Internet architecture termed the (OMNI) Adaptation Layer (OAL). The OAL logically occurs below the IP layer (Layer 3) and above the data link layer (Layer 2) but does not have an associated layer number itself. The OAL performs encapsulation, segmentation, and reassembly as necessary at its own layer to adapt the IP layer to inter-networked paths that may include many heterogeneous data links.
The OAL accepts IP packets from Layer 3 and appends an IPv6 header with addresses relevant to a Non-Broadcast, Multiple Access (NBMA) overlay network manifested by the collection of all nodes that configure OMNI interfaces. The OAL then performs fragmentation if necessary to ensure that encapsulated IP packets will be delivered to the OAL peer without loss due to a size restriction. The OAL next presents each fragment produced to a data link layer interface, which appends any additional encapsulations to create a ‘carrier packet’. This OAL source transmits the carrier packet over the networked path toward the OAL destination.
OAL role in multi-layered integrity architecture
The data link layer interface forwards carrier packets either directly via some form of physical media (for example, Ethernet, Wi-Fi and cellular) or through a lower layer encapsulation service such as an IP-in-IP tunnel. Once a carrier packet is presented to the data link layer, however, it becomes subject to any integrity checks performed at that layer. Physical data link types such as Ethernet often include an integrity check to detect bit errors incurred during transmission. The widely used 32-bit Cyclical Redundancy Check (CRC-32) employed by many data links is considered effective for carrier packet sizes up to ~9KB, while for larger sizes, the check becomes progressively more prone to undetected errors.
Some virtual data link types such as IP-in-IP tunnels fail to include an integrity check of any kind at their layer meaning that upper layer integrity checks would not benefit from a first-pass lower-layer check. Left unmitigated, this could result in undetected data corruption passed to upper layers when instead it could have been discarded at a lower layer without further processing. The result is an unfulfilled gap in the multilayer integrity architecture.
For these reasons, the OAL includes an adaptation layer integrity check in a manner consistent with the layered architecture philosophy. The OAL source applies the 8-bit Fletcher’s Algorithm over the length of the OAL-encapsulated packet before fragmentation, then the OAL destination verifies the check following reassembly. The integrity check (along with the OAL IPv6 fragment header 32-bit identification value) ensures that no reassembly mis-associations occur and that any undetected data corruption passed up by lower layers will very likely be captured and discarded in the OAL without being delivered to the upper layers.
OAL efficiency through minimal encapsulation
A common concern regarding layering is the size of the encapsulation headers added at each layer since they represent extra overhead that cannot be used to convey valuable Upper Layer Protocol (ULP) data.
Indeed, the more encapsulation overhead included in each carrier packet, the greater the amount of ‘waste’ that diminishes network utilization. Since the OAL inserts an IPv6 header, fragment header, and any other extension headers (which, at a minimum, consume 48 octets in their uncompressed form) the concern becomes acute, especially for transmission over ‘low-end’ data links such as some wireless media.
The OAL addresses this concern by providing compressed header formats that greatly reduce encapsulation overhead. Communicating OAL peers use the Automatic Extended Route Optimization (AERO) service over their OMNI interfaces to exchange IPv6 Neighbor Discovery (IPv6 ND) control messages that establish neighbor cache soft state. During this exchange, the peers as well as any intermediate OAL nodes in the path, assign a Multilink Forwarding Vector Index (MFVI) and store the immutable information in the OAL IPv6 headers as neighbor cache soft state.
After neighbor cache soft state is established, future carrier packets exchanged between the peers only need to carry any OAL IPv6 header mutable information, reassembly parameters, including the 32-bit packet identification value, and sometimes the 32-bit next-hop MFVI. This mutable information can be carried in compressed OAL headers of 12 octets or less (8 octets or less when the MVFI is omitted). Peers that connect via low-end wireless links can also often establish a ‘tethered’ relationship with an AERO/OMNI proxy on the link. In that case, the proxy creates neighbor cache entries on behalf of the peer, and the peer can send and receive packets over the wireless link without including any OAL header information.
The OMNI interface also differs from ordinary IP interfaces in that it does not impose an upper bound on the maximum packet size. Since the OAL performs fragmentation at its own layer, the original IP packets can be admitted into the OMNI interface regardless of their size then subjected to OAL fragmentation if necessary. However, the headers of the original IP packet appear only in the first resulting carrier packet and do not appear in any additional carrier packets. The OMNI interface can, therefore, forward fewer and larger original IP packets much more efficiently than an ordinary IP interface can forward more and smaller packets.
(Note: Future posts will discuss other packet sizing considerations in greater detail.)
OAL and security
The OAL plays an important role in the multi-layer AERO/OMNI security architecture to securely establish routing information that cannot be subverted by an attacker. This permits upper layers to apply end-to-end security services such as SSL/TLS/DTLS in the same fashion as for secured Internet services such as online banking.
While additional security services can be applied at the data-link layer or below (for example, by establishing a Virtual Private Network (VPN) and/or through physical security provisions), such arrangements may be less flexible and less efficient than desired for some environments. When OAL nodes are deployed in environments where no security services are applied at the data link or physical layer (for example, in the global public Internet) the OAL becomes responsible for assuring data origin verification.
OAL peers coordinate through the exchange of AERO/OMNI IPv6 ND messages, including Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA) and (sometimes) Redirect. The OAL peers include an authentication code in their IPv6 ND messages and include sequence and acknowledgement numbers in their initial exchanges in the same fashion as for the Transmission Control Protocol (TCP). The purpose of exchanging sequence numbers is to establish windows of acceptable IPv6 identification values for the carrier packets generated by each peer.
When OAL peers perform an IPv6 ND message exchange, they select an unpredictable initial identification sequence number and announce it as part of an exchange conducted in the same manner as the TCP ‘three-way handshake’. This results in the creation of a ‘window’ of acceptable identification values for received carrier packets that each peer can use as a first-pass data origin filter. The purpose of this data origin verification is to provide reasonable assurance that carrier packets originate from the (trusted) peer and not from an attacker.
Each OAL node then examines the identification values in received carrier packets and only admits the packets into the reassembly cache if the identification value is within the current window. Therefore, OAL data origin verification serves as a first-pass filter to avoid admission of spurious carrier packets into the reassembly cache; if any spurious carrier packets somehow evade the test, the reassembly cache will reject any with incongruent reassembly parameters (for example, data offsets and lengths). Again, this lightweight verification provides a useful filter for rejecting spurious packets within the OAL instead of passing them up to higher layers. This greatly improves efficiency for upper layers especially when the OAL receives a flood of spurious carrier packets.
This article is the second in a series of ongoing posts that intend to provide useful architectural insights. The next post will discuss OMNI and the ‘6 M’s’ of modern mobile Internet-working, including multilink, multinet, mobility, multicast, multihop and MTU determination.
Fred Templin is an Internet networking research engineer working in the industry since 1986, where he has been deeply involved in the evolution of the Internet Protocol over Ethernet, FDDI, ATM, wireless and other data link and network layer technologies.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.