Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track A. Whyman
Expires: November 9, 2019 MWA Ltd c/o Inmarsat Global Ltd
May 8, 2019
Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces
draft-templin-atn-aero-interface-01.txt
Abstract
Mobile 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 9, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Templin & Whyman Expires November 9, 2019 [Page 1]
Internet-Draft IPv6 over AERO Interfaces May 2019
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Aeronautical ("aero") Interface Model . . . . . . . . . . . . 4
5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
6. Frame Format and Encapsulation . . . . . . . . . . . . . . . 6
7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 7
8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 8
9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 10
10. Router Discovery . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. S/TLLAO Extensions for Special-Purpose Links . . . . 15
Appendix B. Prefix Length Considerations . . . . . . . . . . . . 16
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
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
Templin & Whyman Expires November 9, 2019 [Page 2]
Internet-Draft IPv6 over AERO Interfaces May 2019
specifies the transmission of IPv6 packets [RFC8200] over
aeronautical ("aero") interfaces.
2. Terminology
The terminology in the normative references applies; especially, the
terms "link" and "interface" are the same as defined in the IPv6
[RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications.
The following terms are defined within the scope of this document:
underlying Internetwork
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.
aero link
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.
aero interface
a node's attachment to an aero link, and configured over one or
more underlying interfaces
aero node
a node with an aero interface attached to an aero link.
aero address
an IPv6 link-local address constructed as specified in Section 7,
and assigned to an aero interface.
underlying link
a link that connects an aero node to the underlying Internetwork.
underlying interface
an aero node's interface point of attachment to an underlying
link.
Templin & Whyman Expires November 9, 2019 [Page 3]
Internet-Draft IPv6 over AERO Interfaces May 2019
3. Requirements
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 [RFC2119]. Lower case
uses of these words are not to be interpreted as carrying RFC2119
significance.
4. Aeronautical ("aero") Interface Model
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
[RFC7847], and reproduced here (in an augmented form) as shown in
Figure 1. The aero interface is therefore a single network-layer
interface with multiple link-layer addresses.
+----------------------------+
| TCP/UDP |
Session-to-IP +---->| |
Address Binding | +----------------------------+
+---->| IPv6 |
IP Address +---->| |
Binding | +----------------------------+
+---->| aero Interface |
Logical-to- +---->| (aero address) |
Physical | +----------------------------+
Interface +---->| L2 | L2 | | L2 |
Binding |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+
Figure 1: aero Interface Architectural Layering Model
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:
o 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
Templin & Whyman Expires November 9, 2019 [Page 4]
Internet-Draft IPv6 over AERO Interfaces May 2019
from an MNP (see: Section 7, this means that no Duplicate Address
Detection (DAD) messaging is necessary over either the aero
interface or any underlying interfaces.
o 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.
o coordinating underlying interfaces in this way allows them to be
presented to a mobility anchor point, thereby enabling more agile
multilink and mobility support.
o 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 [RFC7847].
5. Maximum Transmission Unit
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.
Templin & Whyman Expires November 9, 2019 [Page 5]
Internet-Draft IPv6 over AERO Interfaces May 2019
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.
6. Frame Format and Encapsulation
The aero interface transmits IPv6 packets according to the frame
format of the underlying interface while using the link-local address
format specified in Section 7. For example, for an Ethernet
interface the frame format is exactly as specified in [RFC2464], for
an IPv6 tunnel over IPv4 the frame format is exactly as specified in
[RFC4213], 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.
Templin & Whyman Expires November 9, 2019 [Page 6]
Internet-Draft IPv6 over AERO Interfaces May 2019
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: Section 5) or through the use
of fragmentation during encapsulation.
7. Link-Local Addresses
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: Appendix B). For example, for the MNP:
2001:db8:1000:2000::/56
the corresponding aero addresses are:
fe80::2001:db8:1000:2000
fe80::2001:db8:1000:2001
fe80::2001:db8:1000:2002
... etc. ...
fe80::2001:db8:1000:20ff
When 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 [RFC4291], 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
Templin & Whyman Expires November 9, 2019 [Page 7]
Internet-Draft IPv6 over AERO Interfaces May 2019
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 [RFC4862].
8. Address Mapping - Unicast
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 [RFC4861]. IPv6 ND
messages on aero interfaces include zero or more Source/Target Link-
Layer Address Options (S/TLLAOs) formatted as shown in Figure 2:
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 | Length = 5 | Prefix Length |S|R|D|X|N|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-Layer Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Source/Target Link-Layer Address Option (S/TLLAO) Format
In this format:
Templin & Whyman Expires November 9, 2019 [Page 8]
Internet-Draft IPv6 over AERO Interfaces May 2019
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
octets).
o 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.
o 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.
o 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'.
o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA
message for each Interface ID that is to be disabled in the
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.
o 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..
o 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'.
o Resvd is set to the value '0' on transmission and ignored on
receipt.
o 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.,
Templin & Whyman Expires November 9, 2019 [Page 9]
Internet-Draft IPv6 over AERO Interfaces May 2019
routers MUST use Interface ID '0xfff', and MNs MUST number their
Interface IDs with values between 0 and 0xfffe.
o 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 [RFC2464]) 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'.
o P(i) is a set of Preferences that correspond to the 64
Differentiated Service Code Point (DSCP) values [RFC2474]. 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'.
9. Address Mapping - Multicast
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 [RFC4605] while using the link-
layer address of the router as the link-layer address for all
multicast packets.
Templin & Whyman Expires November 9, 2019 [Page 10]
Internet-Draft IPv6 over AERO Interfaces May 2019
10. Router Discovery
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 [RFC4861].
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.
Templin & Whyman Expires November 9, 2019 [Page 11]
Internet-Draft IPv6 over AERO Interfaces May 2019
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:
o 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.
o 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.
o 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.
o 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
Templin & Whyman Expires November 9, 2019 [Page 12]
Internet-Draft IPv6 over AERO Interfaces May 2019
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.
11. IANA Considerations
No IANA actions are required.
12. Security Considerations
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.
13. Acknowledgements
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.
.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Templin & Whyman Expires November 9, 2019 [Page 13]
Internet-Draft IPv6 over AERO Interfaces May 2019
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
14.2. Informative References
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529,
DOI 10.17487/RFC2529, March 1999,
<https://www.rfc-editor.org/info/rfc2529>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213,
DOI 10.17487/RFC4213, October 2005,
<https://www.rfc-editor.org/info/rfc4213>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
August 2006, <https://www.rfc-editor.org/info/rfc4605>.
Templin & Whyman Expires November 9, 2019 [Page 14]
Internet-Draft IPv6 over AERO Interfaces May 2019
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015,
<https://www.rfc-editor.org/info/rfc7421>.
[RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface
Support for IP Hosts with Multi-Access Support", RFC 7847,
DOI 10.17487/RFC7847, May 2016,
<https://www.rfc-editor.org/info/rfc7847>.
Appendix A. S/TLLAO Extensions for Special-Purpose Links
The S/TLLAO format specified in Section 8 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
Figure 3, where the Length value is 7 and the 'Q(i)' fields provide
link preferences for the corresponding transport port number.
Templin & Whyman Expires November 9, 2019 [Page 15]
Internet-Draft IPv6 over AERO Interfaces May 2019
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 | Length = 7 | Prefix Length |S|R|D|X|N|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-Layer Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ATN/IPS Extended S/TLLAO Format
Appendix B. Prefix Length Considerations
The IPv6 addressing architecture [RFC4291] 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 [RFC7421].
MN aero addresses insert the most-significant 64 MNP bits into the
least-significant 64 bits of the prefix fe80::/64, however [RFC4291]
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).
Templin & Whyman Expires November 9, 2019 [Page 16]
Internet-Draft IPv6 over AERO Interfaces May 2019
Appendix C. Change Log
<< RFC Editor - remove prior to publication >>
Differences from draft-templin-atn-aero-interface-00 to draft-
templin-atn-aero-interface-01:
o Updates based on list review comments on IETF 'atn' list from
4/29/2019 through 5/7/2019 (issue tracker established)
o added list of opportunties afforded by the single virtual link
model
o added discussion of encapsulation considerations to Section 6
o noted that DupAddrDetectTransmits is set to 0
o removed 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.
o Significant re-work of "Router Discovery" seciton.
o New Appendix B on Prefix Length considerations
First draft version (draft-templin-atn-aero-interface-00):
o Draft based on consensus decision of ICAO Working Group I Mobility
Subgroup March 22, 2019.
Authors' Addresses
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin & Whyman Expires November 9, 2019 [Page 17]
Internet-Draft IPv6 over AERO Interfaces May 2019
Tony Whyman
MWA Ltd c/o Inmarsat Global Ltd
99 City Road
London EC1Y 1AX
England
Email: tony.whyman@mccallumwhyman.com
Templin & Whyman Expires November 9, 2019 [Page 18]