Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Standards Track A. Whyman Expires: December 30, 2019 MWA Ltd c/o Inmarsat Global Ltd June 28, 2019 Transmission of IPv6 Packets over Aeronautical ("aero") Interfaces draft-templin-atn-aero-interface-03.txt Abstract Mobile nodes (e.g., aircraft of various configurations) communicate with networked correspondents over multiple access network data links and configure mobile routers to connect their on-board networks. 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 December 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 Templin & Whyman Expires December 30, 2019 [Page 1] Internet-Draft IPv6 over AERO Interfaces June 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 . . . . . . . . . . . . . . . . . . 6 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 6 8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 7 9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 9 10. Conceptual Sending Algorithm . . . . . . . . . . . . . . . . 10 10.1. Multiple Aero Interfaces . . . . . . . . . . . . . . . . 10 11. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Aero Option Extensions for Special-Purpose Links . . 16 Appendix B. Prefix Length Considerations . . . . . . . . . . . . 17 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 access network data links selected for data transport. The MN performs router discovery the same as for customer edge routers [RFC7084], and acts as a mobile router on behalf of its on-board networks. A virtual interface (termed the "aero interface") is configured as a thin layer over the underlying access network interfaces. The aero interface is therefore the only interface abstraction exposed to the IPv6 layer and behaves according to the Non-Broadcast, Templin & Whyman Expires December 30, 2019 [Page 2] Internet-Draft IPv6 over AERO Interfaces June 2019 Multiple Access (NBMA) interface principle, while underlying access network interfaces appear as link layer communication channels in the architecture. The aero interface connects to a virtual overlay cloud service known as the "aero link". Each aero link has one or more associated Mobility Service Prefixes (MSPs) that identify the link. An MSP is an aggregated IPv6 prefix from which aero link MNPs are derived. If the MN connects to multiple aero links, then it configures a separate aero interface for each link. The aero interface interacts with the ground domain Mobility Service (MS) through control message exchanges based on IPv6 Neighbor Discovery [RFC4861]. The MS tracks MN movements and represents their MNPs in a global routing or mapping system. The aero interface provides a traffic engineering nexus for guiding inbound and outbound traffic to the correct underlying interface(s). The IPv6 layer sees the aero interface as a point of connection to the aero link; if there are multiple aero links (i.e., multiple MS's), the IPv6 layer will see multiple aero interfaces. This document specifies the transmission of IPv6 packets [RFC8200] and MN/MS control messaging 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: Access Network (ANET) a data link service network (e.g., an aviation radio access network, satellite service provider network, cellular operator network, etc.) protected by physical and/or link layer security. Each ANET connects to outside Internetworks via border security devices such as proxys, firewalls, packet filtering gateways, etc. ANET interface a node's attachment to a link in an ANET. Internetwork (INET) a connected network region with a coherent IP addressing plan that provides transit forwarding services for ANET mobile nodes and INET correspondents. Examples include private enterprise networks, aviation networks and the global public Internet itself. Templin & Whyman Expires December 30, 2019 [Page 3] Internet-Draft IPv6 over AERO Interfaces June 2019 INET interface a node's attachment to a link in an INET. aero link a virtual overlay cloud service configured over one or more INETs and their connected ANETs. An aero link may comprise multiple segments joined by bridges the same as for any link; the 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 ANET/INET interfaces. aero address an IPv6 link-local address constructed as specified in Section 7, and assigned to an aero interface. 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 Mobile Node (MN) virtual interface configured over one or more ANET interfaces, which may be physical (e.g., an aeronautical radio link) or virtual (e.g., an Internet or higher- layer "tunnel"). The MN coordinates with the aero link Mobility Service (MS) through Router Solicitation (RS) / Router Advertisement (RA) and Neighbor Solicitation (NS) / Neighbor Advertisement (NA) message exchanges. The aero interface architectural layering model is the same as in [RFC7847], and augmented as shown in Figure 1. The IPv6 layer therefore sees the aero interface as a single network layer interface with multiple underlying ANET interfaces that appear as link layer communication channels in the architecture. Templin & Whyman Expires December 30, 2019 [Page 4] Internet-Draft IPv6 over AERO Interfaces June 2019 +----------------------------+ | 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 model gives rise to a number of opportunities: o since aero interface link-local addresses are uniquely derived from an MNP (see: Section 7, no Duplicate Address Detection (DAD) messaging is necessary over the aero interface. o ANET interfaces can remain unnumbered in environments where communications are coordinated entirely over the aero interface. o as ANET interface properties change (e.g., link quality, cost, availability, etc.), any active ANET interface can be used to update the profiles of multiple additional ANET interfaces in a single RS/RA message exchange. This allows for timely adaptation and service continuity under dynamically changing conditions. o coordinating ANET interfaces in this way allows them to be represented in a unified MS profile with provisions for mobility and multilink operations. o exposing 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 while still permitting queuing at the IPv6 layer based on, e.g., traffic class, flow label, etc. o the IPv6 layer sees the aero interface as a point of connection to the aero link; if there are multiple aero links (i.e., multiple MS's), the IPv6 layer will see multiple aero interfaces. Templin & Whyman Expires December 30, 2019 [Page 5] Internet-Draft IPv6 over AERO Interfaces June 2019 Other opportunities are discussed in [RFC7847]. 5. Maximum Transmission Unit The aero interface and all underlying ANET interfaces MUST configure an MTU of at least 1280 bytes [RFC8200]. The aero interface SHOULD configure an MTU based on the largest MTU among all ANET interfaces. If the aero interface receives an RA message with an MTU option, it configures this new value regardless of any ANET interface MTUs. The aero interface returns internally-generated ICMPv6 "Packet Too Big" messages for packets that are no larger than the aero interface MTU but too large to traverse the selected underlying ANET interface. This ensures that the MTU is adaptive and reflects the ANET interface used for a given data flow. 6. Frame Format The aero interface transmits IPv6 packets according to the native frame format of each underlying ANET interface. For example, for an Ethernet interface the frame format is exactly as specified in [RFC2464], for tunnels over IPv6 the frame format is exactly as specified in [RFC2473], etc. 7. Link-Local Addresses A MN "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 Templin & Whyman Expires December 30, 2019 [Page 6] Internet-Draft IPv6 over AERO Interfaces June 2019 the base aero address is fe80::2001:db8:1000:2000). The MN uses the base aero address for IPv6 ND messaging, but accepts packets destined to all aero addresses equally (i.e., the same as for any multi- addressed IPv6 interface). MS aero addresses are allocated from the range fe80::/96, and MUST be managed for uniqueness by the collective aero link administrative authorities. Each address represents a distinct service endpoint in the MS. The lower 32 bits of the 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. Since MN aero addresses are guaranteed unique by the nature of the unique MNP delegation, aero interfaces set the autoconfiguration variable DupAddrDetectTransmits to 0 [RFC4862]. 8. Address Mapping - Unicast Each aero interface maintains a neighbor cache for tracking per- neighbor state the same as for any IPv6 interface. The aero interface uses standard IPv6 Neighbor Discovery (ND) messaging [RFC4861]. IPv6 ND messages on aero interfaces use the native Source/Target Link-Layer Address Option (S/TLLAO) formats of the underlying ANET interfaces (e.g., for Ethernet the S/TLLAO is specified in [RFC2464]). Aero interfaces also use the link-local address format specified in Section 7, and aero interface IPv6 ND messages include aero options formatted as shown in Figure 2: Templin & Whyman Expires December 30, 2019 [Page 7] Internet-Draft IPv6 over AERO Interfaces June 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 = 5 | Prefix Length |S|R|D| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifindex | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix (MNP) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 Option Format In this format: o Type is set to TBD (to be assigned by IANA). o Length is set to the constant value '5' (i.e., 5 units of 8 octets). o Prefix Length is set to the length of the prefix found in the Mobile Network Prefix (MNP) field. For RS messages, the MS validates the MNP assertion, then announces the MNP in the routing system and returns an RA with Router Lifetime set to the MNP assertion lifetime. o S (the 'Source' bit) is set to '1' in the aero options of an ND message that correspond to the ANET interface over which the ND message is sent, and set to '0' in all other aero options. o R (the "Release" bit) is set to '1' in the aero option of an RS message sent for the purpose of withdrawing from the MS; otherwise, set to '0'. The MS withdraws the MNP, then returns an RA with Router Lifetime set to '0'. Templin & Whyman Expires December 30, 2019 [Page 8] Internet-Draft IPv6 over AERO Interfaces June 2019 o D (the "Disable" bit) is set to '1' in the aero option of an RS message for each ifIndex that is to be disabled in the recipient's neighbor cache entry; otherwise, set to '0'. If the message contains multiple aero options the D value in each option is consulted. o Both 'Reserved' fields are set to the value '0' on transmission. o ifIndex is set to a 16-bit integer value corresponding to a specific underlying ANET interface as discussed in [RFC2863]. Once the MN has assigned an ifIndex to an ANET interface, the assignment MUST remain unchanged until the MN disables the interface. MNs MUST number each ifIndex with a value between '1' and '0xffff', and RA messages sent by the MS MUST set ifIndex to 0. o Mobile Network Prefix (MNP) is set to an IPv6 Prefix assigned to the MN. Prefix Length and MNP in an RS message MUST be values that the MN is authorized to assert. Otherwise, the MS ignores the RS message and does not enter the MNP into the routing/mapping system. 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 ANET 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 aero options - each with an ifIndex that corresponds to a specific ANET interface. When an ND message includes aero options, the options corresponding to the underlying ANET interface used to transmit the message MUST set S to '1'. 9. Address Mapping - Multicast The multicast address mapping of the native underlying ANET interface applies, and the ANET interacts with the MS for multicast forwarding and group management purposes. The mobile router on board the aircraft also serves as an IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] while Templin & Whyman Expires December 30, 2019 [Page 9] Internet-Draft IPv6 over AERO Interfaces June 2019 using the link layer address of the router as the link layer address for all multicast packets. 10. Conceptual Sending Algorithm The MN's IPv6 layer selects the outbound aero interface according to standard IPv6 requirements. The aero interface maintains a default route and a neighbor cache entry for MS endpoints, and may also include additional neighbor cache entries created through other means (e.g., Address Resolution (AR), static configuration, etc.). When the MN sends packets via a MS endpoint, it may receive a Redirect message the same as for any IPv6 interface. When the MN uses AR, the aero interface forwards NS messages to an MS endpoint (see: Section 11) which acts as a link-layer forwarding agent according to the NBMA link model. The resulting NA message will provide link-layer address information for the neighbor. When Neighbor Unreachability Detection (NUD) is used, the NS/NA exchange confirms reachability the same as for any IPv6 interface. After a packet enters the aero interface, an outbound ANET interface is selected based on traffic engineering information such as DSCP, application port number, cost, performance, etc. Aero interface traffic engineering could also be configured to perform replication across multiple ANET interfaces for increased reliability at the expense of packet duplication. When a target neighbor has multiple link-layer addresses (each with a different traffic engineering profile), the aero interface selects ANET interfaces and neighbor link-layer addresses according to both its own outbound preferences and the inbound preferences of the target neighbor. 10.1. Multiple Aero Interfaces MNs may associate with multiple MS instances concurrently. Each MS instance represents a distinct aero link distinguished by its associated MSPs. The MN configures a separate aero interface for each link so that multiple interfaces (e.g., aero0, aero1, aero2, etc.) are exposed to the IPv6 layer. Depending on local policy and configuration, an MN may choose between alternative active aero interfaces using a packet's DSCP, routing information or static configuration. In particular, the MN can add the MSPs received in Prefix Information Options (PIOs) [RFC4861] [RFC8028] as guidance for aero interface selection based on per- packet source addresses . Templin & Whyman Expires December 30, 2019 [Page 10] Internet-Draft IPv6 over AERO Interfaces June 2019 Each aero interface can be configured over the same or different sets of ANET interfaces. First hop ANET ARs distinguish between the different aero links based on the MSPs represented in per-packet IPv6 addresses. Multiple distinct aero links can therefore be used to support fault tolerance, load balancing, reliability, etc. The architectural model parallels Layer 2 Virtual Local Area Networks (VLANs), where the MSPs serve as (virtual) VLAN tags. 11. Router and Prefix Discovery MNs interact with the MS through mobility extensions on first-hop ANET Access Routers (ARs). MS extensions on ARs MUST examine the RS messages received on an ANET interface. If the RS message includes aero options, the MS is invoked and an appropriate RA message is generated the same as for an IPv6 router. If the RS message does not include aero options, the AR instead processes the RS message locally the same as for an ordinary IPv6 link. MNs 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 coordinate with the MS through RS/RA exchanges via their aero interfaces. When an aero interface transitions to UP, the MN sends initial RS messages with aero options to assert its MNP and register an initial set of underlying ANET interfaces that are also UP. The MN sends additional RS messages to refresh MNP and/or router lifetimes, and to register/deregister underlying ANET interfaces as they transition to UP or DOWN. The MS sends RA messages with configuration information in response to a MN's RS message. The RA includes a Router Lifetime value and PIOs with (A; L=0) that include MSPs for the link. The configuration information may also include Route Information Options (RIO) options [RFC4191] with more-specific routes, and an MTU option that specifies the maximum acceptable packet size for the link. The MS sends immediate unicast RA responses without delay; therefore, the 'MAX_RA_DELAY_TIME' and 'MIN_DELAY_BETWEEN_RAS' constants for multicast RAs do not apply. The MS MAY send periodic and/or event- Templin & Whyman Expires December 30, 2019 [Page 11] Internet-Draft IPv6 over AERO Interfaces June 2019 driven unsolicited RA messages, but is not required to do so for unicast advertisements [RFC4861]. The MN sends RS messages from within the aero interface while using an UP underlying ANET 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 aero option with a valid Prefix Length and MNP. The aero option also sets S to 1 and contains valid ifIndex and P(i) values appropriate for the underlying ANET interface. When the MS receives the RS, it accepts the message if the prefix assertion was acceptable; otherwise, it drops the message silently. If the prefix assertion was accepted, the MS injects the MNP into the routing/mapping system then caches the new ifIndex, Prefix Length, MNP and P(i) values. The MS then returns an RA with the aero address of an MS endpoint as the source address, the aero address of the MN as the destination address and with Router Lifetime set to a non-zero value. After the MN receives the initial RA confirming the MNP assertion, it notes the aero address in the RA as the destination for all subsequent RS messages it sends via this MS endpoint. If the MN needs to change to a different MS endpoint, it discovers and uses a different MS aero address. The MN then manages its underlying ANET interfaces according to their states as follows: o When an underlying ANET interface transitions to UP, the MN sends an RS over the ANET interface with its base aero address as the source address, the MS aero address as the destination address, and with one or more aero options. Aero options corresponding to the ANET interface set S to 1 and contain valid ifIndex and P(i) values appropriate for this ANET interface, while any additional aero options set S to 0 and contain valid ifIndex and P(i) values appropriate for other ANET interfaces. o When an underlying ANET interface transitions to DOWN, the MN sends an RS over any UP ANET interface with an aero option for the DOWN ANET interface with D set to 1. The RS may include additional aero options for additional ANET interfaces as above. Templin & Whyman Expires December 30, 2019 [Page 12] Internet-Draft IPv6 over AERO Interfaces June 2019 o When a MN wishes to release from the current MS endpoint, it sends an RS message over any UP ANET interface with an aero option with R set to 1. When the MS receives the RS message, it withdraws the MNP from the routing/mapping system and returns an RA message with Router Lifetime set to 0. o When all of a MNs underlying interfaces have transitioned to DOWN, the MS withdraws the MNP the same as if it had received an RS with an aero option with R set to 1. 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 over multiple UP ANET interfaces, the MN declares this MS endpoint unreachable and tries a different MS endpoint. The IPv6 layer sees the aero interface as an ordinary IPv6 interface. Therefore, when the IPv6 layer sends an RS message the aero interface returns an internally-generated RA message as though the message originated from an IPv6 router. The internally-generated RA message contains configuration information (such as Router Lifetime, MTU, etc.) that is consistent with the information received from the RAs generated by the MS. Whether the aero interface RS/RA process is initiated from the receipt of an RS message from the IPv6 layer is an implementation matter. Some implementations may elect to defer the RS/RA process until an RS is received from the IPv6 layer, while others may elect to initiate the RS/RA process independently of any IPv6 layer messaging. 12. IANA Considerations The IANA is instructed to allocate an IPv6 Neighbor Discovery option type for the aero option in the IPv6 Neighbor Discovery Option Formats registry. 13. Security Considerations Security considerations are the same as defined for the specific access network interface types, and readers are referred to the appropriate interface specifications. IPv6 and IPv6 ND security considerations also apply, and are specified in the normative references. Templin & Whyman Expires December 30, 2019 [Page 13] Internet-Draft IPv6 over AERO Interfaces June 2019 14. 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. . 15. References 15.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, . [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, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [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, . Templin & Whyman Expires December 30, 2019 [Page 14] Internet-Draft IPv6 over AERO Interfaces June 2019 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 15.2. Informative References [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, . [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, . [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, . [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, . Templin & Whyman Expires December 30, 2019 [Page 15] Internet-Draft IPv6 over AERO Interfaces June 2019 [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, . Appendix A. Aero Option Extensions for Special-Purpose Links The aero option 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 aero option 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 December 30, 2019 [Page 16] Internet-Draft IPv6 over AERO Interfaces June 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 = 5 | Prefix Length |S|R|D| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ifIndex | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix (MNP) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 Aero Option 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 MS aero addresses cannot overlap. Additionally, this specification currently 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 December 30, 2019 [Page 17] Internet-Draft IPv6 over AERO Interfaces June 2019 Appendix C. Change Log << RFC Editor - remove prior to publication >> Differences from draft-templin-atn-aero-interface-02 to draft- templin-atn-aero-interface-03: o Sections re-arranged to match RFC4861 structure. o Multiple aero interfaces o Conceptual sending algorithm Differences from draft-templin-atn-aero-interface-01 to draft- templin-atn-aero-interface-02: o Removed discussion of encapsulation (out of scope) o Simplified MTU section o Changed to use a new IPv6 ND option (the "aero option") instead of S/TLLAO o Explained the nature of the interaction between the mobility management service and the air interface 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 opportunities 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" section. o New Appendix B on Prefix Length considerations Templin & Whyman Expires December 30, 2019 [Page 18] Internet-Draft IPv6 over AERO Interfaces June 2019 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 Tony Whyman MWA Ltd c/o Inmarsat Global Ltd 99 City Road London EC1Y 1AX England Email: tony.whyman@mccallumwhyman.com Templin & Whyman Expires December 30, 2019 [Page 19]