Transmission of IPv6 Packets
over Aeronautical ("aero") InterfacesBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgMWA Ltd c/o Inmarsat Global Ltd99 City RoadLondonEC1Y 1AXEnglandtony.whyman@mccallumwhyman.comI-DInternet-DraftMobile nodes (e.g., aircraft of various configurations) act as mobile
routers for their on-board networks, and may have multiple data links
for communicating with networked correspondents. Mobile nodes configure
a virtual interface (termed the "aero interface") as a thin layer over
their underlying data link interfaces. This document specifies the
transmission of IPv6 packets over aeronautical ("aero") interfaces.Mobile Nodes (MNs) such as aircraft of various configurations may
have multiple data links for communicating with networked
correspondents. These data links often have differing performance, cost
and availability characteristics that can change dynamically according
to mobility patterns, flight phases, proximity to infrastructure,
etc.Each MN receives an IPv6 Mobile Network Prefix (MNP) that can be used
by on-board networks regardless of the actual link or links selected for
data transport. The MN acts as a mobile router on behalf of its on-board
networks, but appears as a multi-addressed host from the perspective of
off-board correspondents. This implies the need for a virtual interface
(termed the "aero interface") configured as a thin layer over the
underlying data link interfaces.The aero interface is therefore the only interface abstraction
exposed to the IPv6 layer, and behaves according to the Non-Broadcast,
Multiple Access (NBMA) interface principle. This document specifies the
transmission of IPv6 packets over aeronautical
("aero") interfaces.The terminology in the normative references applies; especially, the
terms "link" and "interface" are the same as defined in the IPv6 and IPv6 Neighbor Discovery (ND) specifications.The following terms are defined within the scope of this
document:a connected network
region that has a coherent IP addressing plan and is either
physically isolated or separated from other networks by packet
filtering border routers. Examples include private enterprise
networks, aviation networks and the global public Internet
itself.a Non-Broadcast, Multiple Access
(NBMA) virtual overlay configured over an underlying Internetwork.
Nodes on the aero link appear as single-hop neighbors from the
perspective of the virtual overlay even though they may be separated
by many underlying Internetwork hops. An aero link may comprise
multiple segments joined by bridges the same as for any link; the
underlying Internetwork addressing plans in each segment may be
mutually exclusive and managed by different administrative
entities.a node's attachment to an aero
link, and configured over one or more underlying interfacesa node with an aero interface
attached to an aero link.an IPv6 link-local address
constructed as specified in , and
assigned to an aero interface.a link that connects an aero
node to the underlying Internetwork.an aero node's interface
point of attachment to an underlying link.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Lower case uses of these words are not to be interpreted as carrying
RFC2119 significance.An aero interface is a MN's virtual interface configured over one or
more underlying links, which may be physical (e.g., an Ethernet) or
virtual (e.g., an Internet or higher-layer "tunnel"). The MN discovers
routers on the aero link through Router Solicitation (RS) / Router
Advertisement (RA) message exchanges.The aero interface architectural layering model is the same as in
, and reproduced here (in an augmented form) as
shown in . The aero interface is therefore a
single network-layer interface with multiple link-layer addresses.The aero virtual interface gives rise to a number of opportunities
that are not available if each underlying interface was exposed to the
IPv6 layer independently:since IPv6 interfaces must assign a unique IPv6 link-local
address, only the aero interface (i.e., and not the underlying
interfaces) needs to assign a unique IPv6 link-local address. Since
aero interface link-local addresses are uniquely derived from an MNP
(see: , this means that no Duplicate
Address Detection (DAD) messaging is necessary over either the aero
interface or any underlying interfaces.as underlying interfaces become activated or deactivated (e.g.,
due to changes in aircraft flight phases), an active underlying
interface can be used to report on the status of an interface that
has been deactivated.coordinating underlying interfaces in this way allows them to be
presented to a mobility anchor point, thereby enabling more agile
multilink and mobility support.exposing only a single virtual interface abstraction to the IPv6
layer allows for traffic engineering (including QoS based link
selection, packet replication, load balancing, etc.) at the link
layer and with no supporting structures needed at the IPv6
layer.Other opportunities are discussed in .The aero interface Maximum Transmission Unit (MTU) is derived from
the underlying interface MTUs and set to a value that ensures that the
MTU for each underlying interface is respected. The aero interface MTU
may be common to all data flows or differ between data flows. Regardless
of the strategy by which the MTU is determined, the aero link
administrative authority should configure routers to advertise a
conservative MTU for all nodes noting that fragmentation should be
avoided if possible.In common practice, there may be additional encapsulation headers
inserted by various forms of Layer 2 tunnels on the path to an on-link
neighbor. Such tunnels SHOULD be instrumented to accommodate the native
MTU of the underlying interface, but in some cases it may be prudent to
reduce the size of the underlying interface MTU to allow room for L2
encapsulation. Especially for underlying links with low-end performance
characteristics, it is imperative that packets that successfully
traverse the underlying link are not dropped in the network due to a
size restriction.In a preferred approach, the aero interface MTU should be set to a
value no smaller than the largest MTU among all underlying interfaces.
The aero interface itself then MUST return locally-generated ICMPv6
"Packet Too Big" messages for packets that are too large to traverse the
selected underlying interface in one piece. This ensures that the MTU is
adaptive and reflects the underlying interface used for a given data
flow.Alternatively, the aero interface MTU may be determined as the
minimum MTU among all underlying interfaces. However, this may result in
under-utilization of robust underlying interfaces after a low-end
underlying interface has degraded the common minimum MTU. For example,
if the underlying interfaces have MTUs 1500, 1472 and 1400, then the
minimum aero interface MTU is 1400.If any underlying interface has an MTU smaller than 1280, the aero
interface MUST either perform IPv6 fragmentation when using this
interface or disable the underlying interface.The MTU for an underlying interface is normally determined from
information provided either statically or dynamically when the interface
becomes active. If an underlying interface MTU dynamically reports an
MTU smaller than any minimum MTU already determined then the aero
interface MUST either perform IPv6 fragmentation when using this
interface, or disable the underlying interface.The aero interface MAY also receive an RA with an MTU option. If the
advertised MTU is no larger than 1500, the aero interface MTU is set to
the new value and the aero interface MUST either perform IPv6
fragmentation over any underlying interface having a smaller MTU or
disable the underlying interface.If the advertised MTU is larger than 1500, the aero interface sets
the new value and disables any underlying interface having a smaller MTU
instead of fragmenting, since IPv6 destinations are not required to
reassemble more than 1500 bytes.The aero interface transmits IPv6 packets according to the frame
format of the underlying interface while using the link-local address
format specified in . For example, for an
Ethernet interface the frame format is exactly as specified in , for an IPv6 tunnel over IPv4 the frame format is
exactly as specified in , etc.MNs and routers exchange IPv6 ND messages over their aero interfaces
using link-local IPv6 source and destination addresses. Therefore, when
the MN and router are not on the same physical link encapsulation is
necessary to convey the messages over multiple underlying network hops.
When an underlying interface connects to an underlying network that
applies encapsulation, the aero interface need not apply encapsulation
itself. When the underlying network does not apply encapsulation, the
aero interface must apply some form of IPv6 over IP encapsulation
according the IP protocol version of the underlying interface.When encapsulation is applied either by the underlying network or the
aero interface itself, the size of IPv6 packets that can be conveyed in
a single piece is reduced due to the size of the encapsulation headers.
The encapsulation headers can be accommodated by either reducing the
aero interface MTU (see: ) or through the use of
fragmentation during encapsulation.A MN's "aero address" is an IPv6 link-local address with an interface
identifier based on its assigned MNP. MN aero addresses begin with the
prefix fe80::/64 followed by a 64-bit prefix taken from the MNP (see:
). For example, for the MNP:2001:db8:1000:2000::/56the corresponding aero addresses are:fe80::2001:db8:1000:2000fe80::2001:db8:1000:2001fe80::2001:db8:1000:2002... etc. ...fe80::2001:db8:1000:20ffWhen the MN configures aero addresses from its MNP, it assigns them
to the aero interface. The lowest-numbered aero address serves as the
"base" address (for example, for the MNP 2001:db8:1000:2000::/56 the
base aero address is fe80::2001:db8:1000:2000). MNs and routers use the
base address for the purpose of maintaining neighbor cache entries, but
the MN accepts packets destined to all aero addresses as equivalent.A router's aero address is allocated from the range fe80::/96, and
MUST be managed for uniqueness by the aero link administrative
authority. The lower 32 bits of the aero address includes a unique
integer value, e.g., fe80::1, fe80::2, fe80::3, etc. The address fe80::
is reserved as the IPv6 link-local Subnet Router Anycast address , and the address fe80::ffff:ffff is reserved as the
unspecified aero address; hence, these values are not available for
general assignment.For multi-segment aero links, the routers of each segment MUST assign
aero addresses that are unique among all routers on the (collective)
link. Although the address assignment policy is completely at the
discretion of the aero link administrative authority, a useful technique
may be to assign a different aggregated portion of the fe80::/96 prefix
to each segment, e.g., fe80::/120, fe80::0100/120, fe80::0200/120,
etc.Since the MNs aero addresses are guaranteed unique by the nature of
the unique MNP encapsulation, and since the router's aero address is
guaranteed unique through administrative configuration, aero interfaces
set the autoconfiguration variable DupAddrDetectTransmits to 0 .The aero interface maintains a neighbor cache for tracking
per-neighbor state the same as for any interface. The aero interface
uses standard IPv6 Neighbor Discovery (ND) messages including Router
Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation
(NS), Neighbor Advertisement (NA) and Redirect .
IPv6 ND messages on aero interfaces include zero or more Source/Target
Link-Layer Address Options (S/TLLAOs) formatted as shown in :In this format:Type is set to '1' for SLLAO or '2' for TLLAO.Length is set to the constant value '5' (i.e., 5 units of 8
octets).Prefix Length is set to the MNP prefix length for the aero
address found in the source (RS), destination (RA) or target (NA)
address. For RS messages, the router creates or updates a neighbor
cache entry and announces the MNP in the routing system, then
returns an RA with Router Lifetime set to the MNP assertion
lifetime.S (the 'Source' bit) is set to '1' in the S/TLLAO of an ND
message that corresponds to the underlying interface over which the
ND message is sent, and set to 0 in all other S/TLLAOs.R (the "Release" bit) is set to '1' in the SLLAO of an RS message
sent for the purpose of withdrawing an MNP; otherwise, set to '0'.
If the message contains multiple SLLAOs, only the R value in the
SLLAO with S set to 1 is consulted and the values in other SLLAOs
are ignored. The router withdraws the MNP, then returns an RA with
Router Lifetime set to '0'.D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA
message for each Interface ID that is to be disabled in the
recipient's neighbor cache entry; otherwise, set to '0'. If the
message contains an S/TLLAO with D=1 and Interface ID 0xffff, the
node disables the entire neighbor cache entry. If the message
contains multiple S/TLLAOs the D value in each S/TLLAO is
consulted.X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA
message when there is a proxy in the path; otherwise, set to '0'. If
the message contains multiple SLLAOs, only the X value in the SLLAO
with S set to '1' is consulted and the values in other SLLAOs are
ignored..N (the "(Network Address) Translator (NAT)" bit) is set to '1' in
the SLLAO of an RA message if there is a translator in the path;
otherwise, set to '0'.Resvd is set to the value '0' on transmission and ignored on
receipt.Interface ID is set to a 16-bit integer value corresponding to a
specific underlying interface. Once the MN has assigned an Interface
ID to an underlying interface, the assignment MUST remain unchanged
until the MN disables the aero interface. The value '0xffff' is
reserved as the router Interface ID, i.e., routers MUST use
Interface ID '0xfff', and MNs MUST number their Interface IDs with
values between 0 and 0xfffe.Port Number and Link-Layer Address are set to the addresses
assigned to the underlying interface, or to '0' when the addresses
are left unspecified. For transmission over physical interfaces such
as Ethernet, the Link-Layer Address is set to the same format as in
the appropriate interface specification (e.g., IPv6 over Ethernet
) beginning with the lowest-numbered byte of
the field and ending in trailing null padding to a total of 16
bytes. For transmission over tunnel interfaces, the Link-Layer
address is set to an IPv6 address for IPv6 encapsulation or an
IPv4-mapped IPv6 address for IPv4 encapsulation. When TCP or UDP are
used as part of the encapsulation, Port Number is set to the
encapsulation protocol port number; otherwise, set to '0'.P(i) is a set of Preferences that correspond to the 64
Differentiated Service Code Point (DSCP) values . Each P(i) is set to the value '0' ("disabled"),
'1' ("low"), '2' ("medium") or '3' ("high") to indicate a QoS
preference level for underlying interface selection purposes.MNs such as aircraft typically have many wireless data link types
(e.g. satellite-based, cellular, terrestrial, air-to-air directional,
etc.) with diverse performance, cost and availability properties. From
the perspective of ND, the aero interface would therefore appear to have
multiple link-layer addresses. In that case, ND messages MAY include
multiple S/TLLAOs -- each with an Interface ID that corresponds to a
specific underlying interface.When the MN includes S/TLLAOs solely for the purpose of announcing
new QoS preferences, it sets both Port Number and Link-Layer Address to
0 to indicate that the addresses are not to be updated in the router's
neighbor cache.When an ND message includes multiple S/TLLAOs, the S/TLLAO
corresponding to the underlying interface used to transmit the message
MUST set S to '1'.When the underlying network does not support multicast, aircraft map
link-scoped multicast addresses to the link-layer address of a router,
which acts as a multicast forwarding agent. The mobile router on board
the aircraft also serves as an IGMP/MLD Proxy for its EUNs and/or hosted
applications per while using the link-layer
address of the router as the link-layer address for all multicast
packets.MNs and routers configure aero interfaces that observe the properties
discussed in the previous section. The aero interface and its underlying
interfaces are said to be in either the "UP" or "DOWN" state according
to administrative actions in conjunction with the interface connectivity
status. An aero interface transitions to UP or DOWN through
administrative action and/or through state transitions of the underlying
interfaces. When a first underlying interface transitions to UP, the
aero interface also transitions to UP. When all underlying interfaces
transition to DOWN, the aero interface also transitions to DOWN.MNs and routers coordinate through RS/RA exchanges via the aero
interface, and use IPv6 ND messages to maintain neighbor cache entries.
When an aero interface transitions to UP, the MN sends initial RS
messages to assert its MNP and register an initial set of underlying
interfaces that are also UP. The MN sends additional RS messages to the
router's unicast address to refresh MNP and/or router lifetimes, and to
register/deregister underlying interfaces as they transition to UP or
DOWN. Routers configure their aero interfaces as advertising interfaces,
and therefore send RA messages with configuration information in
response to a MN's RS message. Routers send immediate unicast RA
responses without delay; therefore, the 'MAX_RA_DELAY_TIME' and
'MIN_DELAY_BETWEEN_RAS' constants for multicast RAs do not apply.
Routers MAY send periodic and/or event-driven unsolicited RA messages,
but are not required to do so for unicast advertisements .The MN sends RS messages from within the aero interface while using
an UP underlying interface as the outbound interface. Each message is
formatted as an ordinary RS message as though it originated from the
IPv6 layer, but the process is coordinated wholly from within the aero
interface and is therefore opaque to the IPv6 layer. The MN sends an
initial RS message over an UP underlying interface with its base aero
address as the source address, all-routers multicast as the destination
address and with an SLLAO with a valid Prefix Length for the MNP. The
SLLAO also sets S to 1 and contains valid Interface ID and P(i) values
appropriate for the underlying interface.When the router receives the RS message it accepts the message if the
prefix assertion was acceptable (otherwise, it drops the message
silently). If the prefix assertion was accepted, the router injects the
MNP into the routing system then registers the new Interface ID, Port
Number, Link-Layer Address and P(i) values in a neighbor cache entry.
The router then returns an RA with its aero address as the source
address, the aero address of the MN as the destination address and with
Router Lifetime set to a non-zero value.After the MN receives the initial RA confirming the MNP assertion, it
notes the router's aero address and uses this address as the destination
for all subsequent RS messages it sends to this router. The MN then
manages its underlying interfaces according to their states as
follows:When an underlying interface transitions to UP, the MN sends an
RS over the underlying interface with its base aero address as the
source address, the router's aero address as the destination
address, and with one or more SLLAOs. The SLLAO corresponding to the
underlying interface sets S to 1 and contains valid Interface ID and
P(i) values appropriate for this underlying interface, while any
additional SLLAOs set S to 0 and contain valid Interface ID and P(i)
values appropriate for other underlying interfaces.When an underlying interface transitions to DOWN, the MN sends an
RS over any UP underlying interface with an SLLAO for the DOWN
underlying interface with D set to 1. The RS may include additional
SLLAOs for additional underlying interfaces as above.When a MN wishes to release its router from service, it sends an
RS message over any UP underlying interface with an SLLAO with R set
to 1. When the router receives the RS message, it withdraws the MNP
from the routing system and marks its neighbor cache entry for the
MN as "departed". The router then returns an RA message with Router
Lifetime set to 0.When all of a MNs underlying interfaces have transitioned to
DOWN, the router withdraws the MNP and marks the neighbor cache
entry as "departed" the same as if it had received an RS with an
SLLAO with R set to 1. This gives rise to the possibility that an
underlying network could issue RS messages on the MN's behalf in
case the MN is unable to communicate.The MN is responsible for retrying each RS/RA exchange up to
MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL
seconds until an RA is received. If no RA is received, the MN declares
the underlying interface DOWN, but MAY try again later, e.g., if
underlying link conditions become more favorable.The IPv6 layer sees the aero interface as an ordinary IPv6 interface.
Therefore, when the IPv6 layer sends an RS message over the aero
interface, the aero interface must return an internally-generated RA
message as though the message originated from the router. The
internally-generated RA message must contain configuration information
(such as Router Lifetime, MTU, etc.) that is consistent with the
information received from the RAs generated by the actual router.
Whether the aero interface RS/RA process is initiated from the receipt
of an RS message from the IPv6 layer is an implementation matter. Some
implementations may elect to defer the RS/RA process until an RS is
received from the IPv6 layer, while others may elect to initiate the
RS/RA process independently of any IPv6 layer messaging.No IANA actions are required.Security considerations are the same as defined for the underlying
interface types, and readers are referred to the appropriate underlying
interface specifications.IPv6 and IPv6 ND security considerations also apply, and are
specified in the normative references.This document was prepared per the consensus decision at the 8th
Conference of the International Civil Aviation Organization (ICAO)
Working Group-I Mobility Subgroup on March 22, 2019. Attendees and
contributors included: Guray Acar, Danny Bharj, Francois
D´Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, Vaughn
Maiolla, Tom McParland, Victor Moreno, Madhu Niraula, Brent Phillips,
Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg Saccone, Robert Segers,
Stephane Tamalet, Fred Templin, Bela Varkonyi, Tony Whyman, and Dongsong
Zeng.The following individuals are acknowledged for their useful comments:
Pavel Drasil, Zdenek Jaron..The S/TLLAO format specified in includes a
Length value of 5 (i.e., 5 units of 8 octets). However, special-purpose
aero links may extend the basic format to include additional fields and
a Length value larger than 5.For example, adaptation of the aero interface to the Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS)
includes link selection preferences based on transport port numbers in
addition to the existing DSCP-based preferences. ATN/IPS nodes maintain
a map of transport port numbers to 64 possible preference fields, e.g.,
TCP port 22 maps to preference field 8, TCP port 443 maps to preference
field 20, UDP port 8060 maps to preference field 34, etc. The extended
S/TLLAO format for ATN/IPS is shown in , where
the Length value is 7 and the 'Q(i)' fields provide link preferences for
the corresponding transport port number.The IPv6 addressing architecture reserves
the prefix ::/8; this assures that MNPs will not begin with ::32 so that
MN and router aero addresses cannot overlap. Additionally, this
specification observes the 64-bit boundary in IPv6 addresses .MN aero addresses insert the most-significant 64 MNP bits into the
least-significant 64 bits of the prefix fe80::/64, however defines the link-local prefix as fe80::/10 meaning
"fe80" followed by 54 unused bits followed by the least-significant 64
bits of the address. Future versions of this specification may adapt the
54 unused bits for extended coding of MNP prefixes of /65 or longer (up
to /118).<< RFC Editor - remove prior to publication >>Differences from draft-templin-atn-aero-interface-00 to
draft-templin-atn-aero-interface-01:Updates based on list review comments on IETF 'atn' list from
4/29/2019 through 5/7/2019 (issue tracker established)added list of opportunties afforded by the single virtual link
modeladded discussion of encapsulation considerations to Section 6noted that DupAddrDetectTransmits is set to 0removed discussion of IPv6 ND options for prefix assertions. The
aero address already includes the MNP, and there are many good
reasons for it to continue to do so. Therefore, also including the
MNP in an IPv6 ND option would be redundant.Significant re-work of "Router Discovery" seciton.New Appendix B on Prefix Length considerationsFirst draft version (draft-templin-atn-aero-interface-00):Draft based on consensus decision of ICAO Working Group I
Mobility Subgroup March 22, 2019.