idnits 2.17.1 draft-templin-atn-aero-interface-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2019) is 1847 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-troan-6man-universal-ra-option-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Standards Track A. Whyman 5 Expires: September 30, 2019 MWA Ltd c/o Inmarsat Global Ltd 6 March 29, 2019 8 Transmission of IPv6 Packets over AERO Interfaces 9 draft-templin-atn-aero-interface-00.txt 11 Abstract 13 Mobile nodes (e.g., aircraft of various configurations) act as mobile 14 routers for their on-board networks, and may have multiple data links 15 for communicating with networked correspondents. Mobile nodes 16 configure a virtual interface (termed the "AERO interface") as a thin 17 layer over their underlying data link interfaces. This document 18 specifies the transmission of IPv6 packets over AERO interfaces. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. AERO Interface Model . . . . . . . . . . . . . . . . . . . . 4 58 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 4 59 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 6 61 8. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 7 62 9. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 10 63 10. Router Discovery and MNP Assertion . . . . . . . . . . . . . 10 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 14.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Appendix A. S/TLLAO Extensions for Special-Purpose Links . . . . 13 71 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Mobile Nodes (MNs) such as aircraft of various configurations may 77 have multiple data links for communicating with networked 78 correspondents. These data links often have differing performance, 79 cost and availability characteristics that can change dynamically 80 according to mobility patterns, flight phases, proximity to 81 infrastructure, etc. 83 Each MN receives an IPv6 Mobile Network Prefix (MNP) that can be used 84 by on-board networks regardless of the actual link or links selected 85 for data transport. The MN acts as a mobile router on behalf of its 86 on-board networks, but appears as a multi-addressed host from the 87 perspective of off-board correspondents. This implies the need for a 88 virtual interface (termed the "AERO interface") configured as a thin 89 layer over the underlying data link interfaces. 91 The AERO interface is therefore the only interface abstraction 92 exposed to the IPv6 layer, and behaves according to the Non- 93 Broadcast, Multiple Access (NBMA) interface principle. This document 94 specifies the transmission of IPv6 packets [RFC8200] over AERO 95 interfaces. 97 2. Terminology 99 The terminology in the normative references applies; especially, the 100 terms "link" and "interface" are the same as defined in the IPv6 101 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 103 The following terms are defined within the scope of this document: 105 underlying Internetwork 106 a connected network region that has a coherent IP addressing plan 107 and is either physically isolated or separated from other networks 108 by packet filtering border routers. Examples include private 109 enterprise networks, aviation networks and the global public 110 Internet itself. 112 AERO link 113 a Non-Broadcast, Multiple Access (NBMA) virtual overlay configured 114 over an underlying Internetwork. Nodes on the AERO link appear as 115 single-hop neighbors from the perspective of the virtual overlay 116 even though they may be separated by many underlying Internetwork 117 hops. An AERO link may comprise multiple segments joined by 118 bridges the same as for any link; the underlying Internetwork 119 addressing plans in each segment may be mutually exclusive and 120 managed by different administrative entities. 122 AERO interface 123 a node's attachment to an AERO link, and configured over one or 124 more underlying interfaces 126 AERO node 127 a node with an AERO interface attached to an AERO link. 129 AERO address 130 an IPv6 link-local address constructed as specified in Section 7. 132 underlying link 133 a link that connects an AERO node to the underlying Internetwork. 135 underlying interface 136 an AERO node's interface point of attachment to an underlying 137 link. 139 3. Requirements 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. Lower case 144 uses of these words are not to be interpreted as carrying RFC2119 145 significance. 147 4. AERO Interface Model 149 An AERO interface is a MN's virtual interface configured over one or 150 more underlying links, which may be physical (e.g., an Ethernet) or 151 virtual (e.g., an Internet or higher-layer "tunnel"). The MN 152 discovers routers on the AERO link through Router Solicitation (RS) / 153 Router Advertisement (RA) message exchanges. 155 The AERO interface architectural layering model is the same as in 156 [RFC7847], and reproduced here (in an augmented form) as shown in 157 Figure 1. The AERO interface is therefore a single network-layer 158 interface with multiple link-layer addresses. 160 +----------------------------+ 161 | TCP/UDP | 162 Session-to-IP +---->| | 163 Address Binding | +----------------------------+ 164 +---->| IPv6 | 165 IP Address +---->| | 166 Binding | +----------------------------+ 167 +---->| AERO Interface | 168 Logical-to- +---->| (AERO Address) | 169 Physical | +----------------------------+ 170 Interface +---->| L2 | L2 | | L2 | 171 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 172 +------+------+ +------+ 173 | L1 | L1 | | L1 | 174 | | | | | 175 +------+------+ +------+ 177 Figure 1: AERO Interface Architectural Layering Model 179 5. Maximum Transmission Unit 181 The AERO interface Maximum Transmission Unit (MTU) is derived from 182 the underlying interface MTUs and set to a value that ensures that 183 the MTU for each underlying interface is respected. The AERO 184 interface MTU may be common to all data flows or differ between data 185 flows. Regardless of the strategy by which the MTU is determined, 186 the AERO link administrative authority should configure routers to 187 advertise a conservative MTU for all nodes noting that fragmentation 188 should be avoided if possible. 190 In common practice, there may be additional encapsulation headers 191 inserted by various forms of Layer 2 tunnels on the path to an on- 192 link neighbor. Such tunnels SHOULD be instrumented to accommodate 193 the native MTU of the underlying interface, but in some cases it may 194 be prudent to reduce the size of the underlying interface MTU to 195 allow room for L2 encapsulation. Especially for underlying links 196 with low-end performance characteristics, it is imperative that 197 packets that successfully traverse the underlying link are not 198 dropped in the network due to a size restriction. 200 In a preferred approach, the AERO interface MTU should be set to a 201 value no smaller than the largest MTU among all underlying 202 interfaces. The AERO interface itself then MUST return locally- 203 generated ICMPv6 "Packet Too Big" messages for packets that are too 204 large to traverse the selected underlying interface in one piece. 205 This ensures that the MTU is adaptive and reflects the underlying 206 interface used for a given data flow. 208 Alternatively, the AERO interface MTU may be determined as the 209 minimum MTU among all underlying interfaces. However, this may 210 result in under-utilization of robust underlying interfaces after a 211 low-end underlying interface has degraded the common minimum MTU. 212 For example, if the underlying interfaces have MTUs 1500, 1472 and 213 1400, then the minimum AERO interface MTU is 1400. 215 If any underlying interface has an MTU smaller than 1280, the AERO 216 interface MUST either perform IPv6 fragmentation when using this 217 interface or disable the underlying interface. 219 The MTU for an underlying interface is normally determined from 220 information provided either statically or dynamically when the 221 interface becomes active. If an underlying interface MTU dynamically 222 reports an MTU smaller than any minimum MTU already determined then 223 the AERO interface MUST either perform IPv6 fragmentation when using 224 this interface, or disable the underlying interface. 226 The AERO interface MAY also receive an RA with an MTU option. If the 227 advertised MTU is no larger than 1500, the AERO interface MTU is set 228 to the new value and the AERO interface MUST either perform IPv6 229 fragmentation over any underlying interface having a smaller MTU or 230 disable the underlying interface. 232 If the advertised MTU is larger than 1500, the AERO interface sets 233 the new value and disables any underlying interface having a smaller 234 MTU instead of fragmenting, since IPv6 destinations are not required 235 to reassemble more than 1500 bytes. 237 6. Frame Format 239 AERO interfaces transmit IPv6 packets according to the frame format 240 of the underlying interface. For example, for an Ethernet interface 241 the frame format is exactly as specified in [RFC2464], for an IPv6 242 tunnel over IPv4 the frame format is exactly as specified in 243 [RFC4213], etc. 245 7. Link-Local Addresses 247 A MN's AERO address is an IPv6 link-local address with an interface 248 identifier based on its assigned MNP. AERO addresses begin with the 249 prefix fe80::/64 followed by a 64-bit prefix taken from the MNP. For 250 example, for the MNP: 252 2001:db8:1000:2000::/56 254 the corresponding AERO addresses are: 256 fe80::2001:db8:1000:2000 258 fe80::2001:db8:1000:2001 260 fe80::2001:db8:1000:2002 262 ... etc. ... 264 fe80::2001:db8:1000:20ff 266 When the MN configures AERO addresses from its MNP, the lowest- 267 numbered AERO address serves as the "base" address (for example, for 268 the MNP 2001:db8:1000:2000::/56 the base AERO address is 269 fe80::2001:db8:1000:2000). MNs and routers use the base address for 270 the purpose of maintaining neighbor cache entries, but the MN accepts 271 packets destined to all AERO addresses as equivalent. 273 A router's AERO address is allocated from the range fe80::/96, and 274 MUST be managed for uniqueness by the AERO link administrative 275 authority. The lower 32 bits of the AERO address includes a unique 276 integer value, e.g., fe80::1, fe80::2, fe80::3, etc. The address 277 fe80:: is reserved as the IPv6 link-local Subnet Router Anycast 278 address [RFC4291], and the address fe80::ffff:ffff is reserved as the 279 unspecified AERO address; hence, these values are not available for 280 general assignment. 282 For multi-segment AERO links, the routers of each segment MUST assign 283 AERO addresses that are unique among all routers on the (collective) 284 link. Although the address assignment policy is completely at the 285 discretion of the AERO link administrative authority, a useful 286 technique may be to assign a different aggregated portion of the 287 fe80::/96 prefix to each segment, e.g., fe80::/120, fe80::0100/120, 288 fe80::0200/120, etc. 290 8. Address Mapping - Unicast 292 AERO interfaces maintain a neighbor cache for tracking per-neighbor 293 state the same as for any interface. AERO interfaces use standard 294 IPv6 Neighbor Discovery (ND) messages including Router Solicitation 295 (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor 296 Advertisement (NA) and Redirect. AERO interface ND messages may 297 include zero or more Source/Target Link-Layer Address Options (S/ 298 TLLAOs) formatted as shown in Figure 2: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Length = 5 | Prefix Length |R|D|X|T| Resvd | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Interface ID | Port Number | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 + + 309 | | 310 + Link-Layer Address + 311 | | 312 + + 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 325 Format 327 In this format: 329 o Type is set to '1' for SLLAO or '2' for TLLAO. 331 o Length is set to the constant value '5' (i.e., 5 units of 8 332 octets). 334 o Prefix Length is set to the MNP prefix length for the AERO address 335 found in the source (RS), destination (RA) or target (NA) address 336 of an ND message used for the purpose of asserting an MNP; 337 otherwise set to 0. If the message contains multiple SLLAOs, only 338 the Prefix Length value in the first SLLAO is consulted and the 339 values in other SLLAOs are ignored. For RS messages, the router 340 creates a neighbor cache entry and announces the MNP in the 341 routing system, then returns an RA with Router Lifetime set to the 342 MNP assertion lifetime. 344 o R (the "Release" bit) is set to '1' in the SLLAO of an RS message 345 sent for the purpose of withdrawing an MNP; otherwise, set to '0'. 346 If the message contains multiple SLLAOs, only the R value in the 347 first SLLAO is consulted and the values in other SLLAOs are 348 ignored. The router withdraws the MNP, then returns an RA with 349 Router Lifetime set to '0'. 351 o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA 352 message for each Interface ID that is to be disabled in the 353 recipient's neighbor cache entry; otherwise, set to '0'. If the 354 message contains an S/TLLAO with D=1 and Interface ID 255, the 355 node disables the entire neighbor cache entry. If the message 356 contains multiple S/TLLAOs the D value in each S/TLLAO is 357 consulted. 359 o X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA message 360 when there is a proxy in the path; otherwise, set to '0'. If the 361 message contains multiple SLLAOs, only the X value in the first 362 SLLAO is consulted and the values in other SLLAOs are ignored. 364 o T (the "Translator" bit) is set to '1' in the SLLAO of an RA 365 message if there is a link-layer address translator in the path; 366 otherwise, set to '0'. If the message contains multiple SLLAOs, 367 only the T value in the first SLLAO is consulted and the values in 368 other SLLAOs are ignored. 370 o Resvd is set to the value '0' on transmission and ignored on 371 receipt. 373 o Interface ID is set to a 16-bit integer value corresponding to a 374 specific underlying interface. Once the MN has assigned an 375 Interface ID to an underlying interface, the assignment MUST 376 remain unchanged until the MN disables the AERO interface. The 377 value '255' is reserved as the router Interface ID, i.e., routers 378 MUST use Interface ID '255', and MNs MUST number their Interface 379 IDs with values in the range of 0-254. 381 o Port Number and Link-Layer Address are set to the addresses 382 assigned to the underlying interface, or to '0' when the addresses 383 are left unspecified. For transmission over physical interfaces 384 such as Ethernet, the Link-Layer Address is set to the same format 385 as in the appropriate interface specification (e.g., IPv6 over 386 Ethernet [RFC2464]) beginning with the lowest-numbered byte of the 387 field and ending in trailing null padding to a total of 16 bytes. 388 For transmission over tunnel interfaces, the Link-Layer address is 389 set to an IPv6 address for IPv6 encapsulation or an IPv4-mapped 390 IPv6 address for IPv4 encapsulation. When TCP or UDP are used as 391 part of the encapsulation, Port Number is set to the encapsulation 392 protocol port number; otherwise, set to '0'. 394 o P(i) is a set of Preferences that correspond to the 64 395 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 396 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 397 ("medium") or '3' ("high") to indicate a QoS preference level for 398 underlying interface selection purposes. 400 MNs such as aircraft typically have many wireless data link types 401 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 402 etc.) with diverse performance, cost and availability properties. 403 From the perspective of ND, the AERO interface would therefore appear 404 to have multiple link-layer addresses. In that case, ND messages MAY 405 include multiple S/TLLAOs -- each with an Interface ID that 406 corresponds to a specific underlying interface. 408 When the MN includes S/TLLAOs solely for the purpose of announcing 409 new QoS preferences, it sets both Port Number and Link-Layer Address 410 to 0 to indicate that the addresses are not to be updated in the 411 router's neighbor cache. 413 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 414 correspond to the underlying interface used to transmit the message. 416 Note that this S/TLLAO format includes network-layer information 417 (e.g., Prefix Length) in a link-layer option. This is due to the 418 fact that it is difficult to standardize new IPv6 ND options in a 419 timely fashion. An experimental proposal defines a "Universal RA 420 Option" intended for carrying generic network-layer information in 421 RS/RA messages [I-D.troan-6man-universal-ra-option]. However, there 422 is no way at this time to predict how long the experiment would take 423 nor whether it will be successful. 425 9. Address Mapping - Multicast 427 When the underlying network does not support multicast, aircraft map 428 link-scoped multicast addresses to the link-layer address of a 429 router, which acts as a multicast forwarding agent. The mobile 430 router on board the aircraft also serves as an IGMP/MLD Proxy for its 431 EUNs and/or hosted applications per [RFC4605] while using the link- 432 layer address of the router as the link-layer address for all 433 multicast packets. 435 When the underlying network supports multicast, AERO interfaces use 436 the multicast address mapping specification found in [RFC2529] for 437 IPv4 underlying networks and use a TBD site-scoped multicast mapping 438 for IPv6 underlying networks. In that case, border routers must 439 ensure that the encapsulated site-scoped multicast packets do not 440 leak outside of the AERO link. 442 10. Router Discovery and MNP Assertion 444 MNs and routers coordinate their MNP assertions and per-link 445 parameters through RS/RA exchanges, and use ND messages to maintain 446 neighbor cache entries. Routers configure their AERO interfaces as 447 advertising interfaces, and therefore send unicast RA messages with 448 configuration information in response to a MN's RS message. 449 Thereafter, the MN sends additional RS messages to the router's 450 unicast address to refresh MNP and/or router lifetimes. 452 To assert an MNP, the MN sends an RS message over any underlying 453 interface with its base AERO address as the source address, all- 454 routers multicast as the destination address and with an SLLAO with a 455 valid Prefix Length for the MNP. The SLLAO also contains valid 456 Interface ID and P(i) values appropriate for the underlying 457 interface. When the router receives the RS message it injects the 458 MNP into the routing system if the prefix assertion was acceptable, 459 then registers the new Interface ID, Port Number, Link-Layer Address 460 and P(i) values in a neighbor cache entry. The router then returns 461 an RA with its AERO address as the source address, the AERO address 462 of the MN as the destination address and with Router Lifetime set to 463 a non-zero value if the MNP assertion was accepted; otherwise set to 464 zero. The message also includes an SLLAO with Prefix Length set to 465 the length of the MNP assertion. 467 After the MN receives the RA confirming the MNP assertion, it 468 registers each additional underlying interface with the router by 469 sending an RS over the underlying interface with its base AERO 470 address as the source address, the router's AERO address as the 471 destination address, and with an SLLAO with Prefix Length set to 0. 472 The SLLAO also contains valid Interface ID and P(i) values 473 appropriate for the underlying interface. When the router receives 474 the RS message it registers the new Interface ID, Port Number, Link- 475 Layer Address and P(i) values in the neighbor cache already 476 established during MNP assertion. The router then returns an RA 477 message with its AERO address as the source address, the AERO address 478 of the MN as the destination address and with Router Lifetime set to 479 a non-zero value. The message also includes an SLLAO with Prefix 480 Length set to 0. 482 The MN is responsible for retrying each RS/RA exchange up to 483 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 484 seconds until an RA is received. If no RA is received, the MN 485 declares the underlying interface unreachable, but MAY try again 486 later (e.g., if underlying link conditions become more favorable). 488 MNs that do not need to assert MNP, Port Number, Link-Layer Address, 489 Interface ID or P(i) values MAY omit SLLAOs in RS messages. 490 Responding routers MAY also omit SLLAOs in the corresponding RAs. 492 11. IANA Considerations 494 No IANA actions are required. 496 12. Security Considerations 498 Security considerations are the same as defined for the underlying 499 interface types, and readers are referred to the appropriate 500 underlying interface specifications. 502 IPv6 and IPv6 ND security considerations also apply, and are 503 specified in the normative references. 505 13. Acknowledgements 507 This document was prepared per the consensus decision at the 8th 508 Conference of the International Civil Aviation Organization (ICAO) 509 Working Group-I Mobility Subgroup on March 22, 2019. Attendees and 510 contributors included: Guray Acar, Danny Bharj, Francois D'Humieres, 511 Pavel Drasil, Nikos Fistas, Giovanni Garofolo, Vaughn Maiolla, Tom 512 McParland, Victor Moreno, Madhu Niraula, Brent Phillips, Liviu 513 Popescu, Jacky Pouzet, Aloke Roy, Greg Saccone, Robert Segers, 514 Stephane Tamalet, Fred Templin, Bela Varkonyi, Tony Whyman, and 515 Dongsong Zeng. 517 . 519 14. References 521 14.1. Normative References 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 529 "Definition of the Differentiated Services Field (DS 530 Field) in the IPv4 and IPv6 Headers", RFC 2474, 531 DOI 10.17487/RFC2474, December 1998, 532 . 534 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 535 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 536 2006, . 538 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 539 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 540 DOI 10.17487/RFC4861, September 2007, 541 . 543 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 544 (IPv6) Specification", STD 86, RFC 8200, 545 DOI 10.17487/RFC8200, July 2017, 546 . 548 14.2. Informative References 550 [I-D.troan-6man-universal-ra-option] 551 Troan, O., "The Universal IPv6 Router Advertisement Option 552 (experiment)", draft-troan-6man-universal-ra-option-01 553 (work in progress), December 2018. 555 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 556 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 557 . 559 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 560 Domains without Explicit Tunnels", RFC 2529, 561 DOI 10.17487/RFC2529, March 1999, 562 . 564 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 565 for IPv6 Hosts and Routers", RFC 4213, 566 DOI 10.17487/RFC4213, October 2005, 567 . 569 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 570 "Internet Group Management Protocol (IGMP) / Multicast 571 Listener Discovery (MLD)-Based Multicast Forwarding 572 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 573 August 2006, . 575 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 576 Support for IP Hosts with Multi-Access Support", RFC 7847, 577 DOI 10.17487/RFC7847, May 2016, 578 . 580 Appendix A. S/TLLAO Extensions for Special-Purpose Links 582 The S/TLLAO format specified in Section 8 includes a Length value of 583 5 (i.e., 5 units of 8 octets). However, special-purpose AERO links 584 may extend the basic format to include additional fields and a Length 585 value larger than 5. 587 For example, adaptation of AERO to the Aeronautical 588 Telecommunications Network with Internet Protocol Services (ATN/IPS) 589 includes link selection preferences based on transport port numbers 590 in addition to the existing DSCP-based preferences. ATN/IPS nodes 591 maintain a map of transport port numbers to 64 possible preference 592 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 593 maps to preference field 20, UDP port 8060 maps to preference field 594 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 595 Figure 3, where the Length value is 7 and the 'Q(i)' fields provide 596 link preferences for the corresponding transport port number. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type | Length = 7 | Prefix Length |R|D|X|T| Resvd | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Interface ID | Port Number | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 + + 607 | | 608 + Link-Layer Address + 609 | | 610 + + 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 3: ATN/IPS Extended S/TLLAO Format 632 Appendix B. Change Log 634 << RFC Editor - remove prior to publication >> 636 First draft version (draft-templin-atn-aero-interface-00): 638 o Draft based on consensus decision of ICAO Working Group I Mobility 639 Subgroup March 22, 2019. 641 Authors' Addresses 642 Fred L. Templin (editor) 643 Boeing Research & Technology 644 P.O. Box 3707 645 Seattle, WA 98124 646 USA 648 Email: fltemplin@acm.org 650 Tony Whyman 651 MWA Ltd c/o Inmarsat Global Ltd 652 99 City Road 653 London EC1Y 1AX 654 England 656 Email: tony.whyman@mccallumwhyman.com