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, . 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, . [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, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 14.2. Informative References [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, DOI 10.17487/RFC2529, March 1999, . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [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, . 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, . [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. 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]