Skip to main content

Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces
draft-templin-atn-aero-interface-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Fred Templin , Tony Whyman
Last updated 2019-05-10
Replaced by draft-templin-6man-omni-interface, draft-templin-6man-omni-interface
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-atn-aero-interface-01
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]