Transmission of IPv6 Packets over AERO Interfaces
draft-templin-atn-aero-interface-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2019-03-29
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Standards Track                               A. Whyman
Expires: September 30, 2019              MWA Ltd c/o Inmarsat Global Ltd
                                                          March 29, 2019

           Transmission of IPv6 Packets over AERO Interfaces
                draft-templin-atn-aero-interface-00.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 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 September 30, 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
   include Simplified BSD License text as described in Section 4.e of

Templin & Whyman       Expires September 30, 2019               [Page 1]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  AERO Interface Model  . . . . . . . . . . . . . . . . . . . .   4
   5.  Maximum Transmission Unit . . . . . . . . . . . . . . . . . .   4
   6.  Frame Format  . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Link-Local Addresses  . . . . . . . . . . . . . . . . . . . .   6
   8.  Address Mapping - Unicast . . . . . . . . . . . . . . . . . .   7
   9.  Address Mapping - Multicast . . . . . . . . . . . . . . . . .  10
   10. Router Discovery and MNP Assertion  . . . . . . . . . . . . .  10
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     14.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Appendix A.  S/TLLAO Extensions for Special-Purpose Links . . . .  13
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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
   specifies the transmission of IPv6 packets [RFC8200] over AERO
   interfaces.

Templin & Whyman       Expires September 30, 2019               [Page 2]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

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.

   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.

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

Templin & Whyman       Expires September 30, 2019               [Page 3]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   uses of these words are not to be interpreted as carrying RFC2119
   significance.

4.  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

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-

Templin & Whyman       Expires September 30, 2019               [Page 4]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   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.

Templin & Whyman       Expires September 30, 2019               [Page 5]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

6.  Frame Format

   AERO interfaces transmit IPv6 packets according to the frame format
   of the underlying interface.  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.

7.  Link-Local Addresses

   A MN's AERO address is an IPv6 link-local address with an interface
   identifier based on its assigned MNP.  AERO addresses begin with the
   prefix fe80::/64 followed by a 64-bit prefix taken from the MNP.  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, 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 September 30, 2019               [Page 6]
Internet-Draft          IPv6 over AERO Interfaces             March 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.

8.  Address Mapping - Unicast

   AERO interfaces maintain a neighbor cache for tracking per-neighbor
   state the same as for any interface.  AERO interfaces use standard
   IPv6 Neighbor Discovery (ND) messages including Router Solicitation
   (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor
   Advertisement (NA) and Redirect.  AERO interface ND messages may
   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 |R|D|X|T| 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: AERO Source/Target Link-Layer Address Option (S/TLLAO)
                                  Format

   In this format:

   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).

Templin & Whyman       Expires September 30, 2019               [Page 7]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   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
      of an ND message used for the purpose of asserting an MNP;
      otherwise set to 0.  If the message contains multiple SLLAOs, only
      the Prefix Length value in the first SLLAO is consulted and the
      values in other SLLAOs are ignored.  For RS messages, the router
      creates 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  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
      first SLLAO 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 255, 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 first
      SLLAO is consulted and the values in other SLLAOs are ignored.

   o  T (the "Translator" bit) is set to '1' in the SLLAO of an RA
      message if there is a link-layer address translator in the path;
      otherwise, set to '0'.  If the message contains multiple SLLAOs,
      only the T value in the first SLLAO is consulted and the values in
      other SLLAOs are ignored.

   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 '255' is reserved as the router Interface ID, i.e., routers
      MUST use Interface ID '255', and MNs MUST number their Interface
      IDs with values in the range of 0-254.

Templin & Whyman       Expires September 30, 2019               [Page 8]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   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 first S/TLLAO MUST
   correspond to the underlying interface used to transmit the message.

   Note that this S/TLLAO format includes network-layer information
   (e.g., Prefix Length) in a link-layer option.  This is due to the
   fact that it is difficult to standardize new IPv6 ND options in a
   timely fashion.  An experimental proposal defines a "Universal RA
   Option" intended for carrying generic network-layer information in
   RS/RA messages [I-D.troan-6man-universal-ra-option].  However, there
   is no way at this time to predict how long the experiment would take
   nor whether it will be successful.

Templin & Whyman       Expires September 30, 2019               [Page 9]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

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.

   When the underlying network supports multicast, AERO interfaces use
   the multicast address mapping specification found in [RFC2529] for
   IPv4 underlying networks and use a TBD site-scoped multicast mapping
   for IPv6 underlying networks.  In that case, border routers must
   ensure that the encapsulated site-scoped multicast packets do not
   leak outside of the AERO link.

10.  Router Discovery and MNP Assertion

   MNs and routers coordinate their MNP assertions and per-link
   parameters through RS/RA exchanges, and use ND messages to maintain
   neighbor cache entries.  Routers configure their AERO interfaces as
   advertising interfaces, and therefore send unicast RA messages with
   configuration information in response to a MN's RS message.
   Thereafter, the MN sends additional RS messages to the router's
   unicast address to refresh MNP and/or router lifetimes.

   To assert an MNP, the MN sends an RS message over any 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 contains valid
   Interface ID and P(i) values appropriate for the underlying
   interface.  When the router receives the RS message it injects the
   MNP into the routing system if the prefix assertion was acceptable,
   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 if the MNP assertion was accepted; otherwise set to
   zero.  The message also includes an SLLAO with Prefix Length set to
   the length of the MNP assertion.

   After the MN receives the RA confirming the MNP assertion, it
   registers each additional underlying interface with the router by
   sending 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 an SLLAO with Prefix Length set to 0.
   The SLLAO also contains valid Interface ID and P(i) values

Templin & Whyman       Expires September 30, 2019              [Page 10]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   appropriate for the underlying interface.  When the router receives
   the RS message it registers the new Interface ID, Port Number, Link-
   Layer Address and P(i) values in the neighbor cache already
   established during MNP assertion.  The router then returns an RA
   message 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.  The message also includes an SLLAO with Prefix
   Length set to 0.

   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 unreachable, but MAY try again
   later (e.g., if underlying link conditions become more favorable).

   MNs that do not need to assert MNP, Port Number, Link-Layer Address,
   Interface ID or P(i) values MAY omit SLLAOs in RS messages.
   Responding routers MAY also omit SLLAOs in the corresponding RAs.

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.

   .

Templin & Whyman       Expires September 30, 2019              [Page 11]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

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>.

   [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>.

   [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

   [I-D.troan-6man-universal-ra-option]
              Troan, O., "The Universal IPv6 Router Advertisement Option
              (experiment)", draft-troan-6man-universal-ra-option-01
              (work in progress), December 2018.

   [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>.

Templin & Whyman       Expires September 30, 2019              [Page 12]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   [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>.

   [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 AERO 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 September 30, 2019              [Page 13]
Internet-Draft          IPv6 over AERO Interfaces             March 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 |R|D|X|T| 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.  Change Log

   << RFC Editor - remove prior to publication >>

   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

Templin & Whyman       Expires September 30, 2019              [Page 14]
Internet-Draft          IPv6 over AERO Interfaces             March 2019

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

   Tony Whyman
   MWA Ltd c/o Inmarsat Global Ltd
   99 City Road
   London  EC1Y 1AX
   England

   Email: tony.whyman@mccallumwhyman.com

Templin & Whyman       Expires September 30, 2019              [Page 15]