idnits 2.17.1 draft-templin-6man-omni-interface-98.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2021) is 1134 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) == Missing Reference: 'ULA' is mentioned on line 2862, but not defined -- Looks like a reference, but probably isn't: '00' on line 2256 -- Looks like a reference, but probably isn't: '63' on line 2256 -- Looks like a reference, but probably isn't: '03' on line 2239 -- Looks like a reference, but probably isn't: '04' on line 2240 -- Looks like a reference, but probably isn't: '07' on line 2240 -- Looks like a reference, but probably isn't: '28' on line 2241 -- Looks like a reference, but probably isn't: '31' on line 2241 -- Looks like a reference, but probably isn't: '64' on line 2258 -- Looks like a reference, but probably isn't: '65' on line 2258 -- Looks like a reference, but probably isn't: '66' on line 2258 -- Looks like a reference, but probably isn't: '1' on line 2326 -- Looks like a reference, but probably isn't: '2' on line 2328 -- Looks like a reference, but probably isn't: '3' on line 2328 == Missing Reference: 'RFCXXXX' is mentioned on line 3775, but not defined -- Looks like a reference, but probably isn't: '67' on line 4364 -- Looks like a reference, but probably isn't: '70' on line 4365 -- Looks like a reference, but probably isn't: '76' on line 4365 == Unused Reference: 'I-D.ietf-tsvwg-udp-options' is defined on line 4046, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-dhcpv6-ndopt' is defined on line 4050, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-lla-type' is defined on line 4055, but no explicit reference was found in the text == Unused Reference: 'RFC2225' is defined on line 4101, but no explicit reference was found in the text == Unused Reference: 'RFC2529' is defined on line 4121, but no explicit reference was found in the text == Unused Reference: 'RFC3879' is defined on line 4163, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 4172, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 4186, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 4215, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 4252, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 4329, but no explicit reference was found in the text == Outdated reference: A later version (-37) exists of draft-ietf-drip-rid-06 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-19 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-09 == Outdated reference: A later version (-99) exists of draft-templin-intarea-6706bis-87 -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 22 warnings (==), 19 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 Updates: rfc1191, rfc4443, rfc7526, A. Whyman 5 rfc8201 (if approved) MWA Ltd c/o Inmarsat Global Ltd 6 Intended status: Standards Track March 18, 2021 7 Expires: September 19, 2021 9 Transmission of IP Packets over Overlay Multilink Network (OMNI) 10 Interfaces 11 draft-templin-6man-omni-interface-98 13 Abstract 15 Mobile nodes (e.g., aircraft of various configurations, terrestrial 16 vehicles, seagoing vessels, enterprise wireless devices, etc.) 17 communicate with networked correspondents over multiple access 18 network data links and configure mobile routers to connect end user 19 networks. A multilink interface specification is therefore needed 20 for coordination with the network-based mobility service. This 21 document specifies the transmission of IP packets over Overlay 22 Multilink Network (OMNI) Interfaces. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 19, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 61 4. Overlay Multilink Network (OMNI) Interface Model . . . . . . 10 62 5. OMNI Interface Maximum Transmission Unit (MTU) . . . . . . . 16 63 6. The OMNI Adaptation Layer (OAL) . . . . . . . . . . . . . . . 17 64 6.1. OAL Source Encapsulation and Fragmentation . . . . . . . 17 65 6.2. OAL *NET Encapsulation and Re-Encapsulation . . . . . . . 22 66 6.3. OAL Destination Decapsulation and Reassembly . . . . . . 23 67 6.4. OAL Header Compression . . . . . . . . . . . . . . . . . 24 68 6.5. OAL Fragment Identification Window Maintenance . . . . . 26 69 6.6. OAL Fragment Retransmission . . . . . . . . . . . . . . . 27 70 6.7. OAL MTU Feedback Messaging . . . . . . . . . . . . . . . 28 71 6.8. OAL Requirements . . . . . . . . . . . . . . . . . . . . 30 72 6.9. OAL Fragmentation Security Implications . . . . . . . . . 31 73 6.10. OAL Super-Packets . . . . . . . . . . . . . . . . . . . . 32 74 7. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 34 75 8. Link-Local Addresses (LLAs) . . . . . . . . . . . . . . . . . 34 76 9. Unique-Local Addresses (ULAs) . . . . . . . . . . . . . . . . 35 77 10. Global Unicast Addresses (GUAs) . . . . . . . . . . . . . . . 37 78 11. Node Identification . . . . . . . . . . . . . . . . . . . . . 38 79 12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 38 80 12.1. Sub-Options . . . . . . . . . . . . . . . . . . . . . . 40 81 12.1.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 42 82 12.1.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 42 83 12.1.3. Interface Attributes (Type 1) . . . . . . . . . . . 43 84 12.1.4. Interface Attributes (Type 2) . . . . . . . . . . . 44 85 12.1.5. Traffic Selector . . . . . . . . . . . . . . . . . . 48 86 12.1.6. MS-Register . . . . . . . . . . . . . . . . . . . . 49 87 12.1.7. MS-Release . . . . . . . . . . . . . . . . . . . . . 50 88 12.1.8. Geo Coordinates . . . . . . . . . . . . . . . . . . 50 89 12.1.9. Dynamic Host Configuration Protocol for IPv6 90 (DHCPv6) Message . . . . . . . . . . . . . . . . . . 51 91 12.1.10. Host Identity Protocol (HIP) Message . . . . . . . . 52 92 12.1.11. Reassembly Limit . . . . . . . . . . . . . . . . . . 53 93 12.1.12. Fragmentation Report . . . . . . . . . . . . . . . . 54 94 12.1.13. Node Identification . . . . . . . . . . . . . . . . 56 95 12.1.14. Sub-Type Extension . . . . . . . . . . . . . . . . . 57 96 13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 60 97 14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 61 98 14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 61 99 14.2. MN<->AR Traffic Loop Prevention . . . . . . . . . . . . 62 100 15. Router Discovery and Prefix Registration . . . . . . . . . . 62 101 15.1. Router Discovery in IP Multihop and IPv4-Only Networks . 67 102 15.2. MS-Register and MS-Release List Processing . . . . . . . 68 103 15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 70 104 16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 72 105 17. AR and MSE Resilience . . . . . . . . . . . . . . . . . . . . 72 106 18. Detecting and Responding to MSE Failures . . . . . . . . . . 72 107 19. Transition Considerations . . . . . . . . . . . . . . . . . . 73 108 20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 73 109 21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 75 110 22. (H)HITs and Temporary ULAs . . . . . . . . . . . . . . . . . 76 111 23. Address Selection . . . . . . . . . . . . . . . . . . . . . . 77 112 24. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 77 113 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 114 25.1. "IEEE 802 Numbers" Registry . . . . . . . . . . . . . . 78 115 25.2. "IPv6 Neighbor Discovery Option Formats" Registry . . . 78 116 25.3. "Ethernet Numbers" Registry . . . . . . . . . . . . . . 78 117 25.4. "ICMPv6 Code Fields: Type 2 - Packet Too Big" Registry . 78 118 25.5. "OMNI Option Sub-Type Values" (New Registry) . . . . . . 78 119 25.6. "OMNI Node Identification ID-Type Values" (New Registry) 79 120 25.7. "OMNI Option Sub-Type Extension Values" (New Registry) . 80 121 25.8. "OMNI RFC4380 UDP/IP Header Option" (New Registry) . . . 80 122 25.9. "OMNI RFC6081 UDP/IP Trailer Option" (New Registry) . . 80 123 25.10. Additional Considerations . . . . . . . . . . . . . . . 81 124 26. Security Considerations . . . . . . . . . . . . . . . . . . . 81 125 27. Implementation Status . . . . . . . . . . . . . . . . . . . . 82 126 28. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 83 127 29. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 128 29.1. Normative References . . . . . . . . . . . . . . . . . . 84 129 29.2. Informative References . . . . . . . . . . . . . . . . . 86 130 Appendix A. Interface Attribute Preferences Bitmap Encoding . . 93 131 Appendix B. VDL Mode 2 Considerations . . . . . . . . . . . . . 95 132 Appendix C. MN / AR Isolation Through L2 Address Mapping . . . . 96 133 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 96 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99 136 1. Introduction 138 Mobile Nodes (MNs) (e.g., aircraft of various configurations, 139 terrestrial vehicles, seagoing vessels, enterprise wireless devices, 140 pedestrians with cellphones, etc.) often have multiple interface 141 connections to wireless and/or wired-line data links used for 142 communicating with networked correspondents. These data links may 143 have diverse performance, cost and availability properties that can 144 change dynamically according to mobility patterns, flight phases, 145 proximity to infrastructure, etc. MNs coordinate their data links in 146 a discipline known as "multilink", in which a single virtual 147 interface is configured over the node's underlying interface 148 connections to the data links. 150 The MN configures a virtual interface (termed the "Overlay Multilink 151 Network Interface (OMNI)") as a thin layer over the underlying 152 interfaces. The OMNI interface is therefore the only interface 153 abstraction exposed to the IP layer and behaves according to the Non- 154 Broadcast, Multiple Access (NBMA) interface principle, while 155 underlying interfaces appear as link layer communication channels in 156 the architecture. The OMNI interface internally employs the "OMNI 157 Adaptation Layer (OAL)" to ensure that original IP packets are 158 delivered without loss due to size restrictions. The OMNI interface 159 connects to a virtual overlay service known as the "OMNI link". The 160 OMNI link spans one or more Internetworks that may include private- 161 use infrastructures and/or the global public Internet itself. 163 Each MN receives a Mobile Network Prefix (MNP) for numbering 164 downstream-attached End User Networks (EUNs) independently of the 165 access network data links selected for data transport. The MN 166 performs router discovery over the OMNI interface (i.e., similar to 167 IPv6 customer edge routers [RFC7084]) and acts as a mobile router on 168 behalf of its EUNs. The router discovery process is iterated over 169 each of the OMNI interface's underlying interfaces in order to 170 register per-link parameters (see Section 15). 172 The OMNI interface provides a multilink nexus for exchanging inbound 173 and outbound traffic via the correct underlying interface(s). The IP 174 layer sees the OMNI interface as a point of connection to the OMNI 175 link. Each OMNI link has one or more associated Mobility Service 176 Prefixes (MSPs), which are typically IP Global Unicast Address (GUA) 177 prefixes from which MNPs are derived. If there are multiple OMNI 178 links, the IPv6 layer will see multiple OMNI interfaces. 180 MNs may connect to multiple distinct OMNI links within the same OMNI 181 domain by configuring multiple OMNI interfaces, e.g., omni0, omni1, 182 omni2, etc. Each OMNI interface is configured over a set of 183 underlying interfaces and provides a nexus for Safety-Based Multilink 184 (SBM) operation. Each OMNI interface within the same OMNI domain 185 configures a common ULA prefix [ULA]::/48, and configures a unique 186 16-bit Subnet ID '*' to construct the sub-prefix [ULA*]::/64 (see: 187 Section 9). The IP layer applies SBM routing to select an OMNI 188 interface, which then applies Performance-Based Multilink (PBM) to 189 select the correct underlying interface. Applications can apply 190 Segment Routing [RFC8402] to select independent SBM topologies for 191 fault tolerance. 193 The OMNI interface interacts with a network-based Mobility Service 194 (MS) through IPv6 Neighbor Discovery (ND) control message exchanges 195 [RFC4861]. The MS provides Mobility Service Endpoints (MSEs) that 196 track MN movements and represent their MNPs in a global routing or 197 mapping system. 199 Many OMNI use cases have been proposed. In particular, the 200 International Civil Aviation Organization (ICAO) Working Group-I 201 Mobility Subgroup is developing a future Aeronautical 202 Telecommunications Network with Internet Protocol Services (ATN/IPS) 203 and has issued a liaison statement requesting IETF adoption [ATN] in 204 support of ICAO Document 9896 [ATN-IPS]. The IETF IP Wireless Access 205 in Vehicular Environments (ipwave) working group has further included 206 problem statement and use case analysis for OMNI in a document now in 207 AD evaluation for RFC publication 208 [I-D.ietf-ipwave-vehicular-networking]. Still other communities of 209 interest include AEEC, RTCA Special Committee 228 (SC-228) and NASA 210 programs that examine commercial aviation, Urban Air Mobility (UAM) 211 and Unmanned Air Systems (UAS). Pedestrians with handheld devices 212 represent another large class of potential OMNI users. 214 This document specifies the transmission of IP packets and MN/MS 215 control messages over OMNI interfaces. The OMNI interface supports 216 either IP protocol version (i.e., IPv4 [RFC0791] or IPv6 [RFC8200]) 217 as the network layer in the data plane, while using IPv6 ND messaging 218 as the control plane independently of the data plane IP protocol(s). 219 The OAL operates as a sublayer between L3 and L2 based on IPv6 220 encapsulation [RFC2473] as discussed in the following sections. OMNI 221 interfaces enable Multilink, Mobility, Multihop, Multicast and MTU 222 services (i.e., the "five M's"), with provisions for both Vehicle-to- 223 Infrastructure (V2I) communications and Vehicle-to-Vehicle (V2V) 224 communications outside the context of infrastructure. 226 2. Terminology 228 The terminology in the normative references applies; especially, the 229 terms "link" and "interface" are the same as defined in the IPv6 230 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 231 Additionally, this document assumes the following IPv6 ND message 232 types: Router Solicitation (RS), Router Advertisement (RA), Neighbor 233 Solicitation (NS), Neighbor Advertisement (NA) and Redirect. 235 The Protocol Constants defined in Section 10 of [RFC4861] are used in 236 their same format and meaning in this document. The terms "All- 237 Routers multicast", "All-Nodes multicast" and "Subnet-Router anycast" 238 are the same as defined in [RFC4291] (with Link-Local scope assumed). 240 The term "IP" is used to refer collectively to either Internet 241 Protocol version (i.e., IPv4 [RFC0791] or IPv6 [RFC8200]) when a 242 specification at the layer in question applies equally to either 243 version. 245 The following terms are defined within the scope of this document: 247 Mobile Node (MN) 248 an end system with a mobile router having multiple distinct 249 upstream data link connections that are grouped together in one or 250 more logical units. The MN's data link connection parameters can 251 change over time due to, e.g., node mobility, link quality, etc. 252 The MN further connects a downstream-attached End User Network 253 (EUN). The term MN used here is distinct from uses in other 254 documents, and does not imply a particular mobility protocol. 256 End User Network (EUN) 257 a simple or complex downstream-attached mobile network that 258 travels with the MN as a single logical unit. The IP addresses 259 assigned to EUN devices remain stable even if the MN's upstream 260 data link connections change. 262 Mobility Service (MS) 263 a mobile routing service that tracks MN movements and ensures that 264 MNs remain continuously reachable even across mobility events. 265 Specific MS details are out of scope for this document. 267 Mobility Service Endpoint (MSE) 268 an entity in the MS (either singular or aggregate) that 269 coordinates the mobility events of one or more MN. 271 Mobility Service Prefix (MSP) 272 an aggregated IP Global Unicast Address (GUA) prefix (e.g., 273 2001:db8::/32, 192.0.2.0/24, etc.) assigned to the OMNI link and 274 from which more-specific Mobile Network Prefixes (MNPs) are 275 delegated. OMNI link administrators typically obtain MSPs from an 276 Internet address registry, however private-use prefixes can 277 alternatively be used subject to certain limitations (see: 278 Section 10). OMNI links that connect to the global Internet 279 advertise their MSPs to their interdomain routing peers. 281 Mobile Network Prefix (MNP) 282 a longer IP prefix delegated from an MSP (e.g., 283 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and assigned to a MN. 284 MNs sub-delegate the MNP to devices located in EUNs. 286 Access Network (ANET) 287 a data link service network (e.g., an aviation radio access 288 network, satellite service provider network, cellular operator 289 network, WiFi network, etc.) that connects MNs. Physical and/or 290 data link level security is assumed, and sometimes referred to as 291 "protected spectrum". Private enterprise networks and ground 292 domain aviation service networks may provide multiple secured IP 293 hops between the MN's point of connection and the nearest Access 294 Router. 296 Access Router (AR) 297 a router in the ANET for connecting MNs to correspondents in 298 outside Internetworks. The AR may be located on the same physical 299 link as the MN, or may be located multiple IP hops away. In the 300 latter case, the MN uses encapsulation to communicate with the AR 301 as though it were on the same physical link. 303 ANET interface 304 a MN's attachment to a link in an ANET. 306 Internetwork (INET) 307 a connected network region with a coherent IP addressing plan that 308 provides transit forwarding services between ANETs and nodes that 309 connect directly to the open INET via unprotected media. No 310 physical and/or data link level security is assumed, therefore 311 security must be applied by upper layers. The global public 312 Internet itself is an example. 314 INET interface 315 a node's attachment to a link in an INET. 317 *NET 318 a "wildcard" term used when a given specification applies equally 319 to both ANET and INET cases. 321 OMNI link 322 a Non-Broadcast, Multiple Access (NBMA) virtual overlay configured 323 over one or more INETs and their connected ANETs. An OMNI link 324 can comprise multiple INET segments joined by bridges the same as 325 for any link; the addressing plans in each segment may be mutually 326 exclusive and managed by different administrative entities. 328 OMNI interface 329 a node's attachment to an OMNI link, and configured over one or 330 more underlying *NET interfaces. If there are multiple OMNI links 331 in an OMNI domain, a separate OMNI interface is configured for 332 each link. 334 OMNI Adaptation Layer (OAL) 335 an OMNI interface sublayer service whereby original IP packets 336 admitted into the interface are wrapped in an IPv6 header and 337 subject to fragmentation and reassembly. The OAL is also 338 responsible for generating MTU-related control messages as 339 necessary, and for providing addressing context for spanning 340 multiple segments of a bridged OMNI link. 342 original IP packet 343 a whole IP packet or fragment admitted into the OMNI interface by 344 the network layer prior to OAL encapsulation and fragmentation, or 345 an IP packet delivered to the network layer by the OMNI interface 346 following OAL decapsulation and reassembly. 348 OAL packet 349 an original IP packet encapsulated in OAL headers and trailers 350 before OAL fragmentation, or following OAL reassembly. 352 OAL fragment 353 a portion of an OAL packet following fragmentation but prior to 354 *NET encapsulation, or following *NET encapsulation but prior to 355 OAL reassembly. 357 (OAL) carrier packet 358 an encapsulated packet containing an OAL fragment following *NET 359 encapsulation or prior to *NET decapsulation. OAL sources and 360 destinations exchange carrier packets over underlying interfaces, 361 and may be separated by one or more OAL intermediate nodes. OAL 362 intermediate nodes may perform re-encapsulation on carrier packets 363 by removing the *NET headers of the first hop network and 364 replacing them with new *NET headers for the next hop network. 366 OMNI Option 367 an IPv6 Neighbor Discovery option providing multilink parameters 368 for the OMNI interface as specified in Section 12. 370 Mobile Network Prefix Link Local Address (MNP-LLA) 371 an IPv6 Link Local Address that embeds the most significant 64 372 bits of an MNP in the lower 64 bits of fe80::/64, as specified in 373 Section 8. 375 Mobile Network Prefix Unique Local Address (MNP-ULA) 376 an IPv6 Unique-Local Address derived from an MNP-LLA. 378 Administrative Link Local Address (ADM-LLA) 379 an IPv6 Link Local Address that embeds a 32-bit administratively- 380 assigned identification value in the lower 32 bits of fe80::/96, 381 as specified in Section 8. 383 Administrative Unique Local Address (ADM-ULA) 384 an IPv6 Unique-Local Address derived from an ADM-LLA. 386 Multilink 387 an OMNI interface's manner of managing diverse underlying 388 interface connections to data links as a single logical unit. The 389 OMNI interface provides a single unified interface to upper 390 layers, while underlying interface selections are performed on a 391 per-packet basis considering factors such as DSCP, flow label, 392 application policy, signal quality, cost, etc. Multilinking 393 decisions are coordinated in both the outbound (i.e. MN to 394 correspondent) and inbound (i.e., correspondent to MN) directions. 396 Multihop 397 an iterative relaying of IP packets between MNs over an OMNI 398 underlying interface technology (such as omnidirectional wireless) 399 without support of fixed infrastructure. Multihop services entail 400 node-to-node relaying within a Mobile/Vehicular Ad-hoc Network 401 (MANET/VANET) for MN-to-MN communications and/or for "range 402 extension" where MNs within range of communications infrastructure 403 elements provide forwarding services for other MNs. 405 L2 406 The second layer in the OSI network model. Also known as "layer- 407 2", "link-layer", "sub-IP layer", "data link layer", etc. 409 L3 410 The third layer in the OSI network model. Also known as "layer- 411 3", "network-layer", "IP layer", etc. 413 underlying interface 414 a *NET interface over which an OMNI interface is configured. The 415 OMNI interface is seen as a L3 interface by the IP layer, and each 416 underlying interface is seen as a L2 interface by the OMNI 417 interface. The underlying interface either connects directly to 418 the physical communications media or coordinates with another node 419 where the physical media is hosted. 421 Mobility Service Identification (MSID) 422 Each MSE and AR is assigned a unique 32-bit Identification (MSID) 423 (see: Section 8). IDs are assigned according to MS-specific 424 guidelines (e.g., see: [I-D.templin-intarea-6706bis]). 426 Safety-Based Multilink (SBM) 427 A means for ensuring fault tolerance through redundancy by 428 connecting multiple affiliated OMNI interfaces to independent 429 routing topologies (i.e., multiple independent OMNI links). 431 Performance Based Multilink (PBM) 432 A means for selecting underlying interface(s) for packet 433 transmission and reception within a single OMNI interface. 435 OMNI Domain 436 The set of all SBM/PBM OMNI links that collectively provides 437 services for a common set of MSPs. Each OMNI domain consists of a 438 set of affiliated OMNI links that all configure the same ::/48 ULA 439 prefix with a unique 16-bit Subnet ID as discussed in Section 9. 441 3. Requirements 443 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 444 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 445 "OPTIONAL" in this document are to be interpreted as described in BCP 446 14 [RFC2119][RFC8174] when, and only when, they appear in all 447 capitals, as shown here. 449 An implementation is not required to internally use the architectural 450 constructs described here so long as its external behavior is 451 consistent with that described in this document. 453 4. Overlay Multilink Network (OMNI) Interface Model 455 An OMNI interface is a virtual interface configured over one or more 456 underlying interfaces, which may be physical (e.g., an aeronautical 457 radio link, etc.) or virtual (e.g., an Internet or higher-layer 458 "tunnel"). The OMNI interface architectural layering model is the 459 same as in [RFC5558][RFC7847], and augmented as shown in Figure 1. 460 The IP layer therefore sees the OMNI interface as a single L3 461 interface nexus for multiple underlying interfaces that appear as L2 462 communication channels in the architecture. 464 +----------------------------+ 465 | Upper Layer Protocol | 466 Session-to-IP +---->| | 467 Address Binding | +----------------------------+ 468 +---->| IP (L3) | 469 IP Address +---->| | 470 Binding | +----------------------------+ 471 +---->| OMNI Interface | 472 Logical-to- +---->| (OMNI Adaptation Layer) | 473 Physical | +----------------------------+ 474 Interface +---->| L2 | L2 | | L2 | 475 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 476 +------+------+ +------+ 477 | L1 | L1 | | L1 | 478 | | | | | 479 +------+------+ +------+ 481 Figure 1: OMNI Interface Architectural Layering Model 483 Each underlying interface provides an L2/L1 abstraction according to 484 one of the following models: 486 o INET interfaces connect to an INET either natively or through one 487 or several IPv4 Network Address Translators (NATs). Native INET 488 interfaces have global IP addresses that are reachable from any 489 INET correspondent. NATed INET interfaces typically have private 490 IP addresses and connect to a private network behind one or more 491 NATs that provide INET access. 493 o ANET interfaces connect to a protected ANET that is separated from 494 the open INET by an AR acting as a proxy. The ANET interface may 495 be either on the same L2 link segment as the AR, or separated from 496 the AR by multiple IP hops. 498 o VPNed interfaces use security encapsulation over a *NET to a 499 Virtual Private Network (VPN) gateway. Other than the link-layer 500 encapsulation format, VPNed interfaces behave the same as for 501 Direct interfaces. 503 o Direct (aka "point-to-point") interfaces connect directly to a 504 peer without crossing any *NET paths. An example is a line-of- 505 sight link between a remote pilot and an unmanned aircraft. 507 The OMNI interface forwards original IP packets from the network 508 layer (L3) using the OMNI Adaptation Layer (OAL) (see: Section 5) as 509 an encapsulation and fragmentation sublayer service. This "OAL 510 source" then further encapsulates the resulting OAL packets/fragments 511 in *NET headers to create OAL carrier packets for transmission over 512 underlying interfaces (L2/L1). The target OMNI interface receives 513 the carrier packets from underlying interfaces (L1/L2) and discards 514 the *NET headers. If the resulting OAL packets/fragments are 515 addressed to itself, the OMNI interface acts as an "OAL destination" 516 and performs reassembly if necessary, discards the OAL encapsulation, 517 and delivers the original IP packet to the network layer (L3). If 518 the OAL fragments are addressed to another node, the OMNI interface 519 instead acts as an "OAL intermediate node" by re-encapsulating in new 520 *NET headers and forwarding the new carrier packets over an 521 underlying interface without reassembling or discarding the OAL 522 encapsulation. The OAL source and OAL destination are seen as 523 "neighbors" on the OMNI link, while OAL intermediate nodes are seen 524 as "bridges". 526 The OMNI interface can send/receive original IP packets to/from 527 underlying interfaces while including/omitting various encapsulations 528 including OAL, UDP, IP and L2. The network layer can also access the 529 underlying interfaces directly while bypassing the OMNI interface 530 entirely when necessary. This architectural flexibility may be 531 beneficial for underlying interfaces (e.g., some aviation data links) 532 for which encapsulation overhead may be a primary consideration. 533 OMNI interfaces that send original IP packets directly over 534 underlying interfaces without invoking the OAL can only reach peers 535 located on the same OMNI link segment. However, an ANET proxy that 536 receives the original IP packet can forward it further by performing 537 OAL encapsulation with source set to its own address and destination 538 set to the OAL destination corresponding to the final destination 539 (i.e., even if the OAL destination is on a different OMNI link 540 segment). 542 Original IP packets sent directly over underlying interfaces are 543 subject to the same path MTU related issues as for any 544 Internetworking path, and do not include per-packet identifications 545 that can be used for data origin verification and/or link-layer 546 retransmissions. Original IP packets presented directly to an 547 underlying interface that exceed the underlying network path MTU are 548 dropped with an ordinary ICMPv6 Packet Too Big (PTB) message 549 returned. These PTB messages are subject to loss [RFC2923] the same 550 as for any non-OMNI IP interface. 552 The OMNI interface encapsulation/decapsulation layering possibilities 553 are shown in Figure 2 below. In the figure, imaginary vertical lines 554 drawn between the Network Layer and Underlying interfaces denote the 555 encapsulation/decapsulation layering combinations possible. Common 556 combinations include NULL, IP, OMNI/IP, OMNI/UDP/IP, OMNI/UDP/IP/L2, 557 OMNI/OAL/UDP/IP, OMNI/OAL/UDP/L2, etc. 559 +------------------------------------------------------------+ 560 | Network Layer | 561 +--+---------------------------------------------------------+ 562 | OMNI Interface | 563 +--------------------------+------------------------------+ 564 | OAL Encaps/Decaps | 565 +------------------------------+ 566 | OAL Frag/Reass | 567 +------------+---------------+--------------+ 568 | UDP Encaps/Decaps/Compress | 569 +----+---+------------+--------+--+ +--------+ 570 | IP E/D | | IP E/D | | IP E/D | 571 +---+------+-+----+ +--+---+----+ +----+---+--+ 572 |L2 E/D| |L2 E/D| |L2 E/D| |L2 E/D| 573 +-------+------+---+------+----+------+---------------+------+ 574 | Underlying Interfaces | 575 +------------------------------------------------------------+ 577 Figure 2: OMNI Interface Layering 579 The OMNI/OAL model gives rise to a number of opportunities: 581 o MNs receive a MNP from the MS, and coordinate with the MS through 582 IPv6 ND message exchanges. The MN uses the MNP to construct a 583 unique Link-Local Address (MNP-LLA) through the algorithmic 584 derivation specified in Section 8 and assigns the LLA to the OMNI 585 interface. Since MNP-LLAs are uniquely derived from an MNP, no 586 Duplicate Address Detection (DAD) or Multicast Listener Discovery 587 (MLD) messaging is necessary. 589 o since Temporary ULAs are statistically unique, they can be used 590 without DAD, e.g. for MN-to-MN communications until an MNP-LLA is 591 obtained. 593 o underlying interfaces on the same L2 link segment as an AR do not 594 require any L3 addresses (i.e., not even link-local) in 595 environments where communications are coordinated entirely over 596 the OMNI interface. 598 o as underlying interface properties change (e.g., link quality, 599 cost, availability, etc.), any active interface can be used to 600 update the profiles of multiple additional interfaces in a single 601 message. This allows for timely adaptation and service continuity 602 under dynamically changing conditions. 604 o coordinating underlying interfaces in this way allows them to be 605 represented in a unified MS profile with provisions for mobility 606 and multilink operations. 608 o exposing a single virtual interface abstraction to the IPv6 layer 609 allows for multilink operation (including QoS based link 610 selection, packet replication, load balancing, etc.) at L2 while 611 still permitting L3 traffic shaping based on, e.g., DSCP, flow 612 label, etc. 614 o the OMNI interface allows inter-INET traversal when nodes located 615 in different INETs need to communicate with one another. This 616 mode of operation would not be possible via direct communications 617 over the underlying interfaces themselves. 619 o the OAL supports lossless and adaptive path MTU mitigations not 620 available for communications directly over the underlying 621 interfaces themselves. The OAL supports "packing" of multiple IP 622 payload packets within a single OAL packet. 624 o the OAL applies per-packet identification values that allow for 625 link-layer reliability and data origin authentication. 627 o L3 sees the OMNI interface as a point of connection to the OMNI 628 link; if there are multiple OMNI links (i.e., multiple MS's), L3 629 will see multiple OMNI interfaces. 631 o Multiple independent OMNI interfaces can be used for increased 632 fault tolerance through Safety-Based Multilink (SBM), with 633 Performance-Based Multilink (PBM) applied within each interface. 635 Other opportunities are discussed in [RFC7847]. Note that even when 636 the OMNI virtual interface is present, applications can still access 637 underlying interfaces either through the network protocol stack using 638 an Internet socket or directly using a raw socket. This allows for 639 intra-network (or point-to-point) communications without invoking the 640 OMNI interface and/or OAL. For example, when an IPv6 OMNI interface 641 is configured over an underlying IPv4 interface, applications can 642 still invoke IPv4 intra-network communications as long as the 643 communicating endpoints are not subject to mobility dynamics. 644 However, the opportunities discussed above are not realized when the 645 architectural layering is bypassed in this way. 647 Figure 3 depicts the architectural model for a MN with an attached 648 EUN connecting to the MS via multiple independent *NETs. When an 649 underlying interface becomes active, the MN's OMNI interface sends 650 IPv6 ND messages without encapsulation if the first-hop Access Router 651 (AR) is on the same underlying link; otherwise, the interface uses 652 IP-in-IP encapsulation. The IPv6 ND messages traverse the ground 653 domain *NETs until they reach an AR (AR#1, AR#2, ..., AR#n), which 654 then coordinates with an INET Mobility Service Endpoint (MSE#1, 655 MSE#2, ..., MSE#m) and returns an IPv6 ND message response to the MN. 657 The Hop Limit in IPv6 ND messages is not decremented due to 658 encapsulation; hence, the OMNI interface appears to be attached to an 659 ordinary link. 661 +--------------+ (:::)-. 662 | MN |<-->.-(::EUN:::) 663 +--------------+ `-(::::)-' 664 |OMNI interface| 665 +----+----+----+ 666 +--------|IF#1|IF#2|IF#n|------ + 667 / +----+----+----+ \ 668 / | \ 669 / | \ 670 v v v 671 (:::)-. (:::)-. (:::)-. 672 .-(::*NET:::) .-(::*NET:::) .-(::*NET:::) 673 `-(::::)-' `-(::::)-' `-(::::)-' 674 +----+ +----+ +----+ 675 ... |AR#1| .......... |AR#2| ......... |AR#n| ... 676 . +-|--+ +-|--+ +-|--+ . 677 . | | | 678 . v v v . 679 . <----- INET Encapsulation -----> . 680 . . 681 . +-----+ (:::)-. . 682 . |MSE#2| .-(::::::::) +-----+ . 683 . +-----+ .-(::: INET :::)-. |MSE#m| . 684 . (::::: Routing ::::) +-----+ . 685 . `-(::: System :::)-' . 686 . +-----+ `-(:::::::-' . 687 . |MSE#1| +-----+ +-----+ . 688 . +-----+ |MSE#3| |MSE#4| . 689 . +-----+ +-----+ . 690 . . 691 . . 692 . <----- Worldwide Connected Internetwork ----> . 693 ........................................................... 695 Figure 3: MN/MS Coordination via Multiple *NETs 697 After the initial IPv6 ND message exchange, the MN (and/or any nodes 698 on its attached EUNs) can send and receive original IP packets over 699 the OMNI interface. OMNI interface multilink services will forward 700 the packets via ARs in the correct underlying *NETs. The AR 701 encapsulates the packets according to the capabilities provided by 702 the MS and forwards them to the next hop within the worldwide 703 connected Internetwork via optimal routes. 705 5. OMNI Interface Maximum Transmission Unit (MTU) 707 The OMNI interface observes the link nature of tunnels, including the 708 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 709 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 710 The OMNI interface is configured over one or more underlying 711 interfaces as discussed in Section 4, where the interfaces (and their 712 associated *NET paths) may have diverse MTUs. OMNI interface 713 considerations for accommodating original IP packets of various sizes 714 are discussed in the following sections. 716 IPv6 underlying interfaces are REQUIRED to configure a minimum MTU of 717 1280 bytes and a minimum MRU of 1500 bytes [RFC8200]. Therefore, the 718 minimum IPv6 path MTU is 1280 bytes since routers on the path are not 719 permitted to perform network fragmentation even though the 720 destination is required to reassemble more. The network therefore 721 MUST forward original IP packets of at least 1280 bytes without 722 generating an IPv6 Path MTU Discovery (PMTUD) Packet Too Big (PTB) 723 message [RFC8201]. (While the source can apply "source 724 fragmentation" for locally-generated IPv6 packets up to 1500 bytes 725 and larger still if it knows the destination configures a larger MRU, 726 this does not affect the minimum IPv6 path MTU.) 728 IPv4 underlying interfaces are REQUIRED to configure a minimum MTU of 729 68 bytes [RFC0791] and a minimum MRU of 576 bytes [RFC0791][RFC1122]. 730 Therefore, when the Don't Fragment (DF) bit in the IPv4 header is set 731 to 0 the minimum IPv4 path MTU is 576 bytes since routers on the path 732 support network fragmentation and the destination is required to 733 reassemble at least that much. The OMNI interface therefore MUST set 734 DF to 0 in the IPv4 encapsulation headers of carrier packets that are 735 no larger than 576 bytes, and MUST set DF to 1 in larger carrier 736 packets. (Note: even if the encapsulation source has a way to 737 determine that the encapsulation destination configures an MRU larger 738 than 576 bytes, it should not assume a larger minimum IPv4 path MTU 739 without careful consideration of the issues discussed in 740 Section 6.9.) 742 The OMNI interface configures an MTU and MRU of 9180 bytes [RFC2492]; 743 the size is therefore not a reflection of the underlying interface or 744 *NET path MTUs, but rather determines the largest original IP packet 745 the OAL (and/or underlying interface) can forward or reassemble. For 746 each OAL destination (i.e., for each OMNI link neighbor), the OAL 747 source may discover "hard" or "soft" Reassembly Limit values smaller 748 than the MRU based on receipt of IPv6 ND messages with OMNI 749 Reassembly Limit sub-options (see: Section 12.1.11). The OMNI 750 interface employs the OAL as an encapsulation sublayer service to 751 transform original IP packets into OAL packets/fragments, and the OAL 752 in turn uses *NET encapsulation to forward carrier packets over the 753 underlying interfaces (see: Section 6). 755 6. The OMNI Adaptation Layer (OAL) 757 When an OMNI interface forwards an original IP packet from the 758 network layer for transmission over one or more underlying 759 interfaces, the OMNI Adaptation Layer (OAL) acting as the OAL source 760 drops the packet and returns a PTB message if the packet exceeds the 761 MRU and/or the hard Reassembly Limit for the intended OAL 762 destination. Otherwise, the OAL source applies encapsulation to form 763 OAL packets and fragmentation to produce resulting OAL fragments 764 suitable for *NET encapsulation and transmission as carrier packets 765 over underlying interfaces as described in Section 6.1. 767 These carrier packets travel over one or more underlying networks 768 bridged by OAL intermediate nodes, which re-encapsulate by removing 769 the *NET headers of the first underlying network and appending *NET 770 headers appropriate for the next underlying network in succession. 771 After re-encapsulation by zero or more OAL intermediate nodes, the 772 carrier packets arrive at the OAL destination. 774 When the OAL destination receives the carrier packets, it discards 775 the *NET headers and reassembles the resulting OAL fragments into an 776 OAL packet as described in Section 6.3. The OAL destination then 777 decapsulates the OAL packet to obtain the original IP packet, which 778 it then delivers to the network layer. 780 Detailed operations of the OAL are discussed in the following 781 sections. 783 6.1. OAL Source Encapsulation and Fragmentation 785 When the network layer forwards an original IP packet into the OMNI 786 interface, the OAL source inserts an IPv6 encapsulation header but 787 does not decrement the Hop Limit/TTL of the original IP packet since 788 encapsulation occurs at a layer below IP forwarding [RFC2473]. The 789 OAL source copies the "TTL/Hop Limit", "Type of Service/Traffic 790 Class" [RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion 791 Experienced" [RFC3168] values in the original packet's IP header into 792 the corresponding fields in the OAL header. 794 The OAL next selects source and destination addresses for the IPv6 795 header of the resulting OAL packet. MN OMNI interfaces set the OAL 796 IPv6 header source address to a Unique Local Address (ULA) based on 797 the Mobile Network Prefix (MNP-ULA), while AR and MSE OMNI interfaces 798 set the source address to an Administrative ULA (ADM-ULA) (see: 799 Section 9). When a MN OMNI interface does not (yet) have an MNP-ULA, 800 it can use a Temporary ULA and/or Host Identity Tag (HIT) instead 801 (see: Section 22). 803 When the OAL source forwards an original IP packet toward a final 804 destination via an ANET underlying interface, it sets the OAL IPv6 805 header source address to its own ULA and sets the destination to 806 either the Administrative ULA (ADM-ULA) of the ANET peer or the 807 Mobile Network Prefix ULA (MNP-ULA) corresponding to the final 808 destination (see below). The OAL source then fragments the OAL 809 packet if necessary, encapsulates the OAL fragments in any ANET 810 headers and sends the resulting carrier packets to the ANET peer 811 which either reassembles before forwarding if the OAL destination is 812 its own ULA or forwards the fragments toward the true OAL destination 813 without first reassembling otherwise. 815 When the OAL source forwards an original IP packet toward a final 816 destination via an INET underlying interface, it sets the OAL IPv6 817 header source address to its own ULA and sets the destination to the 818 ULA of an OAL destination node on the final *NET segment. The OAL 819 source then fragments the OAL packet if necessary, encapsulates the 820 OAL fragments in any *NET headers and sends the resulting carrier 821 packets toward the OAL destination on the final segment OMNI node 822 which reassembles before forwarding the original IP packets toward 823 the final destination. 825 Following OAL IPv6 encapsulation and address selection, the OAL 826 source next appends a 2 octet trailing Checksum (initialized to 0) at 827 the end of the original IP packet while incrementing the OAL header 828 IPv6 Payload Length field to reflect the addition of the trailer. 829 The format of the resulting OAL packet following encapsulation is 830 shown in Figure 4: 832 +----------+-----+-----+-----+-----+-----+-----+----+ 833 | OAL Hdr | Original IP packet |Csum| 834 +----------+-----+-----+-----+-----+-----+-----+----+ 836 Figure 4: OAL Packet Before Fragmentation 838 The OAL source next selects a 32-bit Identification value for the 839 packet, beginning with an unpredictable value for the initial OAL 840 packet per [RFC7739] and monotonically incrementing for each 841 successive OAL packet until a new initial value is chosen. 843 The OAL source then calculates the 2's complement (mod 256) 844 Fletcher's checksum [CKSUM][RFC2328][RFC0905] over the entire OAL 845 packet beginning with a pseudo-header of the IPv6 header similar to 846 that found in Section 8.1 of [RFC8200]. The OAL IPv6 pseudo-header 847 is formed as shown in Figure 5: 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | | 851 + + 852 | | 853 + OAL Source Address + 854 | | 855 + + 856 | | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | | 859 + + 860 | | 861 + OAL Destination Address + 862 | | 863 + + 864 | | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | OAL Payload Length | zero | Next Header | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Identification | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 5: OAL IPv6 Pseudo-Header 873 The OAL source then inserts a single OMNI Routing Header (ORH) if 874 necessary (see: [I-D.templin-intarea-6706bis]) while incrementing 875 Payload Length to reflect the addition of the ORH (note that the late 876 addition of the ORH is not covered by the trailing checksum). 878 The OAL source next fragments the OAL packet if necessary while 879 assuming the IPv4 minimum path MTU (i.e., 576 bytes) as the worst 880 case for OAL fragmentation regardless of the underlying interface IP 881 protocol version since IPv6/IPv4 protocol translation and/or IPv6-in- 882 IPv4 encapsulation may occur in any *NET path. By always assuming 883 the IPv4 minimum even for IPv6 underlying interfaces, the OAL source 884 may produce smaller fragments with additional encapsulation overhead 885 but will always interoperate and never run the risk of loss due to an 886 MTU restriction or due to presenting an underlying interface with a 887 carrier packet that exceeds its MRU. Additionally, the OAL path 888 could traverse multiple *NET "segments" with intermediate OAL 889 forwarding nodes performing re-encapsulation where the *NET 890 encapsulation of the previous segment is replaced by the *NET 891 encapsulation of the next segment which may be based on a different 892 IP protocol version and/or encapsulation sizes. 894 The OAL source therefore assumes a default minimum path MTU of 576 895 bytes at each *NET segment for the purpose of generating OAL 896 fragments for *NET encapsulation and transmission as carrier packets. 897 In the worst case, each successive *NET segment may re-encapsulate 898 with either a 20 byte IPv4 or 40 byte IPv6 header, an 8 byte UDP 899 header and in some cases an IP security encapsulation (40 bytes 900 maximum assumed). Any *NET segment may also insert a maximum-length 901 (40 byte) ORH as an extension to the existing 40 byte OAL IPv6 header 902 plus 8 byte Fragment Header if an ORH was not already present. 903 Assuming therefore an absolute worst case of (40 + 40 + 8) = 88 bytes 904 for *NET encapsulation plus (40 + 40 + 8) = 88 bytes for OAL 905 encapsulation leaves (576 - 88 - 88) = 400 bytes to accommodate a 906 portion of the original IP packet/fragment. The OAL source therefore 907 sets a minimum Maximum Payload Size (MPS) of 400 bytes as the basis 908 for the minimum-sized OAL fragment that can be assured of traversing 909 all segments without loss due to an MTU/MRU restriction. The Maximum 910 Fragment Size (MFS) for OAL fragmentation is therefore determined by 911 the MPS plus the size of the OAL encapsulation headers. (Note that 912 the OAL source includes the 2 octet trailer as part of the payload 913 during fragmentation, and the OAL destination regards it as ordinary 914 payload until reassembly and checksum verification are complete.) 916 The OAL source SHOULD maintain "path MPS" values for individual OAL 917 destinations initialized to the minimum MPS and increased to larger 918 values (up to the OMNI interface MTU) if better information is known 919 or discovered. For example, when *NET peers share a common 920 underlying link or a fixed path with a known larger MTU, the OAL 921 source can base path MPS on this larger size (i.e., instead of 576 922 bytes) as long as the *NET peer reassembles before re-encapsulating 923 and forwarding (while re-fragmenting if necessary). Also, if the OAL 924 source has a way of knowing the maximum *NET encapsulation size for 925 all segments along the path it may be able to increase path MPS to 926 reserve additional room for payload data. The OAL source must 927 include the uncompressed OAL header size in its path MPS calculation, 928 since a full header could be included at any time. 930 The OAL source can also actively probe individual OAL destinations to 931 discover larger path MPS values using packetization layer probes per 932 [RFC4821][RFC8899], but care must be taken to avoid setting static 933 values for dynamically changing paths leading to black holes. The 934 probe involves sending an OAL packet larger than the current path MPS 935 and receiving a small acknowledgement message in response. For this 936 purpose, the OAL source can send an NS message with one or more OMNI 937 options with large PadN sub-options (see: Section 12) in order to 938 receive a small NA response from the OAL destination. While 939 observing the minimum MPS will always result in robust and secure 940 behavior, the OAL should optimize path MPS values when more efficient 941 utilization may result in better performance (e.g. for wireless 942 aviation data links). 944 When the OAL source performs fragmentation, it SHOULD produce the 945 minimum number of non-overlapping fragments under current MPS 946 constraints, where each non-final fragment MUST be of equal length at 947 least as large as the minimum MPS, while the final fragment MAY be of 948 different length. The OAL source also converts all original IP 949 packets no larger than the current MPS into "atomic fragments" by 950 including a Fragment Header with Fragment Offset and More Fragments 951 both set to 0. The OAL source finally encapsulates the fragments in 952 *NET headers to form carrier packets and forwards them over an 953 underlying interface, while retaining the fragments and their ordinal 954 positions (i.e., as Frag #0, Frag #1, Frag #2, etc.) for a timeout 955 period in case link-layer retransmission is requested. The formats 956 of OAL fragments and carrier packets are shown in Figure 6. 958 +----------+--+-------------+ 959 | OAL Hdr |FH| Frag #0 | 960 +----------+--+-------------+ 961 +----------+--+-------------+ 962 | OAL Hdr |FH| Frag #1 | 963 +----------+--+-------------+ 964 +----------+--+-------------+ 965 | OAL Hdr |FH| Frag #2 | 966 +----------+--+-------------+ 967 .... 968 +----------+--+-------------+----+ 969 | OAL Hdr |FH| Frag #(N-1) |Csum| 970 +----------+--+-------------+----+ 971 a) OAL fragments after fragmentation 972 (FH = Fragment Header; Csum appears only in final fragment) 974 +--------+--+-----+-----+-----+-----+-----+----+ 975 |OAL Hdr |FH| Original IP packet |Csum| 976 +--------+--+-----+-----+-----+-----+-----+----+ 977 b) An OAL "atomic fragment" with FH but no fragmentation. 979 +--------+----------+--+-------------+ 980 |*NET Hdr| OAL Hdr |FH| Frag #i | 981 +--------+----------+--+-------------+ 982 c) OAL carrier packet after *NET encapsulation 984 Figure 6: OAL Fragments and Carrier Packets 986 6.2. OAL *NET Encapsulation and Re-Encapsulation 988 During *NET encapsulation, OAL sources first encapsulate each OAL 989 fragment in a UDP header as the first *NET encapsulation sublayer if 990 NAT traversal, packet filtering middlebox traversal and/or OAL header 991 compression are necessary. The OAL then optionally appends 992 additional encapsulation sublayer headers, then presents the *NET 993 packet to an underlying interface. This layering can be seen in 994 Figure 2. 996 When a UDP header is included, the OAL source next sets the UDP 997 source port to a constant value that it will use in each successive 998 carrier packet it sends to the next OAL hop. For packets sent to an 999 MSE, the OAL source sets the UDP destination port to 8060, i.e., the 1000 IANA-registered port number for AERO. For packets sent to a MN peer, 1001 the source sets the UDP destination port to the cached port value for 1002 this peer. The OAL source then sets the UDP length to the total 1003 length of the OAL fragment in correspondence with the OAL header 1004 Payload Length (i.e., the UDP length and IPv6 Payload Length must 1005 agree). The OAL source finally sets the UDP checksum to 0 1006 [RFC6935][RFC6936] since the only fields not already covered by the 1007 OAL checksum or underlying *NET CRCs are the Fragment Header fields, 1008 and any corruption in those fields will be garbage collected by the 1009 reassembly algorithm. The UDP encapsulation header is often used in 1010 association with IP encapsulation, but may also be used between 1011 neighbors on a shared physical link with a true L2 header format such 1012 as for transmission over IEEE 802 Ethernet links. This document 1013 therefore requests a new Ether Type code assignment TBD1 in the IANA 1014 'ieee-802-numbers' registry for direct User Datagram Protocol (UDP) 1015 encapsulation over IEEE 802 Ethernet links (see: Section 25). 1017 For *NET encapsulations that include an IP header, the OAL source 1018 next copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 1019 [RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion 1020 Experienced" [RFC3168] values in the original packet's IP header into 1021 the corresponding fields in the *NET IP header. For carrier packets 1022 undergoing re-encapsulation, OAL intermediate nodes instead copy 1023 these values from the previous hop *NET encapsulation header into the 1024 next hop *NET encapsulation header, i.e., the IP values are 1025 transferred between *NET encapsulation headers and *not* copied from 1026 the OAL header. (Note especially that by copying the TTL/Hop Limit 1027 between *NET encapsulation headers the value will eventually 1028 decrement to 0 if there is a (temporary) routing loop.) 1030 Following *NET encapsulation/re-encapsulation, the OAL source sends 1031 the resulting carrier packets over one or more underlying interfaces. 1032 The underlying interfaces often connect directly to physical media on 1033 the local platform (e.g., a laptop computer with WiFi, etc.), but in 1034 some configurations the physical media may be hosted on a separate 1035 Local Area Network (LAN) node. In that case, the OMNI interface can 1036 establish a Layer-2 VLAN or a point-to-point tunnel (at a layer below 1037 the underlying interface) to the node hosting the physical media. 1038 The OMNI interface may also apply encapsulation at the underlying 1039 interface layer (e.g., as for a tunnel virtual interface) such that 1040 carrier packets would appear "double-encapsulated" on the LAN; the 1041 node hosting the physical media in turn removes the LAN encapsulation 1042 prior to transmission or inserts it following reception. Finally, 1043 the underlying interface must monitor the node hosting the physical 1044 media (e.g., through periodic keepalives) so that it can convey 1045 up/down/status information to the OMNI interface. 1047 6.3. OAL Destination Decapsulation and Reassembly 1049 When an OMNI interface receives a carrier packet from an underlying 1050 interface, the OAL destination discards the *NET encapsulation 1051 headers and examines the OAL header of the enclosed OAL fragment. If 1052 the OAL fragment is addressed to a different node, the OAL 1053 destination re-encapsulates and forwards as discussed below. If the 1054 OAL fragment is addressed to itself, the OAL destination creates or 1055 updates a checklist for this (Source, Destination, Identification)- 1056 tuple to track the fragments already received (i.e., by examining the 1057 Payload Length, Fragment Offset, More Fragments and Identification 1058 values supplied by the OAL source). The OAL destination verifies 1059 that all non-final OAL fragments are of equal length no less than the 1060 minimum MPS and that no fragments overlap or leave "holes", while 1061 dropping any non-conforming fragments. The OAL destination records 1062 each conforming OAL fragment's ordinal position based on the OAL 1063 header Payload Length and Fragment Offset values (i.e., as Frag #0, 1064 Frag #1, Frag #2, etc.) and admits each fragment into the reassembly 1065 cache. 1067 When reassembly is complete, the OAL destination removes the ORH if 1068 present while decrementing Payload Length to reflect the removal of 1069 the ORH. The OAL destination next verifies the resulting OAL 1070 packet's checksum and discards the packet if the checksum is 1071 incorrect. If the OAL packet was accepted, the OAL destination then 1072 removes the OAL header/trailer, then delivers the original IP packet 1073 to the network layer. Note that link layers include a CRC-32 1074 integrity check which provides effective hop-by-hop error detection 1075 in the underlying network for payload sizes up to the OMNI interface 1076 MTU [CRC], but that some hops may traverse intermediate layers such 1077 as tunnels over IPv4 that do not include integrity checks. The 1078 trailing Fletcher checksum therefore allows the OAL destination to 1079 detect OAL packet splicing errors due to reassembly misassociations 1080 and/or to verify integrity for OAL packets whose fragments may have 1081 traversed unprotected underlying network hops [CKSUM]. The Fletcher 1082 algorithm also provides diversity with respect to both lower layer 1083 CRCs and upper layer Internet checksums as part of a complimentary 1084 multi-layer integrity assurance architecture. 1086 6.4. OAL Header Compression 1088 When the OAL source and destination are on the same *NET segment, no 1089 ORH is needed and carrier packet header compression is possible. 1090 When the OAL source and destination exchange initial IPv6 ND messages 1091 as discussed in the following Sections, each caches the observed *NET 1092 UDP source port and source IP (or L2) address associated with the OAL 1093 IPv6 source address found in the full-length OAL IPv6 header. After 1094 the initial IPv6 ND message exchange, the OAL source can begin 1095 applying OAL Header Compression to significantly reduce the 1096 encapsulation overhead required in each carrier packet. 1098 When the OAL source determines that header compression state has been 1099 established (i.e., following the IPv6 ND message exchange), it can 1100 begin sending OAL fragments with significant portions of the IPv6 1101 header and Fragment Header omitted thereby reducing the amount of 1102 encapsulation overhead. For OAL first-fragments (including atomic 1103 fragments), the OMNI Compressed Header - Type 0 (OCH-0) is used and 1104 formatted as shown in Figure 7: 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * 1109 | Source port | Destination port | U 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 1111 | Length | Checksum | P 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * 1113 |Version| Traffic Class | Flow Label | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Next Header | Reserved |M| Identification (0 -1) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Identification (2-3) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 1120 Figure 7: OMNI Compressed Header - Type 0 (OCH-0) 1122 In this format, the UDP header appears in its entirety in the first 8 1123 octets, then followed by the first 4 octets of the IPv6 header with 1124 the remainder omitted. (The IPv6 Version field is set to the value 0 1125 to distinguish this header from a true IP protocol version number and 1126 from OCH-1 - see below.) The compressed IPv6 header is then followed 1127 by a compressed IPv6 Fragment Header with the Fragment Offset field 1128 and two Reserved bits omitted (since these fields always encode the 1129 value 0 in first-fragments), and with the More Fragments (M) bit 1130 relocated to the least significant bit of the first Reserved field. 1131 The OCH-0 header is then followed by the OAL fragment body, and the 1132 UDP length field is reduced by 38 octets (i.e., the difference in 1133 length between full-length IPv6 and Fragment Headers and the length 1134 of the compressed headers). 1136 For OAL non-first fragments (i.e., those with non-zero Fragment 1137 Offsets), the OMNI Compressed Header - Type 1 (OCH-1) is used and 1138 formatted as shown in Figure 8: 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * 1143 | Source port | Destination port | U 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D 1145 | Length | Checksum | P 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * 1147 |V|R|M| Fragment Offset | Identification (0-1) | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Identification (1-3) | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 Figure 8: OMNI Compressed Header - Type 1 (OCH-1) 1154 In this format, the UDP header appears in its entirety in the first 8 1155 octets, but all IPv6 header fields except for the most significant 1156 Version (V) bit are omitted. (The V bit is set to the value 1 to 1157 distinguish this header from a true IP protocol version number and 1158 from OCH-0.) The V bit is followed by a single Reserved (R) bit and 1159 the More Fragments (M) bit in a compressed IPv6 Fragment Header with 1160 the Next Header and first Reserved fields omitted. The OCH-1 header 1161 is then followed by the OAL fragment body, and the UDP length field 1162 is reduced by 42 octets (i.e., the difference in length between full- 1163 length IPv6 and Fragment Headers and the length of the compressed 1164 headers). 1166 When the OAL destination receives a carrier packet with an OCH, it 1167 first determines the OAL IPv6 source and destination addresses by 1168 examining the UDP source port and L2 source address, then determines 1169 the length by examining the UDP length. The OAL destination then 1170 examines the (V)ersion field immediately following the UDP header. 1171 If the (4-bit) Version field encodes the value 0, the OAL destination 1172 processes the remainder of the header as an OCH-0, then reconstitutes 1173 the full-sized IPv6 and Fragment Headers and adds this OAL fragment 1174 to the reassembly buffer if necessary. If the (1-bit) V bit encodes 1175 the value 1, the OAL destination instead processes the remainder of 1176 the header as an OCH-1, then reconstitutes the full-sized IPv6 and 1177 Fragment Headers and adds this OAL fragment to the reassembly buffer. 1179 Note that, since the OCH-1 does not include Traffic Class, Flow Label 1180 or Next Header information, the OAL destination writes the value 0 1181 into these fields when it reconstitutes the full headers. These 1182 values will be correctly populated during reassembly after an OAL 1183 first fragment with an OCH-0 or uncompressed OAL header arrives. 1185 6.5. OAL Fragment Identification Window Maintenance 1187 As noted above, the OAL source establishes a window of 32-bit 1188 Identifications beginning with an unpredictable value for the initial 1189 message [RFC7739] and monotonically incrementing for each successive 1190 OAL packet until a new initial value is chosen. The OAL source 1191 asserts the starting value by including it as the Identification in 1192 an IPv6 ND NS/RS/RA messages or in a solicited NA message. When the 1193 OAL destination receives the IPv6 ND message, it resets the 1194 Identification window for this OAL source to the new value coded in 1195 the message's OAL header and expects future OAL fragments received 1196 from this OAL source to include sequential Identification values 1197 (subject to loss and reordering) until the neighbor reachable time 1198 expires or the OAL source sends a new IPv6 ND message. 1200 For example, if the OAL destination receives an NS/RS/RA or solicited 1201 NA message with Identification 0x12345678, it resets the window for 1202 this OAL source to begin with 0x12345678 and examines the 1203 Identification values in subsequent OAL fragments received from this 1204 OAL source. If the Identification values of subsequent OAL fragments 1205 fall within the window of (0x12345678 + N) the OAL destination 1206 accepts the fragment; otherwise, it silently drops the fragment 1207 (where "N" represents the maximum number of fragments expected before 1208 the neighbor reachable time expires). 1210 While monitoring the current window, the OAL destination must accept 1211 new NS/RS/RA or solicited NA Identification values even if outside 1212 the current window. The new Identification value resets the OAL 1213 destination's window start, and the window processing continues from 1214 this new starting point while allowing a period of overlap in case 1215 OAL fragments with Identification values from a previous window are 1216 still in flight. Note also that unsolicited NA messages must include 1217 Identification values within the current window, and therefore do not 1218 reset the current window. 1220 This implies that an IPv6 ND message used to reset the Identification 1221 window should fit within a single OAL fragment (i.e., within current 1222 MPS constraints), since a fragmented IPv6 ND message with an out-of- 1223 window Identification value could be part of a DoS attack. While 1224 larger IPv6 ND messages (up to the OMNI interface MTU) can certainly 1225 be subject to OAL fragmentation, their Identification should be 1226 within the current window maintained by the OAL destination to 1227 increase the likelihood that they will be accepted. 1229 6.6. OAL Fragment Retransmission 1231 When the OAL source sends carrier packets with OAL fragments to an 1232 OAL destination, the source caches them for a timeout period in case 1233 retransmission may be necessary. (The timeout duration is an 1234 implementation matter, and may be influenced by factors such as 1235 packet arrival rates, OAL source/destination round trip times, etc.) 1236 The OAL destination in turn maintains a checklist for the (Source, 1237 Destination, Identification)-tuple of each new OAL fragment received 1238 and notes the ordinal positions of fragments already received (i.e., 1239 as Frag #0, Frag #1, Frag #2, etc.). 1241 If the OAL destination notices some OAL fragments missing after most 1242 other fragments within the same Identification window have already 1243 arrived, it may send an IPv6 ND unsolicited Neighbor Advertisement 1244 (uNA) message to the OAL source that originated the fragments to 1245 report loss. The OAL destination creates a uNA message with an OMNI 1246 option containing a Host Identity Payload (HIP) message sub-option to 1247 provide authentication (if the OAL source is on an open Internetwork) 1248 followed by a Fragmentation Report sub-option that includes a list of 1249 (Identification, Bitmap)-tuples for OAL fragments received and 1250 missing from this OAL source (see: Section 12). The OAL destination 1251 signs the message if the HIP sub-option is included, performs OAL 1252 encapsulation (with the its own address as the OAL source and the 1253 source address of the message that prompted the uNA as the OAL 1254 destination) and sends the message to the OAL source. 1256 When the OAL source receives the uNA message, it authenticates the 1257 message using the HIP message sub-option (if present) then examines 1258 the Fragmentation Report. For each (Source, Destination, 1259 Identification)-tuple, the OAL source determines whether it still 1260 holds the original OAL fragments in its cache and retransmits any for 1261 which the Bitmap indicated a loss event. For example, if the Bitmap 1262 indicates that the ordinal OAL fragments Frag #3, Frag #7, Frag #10 1263 and Frag #13 from the same OAL packet are missing the OAL source 1264 retransmits these fragments only and no others. 1266 Note that the goal of this service is to provide a light-weight link- 1267 layer Automatic Repeat Request (ARQ) capability in the spirit of 1268 Section 8.1 of [RFC3819]. Rather than provide true end-to-end 1269 reliability, however, the service provides timely link-layer 1270 retransmissions that may improve packet delivery ratios and avoid 1271 some delays inherent in true end-to-end services. 1273 6.7. OAL MTU Feedback Messaging 1275 When the OMNI interface forwards original IP packets from the network 1276 layer, it invokes the OAL and returns internally-generated ICMPv4 1277 Fragmentation Needed [RFC1191] or ICMPv6 Path MTU Discovery (PMTUD) 1278 Packet Too Big (PTB) [RFC8201] messages as necessary. This document 1279 refers to both of these ICMPv4/ICMPv6 message types simply as "PTBs", 1280 and introduces a distinction between PTB "hard" and "soft" errors as 1281 discussed below. 1283 Ordinary PTB messages with ICMPv4 header "unused" field or ICMPv6 1284 header Code field value 0 are hard errors that always indicate that a 1285 packet has been dropped due to a real MTU restriction. In 1286 particular, the OAL source drops the packet and returns a PTB hard 1287 error if the packet exceeds the OAL destination MRU. However, the 1288 OMNI interface can also forward large original IP packets via OAL 1289 encapsulation and fragmentation while at the same time returning PTB 1290 soft error messages (subject to rate limiting) if it deems the 1291 original IP packet too large according to factors such as link 1292 performance characteristics, reassembly congestion, etc. This 1293 ensures that the path MTU is adaptive and reflects the current path 1294 used for a given data flow. The OMNI interface can therefore 1295 continuously forward packets without loss while returning PTB soft 1296 error messages recommending a smaller size if necessary. Original 1297 sources that receive the soft errors in turn reduce the size of the 1298 packets they send (i.e., the same as for hard errors), but can soon 1299 resume sending larger packets if the soft errors subside. 1301 An OAL source sends PTB soft error messages by setting the ICMPv4 1302 header "unused" field or ICMPv6 header Code field to the value 1 if a 1303 original IP packet was deemed lost (e.g., due to reassembly timeout) 1304 or to the value 2 otherwise. The OAL source sets the PTB destination 1305 address to the original IP packet source, and sets the source address 1306 to one of its OMNI interface unicast/anycast addresses that is 1307 routable from the perspective of the original source. The OAL source 1308 then sets the MTU field to a value smaller than the original packet 1309 size but no smaller than 576 for ICMPv4 or 1280 for ICMPv6, writes 1310 the leading portion of the original IP packet into the "packet in 1311 error" field, and returns the PTB soft error to the original source. 1312 When the original source receives the PTB soft error, it temporarily 1313 reduces the size of the packets it sends the same as for hard errors 1314 but may seek to increase future packet sizes dynamically while no 1315 further soft errors are arriving. (If the original source does not 1316 recognize the soft error code, it regards the PTB the same as a hard 1317 error but should heed the retransmission advice given in [RFC8201] 1318 suggesting retransmission based on normal packetization layer 1319 retransmission timers.) This document therefore updates 1320 [RFC1191][RFC4443] and [RFC8201]. Furthermore, packetization layer 1321 probing strategies [RFC4821][RFC8899] must be aware that PTB hard or 1322 soft errors may arrive at any time, i.e., even following a successful 1323 probe (this is the same consideration as for an ordinary path 1324 fluctuation following a successful probe). 1326 An OAL destination may experience reassembly cache congestion, and 1327 can return uNA messages to the OAL source that originated the 1328 fragments (subject to rate limiting) to advertise reduced hard/soft 1329 Reassembly Limits and/or to report individual reassembly failures. 1330 The OAL destination creates a uNA message with an OMNI option 1331 containing a HIP message sub-option to provide authentication (if the 1332 OAL source is on an open Internetwork) followed optionally by at most 1333 one hard and one soft Reassembly Limit sub-options with reduced hard/ 1334 soft values, and with one of them optionally including the leading 1335 portion an OAL first fragment containing the header of an original IP 1336 packet whose source must be notified (see: Section 12). The OAL 1337 destination encapsulates as much of the OAL first fragment (beginning 1338 with the OAL header) as will fit in the "OAL First Fragment" field of 1339 sub-option without causing the entire uNA message to exceed the 1340 minimum MPS, signs the message if the HIP sub-option is included, 1341 performs OAL encapsulation (with the its own address as the OAL 1342 source and the source address of the message that prompted the uNA as 1343 the OAL destination) and sends the message to the OAL source. 1345 When the OAL source receives the uNA message, it records the new 1346 hard/soft Reassembly Limit values for this OAL destination if the 1347 OMNI option includes Reassembly Limit sub-options. If a hard or soft 1348 Reassembly Limit sub-option includes an OAL First Fragment, the OAL 1349 source next sends a corresponding network layer PTB hard or soft 1350 error to the original source to recommend a smaller size. For hard 1351 errors, the OAL source sets the PTB Code field to 0. For soft 1352 errors, the OAL source sets the PTB Code field to 1 if the L flag in 1353 the Reassembly Limit sub-option is 1; otherwise, the OAL source sets 1354 the Code field to 2. The OAL source crafts the PTB by extracting the 1355 leading portion of the original IP packet from the OAL First Fragment 1356 field (i.e., not including the OAL header) and writes it in the 1357 "packet in error" field of a PTB with destination set to the original 1358 IP packet source and source set to one of its OMNI interface unicast/ 1359 anycast addresses that is routable from the perspective of the 1360 original source. For future transmissions, if the original IP packet 1361 is larger than the hard Reassembly Limit for this OAL destination the 1362 OAL source drops the packet and returns a PTB hard error with MTU set 1363 to the hard Reassembly Limit. If the packet is no larger than the 1364 current hard Reassembly Limit but larger than the current soft limit, 1365 the OAL source can also return PTB soft errors (subject to rate 1366 limiting) with Code set to 2 and MTU set to the current soft limit 1367 while still forwarding the packet to the OMNI destination. 1369 Original sources that receive PTB soft errors can dynamically tune 1370 the size of the original IP packets they to send to produce the best 1371 possible throughput and latency, with the understanding that these 1372 parameters may change over time due to factors such as congestion, 1373 mobility, network path changes, etc. The receipt or absence of soft 1374 errors should be seen as hints of when increasing or decreasing 1375 packet sizes may be beneficial. The OMNI interface supports 1376 continuous transmission and reception of packets of various sizes in 1377 the face of dynamically changing network conditions. Moreover, since 1378 PTB soft errors do not indicate a hard limit, original sources that 1379 receive soft errors can begin sending larger packets without waiting 1380 for the recommended 10 minutes specified for PTB hard errors 1381 [RFC1191][RFC8201]. The OMNI interface therefore provides an 1382 adaptive service that accommodates MTU diversity especially well- 1383 suited for dynamic multilink environments. 1385 6.8. OAL Requirements 1387 In light of the above, OAL sources, destinations and intermediate 1388 nodes observe the following normative requirements: 1390 o OAL sources MUST NOT send OAL fragments including original IP 1391 packets larger than the OMNI interface MTU or the OAL destination 1392 hard Reassembly Limit, i.e., whether or not fragmentation is 1393 needed. 1395 o OAL sources MUST NOT perform OAL fragmentation for original IP 1396 packets smaller than the minimum MPS minus the trailer size, and 1397 MUST produce non-final fragments that contain equal-length 1398 payloads no smaller than the minimum MPS when performing 1399 fragmentation. 1401 o OAL sources MUST NOT send OAL fragments that include any extension 1402 headers other than a single ORH and a single Fragment Header. 1404 o OAL intermediate nodes SHOULD and OAL destinations MUST 1405 unconditionally drop OAL packets/fragments including original IP 1406 packets larger than the OMNI interface MRU and/or OAL destination 1407 hard Reassembly Limit, i.e., whether or not reassembly was needed. 1409 o OAL intermediate nodes SHOULD and OAL destinations MUST 1410 unconditionally drop any non-final OAL fragments containing a 1411 payload smaller than the minimum MPS. 1413 o OAL intermediate nodes SHOULD and OAL destinations MUST 1414 unconditionally drop OAL fragments that include any extension 1415 headers other than a single ORH and a single Fragment Header. 1417 o OAL destination nodes MUST drop any new OAL non-final fragments of 1418 different length than other non-final fragments that have already 1419 been received, and MUST drop any new OAL fragments with Offset and 1420 Payload length that would overlap with other fragments and/or 1421 leave too-small holes between fragments that have already been 1422 received. 1424 Note: Under the minimum MPS, ordinary 1500 byte original IP packets 1425 would require at most 4 OAL fragments, with each non-final fragment 1426 containing 400 payload bytes and the final fragment containing 302 1427 payload bytes (i.e., the final 300 bytes of the original IP packet 1428 plus the 2 octet trailer). Likewise, maximum-length 9180 byte 1429 original IP packets would require at most 23 fragments. For all 1430 packet sizes, the likelihood of successful reassembly may improve 1431 when the OMNI interface sends all fragments of the same fragmented 1432 OAL packet consecutively over the same underlying interface. 1433 Finally, an assured minimum/path MPS allows continuous operation over 1434 all paths including those that traverse bridged L2 media with 1435 dissimilar MTUs. 1437 Note: Certain legacy network hardware of the past millennium was 1438 unable to accept packet "bursts" resulting from an IP fragmentation 1439 event - even to the point that the hardware would reset itself when 1440 presented with a burst. This does not seem to be a common problem in 1441 the modern era, where fragmentation and reassembly can be readily 1442 demonstrated at line rate (e.g., using tools such as 'iperf3') even 1443 over fast links on average hardware platforms. Even so, the OAL 1444 source could impose an inter-fragment delay while the OAL destination 1445 is reporting reassembly congestion (see: Section 6.7) and decrease 1446 the delay when reassembly congestion subsides. 1448 6.9. OAL Fragmentation Security Implications 1450 As discussed in Section 3.7 of [RFC8900], there are four basic 1451 threats concerning IPv6 fragmentation; each of which is addressed by 1452 effective mitigations as follows: 1454 1. Overlapping fragment attacks - reassembly of overlapping 1455 fragments is forbidden by [RFC8200]; therefore, this threat does 1456 not apply to the OAL. 1458 2. Resource exhaustion attacks - this threat is mitigated by 1459 providing a sufficiently large OAL reassembly cache and 1460 instituting "fast discard" of incomplete reassemblies that may be 1461 part of a buffer exhaustion attack. The reassembly cache should 1462 be sufficiently large so that a sustained attack does not cause 1463 excessive loss of good reassemblies but not so large that (timer- 1464 based) data structure management becomes computationally 1465 expensive. The cache should also be indexed based on the arrival 1466 underlying interface such that congestion experienced over a 1467 first underlying interface does not cause discard of incomplete 1468 reassemblies for uncongested underlying interfaces. 1470 3. Attacks based on predictable fragment identification values - 1471 this threat is mitigated by selecting a suitably random ID value 1472 per [RFC7739]. Additionally, inclusion of the OAL checksum would 1473 make it very difficult for an attacker who could somehow predict 1474 a fragment identification value to inject malicious fragments 1475 resulting in undetected reassemblies of bad data. 1477 4. Evasion of Network Intrusion Detection Systems (NIDS) - this 1478 threat is mitigated by setting a minimum MPS for OAL 1479 fragmentation, which defeats all "tiny fragment"-based attacks. 1481 Additionally, IPv4 fragmentation includes a 16-bit Identification (IP 1482 ID) field with only 65535 unique values such that at high data rates 1483 the field could wrap and apply to new carrier packets while the 1484 fragments of old packets using the same ID are still alive in the 1485 network [RFC4963]. However, since the largest carrier packet that 1486 will be sent via an IPv4 path with DF = 0 is 576 bytes any IPv4 1487 fragmentation would occur only on links with an IPv4 MTU smaller than 1488 this size, and [RFC3819] recommendations suggest that such links will 1489 have low data rates. Since IPv6 provides a 32-bit Identification 1490 value, IP ID wraparound at high data rates is not a concern for IPv6 1491 fragmentation. 1493 Finally, [RFC6980] documents fragmentation security concerns for 1494 large IPv6 ND messages. These concerns are addressed when the OMNI 1495 interface employs the OAL instead of directly fragmenting the IPv6 ND 1496 message itself. For this reason, OMNI interfaces MUST NOT send IPv6 1497 ND messages larger than the OMNI interface MTU, and MUST employ OAL 1498 encapsulation and fragmentation for IPv6 ND messages larger than the 1499 current MPS for this OAL destination. 1501 6.10. OAL Super-Packets 1503 By default, the OAL source includes a 40-byte IPv6 encapsulation 1504 header for each original IP packet during OAL encapsulation. The OAL 1505 source also calculates and appends a 2 octet trailing Fletcher 1506 checksum then performs fragmentation such that a copy of the 40-byte 1507 IPv6 header plus an 8-byte IPv6 Fragment Header is included in each 1508 OAL fragment (when an ORH is added, the OAL encapsulation headers 1509 become larger still). However, these encapsulations may represent 1510 excessive overhead in some environments. OAL header compression can 1511 dramatically reduce the amount of encapsulation overhead, however a 1512 complimentary technique known as "packing" (see: 1514 [I-D.ietf-intarea-tunnels]) is also supported so that multiple 1515 original IP packets and/or control messages can be included within a 1516 single OAL "super-packet". 1518 When the OAL source has multiple original IP packets to send to the 1519 same OAL destination with total length no larger than the OAL 1520 destination MRU, it can concatenate them into a super-packet 1521 encapsulated in a single OAL header and trailing checksum. Within 1522 the OAL super-packet, the IP header of the first original IP packet 1523 (iHa) followed by its data (iDa) is concatenated immediately 1524 following the OAL header, then the IP header of the next original 1525 packet (iHb) followed by its data (iDb) is concatenated immediately 1526 following the first original packet, etc. with the trailing checksum 1527 included last. The OAL super-packet format is transposed from 1528 [I-D.ietf-intarea-tunnels] and shown in Figure 9: 1530 <------- Original IP packets -------> 1531 +-----+-----+ 1532 | iHa | iDa | 1533 +-----+-----+ 1534 | 1535 | +-----+-----+ 1536 | | iHb | iDb | 1537 | +-----+-----+ 1538 | | 1539 | | +-----+-----+ 1540 | | | iHc | iDc | 1541 | | +-----+-----+ 1542 | | | 1543 v v v 1544 +----------+-----+-----+-----+-----+-----+-----+----+ 1545 | OAL Hdr | iHa | iDa | iHb | iDb | iHc | iDc |Csum| 1546 +----------+-----+-----+-----+-----+-----+-----+----+ 1547 <--- OAL "Super-Packet" with single OAL Hdr/Csum ---> 1549 Figure 9: OAL Super-Packet Format 1551 When the OAL source prepares a super-packet, it applies OAL 1552 fragmentation and *NET encapsulation then sends the carrier packets 1553 to the OAL destination. When the OAL destination receives the super- 1554 packet it reassembles if necessary, verifies and removes the trailing 1555 checksum, then regards the remaining OAL header Payload Length as the 1556 sum of the lengths of all payload packets. The OAL destination then 1557 selectively extracts each original IP packet (e.g., by setting 1558 pointers into the super-packet buffer and maintaining a reference 1559 count, by copying each packet into a separate buffer, etc.) and 1560 forwards each packet to the network layer. During extraction, the 1561 OAL determines the IP protocol version of each successive original IP 1562 packet 'j' by examining the four most-significant bits of iH(j), and 1563 determines the length of the packet by examining the rest of iH(j) 1564 according to the IP protocol version. 1566 Note that OMNI interfaces must take care to avoid processing super- 1567 packet payload elements that would subvert security. Specifically, 1568 if a super-packet contains a mix of data and control payload packets 1569 (which could include critical security codes), the node MUST NOT 1570 process the data packets before processing the control packets 1572 7. Frame Format 1574 The OMNI interface forwards original IP packets from the network 1575 layer by first invoking the OAL to create OAL packets/fragments if 1576 necessary, then including any *NET encapsulations and finally 1577 engaging the native frame format of the underlying interface. For 1578 example, for Ethernet-compatible interfaces the frame format is 1579 specified in [RFC2464], for aeronautical radio interfaces the frame 1580 format is specified in standards such as ICAO Doc 9776 (VDL Mode 2 1581 Technical Manual), for various forms of tunnels the frame format is 1582 found in the appropriate tunneling specification, etc. 1584 See Figure 2 for a map of the various *NET layering combinations 1585 possible. For any layering combination, the final layer (e.g., UDP, 1586 IP, Ethernet, etc.) must have an assigned number and frame format 1587 representation that is compatible with the selected underlying 1588 interface. 1590 8. Link-Local Addresses (LLAs) 1592 OMNI nodes are assigned OMNI interface IPv6 Link-Local Addresses 1593 (LLAs) through pre-service administrative actions. "MNP-LLAs" embed 1594 the MNP assigned to the mobile node, while "ADM-LLAs" include an 1595 administratively-unique ID that is guaranteed to be unique on the 1596 link. LLAs are configured as follows: 1598 o IPv6 MNP-LLAs encode the most-significant 64 bits of a MNP within 1599 the least-significant 64 bits of the IPv6 link-local prefix 1600 fe80::/64, i.e., in the LLA "interface identifier" portion. The 1601 prefix length for the LLA is determined by adding 64 to the MNP 1602 prefix length. For example, for the MNP 2001:db8:1000:2000::/56 1603 the corresponding MNP-LLA is fe80::2001:db8:1000:2000/120. 1605 o IPv4-compatible MNP-LLAs are constructed as fe80::ffff:[IPv4], 1606 i.e., the interface identifier consists of 16 '0' bits, followed 1607 by 16 '1' bits, followed by a 32bit IPv4 address/prefix. The 1608 prefix length for the LLA is determined by adding 96 to the MNP 1609 prefix length. For example, the IPv4-Compatible MN OMNI LLA for 1610 192.0.2.0/24 is fe80::ffff:192.0.2.0/120 (also written as 1611 fe80::ffff:c000:0200/120). 1613 o ADM-LLAs are assigned to ARs and MSEs and MUST be managed for 1614 uniqueness. The lower 32 bits of the LLA includes a unique 1615 integer "MSID" value between 0x00000001 and 0xfeffffff, e.g., as 1616 in fe80::1, fe80::2, fe80::3, etc., fe80::feffffff. The ADM-LLA 1617 prefix length is determined by adding 96 to the MSID prefix 1618 length. For example, if the prefix length for MSID 0x10012001 is 1619 16 then the ADM-LLA prefix length is set to 112 and the LLA is 1620 written as fe80::1001:2001/112. The "zero" address for each ADM- 1621 LLA prefix is the Subnet-Router anycast address for that prefix 1622 [RFC4291]; for example, the Subnet-Router anycast address for 1623 fe80::1001:2001/112 is simply fe80::1001:2000. The MSID range 1624 0xff000000 through 0xffffffff is reserved for future use. 1626 Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 1627 MNPs can be allocated from that block ensuring that there is no 1628 possibility for overlap between the different MNP- and ADM-LLA 1629 constructs discussed above. 1631 Since MNP-LLAs are based on the distribution of administratively 1632 assured unique MNPs, and since ADM-LLAs are guaranteed unique through 1633 administrative assignment, OMNI interfaces set the autoconfiguration 1634 variable DupAddrDetectTransmits to 0 [RFC4862]. 1636 Note: If future protocol extensions relax the 64-bit boundary in IPv6 1637 addressing, the additional prefix bits of an MNP could be encoded in 1638 bits 16 through 63 of the MNP-LLA. (The most-significant 64 bits 1639 would therefore still be in bits 64-127, and the remaining bits would 1640 appear in bits 16 through 48.) However, the analysis provided in 1641 [RFC7421] suggests that the 64-bit boundary will remain in the IPv6 1642 architecture for the foreseeable future. 1644 Note: Even though this document honors the 64-bit boundary in IPv6 1645 addressing, it specifies prefix lengths longer than /64 for routing 1646 purposes. This effectively extends IPv6 routing determination into 1647 the interface identifier portion of the IPv6 address, but it does not 1648 redefine the 64-bit boundary. Modern routing protocol 1649 implementations honor IPv6 prefixes of all lengths, up to and 1650 including /128. 1652 9. Unique-Local Addresses (ULAs) 1654 OMNI domains use IPv6 Unique-Local Addresses (ULAs) as the source and 1655 destination addresses in OAL packet IPv6 encapsulation headers. ULAs 1656 are only routable within the scope of a an OMNI domain, and are 1657 derived from the IPv6 Unique Local Address prefix fc00::/7 followed 1658 by the L bit set to 1 (i.e., as fd00::/8) followed by a 40-bit 1659 pseudo-random Global ID to produce the prefix [ULA]::/48, which is 1660 then followed by a 16-bit Subnet ID then finally followed by a 64 bit 1661 Interface ID as specified in Section 3 of [RFC4193]. All nodes in 1662 the same OMNI domain configure the same 40-bit Global ID as the OMNI 1663 domain identifier. The statistic uniqueness of the 40-bit pseudo- 1664 random Global ID allows different OMNI domains to be joined together 1665 in the future without requiring renumbering. 1667 Each OMNI link instance is identified by a value between 0x0000 and 1668 0xfeff in bits 48-63 of [ULA]::/48; the values 0xff00 through 0xfffe 1669 are reserved for future use, and the value 0xffff denotes the 1670 presence of a Temporary ULA (see below). For example, OMNI ULAs 1671 associated with instance 0 are configured from the prefix 1672 [ULA]:0000::/64, instance 1 from [ULA]:0001::/64, instance 2 from 1673 [ULA]:0002::/64, etc. ULAs and their associated prefix lengths are 1674 configured in correspondence with LLAs through stateless prefix 1675 translation where "MNP-ULAs" are assigned in correspondence to MNP- 1676 LLAs and "ADM-ULAs" are assigned in correspondence to ADM-LLAs. For 1677 example, for OMNI link instance [ULA]:1010::/64: 1679 o the MNP-ULA corresponding to the MNP-LLA fe80::2001:db8:1:2 with a 1680 56-bit MNP length is derived by copying the lower 64 bits of the 1681 LLA into the lower 64 bits of the ULA as 1682 [ULA]:1010:2001:db8:1:2/120 (where, the ULA prefix length becomes 1683 64 plus the IPv6 MNP length). 1685 o the MNP-ULA corresponding to fe80::ffff:192.0.2.0 with a 28-bit 1686 MNP length is derived by simply writing the LLA interface ID into 1687 the lower 64 bits as [ULA]:1010:0:ffff:192.0.2.0/124 (where, the 1688 ULA prefix length is 64 plus 32 plus the IPv4 MNP length). 1690 o the ADM-ULA corresponding to fe80::1000/112 is simply 1691 [ULA]:1010::1000/112. 1693 o the ADM-ULA corresponding to fe80::/128 is simply 1694 [ULA]:1010::/128. 1696 o etc. 1698 Each OMNI interface assigns the Anycast ADM-ULA specific to the OMNI 1699 link instance. For example, the OMNI interface connected to instance 1700 3 assigns the Anycast address [ULA]:0003::/128. Routers that 1701 configure OMNI interfaces advertise the OMNI service prefix (e.g., 1702 [ULA]:0003::/64) into the local routing system so that applications 1703 can direct traffic according to SBM requirements. 1705 The ULA presents an IPv6 address format that is routable within the 1706 OMNI routing system and can be used to convey link-scoped IPv6 ND 1707 messages across multiple hops using IPv6 encapsulation [RFC2473]. 1708 The OMNI link extends across one or more underling Internetworks to 1709 include all ARs and MSEs. All MNs are also considered to be 1710 connected to the OMNI link, however OAL encapsulation is omitted 1711 whenever possible to conserve bandwidth (see: Section 14). 1713 Each OMNI link can be subdivided into "segments" that often 1714 correspond to different administrative domains or physical 1715 partitions. OMNI nodes can use IPv6 Segment Routing [RFC8402] when 1716 necessary to support efficient forwarding to destinations located in 1717 other OMNI link segments. A full discussion of Segment Routing over 1718 the OMNI link appears in [I-D.templin-intarea-6706bis]. 1720 Temporary ULAs are constructed per [RFC8981] based on the prefix 1721 [ULA]:ffff::/64 and used by MNs when they have no other addresses. 1722 Temporary ULAs can be used for MN-to-MN communications outside the 1723 context of any supporting OMNI link infrastructure, and can also be 1724 used as an initial address while the MN is in the process of 1725 procuring an MNP. Temporary ULAs are not routable within the OMNI 1726 routing system, and are therefore useful only for OMNI link "edge" 1727 communications. Temporary ULAs employ optimistic DAD principles 1728 [RFC4429] since they are probabilistically unique. 1730 Note: IPv6 ULAs taken from the prefix fc00::/7 followed by the L bit 1731 set to 0 (i.e., as fc00::/8) are never used for OMNI OAL addressing, 1732 however the range could be used for MSP and MNP addressing under 1733 certain limiting conditions (see: Section 10). 1735 10. Global Unicast Addresses (GUAs) 1737 OMNI domains use IP Global Unicast Address (GUA) prefixes [RFC4291] 1738 as Mobility Service Prefixes (MSPs) from which Mobile Network 1739 Prefixes (MNP) are delegated to Mobile Nodes (MNs). 1741 For IPv6, GUA prefixes are assigned by IANA [IPV6-GUA] and/or an 1742 associated regional assigned numbers authority such that the OMNI 1743 domain can be interconnected to the global IPv6 Internet without 1744 causing inconsistencies in the routing system. An OMNI domain could 1745 instead use ULAs with the 'L' bit set to 0 (i.e., from the prefix 1746 fc00::/8)[RFC4193], however this would require IPv6 NAT if the domain 1747 were ever connected to the global IPv6 Internet. 1749 For IPv4, GUA prefixes are assigned by IANA [IPV4-GUA] and/or an 1750 associated regional assigned numbers authority such that the OMNI 1751 domain can be interconnected to the global IPv4 Internet without 1752 causing routing inconsistencies. An OMNI domain could instead use 1753 private IPv4 prefixes (e.g., 10.0.0.0/8, etc.) [RFC3330], however 1754 this would require IPv4 NAT if the domain were ever connected to the 1755 global IPv4 Internet. 1757 11. Node Identification 1759 OMNI MNs and MSEs that connect over open Internetworks generate a 1760 Host Identity Tag (HIT) as specified in [RFC7401] and use the value 1761 as a robust general-purpose node identification value. Hierarchical 1762 HITs (HHITs) [I-D.ietf-drip-rid] may provide a useful alternative in 1763 certain domains such as the Unmanned (Air) Traffic Management (UTM) 1764 service for Unmanned Air Systems (UAS). MNs and MSEs can then use 1765 their (H)HITs in IPv6 ND control message exchanges. 1767 When a MN is truly outside the context of any infrastructure, it may 1768 have no MNP information at all. In that case, the MN can use its 1769 (H)HIT as an IPv6 source/destination address for sustained 1770 communications in Vehicle-to-Vehicle (V2V) and (multihop) Vehicle-to- 1771 Infrastructure (V2I) scenarios. The MN can also propagate the (H)HIT 1772 into the multihop routing tables of (collective) Mobile/Vehicular Ad- 1773 hoc Networks (MANETs/VANETs) using only the vehicles themselves as 1774 communications relays. 1776 When a MN connects to ARs over (non-multihop) protected-spectrum 1777 ANETs, an alternate form of node identification (e.g., MAC address, 1778 serial number, airframe identification value, VIN, etc.) may be 1779 sufficient. In that case, the MN should still generate a (H)HIT and 1780 maintain it in conjunction with any other node identifiers. The MN 1781 can then include OMNI "Node Identification" sub-options (see: 1782 Section 12.1.13) in IPv6 ND messages should the need to transmit 1783 identification information over the network arise. 1785 12. Address Mapping - Unicast 1787 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 1788 state and use the link-local address format specified in Section 8. 1789 OMNI interface IPv6 Neighbor Discovery (ND) [RFC4861] messages sent 1790 over physical underlying interfaces without encapsulation observe the 1791 native underlying interface Source/Target Link-Layer Address Option 1792 (S/TLLAO) format (e.g., for Ethernet the S/TLLAO is specified in 1793 [RFC2464]). OMNI interface IPv6 ND messages sent over underlying 1794 interfaces via encapsulation do not include S/TLLAOs which were 1795 intended for encoding physical L2 media address formats and not 1796 encapsulation IP addresses. Furthermore, S/TLLAOs are not intended 1797 for encoding additional interface attributes needed for multilink 1798 coordination. Hence, this document does not define an S/TLLAO format 1799 but instead defines a new option type termed the "OMNI option" 1800 designed for these purposes. 1802 MNs such as aircraft typically have many wireless data link types 1803 (e.g. satellite-based, cellular, terrestrial, air-to-air directional, 1804 etc.) with diverse performance, cost and availability properties. 1805 The OMNI interface would therefore appear to have multiple L2 1806 connections, and may include information for multiple underlying 1807 interfaces in a single IPv6 ND message exchange. OMNI interfaces use 1808 an IPv6 ND option called the OMNI option formatted as shown in 1809 Figure 10: 1811 0 1 2 3 1812 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 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Type | Length | Preflen | S/T-omIndex | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | | 1817 ~ Sub-Options ~ 1818 | | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 Figure 10: OMNI Option Format 1823 In this format: 1825 o Type is set to TBD2. 1827 o Length is set to the number of 8 octet blocks in the option. The 1828 value 0 is invalid, while the values 1 through 255 (i.e., 8 1829 through 2040 octets, respectively) indicate the total length of 1830 the OMNI option. 1832 o Preflen is an 8 bit field that determines the length of prefix 1833 associated with an LLA. Values 0 through 128 specify a valid 1834 prefix length (all other values are invalid). For IPv6 ND 1835 messages sent from a MN to the MS, Preflen applies to the IPv6 1836 source LLA and provides the length that the MN is requesting or 1837 asserting to the MS. For IPv6 ND messages sent from the MS to the 1838 MN, Preflen applies to the IPv6 destination LLA and indicates the 1839 length that the MS is granting to the MN. For IPv6 ND messages 1840 sent between MS endpoints, Preflen provides the length associated 1841 with the source/target MN that is subject of the ND message. 1843 o S/T-omIndex is an 8 bit field corresponds to the omIndex value for 1844 source or target underlying interface used to convey this IPv6 ND 1845 message. OMNI interfaces MUST number each distinct underlying 1846 interface with an omIndex value between '1' and '255' that 1847 represents a MN-specific 8-bit mapping for the actual ifIndex 1848 value assigned by network management [RFC2863] (the omIndex value 1849 '0' is reserved for use by the MS). For RS and NS messages, S/ 1850 T-omIndex corresponds to the source underlying interface the 1851 message originated from. For RA and NA messages, S/T-omIndex 1852 corresponds to the target underlying interface that the message is 1853 destined to. (For NS messages used for Neighbor Unreachability 1854 Detection (NUD), S/T-omIndex instead identifies the neighbor's 1855 underlying interface to be used as the target interface to return 1856 the NA.) 1858 o Sub-Options is a Variable-length field, of length such that the 1859 complete OMNI Option is an integer multiple of 8 octets long. 1860 Contains one or more Sub-Options, as described in Section 12.1. 1862 The OMNI option may appear in any IPv6 ND message type; it is 1863 processed by interfaces that recognize the option and ignored by all 1864 other interfaces. If multiple OMNI option instances appear in the 1865 same IPv6 ND message, the interface processes the Preflen and S/ 1866 T-omIndex fields in the first instance and ignores those fields in 1867 all other instances. The interface processes the Sub-Options of all 1868 OMNI option instances in the same IPv6 ND message in the consecutive 1869 order in which they appear. 1871 The OMNI option(s) in each IPv6 ND message may include full or 1872 partial information for the neighbor. The union of the information 1873 in the most recently received OMNI options is therefore retained, and 1874 the information is aged/removed in conjunction with the corresponding 1875 neighbor cache entry. 1877 12.1. Sub-Options 1879 Each OMNI option includes zero or more Sub-Options. Each consecutive 1880 Sub-Option is concatenated immediately after its predecessor. All 1881 Sub-Options except Pad1 (see below) are in type-length-value (TLV) 1882 encoded in the following format: 1884 0 1 2 1885 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 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1887 | Sub-Type| Sub-length | Sub-Option Data ... 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1890 Figure 11: Sub-Option Format 1892 o Sub-Type is a 5-bit field that encodes the Sub-Option type. Sub- 1893 Options defined in this document are: 1895 Sub-Option Name Sub-Type 1896 Pad1 0 1897 PadN 1 1898 Interface Attributes (Type 1) 2 1899 Interface Attributes (Type 2) 3 1900 Traffic Selector 4 1901 MS-Register 5 1902 MS-Release 6 1903 Geo Coordinates 7 1904 DHCPv6 Message 8 1905 HIP Message 9 1906 Reassembly Limit 10 1907 Fragmentation Report 11 1908 Node Identification 12 1909 Sub-Type Extension 30 1911 Figure 12 1913 Sub-Types 13-29 are available for future assignment for major 1914 protocol functions. Sub-Type 31 is reserved by IANA. 1916 o Sub-Length is an 11-bit field that encodes the length of the Sub- 1917 Option Data ranging from 0 to 2034 octets. 1919 o Sub-Option Data is a block of data with format determined by Sub- 1920 Type and length determined by Sub-Length. 1922 During transmission, the OMNI interface codes Sub-Type and Sub-Length 1923 together in network byte order in 2 consecutive octets, where Sub- 1924 Option Data may be up to 2034 octets in length. This allows ample 1925 space for coding large objects (e.g., ASCII strings, domain names, 1926 protocol messages, security codes, etc.), while a single OMNI option 1927 is limited to 2040 octets the same as for any IPv6 ND option. If the 1928 Sub-Options to be coded would cause an OMNI option to exceed 2040 1929 octets, the OMNI interface codes any remaining Sub-Options in 1930 additional OMNI option instances in the intended order of processing 1931 in the same IPv6 ND message. Implementations must therefore observe 1932 size limitations, and must refrain from sending IPv6 ND messages 1933 larger than the OMNI interface MTU. If the available OMNI 1934 information would cause a single IPv6 ND message to exceed the OMNI 1935 interface MTU, the OMNI interface codes as much as possible in a 1936 first IPv6 ND message and codes the remainder in additional IPv6 ND 1937 messages. 1939 During reception, the OMNI interface processes each OMNI option Sub- 1940 Option while skipping over and ignoring any unrecognized Sub-Options. 1941 The OMNI interface processes the Sub-Options of all OMNI option 1942 instances in the consecutive order in which they appear in the IPv6 1943 ND message, beginning with the first instance and continuing through 1944 any additional instances to the end of the message. If a Sub-Option 1945 length would cause processing to exceed the OMNI option total length, 1946 the OMNI interface accepts any Sub-Options already processed and 1947 ignores the final Sub-Option. The interface then processes any 1948 remaining OMNI options in the same fashion to the end of the IPv6 ND 1949 message. 1951 Note: large objects that exceed the Sub-Option Data limit of 2034 1952 octets are not supported under the current specification; if this 1953 proves to be limiting in practice, future specifications may define 1954 support for fragmenting large objects across multiple OMNI options 1955 within the same IPv6 ND message. 1957 The following Sub-Option types and formats are defined in this 1958 document: 1960 12.1.1. Pad1 1962 0 1963 0 1 2 3 4 5 6 7 1964 +-+-+-+-+-+-+-+-+ 1965 | S-Type=0|x|x|x| 1966 +-+-+-+-+-+-+-+-+ 1968 Figure 13: Pad1 1970 o Sub-Type is set to 0. If multiple instances appear in OMNI 1971 options of the same message all are processed. 1973 o Sub-Type is followed by 3 'x' bits, set to any value on 1974 transmission (typically all-zeros) and ignored on receipt. Pad1 1975 therefore consists of 1 octet with the most significant 5 bits set 1976 to 0, and with no Sub-Length or Sub-Option Data fields following. 1978 12.1.2. PadN 1980 0 1 2 1981 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 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1983 | S-Type=1| Sub-length=N | N padding octets ... 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1986 Figure 14: PadN 1988 o Sub-Type is set to 1. If multiple instances appear in OMNI 1989 options of the same message all are processed. 1991 o Sub-Length is set to N (from 0 to 2034) that encodes the number of 1992 padding octets that follow. 1994 o Sub-Option Data consists of N octets, set to any value on 1995 transmission (typically all-zeros) and ignored on receipt. 1997 12.1.3. Interface Attributes (Type 1) 1999 The Interface Attributes (Type 1) sub-option provides a basic set of 2000 attributes for underlying interfaces. Interface Attributes (Type 1) 2001 is deprecated throughout the rest of this specification, and 2002 Interface Attributes (Type 2) (see: Section 12.1.4) are indicated 2003 wherever the term "Interface Attributes" appears without an 2004 associated Type designation. 2006 Nodes SHOULD NOT include Interface Attributes (Type 1) sub-options in 2007 IPv6 ND messages they send, and MUST ignore any in IPv6 ND messages 2008 they receive. If an Interface Attributes (Type 1) is included, it 2009 must have the following format: 2011 0 1 2 3 2012 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 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | Sub-Type=2| Sub-length=N | omIndex | omType | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Provider ID | Link | Resvd |P00|P01|P02|P03|P04|P05|P06|P07| 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 |P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19|P20|P21|P22|P23| 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 |P24|P25|P26|P27|P28|P29|P30|P31|P32|P33|P34|P35|P36|P37|P38|P39| 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 |P40|P41|P42|P43|P44|P45|P46|P47|P48|P49|P50|P51|P52|P53|P54|P55| 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 |P56|P57|P58|P59|P60|P61|P62|P63| 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 Figure 15: Interface Attributes (Type 1) 2029 o Sub-Type is set to 2. If multiple instances with different 2030 omIndex values appear in OMNI option of the same message all are 2031 processed; if multiple instances with the same omIndex value 2032 appear, the first is processed and all others are ignored 2034 o Sub-Length is set to N (from 4 to 2034) that encodes the number of 2035 Sub-Option Data octets that follow. 2037 o omIndex is a 1-octet field containing a value from 0 to 255 2038 identifying the underlying interface for which the attributes 2039 apply. 2041 o omType is a 1-octet field containing a value from 0 to 255 2042 corresponding to the underlying interface identified by omIndex. 2044 o Provider ID is a 1-octet field containing a value from 0 to 255 2045 corresponding to the underlying interface identified by omIndex. 2047 o Link encodes a 4-bit link metric. The value '0' means the link is 2048 DOWN, and the remaining values mean the link is UP with metric 2049 ranging from '1' ("lowest") to '15' ("highest"). 2051 o Resvd is reserved for future use. Set to 0 on transmission and 2052 ignored on reception. 2054 o A 16-octet ""Preferences" field immediately follows 'Resvd', with 2055 values P[00] through P[63] corresponding to the 64 Differentiated 2056 Service Code Point (DSCP) values [RFC2474]. Each 2-bit P[*] field 2057 is set to the value '0' ("disabled"), '1' ("low"), '2' ("medium") 2058 or '3' ("high") to indicate a QoS preference for underlying 2059 interface selection purposes. 2061 12.1.4. Interface Attributes (Type 2) 2063 The Interface Attributes (Type 2) sub-option provides L2 forwarding 2064 information for the multilink conceptual sending algorithm discussed 2065 in Section 14. The L2 information is used for selecting among 2066 potentially multiple candidate underlying interfaces that can be used 2067 to forward carrier packets to the neighbor based on factors such as 2068 DSCP preferences and link quality. Interface Attributes (Type 2) 2069 further includes link-layer address information to be used for either 2070 OAL encapsulation or direct UDP/IP encapsulation (when OAL 2071 encapsulation can be avoided). 2073 Interface Attributes (Type 2) are the sole Interface Attributes 2074 format in this specification that all OMNI nodes must honor. 2075 Wherever the term "Interface Attributes" occurs throughout this 2076 specification without a "Type" designation, the format given below is 2077 indicated: 2079 0 1 2 3 2080 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 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | S-Type=3| Sub-length=N | omIndex | omType | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | Provider ID | Link |R| API | SRT | FMT | LHS (0 - 7) | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | LHS (bits 8 - 31) | ~ 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 2088 ~ ~ 2089 ~ Link Layer Address (L2ADDR) ~ 2090 ~ ~ 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Bitmap(0)=0xff|P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11| 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 |P12|P13|P14|P15|P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27| 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 |P28|P29|P30|P31| Bitmap(1)=0xff|P32|P33|P34|P35|P36| ... 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2099 Figure 16: Interface Attributes (Type 2) 2101 o Sub-Type is set to 3. If multiple instances with different 2102 omIndex values appear in OMNI options of the same message all are 2103 processed; if multiple instances with the same omIndex value 2104 appear, the first is processed and all others are ignored. 2106 o Sub-Length is set to N (from 4 to 2034) that encodes the number of 2107 Sub-Option Data octets that follow. The 'omIndex', 'omType', 2108 'Provider ID', 'Link', 'R' and 'API' fields are always present; 2109 hence, the remainder of the Sub-Option Data is limited to 2030 2110 octets. 2112 o Sub-Option Data contains an "Interface Attributes (Type 2)" option 2113 encoded as follows: 2115 * omIndex is set to an 8-bit integer value corresponding to a 2116 specific underlying interface the same as specified above for 2117 the OMNI option S/T-omIndex field. The OMNI options of a same 2118 message may include multiple Interface Attributes Sub-Options, 2119 with each distinct omIndex value pertaining to a different 2120 underlying interface. The OMNI option will often include an 2121 Interface Attributes Sub-Option with the same omIndex value 2122 that appears in the S/T-omIndex. In that case, the actual 2123 encapsulation address of the received IPv6 ND message should be 2124 compared with the L2ADDR encoded in the Sub-Option (see below); 2125 if the addresses are different (or, if L2ADDR is absent) the 2126 presence of a NAT is assumed. 2128 * omType is set to an 8-bit integer value corresponding to the 2129 underlying interface identified by omIndex. The value 2130 represents an OMNI interface-specific 8-bit mapping for the 2131 actual IANA ifType value registered in the 'IANAifType-MIB' 2132 registry [http://www.iana.org]. 2134 * Provider ID is set to an OMNI interface-specific 8-bit ID value 2135 for the network service provider associated with this omIndex. 2137 * Link encodes a 4-bit link metric. The value '0' means the link 2138 is DOWN, and the remaining values mean the link is UP with 2139 metric ranging from '1' ("lowest") to '15' ("highest"). 2141 * R is reserved for future use. 2143 * API - a 3-bit "Address/Preferences/Indexed" code that 2144 determines the contents of the remainder of the sub-option as 2145 follows: 2147 + When the most significant bit (i.e., "Address") is set to 1, 2148 the SRT, FMT, LHS and L2ADDR fields are included immediately 2149 following the API code; else, they are omitted. 2151 + When the next most significant bit (i.e., "Preferences") is 2152 set to 1, a preferences block is included next; else, it is 2153 omitted. (Note that if "Address" is set the preferences 2154 block immediately follows L2ADDR; else, it immediately 2155 follows the API code.) 2157 + When a preferences block is present and the least 2158 significant bit (i.e., "Indexed") is set to 0, the block is 2159 encoded in "Simplex" form as shown in Figure 15; else it is 2160 encoded in "Indexed" form as discussed below. 2162 * When API indicates that an "Address" is included, the following 2163 fields appear in consecutive order (else, they are omitted): 2165 + SRT - a 5-bit Segment Routing Topology prefix length value 2166 that (when added to 96) determines the prefix length to 2167 apply to the ULA formed from concatenating [ULA*]::/96 with 2168 the 32 bit LHS MSID value that follows. For example, the 2169 value 16 corresponds to the prefix length 112. 2171 + FMT - a 3-bit "Framework/Mode/Type" code corresponding to 2172 the included Link Layer Address as follows: 2174 - When the most significant bit (i.e., "Framework") is set 2175 to 1, L2ADDR is the INET encapsulation address for the 2176 Source/Target Client itself; otherwise L2ADDR is the 2177 address of the Proxy/Server named in the LHS. 2179 - When the next most significant bit (i.e., "Mode") is set 2180 to 1, the Framework node is (likely) located behind an 2181 INET Network Address Translator (NAT); otherwise, it is 2182 on the open INET. 2184 - When the least significant bit (i.e., "Type") is set to 2185 0, L2ADDR includes a UDP Port Number followed by an IPv4 2186 address; otherwise, it includes a UDP Port Number 2187 followed by an IPv6 address. 2189 + LHS - the 32 bit MSID of the Last Hop Proxy/Server on the 2190 path to the target. When SRT and LHS are both set to 0, the 2191 LHS is considered unspecified in this IPv6 ND message. When 2192 SRT is set to 0 and LHS is non-zero, the prefix length is 2193 set to 128. SRT and LHS together provide guidance to the 2194 OMNI interface forwarding algorithm. Specifically, if SRT/ 2195 LHS is located in the local OMNI link segment then the OMNI 2196 interface can encapsulate according to FMT/L2ADDR (following 2197 any necessary NAT traversal messaging); else, it must 2198 forward according to the OMNI link spanning tree. See 2199 [I-D.templin-intarea-6706bis] for further discussion. 2201 + Link Layer Address (L2ADDR) - Formatted according to FMT, 2202 and identifies the link-layer address (i.e., the 2203 encapsulation address) of the source/target. The UDP Port 2204 Number appears in the first 2 octets and the IP address 2205 appears in the next 4 octets for IPv4 or 16 octets for IPv6. 2206 The Port Number and IP address are recorded in network byte 2207 order, and in ones-compliment "obfuscated" form per 2208 [RFC4380]. The OMNI interface forwarding algorithm uses 2209 FMT/L2ADDR to determine the encapsulation address for 2210 forwarding when SRT/LHS is located in the local OMNI link 2211 segment. Note that if the target is behind a NAT, L2ADDR 2212 will contain the mapped INET address stored in the NAT; 2213 otherwise, L2ADDR will contain the native INET information 2214 of the target itself. 2216 * When API indicates that "Preferences" are included, a 2217 preferences block appears as the remainder of the Sub-Option as 2218 a series of Bitmaps and P[*] values. In "Simplex" form, the 2219 index for each singleton Bitmap octet is inferred from its 2220 sequential position (i.e., 0, 1, 2, ...) as shown in Figure 16. 2221 In "Indexed" form, each Bitmap is preceded by an Index octet 2222 that encodes a value "i" = (0 - 255) as the index for its 2223 companion Bitmap as follows: 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2226 | Index=i | Bitmap(i) |P[*] values ... 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2229 Figure 17 2231 * The preferences consist of a first (simplex/indexed) Bitmap 2232 (i.e., "Bitmap(i)") followed by 0-8 single-octet blocks of 2233 2-bit P[*] values, followed by a second Bitmap (i), followed by 2234 0-8 blocks of P[*] values, etc. Reading from bit 0 to bit 7, 2235 the bits of each Bitmap(i) that are set to '1'' indicate the 2236 P[*] blocks from the range P[(i*32)] through P[(i*32) + 31] 2237 that follow; if any Bitmap(i) bits are '0', then the 2238 corresponding P[*] block is instead omitted. For example, if 2239 Bitmap(0) contains 0xff then the block with P[00]-P[03], 2240 followed by the block with P[04]-P[07], etc., and ending with 2241 the block with P[28]-P[31] are included (as shown in 2242 Figure 15). The next Bitmap(i) is then consulted with its bits 2243 indicating which P[*] blocks follow, etc. out to the end of the 2244 Sub-Option. 2246 * Each 2-bit P[*] field is set to the value '0' ("disabled"), '1' 2247 ("low"), '2' ("medium") or '3' ("high") to indicate a QoS 2248 preference for underlying interface selection purposes. Not 2249 all P[*] values need to be included in the OMNI option of each 2250 IPv6 ND message received. Any P[*] values represented in an 2251 earlier OMNI option but omitted in the current OMNI option 2252 remain unchanged. Any P[*] values not yet represented in any 2253 OMNI option default to "medium". 2255 * The first 16 P[*] blocks correspond to the 64 Differentiated 2256 Service Code Point (DSCP) values P[00] - P[63] [RFC2474]. Any 2257 additional P[*] blocks that follow correspond to "pseudo-DSCP" 2258 traffic classifier values P[64], P[65], P[66], etc. See 2259 Appendix A for further discussion and examples. 2261 12.1.5. Traffic Selector 2262 0 1 2 3 2263 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 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | S-Type=4| Sub-length=N | omIndex | ~ 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 2267 ~ ~ 2268 ~ RFC 6088 Format Traffic Selector ~ 2269 ~ ~ 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 Figure 18: Traffic Selector 2274 o Sub-Type is set to 4. If multiple instances appear in OMNI 2275 options of the same message all are processed, i.e., even if the 2276 same omIndex value appears multiple times. 2278 o Sub-Length is set to N (from 1 to 2034) that encodes the number of 2279 Sub-Option Data octets that follow. 2281 o Sub-Option Data contains a 1 octet omIndex encoded exactly as 2282 specified in Section 12.1.3, followed by an N-1 octet traffic 2283 selector formatted per [RFC6088] beginning with the "TS Format" 2284 field. The largest traffic selector for a given omIndex is 2285 therefore 2033 octets. 2287 12.1.6. MS-Register 2289 0 1 2 3 2290 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 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | S-Type=5| Sub-length=4n | MSID[1] (bits 0 - 15) | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | MSID [1] (bits 16 - 32) | MSID[2] (bits 0 - 15) | 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | MSID [2] (bits 16 - 32) | MSID[3] (bits 0 - 15) | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 ... ... ... ... ... ... 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | MSID [n] (bits 16 - 32) | 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 Figure 19: MS-Register Sub-option 2305 o Sub-Type is set to 5. If multiple instances appear in OMNI 2306 options of the same message all are processed. Only the first 2307 MAX_MSID values processed (whether in a single instance or 2308 multiple) are retained and all other MSIDs are ignored. 2310 o Sub-Length is set to 4n, with 508 as the maximum value for n. The 2311 length of the Sub-Option Data section is therefore limited to 2032 2312 octets. 2314 o A list of n 4 octet MSIDs is included in the following 4n octets. 2315 The Anycast MSID value '0' in an RS message MS-Register sub-option 2316 requests the recipient to return the MSID of a nearby MSE in a 2317 corresponding RA response. 2319 12.1.7. MS-Release 2321 0 1 2 3 2322 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 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2324 | S-Type=6| Sub-length=4n | MSID[1] (bits 0 - 15) | 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 | MSID [1] (bits 16 - 32) | MSID[2] (bits 0 - 15) | 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | MSID [2] (bits 16 - 32) | MSID[3] (bits 0 - 15) | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 ... ... ... ... ... ... 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | MSID [n] (bits 16 - 32) | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 Figure 20: MS-Release Sub-option 2337 o Sub-Type is set to 6. If multiple instances appear in OMNI 2338 options of the same message all are processed. Only the first 2339 MAX_MSID values processed (whether in a single instance or 2340 multiple) are retained and all other MSIDs are ignored. 2342 o Sub-Length is set to 4n, with 508 as the maximum value for n. The 2343 length of the Sub-Option Data section is therefore limited to 2032 2344 octets. 2346 o A list of n 4 octet MSIDs is included in the following 4n octets. 2347 The Anycast MSID value '0' is ignored in MS-Release sub-options, 2348 i.e., only non-zero values are processed. 2350 12.1.8. Geo Coordinates 2351 0 1 2 3 2352 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 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | S-Type=7| Sub-length=N | Geo Coordinates 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 2357 Figure 21: Geo Coordinates Sub-option 2359 o Sub-Type is set to 7. If multiple instances appear in OMNI 2360 options of the same message the first is processed and all others 2361 are ignored. 2363 o Sub-Length is set to N (from 0 to 2034) that encodes the number of 2364 Sub-Option Data octets that follow. 2366 o A set of Geo Coordinates of maximum length 2034 octets. Format(s) 2367 to be specified in future documents; should include Latitude/ 2368 Longitude, plus any additional attributes such as altitude, 2369 heading, speed, etc. 2371 12.1.9. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Message 2373 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) sub-option 2374 may be included in the OMNI options of RS messages sent by MNs and RA 2375 messages returned by MSEs. ARs that act as proxys to forward RS/RA 2376 messages between MNs and MSEs also forward DHCPv6 sub-options 2377 unchanged and do not process DHCPv6 sub-options themselves. Note 2378 that DHCPv6 message sub-option integrity is protected by the Checksum 2379 included in the IPv6 ND message header. 2381 0 1 2 3 2382 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 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | S-Type=8| Sub-length=N | msg-type | id (octet 0) | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | transaction-id (octets 1-2) | | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2388 | | 2389 . DHCPv6 options . 2390 . (variable number and length) . 2391 | | 2392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 Figure 22: DHCPv6 Message Sub-option 2396 o Sub-Type is set to 8. If multiple instances appear in OMNI 2397 options of the same message the first is processed and all others 2398 are ignored. 2400 o Sub-Length is set to N (from 4 to 2034) that encodes the number of 2401 Sub-Option Data octets that follow. The 'msg-type' and 2402 'transaction-id' fields are always present; hence, the length of 2403 the DHCPv6 options is restricted to 2030 octets. 2405 o 'msg-type' and 'transaction-id' are coded according to Section 8 2406 of [RFC8415]. 2408 o A set of DHCPv6 options coded according to Section 21 of [RFC8415] 2409 follows. 2411 12.1.10. Host Identity Protocol (HIP) Message 2413 The Host Identity Protocol (HIP) Message sub-option may be included 2414 in the OMNI options of RS messages sent by MNs and RA messages 2415 returned by ARs. ARs that act as proxys authenticate and remove HIP 2416 messages in RS messages they forward from a MN to an MSE. ARs that 2417 act as proxys insert and sign HIP messages in the RA messages they 2418 forward from an MSE to a MN. 2420 The HIP message sub-option may also be included in any IPv6 ND 2421 message that may traverse an open Internetwork, i.e., where link- 2422 layer authentication is not already assured by lower layers. 2424 0 1 2 3 2425 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 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 | S-Type=9| Sub-length=N |0| Packet Type |Version| RES.|1| 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | Checksum | Controls | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | Sender's Host Identity Tag (HIT) | 2432 | | 2433 | | 2434 | | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Receiver's Host Identity Tag (HIT) | 2437 | | 2438 | | 2439 | | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | | 2442 / HIP Parameters / 2443 / / 2444 | | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 Figure 23: HIP Message Sub-option 2449 o Sub-Type is set to 9. If multiple instances appear in OMNI 2450 options of the same message the first is processed and all others 2451 are ignored. 2453 o Sub-Length is set to N, i.e., the length of the option in octets 2454 beginning immediately following the Sub-Length field and extending 2455 to the end of the HIP parameters. The length of the entire HIP 2456 message is therefore restricted to 2034 octets. 2458 o The HIP message is coded exactly as specified in Section 5 of 2459 [RFC7401], except that the OMNI "Sub-Type" and "Sub-Length" fields 2460 replace the first 2 octets of the HIP message header (i.e., the 2461 Next Header and Header Length fields). Note that, since the IPv6 2462 ND message header already includes a Checksum, the HIP message 2463 Checksum field is set to 0 on transmission and ignored on 2464 reception. (The Checksum field is still included to retain the 2465 [RFC7401] message format.) 2467 12.1.11. Reassembly Limit 2469 The Reassembly Limit sub-option may be included in the OMNI options 2470 of IPv6 ND messages. The message consists of a 14-bit Reassembly 2471 Limit value, followed by two flag bits (H, L) optionally followed by 2472 an (N-2)-octet leading portion of an OAL First Fragment that 2473 triggered the message. 2475 0 1 2 3 2476 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 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 |S-Type=10| Sub-length=N | Reassembly Limit |H|L| 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | OAL First Fragment (As much of invoking packet | 2481 + as possible without the IPv6 ND message + 2482 | exceeding the minimum IPv6 MTU) | 2483 + + 2485 Figure 24: Reassembly Limit 2487 o Sub-Type is set to 10. If multiple instances appear in OMNI 2488 options of the same message the first occurring "hard" and "soft" 2489 Reassembly Limit values are accepted, and any additional 2490 Reassembly Limit values are ignored. 2492 o Sub-Length is set to 2 if no OAL First Fragment is included, or to 2493 a value N greater than 2 if an OAL First Fragment is included. 2495 o A 14-bit Reassembly Limit follows, and includes a value between 2496 1500 and 9180. If any other value is included, the sub-option is 2497 ignored. The value indicates the hard or soft limit for original 2498 IP packets that the source of the message is currently willing to 2499 reassemble; the source may increase or decrease the hard or soft 2500 limit at any time through the transmission of new IPv6 ND 2501 messages. Until the first IPv6 ND message with a Reassembly Limit 2502 sub-option arrives, OMNI nodes assume initial default hard/soft 2503 limits of 9180 bytes (I.e., the OMNI interface MRU). After IPv6 2504 ND messages with Reassembly Limit sub-options arrive, the OMNI 2505 node retains the most recent hard/soft limit values until new IPv6 2506 ND messages with different values arrive. 2508 o The 'H' flag is set to 1 if the Reassembly Limit is a "Hard" 2509 limit, and set to 0 if the Reassembly Limit is a "Soft" limit. 2511 o The 'L' flag is set to 1 if an OAL First Fragment corresponding to 2512 a reassembly loss event was included; otherwise set to 0. 2514 o If N is greater than 2, the remainder of the Reassembly Limit sub- 2515 option encodes the leading portion of an OAL First Fragment that 2516 prompted this IPv6 ND message. The first fragment is included 2517 beginning with the OAL IPv6 header, and continuing with as much of 2518 the fragment payload as possible without causing the IPv6 ND 2519 message to exceed the minimum IPv6 MTU. (Note that only the OAL 2520 First Fragment is consulted regardless of its size, and without 2521 waiting for additional fragments.) 2523 12.1.12. Fragmentation Report 2525 The Fragmentation Report may be included in the OMNI options of uNA 2526 messages sent from an OAL destination to an OAL source. The message 2527 consists of (N / 8)-many (Identification, Bitmap)-tuples which 2528 include the Identification values of OAL fragments received plus a 2529 Bitmap marking the ordinal positions of individual fragments received 2530 and fragments missing. 2532 0 1 2 3 2533 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 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 |S-Type=11| Sub-Length = N | Identification #1 (bits 0 -15)| 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 | Identification #1 (bits 15-31)| Bitmap #1 (bits 0 - 15) | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | Bitmap #1 (bits 16-31) | Identification #2 (bits 0 -15)| 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | Identification #2 (bits 15-31)| Bitmap #2 (bits 0 - 15) | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Bitmap #2 (bits 16-31) | Identification #3 (bits 0 -15)| 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Identification #3 (bits 15-31)| Bitmap #3 (bits 0 - 15) | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Bitmap #3 (bits 16-31) | ... | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... + 2549 | ... | 2550 + ... + 2552 Figure 25: Fragmentation Report 2554 o Sub-Type is set to 11. If multiple instances appear in OMNI 2555 options of the same message all are processed. 2557 o Sub-Length is set to N, i.e., the length of the option in octets 2558 beginning immediately following the Sub-Length field and extending 2559 to the end of the ICMPv6 error message body. N must be an 2560 integral multiple of 8 octets; otherwise, the sub-option is 2561 ignored. The length of the entire sub-option should not cause the 2562 entire IPv6 ND message to exceed the minimum MPS. 2564 o Identification (i) includes the IPv6 Identification value found in 2565 the Fragment Header of a received OAL fragment. (Only those 2566 Identification values included represent fragments for which loss 2567 was unambiguously observed; any Identification values not included 2568 correspond to fragments that were either received in their 2569 entirety or are still in transit.) 2571 o Bitmap (i) includes an ordinal checklist of fragments, with each 2572 bit set to 1 for a fragment received or 0 for a fragment missing. 2573 For example, for a 20-fragment fragmented OAL packet with ordinal 2574 fragments #3, #10, #13 and #17 missing and all other fragments 2575 received, the bitmap would encode: 2577 0 1 2 2578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2580 |1|1|1|0|1|1|1|1|1|1|0|1|1|0|1|1|1|0|1|1|0|0|0|... 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2583 Figure 26 2585 (Note that loss of an OAL atomic fragment is indicated by a 2586 Bitmap(i) with all bits set to 0.) 2588 12.1.13. Node Identification 2590 0 1 2 3 2591 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 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 |S-Type=12| Sub-length=N | ID-Type | ~ 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 2595 ~ Node Identification Value (N-1 octets) ~ 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 Figure 27: Node Identification 2600 o Sub-Type is set to 12. If multiple instances appear in OMNI 2601 options of the same IPv6 ND message the first instance of a 2602 specific ID-Type is processed and all other instances of the same 2603 ID-Type are ignored. (Note therefore that it is possible for a 2604 single IPv6 ND message to convey multiple Node Identifications - 2605 each having a different ID-Type.) 2607 o Sub-Length is set to N (from 1 to 2034) that encodes the number of 2608 Sub-Option Data octets that follow. The ID-Type field is always 2609 present; hence, the maximum Node Identification Value length is 2610 2033 octets. 2612 o ID-Type is a 1 octet field that encodes the type of the Node 2613 Identification Value. The following ID-Type values are currently 2614 defined: 2616 * 0 - Universally Unique IDentifier (UUID) [RFC4122]. Indicates 2617 that Node Identification Value contains a 16 octet UUID. 2619 * 1 - Host Identity Tag (HIT) [RFC7401]. Indicates that Node 2620 Identification Value contains a 16 octet HIT. 2622 * 2 - Hierarchical HIT (HHIT) [I-D.ietf-drip-rid]. Indicates 2623 that Node Identification Value contains a 16 octet HHIT. 2625 * 3 - Network Access Identifier (NAI) [RFC7542]. Indicates that 2626 Node Identification Value contains an N-1 octet NAI. 2628 * 4 - Fully-Qualified Domain Name (FQDN) [RFC1035]. Indicates 2629 that Node Identification Value contains an N-1 octet FQDN. 2631 * 5 - 252 - Unassigned. 2633 * 253-254 - Reserved for experimentation, as recommended in 2634 [RFC3692]. 2636 * 255 - reserved by IANA. 2638 o Node Identification Value is an (N - 1) octet field encoded 2639 according to the appropriate the "ID-Type" reference above. 2641 When a Node Identification Value is needed for DHCPv6 messaging 2642 purposes, it is encoded as a DHCP Unique IDentifier (DUID) using the 2643 "DUID-EN for OMNI" format with enterprise number 45282 (see: 2644 Section 25) as shown in Figure 28: 2646 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 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | DUID-Type (2) | EN (high bits == 0) | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | EN (low bits = 45282) | ID-Type | | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2652 . Node Identification Value . 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 Figure 28: DUID-EN for OMNI Format 2657 In this format, the ID-Type and Node Identification Value fields are 2658 coded exactly as in Figure 27 following the 6 octet DUID-EN header, 2659 and the entire "DUID-EN for OMNI" is included in a DHCPv6 message per 2660 [RFC8415]. 2662 12.1.14. Sub-Type Extension 2664 Since the Sub-Type field is only 5 bits in length, future 2665 specifications of major protocol functions may exhaust the remaining 2666 Sub-Type values available for assignment. This document therefore 2667 defines Sub-Type 30 as an "extension", meaning that the actual sub- 2668 option type is determined by examining a 1 octet "Extension-Type" 2669 field immediately following the Sub-Length field. The Sub-Type 2670 Extension is formatted as shown in Figure 29: 2672 0 1 2 3 2673 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 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 |S-Type=30| Sub-length=N | Extension-Type| ~ 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 2677 ~ ~ 2678 ~ Extension-Type Body ~ 2679 ~ ~ 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 Figure 29: Sub-Type Extension 2684 o Sub-Type is set to 30. If multiple instances appear in OMNI 2685 options of the same message all are processed, where each 2686 individual extension defines its own policy for processing 2687 multiple of that type. 2689 o Sub-Length is set to N (from 1 to 2034) that encodes the number of 2690 Sub-Option Data octets that follow. The Extension-Type field is 2691 always present; hence, the maximum Extension-Type Body length is 2692 2033 octets. 2694 o Extension-Type contains a 1 octet Sub-Type Extension value between 2695 0 and 255. 2697 o Extension-Type Body contains an N-1 octet block with format 2698 defined by the given extension specification. 2700 Extension-Type values 2 through 252 are available for assignment by 2701 future specifications, which must also define the format of the 2702 Extension-Type Body and its processing rules. Extension-Type values 2703 253 and 254 are reserved for experimentation, as recommended in 2704 [RFC3692], and value 255 is reserved by IANA. Extension-Type values 2705 0 and 1 are defined in the following subsections: 2707 12.1.14.1. RFC4380 UDP/IP Header Option 2709 0 1 2 3 2710 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 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 |S-Type=30| Sub-length=N | Ext-Type=0 | Header Type | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 ~ Header Option Value ~ 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 Figure 30: RFC4380 UDP/IP Header Option (Extension-Type 0) 2719 o Sub-Type is set to 30. 2721 o Sub-Length is set to N (from 2 to 2034) that encodes the number of 2722 Sub-Option Data octets that follow. The Extension-Type and Header 2723 Type fields are always present; hence, the maximum-length Header 2724 Option Value is 2032 octets. 2726 o Extension-Type is set to 0. Each instance encodes exactly one 2727 header option per Section 5.1.1 of [RFC4380], with the leading '0' 2728 octet omitted and the following octet coded as Header Type. If 2729 multiple instances of the same Header Type appear in OMNI options 2730 of the same message the first instance is processed and all others 2731 are ignored. 2733 o Header Type and Header Option Value are coded exactly as specified 2734 in Section 5.1.1 of [RFC4380]; the following types are currently 2735 defined: 2737 * 0 - Origin Indication (IPv4) - value coded per Section 5.1.1 of 2738 [RFC4380]. 2740 * 1 - Authentication Encapsulation - value coded per 2741 Section 5.1.1 of [RFC4380]. 2743 * 2 - Origin Indication (IPv6) - value coded per Section 5.1.1 of 2744 [RFC4380], except that the address is a 16-octet IPv6 address 2745 instead of a 4-octet IPv4 address. 2747 o Header Type values 3 through 252 are available for assignment by 2748 future specifications, which must also define the format of the 2749 Header Option Value and its processing rules. Header Type values 2750 253 and 254 are reserved for experimentation, as recommended in 2751 [RFC3692], and value 255 is Reserved by IANA. 2753 12.1.14.2. RFC6081 UDP/IP Trailer Option 2755 0 1 2 3 2756 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 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 |S-Type=30| Sub-length=N | Ext-Type=1 | Trailer Type | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 ~ Trailer Option Value ~ 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 Figure 31: RFC6081 UDP/IP Trailer Option (Extension-Type 1) 2765 o Sub-Type is set to 30. 2767 o Sub-Length is set to N (from 2 to 2034) that encodes the number of 2768 Sub-Option Data octets that follow. The Extension-Type and 2769 Trailer Type fields are always present; hence, the maximum-length 2770 Trailer Option Value is 2032 octets. 2772 o Extension-Type is set to 1. Each instance encodes exactly one 2773 trailer option per Section 4 of [RFC6081]. If multiple instances 2774 of the same trailer type appear in OMNI options of the same 2775 message the first instance is processed and all others ignored. 2777 o Trailer Type and Trailer Option Value are coded exactly as 2778 specified in Section 4 of [RFC6081]; the following Trailer Types 2779 are currently defined: 2781 * 0 - Unassigned 2783 * 1 - Nonce Trailer - value coded per Section 4.2 of [RFC6081]. 2785 * 2 - Unassigned 2787 * 3 - Alternate Address Trailer (IPv4) - value coded per 2788 Section 4.3 of [RFC6081]. 2790 * 4 - Neighbor Discovery Option Trailer - value coded per 2791 Section 4.4 of [RFC6081]. 2793 * 5 - Random Port Trailer - value coded per Section 4.5 of 2794 [RFC6081]. 2796 * 6 - Alternate Address Trailer (IPv6) - value coded per 2797 Section 4.3 of [RFC6081], except that each address is a 2798 16-octet IPv6 address instead of a 4-octet IPv4 address. 2800 o Trailer Type values 7 through 252 are available for assignment by 2801 future specifications, which must also define the format of the 2802 Trailer Option Value and its processing rules. Trailer Type 2803 values 253 and 254 are reserved for experimentation, as 2804 recommended in [RFC3692], and value 255 is Reserved by IANA. 2806 13. Address Mapping - Multicast 2808 The multicast address mapping of the native underlying interface 2809 applies. The mobile router on board the MN also serves as an IGMP/ 2810 MLD Proxy for its EUNs and/or hosted applications per [RFC4605] while 2811 using the L2 address of the AR as the L2 address for all multicast 2812 packets. 2814 The MN uses Multicast Listener Discovery (MLDv2) [RFC3810] to 2815 coordinate with the AR, and *NET L2 elements use MLD snooping 2816 [RFC4541]. 2818 14. Multilink Conceptual Sending Algorithm 2820 The MN's IPv6 layer selects the outbound OMNI interface according to 2821 SBM considerations when forwarding original IP packets from local or 2822 EUN applications to external correspondents. Each OMNI interface 2823 maintains a neighbor cache the same as for any IPv6 interface, but 2824 with additional state for multilink coordination. Each OMNI 2825 interface maintains default routes via ARs discovered as discussed in 2826 Section 15, and may configure more-specific routes discovered through 2827 means outside the scope of this specification. 2829 After a original IP packet enters the OMNI interface, one or more 2830 outbound underlying interfaces are selected based on PBM traffic 2831 attributes, and one or more neighbor underlying interfaces are 2832 selected based on the receipt of Interface Attributes sub-options in 2833 IPv6 ND messages (see: Figure 15). Underlying interface selection 2834 for the nodes own local interfaces are based on attributes such as 2835 DSCP, application port number, cost, performance, message size, etc. 2836 OMNI interface multilink selections could also be configured to 2837 perform replication across multiple underlying interfaces for 2838 increased reliability at the expense of packet duplication. The set 2839 of all Interface Attributes received in IPv6 ND messages determines 2840 the multilink forwarding profile for selecting the neighbor's 2841 underlying interfaces. 2843 When the OMNI interface sends an original IP packet over a selected 2844 outbound underlying interface, the OAL employs encapsulation and 2845 fragmentation as discussed in Section 5, then performs *NET 2846 encapsulation as determined by the L2 address information received in 2847 Interface Attributes. The OAL also performs encapsulation when the 2848 nearest AR is located multiple hops away as discussed in 2849 Section 15.1. (Note that the OAL MAY employ packing when multiple 2850 original IP packets and/or control messages are available for 2851 forwarding to the same OAL destination.) 2853 OMNI interface multilink service designers MUST observe the BCP 2854 guidance in Section 15 [RFC3819] in terms of implications for 2855 reordering when original IP packets from the same flow may be spread 2856 across multiple underlying interfaces having diverse properties. 2858 14.1. Multiple OMNI Interfaces 2860 MNs may connect to multiple independent OMNI links concurrently in 2861 support of SBM. Each OMNI interface is distinguished by its Anycast 2862 ULA (e.g., [ULA]:0002::, [ULA]:1000::, [ULA]:7345::, etc.). The MN 2863 configures a separate OMNI interface for each link so that multiple 2864 interfaces (e.g., omni0, omni1, omni2, etc.) are exposed to the IPv6 2865 layer. A different Anycast ULA is assigned to each interface, and 2866 the MN injects the service prefixes for the OMNI link instances into 2867 the EUN routing system. 2869 Applications in EUNs can use Segment Routing to select the desired 2870 OMNI interface based on SBM considerations. The Anycast ULA is 2871 written into an original IP packet's IPv6 destination address, and 2872 the actual destination (along with any additional intermediate hops) 2873 is written into the Segment Routing Header. Standard IP routing 2874 directs the packet to the MN's mobile router entity, and the Anycast 2875 ULA identifies the OMNI interface to be used for transmission to the 2876 next hop. When the MN receives the packet, it replaces the IPv6 2877 destination address with the next hop found in the routing header and 2878 transmits the message over the OMNI interface identified by the 2879 Anycast ULA. 2881 Multiple distinct OMNI links can therefore be used to support fault 2882 tolerance, load balancing, reliability, etc. The architectural model 2883 is similar to Layer 2 Virtual Local Area Networks (VLANs). 2885 14.2. MN<->AR Traffic Loop Prevention 2887 After an AR has registered an MNP for a MN (see: Section 15), the AR 2888 will forward packets destined to an address within the MNP to the MN. 2889 The MN will under normal circumstances then forward the packet to the 2890 correct destination within its internal networks. 2892 If at some later time the MN loses state (e.g., after a reboot), it 2893 may begin returning packets destined to an MNP address to the AR as 2894 its default router. The AR therefore must drop any packets 2895 originating from the MN and destined to an address within the MN's 2896 registered MNP. To do so, the AR institutes the following check: 2898 o if the IP destination address belongs to a neighbor on the same 2899 OMNI interface, and if the link-layer source address is the same 2900 as one of the neighbor's link-layer addresses, drop the packet. 2902 15. Router Discovery and Prefix Registration 2904 MNs interface with the MS by sending RS messages with OMNI options 2905 under the assumption that one or more AR on the *NET will process the 2906 message and respond. The MN then configures default routes for the 2907 OMNI interface via the discovered ARs as the next hop. The manner in 2908 which the *NET ensures AR coordination is link-specific and outside 2909 the scope of this document (however, considerations for *NETs that do 2910 not provide ARs that recognize the OMNI option are discussed in 2911 Section 20). 2913 For each underlying interface, the MN sends an RS message with an 2914 OMNI option to coordinate with MSEs identified by MSID values. 2915 Example MSID discovery methods are given in [RFC5214] and include 2916 data link login parameters, name service lookups, static 2917 configuration, a static "hosts" file, etc. The MN can also send an 2918 RS with an MS-Register sub-option that includes the Anycast MSID 2919 value '0', i.e., instead of or in addition to any non-zero MSIDs. 2920 When the AR receives an RS with a MSID '0', it selects a nearby MSE 2921 (which may be itself) and returns an RA with the selected MSID in an 2922 MS-Register sub-option. The AR selects only a single wildcard MSE 2923 (i.e., even if the RS MS-Register sub-option included multiple '0' 2924 MSIDs) while also soliciting the MSEs corresponding to any non-zero 2925 MSIDs. 2927 MNs configure OMNI interfaces that observe the properties discussed 2928 in the previous section. The OMNI interface and its underlying 2929 interfaces are said to be in either the "UP" or "DOWN" state 2930 according to administrative actions in conjunction with the interface 2931 connectivity status. An OMNI interface transitions to UP or DOWN 2932 through administrative action and/or through state transitions of the 2933 underlying interfaces. When a first underlying interface transitions 2934 to UP, the OMNI interface also transitions to UP. When all 2935 underlying interfaces transition to DOWN, the OMNI interface also 2936 transitions to DOWN. 2938 When an OMNI interface transitions to UP, the MN sends RS messages to 2939 register its MNP and an initial set of underlying interfaces that are 2940 also UP. The MN sends additional RS messages to refresh lifetimes 2941 and to register/deregister underlying interfaces as they transition 2942 to UP or DOWN. The MN's OMNI interface sends initial RS messages 2943 over an UP underlying interface with its MNP-LLA as the source and 2944 with destination set to link-scoped All-Routers multicast (ff02::2) 2945 [RFC4291]. The OMNI interface includes an OMNI option per Section 12 2946 with a Preflen assertion, Interface Attributes appropriate for 2947 underlying interfaces, MS-Register/Release sub-options containing 2948 MSID values, Reassembly Limits and with any other necessary OMNI sub- 2949 options (e.g., a Node Identification sub-option as an identity for 2950 the MN). The OMNI interface then sets the S/T-omIndex field to the 2951 index of the underlying interface over which the RS message is sent. 2952 The OMNI interface then sends the RS over the underlying interface, 2953 using OAL encapsulation and fragmentation if necessary. If OAL 2954 encapsulation is used, the OMNI interface sets the OAL source address 2955 to the ULA corresponding to the RS source and sets the OAL 2956 destination to site-scoped All-Routers multicast (ff05::2). 2958 ARs process IPv6 ND messages with OMNI options and act as an MSE 2959 themselves and/or as a proxy for other MSEs. ARs receive RS messages 2960 (while performing OAL reassembly if necessary) and create a neighbor 2961 cache entry for the MN, then coordinate with any MSEs named in the 2962 Register/Release lists in a manner outside the scope of this 2963 document. When an MSE processes the OMNI information, it first 2964 validates the prefix registration information then injects/withdraws 2965 the MNP in the routing/mapping system and caches/discards the new 2966 Preflen, MNP and Interface Attributes. The MSE then informs the AR 2967 of registration success/failure, and the AR returns an RA message to 2968 the MN with an OMNI option per Section 12. 2970 The AR's OMNI interface returns the RA message via the same 2971 underlying interface of the MN over which the RS was received, and 2972 with destination address set to the MNP-LLA (i.e., unicast), with 2973 source address set to its own LLA, and with an OMNI option with S/ 2974 T-omIndex set to the value included in the RS. The OMNI option also 2975 includes a Preflen confirmation, Interface Attributes, MS-Register/ 2976 Release and any other necessary OMNI sub-options (e.g., a Node 2977 Identification sub-option as an identity for the AR). The RA also 2978 includes any information for the link, including RA Cur Hop Limit, M 2979 and O flags, Router Lifetime, Reachable Time and Retrans Timer 2980 values, and includes any necessary options such as: 2982 o PIOs with (A; L=0) that include MSPs for the link [RFC8028]. 2984 o RIOs [RFC4191] with more-specific routes. 2986 o an MTU option that specifies the maximum acceptable packet size 2987 for this underlying interface. 2989 The OMNI interface then sends the RA, using OAL encapsulation and 2990 fragmentation. The OMNI interface sets the OAL source address to the 2991 ULA corresponding to the RA source and sets the OAL destination to 2992 the ULA corresponding to the RA destination. The AR MAY also send 2993 periodic and/or event-driven unsolicited RA messages per [RFC4861]. 2994 In that case, the S/T-omIndex field in the OMNI option of the 2995 unsolicited RA message identifies the target underlying interface of 2996 the destination MN. 2998 The AR can combine the information from multiple MSEs into one or 2999 more "aggregate" RAs sent to the MN in order conserve *NET bandwidth. 3000 Each aggregate RA includes an OMNI option with MS-Register/Release 3001 sub-options with the MSEs represented by the aggregate. If an 3002 aggregate is sent, the RA message contents must consistently 3003 represent the combined information advertised by all represented 3004 MSEs. Note that since the AR uses its own ADM-LLA as the RA source 3005 address, the MN determines the addresses of the represented MSEs by 3006 examining the MS-Register/Release OMNI sub-options. 3008 When the MN receives the RA message, it creates an OMNI interface 3009 neighbor cache entry for each MSID that has confirmed MNP 3010 registration via the L2 address of this AR. If the MN connects to 3011 multiple *NETs, it records the additional L2 AR addresses in each 3012 MSID neighbor cache entry (i.e., as multilink neighbors). The MN 3013 then configures a default route via the MSE that returned the RA 3014 message, and assigns the Subnet Router Anycast address corresponding 3015 to the MNP (e.g., 2001:db8:1:2::) to the OMNI interface. The MN then 3016 manages its underlying interfaces according to their states as 3017 follows: 3019 o When an underlying interface transitions to UP, the MN sends an RS 3020 over the underlying interface with an OMNI option. The OMNI 3021 option contains at least one Interface Attribute sub-option with 3022 values specific to this underlying interface, and may contain 3023 additional Interface Attributes specific to other underlying 3024 interfaces. The option also includes any MS-Register/Release sub- 3025 options. 3027 o When an underlying interface transitions to DOWN, the MN sends an 3028 RS or unsolicited NA message over any UP underlying interface with 3029 an OMNI option containing an Interface Attribute sub-option for 3030 the DOWN underlying interface with Link set to '0'. The MN sends 3031 an RS when an acknowledgement is required, or an unsolicited NA 3032 when reliability is not thought to be a concern (e.g., if 3033 redundant transmissions are sent on multiple underlying 3034 interfaces). 3036 o When the Router Lifetime for a specific AR nears expiration, the 3037 MN sends an RS over the underlying interface to receive a fresh 3038 RA. If no RA is received, the MN can send RS messages to an 3039 alternate MSID in case the current MSID has failed. If no RS 3040 messages are received even after trying to contact alternate 3041 MSIDs, the MN marks the underlying interface as DOWN. 3043 o When a MN wishes to release from one or more current MSIDs, it 3044 sends an RS or unsolicited NA message over any UP underlying 3045 interfaces with an OMNI option with a Release MSID. Each MSID 3046 then withdraws the MNP from the routing/mapping system and informs 3047 the AR that the release was successful. 3049 o When all of a MNs underlying interfaces have transitioned to DOWN 3050 (or if the prefix registration lifetime expires), any associated 3051 MSEs withdraw the MNP the same as if they had received a message 3052 with a release indication. 3054 The MN is responsible for retrying each RS exchange up to 3055 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 3056 seconds until an RA is received. If no RA is received over an UP 3057 underlying interface (i.e., even after attempting to contact 3058 alternate MSEs), the MN declares this underlying interface as DOWN. 3060 The IPv6 layer sees the OMNI interface as an ordinary IPv6 interface. 3061 Therefore, when the IPv6 layer sends an RS message the OMNI interface 3062 returns an internally-generated RA message as though the message 3063 originated from an IPv6 router. The internally-generated RA message 3064 contains configuration information that is consistent with the 3065 information received from the RAs generated by the MS. Whether the 3066 OMNI interface IPv6 ND messaging process is initiated from the 3067 receipt of an RS message from the IPv6 layer is an implementation 3068 matter. Some implementations may elect to defer the IPv6 ND 3069 messaging process until an RS is received from the IPv6 layer, while 3070 others may elect to initiate the process proactively. Still other 3071 deployments may elect to administratively disable the ordinary RS/RA 3072 messaging used by the IPv6 layer over the OMNI interface, since they 3073 are not required to drive the internal RS/RA processing. (Note that 3074 this same logic applies to IPv4 implementations that employ ICMP- 3075 based Router Discovery per [RFC1256].) 3077 Note: The Router Lifetime value in RA messages indicates the time 3078 before which the MN must send another RS message over this underlying 3079 interface (e.g., 600 seconds), however that timescale may be 3080 significantly longer than the lifetime the MS has committed to retain 3081 the prefix registration (e.g., REACHABLETIME seconds). ARs are 3082 therefore responsible for keeping MS state alive on a shorter 3083 timescale than the MN is required to do on its own behalf. 3085 Note: On multicast-capable underlying interfaces, MNs should send 3086 periodic unsolicited multicast NA messages and ARs should send 3087 periodic unsolicited multicast RA messages as "beacons" that can be 3088 heard by other nodes on the link. If a node fails to receive a 3089 beacon after a timeout value specific to the link, it can initiate a 3090 unicast exchange to test reachability. 3092 Note: if an AR acting as a proxy forwards a MN's RS message to 3093 another node acting as an MSE using UDP/IP encapsulation, it must use 3094 a distinct UDP source port number for each MN. This allows the MSE 3095 to distinguish different MNs behind the same AR at the link-layer, 3096 whereas the link-layer addresses would otherwise be 3097 indistinguishable. 3099 Note: when an AR acting as an MSE returns an RA to an INET Client, it 3100 includes an OMNI option with an Interface Attributes sub-option with 3101 omIndex set to 0 and with SRT, FMT, LHS and L2ADDR information for 3102 its INET interface. This provides the Client with partition prefix 3103 context regarding the local OMNI link segment. 3105 15.1. Router Discovery in IP Multihop and IPv4-Only Networks 3107 On some *NETs, a MN may be located multiple IP hops away from the 3108 nearest AR. Forwarding through IP multihop *NETs is conducted 3109 through the application of a routing protocol (e.g., a MANET/VANET 3110 routing protocol over omni-directional wireless interfaces, an inter- 3111 domain routing protocol in an enterprise network, etc.). These *NETs 3112 could be either IPv6-enabled or IPv4-only, while IPv4-only *NETs 3113 could be either multicast-capable or unicast-only (note that for 3114 IPv4-only *NETs the following procedures apply for both single-hop 3115 and multihop cases). 3117 A MN located potentially multiple *NET hops away from the nearest AR 3118 prepares an RS message with source address set to its MNP-LLA (or to 3119 the unspecified address (::) if it does not yet have an MNP-LLA), and 3120 with destination set to link-scoped All-Routers multicast the same as 3121 discussed above. The OMNI interface then employs OAL encapsulation 3122 and fragmentation, and sets the OAL source address to the ULA 3123 corresponding to the RS source (or to a Temporary ULA if the RS 3124 source was the unspecified address (::)) and sets the OAL destination 3125 to site-scoped All-Routers multicast (ff05::2). For IPv6-enabled 3126 *NETs, the MN then encapsulates the message in UDP/IPv6 headers with 3127 source address set to the underlying interface address (or to the ULA 3128 that would be used for OAL encapsulation if the underlying interface 3129 does not yet have an address) and sets the destination to either a 3130 unicast or anycast address of an AR. For IPv4-only *NETs, the MN 3131 instead encapsulates the RS message in UDP/IPv4 headers with source 3132 address set to the IPv4 address of the underlying interface and with 3133 destination address set to either the unicast IPv4 address of an AR 3134 [RFC5214] or an IPv4 anycast address reserved for OMNI. The MN then 3135 sends the encapsulated RS message via the *NET interface, where it 3136 will be forwarded by zero or more intermediate *NET hops. 3138 When an intermediate *NET hop that participates in the routing 3139 protocol receives the encapsulated RS, it forwards the message 3140 according to its routing tables (note that an intermediate node could 3141 be a fixed infrastructure element or another MN). This process 3142 repeats iteratively until the RS message is received by a penultimate 3143 *NET hop within single-hop communications range of an AR, which 3144 forwards the message to the AR. 3146 When the AR receives the message, it decapsulates the RS (while 3147 performing OAL reassembly, if necessary) and coordinates with the MS 3148 the same as for an ordinary link-local RS, since the network layer 3149 Hop Limit will not have been decremented by the multihop forwarding 3150 process. The AR then prepares an RA message with source address set 3151 to its own ADM-LLA and destination address set to the LLA of the 3152 original MN. The AR then performs OAL encapsulation and 3153 fragmentation, with OAL source set to its own ADM-ULA and destination 3154 set to the ULA corresponding to the RA source. The AR then 3155 encapsulates the message in UDP/IPv4 or UDP/IPv6 headers with source 3156 address set to its own address and with destination set to the 3157 encapsulation source of the RS. 3159 The AR then forwards the message to an *NET node within 3160 communications range, which forwards the message according to its 3161 routing tables to an intermediate node. The multihop forwarding 3162 process within the *NET continues repetitively until the message is 3163 delivered to the original MN, which decapsulates the message and 3164 performs autoconfiguration the same as if it had received the RA 3165 directly from the AR as an on-link neighbor. 3167 Note: An alternate approach to multihop forwarding via IPv6 3168 encapsulation would be for the MN and AR to statelessly translate the 3169 IPv6 LLAs into ULAs and forward the RS/RA messages without 3170 encapsulation. This would violate the [RFC4861] requirement that 3171 certain IPv6 ND messages must use link-local addresses and must not 3172 be accepted if received with Hop Limit less than 255. This document 3173 therefore mandates encapsulation since the overhead is nominal 3174 considering the infrequent nature and small size of IPv6 ND messages. 3175 Future documents may consider encapsulation avoidance through 3176 translation while updating [RFC4861]. 3178 Note: An alternate approach to multihop forwarding via IPv4 3179 encapsulation would be to employ IPv6/IPv4 protocol translation. 3180 However, for IPv6 ND messages the LLAs would be truncated due to 3181 translation and the OMNI Router and Prefix Discovery services would 3182 not be able to function. The use of IPv4 encapsulation is therefore 3183 indicated. 3185 Note: An IPv4 anycast address for OMNI in IPv4 networks could be part 3186 of a new IPv4 /24 prefix allocation, but this may be difficult to 3187 obtain given IPv4 address exhaustion. An alternative would be to re- 3188 purpose the prefix 192.88.99.0 which has been set aside from its 3189 former use by [RFC7526]. 3191 15.2. MS-Register and MS-Release List Processing 3193 OMNI links maintain a constant value "MAX_MSID" selected to provide 3194 MNs with an acceptable level of MSE redundancy while minimizing 3195 control message amplification. It is RECOMMENDED that MAX_MSID be 3196 set to the default value 5; if a different value is chosen, it should 3197 be set uniformly by all nodes on the OMNI link. 3199 When a MN sends an RS message with an OMNI option via an underlying 3200 interface to an AR, the MN must convey its knowledge of its 3201 currently-associated MSEs. Initially, the MN will have no associated 3202 MSEs and should therefore include an MS-Register sub-option with the 3203 single "anycast" MSID value 0 which requests the AR to select and 3204 assign an MSE. The AR will then return an RA message with source 3205 address set to the ADM-LLA of the selected MSE. 3207 As the MN activates additional underlying interfaces, it can 3208 optionally include an MS-Register sub-option with MSID value 0, or 3209 with non-zero MSIDs for MSEs discovered from previous RS/RA 3210 exchanges. The MN will thus eventually begin to learn and manage its 3211 currently active set of MSEs, and can register with new MSEs or 3212 release from former MSEs with each successive RS/RA exchange. As the 3213 MN's MSE constituency grows, it alone is responsible for including or 3214 omitting MSIDs in the MS-Register/Release lists it sends in RS 3215 messages. The inclusion or omission of MSIDs determines the MN's 3216 interface to the MS and defines the manner in which MSEs will 3217 respond. The only limiting factor is that the MN should include no 3218 more than MAX_MSID values in each list per each IPv6 ND message, and 3219 should avoid duplication of entries in each list unless it wants to 3220 increase likelihood of control message delivery. 3222 When an AR receives an RS message sent by a MN with an OMNI option, 3223 the option will contain zero or more MS-Register and MS-Release sub- 3224 options containing MSIDs. After processing the OMNI option, the AR 3225 will have a list of zero or more MS-Register MSIDs and a list of zero 3226 or more of MS-Release MSIDs. The AR then processes the lists as 3227 follows: 3229 o For each list, retain the first MAX_MSID values in the list and 3230 discard any additional MSIDs (i.e., even if there are duplicates 3231 within a list). 3233 o Next, for each MSID in the MS-Register list, remove all matching 3234 MSIDs from the MS-Release list. 3236 o Next, proceed as follows: 3238 * If the AR's own MSID or the value 0 appears in the MS-Register 3239 list, send an RA message directly back to the MN and send a 3240 proxy copy of the RS message to each additional MSID in the MS- 3241 Register list with the MS-Register/Release lists omitted. 3242 Then, send an unsolicited NA (uNA) message to each MSID in the 3243 MS-Release list with the MS-Register/Release lists omitted and 3244 with an OMNI option with S/T-omIndex set to 0. 3246 * Otherwise, send a proxy copy of the RS message to each 3247 additional MSID in the MS-Register list with the MS-Register 3248 list omitted. For the first MSID, include the original MS- 3249 Release list; for all other MSIDs, omit the MS-Release list. 3251 Each proxy copy of the RS message will include an OMNI option and OAL 3252 encapsulation header with the ADM-ULA of the AR as the source and the 3253 ADM-ULA of the Register MSE as the destination. When the Register 3254 MSE receives the proxy RS message, if the message includes an MS- 3255 Release list the MSE sends a uNA message to each additional MSID in 3256 the Release list with an OMNI option with S/T-omIndex set to 0. The 3257 Register MSE then sends an RA message back to the (Proxy) AR wrapped 3258 in an OAL encapsulation header with source and destination addresses 3259 reversed, and with RA destination set to the MNP-LLA of the MN. When 3260 the AR receives this RA message, it sends a proxy copy of the RA to 3261 the MN. 3263 Each uNA message (whether sent by the first-hop AR or by a Register 3264 MSE) will include an OMNI option and an OAL encapsulation header with 3265 the ADM-ULA of the Register MSE as the source and the ADM-ULA of the 3266 Release MSE as the destination. The uNA informs the Release MSE that 3267 its previous relationship with the MN has been released and that the 3268 source of the uNA message is now registered. The Release MSE must 3269 then note that the subject MN of the uNA message is now "departed", 3270 and forward any subsequent packets destined to the MN to the Register 3271 MSE. 3273 Note that it is not an error for the MS-Register/Release lists to 3274 include duplicate entries. If duplicates occur within a list, the AR 3275 will generate multiple proxy RS and/or uNA messages - one for each 3276 copy of the duplicate entries. 3278 15.3. DHCPv6-based Prefix Registration 3280 When a MN is not pre-provisioned with an MNP-LLA (or, when the MN 3281 requires additional MNP delegations), it requests the MSE to select 3282 MNPs on its behalf and set up the correct routing state within the 3283 MS. The DHCPv6 service [RFC8415] supports this requirement. 3285 When an MN needs to have the MSE select MNPs, it sends an RS message 3286 with source set to the unspecified address (::) if it has no 3287 MNP_LLAs. If the MN requires only a single MNP delegation, it can 3288 then include a Node Identification sub-option in the OMNI option and 3289 set Preflen to the length of the desired MNP. If the MN requires 3290 multiple MNP delegations and/or more complex DHCPv6 services, it 3291 instead includes a DHCPv6 Message sub-option containing a Client 3292 Identifier, one or more IA_PD options and a Rapid Commit option then 3293 sets the 'msg-type' field to "Solicit", and includes a 3 octet 3294 'transaction-id'. The MN then sets the RS destination to All-Routers 3295 multicast and sends the message using OAL encapsulation and 3296 fragmentation if necessary as discussed above. 3298 When the MSE receives the RS message, it performs OAL reassembly if 3299 necessary. Next, if the RS source is the unspecified address (::) 3300 and/or the OMNI option includes a DHCPv6 message sub-option, the MSE 3301 acts as a "Proxy DHCPv6 Client" in a message exchange with the 3302 locally-resident DHCPv6 server. If the RS did not contain a DHCPv6 3303 message sub-option, the MSE generates a DHCPv6 Solicit message on 3304 behalf of the MN using an IA_PD option with the prefix length set to 3305 the OMNI header Preflen value and with a Client Identifier formed 3306 from the OMNI option Node Identification sub-option; otherwise, the 3307 MSE uses the DHCPv6 Solicit message contained in the OMNI option. 3308 The MSE then sends the DHCPv6 message to the DHCPv6 Server, which 3309 delegates MNPs and returns a DHCPv6 Reply message with PD parameters. 3310 (If the MSE wishes to defer creation of MN state until the DHCPv6 3311 Reply is received, it can instead act as a Lightweight DHCPv6 Relay 3312 Agent per [RFC6221] by encapsulating the DHCPv6 message in a Relay- 3313 forward/reply exchange with Relay Message and Interface ID options. 3314 In the process, the MSE packs any state information needed to return 3315 an RA to the MN in the Relay-forward Interface ID option so that the 3316 information will be echoed back in the Relay-reply.) 3318 When the MSE receives the DHCPv6 Reply, it adds routes to the routing 3319 system and creates MNP-LLAs based on the delegated MNPs. The MSE 3320 then sends an RA back to the MN with the DHCPv6 Reply message 3321 included in an OMNI DHCPv6 message sub-option if and only if the RS 3322 message had included an explicit DHCPv6 Solicit. If the RS message 3323 source was the unspecified address (::), the MSE includes one of the 3324 (newly-created) MNP-LLAs as the RA destination address and sets the 3325 OMNI option Preflen accordingly; otherwise, the MSE includes the RS 3326 source address as the RA destination address. The MSE then sets the 3327 RA source address to its own ADM-LLA then performs OAL encapsulation 3328 and fragmentation and sends the RA to the MN. When the MN receives 3329 the RA, it reassembles and discards the OAL encapsulation, then 3330 creates a default route, assigns Subnet Router Anycast addresses and 3331 uses the RA destination address as its primary MNP-LLA. The MN will 3332 then use this primary MNP-LLA as the source address of any IPv6 ND 3333 messages it sends as long as it retains ownership of the MNP. 3335 Note: After a MN performs a DHCPv6-based prefix registration exchange 3336 with a first MSE, it would need to repeat the exchange with each 3337 additional MSE it registers with. In that case, the MN supplies the 3338 MNP delegation information received from the first MSE when it 3339 engages the additional MSEs. 3341 16. Secure Redirection 3343 If the *NET link model is multiple access, the AR is responsible for 3344 assuring that address duplication cannot corrupt the neighbor caches 3345 of other nodes on the link. When the MN sends an RS message on a 3346 multiple access *NET link, the AR verifies that the MN is authorized 3347 to use the address and returns an RA with a non-zero Router Lifetime 3348 only if the MN is authorized. 3350 After verifying MN authorization and returning an RA, the AR MAY 3351 return IPv6 ND Redirect messages to direct MNs located on the same 3352 *NET link to exchange packets directly without transiting the AR. In 3353 that case, the MNs can exchange packets according to their unicast L2 3354 addresses discovered from the Redirect message instead of using the 3355 dogleg path through the AR. In some *NET links, however, such direct 3356 communications may be undesirable and continued use of the dogleg 3357 path through the AR may provide better performance. In that case, 3358 the AR can refrain from sending Redirects, and/or MNs can ignore 3359 them. 3361 17. AR and MSE Resilience 3363 *NETs SHOULD deploy ARs in Virtual Router Redundancy Protocol (VRRP) 3364 [RFC5798] configurations so that service continuity is maintained 3365 even if one or more ARs fail. Using VRRP, the MN is unaware which of 3366 the (redundant) ARs is currently providing service, and any service 3367 discontinuity will be limited to the failover time supported by VRRP. 3368 Widely deployed public domain implementations of VRRP are available. 3370 MSEs SHOULD use high availability clustering services so that 3371 multiple redundant systems can provide coordinated response to 3372 failures. As with VRRP, widely deployed public domain 3373 implementations of high availability clustering services are 3374 available. Note that special-purpose and expensive dedicated 3375 hardware is not necessary, and public domain implementations can be 3376 used even between lightweight virtual machines in cloud deployments. 3378 18. Detecting and Responding to MSE Failures 3380 In environments where fast recovery from MSE failure is required, ARs 3381 SHOULD use proactive Neighbor Unreachability Detection (NUD) in a 3382 manner that parallels Bidirectional Forwarding Detection (BFD) 3383 [RFC5880] to track MSE reachability. ARs can then quickly detect and 3384 react to failures so that cached information is re-established 3385 through alternate paths. Proactive NUD control messaging is carried 3386 only over well-connected ground domain networks (i.e., and not low- 3387 end *NET links such as aeronautical radios) and can therefore be 3388 tuned for rapid response. 3390 ARs perform proactive NUD for MSEs for which there are currently 3391 active MNs on the *NET. If an MSE fails, ARs can quickly inform MNs 3392 of the outage by sending multicast RA messages on the *NET interface. 3393 The AR sends RA messages to MNs via the *NET interface with an OMNI 3394 option with a Release ID for the failed MSE, and with destination 3395 address set to All-Nodes multicast (ff02::1) [RFC4291]. 3397 The AR SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated 3398 by small delays [RFC4861]. Any MNs on the *NET interface that have 3399 been using the (now defunct) MSE will receive the RA messages and 3400 associate with a new MSE. 3402 19. Transition Considerations 3404 When a MN connects to an *NET link for the first time, it sends an RS 3405 message with an OMNI option. If the first hop AR recognizes the 3406 option, it returns an RA with its ADM-LLA as the source, the MNP-LLA 3407 as the destination and with an OMNI option included. The MN then 3408 engages the AR according to the OMNI link model specified above. If 3409 the first hop AR is a legacy IPv6 router, however, it instead returns 3410 an RA message with no OMNI option and with a non-OMNI unicast source 3411 LLA as specified in [RFC4861]. In that case, the MN engages the *NET 3412 according to the legacy IPv6 link model and without the OMNI 3413 extensions specified in this document. 3415 If the *NET link model is multiple access, there must be assurance 3416 that address duplication cannot corrupt the neighbor caches of other 3417 nodes on the link. When the MN sends an RS message on a multiple 3418 access *NET link with an LLA source address and an OMNI option, ARs 3419 that recognize the option ensure that the MN is authorized to use the 3420 address and return an RA with a non-zero Router Lifetime only if the 3421 MN is authorized. ARs that do not recognize the option instead 3422 return an RA that makes no statement about the MN's authorization to 3423 use the source address. In that case, the MN should perform 3424 Duplicate Address Detection to ensure that it does not interfere with 3425 other nodes on the link. 3427 An alternative approach for multiple access *NET links to ensure 3428 isolation for MN / AR communications is through L2 address mappings 3429 as discussed in Appendix C. This arrangement imparts a (virtual) 3430 point-to-point link model over the (physical) multiple access link. 3432 20. OMNI Interfaces on Open Internetworks 3434 OMNI interfaces configured over IPv6-enabled underlying interfaces on 3435 an open Internetwork without an OMNI-aware first-hop AR receive RA 3436 messages that do not include an OMNI option, while OMNI interfaces 3437 configured over IPv4-only underlying interfaces do not receive any 3438 (IPv6) RA messages at all (although they may receive IPv4 RA messages 3439 [RFC1256]). OMNI interfaces that receive RA messages without an OMNI 3440 option configure addresses, on-link prefixes, etc. on the underlying 3441 interface that received the RA according to standard IPv6 ND and 3442 address resolution conventions [RFC4861] [RFC4862]. OMNI interfaces 3443 configured over IPv4-only underlying interfaces configure IPv4 3444 address information on the underlying interfaces using mechanisms 3445 such as DHCPv4 [RFC2131]. 3447 OMNI interfaces configured over underlying interfaces that connect to 3448 an open Internetwork can apply security services such as VPNs to 3449 connect to an MSE, or can establish a direct link to an MSE through 3450 some other means (see Section 4). In environments where an explicit 3451 VPN or direct link may be impractical, OMNI interfaces can instead 3452 use UDP/IP encapsulation per [RFC6081][RFC4380] and HIP-based message 3453 authentication per [RFC7401]. 3455 OMNI interfaces use UDP service port number 8060 (see: Section 25.10 3456 and Section 3.6 of [I-D.templin-intarea-6706bis]) according to the 3457 simple UDP/IP encapsulation format specified in [RFC4380] for both 3458 IPv4 and IPv6 underlying interfaces. OMNI interfaces do not include 3459 the UDP/IP header/trailer extensions specified in [RFC4380][RFC6081], 3460 but may include them as OMNI sub-options instead when necessary. 3461 Since the OAL includes an integrity check over the OAL packet, OAL 3462 sources selectively disable UDP checksums for OAL packets that do not 3463 require UDP/IP address integrity, but enable UDP checksums for others 3464 including non-OAL packets, IPv6 ND messages used to establish link- 3465 layer addresses, etc. If the OAL source discovers that packets with 3466 UDP checksums disabled are being dropped in the path it should enable 3467 UDP checksums in future packets. Further considerations for UDP 3468 encapsulation checksums are found in [RFC6935][RFC6936]. 3470 For "Vehicle-to-Infrastructure (V2I)" coordination, the MN codes a 3471 HIP "Initiator" message in an OMNI option of an IPv6 RS message and 3472 the AR responds with a HIP "Responder" message coded in an OMNI 3473 option of an IPv6 RA message. HIP security services are applied per 3474 [RFC7401], using the RS/RA messages as simple "shipping containers" 3475 to convey the HIP parameters. In that case, a "two-message HIP 3476 exchange" through a single RS/RA exchange may be sufficient for 3477 mutual authentication. For "Vehicle-to-Vehicle (V2V)" coordination, 3478 two MNs can coordinate directly with one another with HIP "Initiator/ 3479 Responder" messages coded in OMNI options of IPv6 NS/NA messages. In 3480 that case, a four-message HIP exchange (i.e., two back-to-back NS/NA 3481 exchanges) may be necessary for the two MNs to attain mutual 3482 authentication. 3484 After establishing a VPN or preparing for UDP/IP encapsulation, OMNI 3485 interfaces send control plane messages to interface with the MS, 3486 including RS/RA messages used according to Section 15 and NS/NA 3487 messages used for route optimization and mobility (see: 3488 [I-D.templin-intarea-6706bis]). The control plane messages must be 3489 authenticated while data plane messages are delivered the same as for 3490 ordinary best-effort traffic with basic source address-based data 3491 origin verification. Data plane communications via OMNI interfaces 3492 that connect over open Internetworks without an explicit VPN should 3493 therefore employ transport- or higher-layer security to ensure 3494 integrity and/or confidentiality. 3496 OMNI interfaces configured over open Internetworks are often located 3497 behind NATs. The OMNI interface accommodates NAT traversal using 3498 UDP/IP encapsulation and the mechanisms discussed in 3499 [I-D.templin-intarea-6706bis]. To support NAT determination, ARs 3500 include an Origin Indication sub-option in RA messages sent in 3501 response to RS messages received from a Client via UDP/IP 3502 encapsulation. 3504 Note: Following the initial HIP Initiator/Responder exchange, OMNI 3505 interfaces configured over open Internetworks maintain HIP 3506 associations through the transmission of IPv6 ND messages that 3507 include OMNI options with HIP "Update" and "Notify" messages. OMNI 3508 interfaces use the HIP "Update" message when an acknowledgement is 3509 required, and use the "Notify" message in unacknowledged isolated 3510 IPv6 ND messages (e.g., unsolicited NAs). 3512 Note: ARs that act as proxys on an open Internetwork authenticate and 3513 remove HIP message OMNI sub-options from RSes they forward from a MN 3514 to an MSE, and insert and sign HIP message and Origin Indication sub- 3515 options in RAs they forward from an MSE to an MN. Conversely, ARs 3516 that act as proxys forward without processing any DHCPv6 information 3517 in RS/RA message exchanges between MNs and MSEs. The AR is therefore 3518 responsible for MN authentication while the MSE is responsible for 3519 registering/delegating MNPs. 3521 21. Time-Varying MNPs 3523 In some use cases, it is desirable, beneficial and efficient for the 3524 MN to receive a constant MNP that travels with the MN wherever it 3525 moves. For example, this would allow air traffic controllers to 3526 easily track aircraft, etc. In other cases, however (e.g., 3527 intelligent transportation systems), the MN may be willing to 3528 sacrifice a modicum of efficiency in order to have time-varying MNPs 3529 that can be changed every so often to defeat adversarial tracking. 3531 The prefix delegation services discussed in Section 15.3 allows OMNI 3532 MNs that desire time-varying MNPs to obtain short-lived prefixes to 3533 send RS messages with source set to the unspecified address (::) and/ 3534 or with an OMNI option with DHCPv6 Option sub-options. The MN would 3535 then be obligated to renumber its internal networks whenever its MNP 3536 (and therefore also its OMNI address) changes. This should not 3537 present a challenge for MNs with automated network renumbering 3538 services, however presents limits for the durations of ongoing 3539 sessions that would prefer to use a constant address. 3541 22. (H)HITs and Temporary ULAs 3543 MNs that generate (H)HITs but do not have pre-assigned MNPs can 3544 request MNP delegations by issuing IPv6 ND messages that use the 3545 (H)HIT instead of a Temporary ULA. In particular, when a MN creates 3546 an RS message it can set the source to the unspecified address (::) 3547 and destination to All-Routers multicast. The IPv6 ND message 3548 includes an OMNI option with a HIP "Initiator" message sub-option, 3549 and need not include a Node Identification sub-option since the MN's 3550 HIT appears in the HIP message. The MN then encapsulates the message 3551 in an IPv6 header with the (H)HIT as the source address and with 3552 destination set to either a unicast or anycast ADM-ULA. The MN then 3553 sends the message to the AR as specified in Section 15.1. 3555 When the AR receives the message, it notes that the RS source was the 3556 unspecified address (::), then examines the RS encapsulation source 3557 address to determine that the source is a (H)HIT and not a Temporary 3558 ULA. The AR next invokes the DHCPv6 protocol to request an MNP 3559 prefix delegation while using the HIT as the Client Identifier, then 3560 prepares an RA message with source address set to its own ADM-LLA and 3561 destination set to the MNP-LLA corresponding to the delegated MNP. 3562 The AR next includes an OMNI option with a HIP "Responder" message 3563 and any DHCPv6 prefix delegation parameters. The AR then finally 3564 encapsulates the RA in an IPv6 header with source address set to its 3565 own ADM-ULA and destination set to the (H)HIT from the RS 3566 encapsulation source address, then returns the encapsulated RA to the 3567 MN. 3569 MNs can also use (H)HITs and/or Temporary ULAs for direct MN-to-MN 3570 communications outside the context of any OMNI link supporting 3571 infrastructure. When two MNs encounter one another they can use 3572 their (H)HITs and/or Temporary ULAs as original IPv6 packet source 3573 and destination addresses to support direct communications. MNs can 3574 also inject their (H)HITs and/or Temporary ULAs into a MANET/VANET 3575 routing protocol to enable multihop communications. MNs can further 3576 exchange IPv6 ND messages (such as NS/NA) using their (H)HITs and/or 3577 Temporary ULAs as source and destination addresses. Note that the 3578 HIP security protocols for establishing secure neighbor relationships 3579 are based on (H)HITs; therefore, Temporary ULAs would presumably 3580 utilize some alternate form of message authentication such as the 3581 [RFC4380] authentication service. 3583 Lastly, when MNs are within the coverage range of OMNI link 3584 infrastructure a case could be made for injecting (H)HITs and/or 3585 Temporary ULAs into the global MS routing system. For example, when 3586 the MN sends an RS to a MSE it could include a request to inject the 3587 (H)HIT / Temporary ULA into the routing system instead of requesting 3588 an MNP prefix delegation. This would potentially enable OMNI link- 3589 wide communications using only (H)HITs or Temporary ULAs, and not 3590 MNPs. This document notes the opportunity, but makes no 3591 recommendation. 3593 23. Address Selection 3595 OMNI MNs use LLAs only for link-scoped communications on the OMNI 3596 link. Typically, MNs use LLAs as source/destination IPv6 addresses 3597 of IPv6 ND messages, but may also use them for addressing ordinary 3598 original IP packets exchanged with an OMNI link neighbor. 3600 OMNI MNs use MNP-ULAs as source/destination IPv6 addresses in the 3601 encapsulation headers of OAL packets. OMNI MNs use Temporary ULAs 3602 for OAL addressing when an MNP-ULA is not available, or as source/ 3603 destination IPv6 addresses for communications within a MANET/VANET 3604 local area. OMNI MNs use HITs instead of Temporary ULAs when 3605 operation outside the context of a specific ULA domain and/or source 3606 address attestation is necessary. 3608 OMNI MNs use MNP-based GUAs as original IP packet source and 3609 destination addresses for communications with Internet destinations 3610 when they are within range of OMNI link supporting infrastructure 3611 that can inject the MNP into the routing system. 3613 24. Error Messages 3615 An OAL destination or intermediate node may need to return ICMPv6 3616 error messages (e.g., Destination Unreachable, Packet Too Big, Time 3617 Exceeded, etc.) [RFC4443] to an OAL source. Since ICMPv6 error 3618 messages do not themselves include authentication codes, the OAL 3619 includes the ICMPv6 error message as an OMNI sub-option in an IPv6 ND 3620 uNA message. The OAL also includes a HIP message sub-option if the 3621 uNA needs to travel over an open Internetwork. 3623 25. IANA Considerations 3625 The following IANA actions are requested: 3627 25.1. "IEEE 802 Numbers" Registry 3629 The IANA is instructed to allocate an official Ether Type number TBD1 3630 from the 'ieee-802-numbers' registry for User Datagram Protocol (UDP) 3631 encapsulation on Ethernet networks. Guidance is found in [RFC7042]. 3633 25.2. "IPv6 Neighbor Discovery Option Formats" Registry 3635 The IANA is instructed to allocate an official Type number TBD2 from 3636 the "IPv6 Neighbor Discovery Option Formats" registry for the OMNI 3637 option. Implementations set Type to 253 as an interim value 3638 [RFC4727]. 3640 25.3. "Ethernet Numbers" Registry 3642 The IANA is instructed to allocate one Ethernet unicast address TBD3 3643 (suggested value '00-52-14') in the 'ethernet-numbers' registry under 3644 "IANA Unicast 48-bit MAC Addresses" as follows: 3646 Addresses Usage Reference 3647 --------- ----- --------- 3648 00-52-14 Overlay Multilink Network (OMNI) Interface [RFCXXXX] 3650 Figure 32: IANA Unicast 48-bit MAC Addresses 3652 25.4. "ICMPv6 Code Fields: Type 2 - Packet Too Big" Registry 3654 The IANA is instructed to assign two new Code values in the "ICMPv6 3655 Code Fields: Type 2 - Packet Too Big" registry. The registry should 3656 appear as follows: 3658 Code Name Reference 3659 --- ---- --------- 3660 0 PTB Hard Error [RFC4443] 3661 1 PTB Soft Error (loss) [RFCXXXX] 3662 2 PTB Soft Error (no loss) [RFCXXXX] 3664 Figure 33: ICMPv6 Code Fields: Type 2 - Packet Too Big Values 3666 (Note: this registry also to be used to define values for setting the 3667 "unused" field of ICMPv4 "Destination Unreachable - Fragmentation 3668 Needed" messages.) 3670 25.5. "OMNI Option Sub-Type Values" (New Registry) 3672 The OMNI option defines a 5-bit Sub-Type field, for which IANA is 3673 instructed to create and maintain a new registry entitled "OMNI 3674 Option Sub-Type Values". Initial values are given below (future 3675 assignments are to be made through Standards Action [RFC8126]): 3677 Value Sub-Type name Reference 3678 ----- ------------- ---------- 3679 0 Pad1 [RFCXXXX] 3680 1 PadN [RFCXXXX] 3681 2 Interface Attributes (Type 1) [RFCXXXX] 3682 3 Interface Attributes (Type 2) [RFCXXXX] 3683 4 Traffic Selector [RFCXXXX] 3684 5 MS-Register [RFCXXXX] 3685 6 MS-Release [RFCXXXX] 3686 7 Geo Coordinates [RFCXXXX] 3687 8 DHCPv6 Message [RFCXXXX] 3688 9 HIP Message [RFCXXXX] 3689 10 Reassembly Limit [RFCXXXX] 3690 11 Fragmentation Report [RFCXXXX] 3691 12 Node Identification [RFCXXXX] 3692 13-29 Unassigned 3693 30 Sub-Type Extension [RFCXXXX] 3694 31 Reserved by IANA [RFCXXXX] 3696 Figure 34: OMNI Option Sub-Type Values 3698 25.6. "OMNI Node Identification ID-Type Values" (New Registry) 3700 The OMNI Node Identification Sub-Option (see: Section 12.1.13) 3701 contains an 8-bit ID-Type field, for which IANA is instructed to 3702 create and maintain a new registry entitled "OMNI Node Identification 3703 ID-Type Values". Initial values are given below (future assignments 3704 are to be made through Expert Review [RFC8126]): 3706 Value Sub-Type name Reference 3707 ----- ------------- ---------- 3708 0 UUID [RFCXXXX] 3709 1 HIT [RFCXXXX] 3710 2 HHIT [RFCXXXX] 3711 3 Network Access Identifier [RFCXXXX] 3712 4 FQDN [RFCXXXX] 3713 5-252 Unassigned [RFCXXXX] 3714 253-254 Reserved for Experimentation [RFCXXXX] 3715 255 Reserved by IANA [RFCXXXX] 3717 Figure 35: OMNI Node Identification ID-Type Values 3719 25.7. "OMNI Option Sub-Type Extension Values" (New Registry) 3721 The OMNI option defines an 8-bit Extension-Type field for Sub-Type 30 3722 (Sub-Type Extension), for which IANA is instructed to create and 3723 maintain a new registry entitled "OMNI Option Sub-Type Extension 3724 Values". Initial values are given below (future assignments are to 3725 be made through Expert Review [RFC8126]): 3727 Value Sub-Type name Reference 3728 ----- ------------- ---------- 3729 0 RFC4380 UDP/IP Header Option [RFCXXXX] 3730 1 RFC6081 UDP/IP Trailer Option [RFCXXXX] 3731 2-252 Unassigned 3732 253-254 Reserved for Experimentation [RFCXXXX] 3733 255 Reserved by IANA [RFCXXXX] 3735 Figure 36: OMNI Option Sub-Type Extension Values 3737 25.8. "OMNI RFC4380 UDP/IP Header Option" (New Registry) 3739 The OMNI Sub-Type Extension "RFC4380 UDP/IP Header Option" defines an 3740 8-bit Header Type field, for which IANA is instructed to create and 3741 maintain a new registry entitled "OMNI RFC4380 UDP/IP Header Option". 3742 Initial registry values are given below (future assignments are to be 3743 made through Expert Review [RFC8126]): 3745 Value Sub-Type name Reference 3746 ----- ------------- ---------- 3747 0 Origin Indication (IPv4) [RFC4380] 3748 1 Authentication Encapsulation [RFC4380] 3749 2 Origin Indication (IPv6) [RFCXXXX] 3750 3-252 Unassigned 3751 253-254 Reserved for Experimentation [RFCXXXX] 3752 255 Reserved by IANA [RFCXXXX] 3754 Figure 37: OMNI RFC4380 UDP/IP Header Option 3756 25.9. "OMNI RFC6081 UDP/IP Trailer Option" (New Registry) 3758 The OMNI Sub-Type Extension for "RFC6081 UDP/IP Trailer Option" 3759 defines an 8-bit Trailer Type field, for which IANA is instructed to 3760 create and maintain a new registry entitled "OMNI RFC6081 UDP/IP 3761 Trailer Option". Initial registry values are given below (future 3762 assignments are to be made through Expert Review [RFC8126]): 3764 Value Sub-Type name Reference 3765 ----- ------------- ---------- 3766 0 Unassigned 3767 1 Nonce [RFC6081] 3768 2 Unassigned 3769 3 Alternate Address (IPv4) [RFC6081] 3770 4 Neighbor Discovery Option [RFC6081] 3771 5 Random Port [RFC6081] 3772 6 Alternate Address (IPv6) [RFCXXXX] 3773 7-252 Unassigned 3774 253-254 Reserved for Experimentation [RFCXXXX] 3775 255 Reserved by IANA [RFCXXXX] 3777 Figure 38: OMNI RFC6081 Trailer Option 3779 25.10. Additional Considerations 3781 The IANA has assigned the UDP port number "8060" for an earlier 3782 experimental version of AERO [RFC6706]. This document together with 3783 [I-D.templin-intarea-6706bis] reclaims the UDP port number "8060" for 3784 'aero' as the service port for UDP/IP encapsulation. (Note that, 3785 although [RFC6706] was not widely implemented or deployed, any 3786 messages coded to that specification can be easily distinguished and 3787 ignored since they use the invalid ICMPv6 message type number '0'.) 3788 The IANA is therefore instructed to update the reference for UDP port 3789 number "8060" from "RFC6706" to "RFCXXXX" (i.e., this document). 3791 The IANA has assigned a 4 octet Private Enterprise Number (PEN) code 3792 "45282" in the "enterprise-numbers" registry. This document is the 3793 normative reference for using this code in DHCP Unique IDentifiers 3794 based on Enterprise Numbers ("DUID-EN for OMNI Interfaces") (see: 3795 Section 11). The IANA is therefore instructed to change the 3796 enterprise designation for PEN code "45282" from "LinkUp Networks" to 3797 "Overlay Multilink Network Interface (OMNI)". 3799 The IANA has assigned the ifType code "301 - omni - Overlay Multilink 3800 Network Interface (OMNI)" in accordance with Section 6 of [RFC8892]. 3801 The registration appears under the IANA "Structure of Management 3802 Information (SMI) Numbers (MIB Module Registrations) - Interface 3803 Types (ifType)" registry. 3805 No further IANA actions are required. 3807 26. Security Considerations 3809 Security considerations for IPv4 [RFC0791], IPv6 [RFC8200] and IPv6 3810 Neighbor Discovery [RFC4861] apply. OMNI interface IPv6 ND messages 3811 SHOULD include Nonce and Timestamp options [RFC3971] when transaction 3812 confirmation and/or time synchronization is needed. 3814 MN OMNI interfaces configured over secured ANET interfaces inherit 3815 the physical and/or link-layer security properties (i.e., "protected 3816 spectrum") of the connected ANETs. MN OMNI interfaces configured 3817 over open INET interfaces can use symmetric securing services such as 3818 VPNs or can by some other means establish a direct link. When a VPN 3819 or direct link may be impractical, however, the security services 3820 specified in [RFC7401] and/or [RFC4380] can be employed. While the 3821 OMNI link protects control plane messaging, applications must still 3822 employ end-to-end transport- or higher-layer security services to 3823 protect the data plane. 3825 Strong network layer security for control plane messages and 3826 forwarding path integrity for data plane messages between MSEs MUST 3827 be supported. In one example, the AERO service 3828 [I-D.templin-intarea-6706bis] constructs a spanning tree between MSEs 3829 and secures the links in the spanning tree with network layer 3830 security mechanisms such as IPsec [RFC4301] or Wireguard. Control 3831 plane messages are then constrained to travel only over the secured 3832 spanning tree paths and are therefore protected from attack or 3833 eavesdropping. Since data plane messages can travel over route 3834 optimized paths that do not strictly follow the spanning tree, 3835 however, end-to-end transport- or higher-layer security services are 3836 still required. 3838 Identity-based key verification infrastructure services such as iPSK 3839 may be necessary for verifying the identities claimed by MNs. This 3840 requirement should be harmonized with the manner in which (H)HITs are 3841 attested in a given operational environment. 3843 Security considerations for specific access network interface types 3844 are covered under the corresponding IP-over-(foo) specification 3845 (e.g., [RFC2464], [RFC2492], etc.). 3847 Security considerations for IPv6 fragmentation and reassembly are 3848 discussed in Section 6.9. 3850 27. Implementation Status 3852 AERO/OMNI Release-3.0.2 was tagged on October 15, 2020, and is 3853 undergoing internal testing. Additional internal releases expected 3854 within the coming months, with first public release expected end of 3855 1H2021. 3857 28. Acknowledgements 3859 The first version of this document was prepared per the consensus 3860 decision at the 7th Conference of the International Civil Aviation 3861 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 3862 2019. Consensus to take the document forward to the IETF was reached 3863 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 3864 Attendees and contributors included: Guray Acar, Danny Bharj, 3865 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 3866 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 3867 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 3868 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 3869 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 3870 Fryderyk Wrobel and Dongsong Zeng. 3872 The following individuals are acknowledged for their useful comments: 3873 Stuart Card, Michael Matyas, Robert Moskowitz, Madhu Niraula, Greg 3874 Saccone, Stephane Tamalet, Eric Vyncke. Pavel Drasil, Zdenek Jaron 3875 and Michal Skorepa are especially recognized for their many helpful 3876 ideas and suggestions. Madhuri Madhava Badgandi, Sean Dickson, Don 3877 Dillenburg, Joe Dudkowski, Vijayasarathy Rajagopalan, Ron Sackman and 3878 Katherine Tran are acknowledged for their hard work on the 3879 implementation and technical insights that led to improvements for 3880 the spec. 3882 Discussions on the IETF 6man and atn mailing lists during the fall of 3883 2020 suggested additional points to consider. The authors gratefully 3884 acknowledge the list members who contributed valuable insights 3885 through those discussions. Eric Vyncke and Erik Kline were the 3886 intarea ADs, while Bob Hinden and Ole Troan were the 6man WG chairs 3887 at the time the document was developed; they are all gratefully 3888 acknowledged for their many helpful insights. Many of the ideas in 3889 this document have further built on IETF experiences beginning as 3890 early as Y2K, with insights from colleagues including Brian 3891 Carpenter, Ralph Droms, Christian Huitema, Thomas Narten, Dave 3892 Thaler, Joe Touch, and many others who deserve recognition. 3894 Early observations on IP fragmentation performance implications were 3895 noted in the 1986 Digital Equipment Corporation (DEC) "qe reset" 3896 investigation, where fragment bursts from NFS UDP traffic triggered 3897 hardware resets resulting in communication failures. Jeff Chase, 3898 Fred Glover and Chet Juzsczak of the Ultrix Engineering Group led the 3899 investigation, and determined that setting a smaller NFS mount block 3900 size reduced the amount of fragmentation and suppressed the resets. 3901 Early observations on L2 media MTU issues were noted in the 1988 DEC 3902 FDDI investigation, where Raj Jain, KK Ramakrishnan and Kathy Wilde 3903 represented architectural considerations for FDDI networking in 3904 general including FDDI/Ethernet bridging. Jeff Mogul (who led the 3905 IETF Path MTU Discovery working group) and other DEC colleagues who 3906 supported these early investigations are also acknowledged. 3908 This work is aligned with the NASA Safe Autonomous Systems Operation 3909 (SASO) program under NASA contract number NNA16BD84C. 3911 This work is aligned with the FAA as per the SE2025 contract number 3912 DTFAWA-15-D-00030. 3914 This work is aligned with the Boeing Information Technology (BIT) 3915 Mobility Vision Lab (MVL) program. 3917 29. References 3919 29.1. Normative References 3921 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3922 DOI 10.17487/RFC0791, September 1981, 3923 . 3925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3926 Requirement Levels", BCP 14, RFC 2119, 3927 DOI 10.17487/RFC2119, March 1997, 3928 . 3930 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3931 "Definition of the Differentiated Services Field (DS 3932 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3933 DOI 10.17487/RFC2474, December 1998, 3934 . 3936 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 3937 "SEcure Neighbor Discovery (SEND)", RFC 3971, 3938 DOI 10.17487/RFC3971, March 2005, 3939 . 3941 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3942 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 3943 November 2005, . 3945 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3946 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3947 . 3949 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3950 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3951 2006, . 3953 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3954 Control Message Protocol (ICMPv6) for the Internet 3955 Protocol Version 6 (IPv6) Specification", STD 89, 3956 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3957 . 3959 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 3960 ICMPv6, UDP, and TCP Headers", RFC 4727, 3961 DOI 10.17487/RFC4727, November 2006, 3962 . 3964 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3965 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3966 DOI 10.17487/RFC4861, September 2007, 3967 . 3969 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3970 Address Autoconfiguration", RFC 4862, 3971 DOI 10.17487/RFC4862, September 2007, 3972 . 3974 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 3975 "Traffic Selectors for Flow Bindings", RFC 6088, 3976 DOI 10.17487/RFC6088, January 2011, 3977 . 3979 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 3980 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 3981 RFC 7401, DOI 10.17487/RFC7401, April 2015, 3982 . 3984 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 3985 Hosts in a Multi-Prefix Network", RFC 8028, 3986 DOI 10.17487/RFC8028, November 2016, 3987 . 3989 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3990 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3991 May 2017, . 3993 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3994 (IPv6) Specification", STD 86, RFC 8200, 3995 DOI 10.17487/RFC8200, July 2017, 3996 . 3998 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 3999 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 4000 DOI 10.17487/RFC8201, July 2017, 4001 . 4003 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 4004 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 4005 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 4006 RFC 8415, DOI 10.17487/RFC8415, November 2018, 4007 . 4009 29.2. Informative References 4011 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 4012 Interface for Civil Aviation, IETF Liaison Statement 4013 #1676, https://datatracker.ietf.org/liaison/1676/", March 4014 2020. 4016 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 4017 Aeronautical Telecommunication Network (ATN) using 4018 Internet Protocol Suite (IPS) Standards and Protocol), 4019 Draft Edition 3 (work-in-progress)", December 2020. 4021 [CKSUM] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, 4022 "Performance of Checksums and CRC's Over Real Data, IEEE/ 4023 ACM Transactions on Networking, Vol. 6, No. 5", October 4024 1998. 4026 [CRC] Jain, R., "Error Characteristics of Fiber Distributed Data 4027 Interface (FDDI), IEEE Transactions on Communications", 4028 August 1990. 4030 [I-D.ietf-drip-rid] 4031 Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, 4032 "UAS Remote ID", draft-ietf-drip-rid-06 (work in 4033 progress), December 2020. 4035 [I-D.ietf-intarea-tunnels] 4036 Touch, J. and M. Townsley, "IP Tunnels in the Internet 4037 Architecture", draft-ietf-intarea-tunnels-10 (work in 4038 progress), September 2019. 4040 [I-D.ietf-ipwave-vehicular-networking] 4041 Jeong, J., "IPv6 Wireless Access in Vehicular Environments 4042 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 4043 ipwave-vehicular-networking-19 (work in progress), July 4044 2020. 4046 [I-D.ietf-tsvwg-udp-options] 4047 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 4048 udp-options-09 (work in progress), November 2020. 4050 [I-D.templin-6man-dhcpv6-ndopt] 4051 Templin, F., "A Unified Stateful/Stateless Configuration 4052 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-11 4053 (work in progress), January 2021. 4055 [I-D.templin-6man-lla-type] 4056 Templin, F., "The IPv6 Link-Local Address Type Field", 4057 draft-templin-6man-lla-type-02 (work in progress), 4058 November 2020. 4060 [I-D.templin-intarea-6706bis] 4061 Templin, F., "Asymmetric Extended Route Optimization 4062 (AERO)", draft-templin-intarea-6706bis-87 (work in 4063 progress), January 2021. 4065 [IPV4-GUA] 4066 Postel, J., "IPv4 Address Space Registry, 4067 https://www.iana.org/assignments/ipv4-address-space/ipv4- 4068 address-space.xhtml", December 2020. 4070 [IPV6-GUA] 4071 Postel, J., "IPv6 Global Unicast Address Assignments, 4072 https://www.iana.org/assignments/ipv6-unicast-address- 4073 assignments/ipv6-unicast-address-assignments.xhtml", 4074 December 2020. 4076 [RFC0905] "ISO Transport Protocol specification ISO DP 8073", 4077 RFC 905, DOI 10.17487/RFC0905, April 1984, 4078 . 4080 [RFC1035] Mockapetris, P., "Domain names - implementation and 4081 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4082 November 1987, . 4084 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 4085 Communication Layers", STD 3, RFC 1122, 4086 DOI 10.17487/RFC1122, October 1989, 4087 . 4089 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4090 DOI 10.17487/RFC1191, November 1990, 4091 . 4093 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", 4094 RFC 1256, DOI 10.17487/RFC1256, September 1991, 4095 . 4097 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 4098 RFC 2131, DOI 10.17487/RFC2131, March 1997, 4099 . 4101 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 4102 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 4103 . 4105 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 4106 DOI 10.17487/RFC2328, April 1998, 4107 . 4109 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 4110 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 4111 . 4113 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 4114 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 4115 December 1998, . 4117 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 4118 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 4119 . 4121 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 4122 Domains without Explicit Tunnels", RFC 2529, 4123 DOI 10.17487/RFC2529, March 1999, 4124 . 4126 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 4127 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 4128 . 4130 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 4131 RFC 2923, DOI 10.17487/RFC2923, September 2000, 4132 . 4134 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4135 RFC 2983, DOI 10.17487/RFC2983, October 2000, 4136 . 4138 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4139 of Explicit Congestion Notification (ECN) to IP", 4140 RFC 3168, DOI 10.17487/RFC3168, September 2001, 4141 . 4143 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 4144 DOI 10.17487/RFC3330, September 2002, 4145 . 4147 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 4148 Considered Useful", BCP 82, RFC 3692, 4149 DOI 10.17487/RFC3692, January 2004, 4150 . 4152 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 4153 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 4154 DOI 10.17487/RFC3810, June 2004, 4155 . 4157 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 4158 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 4159 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 4160 RFC 3819, DOI 10.17487/RFC3819, July 2004, 4161 . 4163 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 4164 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 4165 2004, . 4167 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4168 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4169 DOI 10.17487/RFC4122, July 2005, 4170 . 4172 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 4173 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 4174 DOI 10.17487/RFC4271, January 2006, 4175 . 4177 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4178 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 4179 December 2005, . 4181 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 4182 Network Address Translations (NATs)", RFC 4380, 4183 DOI 10.17487/RFC4380, February 2006, 4184 . 4186 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 4187 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 4188 2006, . 4190 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 4191 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 4192 . 4194 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 4195 "Considerations for Internet Group Management Protocol 4196 (IGMP) and Multicast Listener Discovery (MLD) Snooping 4197 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 4198 . 4200 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 4201 "Internet Group Management Protocol (IGMP) / Multicast 4202 Listener Discovery (MLD)-Based Multicast Forwarding 4203 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 4204 August 2006, . 4206 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 4207 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 4208 . 4210 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 4211 Errors at High Data Rates", RFC 4963, 4212 DOI 10.17487/RFC4963, July 2007, 4213 . 4215 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 4216 Advertisement Flags Option", RFC 5175, 4217 DOI 10.17487/RFC5175, March 2008, 4218 . 4220 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 4221 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 4222 RFC 5213, DOI 10.17487/RFC5213, August 2008, 4223 . 4225 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 4226 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 4227 DOI 10.17487/RFC5214, March 2008, 4228 . 4230 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 4231 RFC 5558, DOI 10.17487/RFC5558, February 2010, 4232 . 4234 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 4235 Version 3 for IPv4 and IPv6", RFC 5798, 4236 DOI 10.17487/RFC5798, March 2010, 4237 . 4239 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 4240 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 4241 . 4243 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 4244 DOI 10.17487/RFC6081, January 2011, 4245 . 4247 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 4248 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 4249 DOI 10.17487/RFC6221, May 2011, 4250 . 4252 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 4253 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 4254 DOI 10.17487/RFC6355, August 2011, 4255 . 4257 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 4258 for Equal Cost Multipath Routing and Link Aggregation in 4259 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 4260 . 4262 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 4263 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 4264 2012, . 4266 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 4267 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 4268 . 4270 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 4271 UDP Checksums for Tunneled Packets", RFC 6935, 4272 DOI 10.17487/RFC6935, April 2013, 4273 . 4275 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 4276 for the Use of IPv6 UDP Datagrams with Zero Checksums", 4277 RFC 6936, DOI 10.17487/RFC6936, April 2013, 4278 . 4280 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 4281 with IPv6 Neighbor Discovery", RFC 6980, 4282 DOI 10.17487/RFC6980, August 2013, 4283 . 4285 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 4286 IETF Protocol and Documentation Usage for IEEE 802 4287 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 4288 October 2013, . 4290 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 4291 Requirements for IPv6 Customer Edge Routers", RFC 7084, 4292 DOI 10.17487/RFC7084, November 2013, 4293 . 4295 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 4296 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 4297 Boundary in IPv6 Addressing", RFC 7421, 4298 DOI 10.17487/RFC7421, January 2015, 4299 . 4301 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 4302 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 4303 DOI 10.17487/RFC7526, May 2015, 4304 . 4306 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 4307 DOI 10.17487/RFC7542, May 2015, 4308 . 4310 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 4311 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 4312 February 2016, . 4314 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 4315 Support for IP Hosts with Multi-Access Support", RFC 7847, 4316 DOI 10.17487/RFC7847, May 2016, 4317 . 4319 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4320 Writing an IANA Considerations Section in RFCs", BCP 26, 4321 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4322 . 4324 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 4325 Decraene, B., Litkowski, S., and R. Shakir, "Segment 4326 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 4327 July 2018, . 4329 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 4330 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 4331 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 4332 . 4334 [RFC8892] Thaler, D. and D. Romascanu, "Guidelines and Registration 4335 Procedures for Interface Types and Tunnel Types", 4336 RFC 8892, DOI 10.17487/RFC8892, August 2020, 4337 . 4339 [RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 4340 T. Voelker, "Packetization Layer Path MTU Discovery for 4341 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 4342 September 2020, . 4344 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 4345 and F. Gont, "IP Fragmentation Considered Fragile", 4346 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 4347 . 4349 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 4350 "Temporary Address Extensions for Stateless Address 4351 Autoconfiguration in IPv6", RFC 8981, 4352 DOI 10.17487/RFC8981, February 2021, 4353 . 4355 Appendix A. Interface Attribute Preferences Bitmap Encoding 4357 Adaptation of the OMNI option Interface Attributes Preferences Bitmap 4358 encoding to specific Internetworks such as the Aeronautical 4359 Telecommunications Network with Internet Protocol Services (ATN/IPS) 4360 may include link selection preferences based on other traffic 4361 classifiers (e.g., transport port numbers, etc.) in addition to the 4362 existing DSCP-based preferences. Nodes on specific Internetworks 4363 maintain a map of traffic classifiers to additional P[*] preference 4364 fields beyond the first 64. For example, TCP port 22 maps to P[67], 4365 TCP port 443 maps to P[70], UDP port 8060 maps to P[76], etc. 4367 Implementations use Simplex or Indexed encoding formats for P[*] 4368 encoding in order to encode a given set of traffic classifiers in the 4369 most efficient way. Some use cases may be more efficiently coded 4370 using Simplex form, while others may be more efficient using Indexed. 4371 Once a format is selected for preparation of a single Interface 4372 Attribute the same format must be used for the entire Interface 4373 Attribute sub-option. Different sub-options may use different 4374 formats. 4376 The following figures show coding examples for various Simplex and 4377 Indexed formats: 4379 0 1 2 3 4380 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 4381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4382 | Sub-Type=3| Sub-length=N | omIndex | omType | 4383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4384 | Provider ID | Link |R| API | Bitmap(0)=0xff|P00|P01|P02|P03| 4385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4386 |P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15|P16|P17|P18|P19| 4387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4388 |P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| Bitmap(1)=0xff| 4389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4390 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 4391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4392 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 4393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4394 | Bitmap(2)=0xff|P64|P65|P67|P68| ... 4395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4397 Figure 39: Example 1: Dense Simplex Encoding 4399 0 1 2 3 4400 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 4401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4402 | Sub-Type=3| Sub-length=N | omIndex | omType | 4403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4404 | Provider ID | Link |R| API | Bitmap(0)=0x00| Bitmap(1)=0x0f| 4405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4406 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 4407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4408 | Bitmap(2)=0x00| Bitmap(3)=0x00| Bitmap(4)=0x00| Bitmap(5)=0x00| 4409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4410 | Bitmap(6)=0xf0|192|193|194|195|196|197|198|199|200|201|202|203| 4411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4412 |204|205|206|207| Bitmap(7)=0x00| Bitmap(8)=0x0f|272|273|274|275| 4413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4414 |276|277|278|279|280|281|282|283|284|285|286|287| Bitmap(9)=0x00| 4415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4416 |Bitmap(10)=0x00| ... 4417 +-+-+-+-+-+-+-+-+-+-+- 4419 Figure 40: Example 2: Sparse Simplex Encoding 4421 0 1 2 3 4422 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 4423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4424 | Sub-Type=3| Sub-length=N | omIndex | omType | 4425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4426 | Provider ID | Link |R| API | Index = 0x00 | Bitmap = 0x80 | 4427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4428 |P00|P01|P02|P03| Index = 0x01 | Bitmap = 0x01 |P60|P61|P62|P63| 4429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4430 | Index = 0x10 | Bitmap = 0x80 |512|513|514|515| Index = 0x18 | 4431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4432 | Bitmap = 0x01 |796|797|798|799| ... 4433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 4435 Figure 41: Example 3: Indexed Encoding 4437 Appendix B. VDL Mode 2 Considerations 4439 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 4440 (VDLM2) that specifies an essential radio frequency data link service 4441 for aircraft and ground stations in worldwide civil aviation air 4442 traffic management. The VDLM2 link type is "multicast capable" 4443 [RFC4861], but with considerable differences from common multicast 4444 links such as Ethernet and IEEE 802.11. 4446 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 4447 magnitude less than most modern wireless networking gear. Second, 4448 due to the low available link bandwidth only VDLM2 ground stations 4449 (i.e., and not aircraft) are permitted to send broadcasts, and even 4450 so only as compact layer 2 "beacons". Third, aircraft employ the 4451 services of ground stations by performing unicast RS/RA exchanges 4452 upon receipt of beacons instead of listening for multicast RA 4453 messages and/or sending multicast RS messages. 4455 This beacon-oriented unicast RS/RA approach is necessary to conserve 4456 the already-scarce available link bandwidth. Moreover, since the 4457 numbers of beaconing ground stations operating within a given spatial 4458 range must be kept as sparse as possible, it would not be feasible to 4459 have different classes of ground stations within the same region 4460 observing different protocols. It is therefore highly desirable that 4461 all ground stations observe a common language of RS/RA as specified 4462 in this document. 4464 Note that links of this nature may benefit from compression 4465 techniques that reduce the bandwidth necessary for conveying the same 4466 amount of data. The IETF lpwan working group is considering possible 4467 alternatives: [https://datatracker.ietf.org/wg/lpwan/documents]. 4469 Appendix C. MN / AR Isolation Through L2 Address Mapping 4471 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 4472 unicast link-scoped IPv6 destination address. However, IPv6 ND 4473 messaging should be coordinated between the MN and AR only without 4474 invoking other nodes on the *NET. This implies that MN / AR control 4475 messaging should be isolated and not overheard by other nodes on the 4476 link. 4478 To support MN / AR isolation on some *NET links, ARs can maintain an 4479 OMNI-specific unicast L2 address ("MSADDR"). For Ethernet-compatible 4480 *NETs, this specification reserves one Ethernet unicast address TBD3 4481 (see: Section 25). For non-Ethernet statically-addressed *NETs, 4482 MSADDR is reserved per the assigned numbers authority for the *NET 4483 addressing space. For still other *NETs, MSADDR may be dynamically 4484 discovered through other means, e.g., L2 beacons. 4486 MNs map the L3 addresses of all IPv6 ND messages they send (i.e., 4487 both multicast and unicast) to MSADDR instead of to an ordinary 4488 unicast or multicast L2 address. In this way, all of the MN's IPv6 4489 ND messages will be received by ARs that are configured to accept 4490 packets destined to MSADDR. Note that multiple ARs on the link could 4491 be configured to accept packets destined to MSADDR, e.g., as a basis 4492 for supporting redundancy. 4494 Therefore, ARs must accept and process packets destined to MSADDR, 4495 while all other devices must not process packets destined to MSADDR. 4496 This model has well-established operational experience in Proxy 4497 Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 4499 Appendix D. Change Log 4501 << RFC Editor - remove prior to publication >> 4503 Differences from draft-templin-6man-omni-interface-35 to draft- 4504 templin-6man-omni-interface-36: 4506 o Major clarifications on aspects such as "hard/soft" PTB error 4507 messages 4509 o Made generic so that either IP protocol version (IPv4 or IPv6) can 4510 be used in the data plane. 4512 Differences from draft-templin-6man-omni-interface-31 to draft- 4513 templin-6man-omni-interface-32: 4515 o MTU 4516 o Support for multi-hop ANETS such as ISATAP. 4518 Differences from draft-templin-6man-omni-interface-29 to draft- 4519 templin-6man-omni-interface-30: 4521 o Moved link-layer addressing information into the OMNI option on a 4522 per-ifIndex basis 4524 o Renamed "ifIndex-tuple" to "Interface Attributes" 4526 Differences from draft-templin-6man-omni-interface-27 to draft- 4527 templin-6man-omni-interface-28: 4529 o Updates based on implementation experience. 4531 Differences from draft-templin-6man-omni-interface-25 to draft- 4532 templin-6man-omni-interface-26: 4534 o Further clarification on "aggregate" RA messages. 4536 o Expanded Security Considerations to discuss expectations for 4537 security in the Mobility Service. 4539 Differences from draft-templin-6man-omni-interface-20 to draft- 4540 templin-6man-omni-interface-21: 4542 o Safety-Based Multilink (SBM) and Performance-Based Multilink 4543 (PBM). 4545 Differences from draft-templin-6man-omni-interface-18 to draft- 4546 templin-6man-omni-interface-19: 4548 o SEND/CGA. 4550 Differences from draft-templin-6man-omni-interface-17 to draft- 4551 templin-6man-omni-interface-18: 4553 o Teredo 4555 Differences from draft-templin-6man-omni-interface-14 to draft- 4556 templin-6man-omni-interface-15: 4558 o Prefix length discussions removed. 4560 Differences from draft-templin-6man-omni-interface-12 to draft- 4561 templin-6man-omni-interface-13: 4563 o Teredo 4564 Differences from draft-templin-6man-omni-interface-11 to draft- 4565 templin-6man-omni-interface-12: 4567 o Major simplifications and clarifications on MTU and fragmentation. 4569 o Document now updates RFC4443 and RFC8201. 4571 Differences from draft-templin-6man-omni-interface-10 to draft- 4572 templin-6man-omni-interface-11: 4574 o Removed /64 assumption, resulting in new OMNI address format. 4576 Differences from draft-templin-6man-omni-interface-07 to draft- 4577 templin-6man-omni-interface-08: 4579 o OMNI MNs in the open Internet 4581 Differences from draft-templin-6man-omni-interface-06 to draft- 4582 templin-6man-omni-interface-07: 4584 o Brought back L2 MSADDR mapping text for MN / AR isolation based on 4585 L2 addressing. 4587 o Expanded "Transition Considerations". 4589 Differences from draft-templin-6man-omni-interface-05 to draft- 4590 templin-6man-omni-interface-06: 4592 o Brought back OMNI option "R" flag, and discussed its use. 4594 Differences from draft-templin-6man-omni-interface-04 to draft- 4595 templin-6man-omni-interface-05: 4597 o Transition considerations, and overhaul of RS/RA addressing with 4598 the inclusion of MSE addresses within the OMNI option instead of 4599 as RS/RA addresses (developed under FAA SE2025 contract number 4600 DTFAWA-15-D-00030). 4602 Differences from draft-templin-6man-omni-interface-02 to draft- 4603 templin-6man-omni-interface-03: 4605 o Added "advisory PTB messages" under FAA SE2025 contract number 4606 DTFAWA-15-D-00030. 4608 Differences from draft-templin-6man-omni-interface-01 to draft- 4609 templin-6man-omni-interface-02: 4611 o Removed "Primary" flag and supporting text. 4613 o Clarified that "Router Lifetime" applies to each ANET interface 4614 independently, and that the union of all ANET interface Router 4615 Lifetimes determines MSE lifetime. 4617 Differences from draft-templin-6man-omni-interface-00 to draft- 4618 templin-6man-omni-interface-01: 4620 o "All-MSEs" OMNI LLA defined. Also reserved fe80::ff00:0000/104 4621 for future use (most likely as "pseudo-multicast"). 4623 o Non-normative discussion of alternate OMNI LLA construction form 4624 made possible if the 64-bit assumption were relaxed. 4626 First draft version (draft-templin-atn-aero-interface-00): 4628 o Draft based on consensus decision of ICAO Working Group I Mobility 4629 Subgroup March 22, 2019. 4631 Authors' Addresses 4633 Fred L. Templin (editor) 4634 The Boeing Company 4635 P.O. Box 3707 4636 Seattle, WA 98124 4637 USA 4639 Email: fltemplin@acm.org 4641 Tony Whyman 4642 MWA Ltd c/o Inmarsat Global Ltd 4643 99 City Road 4644 London EC1Y 1AX 4645 England 4647 Email: tony.whyman@mccallumwhyman.com