idnits 2.17.1 draft-templin-6man-omni-interface-21.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 (May 3, 2020) is 1448 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) -- Looks like a reference, but probably isn't: '00' on line 837 -- Looks like a reference, but probably isn't: '03' on line 831 -- Looks like a reference, but probably isn't: '04' on line 832 -- Looks like a reference, but probably isn't: '07' on line 832 -- Looks like a reference, but probably isn't: '28' on line 833 -- Looks like a reference, but probably isn't: '31' on line 833 -- Looks like a reference, but probably isn't: '63' on line 837 -- Looks like a reference, but probably isn't: '64' on line 839 -- Looks like a reference, but probably isn't: '65' on line 839 -- Looks like a reference, but probably isn't: '66' on line 839 == Missing Reference: 'RFCXXXX' is mentioned on line 1333, but not defined -- Looks like a reference, but probably isn't: '67' on line 1624 -- Looks like a reference, but probably isn't: '70' on line 1625 -- Looks like a reference, but probably isn't: '76' on line 1625 == Unused Reference: 'RFC2225' is defined on line 1481, but no explicit reference was found in the text == Unused Reference: 'RFC7421' is defined on line 1579, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-09 == Outdated reference: A later version (-99) exists of draft-templin-intarea-6706bis-48 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft The Boeing Company 4 Intended status: Standards Track A. Whyman 5 Expires: November 4, 2020 MWA Ltd c/o Inmarsat Global Ltd 6 May 3, 2020 8 Transmission of IPv6 Packets over Overlay Multilink Network (OMNI) 9 Interfaces 10 draft-templin-6man-omni-interface-21 12 Abstract 14 Mobile nodes (e.g., aircraft of various configurations, terrestrial 15 vehicles, seagoing vessels, enterprise wireless devices, etc.) 16 communicate with networked correspondents over multiple access 17 network data links and configure mobile routers to connect end user 18 networks. A multilink interface specification is therefore needed 19 for coordination with the network-based mobility service. This 20 document specifies the transmission of IPv6 packets over Overlay 21 Multilink Network (OMNI) Interfaces. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 4, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Overlay Multilink Network (OMNI) Interface Model . . . . . . 7 61 5. Maximum Transmission Unit (MTU) and Fragmentation . . . . . . 10 62 6. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 11 63 7. Link-Local Addresses . . . . . . . . . . . . . . . . . . . . 12 64 8. The SPAN . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 9. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 13 66 9.1. Sub-Options . . . . . . . . . . . . . . . . . . . . . . . 15 67 9.1.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 16 68 9.1.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9.1.3. ifIndex-tuple (Type 1) . . . . . . . . . . . . . . . 16 70 9.1.4. ifIndex-tuple (Type 2) . . . . . . . . . . . . . . . 19 71 9.1.5. MS-Register . . . . . . . . . . . . . . . . . . . . . 19 72 9.1.6. MS-Release . . . . . . . . . . . . . . . . . . . . . 20 73 9.1.7. Network Access Identifier (NAI) . . . . . . . . . . . 20 74 9.1.8. Geo Coordiantes . . . . . . . . . . . . . . . . . . . 20 75 10. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 21 76 11. Conceptual Sending Algorithm . . . . . . . . . . . . . . . . 21 77 11.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 22 78 12. Router Discovery and Prefix Registration . . . . . . . . . . 22 79 13. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 25 80 14. AR and MSE Resilience . . . . . . . . . . . . . . . . . . . . 26 81 15. Detecting and Responding to MSE Failures . . . . . . . . . . 26 82 16. Transition Considerations . . . . . . . . . . . . . . . . . . 27 83 17. OMNI Interfaces on the Open Internet . . . . . . . . . . . . 27 84 18. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 28 85 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 86 20. Security Considerations . . . . . . . . . . . . . . . . . . . 29 87 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 88 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 22.1. Normative References . . . . . . . . . . . . . . . . . . 30 90 22.2. Informative References . . . . . . . . . . . . . . . . . 32 91 Appendix A. Type 1 ifIndex-tuple Traffic Classifier Preference 92 Encoding . . . . . . . . . . . . . . . . . . . . . . 35 93 Appendix B. VDL Mode 2 Considerations . . . . . . . . . . . . . 37 94 Appendix C. MN / AR Isolation Through L2 Address Mapping . . . . 38 95 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 38 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 98 1. Introduction 100 Mobile Nodes (MNs) (e.g., aircraft of various configurations, 101 terrestrial vehicles, seagoing vessels, enterprise wireless devices, 102 etc.) often have multiple data links for communicating with networked 103 correspondents. These data links may have diverse performance, cost 104 and availability properties that can change dynamically according to 105 mobility patterns, flight phases, proximity to infrastructure, etc. 106 MNs coordinate their data links in a discipline known as "multilink", 107 in which a single virtual interface is configured over the underlying 108 data links. 110 The MN configures a virtual interface (termed the "Overlay Multilink 111 Network (OMNI) interface") as a thin layer over the underlying Access 112 Network (ANET) interfaces. The OMNI interface is therefore the only 113 interface abstraction exposed to the IPv6 layer and behaves according 114 to the Non-Broadcast, Multiple Access (NBMA) interface principle, 115 while underlying interfaces appear as link layer communication 116 channels in the architecture. The OMNI interface connects to a 117 virtual overlay service known as the "OMNI link". The OMNI link 118 spans a worldwide Internetwork that may include private-use 119 infrastructures and/or the global public Internet itself. 121 Each MN receives a Mobile Network Prefix (MNP) for numbering 122 downstream-attached End User Networks (EUNs) independently of the 123 access network data links selected for data transport. The MN 124 performs router discovery over the OMNI interface (i.e., similar to 125 IPv6 customer edge routers [RFC7084]) and acts as a mobile router on 126 behalf of its EUNs. The router discovery process is iterated over 127 each of the OMNI interface's underlying interfaces in order to 128 register per-link parameters (see Section 12). 130 The OMNI interface provides a multilink nexus for exchanging inbound 131 and outbound traffic via the correct underlying interface(s). The 132 IPv6 layer sees the OMNI interface as a point of connection to the 133 OMNI link. Each OMNI link has one or more associated Mobility 134 Service Prefixes (MSPs) from which OMNI link MNPs are derived. If 135 there are multiple OMNI links, the IPv6 layer will see multiple OMNI 136 interfaces. 138 MNs may connect to multiple distinct OMNI links by configuring 139 multiple OMNI interfaces, e.g., omni0, omni1, omni2, etc. Each OMNI 140 interface is configured over a set of underlying interfaces and 141 provides a nexus for Safety-Based Multilink (SBM) operation. The IP 142 layer selects an OMNI interface based on SBM routing considerations, 143 then the selected interface applies Performance-Based Multilink (PBM) 144 to select the correct underlying interface. Applications can apply 145 segment routing to select independent SBM topologies for fault 146 tolerance. 148 The OMNI interface interacts with a network-based Mobility Service 149 (MS) through IPv6 Neighbor Discovery (ND) control message exchanges 150 [RFC4861]. The MS provides Mobility Service Endpoints (MSEs) that 151 track MN movements and represent their MNPs in a global routing or 152 mapping system. 154 This document specifies the transmission of IPv6 packets [RFC8200] 155 and MN/MS control messaging over OMNI interfaces. 157 2. Terminology 159 The terminology in the normative references applies; especially, the 160 terms "link" and "interface" are the same as defined in the IPv6 161 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 162 Also, the Protocol Constants defined in Section 10 of [RFC4861] are 163 used in their same format and meaning in this document. The terms 164 "All-Routers multicast", "All-Nodes multicast" and "Subnet-Router 165 anycast" are the same as defined in [RFC4291] (with Link-Local scope 166 assumed). 168 The following terms are defined within the scope of this document: 170 Mobile Node (MN) 171 an end system with a mobile router having multiple distinct 172 upstream data link connections that are grouped together in one or 173 more logical units. The MN's data link connection parameters can 174 change over time due to, e.g., node mobility, link quality, etc. 175 The MN further connects a downstream-attached End User Network 176 (EUN). The term MN used here is distinct from uses in other 177 documents, and does not imply a particular mobility protocol. 179 End User Network (EUN) 180 a simple or complex downstream-attached mobile network that 181 travels with the MN as a single logical unit. The IPv6 addresses 182 assigned to EUN devices remain stable even if the MN's upstream 183 data link connections change. 185 Mobility Service (MS) 186 a mobile routing service that tracks MN movements and ensures that 187 MNs remain continuously reachable even across mobility events. 188 Specific MS details are out of scope for this document. 190 Mobility Service Endpoint (MSE) 191 an entity in the MS (either singular or aggregate) that 192 coordinates the mobility events of one or more MN. 194 Mobility Service Prefix (MSP) 195 an aggregated IPv6 prefix (e.g., 2001:db8::/32) advertised to the 196 rest of the Internetwork by the MS, and from which more-specific 197 Mobile Network Prefixes (MNPs) are derived. 199 Mobile Network Prefix (MNP) 200 a longer IPv6 prefix taken from an MSP (e.g., 201 2001:db8:1000:2000::/56) and assigned to a MN. MNs sub-delegate 202 the MNP to devices located in EUNs. 204 Access Network (ANET) 205 a data link service network (e.g., an aviation radio access 206 network, satellite service provider network, cellular operator 207 network, wifi network, etc.) that connects MNs. Physical and/or 208 data link level security between the MN and ANET are assumed. 210 Access Router (AR) 211 a first-hop router in the ANET for connecting MNs to 212 correspondents in outside Internetworks. 214 ANET interface 215 a MN's attachment to a link in an ANET. 217 Internetwork (INET) 218 a connected network region with a coherent IP addressing plan that 219 provides transit forwarding services for ANET MNs and INET 220 correspondents. Examples include private enterprise networks, 221 ground domain aviation service networks and the global public 222 Internet itself. 224 INET interface 225 a node's attachment to a link in an INET. 227 OMNI link 228 a virtual overlay configured over one or more INETs and their 229 connected ANETs. An OMNI link can comprise multiple INET segments 230 joined by bridges the same as for any link; the addressing plans 231 in each segment may be mutually exclusive and managed by different 232 administrative entities. 234 OMNI interface 235 a node's attachment to an OMNI link, and configured over one or 236 more underlying ANET/INET interfaces. 238 OMNI link local address (LLA) 239 an IPv6 link-local address constructed as specified in Section 7, 240 and assigned to an OMNI interface. 242 OMNI Option 243 an IPv6 Neighbor Discovery option providing multilink parameters 244 for the OMNI interface as specified in Section 9. 246 Multilink 247 an OMNI interface's manner of managing diverse underlying data 248 link interfaces as a single logical unit. The OMNI interface 249 provides a single unified interface to upper layers, while 250 underlying data link selections are performed on a per-packet 251 basis considering factors such as DSCP, flow label, application 252 policy, signal quality, cost, etc. Multilinking decisions are 253 coordinated in both the outbound (i.e. MN to correspondent) and 254 inbound (i.e., correspondent to MN) directions. 256 L2 257 The second layer in the OSI network model. Also known as "layer- 258 2", "link-layer", "sub-IP layer", "data link layer", etc. 260 L3 261 The third layer in the OSI network model. Also known as "layer- 262 3", "network-layer", "IPv6 layer", etc. 264 underlying interface 265 an ANET/INET interface over which an OMNI interface is configured. 266 The OMNI interface is seen as a L3 interface by the IP layer, and 267 each underlying interface is seen as a L2 interface by the OMNI 268 interface. 270 Mobility Service Identification (MSID) 271 Each MSE and AR is assigned a unique 32-bit Identification (MSID) 272 as specified in Section 7. 274 Spanning Partitioned Administrative Networks (SPAN) 275 A means for bridging disjoint INET partitions as segments of a 276 unified OMNI link the same as for a bridged campus LAN. The SPAN 277 is a mid-layer IPv6 encapsulation service that supports a unified 278 OMNI link view for all segments. 280 Safety-Based Multilink (SBM) 281 A means for ensuring fault tolerance through redundancy by 282 connecting multiple independent OMNI interfaces to independent 283 routing topologies (i.e., multiple independent OMNI links). 285 Performance Based Multilink (PBM) 286 A means for selecting underlying interface(s) for packet 287 trasnmission and reception within a single OMNI interface. 289 3. Requirements 291 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 292 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 293 "OPTIONAL" in this document are to be interpreted as described in BCP 294 14 [RFC2119][RFC8174] when, and only when, they appear in all 295 capitals, as shown here. 297 An implementation is not required to internally use the architectural 298 constructs described here so long as its external behavior is 299 consistent with that described in this document. 301 4. Overlay Multilink Network (OMNI) Interface Model 303 An OMNI interface is a MN virtual interface configured over one or 304 more underlying interfaces, which may be physical (e.g., an 305 aeronautical radio link) or virtual (e.g., an Internet or higher- 306 layer "tunnel"). The MN receives a MNP from the MS, and coordinates 307 with the MS through IPv6 ND message exchanges. The MN uses the MNP 308 to construct a unique OMNI LLA through the algorithmic derivation 309 specified in Section 7 and assigns the LLA to the OMNI interface. 311 The OMNI interface architectural layering model is the same as in 312 [RFC5558][RFC7847], and augmented as shown in Figure 1. The IP layer 313 therefore sees the OMNI interface as a single L3 interface with 314 multiple underlying interfaces that appear as L2 communication 315 channels in the architecture. 317 +----------------------------+ 318 | Upper Layer Protocol | 319 Session-to-IP +---->| | 320 Address Binding | +----------------------------+ 321 +---->| IP (L3) | 322 IP Address +---->| | 323 Binding | +----------------------------+ 324 +---->| OMNI Interface | 325 Logical-to- +---->| (OMNI LLA) | 326 Physical | +----------------------------+ 327 Interface +---->| L2 | L2 | | L2 | 328 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 329 +------+------+ +------+ 330 | L1 | L1 | | L1 | 331 | | | | | 332 +------+------+ +------+ 334 Figure 1: OMNI Interface Architectural Layering Model 336 The OMNI virtual interface model gives rise to a number of 337 opportunities: 339 o since OMNI LLAs are uniquely derived from an MNP, no Duplicate 340 Address Detection (DAD) or Muticast Listener Discovery (MLD) 341 messaging is necessary. 343 o ANET interfaces do not require any L3 addresses (i.e., not even 344 link-local) in environments where communications are coordinated 345 entirely over the OMNI interface. (An alternative would be to 346 also assign the same OMNI LLA to all ANET interfaces.) 348 o as ANET interface properties change (e.g., link quality, cost, 349 availability, etc.), any active ANET interface can be used to 350 update the profiles of multiple additional ANET interfaces in a 351 single message. This allows for timely adaptation and service 352 continuity under dynamically changing conditions. 354 o coordinating ANET interfaces in this way allows them to be 355 represented in a unified MS profile with provisions for mobility 356 and multilink operations. 358 o exposing a single virtual interface abstraction to the IPv6 layer 359 allows for multilink operation (including QoS based link 360 selection, packet replication, load balancing, etc.) at L2 while 361 still permitting L3 traffic shaping based on, e.g., DSCP, flow 362 label, etc. 364 o L3 sees the OMNI interface as a point of connection to the OMNI 365 link; if there are multiple OMNI links (i.e., multiple MS's), L3 366 will see multiple OMNI interfaces. 368 o Multiple independent OMNI interfaces can be used for increased 369 fault tolerance through Safety-Based Multilink (SBM), with 370 Performance-Based Multilink (PBM) applied within each interface. 372 Other opportunities are discussed in [RFC7847]. 374 Figure 2 depicts the architectural model for a MN connecting to the 375 MS via multiple independent ANETs. When an underlying interface 376 becomes active, the MN's OMNI interface sends native (i.e., 377 unencapsulated) IPv6 ND messages via the underlying interface. IPv6 378 ND messages traverse the ground domain ANETs until they reach an 379 Access Router (AR#1, AR#2, .., AR#n). The AR then coordinates with a 380 Mobility Service Endpoint (MSE#1, MSE#2, ..., MSE#m) in the INET and 381 returns an IPv6 ND message response to the MN. IPv6 ND messages 382 traverse the ANET at layer 2; hence, the Hop Limit is not 383 decremented. 385 +--------------+ 386 | MN | 387 +--------------+ 388 |OMNI interface| 389 +----+----+----+ 390 +--------|IF#1|IF#2|IF#n|------ + 391 / +----+----+----+ \ 392 / | \ 393 / <---- Native | IP ----> \ 394 v v v 395 (:::)-. (:::)-. (:::)-. 396 .-(::ANET:::) .-(::ANET:::) .-(::ANET:::) 397 `-(::::)-' `-(::::)-' `-(::::)-' 398 +----+ +----+ +----+ 399 ... |AR#1| .......... |AR#2| ......... |AR#n| ... 400 . +-|--+ +-|--+ +-|--+ . 401 . | | | 402 . v v v . 403 . <----- Encapsulation -----> . 404 . . 405 . +-----+ (:::)-. . 406 . |MSE#2| .-(::::::::) +-----+ . 407 . +-----+ .-(::: INET :::)-. |MSE#m| . 408 . (::::: Routing ::::) +-----+ . 409 . `-(::: System :::)-' . 410 . +-----+ `-(:::::::-' . 411 . |MSE#1| +-----+ +-----+ . 412 . +-----+ |MSE#3| |MSE#4| . 413 . +-----+ +-----+ . 414 . . 415 . . 416 . <----- Worldwide Connected Internetwork ----> . 417 ........................................................... 419 Figure 2: MN/MS Coordination via Multiple ANETs 421 After the initial IPv6 ND message exchange, the MN can send and 422 receive unencapsulated IPv6 data packets over the OMNI interface. 423 OMNI interface multilink services will forward the packets via ARs in 424 the correct underlying ANETs. The AR encapsulates the packets 425 according to the capabilities provided by the MS and forwards them to 426 the next hop within the worldwide connected Internetwork via optimal 427 routes. 429 OMNI links span the underlying Internetwork via a mid-layer overlay 430 known as "The SPAN" - see Section 8. Each OMNI link corresponds to a 431 different SPAN overlay (differentiated by a SPAN header codepoint) 432 which may be carried over a completely separate Internetwork 433 topology. Each MN can facilitate SBM by connecting to multiple OMNI 434 links (i.e., multiple SPANs) using a distinct OMNI interface for each 435 link. 437 5. Maximum Transmission Unit (MTU) and Fragmentation 439 All IPv6 interfaces are REQUIRED to configure a minimum Maximum 440 Transmission Unit (MTU) of 1280 bytes [RFC8200]. The network 441 therefore MUST forward packets of at least 1280 bytes without 442 generating an IPv6 Path MTU Discovery (PMTUD) Packet Too Big (PTB) 443 message [RFC8201]. 445 The OMNI interface configures an MTU of 9180 bytes [RFC2492]; the 446 size is therefore not a reflection of the underlying interface MTUs, 447 but rather determines the largest packet the OMNI interface can 448 forward or reassemble. The OMNI interface therefore accommodates IP 449 packets up to 9180 bytes while generating IPv6 Path MTU Discovery 450 (PMTUD) Packet Too Big (PTB) messages [RFC8201] as necessary (see 451 below). 453 OMNI interfaces employ mid-layer IPv6 encapsulation and 454 fragmentation/reassembly per [RFC2473] (also known as "SPAN 455 encapsulation" - see Section 8) to accommodate the 9180 byte MTU. 456 The OMNI interface returns internally-generated PTB messages for 457 packets admitted into the interface that it deems too large (e.g., 458 according to link performance characteristics, reassembly cost, etc.) 459 while either dropping or forwarding the packet as necessary. The 460 OMNI interface performs PMTUD even if the destination appears to be 461 on the same link since an OMNI link node on the path may return a 462 PTB. This ensures that the path MTU is adaptive and reflects the 463 current path used for a given data flow. 465 OMNI interfaces perform SPAN encapsulation and fragmentation/ 466 reassembly as follows: 468 o When an OMNI interface sends a packet toward a final destination 469 via an ANET peer, it sends without SPAN encapsulation if the 470 packet is no larger than the underlying interface MTU. Otherwise, 471 it inserts a SPAN header with source address set to the node's own 472 SPAN address and destination set to the SPAN address of the ANET 473 peer. The OMNI interface then uses IPv6 fragmentation to break 474 the packet into a minimum number of non-overlapping fragments, 475 where the largest fragment size is determined by the underlying 476 interface MTU and the smallest fragment is no smaller than 640 477 bytes. The OMNI interface then sends the fragments to the ANET 478 peer, which reassembles before forwarding toward the final 479 destination. 481 o When an OMNI interface sends a packet toward a final destination 482 via an INET interface, it sends encapsulated packets no larger 483 than 1280 bytes without a SPAN header if the destination is 484 reached via an INET address within the same SPAN segment. 485 Otherwise, it inserts a SPAN header with source address set to the 486 node's SPAN address, destination set to the SPAN address of the 487 next hop OMNI node toward the final destination and (if necessary) 488 with a Segment Routing Header [RFC8754] with the remaining Segment 489 IDs on the path to the final destination. The OMNI interface then 490 uses IPv6 fragmentation to break the encapsulated packet into a 491 minimum number of non-overlapping fragments, where the largest 492 fragment size (including both SPAN and INET encapsulation) is 1280 493 bytes and the smallest fragment is no smaller than 640 bytes. The 494 OMNI interface then sends the fragments to the SPAN destination, 495 which reassembles before forwarding toward the final destination. 497 In order to avoid a "tiny fragment" attack, OMNI interfaces 498 unconditionally drop all SPAN fragments smaller than 640 bytes. In 499 order to set the correct context for reassembly, the OMNI interface 500 that inserts a SPAN header MUST also be the one that inserts the IPv6 501 Fragment Header Identification value. Although all fragments of the 502 same fragmented SPAN packet are typically sent via the same 503 underlying interface, this is not strictly required since all 504 fragments will arrive at the OMNI interface that performs reassembly 505 even if they travel over different paths. 507 Note that the OMNI interface can forward large packets via 508 encapsulation and fragmentation while at the same time returning 509 advisory PTB messages, e.g., subject to rate limiting. The receiving 510 node that performs reassembly can also send advisory PTB messages if 511 reassembly conditions become unfavorable. The AERO interface can 512 therefore continuously forward large packets without loss while 513 returning advisory messages recommending a smaller size (but no 514 smaller than 1280). Advisory PTB messages are differentiated from 515 PTB messages that report loss by setting the Code field in the ICMPv6 516 message header to the value 1. This document therefore updates 517 [RFC4443] and [RFC8201]. 519 6. Frame Format 521 The OMNI interface transmits IPv6 packets according to the native 522 frame format of each underlying interface. For example, for 523 Ethernet-compatible interfaces the frame format is specified in 524 [RFC2464], for aeronautical radio interfaces the frame format is 525 specified in standards such as ICAO Doc 9776 (VDL Mode 2 Technical 526 Manual), for tunnels over IPv6 the frame format is specified in 527 [RFC2473], etc. 529 7. Link-Local Addresses 531 OMNI interfaces construct IPv6 Link-Local Addresses (i.e., "OMNI 532 LLAs") as follows: 534 o IPv6 MN OMNI LLAs encode the most-significant 112 bits of a MNP 535 within the least-significant 112 bits of the IPv6 link-local 536 prefix fe80::/16. For example, for the MNP 537 2001:db8:1000:2000::/56 the corresponding LLA is 538 fe80:2001:db8:1000:2000::. See: [RFC4291], Section 2.5.6) for a 539 discussion of IPv6 link-local addresses. 541 o IPv4-compatible MN OMNI LLAs are constructed as 542 fe80::ffff:[v4addr], i.e., the most significant 16 bits of the 543 prefix fe80::/16, followed by 64 '0' bits, followed by 16 '1' 544 bits, followed by a 32bit IPv4 address. For example, the 545 IPv4-Compatible MN OMNI LLA for 192.0.2.1 is fe80::ffff:192.0.2.1 546 (also written as fe80::ffff:c000:0201). 548 o MS OMNI LLAs are assigned to ARs and MSEs from the range 549 fe80::/96, and MUST be managed for uniqueness. The lower 32 bits 550 of the LLA includes a unique integer "MSID" value between 551 0x00000001 and 0xfeffffff, e.g., as in fe80::1, fe80::2, fe80::3, 552 etc., fe80::feff:ffff. The MSID 0x00000000 corresponds to the 553 link-local Subnet-Router anycast address (fe80::) [RFC4291]. The 554 MSID range 0xff000000 through 0xffffffff is reserved for future 555 use. 557 o The OMNI LLA range fe80::/32 is used as the service prefix for the 558 address format specified in Section 4 of [RFC4380] (see Section 17 559 for further discussion). 561 Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 562 MNPs can be allocated from that block ensuring that there is no 563 possibility for overlap between the above OMNI LLA constructs. 565 Since MN OMNI LLAs are based on the distribution of administratively 566 assured unique MNPs, and since MS OMNI LLAs are guaranteed unique 567 through administrative assignment, OMNI interfaces set the 568 autoconfiguration variable DupAddrDetectTransmits to 0 [RFC4862]. 570 8. The SPAN 572 OMNI links employ an overlay network instance called "The SPAN" 573 (Spanning Partitioned Administrative Networks) that supports 574 forwarding of encapsulated link-scoped messages over an IPv6 overlay 575 routing instance that spans the entire link without decrementing the 576 (link-local) Hop Limit. The Unique Local Address (ULA) prefix 577 fd80::/10 [RFC4193] is reserved for mapping OMNI LLAs to routable 578 SPAN addresses. 580 Each OMNI link instance is identified by bits 10-15 of the SPAN 581 service prefix fd80::/10. For example, SPAN addresses associated 582 with instance 0 are configured from the prefix fd80::/16, instance 1 583 from fd81::/16, etc., up to instance 63 from fdbf::/16. SPAN 584 addresses are configured in one-to-one correspondence with MN/MS OMNI 585 LLAs through stateless prefix translation. For example, for SPAN 586 instance fd80::/16: 588 o the SPAN address corresponding to fe80:2001:db8:1:2:: is simply 589 fd80:2001:db8:1:2:: 591 o the SPAN address corresponding to fe80::ffff:192.0.2.1 is simply 592 fd80::ffff:192.0.2.1 594 o the SPAN address corresponding to fe80::1000 is simply fd80::1000 596 o the SPAN address corresponding to fe80:: is simply fd80:: 598 Each OMNI interface assigns the SPAN Anycast address specific to the 599 OMNI link instance, e.g., the OMNI interface connected to instance 3 600 assigns the address fd83:. Routers that configure OMNI interfaces 601 advertise the SPAN prefix for the OMNI link instance (e.g., 602 fd83::/16) into the local routing system so that applications can 603 direct traffic according to SBM requirements. 605 The SPAN address presents an IPv6 address format that is routable 606 within the OMNI link routing system and can be used to convey link- 607 scoped messages across multiple hops using IPv6 encapsulation 608 [RFC2473]. The SPAN extends over the entire OMNI link to include all 609 ARs and MSEs. All MNs are also considered to be "on the SPAN", 610 however SPAN encapsulation is omitted over ANET links when possible 611 to conserve bandwidth (see: Section 11). 613 The SPAN allows the OMNI link to be subdivided into "segments" that 614 often correspond to administrative domains or physical partitions. 615 OMNI nodes can use IPv6 Segment Routing [RFC8754][RFC8402] when 616 necessary to support efficient packet forwarding to destinations 617 located in other SPAN segments. A full discussion of Segment Routing 618 over the SPAN appears in [I-D.templin-intarea-6706bis]. 620 9. Address Mapping - Unicast 622 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 623 state and use the link-local address format specified in Section 7. 624 IPv6 Neighbor Discovery (ND) [RFC4861] messages on MN OMNI interfaces 625 observe the native Source/Target Link-Layer Address Option (S/TLLAO) 626 formats of the underlying interfaces (e.g., for Ethernet the S/TLLAO 627 is specified in [RFC2464]). 629 MNs such as aircraft typically have many wireless data link types 630 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 631 etc.) with diverse performance, cost and availability properties. 632 The OMNI interface would therefore appear to have multiple L2 633 connections, and may include information for multiple underlying 634 interfaces in a single IPv6 ND message exchange. 636 OMNI interfaces use an IPv6 ND option called the "OMNI option" 637 formatted as shown in Figure 3: 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Type | Length | Prefix Length |R| Reserved | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 ~ Sub-Options ~ 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Figure 3: OMNI Option Format 651 In this format: 653 o Type is set to TBD. 655 o Length is set to the number of 8 octet blocks in the option. 657 o Prefix Length is set according to the IPv6 source address type. 658 For MN OMNI LLAs, the value is set to the length of the embedded 659 MNP. For IPv4-compatible MN OMNI LLAs, the value is set to 96 660 plus the length of the embedded IPv4 prefix. For MS OMNI LLAs, 661 the value is set to 128. 663 o R (the "Register/Release" bit) is set to 1/0 to request the 664 message recipient to register/release a MN's MNP. The OMNI option 665 may additionally include MSIDs for the recipient to contact to 666 also register/release the MNP. 668 o Reserved is set to the value '0' on transmission and ignored on 669 reception. 671 o Sub-Options is a Variable-length field, of length such that the 672 complete OMNI Option is an integer multiple of 8 octets long. 673 Contains one or more options, as described in Section 9.1. 675 9.1. Sub-Options 677 The OMNI option includes zero or more Sub-Options, some of which may 678 appear multiple times in the same message. Each consecutive Sub- 679 Option is concatenated immediately after its predecessor. All Sub- 680 Options except Pad1 (see below) are type-length-value (TLV) encoded 681 in the following format: 683 0 1 2 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 686 | Sub-Type | Sub-length | Sub-Option Data ... 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 689 Figure 4: Sub-Option Format 691 o Sub-Type is a 1-byte field that encodes the Sub-Option type. Sub- 692 Options defined in this document are: 694 Option Name Sub-Type 695 Pad1 0 696 PadN 1 697 ifIndex-tuple (Type 1) 2 698 ifIndex-tuple (Type 2) 3 699 MS-Register 4 700 MS-Release 5 701 Network Access Identifier 6 702 Geo Coordinates 7 704 Figure 5 706 Sub-Types 253 and 254 are reserved for experimentation, as 707 recommended in [RFC3692]. 709 o Sub-Length is a 1-byte field that encodes the length of the Sub- 710 Option Data, in bytes 712 o Sub-Option Data is a byte string with format determined by Sub- 713 Type 715 During processing, unrecognized Sub-Options are ignored and the next 716 Sub-Option processed until the end of the OMNI option. 718 The following Sub-Option types and formats are defined in this 719 document: 721 9.1.1. Pad1 723 0 724 0 1 2 3 4 5 6 7 725 +-+-+-+-+-+-+-+-+ 726 | Sub-Type=0 | 727 +-+-+-+-+-+-+-+-+ 729 Figure 6: Pad1 731 o Sub-Type is set to 0. 733 o No Sub-Length or Sub-Option Data follows (i.e., the "Sub-Option" 734 consists of a single zero octet). 736 9.1.2. PadN 738 0 1 2 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 741 | Sub-Type=1 |Sub-length=N-2 | N-2 padding bytes ... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 744 Figure 7: PadN 746 o Sub-Type is set to 1. 748 o Sub-Length is set to N-2 being the number of padding bytes that 749 follow. 751 o Sub-Option Data consists of N-2 zero-valued octets. 753 9.1.3. ifIndex-tuple (Type 1) 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Sub-Type=2 | Sub-length=4+N| ifIndex | ifType | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Provider ID | Link |S|I|RSV| Bitmap(0)=0xff|P00|P01|P02|P03| 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 |P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19| 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| Bitmap(1)=0xff| 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |P32|P33|P34|P35|P36|P37|P38|P39| ... 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 768 Figure 8: ifIndex-tuple (Type 1) 770 o Sub-Type is set to 2. 772 o Sub-Length is set to 4+N (the number of Sub-Option Data bytes that 773 follow). 775 o Sub-Option Data contains an "ifIndex-tuple" (Type 1) encoded as 776 follows (note that the first four bytes must be present): 778 * ifIndex is set to an 8-bit integer value corresponding to a 779 specific underlying interface. OMNI options MAY include 780 multiple ifIndex-tuples, and MUST number each with an ifIndex 781 value between '1' and '255' that represents a MN-specific 8-bit 782 mapping for the actual ifIndex value assigned to the underlying 783 interface by network management [RFC2863] (the ifIndex value 784 '0' is reserved for use by the MS). Multiple ifIndex-tuples 785 with the same ifIndex value MAY appear in the same OMNI option. 787 * ifType is set to an 8-bit integer value corresponding to the 788 underlying interface identified by ifIndex. The value 789 represents an OMNI interface-specific 8-bit mapping for the 790 actual IANA ifType value registered in the 'IANAifType-MIB' 791 registry [http://www.iana.org]. 793 * Provider ID is set to an OMNI interface-specific 8-bit ID value 794 for the network service provider associated with this ifIndex. 796 * Link encodes a 4-bit link metric. The value '0' means the link 797 is DOWN, and the remaining values mean the link is UP with 798 metric ranging from '1' ("lowest") to '15' ("highest"). 800 * S is set to '1' if this ifIndex-tuple corresponds to the 801 underlying interface that is the source of the ND message. Set 802 to '0' otherwise. 804 * I is set to '0' ("Simplex") if the index for each singleton 805 Bitmap byte in the Sub-Option Data is inferred from its 806 sequential position (i.e., 0, 1, 2, ...), or set to '1' 807 ("Indexed") if each Bitmap is preceded by an Index byte. 808 Figure 8 shows the simplex case for I set to '0'. For I set to 809 '1', each Bitmap is instead preceded by an Index byte that 810 encodes a value "i" = (0 - 255) as the index for its companion 811 Bitmap as follows: 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 814 | Index=i | Bitmap(i) |P[*] values ... 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 817 Figure 9 819 * RSV is set to the value 0 on transmission and ignored on 820 reception. 822 * The remainder of the Sub-Option Data contains N = (0 - 251) 823 bytes of traffic classifier preferences consisting of a first 824 (indexed) Bitmap (i.e., "Bitmap(i)") followed by 0-8 1-byte 825 blocks of 2-bit P[*] values, followed by a second Bitmap (i), 826 followed by 0-8 blocks of P[*] values, etc. Reading from bit 0 827 to bit 7, the bits of each Bitmap(i) that are set to '1'' 828 indicate the P[*] blocks from the range P[(i*32)] through 829 P[(i*32) + 31] that follow; if any Bitmap(i) bits are '0', then 830 the corresponding P[*] block is instead omitted. For example, 831 if Bitmap(0) contains 0xff then the block with P[00]-P[03], 832 followed by the block with P[04]-P[07], etc., and ending with 833 the block with P[28]-P[31] are included (as shown in Figure 8). 834 The next Bitmap(i) is then consulted with its bits indicating 835 which P[*] blocks follow, etc. out to the end of the Sub- 836 Option. The first 16 P[*] blocks correspond to the 64 837 Differentiated Service Code Point (DSCP) values P[00] - P[63] 838 [RFC2474]. Any additional P[*] blocks that follow correspond 839 to "pseudo-DSCP" traffic classifier values P[64], P[65], P[66], 840 etc. See Appendix A for further discussion and examples. 842 * Each 2-bit P[*] field is set to the value '0' ("disabled"), '1' 843 ("low"), '2' ("medium") or '3' ("high") to indicate a QoS 844 preference level for underlying interface selection purposes. 845 Not all P[*] values need to be included in all OMNI option 846 instances of a given ifIndex-tuple. Any P[*] values 847 represented in an earlier OMNI option but omitted in the 848 current OMNI option remain unchanged. Any P[*] values not yet 849 represented in any OMNI option default to "medium". 851 9.1.4. ifIndex-tuple (Type 2) 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Sub-Type=3 | Sub-length=4+N| ifIndex | ifType | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Provider ID | Link |S|Resvd| ~ 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 860 ~ ~ 861 ~ RFC 6088 Format Traffic Selector ~ 862 ~ ~ 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Figure 10: ifIndex-tuple (Type 2) 867 o Sub-Type is set to 3. 869 o Sub-Length is set to 4+N (the number of Sub-Option Data bytes that 870 follow). 872 o Sub-Option Data contains an "ifIndex-tuple" (Type 2) encoded as 873 follows (note that the first four bytes must be present): 875 * ifIndex, ifType, Provider ID, Link and S are set exactly as for 876 Type 1 ifIndex-tuples as specified in Section 9.1.3. 878 * the remainder of the Sub-Option body encodes a variable-length 879 traffic selector formatted per [RFC6088], beginning with the 880 "TS Format" field. 882 9.1.5. MS-Register 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Sub-Type=4 | Sub-length=4 | MSID (bits 0 - 15) | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | MSID (bits 16 - 32) | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Figure 11: MS-Register Sub-option 894 o Sub-Type is set to 4. 896 o Sub-Length is set to 4. 898 o MSID contains the 32 bit ID of an MSE or AR, in network byte 899 order. OMNI options contain zero or more MS-Register sub-options. 901 9.1.6. MS-Release 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Sub-Type=5 | Sub-length=4 | MSID (bits 0 - 15) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | MSID (bits 16 - 32) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Figure 12: MS-Release Sub-option 913 o Sub-Type is set to 5. 915 o Sub-Length is set to 4. 917 o MSIID contains the 32 bit ID of an MS or AR, in network byte 918 order. OMNI options contain zero or more MS-Release sub-options. 920 9.1.7. Network Access Identifier (NAI) 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Sub-Type=6 | Sub-length=N |Network Access Identifier (NAI) 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 928 Figure 13: Network Access Identifier (NAI) Sub-option 930 o Sub-Type is set to 6. 932 o Sub-Length is set to N. 934 o Network Access Identifier (NAI) is coded per [RFC7542], and is up 935 to 253 bytes in length. 937 9.1.8. Geo Coordiantes 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Sub-Type=7 | Sub-length=N | Geo Coordinates 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 944 Figure 14: Geo Coordinates Sub-option 946 o Sub-Type is set to 7. 948 o Sub-Length is set to N. 950 o A set of Geo Coordinates up to 253 bytes in length (format TBD). 951 Includes Latitude/Longitude at a minimum; may also include 952 additional attributes such as altitude, heading, speed, etc.). 954 10. Address Mapping - Multicast 956 The multicast address mapping of the native underlying interface 957 applies. The mobile router on board the MN also serves as an IGMP/ 958 MLD Proxy for its EUNs and/or hosted applications per [RFC4605] while 959 using the L2 address of the AR as the L2 address for all multicast 960 packets. 962 The MN uses Multicast Listener Discovery (MLDv2) [RFC3810] to 963 coordinate with the AR, and ANET L2 elements use MLD snooping 964 [RFC4541]. 966 11. Conceptual Sending Algorithm 968 The MN's IPv6 layer selects the outbound OMNI interface according to 969 SBM considerations when forwarding data packets from local or EUN 970 applications to external correspondents. Each OMNI interface 971 maintains a neighbor cache the same as for any IPv6 interface, but 972 with additional state for multilink coordination. 974 After a packet enters the OMNI interface, an outbound underlying 975 interface is selected based on PBM traffic selectors such as DSCP, 976 application port number, cost, performance, message size, etc. OMNI 977 interface multilink selections could also be configured to perform 978 replication across multiple underlying interfaces for increased 979 reliability at the expense of packet duplication. 981 When an OMNI interface sends a packet over a selected outbound 982 underlying interface, it omits SPAN encapsulation if the packet does 983 not require fragmentation and the neighbor can determine the SPAN 984 addresses through other means (e.g., the packet's destination, 985 neighbor cache information, etc.). Otherwise, the OMNI interface 986 inserts a SPAN header and performs fragmentation if necessary. 988 OMNI interface multilink service designers MUST observe the BCP 989 guidance in Section 15 [RFC3819] in terms of implications for 990 reordering when packets from the same flow may be spread across 991 multiple underlying interfaces having diverse properties. 993 11.1. Multiple OMNI Interfaces 995 MNs may connect to multiple independent OMNI links concurrently in 996 support of SBM. Each OMNI interface is distinguished by its SPAN 997 Anycast address (e.g., fd80::, fd81::, fd82::). The MN configures a 998 separate OMNI interface for each link so that multiple interfaces 999 (e.g., omni0, omni1, omni2, etc.) are exposed to the IPv6 layer. A 1000 different SPAN Anycast address is assigned to each interface, and the 1001 MN injects the SPAN prefixes for the OMNI link instances into the EUN 1002 routing system. 1004 Applications in EUNs can use Segment Routing to select the desired 1005 OMNI interface based on SBM considerations. The SPAN Anycast address 1006 is written into the IPv6 destination address, and the actual 1007 destination (along with any additional intermediate hops) is written 1008 into the Segment Routing Header. Standard IP routing directs the 1009 packets to the MN's mobile router entity, and the SPAN Anycast 1010 address identifies the OMNI interface to be used for transmission to 1011 the next hop. When the MN receives the message, it replaces the IPv6 1012 destination address with the next hop found in the routing header and 1013 transmits the message over the OMNI interface identified by the SPAN 1014 Anycast address. 1016 Multiple distinct OMNI links can therefore be used to support fault 1017 tolerance, load balancing, reliability, etc. The architectural model 1018 is similar to Layer 2 Virtual Local Area Networks (VLANs). 1020 12. Router Discovery and Prefix Registration 1022 MNs interface with the MS by sending RS messages with OMNI options 1023 under the assumption that a single AR on the ANET will process the 1024 message and respond. This places a requirement on each ANET, which 1025 may be enforced by physical/logical partitioning, L2 AR beaconing, 1026 etc. The manner in which the ANET ensures single AR coordination is 1027 link-specific and outside the scope of this document. 1029 For each underlying interface, the MN sends an RS message with an 1030 OMNI option with prefix registration information, ifIndex-tuples, MS- 1031 Register/Release suboptions containing MSIDs, and with destination 1032 address set to All-Routers multicast (ff02::2) [RFC4291]. Example 1033 MSID discovery methods are given in [RFC5214], including data link 1034 login parameters, name service lookups, static configuration, etc. 1035 Alternatively, MNs can discover individual MSIDs by sending an 1036 initial RS with MS-Register MSID set to 0x00000000. 1038 MNs configure OMNI interfaces that observe the properties discussed 1039 in the previous section. The OMNI interface and its underlying 1040 interfaces are said to be in either the "UP" or "DOWN" state 1041 according to administrative actions in conjunction with the interface 1042 connectivity status. An OMNI interface transitions to UP or DOWN 1043 through administrative action and/or through state transitions of the 1044 underlying interfaces. When a first underlying interface transitions 1045 to UP, the OMNI interface also transitions to UP. When all 1046 underlying interfaces transition to DOWN, the OMNI interface also 1047 transitions to DOWN. 1049 When an OMNI interface transitions to UP, the MN sends RS messages to 1050 register its MNP and an initial set of underlying interfaces that are 1051 also UP. The MN sends additional RS messages to refresh lifetimes 1052 and to register/deregister underlying interfaces as they transition 1053 to UP or DOWN. The MN sends initial RS messages over an UP 1054 underlying interface with its OMNI LLA as the source and with 1055 destination set to All-Routers multicast. The RS messages include an 1056 OMNI option per Section 9 with valid prefix registration information, 1057 ifIndex-tuples appropriate for underlying interfaces and MS-Register/ 1058 Release sub-options. 1060 ARs process IPv6 ND messages with OMNI options and act as a proxy for 1061 MSEs. ARs receive RS messages and create a neighbor cache entry for 1062 the MN, then coordinate with any named MSIDs in a manner outside the 1063 scope of this document. The AR returns an RA message with 1064 destination address set to the MN OMNI LLA (i.e., unicast), with 1065 source address set to its MS OMNI LLA, with the P(roxy) bit set in 1066 the RA flags [RFC4389][RFC5175], with an OMNI option with valid 1067 prefix registration information, ifIndex-tuples, MS-Register/Release 1068 sub-options, and with any information for the link that would 1069 normally be delivered in a solicited RA message. ARs return RA 1070 messages with configuration information in response to a MN's RS 1071 messages. The AR sets the RA Cur Hop Limit, M and O flags, Router 1072 Lifetime, Reachable Time and Retrans Timer values, and includes any 1073 necessary options such as: 1075 o PIOs with (A; L=0) that include MSPs for the link [RFC8028]. 1077 o RIOs [RFC4191] with more-specific routes. 1079 o an MTU option that specifies the maximum acceptable packet size 1080 for this ANET interface. 1082 The AR coordinates with each Register/Release MSID then sends an 1083 immediate unicast RA response without delay; therefore, the IPv6 ND 1084 MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS constants for multicast 1085 RAs do not apply. The AR MAY send periodic and/or event-driven 1086 unsolicited RA messages according to the standard [RFC4861]. 1088 When the MSE processes the OMNI information, it first validates the 1089 prefix registration information. The MSE then injects/withdraws the 1090 MNP in the routing/mapping system and caches/discards the new Prefix 1091 Length, MNP and ifIndex-tuples. The MSE then informs the AR of 1092 registration success/failure, and the AR adds the MSE to the list of 1093 Register/Release MSIDs to return in an RA message OMNI option per 1094 Section 9. 1096 When the MN receives the RA message, it creates an OMNI interface 1097 neighbor cache entry with the AR's address as an L2 address and 1098 records the MSIDs that have confirmed MNP registration via this AR. 1099 If the MN connects to multiple ANETs, it establishes additional AR L2 1100 addresses (i.e., as a Multilink neighbor). The MN then manages its 1101 underlying interfaces according to their states as follows: 1103 o When an underlying interface transitions to UP, the MN sends an RS 1104 over the underlying interface with an OMNI option with R set to 1. 1105 The OMNI option contains at least one ifIndex-tuple with values 1106 specific to this underlying interface, and may contain additional 1107 ifIndex-tuples specific to this and/or other underlying 1108 interfaces. The option also includes any Register/Release MSIDs. 1110 o When an underlying interface transitions to DOWN, the MN sends an 1111 RS or unsolicited NA message over any UP underlying interface with 1112 an OMNI option containing an ifIndex-tuple for the DOWN underlying 1113 interface with Link set to '0'. The MN sends an RS when an 1114 acknowledgement is required, or an unsolicited NA when reliability 1115 is not thought to be a concern (e.g., if redundant transmissions 1116 are sent on multiple underlying interfaces). 1118 o When the Router Lifetime for a specific AR nears expiration, the 1119 MN sends an RS over the underlying interface to receive a fresh 1120 RA. If no RA is received, the MN marks the underlying interface 1121 as DOWN. 1123 o When a MN wishes to release from one or more current MSIDs, it 1124 sends an RS or unsolicited NA message over any UP underlying 1125 interfaces with an OMNI option with a Release MSID. Each MSID 1126 then withdraws the MNP from the routing/mapping system and informs 1127 the AR that the release was successful. 1129 o When all of a MNs underlying interfaces have transitioned to DOWN 1130 (or if the prefix registration lifetime expires), any associated 1131 MSEs withdraw the MNP the same as if they had received a message 1132 with a release indication. 1134 The MN is responsible for retrying each RS exchange up to 1135 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 1136 seconds until an RA is received. If no RA is received over a an UP 1137 underlying interface, the MN declares this underlying interface as 1138 DOWN. 1140 The IPv6 layer sees the OMNI interface as an ordinary IPv6 interface. 1141 Therefore, when the IPv6 layer sends an RS message the OMNI interface 1142 returns an internally-generated RA message as though the message 1143 originated from an IPv6 router. The internally-generated RA message 1144 contains configuration information that is consistent with the 1145 information received from the RAs generated by the MS. Whether the 1146 OMNI interface IPv6 ND messaging process is initiated from the 1147 receipt of an RS message from the IPv6 layer is an implementation 1148 matter. Some implementations may elect to defer the IPv6 ND 1149 messaging process until an RS is received from the IPv6 layer, while 1150 others may elect to initiate the process proactively. 1152 Note: The Router Lifetime value in RA messages indicates the time 1153 before which the MN must send another RS message over this underlying 1154 interface (e.g., 600 seconds), however that timescale may be 1155 significantly longer than the lifetime the MS has committed to retain 1156 the prefix registration (e.g., REACHABLETIME seconds). ARs are 1157 therefore responsible for keeping MS state alive on a shorter 1158 timescale than the MN is required to do on its own behalf. 1160 Note: On multicast-capable underlying interfaces, MNs should send 1161 periodic unsolicited multicast NA messages and ARs should send 1162 periodic unsolicited multicast RA messages as "beacons" that can be 1163 heard by other nodes on the link. If a node fails to receive a 1164 beacon after a timeout value specific to the link, it can initiate a 1165 unicast exchange to test reachability. 1167 13. Secure Redirection 1169 If the ANET link model is multiple access, the AR is responsible for 1170 assuring that address duplication cannot corrupt the neighbor caches 1171 of other nodes on the link. When the MN sends an RS message on a 1172 multiple access ANET link, the AR verifies that the MN is authorized 1173 to use the address and returns an RA with a non-zero Router Lifetime 1174 only if the MN is authorized. 1176 After verifying MN authorization and returning an RA, the AR MAY 1177 return IPv6 ND Redirect messages to direct MNs located on the same 1178 ANET link to exchange packets directly without transiting the AR. In 1179 that case, the MNs can exchange packets according to their unicast L2 1180 addresses discovered from the Redirect message instead of using the 1181 dogleg path through the AR. In some ANET links, however, such direct 1182 communications may be undesirable and continued use of the dogleg 1183 path through the AR may provide better performance. In that case, 1184 the AR can refrain from sending Redirects, and/or MNs can ignore 1185 them. 1187 14. AR and MSE Resilience 1189 ANETs SHOULD deploy ARs in Virtual Router Redundancy Protocol (VRRP) 1190 [RFC5798] configurations so that service continuity is maintained 1191 even if one or more ARs fail. Using VRRP, the MN is unaware which of 1192 the (redundant) ARs is currently providing service, and any service 1193 discontinuity will be limited to the failover time supported by VRRP. 1194 Widely deployed public domain implementations of VRRP are available. 1196 MSEs SHOULD use high availability clustering services so that 1197 multiple redundant systems can provide coordinated response to 1198 failures. As with VRRP, widely deployed public domain 1199 implementations of high availability clustering services are 1200 available. Note that special-purpose and expensive dedicated 1201 hardware is not necessary, and public domain implementations can be 1202 used even between lightweight virtual machines in cloud deployments. 1204 15. Detecting and Responding to MSE Failures 1206 In environments where fast recovery from MSE failure is required, ARs 1207 SHOULD use proactive Neighbor Unreachability Detection (NUD) in a 1208 manner that parallels Bidirectional Forwarding Detection (BFD) 1209 [RFC5880] to track MSE reachability. ARs can then quickly detect and 1210 react to failures so that cached information is re-established 1211 through alternate paths. Proactive NUD control messaging is carried 1212 only over well-connected ground domain networks (i.e., and not low- 1213 end ANET links such as aeronautical radios) and can therefore be 1214 tuned for rapid response. 1216 ARs perform proactive NUD for MSEs for which there are currently 1217 active MNs on the ANET. If an MSE fails, ARs can quickly inform MNs 1218 of the outage by sending multicast RA messages on the ANET interface. 1219 The AR sends RA messages to MNs via the ANET interface with an OMNI 1220 option with a Release ID for the failed MSE, and with destination 1221 address set to All-Nodes multicast (ff02::1) [RFC4291]. 1223 The AR SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated 1224 by small delays [RFC4861]. Any MNs on the ANET interface that have 1225 been using the (now defunct) MSE will receive the RA messages and 1226 associate with a new MSE. 1228 16. Transition Considerations 1230 When a MN connects to an ANET link for the first time, it sends an RS 1231 message with an OMNI option. If the first hop AR recognizes the 1232 option, it returns an RA with its MS OMNI LLA as the source, the MN 1233 OMNI LLA as the destination, the P(roxy) bit set in the RA flags and 1234 with an OMNI option included. The MN then engages the AR according 1235 to the OMNI link model specified above. If the first hop AR is a 1236 legacy IPv6 router, however, it instead returns an RA message with no 1237 OMNI option and with a non-OMNI unicast source LLA as specified in 1238 [RFC4861]. In that case, the MN engages the ANET according to the 1239 legacy IPv6 link model and without the OMNI extensions specified in 1240 this document. 1242 If the ANET link model is multiple access, there must be assurance 1243 that address duplication cannot corrupt the neighbor caches of other 1244 nodes on the link. When the MN sends an RS message on a multiple 1245 access ANET link with an OMNI LLA source address and an OMNI option, 1246 ARs that recognize the option ensure that the MN is authorized to use 1247 the address and return an RA with a non-zero Router Lifetime only if 1248 the MN is authorized. ARs that do not recognize the option instead 1249 return an RA that makes no statement about the MN's authorization to 1250 use the source address. In that case, the MN should perform 1251 Duplicate Address Detection to ensure that it does not interfere with 1252 other nodes on the link. 1254 An alternative approach for multiple access ANET links to ensure 1255 isolation for MN / AR communications is through L2 address mappings 1256 as discussed in Appendix C. This arrangement imparts a (virtual) 1257 point-to-point link model over the (physical) multiple access link. 1259 17. OMNI Interfaces on the Open Internet 1261 OMNI interfaces configured over INET interfaces that connect to the 1262 open Internet can apply symmetric security services such as VPNs or 1263 establish a direct link through some other means. In environments 1264 where an explicit VPN or direct link may be impractical, OMNI 1265 interfaces can instead use Teredo UDP/IP encapsulation 1266 [RFC6081][RFC4380]. (SEcure Neighbor Discovery (SEND) and 1267 Cryptographically Generated Addresses (CGA) [RFC3971][RFC3972] can 1268 also be used if additional authentication is necessary.) 1269 The IPv6 ND control plane messages used to establish neighbor cache 1270 state must be authenticated while data plane messages are delivered 1271 the same as for ordinary best-effort Internet traffic with basic 1272 source address-based data origin verification. Data plane 1273 communications via OMNI interfaces that connect over the open 1274 Internet without an explicit VPN should therefore employ transport- 1275 or higher-layer security to ensure integrity and/or confidentiality. 1277 OMNI interfaces in the open Internet are often located behind Network 1278 Address Translators (NATs). The OMNI interface accommodates NAT 1279 traversal using UDP/IP encapsulation and the mechanisms discussed in 1280 [RFC6081][RFC4380][I-D.templin-intarea-6706bis]. 1282 18. Time-Varying MNPs 1284 In some use cases, it is desirable, beneficial and efficient for the 1285 MN to receive a constant MNP that travels with the MN wherever it 1286 moves. For example, this would allow air traffic controllers to 1287 easily track aircraft, etc. In other cases, however (e.g., 1288 intelligent transportation systems), the MN may be willing to 1289 sacrifice a modicum of efficiency in order to have time-varying MNPs 1290 that can be changed every so often to defeat adversarial tracking. 1292 Prefix delegation services such as those discussed in 1293 [I-D.templin-6man-dhcpv6-ndopt] and [I-D.templin-intarea-6706bis] 1294 allow OMNI MNs that desire time-varying MNPs to obtain short-lived 1295 prefixes. In that case, the identity of the MN can be used as a 1296 prefix delegation seed (e.g., a DHCPv6 Device Unique IDentifier 1297 (DUID) [RFC8415]). The MN would then be obligated to renumber its 1298 internal networks whenever its MNP (and therefore also its OMNI 1299 address) changes. This should not present a challenge for MNs with 1300 automated network renumbering services, however presents limits for 1301 the durations of ongoing sessions that would prefer to use a constant 1302 address. 1304 19. IANA Considerations 1306 The IANA is instructed to allocate an official Type number TBD from 1307 the registry "IPv6 Neighbor Discovery Option Formats" for the OMNI 1308 option. Implementations set Type to 253 as an interim value 1309 [RFC4727]. 1311 The IANA is instructed to allocate one Ethernet unicast address TBD2 1312 (suggest 00-00-5E-00-52-14 [RFC5214]) in the registry "IANA Ethernet 1313 Address Block - Unicast Use". 1315 The OMNI option also defines an 8-bit Sub-Type field, for which IANA 1316 is instructed to create and maintain a new registry entitled "OMNI 1317 option Sub-Type values". Initial values for the OMNI option Sub-Type 1318 values registry are given below; future assignments are to be made 1319 through Expert Review [RFC8126]. 1321 Value Sub-Type name Reference 1322 ----- ------------- ---------- 1323 0 Pad1 [RFCXXXX] 1324 1 PadN [RFCXXXX] 1325 2 ifIndex-tuple (Type 1) [RFCXXXX] 1326 3 ifIndex-tuple (Type 2) [RFCXXXX] 1327 4 MS-Register [RFCXXXX] 1328 5 MS-Release [RFCXXXX] 1329 6 Network Acceess Identifier [RFCXXXX] 1330 7 Geo Coordinates [RFCXXXX] 1331 8-252 Unassigned 1332 253-254 Experimental [RFCXXXX] 1333 255 Reserved [RFCXXXX] 1335 Figure 15: OMNI Option Sub-Type Values 1337 20. Security Considerations 1339 Security considerations for IPv6 [RFC8200] and IPv6 Neighbor 1340 Discovery [RFC4861] apply. OMNI interface IPv6 ND messages SHOULD 1341 include Nonce and Timestamp options [RFC3971] when transaction 1342 confirmation and/or time synchronization is needed. 1344 OMNI interfaces configured over secured ANET interfaces inherit the 1345 physical and/or link-layer security properties of the connected 1346 ANETs. OMNI interfaces configured over open INET interfaces can use 1347 symmetric securing services such as VPNs or can by some other means 1348 establish a direct link. When a VPN or direct link may be 1349 impractical, however, an asymmetric security service such as SEcure 1350 Neighbor Discovery (SEND) [RFC3971] with Cryptographically Generated 1351 Addresses (CGAs) [RFC3972] and/or the Teredo Authentication option 1352 [RFC4380] may be necessary. 1354 While the OMNI link protects control plane messaging as discussed 1355 above, applications should still employ transport- or higher-layer 1356 security services to protect the data plane. 1358 Security considerations for specific access network interface types 1359 are covered under the corresponding IP-over-(foo) specification 1360 (e.g., [RFC2464], [RFC2492], etc.). 1362 21. Acknowledgements 1364 The first version of this document was prepared per the consensus 1365 decision at the 7th Conference of the International Civil Aviation 1366 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 1367 2019. Consensus to take the document forward to the IETF was reached 1368 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 1369 Attendees and contributors included: Guray Acar, Danny Bharj, 1370 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 1371 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 1372 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 1373 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 1374 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 1375 Fryderyk Wrobel and Dongsong Zeng. 1377 The following individuals are acknowledged for their useful comments: 1378 Michael Matyas, Madhu Niraula, Greg Saccone, Stephane Tamalet, Eric 1379 Vyncke. Pavel Drasil, Zdenek Jaron and Michal Skorepa are recognized 1380 for their many helpful ideas and suggestions. 1382 This work is aligned with the NASA Safe Autonomous Systems Operation 1383 (SASO) program under NASA contract number NNA16BD84C. 1385 This work is aligned with the FAA as per the SE2025 contract number 1386 DTFAWA-15-D-00030. 1388 22. References 1390 22.1. Normative References 1392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1393 Requirement Levels", BCP 14, RFC 2119, 1394 DOI 10.17487/RFC2119, March 1997, 1395 . 1397 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1398 "Definition of the Differentiated Services Field (DS 1399 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1400 DOI 10.17487/RFC2474, December 1998, 1401 . 1403 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1404 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1405 DOI 10.17487/RFC3971, March 2005, 1406 . 1408 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1409 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1410 . 1412 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1413 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1414 November 2005, . 1416 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1417 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1418 . 1420 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1421 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1422 2006, . 1424 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1425 Control Message Protocol (ICMPv6) for the Internet 1426 Protocol Version 6 (IPv6) Specification", STD 89, 1427 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1428 . 1430 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1431 ICMPv6, UDP, and TCP Headers", RFC 4727, 1432 DOI 10.17487/RFC4727, November 2006, 1433 . 1435 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1436 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1437 DOI 10.17487/RFC4861, September 2007, 1438 . 1440 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1441 Address Autoconfiguration", RFC 4862, 1442 DOI 10.17487/RFC4862, September 2007, 1443 . 1445 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 1446 "Traffic Selectors for Flow Bindings", RFC 6088, 1447 DOI 10.17487/RFC6088, January 2011, 1448 . 1450 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1451 Hosts in a Multi-Prefix Network", RFC 8028, 1452 DOI 10.17487/RFC8028, November 2016, 1453 . 1455 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1456 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1457 May 2017, . 1459 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1460 (IPv6) Specification", STD 86, RFC 8200, 1461 DOI 10.17487/RFC8200, July 2017, 1462 . 1464 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1465 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1466 DOI 10.17487/RFC8201, July 2017, 1467 . 1469 22.2. Informative References 1471 [I-D.templin-6man-dhcpv6-ndopt] 1472 Templin, F., "A Unified Stateful/Stateless Configuration 1473 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-09 1474 (work in progress), January 2020. 1476 [I-D.templin-intarea-6706bis] 1477 Templin, F., "Asymmetric Extended Route Optimization 1478 (AERO)", draft-templin-intarea-6706bis-48 (work in 1479 progress), May 2020. 1481 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 1482 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 1483 . 1485 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1486 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1487 . 1489 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1490 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1491 December 1998, . 1493 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 1494 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 1495 . 1497 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1498 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 1499 . 1501 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1502 Considered Useful", BCP 82, RFC 3692, 1503 DOI 10.17487/RFC3692, January 2004, 1504 . 1506 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1507 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1508 DOI 10.17487/RFC3810, June 2004, 1509 . 1511 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1512 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1513 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1514 RFC 3819, DOI 10.17487/RFC3819, July 2004, 1515 . 1517 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1518 Network Address Translations (NATs)", RFC 4380, 1519 DOI 10.17487/RFC4380, February 2006, 1520 . 1522 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1523 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 1524 2006, . 1526 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1527 "Considerations for Internet Group Management Protocol 1528 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1529 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 1530 . 1532 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1533 "Internet Group Management Protocol (IGMP) / Multicast 1534 Listener Discovery (MLD)-Based Multicast Forwarding 1535 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 1536 August 2006, . 1538 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 1539 Advertisement Flags Option", RFC 5175, 1540 DOI 10.17487/RFC5175, March 2008, 1541 . 1543 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1544 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1545 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1546 . 1548 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1549 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1550 DOI 10.17487/RFC5214, March 2008, 1551 . 1553 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 1554 RFC 5558, DOI 10.17487/RFC5558, February 2010, 1555 . 1557 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 1558 Version 3 for IPv4 and IPv6", RFC 5798, 1559 DOI 10.17487/RFC5798, March 2010, 1560 . 1562 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1563 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1564 . 1566 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 1567 DOI 10.17487/RFC6081, January 2011, 1568 . 1570 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 1571 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 1572 2012, . 1574 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1575 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1576 DOI 10.17487/RFC7084, November 2013, 1577 . 1579 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 1580 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 1581 Boundary in IPv6 Addressing", RFC 7421, 1582 DOI 10.17487/RFC7421, January 2015, 1583 . 1585 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1586 DOI 10.17487/RFC7542, May 2015, 1587 . 1589 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 1590 Support for IP Hosts with Multi-Access Support", RFC 7847, 1591 DOI 10.17487/RFC7847, May 2016, 1592 . 1594 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1595 Writing an IANA Considerations Section in RFCs", BCP 26, 1596 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1597 . 1599 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1600 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1601 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1602 July 2018, . 1604 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1605 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1606 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1607 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1608 . 1610 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1611 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1612 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1613 . 1615 Appendix A. Type 1 ifIndex-tuple Traffic Classifier Preference Encoding 1617 Adaptation of the OMNI option Type 1 ifIndex-tuple's traffic 1618 classifier Bitmap to specific Internetworks such as the Aeronautical 1619 Telecommunications Network with Internet Protocol Services (ATN/IPS) 1620 may include link selection preferences based on other traffic 1621 classifiers (e.g., transport port numbers, etc.) in addition to the 1622 existing DSCP-based preferences. Nodes on specific Internetworks 1623 maintain a map of traffic classifiers to additional P[*] preference 1624 fields beyond the first 64. For example, TCP port 22 maps to P[67], 1625 TCP port 443 maps to P[70], UDP port 8060 maps to P[76], etc. 1627 Implementations use Simplex or Indexed encoding formats for P[*] 1628 encoding in order to encode a given set of traffic classifiers in the 1629 most efficient way. Some use cases may be more efficiently coded 1630 using Simplex form, while others may be more efficient using Indexed. 1631 Once a format is selected for preparation of a single ifIndex-tuple 1632 the same format must be used for the entire Sub-Option. Different 1633 Sub-Options may use different formats. 1635 The following figures show coding examples for various Simplex and 1636 Indexed formats: 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Sub-Type=2 | Sub-length=4+N| ifIndex | ifType | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Provider ID | Link |S|0|RSV| Bitmap(0)=0xff|P00|P01|P02|P03| 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 |P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19| 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 |P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| Bitmap(1)=0xff| 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | Bitmap(2)=0xff|P64|P65|P67|P68| ... 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1656 Figure 16: Example 1: Dense Simplex Encoding 1658 0 1 2 3 1659 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 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Sub-Type=2 | Sub-length=4+N| ifIndex | ifType | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Provider ID | Link |S|0|RSV| Bitmap(0)=0x00| Bitmap(1)=0x0f| 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | Bitmap(2)=0x00| Bitmap(3)=0x00| Bitmap(4)=0x00| Bitmap(5)=0x00| 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | Bitmap(6)=0xf0|192|193|194|195|196|197|198|199|200|201|202|203| 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 |204|205|206|207| Bitmap(7)=0x00| Bitmap(8)=0x0f|272|273|274|275| 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 |276|277|278|279|280|281|282|283|284|285|286|287| Bitmap(9)=0x00| 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 |Bitmap(10)=0x00| ... 1676 +-+-+-+-+-+-+-+-+-+-+- 1678 Figure 17: Example 2: Sparse Simplex Encoding 1680 0 1 2 3 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Sub-Type=2 | Sub-length=4+N| ifIndex | ifType | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Provider ID | Link |S|1|RSV| Index = 0x00 | Bitmap = 0x80 | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 |P00|P01|P02|P03| Index = 0x01 | Bitmap = 0x01 |P60|P61|P62|P63| 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | Index = 0x10 | Bitmap = 0x80 |512|513|514|515| Index = 0x18 | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Bitmap = 0x01 |796|797|798|799| ... 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1694 Figure 18: Example 3: Indexed Encoding 1696 Appendix B. VDL Mode 2 Considerations 1698 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 1699 (VDLM2) that specifies an essential radio frequency data link service 1700 for aircraft and ground stations in worldwide civil aviation air 1701 traffic management. The VDLM2 link type is "multicast capable" 1702 [RFC4861], but with considerable differences from common multicast 1703 links such as Ethernet and IEEE 802.11. 1705 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 1706 magnitude less than most modern wireless networking gear. Second, 1707 due to the low available link bandwidth only VDLM2 ground stations 1708 (i.e., and not aircraft) are permitted to send broadcasts, and even 1709 so only as compact layer 2 "beacons". Third, aircraft employ the 1710 services of ground stations by performing unicast RS/RA exchanges 1711 upon receipt of beacons instead of listening for multicast RA 1712 messages and/or sending multicast RS messages. 1714 This beacon-oriented unicast RS/RA approach is necessary to conserve 1715 the already-scarce available link bandwidth. Moreover, since the 1716 numbers of beaconing ground stations operating within a given spatial 1717 range must be kept as sparse as possible, it would not be feasible to 1718 have different classes of ground stations within the same region 1719 observing different protocols. It is therefore highly desirable that 1720 all ground stations observe a common language of RS/RA as specified 1721 in this document. 1723 Note that links of this nature may benefit from compression 1724 techniques that reduce the bandwidth necessary for conveying the same 1725 amount of data. The IETF lpwan working group is considering possible 1726 alternatives: [https://datatracker.ietf.org/wg/lpwan/documents]. 1728 Appendix C. MN / AR Isolation Through L2 Address Mapping 1730 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 1731 unicast link-scoped IPv6 destination address. However, IPv6 ND 1732 messaging should be coordinated between the MN and AR only without 1733 invoking other nodes on the ANET. This implies that MN / AR control 1734 messaging should be isolated and not overheard by other nodes on the 1735 link. 1737 To support MN / AR isolation on some ANET links, ARs can maintain an 1738 OMNI-specific unicast L2 address ("MSADDR"). For Ethernet-compatible 1739 ANETs, this specification reserves one Ethernet unicast address TBD2 1740 (see: Section 19). For non-Ethernet statically-addressed ANETs, 1741 MSADDR is reserved per the assigned numbers authority for the ANET 1742 addressing space. For still other ANETs, MSADDR may be dynamically 1743 discovered through other means, e.g., L2 beacons. 1745 MNs map the L3 addresses of all IPv6 ND messages they send (i.e., 1746 both multicast and unicast) to MSADDR instead of to an ordinary 1747 unicast or multicast L2 address. In this way, all of the MN's IPv6 1748 ND messages will be received by ARs that are configured to accept 1749 packets destined to MSADDR. Note that multiple ARs on the link could 1750 be configured to accept packets destined to MSADDR, e.g., as a basis 1751 for supporting redundancy. 1753 Therefore, ARs must accept and process packets destined to MSADDR, 1754 while all other devices must not process packets destined to MSADDR. 1755 This model has well-established operational experience in Proxy 1756 Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 1758 Appendix D. Change Log 1760 << RFC Editor - remove prior to publication >> 1762 Differences from draft-templin-6man-omni-interface-18 to draft- 1763 templin-6man-omni-interface-19: 1765 o SEND/CGA. 1767 Differences from draft-templin-6man-omni-interface-17 to draft- 1768 templin-6man-omni-interface-18: 1770 o Teredo 1772 Differences from draft-templin-6man-omni-interface-14 to draft- 1773 templin-6man-omni-interface-15: 1775 o Prefix length discussions removed. 1777 Differences from draft-templin-6man-omni-interface-12 to draft- 1778 templin-6man-omni-interface-13: 1780 o Teredo 1782 Differences from draft-templin-6man-omni-interface-11 to draft- 1783 templin-6man-omni-interface-12: 1785 o Major simplifications and clarifications on MTU and fragmentation. 1787 o Document now updates RFC4443 and RFC8201. 1789 Differences from draft-templin-6man-omni-interface-10 to draft- 1790 templin-6man-omni-interface-11: 1792 o Removed /64 assumption, resulting in new OMNI address format. 1794 Differences from draft-templin-6man-omni-interface-07 to draft- 1795 templin-6man-omni-interface-08: 1797 o OMNI MNs in the open Internet 1799 Differences from draft-templin-6man-omni-interface-06 to draft- 1800 templin-6man-omni-interface-07: 1802 o Brought back L2 MSADDR mapping text for MN / AR isolation based on 1803 L2 addressing. 1805 o Expanded "Transition Considerations". 1807 Differences from draft-templin-6man-omni-interface-05 to draft- 1808 templin-6man-omni-interface-06: 1810 o Brought back OMNI option "R" flag, and discussed its use. 1812 Differences from draft-templin-6man-omni-interface-04 to draft- 1813 templin-6man-omni-interface-05: 1815 o Transition considerations, and overhaul of RS/RA addressing with 1816 the inclusion of MSE addresses within the OMNI option instead of 1817 as RS/RA addresses (developed under FAA SE2025 contract number 1818 DTFAWA-15-D-00030). 1820 Differences from draft-templin-6man-omni-interface-02 to draft- 1821 templin-6man-omni-interface-03: 1823 o Added "advisory PTB messages" under FAA SE2025 contract number 1824 DTFAWA-15-D-00030. 1826 Differences from draft-templin-6man-omni-interface-01 to draft- 1827 templin-6man-omni-interface-02: 1829 o Removed "Primary" flag and supporting text. 1831 o Clarified that "Router Lifetime" applies to each ANET interface 1832 independently, and that the union of all ANET interface Router 1833 Lifetimes determines MSE lifetime. 1835 Differences from draft-templin-6man-omni-interface-00 to draft- 1836 templin-6man-omni-interface-01: 1838 o "All-MSEs" OMNI LLA defined. Also reserved fe80::ff00:0000/104 1839 for future use (most likely as "pseudo-multicast"). 1841 o Non-normative discussion of alternate OMNI LLA construction form 1842 made possible if the 64-bit assumption were relaxed. 1844 Differences from draft-templin-atn-aero-interface-21 to draft- 1845 templin-6man-omni-interface-00: 1847 o Minor clarification on Type-2 ifIndex-tuple encoding. 1849 o Draft filename change (replaces draft-templin-atn-aero-interface). 1851 Differences from draft-templin-atn-aero-interface-20 to draft- 1852 templin-atn-aero-interface-21: 1854 o OMNI option format 1856 o MTU 1858 Differences from draft-templin-atn-aero-interface-19 to draft- 1859 templin-atn-aero-interface-20: 1861 o MTU 1863 Differences from draft-templin-atn-aero-interface-18 to draft- 1864 templin-atn-aero-interface-19: 1866 o MTU 1868 Differences from draft-templin-atn-aero-interface-17 to draft- 1869 templin-atn-aero-interface-18: 1871 o MTU and RA configuration information updated. 1873 Differences from draft-templin-atn-aero-interface-16 to draft- 1874 templin-atn-aero-interface-17: 1876 o New "Primary" flag in OMNI option. 1878 Differences from draft-templin-atn-aero-interface-15 to draft- 1879 templin-atn-aero-interface-16: 1881 o New note on MSE OMNI LLA uniqueness assurance. 1883 o General cleanup. 1885 Differences from draft-templin-atn-aero-interface-14 to draft- 1886 templin-atn-aero-interface-15: 1888 o General cleanup. 1890 Differences from draft-templin-atn-aero-interface-13 to draft- 1891 templin-atn-aero-interface-14: 1893 o General cleanup. 1895 Differences from draft-templin-atn-aero-interface-12 to draft- 1896 templin-atn-aero-interface-13: 1898 o Minor re-work on "Notify-MSE" (changed to Notification ID). 1900 Differences from draft-templin-atn-aero-interface-11 to draft- 1901 templin-atn-aero-interface-12: 1903 o Removed "Request/Response" OMNI option formats. Now, there is 1904 only one OMNI option format that applies to all ND messages. 1906 o Added new OMNI option field and supporting text for "Notify-MSE". 1908 Differences from draft-templin-atn-aero-interface-10 to draft- 1909 templin-atn-aero-interface-11: 1911 o Changed name from "aero" to "OMNI" 1913 o Resolved AD review comments from Eric Vyncke (posted to atn list) 1915 Differences from draft-templin-atn-aero-interface-09 to draft- 1916 templin-atn-aero-interface-10: 1918 o Renamed ARO option to AERO option 1920 o Re-worked Section 13 text to discuss proactive NUD. 1922 Differences from draft-templin-atn-aero-interface-08 to draft- 1923 templin-atn-aero-interface-09: 1925 o Version and reference update 1927 Differences from draft-templin-atn-aero-interface-07 to draft- 1928 templin-atn-aero-interface-08: 1930 o Removed "Classic" and "MS-enabled" link model discussion 1932 o Added new figure for MN/AR/MSE model. 1934 o New Section on "Detecting and responding to MSE failure". 1936 Differences from draft-templin-atn-aero-interface-06 to draft- 1937 templin-atn-aero-interface-07: 1939 o Removed "nonce" field from AR option format. Applications that 1940 require a nonce can include a standard nonce option if they want 1941 to. 1943 o Various editorial cleanups. 1945 Differences from draft-templin-atn-aero-interface-05 to draft- 1946 templin-atn-aero-interface-06: 1948 o New Appendix C on "VDL Mode 2 Considerations" 1950 o New Appendix D on "RS/RA Messaging as a Single Standard API" 1952 o Various significant updates in Section 5, 10 and 12. 1954 Differences from draft-templin-atn-aero-interface-04 to draft- 1955 templin-atn-aero-interface-05: 1957 o Introduced RFC6543 precedent for focusing IPv6 ND messaging to a 1958 reserved unicast link-layer address 1960 o Introduced new IPv6 ND option for Aero Registration 1962 o Specification of MN-to-MSE message exchanges via the ANET access 1963 router as a proxy 1965 o IANA Considerations updated to include registration requests and 1966 set interim RFC4727 option type value. 1968 Differences from draft-templin-atn-aero-interface-03 to draft- 1969 templin-atn-aero-interface-04: 1971 o Removed MNP from aero option format - we already have RIOs and 1972 PIOs, and so do not need another option type to include a Prefix. 1974 o Clarified that the RA message response must include an aero option 1975 to indicate to the MN that the ANET provides a MS. 1977 o MTU interactions with link adaptation clarified. 1979 Differences from draft-templin-atn-aero-interface-02 to draft- 1980 templin-atn-aero-interface-03: 1982 o Sections re-arranged to match RFC4861 structure. 1984 o Multiple aero interfaces 1986 o Conceptual sending algorithm 1988 Differences from draft-templin-atn-aero-interface-01 to draft- 1989 templin-atn-aero-interface-02: 1991 o Removed discussion of encapsulation (out of scope) 1993 o Simplified MTU section 1995 o Changed to use a new IPv6 ND option (the "aero option") instead of 1996 S/TLLAO 1998 o Explained the nature of the interaction between the mobility 1999 management service and the air interface 2001 Differences from draft-templin-atn-aero-interface-00 to draft- 2002 templin-atn-aero-interface-01: 2004 o Updates based on list review comments on IETF 'atn' list from 2005 4/29/2019 through 5/7/2019 (issue tracker established) 2007 o added list of opportunities afforded by the single virtual link 2008 model 2010 o added discussion of encapsulation considerations to Section 6 2012 o noted that DupAddrDetectTransmits is set to 0 2014 o removed discussion of IPv6 ND options for prefix assertions. The 2015 aero address already includes the MNP, and there are many good 2016 reasons for it to continue to do so. Therefore, also including 2017 the MNP in an IPv6 ND option would be redundant. 2019 o Significant re-work of "Router Discovery" section. 2021 o New Appendix B on Prefix Length considerations 2023 First draft version (draft-templin-atn-aero-interface-00): 2025 o Draft based on consensus decision of ICAO Working Group I Mobility 2026 Subgroup March 22, 2019. 2028 Authors' Addresses 2030 Fred L. Templin (editor) 2031 The Boeing Company 2032 P.O. Box 3707 2033 Seattle, WA 98124 2034 USA 2036 Email: fltemplin@acm.org 2038 Tony Whyman 2039 MWA Ltd c/o Inmarsat Global Ltd 2040 99 City Road 2041 London EC1Y 1AX 2042 England 2044 Email: tony.whyman@mccallumwhyman.com