idnits 2.17.1 draft-templin-6man-omni-51.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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2021) is 894 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2314, but not defined -- Looks like a reference, but probably isn't: '32' on line 2385 -- Looks like a reference, but probably isn't: '64' on line 2371 -- Looks like a reference, but probably isn't: '16' on line 2379 == Missing Reference: 'RFCXXXX' is mentioned on line 4963, but not defined -- Looks like a reference, but probably isn't: '1' on line 5677 == Missing Reference: 'N' is mentioned on line 5678, but not defined -- Looks like a reference, but probably isn't: '2' on line 5671 -- Looks like a reference, but probably isn't: '40' on line 5677 -- Looks like a reference, but probably isn't: '41' on line 5678 == Unused Reference: 'RFC2474' is defined on line 5160, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tsvwg-udp-options' is defined on line 5272, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-lla-type' is defined on line 5281, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-omni-interface' is defined on line 5286, but no explicit reference was found in the text == Unused Reference: 'RFC2225' is defined on line 5332, but no explicit reference was found in the text == Unused Reference: 'RFC2526' is defined on line 5348, but no explicit reference was found in the text == Unused Reference: 'RFC2529' is defined on line 5352, but no explicit reference was found in the text == Unused Reference: 'RFC3879' is defined on line 5407, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 5416, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 5459, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 5507, but no explicit reference was found in the text == Unused Reference: 'RFC7084' is defined on line 5545, but no explicit reference was found in the text == Unused Reference: 'RFC7323' is defined on line 5555, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 5610, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-37) exists of draft-ietf-drip-rid-13 == 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-24 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-13 == Outdated reference: A later version (-63) exists of draft-templin-6man-aero-36 -- Obsolete informational reference (is this intentional?): RFC 1146 (Obsoleted by RFC 6247) -- 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: 2 errors (**), 0 flaws (~~), 25 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft The Boeing Company 4 Intended status: Standards Track A. Whyman 5 Expires: May 19, 2022 MWA Ltd c/o Inmarsat Global Ltd 6 November 15, 2021 8 Transmission of IP Packets over Overlay Multilink Network (OMNI) 9 Interfaces 10 draft-templin-6man-omni-51 12 Abstract 14 Mobile network platforms and devices (e.g., aircraft of various 15 configurations, terrestrial vehicles, seagoing vessels, enterprise 16 wireless devices, pedestrians with cell phones, etc.) communicate 17 with networked correspondents over multiple access network data links 18 and configure mobile routers to connect end user networks. A 19 multilink interface specification is presented that enables mobile 20 nodes to coordinate with a network-based mobility service and/or with 21 other mobile node peers. This document specifies the transmission of 22 IP packets over Overlay 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 May 19, 2022. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 13 61 4. Overlay Multilink Network (OMNI) Interface Model . . . . . . 13 62 5. OMNI Interface Maximum Transmission Unit (MTU) . . . . . . . 19 63 5.1. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . . . 20 64 6. The OMNI Adaptation Layer (OAL) . . . . . . . . . . . . . . . 21 65 6.1. OAL Source Encapsulation and Fragmentation . . . . . . . 22 66 6.2. OAL *NET Encapsulation and Re-Encapsulation . . . . . . . 26 67 6.3. OAL *NET Decapsulation and Reassembly . . . . . . . . . . 29 68 6.4. OAL Header Compression . . . . . . . . . . . . . . . . . 30 69 6.5. OAL-in-OAL Encapsulation . . . . . . . . . . . . . . . . 32 70 6.6. OAL Identification Window Maintenance . . . . . . . . . . 35 71 6.7. OAL Fragment Retransmission . . . . . . . . . . . . . . . 39 72 6.8. OAL MTU Feedback Messaging . . . . . . . . . . . . . . . 40 73 6.9. OAL Requirements . . . . . . . . . . . . . . . . . . . . 42 74 6.10. OAL Fragmentation Security Implications . . . . . . . . . 43 75 6.11. OAL Super-Packets . . . . . . . . . . . . . . . . . . . . 45 76 6.12. OAL Bubbles . . . . . . . . . . . . . . . . . . . . . . . 47 77 7. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 47 78 8. Link-Local Addresses (LLAs) . . . . . . . . . . . . . . . . . 47 79 9. Unique-Local Addresses (ULAs) . . . . . . . . . . . . . . . . 49 80 10. Global Unicast Addresses (GUAs) . . . . . . . . . . . . . . . 51 81 11. Node Identification . . . . . . . . . . . . . . . . . . . . . 52 82 12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 53 83 12.1. The OMNI Option . . . . . . . . . . . . . . . . . . . . 54 84 12.2. OMNI Sub-Options . . . . . . . . . . . . . . . . . . . . 54 85 12.2.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 57 86 12.2.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 57 87 12.2.3. Interface Attributes . . . . . . . . . . . . . . . . 58 88 12.2.4. Multilink Forwarding Parameters . . . . . . . . . . 61 89 12.2.5. Traffic Selector . . . . . . . . . . . . . . . . . . 65 90 12.2.6. Geo Coordinates . . . . . . . . . . . . . . . . . . 67 91 12.2.7. Dynamic Host Configuration Protocol for IPv6 92 (DHCPv6) Message . . . . . . . . . . . . . . . . . . 67 93 12.2.8. Host Identity Protocol (HIP) Message . . . . . . . . 68 94 12.2.9. PIM-SM Message . . . . . . . . . . . . . . . . . . . 71 95 12.2.10. Fragmentation Report (FRAGREP) . . . . . . . . . . . 72 96 12.2.11. Node Identification . . . . . . . . . . . . . . . . 73 97 12.2.12. ICMPv6 Error . . . . . . . . . . . . . . . . . . . . 75 98 12.2.13. QUIC-TLS Message . . . . . . . . . . . . . . . . . . 76 99 12.2.14. Proxy/Server Departure . . . . . . . . . . . . . . . 76 100 12.2.15. OMNI Header Extension . . . . . . . . . . . . . . . 77 101 12.2.16. Sub-Type Extension . . . . . . . . . . . . . . . . . 79 102 13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 82 103 14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 82 104 14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 83 105 14.2. Client-Proxy/Server Loop Prevention . . . . . . . . . . 84 106 15. Router Discovery and Prefix Registration . . . . . . . . . . 84 107 15.1. Window Synchronization . . . . . . . . . . . . . . . . . 91 108 15.2. Router Discovery in IP Multihop and IPv4-Only Networks . 92 109 15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 94 110 16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 95 111 17. Proxy/Server Resilience . . . . . . . . . . . . . . . . . . . 96 112 18. Detecting and Responding to Proxy/Server Failures . . . . . . 96 113 19. Transition Considerations . . . . . . . . . . . . . . . . . . 97 114 20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 97 115 21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 100 116 22. (H)HITs and Temporary ULAs . . . . . . . . . . . . . . . . . 101 117 23. Address Selection . . . . . . . . . . . . . . . . . . . . . . 102 118 24. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 102 119 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 102 120 25.1. "Protocol Numbers" Registry . . . . . . . . . . . . . . 103 121 25.2. "IEEE 802 Numbers" Registry . . . . . . . . . . . . . . 103 122 25.3. "IPv4 Special-Purpose Address" Registry . . . . . . . . 103 123 25.4. "IPv6 Neighbor Discovery Option Formats" Registry . . . 103 124 25.5. "Ethernet Numbers" Registry . . . . . . . . . . . . . . 103 125 25.6. "ICMPv6 Code Fields: Type 2 - Packet Too Big" Registry . 104 126 25.7. "OMNI Option Sub-Type Values" (New Registry) . . . . . . 104 127 25.8. "OMNI Geo Coordinates Type Values" (New Registry) . . . 105 128 25.9. "OMNI Node Identification ID-Type Values" (New Registry) 105 129 25.10. "OMNI Option Sub-Type Extension Values" (New Registry) . 106 130 25.11. "OMNI RFC4380 UDP/IP Header Option" (New Registry) . . . 106 131 25.12. "OMNI RFC6081 UDP/IP Trailer Option" (New Registry) . . 107 132 25.13. Additional Considerations . . . . . . . . . . . . . . . 107 133 26. Security Considerations . . . . . . . . . . . . . . . . . . . 108 134 27. Implementation Status . . . . . . . . . . . . . . . . . . . . 109 135 28. Document Updates . . . . . . . . . . . . . . . . . . . . . . 109 136 29. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 109 137 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 138 30.1. Normative References . . . . . . . . . . . . . . . . . . 111 139 30.2. Informative References . . . . . . . . . . . . . . . . . 113 140 Appendix A. OAL Checksum Algorithm . . . . . . . . . . . . . . . 122 141 Appendix B. IPv6 ND Message Authentication and Integrity . . . . 122 142 Appendix C. VDL Mode 2 Considerations . . . . . . . . . . . . . 123 143 Appendix D. Client-Proxy/Server Isolation Through L2 Address 144 Mapping . . . . . . . . . . . . . . . . . . . . . . 124 146 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 124 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 149 1. Introduction 151 Mobile network platforms and devices (e.g., aircraft of various 152 configurations, terrestrial vehicles, seagoing vessels, enterprise 153 wireless devices, pedestrians with cellphones, etc.) configure mobile 154 routers with multiple interface connections to wireless and/or wired- 155 line data links. These data links may have diverse performance, cost 156 and availability properties that can change dynamically according to 157 mobility patterns, flight phases, proximity to infrastructure, etc. 158 The mobile router acts as a Client of a network-based Mobility 159 Service (MS) by configuring a virtual interface over its underlying 160 interface data link connections to support the "6M's of modern 161 Internetworking" (see below). 163 Each Client configures a virtual interface (termed the "Overlay 164 Multilink Network Interface (OMNI)") as a thin layer over its 165 underlying interfaces. The OMNI interface is therefore the only 166 interface abstraction exposed to the IP layer and behaves according 167 to the Non-Broadcast, Multiple Access (NBMA) interface principle, 168 while underlying interfaces appear as link layer communication 169 channels in the architecture. The OMNI interface internally employs 170 the "OMNI Adaptation Layer (OAL)" to ensure that original IP packets 171 are delivered without loss due to size restrictions. The OMNI 172 interface connects to a virtual overlay service known as the "OMNI 173 link". The OMNI link spans one or more Internetworks that may 174 include private-use infrastructures and/or the global public Internet 175 itself. 177 The Client's OMNI interface interacts with the MS and/or other 178 Clients through IPv6 Neighbor Discovery (ND) control message 179 exchanges [RFC4861]. The MS consists of a distributed set of service 180 nodes known as Proxy/Servers (and other infrastructure elements) that 181 also configure OMNI interfaces. An example MS termed "Automatic 182 Extended Route Optimization (AERO)" appears in 183 [I-D.templin-6man-aero]. In terms of precedence, the AERO 184 specification may provide first-principle insights into a 185 representative mobility service architecture as useful context for 186 this specification. 188 Each OMNI interface provides a multilink nexus for exchanging inbound 189 and outbound traffic via selected underlying interface(s). The IP 190 layer sees the OMNI interface as a point of connection to the OMNI 191 link. Each OMNI link has one or more associated Mobility Service 192 Prefixes (MSPs), which are typically IP Global Unicast Address (GUA) 193 prefixes assigned to the link and from which Mobile Network Prefixes 194 (MNPs) are derived. If there are multiple OMNI links, the IP layer 195 will see multiple OMNI interfaces. 197 Each Client receives an MNP through IPv6 ND control message exchanges 198 with Proxy/Servers. The Client uses the MNP for numbering 199 downstream-attached End User Networks (EUNs) independently of the 200 access network data links selected for data transport. The Client 201 acts as a mobile router on behalf of its EUNs, and uses OMNI 202 interface control messaging to coordinate with Proxy/Servers and/or 203 other Clients. The Client iterates its control messaging over each 204 of the OMNI interface's underlying interfaces in order to register 205 each interface with the MS (see Section 15). 207 Clients may connect to multiple distinct OMNI links within the same 208 OMNI domain by configuring multiple OMNI interfaces, e.g., omni0, 209 omni1, omni2, etc. Each OMNI interface is configured over a set of 210 underlying interfaces and provides a nexus for Safety-Based Multilink 211 (SBM) operation. Each OMNI interface within the same OMNI domain 212 configures a common ULA prefix [ULA]::/48, and configures a unique 213 16-bit Subnet ID '*' to construct the sub-prefix [ULA*]::/64 (see: 214 Section 9). The IP layer applies SBM routing to select a specific 215 OMNI interface, then the selected OMNI interface applies Performance- 216 Based Multilink (PBM) internally to select appropriate underlying 217 interfaces. Applications select SBM topologies based on IP layer 218 Segment Routing [RFC8402], while each OMNI interface orchestrates PBM 219 internally based on OMNI layer Segment Routing. 221 OMNI provides a link model suitable for a wide range of use cases. 222 In particular, the International Civil Aviation Organization (ICAO) 223 Working Group-I Mobility Subgroup is developing a future Aeronautical 224 Telecommunications Network with Internet Protocol Services (ATN/IPS) 225 and has issued a liaison statement requesting IETF adoption [ATN] in 226 support of ICAO Document 9896 [ATN-IPS]. The IETF IP Wireless Access 227 in Vehicular Environments (ipwave) working group has further included 228 problem statement and use case analysis for OMNI in a document now in 229 AD evaluation for RFC publication 230 [I-D.ietf-ipwave-vehicular-networking]. Still other communities of 231 interest include AEEC, RTCA Special Committee 228 (SC-228) and NASA 232 programs that examine commercial aviation, Urban Air Mobility (UAM) 233 and Unmanned Air Systems (UAS). Pedestrians with handheld devices 234 represent another large class of potential OMNI users. 236 OMNI supports the "6M's of modern Internetworking" including: 238 1. Multilink - a Client's ability to coordinate multiple diverse 239 underlying data links as a single logical unit (i.e., the OMNI 240 interface) to achieve the required communications performance and 241 reliability objectives. 243 2. Multinet - the ability to span the OMNI link over a segment 244 routing topology with multiple diverse administrative domain 245 network segments while maintaining seamless end-to-end 246 communications between mobile Clients and correspondents such as 247 air traffic controllers, fleet administrators, etc. 249 3. Mobility - a Client's ability to change network points of 250 attachment (e.g., moving between wireless base stations) which 251 may result in an underlying interface address change, but without 252 disruptions to ongoing communication sessions with peers over the 253 OMNI link. 255 4. Multicast - the ability to send a single network transmission 256 that reaches multiple Clients belonging to the same interest 257 group, but without disturbing other Clients not subscribed to the 258 interest group. 260 5. Multihop - a mobile Client vehicle-to-vehicle relaying capability 261 useful when multiple forwarding hops between vehicles may be 262 necessary to "reach back" to an infrastructure access point 263 connection to the OMNI link. 265 6. MTU assurance - the ability to deliver packets of various robust 266 sizes between peers without loss due to a link size restriction, 267 and to dynamically adjust packets sizes to achieve the optimal 268 performance for each independent traffic flow. 270 This document specifies the transmission of IP packets and control 271 messages over OMNI interfaces. The OMNI interface supports either IP 272 protocol version (i.e., IPv4 [RFC0791] or IPv6 [RFC8200]) as the 273 network layer data plane, while using IPv6 ND messaging as the 274 control plane independently of the data plane IP protocol(s). The 275 OAL operates as a sublayer between L3 and L2 based on IPv6 276 encapsulation [RFC2473] as discussed in the following sections. 278 2. Terminology 280 The terminology in the normative references applies; especially, the 281 terms "link" and "interface" are the same as defined in the IPv6 282 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 283 Additionally, this document assumes the following IPv6 ND message 284 types: Router Solicitation (RS), Router Advertisement (RA), Neighbor 285 Solicitation (NS), Neighbor Advertisement (NA) and Redirect. Clients 286 and Proxy/Servers that implement IPv6 ND maintain per-neighbor state 287 in Neighbor Cache Entries (NCEs). Each NCE is indexed by the 288 neighbor's Link-Local Address (LLA), while the Unique-Local Address 289 (ULA) used for encapsulation provides context for Identification 290 verification. 292 The Protocol Constants defined in Section 10 of [RFC4861] are used in 293 their same format and meaning in this document. The terms "All- 294 Routers multicast", "All-Nodes multicast" and "Subnet-Router anycast" 295 are the same as defined in [RFC4291] (with Link-Local scope assumed). 297 The term "IP" is used to refer collectively to either Internet 298 Protocol version (i.e., IPv4 [RFC0791] or IPv6 [RFC8200]) when a 299 specification at the layer in question applies equally to either 300 version. 302 The following terms are defined within the scope of this document: 304 Client 305 a network platform/device mobile router that has one or more 306 distinct upstream data link connections grouped together into one 307 or more logical units. The Client's data link connection 308 parameters can change over time due to, e.g., node mobility, link 309 quality, etc. The Client further connects downstream-attached End 310 User Networks (EUNs). 312 End User Network (EUN) 313 a simple or complex downstream-attached mobile network that 314 travels with the Client as a single logical unit. The IP 315 addresses assigned to EUN devices remain stable even if the 316 Client's upstream data link connections change. 318 Mobility Service (MS) 319 a mobile routing service that tracks Client movements and ensures 320 that Clients remain continuously reachable even across mobility 321 events. The MS consists of the set of all Proxy/Servers (and any 322 other supporting infrastructure nodes) for the OMNI link. 323 Specific MS details are out of scope for this document, with an 324 example found in [I-D.templin-6man-aero]. 326 Proxy/Server 327 a segment routing topology edge node that provides Clients with a 328 multi-purpose interface to the MS. As a server, the Proxy/Server 329 responds directly to some Client IPv6 ND messages. As a proxy, 330 the Proxy/Server forwards other Client IPv6 ND messages to other 331 Proxy/Servers and Clients. As a router, the Proxy/Server provides 332 a forwarding service for ordinary data packets that may be 333 essential in some environments and a last resort in others. 335 First-Hop Segment (FHS) Proxy/Server 336 a Proxy/Server reached via an underlying interface of the source 337 Client that forwards packets sent by the source Client over that 338 interface into the segment routing topology. FHS Proxy/Servers 339 act as intermediate forwarding nodes to facilitate RS/RA exchanges 340 between a Client and its Hub Proxy/Server. 342 Last-Hop Segment (LHS) Proxy/Server 343 a Proxy/Server for an underlying interface of the target Client 344 that forwards packets received from the segment routing topology 345 to the target Client over that interface. 347 Hub Proxy/Server 348 a single Proxy/Server selected by the Client that provides a 349 designated router service for all of the Client's underlying 350 interfaces. Clients normally select the first FHS Proxy/Server 351 they coordinate with to serve in the Hub role (as all FHS Proxy/ 352 Servers are equally capable candidates to serve in that capacity), 353 however the Hub can also be any available Proxy/Server for the 354 OMNI link (as there is no requirement that the Hub must also be 355 one of the Client's FHS Proxy/Servers). 357 Segment Routing Topology (SRT) 358 a multinet forwarding region between the FHS Proxy/Server and LHS 359 Proxy/Server. FHS/LHS Proxy/Servers and the SRT span the OMNI 360 link on behalf of source/target Client pairs using segment routing 361 in a manner outside the scope of this document (see: 362 [I-D.templin-6man-aero]). 364 Mobility Service Prefix (MSP) 365 an aggregated IP Global Unicast Address (GUA) prefix (e.g., 366 2001:db8::/32, 192.0.2.0/24, etc.) assigned to the OMNI link and 367 from which more-specific Mobile Network Prefixes (MNPs) are 368 delegated. OMNI link administrators typically obtain MSPs from an 369 Internet address registry, however private-use prefixes can 370 alternatively be used subject to certain limitations (see: 371 Section 10). OMNI links that connect to the global Internet 372 advertise their MSPs to their interdomain routing peers. 374 Mobile Network Prefix (MNP) 375 a longer IP prefix delegated from an MSP (e.g., 376 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and assigned to a 377 Client. Clients sub-delegate the MNP to devices located in EUNs. 378 Note that OMNI link Relay nodes may also service non-MNP routes 379 (i.e., GUA prefixes not covered by an MSP) but that these 380 correspond to fixed correspondent nodes and not Clients. Other 381 than this distinction, MNP and non-MNP routes are treated exactly 382 the same by the OMNI routing system. 384 Access Network (ANET) 385 a data link service network (e.g., an aviation radio access 386 network, satellite service provider network, cellular operator 387 network, WiFi network, etc.) that connects Clients. Physical and/ 388 or data link level security is assumed, and sometimes referred to 389 as "protected spectrum". Private enterprise networks and ground 390 domain aviation service networks may provide multiple secured IP 391 hops between the Client's point of connection and the nearest 392 Proxy/Server. 394 ANET interface 395 a Client's attachment to a link in an ANET. 397 Internetwork (INET) 398 a connected network region with a coherent IP addressing plan that 399 provides transit forwarding services between ANETs and nodes that 400 connect directly to the open INET via unprotected media. No 401 physical and/or data link level security is assumed, therefore 402 security must be applied by upper layers. The global public 403 Internet itself is an example. 405 INET interface 406 a node's attachment to a link in an INET. 408 *NET 409 a "wildcard" term used when a given specification applies equally 410 to both ANET and INET cases. 412 INADDR 413 the IP address (and also the UDP port number when UDP is used) 414 that appear in *NET header address fields. The terms "*NET 415 address" and "INADDR" are used interchangeably. 417 OMNI link 418 a Non-Broadcast, Multiple Access (NBMA) virtual overlay configured 419 over one or more INETs and their connected ANETs. An OMNI link 420 may comprise multiple distinct segments joined by bridges the same 421 as for any link; the addressing plans in each segment may be 422 mutually exclusive and managed by different administrative 423 entities. Proxy/Servers and other MS infrastructure elements 424 extend the link to support communications between Clients as 425 single-hop neighbors. 427 OMNI interface 428 a node's attachment to an OMNI link, and configured over one or 429 more underlying *NET interfaces. If there are multiple OMNI links 430 in an OMNI domain, a separate OMNI interface is configured for 431 each link. As with any interface, the OMNI interface configures a 432 Maximum Transmission Unit (MTU) and a Maximum Reassembly Unit 433 (MRU). 435 OMNI Adaptation Layer (OAL) 436 an OMNI interface sublayer service whereby original IP packets 437 admitted into the interface are wrapped in an IPv6 header and 438 subject to fragmentation and reassembly. The OAL is also 439 responsible for generating MTU-related control messages as 440 necessary, and for providing addressing context for OMNI link SRT 441 traversal. 443 original IP packet 444 a whole IP packet or fragment admitted into the OMNI interface by 445 the network layer prior to OAL encapsulation and fragmentation, or 446 an IP packet delivered to the network layer by the OMNI interface 447 following OAL decapsulation and reassembly. 449 OAL packet 450 an original IP packet encapsulated in an IPv6 header (i.e., the 451 OAL header) then submitted for OAL fragmentation and reassembly. 453 OAL fragment 454 a portion of an OAL packet following fragmentation but prior to 455 *NET encapsulation, or following *NET encapsulation but prior to 456 OAL reassembly. 458 (OAL) atomic fragment 459 an OAL packet that does not require fragmentation is always 460 encapsulated as an "atomic fragment" with a Fragment Header with 461 Fragment Offset and More Fragments both set to 0, but with a valid 462 Identification value. 464 (OAL) carrier packet 465 an encapsulated OAL fragment following *NET encapsulation or prior 466 to *NET decapsulation. OAL sources and destinations exchange 467 carrier packets over underlying interfaces, and may be separated 468 by one or more OAL intermediate nodes. OAL intermediate nodes may 469 perform re-encapsulation on carrier packets by removing the *NET 470 headers of the first hop network and replacing them with new *NET 471 headers for the next hop network. 473 OAL source 474 an OMNI interface acts as an OAL source when it encapsulates 475 original IP packets to form OAL packets, then performs OAL 476 fragmentation and *NET encapsulation to create carrier packets. 478 OAL destination 479 an OMNI interface acts as an OAL destination when it decapsulates 480 carrier packets, then performs OAL reassembly and decapsulation to 481 derive the original IP packet. 483 OAL intermediate node 484 an OMNI interface acts as an OAL intermediate node when it removes 485 the *NET headers of carrier packets received on a first segment, 486 then re-encapsulates the carrier packets in new *NET headers and 487 forwards them into the next segment. 489 OMNI Option 490 an IPv6 Neighbor Discovery option providing multilink parameters 491 for the OMNI interface as specified in Section 12. 493 Mobile Network Prefix Link Local Address (MNP-LLA) 494 an IPv6 Link Local Address that embeds the most significant 64 495 bits of an MNP in the lower 64 bits of fe80::/64, as specified in 496 Section 8. 498 Mobile Network Prefix Unique Local Address (MNP-ULA) 499 an IPv6 Unique-Local Address derived from an MNP-LLA. 501 Administrative Link Local Address (ADM-LLA) 502 an IPv6 Link Local Address that embeds a 32-bit administratively- 503 assigned identification value in the lower 32 bits of fe80::/96, 504 as specified in Section 8. 506 Administrative Unique Local Address (ADM-ULA) 507 an IPv6 Unique-Local Address derived from an ADM-LLA. 509 Multilink 510 an OMNI interface's manner of managing diverse underlying 511 interface connections to data links as a single logical unit. The 512 OMNI interface provides a single unified interface to upper 513 layers, while underlying interface selections are performed on a 514 per-packet basis considering traffic selectors such as DSCP, flow 515 label, application policy, signal quality, cost, etc. Multilink 516 selections are coordinated in both the outbound and inbound 517 directions based on source/target underlying interface pairs. 519 Multinet 520 an OAL intermediate node's manner of spanning multiple diverse IP 521 Internetwork and/or private enterprise network "segments" at the 522 OAL layer below IP. Through intermediate node concatenation of 523 SRT bridged network segments, multiple diverse Internetworks (such 524 as the global public IPv4 and IPv6 Internets) can serve as transit 525 segments in a bridged path for forwarding IP packets end-to-end. 526 This bridging capability provide benefits such as supporting IPv4/ 527 IPv6 transition and coexistence, joining multiple diverse operator 528 networks into a cooperative single service network, etc. 530 Multihop 531 an iterative relaying of IP packets between Client's over an OMNI 532 underlying interface technology (such as omnidirectional wireless) 533 without support of fixed infrastructure. Multihop services entail 534 Client-to-Client relaying within a Mobile/Vehicular Ad-hoc Network 535 (MANET/VANET) for Vehicle-to-Vehicle (V2V) communications and/or 536 for Vehicle-to-Infrastructure (V2I) "range extension" where 537 Clients within range of communications infrastructure elements 538 provide forwarding services for other Clients. 540 L2 541 The second layer in the OSI network model. Also known as "layer- 542 2", "link-layer", "sub-IP layer", "data link layer", etc. 544 L3 545 The third layer in the OSI network model. Also known as "layer- 546 3", "network-layer", "IP layer", etc. 548 underlying interface 549 a *NET interface over which an OMNI interface is configured. The 550 OMNI interface is seen as a L3 interface by the IP layer, and each 551 underlying interface is seen as a L2 interface by the OMNI 552 interface. The underlying interface either connects directly to 553 the physical communications media or coordinates with another node 554 where the physical media is hosted. 556 Mobility Service Identification (MSID) 557 All MS elements (including Proxy/Servers and other MS nodes) 558 assign a unique 32-bit Identification (MSID) (see: Section 8) 559 according to MS-specific guidelines (e.g., see: 560 [I-D.templin-6man-aero]). 562 Safety-Based Multilink (SBM) 563 A means for ensuring fault tolerance through redundancy by 564 connecting multiple affiliated OMNI interfaces to independent 565 routing topologies (i.e., multiple independent OMNI links). 567 Performance Based Multilink (PBM) 568 A means for selecting one or more underlying interface(s) for 569 packet transmission and reception within a single OMNI interface. 571 OMNI Domain 572 The set of all SBM/PBM OMNI links that collectively provides 573 services for a common set of MSPs. Each OMNI domain consists of a 574 set of affiliated OMNI links that all configure the same ::/48 ULA 575 prefix with a unique 16-bit Subnet ID as discussed in Section 9. 577 Multilink Forwarding Information Base (MFIB) 578 A forwarding table on each OMNI source, destination and 579 intermediate node that includes Multilink Forwarding Vectors (MFV) 580 with both next hop forwarding instructions and context for 581 reconstructing compressed headers for specific underlying 582 interface pairs used to communicate with peers. See: 583 [I-D.templin-6man-aero] for further discussion. 585 Multilink Forwarding Vector (MFV) 586 An MFIB entry that includes soft state for each underlying 587 interface pairwise communication session between peers. MFVs are 588 identified by both a next-hop and previous-hop MFV Index (MFVI), 589 with the next-hop established based on an IPv6 ND solicitation and 590 the previous hop established based on the solicited IPv6 ND 591 advertisement response. See: [I-D.templin-6man-aero] for further 592 discussion. 594 Multilink Forwarding Vector Index (MVFI) 595 A 4 octet value selected by an OMNI node when it creates an MFV, 596 then advertised to either a next-hop or previous-hop. OMNI 597 intermediate nodes assign two distinct MFVIs for each MFV and 598 advertise one to the next-hop and the other to the previous-hop. 599 OMNI end systems assign and advertise a single MFVI. See: 600 [I-D.templin-6man-aero] for further discussion. 602 3. Requirements 604 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 605 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 606 "OPTIONAL" in this document are to be interpreted as described in BCP 607 14 [RFC2119][RFC8174] when, and only when, they appear in all 608 capitals, as shown here. 610 An implementation is not required to internally use the architectural 611 constructs described here so long as its external behavior is 612 consistent with that described in this document. 614 4. Overlay Multilink Network (OMNI) Interface Model 616 An OMNI interface is a virtual interface configured over one or more 617 underlying interfaces, which may be physical (e.g., an aeronautical 618 radio link, etc.) or virtual (e.g., an Internet or higher-layer 619 "tunnel"). The OMNI interface architectural layering model is the 620 same as in [RFC5558][RFC7847], and augmented as shown in Figure 1. 621 The IP layer therefore sees the OMNI interface as a single L3 622 interface nexus for multiple underlying interfaces that appear as L2 623 communication channels in the architecture. 625 +----------------------------+ 626 | Upper Layer Protocol | 627 Session-to-IP +---->| | 628 Address Binding | +----------------------------+ 629 +---->| IP (L3) | 630 IP Address +---->| | 631 Binding | +----------------------------+ 632 +---->| OMNI Interface | 633 Logical-to- +---->| (OMNI Adaptation Layer) | 634 Physical | +----------------------------+ 635 Interface +---->| L2 | L2 | | L2 | 636 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 637 +------+------+ +------+ 638 | L1 | L1 | | L1 | 639 | | | | | 640 +------+------+ +------+ 642 Figure 1: OMNI Interface Architectural Layering Model 644 Each underlying interface provides an L2/L1 abstraction according to 645 one of the following models: 647 o INET interfaces connect to an INET either natively or through one 648 or several IPv4 Network Address Translators (NATs). Native INET 649 interfaces have global IP addresses that are reachable from any 650 INET correspondent. NATed INET interfaces typically have private 651 IP addresses and connect to a private network behind one or more 652 NATs with the outermost NAT providing INET access. 654 o ANET interfaces connect to a protected and secured ANET that is 655 separated from the open INET by Proxy/Servers. The ANET interface 656 may be either on the same L2 link segment as a Proxy/Server, or 657 separated from a Proxy/Server by multiple IP hops. (Note that 658 NATs may appear internally within an ANET and may require NAT 659 traversal on the path to the Proxy/Server the same as for the INET 660 case.) 662 o VPNed interfaces use security encapsulation over a *NET to a 663 Proxy/Server acting as a Virtual Private Network (VPN) gateway. 664 Other than the link-layer encapsulation format, VPNed interfaces 665 behave the same as for Direct interfaces. 667 o Direct (aka "point-to-point") interfaces connect directly to a 668 peer (i.e., a Proxy/Server or another Client) without crossing any 669 *NET paths. An example is a line-of-sight link between a remote 670 pilot and an unmanned aircraft. 672 The OMNI interface forwards original IP packets from the network 673 layer (L3) using the OMNI Adaptation Layer (OAL) (see: Section 5) as 674 an encapsulation and fragmentation sublayer service. This "OAL 675 source" then further encapsulates the resulting OAL packets/fragments 676 in *NET headers to create "carrier packets" for transmission over 677 underlying interfaces (L2/L1). The target OMNI interface receives 678 the carrier packets from underlying interfaces (L1/L2) and discards 679 the *NET headers. If the resulting OAL packets/fragments are 680 addressed to itself, the OMNI interface acts as an "OAL destination" 681 and performs reassembly if necessary, discards the OAL encapsulation, 682 and delivers the original IP packet to the network layer (L3). If 683 the OAL fragments are addressed to another node, the OMNI interface 684 instead acts as an "OAL intermediate node" by re-encapsulating in new 685 *NET headers and forwarding the new carrier packets over an 686 underlying interface without reassembling or discarding the OAL 687 encapsulation. The OAL source and OAL destination are seen as 688 "neighbors" on the OMNI link, while OAL intermediate nodes provide a 689 virtual bridging service that joins the segments of a (multinet) 690 Segment Routing Topology (SRT). 692 The OMNI interface can send/receive original IP packets to/from 693 underlying interfaces while including/omitting various encapsulations 694 including OAL, UDP, IP and L2. The network layer can also access the 695 underlying interfaces directly while bypassing the OMNI interface 696 entirely when necessary. This architectural flexibility may be 697 beneficial for underlying interfaces (e.g., some aviation data links) 698 for which encapsulation overhead may be a primary consideration. 699 OMNI interfaces that send original IP packets directly over 700 underlying interfaces without invoking the OAL can only reach peers 701 located on the same OMNI link segment. Source Clients can instead 702 use the OAL to coordinate with target Clients in the same or 703 different OMNI link segments by sending initial carrier packets to a 704 First-Hop Segment (FHS) Proxy/Server. The FHS Proxy/Sever then 705 forwards the packets into the SRT spanning tree, which transports 706 them to a Last-Hop Segment (LHS) Proxy/Server for the target Client. 708 Original IP packets sent directly over underlying interfaces are 709 subject to the same path MTU related issues as for any 710 Internetworking path, and do not include per-packet identifications 711 that can be used for data origin verification and/or link-layer 712 retransmissions. Original IP packets presented directly to an 713 underlying interface that exceed the underlying network path MTU are 714 dropped with an ordinary ICMPv6 Packet Too Big (PTB) message 715 returned. These PTB messages are subject to loss [RFC2923] the same 716 as for any non-OMNI IP interface. 718 The OMNI interface encapsulation/decapsulation layering possibilities 719 are shown in Figure 2 below. Imaginary vertical lines drawn between 720 the Network Layer and Underlying interfaces in the figure denote the 721 encapsulation/decapsulation layering combinations possible. Common 722 combinations include NULL (i.e., direct access to underlying 723 interfaces with or without using the OMNI interface), IP/IP, IP/UDP/ 724 IP, IP/UDP/IP/L2, IP/OAL/UDP/IP, IP/OAL/UDP/L2, etc. 726 +------------------------------------------------------------+ 727 | Network Layer (Original IP packets) | 728 +--+---------------------------------------------------------+ 729 | OMNI Interface (virtual sublayer nexus) | 730 +--------------------------+------------------------------+ 731 | OAL Encaps/Decaps | 732 +------------------------------+ 733 | OAL Frag/Reass | 734 +------------+---------------+--------------+ 735 | UDP Encaps/Decaps/Compress | 736 +----+---+------------+--------+--+ +--------+ 737 | IP E/D | | IP E/D | | IP E/D | 738 +---+------+-+----+ +--+---+----+ +----+---+--+ 739 |L2 E/D| |L2 E/D| |L2 E/D| |L2 E/D| 740 +-------+------+---+------+----+------+---------------+------+ 741 | Underlying Interfaces | 742 +------------------------------------------------------------+ 744 Figure 2: OMNI Interface Layering 746 The OMNI/OAL model gives rise to a number of opportunities: 748 o Clients receive MNPs from the MS, and coordinate with the MS 749 through IPv6 ND message exchanges with Proxy/Servers. Clients use 750 the MNP to construct a unique Link-Local Address (MNP-LLA) through 751 the algorithmic derivation specified in Section 8 and assign the 752 LLA to the OMNI interface. Since MNP-LLAs are uniquely derived 753 from an MNP, no Duplicate Address Detection (DAD) or Multicast 754 Listener Discovery (MLD) messaging is necessary. 756 o since Temporary ULAs are statistically unique, they can be used 757 without DAD until an MNP-LLA is obtained. 759 o underlying interfaces on the same L2 link segment as a Proxy/ 760 Server do not require any L3 addresses (i.e., not even link-local) 761 in environments where communications are coordinated entirely over 762 the OMNI interface. 764 o as underlying interface properties change (e.g., link quality, 765 cost, availability, etc.), any active interface can be used to 766 update the profiles of multiple additional interfaces in a single 767 message. This allows for timely adaptation and service continuity 768 under dynamically changing conditions. 770 o coordinating underlying interfaces in this way allows them to be 771 represented in a unified MS profile with provisions for mobility 772 and multilink operations. 774 o exposing a single virtual interface abstraction to the IPv6 layer 775 allows for multilink operation (including QoS based link 776 selection, packet replication, load balancing, etc.) at L2 while 777 still permitting L3 traffic shaping based on, e.g., DSCP, flow 778 label, etc. 780 o the OMNI interface allows multinet traversal over the SRT when 781 communications across different administrative domain network 782 segments are necessary. This mode of operation would not be 783 possible via direct communications over the underlying interfaces 784 themselves. 786 o the OAL supports lossless and adaptive path MTU mitigations not 787 available for communications directly over the underlying 788 interfaces themselves. The OAL supports "packing" of multiple IP 789 payload packets within a single OAL "super-packet". 791 o the OAL applies per-packet identification values that allow for 792 link-layer reliability and data origin authentication. 794 o L3 sees the OMNI interface as a point of connection to the OMNI 795 link; if there are multiple OMNI links (i.e., multiple MS's), L3 796 will see multiple OMNI interfaces. 798 o Multiple independent OMNI interfaces can be used for increased 799 fault tolerance through Safety-Based Multilink (SBM), with 800 Performance-Based Multilink (PBM) applied within each interface. 802 Note that even when the OMNI virtual interface is present, 803 applications can still access underlying interfaces either through 804 the network protocol stack using an Internet socket or directly using 805 a raw socket. This allows for intra-network (or point-to-point) 806 communications without invoking the OMNI interface and/or OAL. For 807 example, when an IPv6 OMNI interface is configured over an underlying 808 IPv4 interface, applications can still invoke IPv4 intra-network 809 communications as long as the communicating endpoints are not subject 810 to mobility dynamics. 812 Figure 3 depicts the architectural model for a source Client with an 813 attached EUN connecting to the OMNI link via multiple independent 814 *NETs. The Client's OMNI interface sends IPv6 ND messages over 815 available underlying interfaces to FHS Proxy/Servers using any 816 necessary *NET encapsulations. The IPv6 ND messages traverse the 817 *NETs until they reach an FHS Proxy/Server (FHS#1, FHS#2, ..., 818 FHS#n), which returns an IPv6 ND message response and/or forwards a 819 proxyed version of the message over the SRT to an LHS Proxy/Server 820 near the target Client (LHS#1, LHS#2, ..., LHS#m). The Hop Limit in 821 IPv6 ND messages is not decremented due to encapsulation; hence, the 822 source and target Client OMNI interfaces appear to be attached to a 823 common link. 825 +--------------+ (:::)-. 826 |Source Client |<-->.-(::EUN:::) 827 +--------------+ `-(::::)-' 828 |OMNI interface| 829 +----+----+----+ 830 +--------|IF#1|IF#2|IF#n|------ + 831 / +----+----+----+ \ 832 / | \ 833 / | \ 834 v v v 835 (:::)-. (:::)-. (:::)-. 836 .-(::*NET:::) .-(::*NET:::) .-(::*NET:::) 837 `-(::::)-' `-(::::)-' `-(::::)-' 838 +-----+ +-----+ +-----+ 839 ... |FHS#1| ......... |FHS#2| ......... |FHS#n| ... 840 . +--|--+ +--|--+ +--|--+ . 841 . | | | 842 . \ v / . 843 . \ / . 844 . v (:::)-. v . 845 . .-(::::::::) . 846 . .-(::: Segment :::)-. . 847 . (::::: Routing ::::) . 848 . `-(:: Topology ::)-' . 849 . `-(:::::::-' . 850 . / | \ . 851 . / | \ . 852 . v v v 853 . +-----+ +-----+ +-----+ . 854 ... |LHS#1| ......... |LHS#2| ......... |LHS#m| ... 855 +--|--+ +--|--+ +--|--+ 856 \ | / 857 v v v 858 <-- Target Clients --> 860 Figure 3: Source/Target Client Coordination over the OMNI Link 862 After the initial IPv6 ND message exchange, the source Client (and/or 863 any nodes on its attached EUNs) can send packets to the target Client 864 over the OMNI interface. OMNI interface multilink services will 865 forward the packets via FHS Proxy/Servers for the correct underlying 866 *NETs. The FHS Proxy/Server then forwards them over the SRT which 867 delivers them to an LHS Proxy/Server, and the LHS Proxy/Server in 868 turn forwards the packets to the target Client. (Note that when the 869 source and target Client are on the same SRT segment, the FHS and LHS 870 Proxy/Servers may be one and the same.) 872 Clients select a Hub Proxy/Server (not shown in the figure), which 873 will often be one of their FHS Proxy/Servers but could also be any 874 Proxy/Server on the OMNI link. Clients then register all of their 875 underlying interfaces with the Hub Proxy/Server via the FHS Proxy/ 876 Server in a pure proxy role. The Hub Proxy/Server then provides a 877 designated router service for the Client, and the Client can quickly 878 migrate to a new Hub Proxy/Server if the first becomes unresponsive. 880 Clients therefore use Proxy/Servers as gateways into the SRT to reach 881 OMNI link correspondents via a spanning tree established in a manner 882 outside the scope of this document. Proxy/Servers forward critical 883 MS control messages via the secured spanning tree and forward other 884 messages via the unsecured spanning tree (see Security 885 Considerations). When route optimization is applied as discussed in 886 [I-D.templin-6man-aero], Clients can instead forward directly to an 887 SRT intermediate node themselves (or directly to correspondents in 888 the same SRT segment) to reduce Proxy/Server load. 890 5. OMNI Interface Maximum Transmission Unit (MTU) 892 The OMNI interface observes the link nature of tunnels, including the 893 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 894 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 895 The OMNI interface is configured over one or more underlying 896 interfaces as discussed in Section 4, where the interfaces (and their 897 associated *NET paths) may have diverse MTUs. OMNI interface 898 considerations for accommodating original IP packets of various sizes 899 are discussed in the following sections. 901 IPv6 underlying interfaces are REQUIRED to configure a minimum MTU of 902 1280 octets and a minimum MRU of 1500 octets [RFC8200]. Therefore, 903 the minimum IPv6 path MTU is 1280 octets since routers on the path 904 are not permitted to perform network fragmentation even though the 905 destination is required to reassemble more. The network therefore 906 MUST forward original IP packets of at least 1280 octets without 907 generating an IPv6 Path MTU Discovery (PMTUD) Packet Too Big (PTB) 908 message [RFC8201]. (While the source can apply "source 909 fragmentation" for locally-generated IPv6 packets up to 1500 octets 910 and larger still if it knows the destination configures a larger MRU, 911 this does not affect the minimum IPv6 path MTU.) 913 IPv4 underlying interfaces are REQUIRED to configure a minimum MTU of 914 68 octets [RFC0791] and a minimum MRU of 576 octets 915 [RFC0791][RFC1122]. Therefore, when the Don't Fragment (DF) bit in 916 the IPv4 header is set to 0 the minimum IPv4 path MTU is 576 octets 917 since routers on the path support network fragmentation and the 918 destination is required to reassemble at least that much. The OMNI 919 interface therefore MUST set DF to 0 in the IPv4 encapsulation 920 headers of carrier packets that are no larger than 576 octets, and 921 SHOULD set DF to 1 in larger carrier packets unless it has a way to 922 determine the encapsulation destination MRU and has carefully 923 considered the issues discussed in Section 6.10. 925 When the network layer admits an original IP packet into the OMNI 926 interface the OAL prepends an IPv6 encapsulation header (see: 927 Section 6) where the 16-bit Payload Length field limits the maximum- 928 sized original IP packet to (2**16 -1) = 65,535 octets; this is also 929 the maximum size that the OAL can accommodate with IPv6 930 fragmentation. The OMNI interface therefore sets both an MTU and MRU 931 of 65,535 octets to support assured delivery of original packets no 932 larger than this size even if IPv6 fragmentation is required. The 933 OMNI interface then employs the OAL as an encapsulation sublayer 934 service to transform original IP packets into OAL packets/fragments, 935 and the OAL in turn uses *NET encapsulation to forward carrier 936 packets over underlying interfaces (see: Section 6). 938 Note: As for any IP interface, the OMNI interface MAY set a smaller 939 MTU (to a minimum of 1280 for IPv6 or 576 for IPv4), but MUST NOT set 940 a smaller MRU. 942 5.1. IPv6 Jumbograms 944 While the maximum-sized original IP packet that the OAL can 945 accommodate with IPv6 fragmentation is 65,535 octets, OMNI interfaces 946 can forward still larger IPv6 packets as OAL "atomic fragments" 947 through the application of IPv6 Jumbograms [RFC2675]. For these 948 larger packets, the OMNI interface performs OAL encapsulation by 949 appending an IPv6 header followed by an 8-octet Hop-By-Hop header 950 with Jumbo Payload option followed by a Routing Header of no more 951 than 40-octets (if necessary) and finally followed by an 8-octet 952 Fragment Header. 954 Since the Jumbo Payload option includes a 32-bit length field, OMNI 955 interfaces can therefore configure a larger IPv6 MTU up to a maximum 956 of ((2**32 - 1) - 8 - 40 - 8) = 4,294,967,239 octets. In that case, 957 the OAL will still provide original IP packets no larger than 65,535 958 with an IPv6 fragmentation-based assured delivery service while 959 larger IPv6 packets will receive a best-effort delivery service as 960 atomic fragments (note that the OAL destination is permitted to 961 accept atomic fragments that exceed the OMNI interface MRU). 963 The OAL source forwards jumbo atomic fragments under the assumption 964 that lower layers capable of forwarding such large packets will 965 employ sufficient integrity assurance, noting that commonly-used 966 32-bit CRCs may be inadequate for these larger sizes [CRC]. If the 967 packet is dropped along the path to the OAL destination, the OAL 968 source must arrange to return a PTB "hard error" to the original 969 source Section 6.8. 971 6. The OMNI Adaptation Layer (OAL) 973 When an OMNI interface forwards an original IP packet from the 974 network layer for transmission over one or more underlying 975 interfaces, the OMNI Adaptation Layer (OAL) acting as the OAL source 976 drops the packet and returns a PTB message if the packet is larger 977 than the MRU and also larger than the MTU of the selected underlying 978 interface. Otherwise, the OAL source applies encapsulation to form 979 OAL packets subject to fragmentation producing OAL fragments suitable 980 for *NET encapsulation and transmission as carrier packets over 981 underlying interfaces as described in Section 6.1. 983 These carrier packets travel over one or more underlying networks 984 spanned by OAL intermediate nodes in the SRT, which re-encapsulate by 985 removing the *NET headers of the first underlying network and 986 appending *NET headers appropriate for the next underlying network in 987 succession. (This process supports the multinet concatenation 988 capability needed for joining multiple diverse networks.) After re- 989 encapsulation by zero or more OAL intermediate nodes, the carrier 990 packets arrive at the OAL destination. 992 When the OAL destination receives the carrier packets, it discards 993 the *NET headers and reassembles the resulting OAL fragments (if 994 necessary) into an OAL packet as described in Section 6.3. The OAL 995 destination then decapsulates the OAL packet to obtain the original 996 IP packet, which it then delivers to the network layer. The OAL 997 source may be either the source Client or its FHS Proxy/Server, while 998 the OAL destination may be either the LHS Proxy/Server or the target 999 Client. Proxy/Servers (and other SRT infrastructure node types such 1000 as those discussed in [I-D.templin-6man-aero]) may also serve as OAL 1001 intermediate nodes. 1003 The OAL presents an OMNI sublayer abstraction similar to ATM 1004 Adaptation Layer 5 (AAL5). Unlike AAL5 which performs segmentation 1005 and reassembly with fixed-length 53 octet cells over ATM networks, 1006 however, the OAL uses IPv6 encapsulation, fragmentation and 1007 reassembly with larger variable-length cells over heterogeneous 1008 underlying networks. Detailed operations of the OAL are specified in 1009 the following sections. 1011 6.1. OAL Source Encapsulation and Fragmentation 1013 When the network layer forwards an original IP packet into the OMNI 1014 interface, the OAL source creates an "OAL packet" by prepending an 1015 IPv6 OAL encapsulation header per [RFC2473] but does not decrement 1016 the Hop Limit/TTL of the original IP packet since encapsulation 1017 occurs at a layer below IP forwarding. The OAL source copies the 1018 "Type of Service/Traffic Class" [RFC2983] and "Congestion 1019 Experienced" [RFC3168] values in the original packet's IP header into 1020 the corresponding fields in the OAL header, then sets the OAL header 1021 "Flow Label" as specified in [RFC6438]. The OAL source finally sets 1022 the OAL header IPv6 Hop Limit to a conservative value sufficient to 1023 enable loop-free forwarding over multiple concatenated OMNI link 1024 segments and sets the Payload Length to the length of the original IP 1025 packet. 1027 The OAL next selects OAL packet source and destination addresses. 1028 Client OMNI interfaces set the OAL source address to a Unique Local 1029 Address (ULA) based on the Mobile Network Prefix (MNP-ULA), while 1030 Proxy/Server OMNI interfaces set the source address to an 1031 Administrative ULA (ADM-ULA) (see: Section 9). When a Client OMNI 1032 interface does not (yet) have an MNP-ULA, it can use a Temporary ULA 1033 and/or Host Identity Tag (HIT) instead (see: Section 22) as OAL 1034 addresses. (In addition to ADM-ULAs, Proxy/Servers also process 1035 packets with anycast and/or multicast OAL addresses.) 1037 The OAL source next selects a 32-bit OAL packet Identification value 1038 as specified in Section 6.6. For original IP packets no larger than 1039 65,535 octets, the OAL then calculates a 2-octet OAL checksum using 1040 the algorithm specified in Appendix A. The OAL source calculates the 1041 checksum over the OAL packet beginning with a pseudo-header of the 1042 OAL header similar to that found in Section 8.1 of [RFC8200], then 1043 extending over the entire length of the original IP packet. The OAL 1044 pseudo-header is formed as shown in Figure 4: 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | | 1048 + + 1049 | | 1050 + OAL Source Address + 1051 | | 1052 + + 1053 | | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 + + 1057 | | 1058 + OAL Destination Address + 1059 | | 1060 + + 1061 | | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | OAL Payload Length | zero | Next Header | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Identification | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Figure 4: OAL Pseudo-Header 1070 After calculating the checksum, the OAL source next fragments the OAL 1071 packet if necessary while assuming the IPv4 minimum path MTU (i.e., 1072 576 octets) as the worst case for OAL fragmentation regardless of the 1073 underlying interface IP protocol version since IPv6/IPv4 protocol 1074 translation and/or IPv6-in-IPv4 encapsulation may occur in any *NET 1075 path. By initially assuming the IPv4 minimum even for IPv6 1076 underlying interfaces, the OAL source may produce smaller fragments 1077 with additional encapsulation overhead but will always interoperate 1078 and never run the risk of loss due to an MTU restriction or due to 1079 presenting an underlying interface with a carrier packet that exceeds 1080 its MRU. Additionally, the OAL path could traverse multiple SRT 1081 segments with intermediate OAL forwarding nodes performing re- 1082 encapsulation where the *NET encapsulation of the previous segment is 1083 replaced by the *NET encapsulation of the next segment which may be 1084 based on a different IP protocol version and/or encapsulation sizes. 1086 The OAL source therefore assumes a default minimum path MTU of 576 1087 octets at each SRT segment for the purpose of generating OAL 1088 fragments for *NET encapsulation and transmission as carrier packets. 1089 Each successive SRT intermediate node may include either a 20 octet 1090 IPv4 or 40 octet IPv6 header, an 8 octet UDP header and in some cases 1091 an IP security encapsulation (40 octets maximum assumed) during re- 1092 encapsulation. Intermediate nodes at any SRT segment may also insert 1093 or modify the Routing Header (40 octets maximum) following the 40 1094 octet OAL IPv6 header and preceding the 8 octet Fragment Header. 1095 Therefore, assuming a worst case of (40 + 40 + 8) = 88 octets for 1096 *NET encapsulation plus (40 + 40 + 8) = 88 octets for OAL 1097 encapsulation leaves no less than (576 - 88 - 88) = 400 octets 1098 remaining to accommodate a portion of the original IP packet/ 1099 fragment. The OAL source therefore sets a minimum Maximum Payload 1100 Size (MPS) of 400 octets as the basis for the minimum-sized OAL 1101 fragment that can be assured of traversing all SRT segments without 1102 loss due to an MTU/MRU restriction. The Maximum Fragment Size (MFS) 1103 for OAL fragmentation is therefore determined by the MPS plus the 1104 size of the OAL encapsulation headers. 1106 The OAL source SHOULD maintain "path MPS" values for individual OAL 1107 destinations initialized to the minimum MPS and increased to larger 1108 values if better information is known or discovered. For example, 1109 when *NET peers share a common underlying link or a fixed path with a 1110 known larger MTU, the OAL source can set path MPS to this larger size 1111 (i.e., greater than 576 octets) as long as the *NET peer reassembles 1112 before re-encapsulating and forwarding (while re-fragmenting if 1113 necessary). Also, if the OAL source has a way of knowing the maximum 1114 *NET encapsulation size for all SRT segments along the path it may be 1115 able to increase path MPS to reserve additional room for payload 1116 data. Even when OAL header compression is used, the OAL source must 1117 include the uncompressed OAL header size in its path MPS calculation 1118 since it may need to include a full header at any time. 1120 The OAL source can also optimistically set a larger path MPS and/or 1121 actively probe individual OAL destinations to discover larger sizes 1122 using packetization layer probes in a similar fashion as 1123 [RFC4821][RFC8899], but care must be taken to avoid setting static 1124 values for dynamically changing paths leading to black holes. The 1125 probe involves sending an OAL packet larger than the current path MPS 1126 and receiving a small acknowledgement response (with the possible 1127 receipt of link-layer error message when a probe is lost). For this 1128 purpose, the OAL source can send an NS message with one or more OMNI 1129 options with large PadN sub-options (see: Section 12) in order to 1130 receive a small NA response from the OAL destination. While 1131 observing the minimum MPS will always result in robust and secure 1132 behavior, the OAL source should optimize path MPS values when more 1133 efficient utilization may result in better performance (e.g. for 1134 wireless aviation data links). The OAL source should maintain 1135 separate path MPS values for each (source, target) underlying 1136 interface pair for the same OAL destination, since different 1137 underlying interface pairs may support differing path MPS values. 1139 When the OAL source performs fragmentation, it SHOULD produce the 1140 minimum number of non-overlapping fragments under current MPS 1141 constraints, where each non-final fragment MUST be at least as large 1142 as the minimum MPS, while the final fragment MAY be smaller. The OAL 1143 source also converts all original IP packets no larger than the 1144 current MPS (or larger than 65,535 octets) into atomic fragments by 1145 including a Fragment Header with Fragment Offset and More Fragments 1146 both set to 0. The OAL source then inserts a Routing Header (if 1147 necessary) following the IPv6 encapsulation header and before the 1148 Fragment Header. If the original IP packet is larger than 65,535, 1149 the OAL source also inserts a Hop-By-Hop header with Jumbo Payload 1150 option immediately following the IPv6 encapulation header and before 1151 the Routing Header (if necessary). The header extension order for 1152 each fragment therefore appears as the OAL IPv6 header followed by 1153 Hop-By-Hop header followed by Routing Header followed by Fragment 1154 Header. 1156 For packets that will include an OAL checksum, the OAL source next 1157 appends the checksum as the final two octets of the final fragment 1158 while increasing its Payload Length by 2. If appending the checksum 1159 would cause the final fragment to exceed the current MPS, the OAL 1160 source instead reduces this "former" final fragment's Payload Length 1161 (PL) by (N*8 + (PL mod 8)) octets, where N is an integer that would 1162 result in a non-zero reduction but without causing the former final 1163 fragment to become smaller than the minimum MPS. The OAL source then 1164 creates a "new" final fragment by copying the OAL IPv6 header and 1165 extension headers from the former final fragment, then copying the 1166 (N*8 + (PL mod 8)) octets from the end of the former final fragment 1167 immediately following the new final fragment extension headers. The 1168 OAL source then sets the former final fragment's More Fragments flag 1169 to 1, increments the new final fragment's fragment offset by the 1170 former final fragment's new (PL / 8) and finally appends the checksum 1171 the same as discussed above. 1173 Next, OMNI redefines the 1-octet Reserved field in the IPv6 Fragment 1174 Header as an integer "Ordinal" value in the most significant 6 bits, 1175 followed by a 1-bit "Reserved" flag followed by a 1-bit "ARQ Enabled" 1176 flag. For each fragment produced, the OAL source writes a 1177 monotonically-increasing value in the Ordinal field and sets the "ARQ 1178 Enabled" flag. Specifically, the OAL source writes the ordinal 1179 number '0' for the first fragment, '1' for the second fragment, '2' 1180 for the third fragment, etc. up to the final fragment or the ordinal 1181 value '63', whichever comes first. (For any additional fragments, 1182 the OAL source instead writes the value '0' in the Ordinal field and 1183 clears the "ARQ Enabled" flag.) 1185 The OAL source finally encapsulates the fragments in *NET headers to 1186 form carrier packets and forwards them over an underlying interface, 1187 while retaining the fragments and their ordinal numbers (i.e., #0, 1188 #1, #2, etc. up to #63) for a brief period to support link-layer 1189 retransmissions (see: Section 6.7). OAL fragment and carrier packet 1190 formats are shown in Figure 5. 1192 +----------+----------------+ 1193 |OAL Header| Frag #0 | 1194 +----------+----------------+ 1195 +----------+----------------+ 1196 |OAL Header| Frag #1 | 1197 +----------+----------------+ 1198 +----------+----------------+ 1199 |OAL Header| Frag #2 | 1200 +----------+----------------+ 1201 .... 1202 +----------+----------------+----+ 1203 |OAL Header| Frag #(N-1) |Csum| 1204 +----------+----------------+----+ 1205 a) OAL fragmentation (Csum in final fragment) 1207 +----------+-----+-----+-----+-----+-----+----+ 1208 |OAL Header| Original IP packet |Csum| 1209 +----------+-----+-----+-----+-----+-----+----+ 1210 b) An OAL atomic fragment 1212 +--------+----------+----------------+ 1213 |*NET Hdr|OAL Header| Frag #i | 1214 +--------+----------+----------------+ 1215 c) OAL carrier packet after *NET encapsulation 1217 Figure 5: OAL Fragments and Carrier Packets 1219 6.2. OAL *NET Encapsulation and Re-Encapsulation 1221 The OAL source or intermediate node encapsulates each OAL fragment 1222 (with either full or compressed headers) in *NET encapsulation 1223 headers to create a carrier packet. The OAL source or intermediate 1224 node (i.e., the *NET source) includes a UDP header as the innermost 1225 sublayer if NAT traversal and/or packet filtering middlebox traversal 1226 are required; otherwise, the *NET source includes either a full or 1227 compressed IP header or a true L2 header (e.g., such as for Ethernet- 1228 compatible links). The *NET source then appends any additional 1229 encapsulation sublayer headers necessary and presents the resulting 1230 carrier packet to an underlying interface, where the underlying 1231 network conveys it to a next-hop OAL intermediate node or destination 1232 (i.e., the *NET destination). 1234 The *NET source encapsulates the OAL information immediately 1235 following the *NET innermost sublayer header. If the first four bits 1236 of the encapsulated OAL information following the innermost sublayer 1237 header encode the value '6', the information must include an 1238 uncompressed IPv6 header followed by any IPv6 extension headers 1239 followed by upper layer protocol headers and data. Otherwise, the 1240 first four bits include a "Type" value, and the OAL information 1241 appears in an alternate format as specified in Section 6.4). 1242 Alternate formats for Types '0' and '1' are currently specified, 1243 while Type value '4' is permanently reserved and all other values are 1244 reserved for future use. Carrier packets that contain an unsupported 1245 Type value are unconditionally dropped. 1247 The OAL node prepares the innermost *NET encapsulation header for OAL 1248 packets as follows: 1250 o For UDP, the *NET source sets the UDP source port to 8060 (i.e., 1251 the port number reserved for AERO/OMNI). When the *NET 1252 destination is a Proxy/Server or Bridge, the *NET source sets the 1253 UDP destination port to 8060; otherwise, the *NET source sets the 1254 UDP destination port to its cached port number value for the peer. 1255 The *NET source finally sets the UDP Length the same as specified 1256 in [RFC0768]. 1258 o For IP encapsulation, the IP protocol number or Next Header is set 1259 to TBD1 as the Internet Protocol number for OMNI (see: IANA 1260 Considerations). For IPv4, the *NET source sets the Total Length 1261 the same as specified in [RFC0791]; for IPv6, the *NET source sets 1262 the Payload Length the same as specified in [RFC8200]. 1264 o For encapsulations over Ethernet-compatible L2s, the EtherType is 1265 set to TBD2 as the EtherType number for OMNI (see: IANA 1266 Considerations). Since the Ethernet header does not include a 1267 length field, for the OMNI EtherType the Ethernet header is 1268 followed by a two-octet length field followed immediately by the 1269 encapsulated OAL information. The length field encodes the length 1270 in octets (in network byte order) of the information following the 1271 Ethernet header including the length field, but excluding the 1272 Ethernet trailer. 1274 When a *NET source includes a UDP header, it SHOULD calculate and 1275 include a UDP checksum in carrier packets with full OAL headers to 1276 prevent mis-delivery, and MAY disable UDP checksums in carrier 1277 packets with compressed OAL headers (see: Section 6.4). If the *NET 1278 source discovers that a path is dropping carrier packets with UDP 1279 checksums disabled, it should enable UDP checksums in future carrier 1280 packets sent to the same *NET destination. If the *NET source 1281 discovers that a path is dropping carrier packets that do not include 1282 a UDP header, it should include a UDP header in future carrier 1283 packets. 1285 When a *NET source sends carrier packets with compressed OAL headers 1286 and with UDP checksums disabled, mis-delivery due to corruption of 1287 the 4-octet Multilink Forwarding Vector Index (MFVI) is possible but 1288 unlikely since the corrupted index would somehow have to match valid 1289 state in the (sparsely-populated) Multilink Forwarding Information 1290 Based (MFIB). In the unlikely event that a match occurs, an OAL 1291 destination may receive a mis-delivered carrier packet but can 1292 immediately reject packets with an incorrect Identification. If the 1293 Identification value is somehow accepted, the OAL destination may 1294 submit the mis-delivered carrier packet to the reassembly cache where 1295 it will most likely be rejected due to incorrect reassembly 1296 parameters. If a reassembly that includes the mis-delivered carrier 1297 packets somehow succeeds (or, for atomic fragments) the OAL 1298 destination will verify the OAL checksum to detect corruption. 1299 Finally, any spurious data that somehow eludes all prior checks will 1300 be detected and rejected by end-to-end upper layer integrity checks. 1301 See: [RFC6935][RFC6936] for further discussion. 1303 For *NET encapsulations over IP, when the *NET source is also the OAL 1304 source it next copies the "Type of Service/Traffic Class" [RFC2983] 1305 and "Congestion Experienced" [RFC3168] values in the OAL header into 1306 the corresponding fields in the *NET IP header, then (for IPv6) set 1307 the *NET IPv6 header "Flow Label" as specified in [RFC6438]. The 1308 *NET source then sets the *NET IP TTL/Hop Limit the same as for any 1309 host (i.e., it does not copy the Hop Limit value from the OAL header) 1310 and finally sets the source and destination IP addresses to direct 1311 the carrier packet to the next hop. For carrier packets undergoing 1312 re-encapsulation, the OAL intermediate node *NET source decrements 1313 the OAL header Hop Limit and discards the carrier packet if the value 1314 reaches 0. The *NET source then copies the "Type of Service/Traffic 1315 Class" and "Congestion Experienced" values from the previous hop *NET 1316 encapsulation header into the OAL header, then finally sets the 1317 source and destination IP addresses the same as above. 1319 Following *NET encapsulation/re-encapsulation, the *NET source sends 1320 the resulting carrier packets over one or more underlying interfaces. 1321 The underlying interfaces often connect directly to physical media on 1322 the local platform (e.g., a laptop computer with WiFi, etc.), but in 1323 some configurations the physical media may be hosted on a separate 1324 Local Area Network (LAN) node. In that case, the OMNI interface can 1325 establish a Layer-2 VLAN or a point-to-point tunnel (at a layer below 1326 the underlying interface) to the node hosting the physical media. 1327 The OMNI interface may also apply encapsulation at the underlying 1328 interface layer (e.g., as for a tunnel virtual interface) such that 1329 carrier packets would appear "double-encapsulated" on the LAN; the 1330 node hosting the physical media in turn removes the LAN encapsulation 1331 prior to transmission or inserts it following reception. Finally, 1332 the underlying interface must monitor the node hosting the physical 1333 media (e.g., through periodic keepalives) so that it can convey 1334 up/down/status information to the OMNI interface. 1336 6.3. OAL *NET Decapsulation and Reassembly 1338 When an OMNI interface receives a carrier packet from an underlying 1339 interface, it discards the *NET encapsulation headers and examines 1340 the OAL header of the enclosed OAL fragment. If the OAL fragment is 1341 addressed to a different node, the OMNI interface (acting as an OAL 1342 intermediate node) re-encapsulates and forwards as discussed in 1343 Section 6.2. If the OAL fragment is addressed to itself, the OMNI 1344 interface (acting as an OAL destination) accepts or drops the 1345 fragment based on the (Source, Destination, Identification)-tuple 1346 and/or integrity checks. 1348 The OAL destination next drops all non-final OAL fragments smaller 1349 than the minimum MPS and all fragments that would overlap or leave 1350 "holes" smaller than the minimum MPS with respect to other fragments 1351 already received. The OAL destination updates a checklist of 1352 accepted fragments of the same OAL packet that include an Ordinal 1353 number (i.e., Ordinals 0 through 63), but admits all accepted 1354 fragments into the reassembly cache after first removing any 1355 extension headers except for the fragment header itself. Except for 1356 atomic fragments that include a Jumbo Payload which do not include an 1357 OAL packet checksum, when the OAL destination receives the final 1358 fragment (i.e., the one with More Fragments set to 0), it caches the 1359 trailing checksum and reduces the Payload Length by 2. When 1360 reassembly is complete, the OAL destination verifies the OAL packet 1361 checksum and discards the packet if the checksum is incorrect. If 1362 the OAL packet was accepted, the OAL destination finally removes the 1363 OAL headers and delivers the original IP packet to the network layer. 1365 Carrier packets often travel over paths where all links in the path 1366 include CRC-32 integrity checks for effective hop-by-hop error 1367 detection for payload sizes up to 9180 octets [CRC], but other paths 1368 may traverse links (such as tunnels over IPv4) that do not include 1369 adequate integrity protection. The OAL checksum therefore allows OAL 1370 destinations to detect reassembly misassociation splicing errors and/ 1371 or carrier packet corruption caused by unprotected links [CKSUM]. 1373 The OAL checksum also provides algorithmic diversity with respect to 1374 both lower layer CRCs and upper layer Internet checksums as part of a 1375 complimentary multi-layer integrity assurance architecture. Any 1376 corruption not detected by lower layer integrity checks is therefore 1377 very likely to be detected by upper layer integrity checks that use 1378 diverse algorithms. 1380 6.4. OAL Header Compression 1382 OAL sources that send carrier packets with full OAL headers include a 1383 CRH-32 extension for segment-by-segment forwarding based on a 1384 Multilink Forwarding Information Base (MFIB) in each OAL intermediate 1385 node. OAL source, intermediate and destination nodes can instead 1386 establish header compression state through IPv6 ND NS/NA message 1387 exchanges. After an initial NS/NA exchange, OAL nodes can apply OAL 1388 Header Compression to significantly reduce encapsulation overhead. 1390 Each OAL node establishes MFIB soft state entries known as Multilink 1391 Forwarding Vectors (MVFs) which support both carrier packet 1392 forwarding and OAL header compression/decompression. For OAL 1393 sources, each MFV is referenced by a single MFV Index (MFVI) that 1394 provides compression/decompression and forwarding context for the 1395 next hop. For OAL destinations, the MFV is referenced by a single 1396 MFVI that provides context for the previous hop. For OAL 1397 intermediate nodes, the MFV is referenced by two MFVIs - one for the 1398 previous hop and one for the next hop. 1400 When an OAL node forwards carrier packets to a next hop, it can 1401 include a full OAL header with a CRH-32 extension containing one or 1402 more MVFIs. The OAL node can instead omit significant portions of 1403 the OAL header (including the CRH-32) while applying OAL header 1404 compression. The full or compressed OAL header follows immediately 1405 after the innermost *NET encapsulation (i.e., UDP, IP or L2) as 1406 discussed in Section 6.2. Two OAL compressed header types (Type '0' 1407 and Type '1') are currently specified below. 1409 For OAL first-fragments (including atomic fragments), the OAL node 1410 uses OMNI Compressed Header - Type 0 (OCH-0) as shown in Figure 6: 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 |Type=0 | Traffic Class | Flow Label | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Next Header | Hop Limit |M| Identification (0-1) | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Identification (2-3) | MFVI (0-1) | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | MFVI (2-3) | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 Figure 6: OMNI Compressed Header - Type 0 (OCH-0) 1426 The format begins with a 4-bit Type field set to 0, and is followed 1427 by the uncompressed Traffic Class and Flow Label copied from the OAL 1428 header, followed by a Next Header field set to the protocol number 1429 for the header immediately following the IPv6 Fragment Header. The 1430 Next Header field is then followed by a 7-bit compressed Hop Limit 1431 field set to the minimum of 127 and the uncompressed OAL IPv6 Hop 1432 Limit value. The Hop Limit is then followed by a compressed Fragment 1433 Header that includes only the (M)ore Fragments bit and the 4-octet 1434 Identification and with all other fields omitted. The compressed 1435 Fragment Header is then followed by a 4-octet Multilink Forwarding 1436 Vector Index (MFVI). 1438 The OAL fragment body is then included immediately following the 1439 OCH-0 header, and the *NET header length field is reduced by the 1440 difference in length between the compressed headers and full-length 1441 IPv6 and Fragment headers. The OAL destination will then be able to 1442 determine the Payload Length by examining the *NET header length 1443 field. The OCH-0 format applies for first fragments only, which are 1444 always regarded as ordinal fragment 0 even though no explicit Ordinal 1445 field is included. 1447 For OAL non-first fragments (i.e., those with non-zero Fragment 1448 Offsets), the OAL uses OMNI Compressed Header - Type 1 (OCH-1) as 1449 shown in Figure 7: 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 |Type=1 | Ordinal |M| Fragment Offset | Id(0) | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Identification (1-3) | MFVI(0) | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | MFVI (1-3) | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Figure 7: OMNI Compressed Header - Type 1 (OCH-1) 1463 The format begins with a Type field set to 1 and the IPv6 header is 1464 omitted entirely. The Type field is then followed by a compressed 1465 IPv6 Fragment Header with a 6-bit Ordinal number field, and with 1466 ((M)ore Fragments/Fragment Offset/Identification) copied from the 1467 uncompressed fragment header. The compressed Fragment Header is then 1468 followed by a 4-octet MFVI. 1470 The OAL fragment body is then included immediately following the 1471 OCH-1 header, and the *NET header length field is reduced by the 1472 difference in length between the compressed headers and full-length 1473 IPv6 and Fragment headers. The OAL destination will then be able to 1474 determine the Payload Length by examining the *NET header length 1475 field. The OCH-1 format applies for non-first fragments only; 1476 therefore, Ordinal is set to a monotonically increasing value 1477 beginning with 1 for the first non-first fragment, 2 for the second 1478 non-first fragment, etc., up to and including the final fragment. If 1479 more than 64 fragments are included, the Ordinal value for all 1480 fragments beyond the 64th is instead set to 0. 1482 When an OAL destination or intermediate node receives a carrier 1483 packet, it determines the length of the encapsulated OAL information 1484 by examining the length field of the innermost *NET header, verifies 1485 that the appropriate *NET header next header field indicates OMNI 1486 (see: Section 6.2), then examines the first four bits immediately 1487 following the *NET header. If the bits contain the value 6, the OAL 1488 node processes the remainder as an uncompressed OAL header. If the 1489 bits contain the value 0 or 1, the OAL node instead processes the 1490 remainder of the header as an OCH-0 or OCH-1, respectively. 1492 For carrier packets with OCH-0/1 or full OAL headers addressed to 1493 itself and with CRH-32 extensions, the OAL node then uses the MFVI to 1494 locate the cached MFV which determines the next hop. During 1495 forwarding, the OAL node changes the MFVI to the cached value for the 1496 MVF next hop. If the OAL node is the destination, it instead 1497 reconstructs the full OAL headers then adds the resulting OAL 1498 fragment to the reassembly cache if the Identification is acceptable. 1499 For carrier packets with OCH-1 headers that do not include Traffic 1500 Class, Flow Label, Next Header or Hop Limit information, the OAL node 1501 writes the value 0 into those fields when it reconstructs the full 1502 OAL headers. The values will be correctly populated during 1503 reassembly after an OAL first fragment with an OCH-0 or uncompressed 1504 OAL header arrives. 1506 Note: OAL header compression does not interfere with checksum 1507 calculation and verification, which must be applied according to the 1508 full OAL pseudo-header per Section 6.1 even when compression is used. 1510 Note: when OAL-in-OAL encapsulation is used, any outer OCH-0/1 1511 headers or full OAL headers with CRH-32 extensions include an MVFI, 1512 while the innermost OCH-0/1 header or full OAL header must not 1513 include an MFVI. 1515 6.5. OAL-in-OAL Encapsulation 1517 When an OAL source is unable to forward carrier packets directly to 1518 an OAL destination without "tunneling" through a pair of OAL 1519 intermediate nodes, the OAL source must regard the intermediate nodes 1520 as ingress and egress tunnel endpoints. This will result in nested 1521 OAL-in-OAL encapsulation in which the OAL source performs 1522 fragmentation on the inner OAL packet then forwards the fragments to 1523 the ingress tunnel endpoint which encapsulates each resulting OAL 1524 fragment in an additional OAL header before performing fragmentation 1525 following encapsulation. 1527 For example, if the OAL source has an NCE for the OAL destination 1528 with MFVI 0x2376a7b5 and Identification 0x12345678 and the OAL 1529 ingress tunnel endpoint has an NCE for the OAL egress tunnel endpoint 1530 with MFVI 0xacdebf12 and Identification 0x98765432, the OAL source 1531 prepares the carrier packets using compressed/uncompressed OAL 1532 headers that include the MFVI and Identification corresponding to the 1533 OAL destination and with *NET header information addressed to the 1534 next hop toward the ingress tunnel endpoint. When the ingress tunnel 1535 endpoint receives the carrier packet, it recognizes the current MFVI 1536 included by the OAL source and determines the correct next hop MFVI. 1538 The ingress tunnel endpoint then discards the *NET headers from the 1539 previous hop and encapsulates the original compressed/uncompressed 1540 OAL header within a second compressed/uncompressed OAL header while 1541 including the next-hop MVFI in the outer OAL encapsulation header and 1542 omitting the MFVI in the inner header. The ingress tunnel endpoint 1543 then includes *NET encapsulation headers with destinations 1544 appropriate for the next hop on the path to the egress tunnel 1545 endpoint. The encapsulation appears as shown in Figure 8: 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | *NET headers (previous hop) | | *NET headers (next hop) | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Original OAL/OCH Hdr | | Encapsulation OAL/OCH Hdr | 1551 | Id=0x12345678 | | Id=0x98765432 | 1552 | MFVI=0x2376a7b5 | | MFVI=0xacdebf12 | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | | | Original OAL/OCH Hdr | 1555 | | | Id=0x12345678 | 1556 | Carrier packet data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | | | | 1558 | | | | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Carrier packet data | 1560 | Original OAL Checksum | | | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1562 Original Carrier packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 from OAL source | Original OAL Checksum | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | Encapsulation OAL Checksum | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 Carrier packet following OAL ingress 1569 (re)encapsulation before fragmentation 1571 Figure 8: Carrier Packet in Carrier Packet Encapsulation 1573 Note that only a single OAL-in-OAL encapsulation layer is supported, 1574 and that MFVIs appear only in the outer OAL header (i.e., either 1575 within a CRH-32 routing header when a full OAL header is used or 1576 within an OCH-0/1 header). The inner OAL/OCH header should omit the 1577 CRH-32 header or set I to 0, respectively. 1579 Note that OAL/OCH encapsulation may cause the payloads of OAL packets 1580 produced by the ingress tunnel endpoint to exceed the minimum MPS by 1581 a small amount. If the ingress has assurance that the path to the 1582 egress will include only links capable of transiting the resulting 1583 (slightly larger) carrier packets it should forward without further 1584 fragmentation. Otherwise, the ingress must perform fragmentation 1585 following encapsulation to produce two fragments such that the size 1586 of the first fragment matches the size of the original OAL packet, 1587 and with the remainder in a second fragment. The egress tunnel 1588 endpoint must then reassemble then decapsulate to arrive at the 1589 original OAL packet which is then subject to further forwarding. 1591 6.6. OAL Identification Window Maintenance 1593 The OAL encapsulates each original IP packet as an OAL packet then 1594 performs fragmentation to produce one or more carrier packets with 1595 the same 32-bit Identification value. In environments where spoofing 1596 is not considered a threat, OMNI interfaces send OAL packets with 1597 Identifications beginning with an unpredictable Initial Send Sequence 1598 (ISS) value [RFC7739] monotonically incremented (modulo 2**32) for 1599 each successive OAL packet sent to either a specific neighbor or to 1600 any neighbor. (The OMNI interface may later change to a new 1601 unpredictable ISS value as long as the Identifications are assured 1602 unique within a timeframe that would prevent the fragments of a first 1603 OAL packet from becoming associated with the reassembly of a second 1604 OAL packet.) In other environments, OMNI interfaces should maintain 1605 explicit per-neighbor send and receive windows to detect and exclude 1606 spurious carrier packets that might clutter the reassembly cache as 1607 discussed below. 1609 OMNI interface neighbors use TCP-like synchronization to maintain 1610 windows with unpredictable ISS values incremented (modulo 2**32) for 1611 each successive OAL packet and re-negotiate windows often enough to 1612 maintain an unpredictable profile. OMNI interface neighbors exchange 1613 IPv6 ND messages with OMNI options that include TCP-like information 1614 fields to manage streams of OAL packets instead of streams of octets. 1615 As a link-layer service, the OAL provides low-persistence best-effort 1616 retransmission with no mitigations for duplication, reordering or 1617 deterministic delivery. Since the service model is best-effort and 1618 only control message sequence numbers are acknowledged, OAL nodes can 1619 select unpredictable new initial sequence numbers outside of the 1620 current window without delaying for the Maximum Segment Lifetime 1621 (MSL). 1623 OMNI interface neighbors maintain current and previous window state 1624 in IPv6 ND neighbor cache entries (NCEs) to support dynamic rollover 1625 to a new window while still sending OAL packets and accepting carrier 1626 packets from the previous windows. Each NCE is indexed by the 1627 neighbor's LLA, which must also match the ULA used for OAL 1628 encapsulation. OMNI interface neighbors synchronize windows through 1629 asymmetric and/or symmetric IPv6 ND message exchanges. When a node 1630 receives an IPv6 ND message with new window information, it resets 1631 the previous window state based on the current window then resets the 1632 current window based on new and/or pending information. 1634 The IPv6 ND message OMNI option header extension sub-option includes 1635 TCP-like information fields including Sequence Number, 1636 Acknowledgement Number, Window and flags (see: Section 12). OMNI 1637 interface neighbors maintain the following TCP-like state variables 1638 in the NCE: 1640 Send Sequence Variables (current, previous and pending) 1642 SND.NXT - send next 1643 SND.WND - send window 1644 ISS - initial send sequence number 1646 Receive Sequence Variables (current and previous) 1648 RCV.NXT - receive next 1649 RCV.WND - receive window 1650 IRS - initial receive sequence number 1652 OMNI interface neighbors "OAL A" and "OAL B" exchange IPv6 ND 1653 messages per [RFC4861] with OMNI options that include TCP-like 1654 information fields. When OAL A synchronizes with OAL B, it maintains 1655 both a current and previous SND.WND beginning with a new 1656 unpredictable ISS and monotonically increments SND.NXT for each 1657 successive OAL packet transmission. OAL A initiates synchronization 1658 by including the new ISS in the Sequence Number of an authentic IPv6 1659 ND message with the SYN flag set and with Window set to M (up to 1660 2**24) as a tentative receive window size while creating a NCE in the 1661 INCOMPLETE state if necessary. OAL A caches the new ISS as pending, 1662 uses the new ISS as the Identification for OAL encapsulation, then 1663 sends the resulting OAL packet to OAL B and waits up to RetransTimer 1664 milliseconds to receive an IPv6 ND message response with the ACK flag 1665 set (retransmitting up to MAX_UNICAST_SOLICIT times if necessary). 1667 When OAL B receives the SYN, it creates a NCE in the STALE state if 1668 necessary, resets its RCV variables, caches the tentative (send) 1669 window size M, and selects a (receive) window size N (up to 2**24) to 1670 indicate the number of OAL packets it is willing to accept under the 1671 current RCV.WND. (The RCV.WND should be large enough to minimize 1672 control message overhead yet small enough to provide an effective 1673 filter for spurious carrier packets.) OAL B then prepares an IPv6 ND 1674 message with the ACK flag set, with the Acknowledgement Number set to 1675 OAL A's next sequence number, and with Window set to N. Since OAL B 1676 does not assert an ISS of its own, it uses the IRS it has cached for 1677 OAL A as the Identification for OAL encapsulation then sends the ACK 1678 to OAL A. 1680 When OAL A receives the ACK, it notes that the Identification in the 1681 OAL header matches its pending ISS. OAL A then sets the NCE state to 1682 REACHABLE and resets its SND variables based on the Window size and 1683 Acknowledgement Number (which must include the sequence number 1684 following the pending ISS). OAL A can then begin sending OAL packets 1685 to OAL B with Identification values within the (new) current SND.WND 1686 for up to ReachableTime milliseconds or until the NCE is updated by a 1687 new IPv6 ND message exchange. This implies that OAL A must send a 1688 new SYN before sending more than N OAL packets within the current 1689 SND.WND, i.e., even if ReachableTime is not nearing expiration. 1690 After OAL B returns the ACK, it accepts carrier packets received from 1691 OAL A within either the current or previous RCV.WND as well as any 1692 new authentic NS/RS SYN messages received from OAL A even if outside 1693 the windows. 1695 OMNI interface neighbors can employ asymmetric window synchronization 1696 as described above using two independent (SYN -> ACK) exchanges 1697 (i.e., a four-message exchange), or they can employ symmetric window 1698 synchronization using a modified version of the TCP three-way 1699 handshake as follows: 1701 o OAL A prepares a SYN with an unpredictable ISS not within the 1702 current SND.WND and with Window set to M as a tentative receive 1703 window size. OAL A caches the new ISS and Window size as pending 1704 information, uses the pending ISS as the Identification for OAL 1705 encapsulation, then sends the resulting OAL packet to OAL B and 1706 waits up to RetransTimer milliseconds to receive an ACK response 1707 (retransmitting up to MAX_UNICAST_SOLICIT times if necessary). 1709 o OAL B receives the SYN, then resets its RCV variables based on the 1710 Sequence Number while caching OAL A's tentative receive Window 1711 size M and a new unpredictable ISS outside of its current window 1712 as pending information. OAL B then prepares a response with 1713 Sequence Number set to the pending ISS and Acknowledgement Number 1714 set to OAL A's next sequence number. OAL B then sets both the SYN 1715 and ACK flags, sets Window to N and sets the OPT flag according to 1716 whether an explicit concluding ACK is optional or mandatory. OAL 1717 B then uses the pending ISS as the Identification for OAL 1718 encapsulation, sends the resulting OAL packet to OAL A and waits 1719 up to RetransTimer milliseconds to receive an acknowledgement 1720 (retransmitting up to MAX_UNICAST_SOLICIT times if necessary). 1722 o OAL A receives the SYN/ACK, then resets its SND variables based on 1723 the Acknowledgement Number (which must include the sequence number 1724 following the pending ISS) and OAL B's advertised Window N. OAL A 1725 then resets its RCV variables based on the Sequence Number and 1726 marks the NCE as REACHABLE. If the OPT flag is clear, OAL A next 1727 prepares an immediate solicited NA message with the ACK flag set, 1728 the Acknowledgement Number set to OAL B's next sequence number, 1729 with Window set a value that may be the same as or different than 1730 M, and with the OAL encapsulation Identification to SND.NXT, then 1731 sends the resulting OAL packet to OAL B. If the OPT flag is set 1732 and OAL A has OAL packets queued to send to OAL B, it can 1733 optionally begin sending their carrier packets under the (new) 1734 current SND.WND as implicit acknowledgements instead of returning 1735 an explicit ACK. In that case, the tentative Window size M 1736 becomes the current receive window size. 1738 o OAL B receives the implicit/explicit acknowledgement(s) then 1739 resets its SND state based on the pending/advertised values and 1740 marks the NCE as REACHABLE. If OAL B receives an explicit 1741 acknowledgement, it uses the advertised Window size and abandons 1742 the tentative size. (Note that OAL B sets the OPT flag in the 1743 SYN/ACK to assert that it will interpret timely receipt of carrier 1744 packets within the (new) current window as an implicit 1745 acknowledgement. Potential benefits include reduced delays and 1746 control message overhead, but use case analysis is outside the 1747 scope of this specification.) 1749 Following synchronization, OAL A and OAL B hold updated NCEs and can 1750 exchange OAL packets with Identifications set to SND.NXT while the 1751 state remains REACHABLE and there is available window capacity. 1752 Either neighbor may at any time send a new SYN to assert a new ISS. 1753 For example, if OAL A's current SND.WND for OAL B is nearing 1754 exhaustion and/or ReachableTime is nearing expiration, OAL A 1755 continues to send OAL packets under the current SND.WND while also 1756 sending a SYN with a new unpredictable ISS. When OAL B receives the 1757 SYN, it resets its RCV variables and may optionally return either an 1758 asymmetric ACK or a symmetric SYN/ACK to also assert a new ISS. 1759 While sending SYNs, both neighbors continue to send OAL packets with 1760 Identifications set to the current SND.NXT then reset the SND 1761 variables after an acknowledgement is received. 1763 While the optimal symmetric exchange is efficient, anomalous 1764 conditions such as receipt of old duplicate SYNs can cause confusion 1765 for the algorithm as discussed in Section 3.4 of [RFC0793]. For this 1766 reason, the OMNI option header includes an RST flag which OAL nodes 1767 set in solicited NA responses to ACKs received with incorrect 1768 acknowledgement numbers. The RST procedures (and subsequent 1769 synchronization recovery) are conducted exactly as specified in 1770 [RFC0793]. 1772 OMNI interfaces may set the PNG ("ping") flag when a reachability 1773 confirmation outside the context of the IPv6 ND protocol is needed 1774 (OMNI interfaces therefore most often set the PNG flag in 1775 advertisement messages and ignore it in solicitation messages). When 1776 an OMNI interface receives a PNG, it returns an unsolicited NA (uNA) 1777 ACK with the PNG message Identification in the Acknowledgment, but 1778 without updating RCV state variables. OMNI interfaces return unicast 1779 uNA ACKs even for multicast PNG destination addresses, since OMNI 1780 link multicast is based on unicast emulation. 1782 OMNI interfaces that employ the window synchronization procedures 1783 described above observe the following requirements: 1785 o OMNI interfaces MUST select new unpredictable ISS values that are 1786 at least a full window outside of the current SND.WND. 1788 o OMNI interfaces MUST set the initial SYN message Window field to a 1789 tentative value to be used only if no concluding NA ACK is sent. 1791 o OMNI interfaces that receive advertisements with the PNG and/or 1792 SYN flag set MUST NOT set the PNG and/or SYN flag in uNA 1793 responses. 1795 o OMNI interfaces that send advertisements with the PNG and/or SYN 1796 flag set MUST ignore uNA responses with the PNG and/or SYN flag 1797 set. 1799 o OMNI interfaces MUST send IPv6 ND messages used for window 1800 synchronization securely while using unpredictable initial 1801 Identification values until synchronization is complete. 1803 Note: Although OMNI interfaces employ TCP-like window synchronization 1804 and support uNA ACK responses to SYNs and PNGs, all other aspects of 1805 the IPv6 ND protocol (e.g., control message exchanges, NCE state 1806 management, timers, retransmission limits, etc.) are honored exactly 1807 per [RFC4861]. 1809 Note: Recipients of OAL-encapsulated IPv6 ND messages index the NCE 1810 based on the ULA source address, which also determines the carrier 1811 packet Identification window. However, IPv6 ND messages may contain 1812 an LLA source address that does not match the ULA source address when 1813 the recipient acts as a proxy. 1815 Note: OMNI interface neighbors apply the same send and receive 1816 windows for all of their (multilink) underlying interface pairs that 1817 exchange carrier packets. Each interface pair represents a distinct 1818 underlying network path, and the set of paths traversed may be highly 1819 diverse when multiple interface pairs are used. OMNI intermediate 1820 nodes therefore SHOULD NOT cache window synchronization parameters in 1821 IPv6 ND messages they forward since there is no way to ensure 1822 network-wide middlebox state consistency. 1824 6.7. OAL Fragment Retransmission 1826 When the OAL source sends carrier packets to an OAL destination, it 1827 should cache recently sent packets in case timely best-effort 1828 selective retransmission is requested. The OAL destination in turn 1829 maintains a checklist for the (Source, Destination, Identification)- 1830 tuple of recently received carrier packets and notes the ordinal 1831 numbers of OAL packet fragments already received (i.e., as Frag #0, 1832 Frag #1, Frag #2, etc.). The timeframe for maintaining the OAL 1833 source and destination caches determines the link persistence (see: 1834 [RFC3366]). 1836 If the OAL destination notices some fragments missing after most 1837 other fragments within the same link persistence timeframe have 1838 already arrived, it may issue an Automatic Repeat Request (ARQ) with 1839 Selective Repeat (SR) by sending a uNA message to the OAL source. 1840 The OAL destination creates a uNA message with an OMNI option with 1841 one or more Fragmentation Report (FRAGREP) sub-options that include a 1842 list of (Identification, Bitmap)-tuples for fragments received and 1843 missing from this OAL source (see: Section 12). The OAL destination 1844 includes an authentication signature if necessary, performs OAL 1845 encapsulation (with the its own address as the OAL source and the 1846 source address of the message that prompted the uNA as the OAL 1847 destination) and sends the message to the OAL source. 1849 When the OAL source receives the uNA message, it authenticates the 1850 message then examines the FRAGREP. For each (Source, Destination, 1851 Identification)-tuple, the OAL source determines whether it still 1852 holds the corresponding carrier packets in its cache and retransmits 1853 any for which the Bitmap indicates a loss event. For example, if the 1854 Bitmap indicates that ordinal fragments #3, #7, #10 and #13 from the 1855 OAL packet with Identification 0x12345678 are missing the OAL source 1856 only retransmits carrier packets containing those fragments. When 1857 the OAL destination receives the retransmitted carrier packets, it 1858 admits the enclosed fragments into the reassembly cache and updates 1859 its checklist. If some fragments are still missing, the OAL 1860 destination may send a small number of additional uNA ARQ/SRs within 1861 the link persistence timeframe. 1863 The OAL therefore provides a link-layer low-to-medium persistence 1864 ARQ/SR service consistent with [RFC3366] and Section 8.1 of 1865 [RFC3819]. The service provides the benefit of timely best-effort 1866 link-layer retransmissions which may reduce packet loss and avoid 1867 some unnecessary end-to-end delays. This best-effort network-based 1868 service therefore compliments higher layer end-to-end protocols 1869 responsible for true reliability. 1871 6.8. OAL MTU Feedback Messaging 1873 When the OMNI interface forwards original IP packets from the network 1874 layer, it invokes the OAL and returns internally-generated ICMPv4 1875 Fragmentation Needed [RFC1191] or ICMPv6 Path MTU Discovery (PMTUD) 1876 Packet Too Big (PTB) [RFC8201] messages as necessary. This document 1877 refers to both of these ICMPv4/ICMPv6 message types simply as "PTBs", 1878 and introduces a distinction between PTB "hard" and "soft" errors as 1879 discussed below. 1881 Ordinary PTB messages with ICMPv4 header "unused" field or ICMPv6 1882 header Code field value 0 are hard errors that always indicate that a 1883 packet has been dropped due to a real MTU restriction. However, the 1884 OMNI interface can also forward large original IP packets via OAL 1885 encapsulation and fragmentation while at the same time returning PTB 1886 soft error messages (subject to rate limiting) if it deems the 1887 original IP packet too large according to factors such as link 1888 performance characteristics, number of fragments needed, reassembly 1889 congestion, etc. This ensures that the path MTU is adaptive and 1890 reflects the current path used for a given data flow. The OMNI 1891 interface can therefore continuously forward packets without loss 1892 while returning PTB soft error messages recommending a smaller size 1893 if necessary. Original sources that receive the soft errors in turn 1894 reduce the size of the packets they send (i.e., the same as for hard 1895 errors), but can soon resume sending larger packets if the soft 1896 errors subside. 1898 An OAL source sends PTB soft error messages by setting the ICMPv4 1899 header "unused" field or ICMPv6 header Code field to the value 1 if 1900 the packet was forwarded or 2 if the packet was dropped. The OAL 1901 source sets the PTB destination address to the original IP packet 1902 source, and sets the source address to one of its OMNI interface 1903 addresses that is routable from the perspective of the original 1904 source. The OAL source then sets the MTU field to a value smaller 1905 than the original packet size but no smaller than 576 for ICMPv4 or 1906 1280 for ICMPv6, writes the leading portion of the original IP packet 1907 first fragment into the "packet in error" field, and returns the PTB 1908 soft error to the original source. When the original source receives 1909 the PTB soft error, it temporarily reduces the size of the packets it 1910 sends the same as for hard errors but may seek to increase future 1911 packet sizes dynamically while no further soft errors are arriving. 1912 (If the original source does not recognize the soft error code, it 1913 regards the PTB the same as a hard error but should heed the 1914 retransmission advice given in [RFC8201] suggesting retransmission 1915 based on normal packetization layer retransmission timers.) 1917 An OAL destination may experience reassembly cache congestion, and 1918 can return uNA messages to the OAL source that originated the 1919 fragments (subject to rate limiting) that include OMNI encapsulated 1920 PTB messages with code 1 or 2. The OAL destination creates a uNA 1921 message with an OMNI option containing an authentication message sub- 1922 option if necessary followed optionally by a ICMPv6 Error sub-option 1923 that encodes a PTB message with a reduced value and with the leading 1924 portion an OAL first fragment containing the header of an original IP 1925 packet whose source must be notified (see: Section 12). The OAL 1926 destination encapsulates the leading portion of the OAL first 1927 fragment (beginning with the OAL header) in the PTB "packet in error" 1928 field, signs the message if an authentication sub-option is included, 1929 performs OAL encapsulation (with the its own address as the OAL 1930 source and the source address of the message that prompted the uNA as 1931 the OAL destination) and sends the message to the OAL source. 1933 When the OAL source receives the uNA message, it sends a 1934 corresponding network layer PTB soft error to the original source to 1935 recommend a smaller size. The OAL source crafts the PTB by 1936 extracting the leading portion of the original IP packet from the 1937 OMNI encapsulated PTB message (i.e., not including the OAL header) 1938 and writes it in the "packet in error" field of a network layer PTB 1939 with destination set to the original IP packet source and source set 1940 to one of its OMNI interface addresses that is routable from the 1941 perspective of the original source. 1943 Original sources that receive PTB soft errors can dynamically tune 1944 the size of the original IP packets they to send to produce the best 1945 possible throughput and latency, with the understanding that these 1946 parameters may change over time due to factors such as congestion, 1947 mobility, network path changes, etc. The receipt or absence of soft 1948 errors should be seen as hints of when increasing or decreasing 1949 packet sizes may be beneficial. The OMNI interface supports 1950 continuous transmission and reception of packets of various sizes in 1951 the face of dynamically changing network conditions. Moreover, since 1952 PTB soft errors do not indicate a hard limit, original sources that 1953 receive soft errors can begin sending larger packets without waiting 1954 for the recommended 10 minutes specified for PTB hard errors 1955 [RFC1191][RFC8201]. The OMNI interface therefore provides an 1956 adaptive service that accommodates MTU diversity especially well- 1957 suited for dynamic multilink environments. 1959 6.9. OAL Requirements 1961 In light of the above, OAL sources, destinations and intermediate 1962 nodes observe the following normative requirements: 1964 o OAL sources MUST forward original IP packets either larger than 1965 the OMNI interface MRU or smaller than the minimum MPS minus the 1966 trailing checksum size as atomic fragments (i.e., and not as 1967 multiple fragments). 1969 o OAL sources MUST produce non-final fragments with payloads no 1970 smaller than the minimum MPS during fragmentation. 1972 o OAL intermediate nodes SHOULD and OAL destinations MUST 1973 unconditionally drop any non-final OAL fragments with payloads 1974 smaller than the minimum MPS. 1976 o OAL destinations MUST drop any new OAL fragments with offset and 1977 length that would overlap with other fragments and/or leave holes 1978 smaller than the minimum MPS between fragments that have already 1979 been received. 1981 Note: Under the minimum MPS, ordinary 1500 octet original IP packets 1982 would require at most 4 OAL fragments, with each non-final fragment 1983 containing 400 payload octets and the final fragment containing 302 1984 payload octets (i.e., the final 300 octets of the original IP packet 1985 plus the 2 octet trailing checksum). For all packet sizes, the 1986 likelihood of successful reassembly may improve when the OMNI 1987 interface sends all fragments of the same fragmented OAL packet 1988 consecutively over the same underlying interface pair instead of 1989 spread across multiple underlying interface pairs. Finally, an 1990 assured minimum/path MPS allows continuous operation over all paths 1991 including those that traverse bridged L2 media with dissimilar MTUs. 1993 Note: Certain legacy network hardware of the past millennium was 1994 unable to accept packet "bursts" resulting from an IP fragmentation 1995 event - even to the point that the hardware would reset itself when 1996 presented with a burst. This does not seem to be a common problem in 1997 the modern era, where fragmentation and reassembly can be readily 1998 demonstrated at line rate (e.g., using tools such as 'iperf3') even 1999 over fast links on ordinary hardware platforms. Even so, while the 2000 OAL destination is reporting reassembly congestion (see: Section 6.8) 2001 the OAL source could impose an inter-fragment delay and decrease the 2002 delay when reassembly congestion subsides. 2004 6.10. OAL Fragmentation Security Implications 2006 As discussed in Section 3.7 of [RFC8900], there are four basic 2007 threats concerning IPv6 fragmentation; each of which is addressed by 2008 effective mitigations as follows: 2010 1. Overlapping fragment attacks - reassembly of overlapping 2011 fragments is forbidden by [RFC8200]; therefore, this threat does 2012 not apply to the OAL. 2014 2. Resource exhaustion attacks - this threat is mitigated by 2015 providing a sufficiently large OAL reassembly cache and 2016 instituting "fast discard" of incomplete reassemblies that may be 2017 part of a buffer exhaustion attack. The reassembly cache should 2018 be sufficiently large so that a sustained attack does not cause 2019 excessive loss of good reassemblies but not so large that (timer- 2020 based) data structure management becomes computationally 2021 expensive. The cache should also be indexed based on the arrival 2022 underlying interface such that congestion experienced over a 2023 first underlying interface does not cause discard of incomplete 2024 reassemblies for uncongested underlying interfaces. 2026 3. Attacks based on predictable fragment identification values - in 2027 environments where spoofing is possible, this threat is mitigated 2028 through the use of Identification windows beginning with 2029 unpredictable values per Section 6.6. By maintaining windows of 2030 acceptable Identifications, OAL neighbors can quickly discard 2031 spurious carrier packets that might otherwise clutter the 2032 reassembly cache. The OAL additionally provides an integrity 2033 check to detect corruption that may be caused by spurious 2034 fragments received with in-window Identification values. 2036 4. Evasion of Network Intrusion Detection Systems (NIDS) - since the 2037 OAL source employs a robust MPS, network-based firewalls can 2038 inspect and drop OAL fragments containing malicious data thereby 2039 disabling reassembly by the OAL destination. However, since OAL 2040 fragments may take different paths through the network (some of 2041 which may not employ a firewall) each OAL destination must also 2042 employ a firewall. 2044 IPv4 includes a 16-bit Identification (IP ID) field with only 65535 2045 unique values such that at high data rates the field could wrap and 2046 apply to new carrier packets while the fragments of old packets using 2047 the same IP ID are still alive in the network [RFC4963]. Since 2048 carrier packets sent via an IPv4 path with DF=0 are normally no 2049 larger than 576 octets, IPv4 fragmentation is possible only at small- 2050 MTU links in the path which should support data rates low enough for 2051 safe reassembly [RFC3819]. (IPv4 carrier packets larger than 576 2052 octets with DF=0 may incur high data rate reassembly errors in the 2053 path, but the OAL checksum provides OAL destination integrity 2054 assurance.) Since IPv6 provides a 32-bit Identification value, IP ID 2055 wraparound at high data rates is not a concern for IPv6 2056 fragmentation. 2058 Fragmentation security concerns for large IPv6 ND messages are 2059 documented in [RFC6980]. These concerns are addressed when the OMNI 2060 interface employs the OAL instead of directly fragmenting the IPv6 ND 2061 message itself. For this reason, OMNI interfaces MUST NOT send IPv6 2062 ND messages larger than the OMNI interface MTU, and MUST employ OAL 2063 encapsulation and fragmentation for IPv6 ND messages larger than the 2064 minimum/path MPS for this OAL destination. 2066 Unless the path is secured at the network-layer or below (i.e., in 2067 environments where spoofing is possible), OMNI interfaces MUST NOT 2068 send ordinary carrier packets with Identification values outside the 2069 current window and MUST secure IPv6 ND messages used for address 2070 resolution or window state synchronization. OAL destinations SHOULD 2071 therefore discard without reassembling any out-of-window OAL 2072 fragments received over an unsecured path. 2074 6.11. OAL Super-Packets 2076 By default, the OAL source includes a 40-octet IPv6 encapsulation 2077 header for each original IP packet during OAL encapsulation. The OAL 2078 source also calculates then performs fragmentation such that a copy 2079 of the 40-octet IPv6 header plus an 8-octet IPv6 Fragment Header is 2080 included in each OAL fragment (when a Routing Header is added, the 2081 OAL encapsulation headers become larger still). However, these 2082 encapsulations may represent excessive overhead in some environments. 2083 OAL header compression can dramatically reduce the amount of 2084 encapsulation overhead, however a complimentary technique known as 2085 "packing" (see: [I-D.ietf-intarea-tunnels]) supports encapsulation of 2086 multiple original IP packets and/or control messages within a single 2087 OAL "super-packet". 2089 When the OAL source has multiple original IP packets to send to the 2090 same OAL destination with total length no larger than the OAL 2091 destination MRU, it can concatenate them into a super-packet 2092 encapsulated in a single OAL header. Within the OAL super-packet, 2093 the IP header of the first original IP packet (iHa) followed by its 2094 data (iDa) is concatenated immediately following the OAL header, then 2095 the IP header of the next original packet (iHb) followed by its data 2096 (iDb) is concatenated immediately following the first original 2097 packet, etc. with a trailing checksum field included in the final 2098 fragment. The OAL super-packet format is transposed from 2099 [I-D.ietf-intarea-tunnels] and shown in Figure 9: 2101 <------- Original IP packets -------> 2102 +-----+-----+ 2103 | iHa | iDa | 2104 +-----+-----+ 2105 | 2106 | +-----+-----+ 2107 | | iHb | iDb | 2108 | +-----+-----+ 2109 | | 2110 | | +-----+-----+ 2111 | | | iHc | iDc | 2112 | | +-----+-----+ 2113 | | | 2114 v v v 2115 +----------+-----+-----+-----+-----+-----+-----+----+ 2116 | OAL Hdr | iHa | iDa | iHb | iDb | iHc | iDc |Csum| 2117 +----------+-----+-----+-----+-----+-----+-----+----+ 2118 <--- OAL "Super-Packet" with single OAL Hdr/Csum ---> 2120 Figure 9: OAL Super-Packet Format 2122 When the OAL source prepares a super-packet, it applies OAL 2123 fragmentation, includes a trailing checksum in the final fragment, 2124 applies *NET encapsulation to each fragment then sends the resulting 2125 carrier packets to the OAL destination. When the OAL destination 2126 receives the super-packet it sets aside the trailing checksum, 2127 reassembles if necessary, then verifies the checksum while regarding 2128 the remaining OAL header Payload Length as the sum of the lengths of 2129 all payload packets. The OAL destination then selectively extracts 2130 each original IP packet (e.g., by setting pointers into the super- 2131 packet buffer and maintaining a reference count, by copying each 2132 packet into a separate buffer, etc.) and forwards each packet to the 2133 network layer. During extraction, the OAL determines the IP protocol 2134 version of each successive original IP packet 'j' by examining the 2135 four most-significant bits of iH(j), and determines the length of the 2136 packet by examining the rest of iH(j) according to the IP protocol 2137 version. 2139 When an OAL source prepares a super-packet that includes an IPv6 ND 2140 message with an authentication signature or ICMPv6 message checksum 2141 as the first original IP packet (i.e., iHa/iDa), it calculates the 2142 authentication signature or checksum over the remainder of super- 2143 packet. Security and integrity for forwarding initial protocol data 2144 packets in conjunction with IPv6 ND messages used to establish NCE 2145 state are therefore supported. 2147 6.12. OAL Bubbles 2149 OAL sources may send NULL OAL packets known as "bubbles" for the 2150 purpose of establishing Network Address Translator (NAT) state on the 2151 path to the OAL destination. The OAL source prepares a bubble by 2152 crafting an OAL header with appropriate IPv6 source and destination 2153 ULAs, with the IPv6 Next Header field set to the value 59 ("No Next 2154 Header" - see [RFC8200]) and with only the trailing OAL Checksum 2155 field (i.e., and no protocol data) immediately following the IPv6 2156 header. 2158 The OAL source includes a random Identification value then 2159 encapsulates the OAL packet in *NET headers destined to either the 2160 mapped address of the OAL destination's first-hop ingress NAT or the 2161 INADDR of the OAL destination itself. When the OAL source sends the 2162 resulting carrier packet, any egress NATs in the path toward the *NET 2163 destination will establish state based on the activity but the bubble 2164 will be harmlessly discarded by either an ingress NAT on the path to 2165 the OAL destination or by the OAL destination itself. 2167 The bubble concept for establishing NAT state originated in [RFC4380] 2168 and was later updated by [RFC6081]. OAL bubbles may be employed by 2169 mobility services such as [I-D.templin-6man-aero]. 2171 7. Frame Format 2173 When the OMNI interface forwards original IP packets from the network 2174 layer it first invokes the OAL to create OAL packets/fragments if 2175 necessary, then includes any *NET encapsulations and finally engages 2176 the native frame format of the underlying interface. For example, 2177 for Ethernet-compatible interfaces the frame format is specified in 2178 [RFC2464], for aeronautical radio interfaces the frame format is 2179 specified in standards such as ICAO Doc 9776 (VDL Mode 2 Technical 2180 Manual), for various forms of tunnels the frame format is found in 2181 the appropriate tunneling specification, etc. 2183 See Figure 2 for a map of the various *NET layering combinations 2184 possible. For any layering combination, the final layer (e.g., UDP, 2185 IP, Ethernet, etc.) must have an assigned number and frame format 2186 representation that is compatible with the selected underlying 2187 interface. 2189 8. Link-Local Addresses (LLAs) 2191 OMNI interfaces assign IPv6 Link-Local Addresses (LLAs) through pre- 2192 service administrative actions. Clients assign "MNP-LLAs" with 2193 interface identifiers that embed the Client's unique MNP, while 2194 Proxy/Servers assign "ADM-LLAs" that include an administrative ID 2195 guaranteed to be unique on the link. LLAs are configured as follows: 2197 o IPv6 MNP-LLAs encode the most-significant 64 bits of an MNP within 2198 the least-significant 64 bits of the IPv6 link-local prefix 2199 fe80::/64, i.e., in the LLA "interface identifier" portion. The 2200 prefix length for the LLA is determined by adding 64 to the MNP 2201 prefix length. For example, for the MNP 2001:db8:1000:2000::/56 2202 the corresponding MNP-LLA prefix is fe80::2001:db8:1000:2000/120. 2203 (The base MNP-LLA for each "/N" prefix sets the final 128-N bits 2204 to 0, but all MNP-LLAs that match the prefix are also accepted.) 2205 Non-MNP routes are also represented the same as for MNP-LLAs, but 2206 include a GUA prefix that is not properly covered by the MSP. 2208 o IPv4-mapped MNP-LLAs are constructed as fe80::ffff:[IPv4], i.e., 2209 the interface identifier consists of 16 '0' bits, followed by 16 2210 '1' bits, followed by a 32bit IPv4 address/prefix. The prefix 2211 length for the LLA is determined by adding 96 to the MNP prefix 2212 length. For example, the IPv4-mapped MNP-LLA for 192.0.2.0/24 is 2213 fe80::ffff:192.0.2.0/120, also written as 2214 fe80::ffff:c000:0200/120. (The base MNP-LLA for each "/N" prefix 2215 sets the final 128-N bits to 0, but all MNP-LLAs that match the 2216 prefix are also accepted.) 2218 o ADM-LLAs are assigned to Proxy/Servers (and possibly other SRT 2219 infrastructure elements) and MUST be managed for uniqueness. The 2220 upper 96 bits of the LLA encode the prefix fe80::/96, and the 2221 lower 32 bits include a unique integer "MSID" value between 2222 0x00000001 and 0xfeffffff, e.g., as in fe80::1, fe80::2, fe80::3, 2223 etc., fe80::feffffff. The ADM-LLA prefix length is determined by 2224 adding 96 to the MSID prefix length. For example, if the prefix 2225 length for MSID 0x10012001 is 16 then the ADM-LLA prefix length is 2226 set to 112 and the LLA is written as fe80::1001:2001/112. The 2227 "zero" address for each ADM-LLA prefix is the Subnet-Router 2228 anycast address for that prefix [RFC4291]; for example, the 2229 Subnet-Router anycast address for fe80::1001:2001/112 is simply 2230 fe80::1001:2000. The MSID range 0xff000000 through 0xffffffff is 2231 reserved for future use. 2233 Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 2234 MNPs can be allocated from that block ensuring that there is no 2235 possibility for overlap between the different MNP- and ADM-LLA 2236 constructs discussed above. 2238 Since MNP-LLAs are based on the distribution of administratively 2239 assured unique MNPs, and since ADM-LLAs are guaranteed unique through 2240 administrative assignment, OMNI interfaces set the autoconfiguration 2241 variable DupAddrDetectTransmits to 0 [RFC4862]. 2243 Note: If future protocol extensions relax the 64-bit boundary in IPv6 2244 addressing, the additional prefix bits of an MNP could be encoded in 2245 bits 16 through 63 of the MNP-LLA. (The most-significant 64 bits 2246 would therefore still be in bits 64-127, and the remaining bits would 2247 appear in bits 16 through 48.) However, the analysis provided in 2248 [RFC7421] suggests that the 64-bit boundary will remain in the IPv6 2249 architecture for the foreseeable future. 2251 Note: Even though this document honors the 64-bit boundary in IPv6 2252 addressing, it specifies prefix lengths longer than /64 for routing 2253 purposes. This effectively extends IPv6 routing determination into 2254 the interface identifier portion of the IPv6 address, but it does not 2255 redefine the 64-bit boundary. Modern routing protocol 2256 implementations honor IPv6 prefixes of all lengths, up to and 2257 including /128. 2259 9. Unique-Local Addresses (ULAs) 2261 OMNI domains use IPv6 Unique-Local Addresses (ULAs) as the source and 2262 destination addresses in OAL packet IPv6 encapsulation headers. ULAs 2263 are only routable within the scope of a an OMNI domain, and are 2264 derived from the IPv6 Unique Local Address prefix fc00::/7 followed 2265 by the L bit set to 1 (i.e., as fd00::/8) followed by a 40-bit 2266 pseudo-random Global ID to produce the prefix [ULA]::/48, which is 2267 then followed by a 16-bit Subnet ID then finally followed by a 64 bit 2268 Interface ID as specified in Section 3 of [RFC4193]. All nodes in 2269 the same OMNI domain configure the same 40-bit Global ID as the OMNI 2270 domain identifier. The statistic uniqueness of the 40-bit pseudo- 2271 random Global ID allows different OMNI domains to be joined together 2272 in the future without requiring renumbering. 2274 Each OMNI link instance is identified by a 16-bit Subnet ID value 2275 between 0x0000 and 0xfeff in bits 48-63 of [ULA]::/48. The Subnet ID 2276 values 0xff00 through 0xfffe are reserved for future use, while 2277 0xffff denotes the presence of a Temporary ULA (see below). For 2278 example, OMNI ULAs associated with instance 0 are configured from the 2279 prefix [ULA]:0000::/64, instance 1 from [ULA]:0001::/64, instance 2 2280 from [ULA]:0002::/64, etc. ULAs and their associated prefix lengths 2281 are configured in correspondence with LLAs through stateless prefix 2282 translation where "MNP-ULAs" are assigned in correspondence to MNP- 2283 LLAs and "ADM-ULAs" are assigned in correspondence to ADM-LLAs. For 2284 example, for OMNI link instance [ULA]:1010::/64: 2286 o the MNP-ULA corresponding to the MNP-LLA fe80::2001:db8:1:2 with a 2287 56-bit MNP length is derived by copying the lower 64 bits of the 2288 LLA into the lower 64 bits of the ULA as 2289 [ULA]:1010:2001:db8:1:2/120 (where, the ULA prefix length becomes 2290 64 plus the IPv6 MNP length). 2292 o the MNP-ULA corresponding to fe80::ffff:192.0.2.0 with a 28-bit 2293 MNP length is derived by simply writing the LLA interface ID into 2294 the lower 64 bits as [ULA]:1010:0:ffff:192.0.2.0/124 (where, the 2295 ULA prefix length is 64 plus 32 plus the IPv4 MNP length). 2297 o the ADM-ULA corresponding to fe80::1000/112 is simply 2298 [ULA]:1010::1000/112. 2300 o the ADM-ULA corresponding to fe80::/128 is simply 2301 [ULA]:1010::/128. 2303 o etc. 2305 The ULA presents an IPv6 address format that is routable within the 2306 OMNI routing system and can be used to convey link-scoped IPv6 ND 2307 messages across multiple hops using IPv6 encapsulation [RFC2473]. 2308 The OMNI link extends across one or more underling Internetworks to 2309 include all Proxy/Servers. All Clients are also considered to be 2310 connected to the OMNI link, however unnecessary encapsulations are 2311 omitted whenever possible to conserve bandwidth (see: Section 14). 2313 Temporary ULAs are constructed per [RFC8981] based on the prefix 2314 [ULA]:ffff::/64 and used by Clients when they have no other 2315 addresses. Temporary ULAs can be used for Client-to-Client 2316 communications outside the context of any supporting OMNI link 2317 infrastructure, and can also be used as an initial address while the 2318 Client is in the process of procuring an MNP. Temporary ULAs are not 2319 routable within the OMNI routing system, and are therefore useful 2320 only for OMNI link "edge" communications. Temporary ULAs employ 2321 optimistic DAD principles [RFC4429] since they are probabilistically 2322 unique. 2324 Each OMNI link may be subdivided into SRT segments that often 2325 correspond to different administrative domains or physical 2326 partitions. OMNI nodes can use Segment Routing [RFC8402] to support 2327 efficient forwarding to destinations located in other OMNI link 2328 segments. A full discussion of Segment Routing over the OMNI link 2329 appears in [I-D.templin-6man-aero]. 2331 Note: IPv6 ULAs taken from the prefix fc00::/7 followed by the L bit 2332 set to 0 (i.e., as fc00::/8) are never used for OMNI OAL addressing, 2333 however the range could be used for MSP/MNP addressing under certain 2334 limiting conditions (see: Section 10). 2336 10. Global Unicast Addresses (GUAs) 2338 OMNI domains use IP Global Unicast Address (GUA) prefixes [RFC4291] 2339 as Mobility Service Prefixes (MSPs) from which Mobile Network 2340 Prefixes (MNP) are delegated to Clients. Fixed correspondent node 2341 networks reachable from the OMNI domain are represented by non-MNP 2342 GUA prefixes that are not derived from the MSP, but are treated in 2343 all other ways the same as for MNPs. 2345 For IPv6, GUA MSPs are assigned by IANA [IPV6-GUA] and/or an 2346 associated regional assigned numbers authority such that the OMNI 2347 domain can be interconnected to the global IPv6 Internet without 2348 causing inconsistencies in the routing system. An OMNI domain could 2349 instead use ULAs with the 'L' bit set to 0 (i.e., from the prefix 2350 fc00::/8)[RFC4193], however this would require IPv6 NAT if the domain 2351 were ever connected to the global IPv6 Internet. 2353 For IPv4, GUA MSPs are assigned by IANA [IPV4-GUA] and/or an 2354 associated regional assigned numbers authority such that the OMNI 2355 domain can be interconnected to the global IPv4 Internet without 2356 causing routing inconsistencies. An OMNI domain could instead use 2357 private IPv4 prefixes (e.g., 10.0.0.0/8, etc.) [RFC3330], however 2358 this would require IPv4 NAT if the domain were ever connected to the 2359 global IPv4 Internet. OMNI interfaces advertise IPv4 MSPs into IPv6 2360 routing systems as IPv4-mapped IPv6 prefixes [RFC4291] (e.g., the 2361 IPv6 prefix for the IPv4 MSP 192.0.2.0/24 is ::ffff:192.0.2.0/120). 2363 OMNI interfaces assign the IPv4 anycast address TBD3, and IPv4 2364 routers that configure OMNI interfaces advertise the prefix TBD3/N 2365 into the routing system of other networks (see: IANA Considerations). 2366 OMNI interfaces also configure global IPv6 anycast addresses formed 2367 according to [RFC3056] as: 2369 2002:TBD3[32]:MNP[64]:Link_ID[16] 2371 where TBD3[32] is the 32 bit IPv4 anycast address, MNP[64] encodes an 2372 MSP zero-padded to 64 bits (if necessary) and Link_ID[16] encodes a 2373 16 bit value between 0 and 0xfffe that identifies a specific OMNI 2374 link within an OMNI domain (the Link_ID value 0xffff is an OMNI link 2375 "anycast" value configured by all OMNI interfaces within the same 2376 domain). For example, the OMNI IPv6 anycast address for MSP 2377 2001:db8::/32 is 2002:TBD3[32]:2001:db8:0:0:Link_ID[16], the OMNI 2378 IPv6 anycast address for MSP 192.0.2.0/24 is 2379 2002:TBD3[32]:0000:ffff:c000:0200:Link_ID[16], etc.). 2381 OMNI interfaces assign OMNI IPv6 anycast addresses, and IPv6 routers 2382 that configure OMNI interfaces advertise the corresponding prefixes 2383 into the routing system of other networks. An OMNI IPv6 anycast 2384 prefix is formed the same as for any IPv6 prefix; for example, the 2385 prefix 2002:TBD3[32]:2001:db8::/80 matches all OMNI IPv6 anycast 2386 addresses covered by the prefix. By advertising OMNI IPv6 anycast 2387 prefixes in this way, OMNI Clients can locate and associate with the 2388 OMNI domain and/or a specific link within the OMNI domain that 2389 services the MSP of interest. 2391 OMNI interfaces use OMNI IPv6 and IPv4 anycast addresses to support 2392 Service Discovery in the spirit of [RFC7094], i.e., the addresses are 2393 not intended for use in long-term transport protocol sessions. 2394 Specific applications for OMNI IPv6 and IPv4 anycast addresses are 2395 discussed throughout the document as well as in 2396 [I-D.templin-6man-aero]. 2398 11. Node Identification 2400 OMNI Clients and Proxy/Servers that connect over open Internetworks 2401 include a unique node identification value for themselves in the OMNI 2402 options of their IPv6 ND messages (see: Section 12.2.11). An example 2403 identification value alternative is the Host Identity Tag (HIT) as 2404 specified in [RFC7401], while Hierarchical HITs (HHITs) 2405 [I-D.ietf-drip-rid] may be more appropriate for certain domains such 2406 as the Unmanned (Air) Traffic Management (UTM) service for Unmanned 2407 Air Systems (UAS). Another example is the Universally Unique 2408 IDentifier (UUID) [RFC4122] which can be self-generated by a node 2409 without supporting infrastructure with very low probability of 2410 collision. 2412 When a Client is truly outside the context of any infrastructure, it 2413 may have no MNP information at all. In that case, the Client can use 2414 an IPv6 temporary ULA or (H)HIT as an IPv6 source/destination address 2415 for sustained communications in Vehicle-to-Vehicle (V2V) and 2416 (multihop) Vehicle-to-Infrastructure (V2I) scenarios. The Client can 2417 also propagate the ULA/(H)HIT into the multihop routing tables of 2418 (collective) Mobile/Vehicular Ad-hoc Networks (MANETs/VANETs) using 2419 only the vehicles themselves as communications relays. 2421 When a Client connects via a protected-spectrum ANET, an alternate 2422 form of node identification (e.g., MAC address, serial number, 2423 airframe identification value, VIN, etc.) embedded in an LLA/ULA may 2424 be sufficient. The Client can then include OMNI "Node 2425 Identification" sub-options (see: Section 12.2.11) in IPv6 ND 2426 messages should the need to transmit identification information over 2427 the network arise. 2429 12. Address Mapping - Unicast 2431 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 2432 state and use the link-local address format specified in Section 8. 2433 IPv6 Neighbor Discovery (ND) [RFC4861] messages sent over OMNI 2434 interfaces without encapsulation observe the native underlying 2435 interface Source/Target Link-Layer Address Option (S/TLLAO) format 2436 (e.g., for Ethernet the S/TLLAO is specified in [RFC2464]). IPv6 ND 2437 messages sent over OMNI interfaces using encapsulation do not include 2438 S/TLLAOs, but instead include a new option type that encodes 2439 encapsulation addresses, interface attributes and other OMNI link 2440 information. Hence, this document does not define an S/TLLAO format 2441 but instead defines a new option type termed the "OMNI option" 2442 designed for these purposes. (Note that OMNI interface IPv6 ND 2443 messages sent without encapsulation may include both OMNI options and 2444 S/TLLAOs, but the information conveyed in each is mutually 2445 exclusive.) 2447 OMNI interfaces prepare IPv6 ND messages that include one or more 2448 OMNI options (and any other IPv6 ND options) then completely populate 2449 all option information. If the OMNI interface includes an 2450 authentication signature, it sets the IPv6 ND message Checksum field 2451 to 0 and calculates the authentication signature over the length of 2452 the entire OAL packet or super-packet (beginning with a pseudo-header 2453 of the IPv6 ND message IPv6 header) but does not calculate/include 2454 the IPv6 ND message checksum itself. Otherwise, the OMNI interface 2455 calculates the standard IPv6 ND message checksum over the entire OAL 2456 packet or super-packet and writes the value in the Checksum field 2457 noting that optimized implementations can verify both the OAL and 2458 IPv6 ND message checksums in a single pass over the message data. 2459 OMNI interfaces verify authentication and/or integrity of each IPv6 2460 ND message received according to the specific check(s) included, and 2461 process the message further only following verification. 2463 OMNI interface Clients such as aircraft typically have multiple 2464 wireless data link types (e.g. satellite-based, cellular, 2465 terrestrial, air-to-air directional, etc.) with diverse performance, 2466 cost and availability properties. The OMNI interface would therefore 2467 appear to have multiple L2 connections, and may include information 2468 for multiple underlying interfaces in a single IPv6 ND message 2469 exchange. OMNI interfaces manage their dynamically-changing 2470 multilink profiles by including OMNI options in IPv6 ND messages as 2471 discussed in the following subsections. 2473 12.1. The OMNI Option 2475 OMNI options appear in IPv6 ND messages formatted as shown in 2476 Figure 10: 2478 0 1 2 3 2479 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 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Type | Length | Sub-Options ~ 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 Figure 10: OMNI Option Format 2486 In this format: 2488 o Type is set to TBD4 (see: IANA Considerations). 2490 o Length is set to the number of 8 octet blocks in the option. The 2491 value 0 is invalid, while the values 1 through 255 (i.e., 8 2492 through 2040 octets, respectively) indicate the total length of 2493 the OMNI option. If multiple OMNI option instances appear in the 2494 same IPv6 ND message, the union of the contents of all OMNI 2495 options is accepted unless otherwise qualified for specific sub- 2496 options below. 2498 o Sub-Options is a Variable-length field padded if necessary such 2499 that the complete OMNI Option is an integer multiple of 8 octets 2500 long. Sub-Options contains zero or more sub-options as specified 2501 in Section 12.2. 2503 The OMNI option is included in all OMNI interface IPv6 ND messages; 2504 the option is processed by receiving interfaces that recognize it and 2505 otherwise ignored. The OMNI interface processes all OMNI option 2506 instances received in the same IPv6 ND message in the consecutive 2507 order in which they appear. The OMNI option(s) included in each IPv6 2508 ND message may include full or partial information for the neighbor. 2509 The OMNI interface therefore retains the union of the information in 2510 the most recently received OMNI options in the corresponding NCE. 2512 12.2. OMNI Sub-Options 2514 Each OMNI option includes a Sub-Options block containing zero or more 2515 individual sub-options. Each consecutive sub-option is concatenated 2516 immediately following its predecessor. All sub-options except Pad1 2517 (see below) are in an OMNI-specific type-length-value (TLV) format 2518 encoded as follows: 2520 0 1 2 2521 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 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2523 | Sub-Type| Sub-Length | Sub-Option Data ... 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2526 Figure 11: Sub-Option Format 2528 o Sub-Type is a 5-bit field that encodes the sub-option type. Sub- 2529 option types defined in this document are: 2531 Sub-Option Name Sub-Type 2532 Pad1 0 2533 PadN 1 2534 Interface Attributes 2 2535 Multilink Forwarding Params 3 2536 Traffic Selector 4 2537 Geo Coordinates 5 2538 DHCPv6 Message 6 2539 HIP Message 7 2540 PIM-SM Message 8 2541 Fragmentation Report 9 2542 Node Identification 10 2543 ICMPv6 Error 11 2544 QUIC-TLS Message 12 2545 Proxy/Server Departure 13 2546 OMNI Header Extension 14 2547 Sub-Type Extension 30 2549 Figure 12 2551 Sub-Types 15-29 are available for future assignment for major 2552 protocol functions. Sub-Type 31 is reserved by IANA. 2554 o Sub-Length is an 11-bit field that encodes the length of the Sub- 2555 Option Data in octets. 2557 o Sub-Option Data is a block of data with format determined by Sub- 2558 Type and length determined by Sub-Length. Note that each 2559 individual sub-option may end on an arbitrary octet boundary, 2560 whereas the OMNI option itself must include padding if necessary 2561 for 8-octet alignment. 2563 The OMNI interface codes each sub-option with a 2 octet header that 2564 includes Sub-Type in the most significant 5 bits followed by Sub- 2565 Length in the next most significant 11 bits. Each sub-option encodes 2566 a maximum Sub-Length value of 2038 octets minus the lengths of the 2567 OMNI option header and any preceding sub-options. This allows ample 2568 Sub-Option Data space for coding large objects (e.g., ASCII strings, 2569 domain names, protocol messages, security codes, etc.), while a 2570 single OMNI option is limited to 2040 octets the same as for any IPv6 2571 ND option. 2573 The OMNI interface codes initial sub-options in a first OMNI option 2574 instance and subsequent sub-options in additional instances in the 2575 same IPv6 ND message in the intended order of processing. The OMNI 2576 interface can then code any remaining sub-options in additional IPv6 2577 ND messages if necessary. Implementations must observe these size 2578 limits and refrain from sending IPv6 ND messages larger than the OMNI 2579 interface MTU. 2581 The OMNI interface processes all OMNI option Sub-Options received in 2582 an IPv6 ND message while skipping over and ignoring any unrecognized 2583 sub-options. The OMNI interface processes the Sub-Options of all 2584 OMNI option instances in the consecutive order in which they appear 2585 in the IPv6 ND message, beginning with the first instance and 2586 continuing through any additional instances to the end of the 2587 message. If an individual sub-option length would cause processing 2588 to exceed the OMNI option instance and/or IPv6 ND message lengths, 2589 the OMNI interface accepts any sub-options already processed and 2590 ignores the remainder of that instance. The interface then processes 2591 any remaining OMNI option instances in the same fashion to the end of 2592 the IPv6 ND message. 2594 When an OMNI interface includes an authentication sub-option (e.g., 2595 see: Section 12.2.8), it MUST appear as the first sub-option of the 2596 first OMNI option which must appear immediately following the IPv6 ND 2597 message header. If the IPv6 ND message includes additional 2598 authentication sub-options, only the first sub-option is processed 2599 and all others are ignored. If the IPv6 ND message is the first 2600 packet in a combined OAL super-packet, the OMNI interface calculates 2601 the authentication signature over the entire length of the super- 2602 packet, i.e., and not just to the end of the IPv6 ND message itself. 2603 (When no authentication sub-option is included, the OMNI interface 2604 instead calculates the IPv6 ND message checksum over the entire 2605 length of the packet/super-packet.) 2607 When a Client OMNI interface prepares a secured unicast RS message, 2608 it includes an Interface Attributes sub-option specific to the 2609 underlying interface that will transmit the RS (see: Section 12.2.3) 2610 immediately following the authentication and header extension sub- 2611 options if present; otherwise as the first sub-option of the first 2612 OMNI option which must appear immediately following the IPv6 ND 2613 message header. When a Client OMNI interface prepares a secured 2614 unicast NS message, it instead includes a Multilink Forwarding 2615 Parameters sub-option specific to the underlying interface that will 2616 transmit the NS (see: Section 12.2.4). 2618 Note: large objects that exceed the maximum Sub-Option Data length 2619 are not supported under the current specification; if this proves to 2620 be limiting in practice, future specifications may define support for 2621 fragmenting large sub-options across multiple OMNI options within the 2622 same IPv6 ND message (or even across multiple IPv6 ND messages, if 2623 necessary). 2625 The following sub-option types and formats are defined in this 2626 document: 2628 12.2.1. Pad1 2630 0 2631 0 1 2 3 4 5 6 7 2632 +-+-+-+-+-+-+-+-+ 2633 | S-Type=0|x|x|x| 2634 +-+-+-+-+-+-+-+-+ 2636 Figure 13: Pad1 2638 o Sub-Type is set to 0. If multiple instances appear in OMNI 2639 options of the same message all are processed. 2641 o Sub-Type is followed by 3 'x' bits, set to any value on 2642 transmission (typically all-zeros) and ignored on reception. Pad1 2643 therefore consists of 1 octet with the most significant 5 bits set 2644 to 0, and with no Sub-Length or Sub-Option Data fields following. 2646 If more than one octet of padding is required, the PadN option, 2647 described next, should be used, rather than multiple Pad1 options. 2649 12.2.2. PadN 2651 0 1 2 2652 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 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2654 | S-Type=1| Sub-length=N | N padding octets ... 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2657 Figure 14: PadN 2659 o Sub-Type is set to 1. If multiple instances appear in OMNI 2660 options of the same message all are processed. 2662 o Sub-Length is set to N that encodes the number of padding octets 2663 that follow. 2665 o Sub-Option Data consists of N octets, set to any value on 2666 transmission (typically all-zeros) and ignored on receipt. 2668 When a proxy forwards an IPv6 ND message with OMNI options, it can 2669 employ PadN to cancel any sub-options (other than Pad1) that should 2670 not be processed by the next hop by simply writing the value '1' over 2671 the Sub-Type. When the proxy alters the IPv6 ND message contents in 2672 this way, any included authentication and integrity checks are 2673 invalidated. See: Appendix B for a discussion of IPv6 ND message 2674 authentication and integrity. 2676 12.2.3. Interface Attributes 2678 The Interface Attributes sub-option provides neighbors with 2679 forwarding information for the multilink conceptual sending algorithm 2680 discussed in Section 14. Neighbors use the forwarding information to 2681 selecting among potentially multiple candidate underlying interfaces 2682 that can be used to forward carrier packets to the neighbor based on 2683 factors such as traffic selectors and link quality. Interface 2684 Attributes further include link-layer address information to be used 2685 for either direct INET encapsulation for targets in the local SRT 2686 segment or spanning tree forwarding for targets in remote SRT 2687 segments. 2689 OMNI nodes include Interface Attributes for some/all of a target 2690 Client's underlying interfaces in NS/NA and uNA messages used to 2691 publish Client information (see: [I-D.templin-6man-aero]). At most 2692 one Interface Attributes sub-option for each distinct omIndex may be 2693 included; if an NS/NA message includes multiple Interface Attributes 2694 sub-options for the same omIndex, the first is processed and all 2695 others are ignored. OMNI nodes that receive NS/NA messages can use 2696 all of the included Interface Attributes and/or Traffic Selectors to 2697 formulate a map of the prospective target node as well as to seed the 2698 information to be populated in a Multilink Forwarding Parameters sub- 2699 option (see: Section 12.2.4). 2701 OMNI Clients and Proxy/Servers also include Interface Attributes sub- 2702 options in RS/RA messages used to initialize, discover and populate 2703 routing and addressing information. Each RS message MUST contain 2704 exactly one Interface Attributes sub-option with an omIndex 2705 corresponding to the Client's underlying interface used to transmit 2706 the message, and each RA message MUST echo the same Interface 2707 Attributes sub-option with any (proxyed) information populated by the 2708 FHS Proxy/Server to provide operational context. 2710 OMNI Client RS and Proxy/Server RA messages MUST include the 2711 Interface Attributes sub-option for the Client underlying interface 2712 in the first OMNI option immediately following an authentication 2713 message sub-option if present; otherwise, immediately following the 2714 OMNI header. When an FHS Proxy/Server receives an RS message 2715 destined to an anycast *NET address, it MUST include an Interface 2716 Attributes sub-option with omIndex '0' that encodes a unicast *NET 2717 INADDR immediately after the Interface Attributes sub-option for the 2718 Client's underlying interface in the solicited RA response. Any 2719 additional Interface Attributes sub-options that appear in RS/RA 2720 messages are ignored. 2722 The Interface Attributes sub-options are formatted as shown below: 2724 0 1 2 3 2725 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 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | S-Type=2| Sub-length=N | omIndex | omType | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | Provider ID | Link | Resvd | FMT | SRT | ~ 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 2731 ~ LHS Proxy/Server MSID/INADDR ~ 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 Figure 15: Interface Attributes 2736 o Sub-Type is set to 2. 2738 o Sub-Length is set to N that encodes the number of Sub-Option Data 2739 octets that follow. 2741 o Sub-Option Data contains an "Interface Attributes" option encoded 2742 as follows: 2744 * omIndex is a 1-octet value corresponding to a specific 2745 underlying interface. Client OMNI interfaces MUST number each 2746 distinct underlying interface with an omIndex value between '1' 2747 and '255' that represents a Client-specific 8-bit mapping for 2748 the actual ifIndex value assigned by network management 2749 [RFC2863], then set omIndex to either a specific omIndex value 2750 or '0' to denote "unspecified". 2752 * omType is set to an 8-bit integer value corresponding to the 2753 underlying interface identified by omIndex. The value 2754 represents an OMNI interface-specific 8-bit mapping for the 2755 actual IANA ifType value registered in the 'IANAifType-MIB' 2756 registry [http://www.iana.org]. 2758 * Provider ID is set to an OMNI interface-specific 8-bit ID value 2759 for the network service provider associated with this omIndex. 2761 * Link encodes a 4-bit link metric. The value '0' means the link 2762 is DOWN, and the remaining values mean the link is UP with 2763 metric ranging from '1' ("lowest") to '15' ("highest"). 2765 * Resvd is a 4-bit Reserved field set to 0 on transmission and 2766 ignored on reception. 2768 * FMT - a 3-bit "Forward/Mode/Type" code interpreted as follows: 2770 + The most significant two bits (i.e., "FMT-Forward" and "FMT- 2771 Mode") are interpreted in conjunction with one another. 2772 When FMT-Forward is clear, the LHS Proxy/Server performs OAL 2773 reassembly and decapsulation to obtain the original IP 2774 packet before forwarding. If the FMT-Mode bit is clear, the 2775 LHS Proxy/Server then forwards the original IP packet at 2776 layer 3; otherwise, it invokes the OAL to re-encapsulate, 2777 re-fragment and forwards the resulting carrier packets to 2778 the Client via the selected underlying interface. When FMT- 2779 Forward is set, the LHS Proxy/Server forwards unsecured OAL 2780 fragments to the Client without reassembling, while 2781 reassembling secured OAL fragments before re-fragmenting and 2782 forwarding to the Client. If FMT-Mode is clear, all carrier 2783 packets destined to the Client must always be forwarded 2784 through the LHS Proxy/Server; otherwise the Client is 2785 eligible for direct forwarding over the open INET where it 2786 may be located behind one or more NATs. 2788 + The least significant bit (i.e., "FMT-Type") determines the 2789 length of the LHS Proxy/Server INADDR field for NS/NA 2790 messages; if FMT-Type is clear, INADDR includes a 4-octet 2791 IPv4 address (otherwise a 16-octet IPv6 address). For RS/RA 2792 messages, the LHS Proxy/Server INADDR field is always 2793 exactly 16 octets. If FMT-type is clear, INADDR encodes an 2794 IPv4-mapped IPv6 address; otherwise an ordinary IPv6 2795 address. 2797 * SRT - a 5-bit Segment Routing Topology prefix length value that 2798 (when added to 96) determines the prefix length to apply to the 2799 ULA formed from concatenating [ULA*]::/96 with the 32 bit LHS 2800 MSID value that follows. For example, the value 16 corresponds 2801 to the prefix length 112. 2803 * LHS Proxy/Server MSID/INADDR - the first 32 bits includes the 2804 MSID of the LHS Proxy/Server on the path from a source neighbor 2805 to the target Client's underlying interface. When SRT and MSID 2806 are both set to 0, the LHS Proxy/Server is considered 2807 unspecified in this IPv6 ND message. FMT, SRT and LHS together 2808 provide guidance for the OMNI interface forwarding algorithm. 2809 Specifically, if SRT/LHS is located in the local OMNI link 2810 segment, then the source can reach the target Client either 2811 through its dependent Proxy/Server or through direct 2812 encapsulation following NAT traversal according to FMT. 2813 Otherwise, the target Client is located on a different SRT 2814 segment and the path from the source must employ a combination 2815 of route optimization and spanning tree hop traversals. INADDR 2816 identifies the LHS Proxy/Server's INET-facing interface not 2817 located behind NATs, therefore no UDP port number is included 2818 since port number 8060 is used when the *NET encapsulation 2819 includes a UDP header. Instead, INADDR includes only a 4-octet 2820 IPv4 or 16-octet IPv6 address with type and length determined 2821 by FMT-Type. The IP address is recorded in network byte order 2822 in ones-compliment "obfuscated" form per [RFC4380]. 2824 12.2.4. Multilink Forwarding Parameters 2826 OMNI nodes include the Multilink Forwarding Parameters sub-option in 2827 NS/NA messages used to coordinate with multilink route optimization 2828 targets. If an NS message includes the sub-option, the solicited NA 2829 response must also include the sub-option. The OMNI node MUST 2830 include the sub-option in the first OMNI option immediately following 2831 an authentication message sub-option. Otherwise, the OMNI node MUST 2832 include the sub-option immediately following the OMNI header. Each 2833 NS/NA message may contain at most one Multilink Forwarding Parameters 2834 sub-option; if an NS/NA message contains additional Multlink 2835 Forwarding Parameters sub-options, the first is processed and all 2836 others are ignored. 2838 When an NS/NA message includes the sub-option, the FHS Client omIndex 2839 MUST correspond to the underlying interface used to transmit the 2840 message. When the NS/NA message also includes Interface Attributes 2841 sub-options any that include the same FHS/LHS Client omIndex are 2842 ignored while all others are processed. 2844 The Multilink Forwarding Parameters sub-option includes the necessary 2845 state for establishing Multilink Forwarding Vectors (MFVs) in the 2846 Multilink Forwarding Information Bases (MFIBs) of the OAL source, 2847 destination and intermediate nodes in the path. The sub-option also 2848 records addressing information for FHS/LHS nodes on the path, 2849 including "INADDRs" which MUST be unicast IP encapsulation addresses 2850 (i.e., and not anycast/multicast). The manner for populating 2851 multilink forwarding information is specified in detail in 2852 [I-D.templin-6man-aero]. 2854 The Multilink Forwarding Parameters sub-option is formatted as shown 2855 in Figure 16: 2857 0 1 2 3 2858 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 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | S-Type=3| Sub-length=N |Job| A | B | ~ 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 2862 ~ Multilink Forwarding Vector Index (MFVI) List ~ 2863 ~ (5 consecutive 4-octet MFVIs) ~ 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 ~ Tunnel Window Synchronization Parameters ~ 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 |FHS Cli omIndex| omType | Provider ID | Link | Resvd | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | FMT | SRT | ~ 2870 +-+-+-+-+-+-+-+-+ ~ 2871 ~ FHS Proxy/Server MSID/INADDR ~ 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 ~ FHS Bridge MSID/INADDR ~ 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 |LHS Cli omIndex| omType | Provider ID | Link | Resvd | 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2877 | FMT | SRT | ~ 2878 +-+-+-+-+-+-+-+-+ ~ 2879 ~ LHS Proxy/Server MSID/INADDR ~ 2880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 ~ LHS Bridge MSID/INADDR ~ 2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 Figure 16: Multilink Forwarding Parameters 2886 o Sub-Type is set to 3. If multiple instances appear in the same 2887 message (i.e., whether in a single OMNI option or multiple) the 2888 first instance is processed and all others are ignored. 2890 o Sub-Length encodes the number of Sub-Option Data octets that 2891 follow. The length includes all fields up to and including the 2892 Tunnel Window Synchronization Parameters for all Job codes, while 2893 including the remaining fields only for Job codes "00" and "01" 2894 (see below). 2896 o Sub-Option Data contains Multilink Forwarding Parameters as 2897 follows: 2899 * Job/A/B is a 1-octet field that determines per-hop processing 2900 of the MFVI List, where A is a 3-bit count of the number of "A" 2901 MVFI List entries and B is a 3-bit count of the number of "B" 2902 MVFI List entries (valid A/B values are 0-5). Job is a 2-bit 2903 code interpreted as follows: 2905 + 00 - "Initialize; Build B" - the FHS source sets this code 2906 in an NS used to initialize MFV state (any other messages 2907 that include this code MUST be dropped). The FHS source 2908 first sets A/B to 0, and the FHS source and each 2909 intermediate node along the path to the LHS destination that 2910 processes the message creates a new MFV. Each node that 2911 processes the message then assigns a unique 4-octet "B" MFVI 2912 to the MVF and also writes the value into list entry B, then 2913 increments B. When the message arrives at the LHS 2914 destination, B will contain the number of MFVI List "B" 2915 entries, with the FHS source entry first, followed by 2916 entries for each consecutive intermediate node and ending 2917 with an entry for the final intermediate node (i.e., the 2918 list is populated in the forward direction). 2920 + 01 - "Follow B; Build A" - the LHS source sets this code in 2921 a solicited NA response to a solicitation with code "00" 2922 (any other messages that include this code MUST be dropped). 2923 The LHS source first copies the MFVI List and B value from 2924 the code "00" solicitation into these fields and sets A to 2925 0. The LHS source and each intermediate node along the path 2926 to the FHS destination that processes the message then uses 2927 MFVI List entry B to locate the corresponding MFV. Each 2928 node that processes the message then assigns a unique 2929 4-octet "A" MFVI to the MVF and also writes the value into 2930 list entry B, then increments A and decrements B. When the 2931 message arrives at the FHS destination, A will contain the 2932 number of MFVI List "A" entries, with the LHS source entry 2933 last, preceded by entries for each consecutive intermediate 2934 node and beginning with an entry for the final intermediate 2935 node (i.e., the list is populated in the reverse direction). 2937 + 10 - "Follow A; Record B" - the FHS node that sent the 2938 original code "00" solicitation and received the 2939 corresponding code "01" advertisement sets this code in any 2940 subsequent NS/NA messages sent to the same LHS destination. 2941 The FHS source copies the MVFI List and A value from the 2942 code "01" advertisement into these fields and sets B to 0. 2943 The FHS source and each intermediate node along the path to 2944 the LHS destination that processes the message then uses the 2945 "A" MFVI found at list entry B to locate the corresponding 2946 MFV. Each node that processes the message then writes the 2947 MVF's "B" MFVI into list entry B, then decrements A and 2948 increments B. When the message arrives at the LHS 2949 destination, B will contain the number of MFVI List "B" 2950 entries populated in the forward direction. 2952 + 11 - "Follow B; Record A" - the LHS node that received the 2953 original code "00" solicitation and sent the corresponding 2954 code "01" advertisement sets this code in any subsequent NS/ 2955 NA messages sent to the same FHS destination. The LHS 2956 source copies the MVFI List and B values from the code "00" 2957 solicitation into these fields and sets A to 0. The LHS 2958 source and each intermediate node along the path to the FHS 2959 destination that processes the message then uses the "B" 2960 MFVI List entry found at list entry B to locate the 2961 corresponding MFV. Each node that processes the message 2962 then writes the MFV's "A" MFVI into list entry B, then 2963 increments A and decrements B. When the message arrives at 2964 the FHS destination, A will contain the number of MFVI List 2965 "A" entries populated in the reverse direction. 2967 Job/A/B together determine the per-hop behavior at each FHS/LHS 2968 source, intermediate node and destination that processes an 2969 IPv6 ND message. When a Job code specifies "Initialize", each 2970 FHS/LHS node that processes the message creates a new MVF. 2971 When a Job code specifies "Build", each node that processes the 2972 message assigns a new MFVI. When a Job code specifies 2973 "Follow", each node that processes the message uses an A/B MFVI 2974 List entry to locate an MFV (if the MFV cannot be located, the 2975 node returns a parameter problem and drops the message). Using 2976 this algorithm, FHS sources that send code "00" solicitations 2977 and receive code "01 advertisements discover only "A" 2978 information, while LHS sources that receive code "00" 2979 solicitations and return code "01" advertisements discover only 2980 "B" information. FHS/LHS intermediate nodes can instead 2981 examine A, B and the MFVI List to determine the number of 2982 previous hops, the number of remaining hops, and the A/B MFVIs 2983 associated with the previous/remaining hops. However, no 2984 intermediate nodes will discover inappropriate A/B MFVIs for 2985 their location in the multihop forwarding chain. See: 2986 [I-D.templin-6man-aero] for further discussion on A/B MFVI 2987 processing. 2989 * Multilink Forwarding Vector Index (MFVI) List is a 20-octet 2990 block that contains 5 consecutive 4-octet MFVI entries. The 2991 FHS/LHS source and each intermediate node on the path to the 2992 destination processes the list according to the Job/A/B codes 2993 (see above). 2995 * Tunnel Window Synchronization Parameters is a 12-octet block 2996 that consists of a 4-octet Sequence Number followed by a 2997 4-octet Acknowledgement Number followed by a 1-octet Flags 2998 field followed by a 3-octet Window field (i.e., the same as for 2999 the OMNI header parameters). Tunnel endpoints use these 3000 parameters for simultaneous middlebox window synchronization in 3001 a single solicitation/advertisement message exchange. 3003 * For Job codes "00" and "01" only, two trailing state variable 3004 blocks are included for First-Hop Segment (FHS) followed by 3005 Last-Hop Segment (LHS) network elements. When present, each 3006 block encodes the following information: 3008 + Client omIndex, omType, Provider ID and Resvd/Link are 3009 1-octet fields (at offset 0 from the beginning of the Sub- 3010 Option Data) that include link parameters for the Client 3011 underlying interface. These fields are populated based on 3012 information discovered in Interface Attributes sub-options 3013 included in earlier RS/RA and/or NS/NA exchanges. 3015 + FMT/SRT is a 1-octet field with a 5-bit SRT prefix length 3016 that applies to all elements in the segment. The FMT- 3017 Forward/Mode bits determine the characteristics of the 3018 Proxy/Server relationship for this specific Client 3019 underlying interface (i.e., the same as described in 3020 Section 12.2.3), and the FMT-Type bits determine the IP 3021 address version for all INADDR fields relative to this SRT 3022 segment. Unlike the case for Interface Attributes, all 3023 INADDR fields are always 16 bits in length regardless of the 3024 IP protocol version (for IPv4, INADDR is encoded as an 3025 IPv4-mapped IPv6 address [RFC4291]). The IP address is 3026 recoded in network byte order, and in ones-compliment 3027 "obfuscated" form the same as described in Section 12.2.3. 3029 + Proxy/Server MSID/INADDR includes a 4-octet Proxy/Server 3030 MSID followed by a 16 octet INADDR. INADDR identifies an 3031 open INET interface not located behind NATs, therefore no 3032 UDP port number is included since port number 8060 is used 3033 when the *NET encapsulation includes a UDP header. 3035 + Bridge MSID/INADDR encodes a 4 octet MSID followed by a 3036 16-octet INADDR exactly as for the Proxy/Server MSID/INADDR. 3038 12.2.5. Traffic Selector 3040 When used in conjunction with Interface Attributes and/or Multilink 3041 Forwarding Parameters information, the Traffic Selector sub-option 3042 provides forwarding information for the multilink conceptual sending 3043 algorithm discussed in Section 14. 3045 IPv6 ND messages include Traffic Selectors for some or all of the 3046 source/target Client's underlying interfaces. Traffic Selectors for 3047 some or all of a target Client's underlying interfaces are also 3048 included in uNA messages used to publish Client information changes. 3049 See: [I-D.templin-6man-aero] for more information. 3051 Traffic Selectors must be honored by all implementations in the 3052 format shown below: 3054 0 1 2 3 3055 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 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3057 | S-Type=4| Sub-length=N | omIndex | TS Format | 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3059 ~ ~ 3060 ~ RFC 6088 Format Traffic Selector ~ 3061 ~ ~ 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3064 Figure 17: Traffic Selector 3066 o Sub-Type is set to 4. Each IPv6 ND message may contain zero or 3067 more Traffic Selectors for each omIndex; when multiple Traffic 3068 Selectors for the same omIndex appear, all are processed and the 3069 cumulative information from all is accepted. 3071 o Sub-Length is set to N that encodes the number of Sub-Option Data 3072 octets that follow. 3074 o Sub-Option Data contains a "Traffic Selector" encoded as follows: 3076 * omIndex is a 1-octet value corresponding to a specific 3077 underlying interface the same as specified above for Interface 3078 Attributes and Multilink Forwarding Parameters above. The OMNI 3079 options of a single message may include multiple Traffic 3080 Selector sub-options; each with the same or different omIndex 3081 values. 3083 * TS Format is a 1-octet field that encodes a Traffic Selector 3084 version per [RFC6088]. If TS Format encodes the value 1 or 2, 3085 the Traffic Selector includes IPv4 or IPv6 information, 3086 respectively. If TS Format encodes any other value, the sub- 3087 option is ignored. 3089 * The remainder of the sub-option includes a traffic selector 3090 formatted per [RFC6088] beginning with the "Flags (A-N)" field, 3091 and with the Traffic Selector IP protocol version coded in the 3092 TS Format field. If a single interface identified by omIndex 3093 requires Traffic Selectors for multiple IP protocol versions, 3094 or if a Traffic Selector block would exceed the available 3095 space, the remaining information is coded in additional Traffic 3096 Selector sub-options that all encode the same omIndex. 3098 12.2.6. Geo Coordinates 3100 0 1 2 3 3101 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 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3103 | S-Type=5| Sub-length=N | Geo Type |Geo Coordinates 3104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 3106 Figure 18: Geo Coordinates Sub-option 3108 o Sub-Type is set to 5. If multiple instances appear in OMNI 3109 options of the same message all are processed. 3111 o Sub-Length is set to N that encodes the number of Sub-Option Data 3112 octets that follow. 3114 o Geo Type is a 1 octet field that encodes a type designator that 3115 determines the format and contents of the Geo Coordinates field 3116 that follows. The following types are currently defined: 3118 * 0 - NULL, i.e., the Geo Coordinates field is zero-length. 3120 o A set of Geo Coordinates of length up to the remaining available 3121 space for this OMNI option. New formats to be specified in future 3122 documents and may include attributes such as latitude/longitude, 3123 altitude, heading, speed, etc. 3125 12.2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Message 3127 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) sub-option 3128 may be included in the OMNI options of Client RS messages and Proxy/ 3129 Server RA messages. FHS Proxy/Servers that forward RS/RA messages 3130 between a Client and an LHS Proxy/Server also forward DHCPv6 Sub- 3131 Options unchanged. Note that DHCPv6 messages do not include a 3132 Checksum field since integrity is protected by the IPv6 ND message 3133 checksum, authentication signature and/or lower-layer authentication 3134 and integrity checks. 3136 0 1 2 3 3137 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 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 | S-Type=6| Sub-length=N | msg-type | id (octet 0) | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 | transaction-id (octets 1-2) | | 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3143 | | 3144 . DHCPv6 options . 3145 . (variable number and length) . 3146 | | 3147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 Figure 19: DHCPv6 Message Sub-option 3151 o Sub-Type is set to 6. If multiple instances appear in OMNI 3152 options of the same message the first is processed and all others 3153 are ignored. 3155 o Sub-Length is set to N that encodes the number of Sub-Option Data 3156 octets that follow. The 'msg-type' and 'transaction-id' fields 3157 are always present; hence, the length of the DHCPv6 options is 3158 limited by the remaining available space for this OMNI option. 3160 o 'msg-type' and 'transaction-id' are coded according to Section 8 3161 of [RFC8415]. 3163 o A set of DHCPv6 options coded according to Section 21 of [RFC8415] 3164 follows. 3166 12.2.8. Host Identity Protocol (HIP) Message 3168 The Host Identity Protocol (HIP) Message sub-option (when present) 3169 provides authentication for IPv6 ND messages exchanged between 3170 Clients and FHS Proxy/Servers over an open Internetwork. FHS Proxy/ 3171 Servers authenticate the HIP authentication signatures in source 3172 Client IPv6 ND messages before securely forwarding them to other OMNI 3173 nodes. LHS Proxy/Servers that receive secured IPv6 ND messages from 3174 other OMNI nodes that do not already include a security sub-option 3175 insert HIP authentication signatures before forwarding them to the 3176 target Client. 3178 OMNI interfaces MUST include the HIP message (when present) as the 3179 first sub-option of the first OMNI option, which MUST appear 3180 immediately following the IPv6 ND message header. OMNI interfaces 3181 can therefore easily locate the HIP message and verify the 3182 authentication signature without applying deep inspection. OMNI 3183 interfaces that receive IPv6 ND messages without a HIP (or other 3184 authentication) sub-option instead verify the IPv6 ND message 3185 checksum. 3187 OMNI interfaces include the HIP message sub-option when they forward 3188 IPv6 ND messages that require security over INET underlying 3189 interfaces, i.e., where authentication and integrity is not already 3190 assured by lower layers. The OMNI interface calculates the 3191 authentication signature over the entire length of the OAL packet (or 3192 super-packet) beginning with a pseudo-header of the IPv6 ND message 3193 header and extending over the remainder of the OAL packet. OMNI 3194 interfaces that process OAL packets that contain secured IPv6 ND 3195 messages verify the signature then either process the rest of the 3196 message locally or forward a proxyed copy to the next hop. 3198 When a FHS Client inserts a HIP message sub-option in an NS/NA 3199 message destined to a target in a remote spanning tree segment, it 3200 must ensure that the insertion does not cause the message to exceed 3201 the OMNI interface MTU. When the remote segment LHS Proxy/Server 3202 forwards the NS/NA message from the spanning tree to the target 3203 Client, it inserts a new HIP message sub-option if necessary while 3204 overwriting or cancelling the (now defunct) HIP message sub-option 3205 supplied by the FHS Client. 3207 If the defunct HIP sub-option size was smaller than the space needed 3208 for the LHS Client HIP message (or, if no defunct HIP sub-option is 3209 present), the LHS Proxy/Server adjusts the space immediately 3210 following the OMNI header by copying the preceding portion of the 3211 IPv6 ND message into buffer headroom free space or copying the 3212 remainder of the IPv6 ND message into buffer tailroom free space. 3213 The LHS Proxy/Server then insets the new HIP sub-option immediately 3214 after the OMNI header and immediately before the next sub-option 3215 while properly overwriting the defunct sub-option if present. 3217 If the defunct HIP sub-option size was larger than the space needed 3218 for the LHS Client HIP message, the LHS Proxy/Server instead 3219 overwrites the existing sub-option and writes a single Pad1 or PadN 3220 sub-option over the next 1-2 octets to cancel the remainder of the 3221 defunct sub-option. If the LHS Proxy/Server cannot create sufficient 3222 space through any means without causing the OMNI option to exceed 3223 2040 octets or causing the IPv6 ND message to exceed the OMNI 3224 interface MTU, it returns a suitable error (see: Section 12.2.12) and 3225 drops the message. 3227 The HIP message sub-option is formatted as shown below: 3229 0 1 2 3 3230 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 3231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3232 | S-Type=7| Sub-length=N |0| Packet Type |Version| RES.|1| 3233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3234 | Reserved | Controls | 3235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3236 | Sender's Host Identity Tag (HIT) | 3237 | | 3238 | | 3239 | | 3240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3241 | Receiver's Host Identity Tag (HIT) | 3242 | | 3243 | | 3244 | | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | | 3247 / HIP Parameters / 3248 / / 3249 | | 3250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 Figure 20: HIP Message Sub-option 3254 o Sub-Type is set to 7. If multiple instances appear in OMNI 3255 options of the same message the first is processed and all others 3256 are ignored. 3258 o Sub-Length is set to N, i.e., the length of the option in octets 3259 beginning immediately following the Sub-Length field and extending 3260 to the end of the HIP parameters. The length of the entire HIP 3261 message is therefore limited by the remaining available space for 3262 this OMNI option. 3264 o The HIP message is coded per Section 5 of [RFC7401], except that 3265 the OMNI "Sub-Type" and "Sub-Length" fields replace the first 2 3266 octets of the HIP message header (i.e., the Next Header and Header 3267 Length fields). Also, since the IPv6 ND message is already 3268 protected by the authentication signature and/or lower-layer 3269 authentication and integrity checks, the HIP message Checksum 3270 field is replaced by a Reserved field set to 0 on transmission and 3271 ignored on reception. 3273 Note: In some environments, maintenance of a Host Identity Tag (HIT) 3274 namespace may be unnecessary for securely associating an OMNI node 3275 with an IPv6 address-based identity. In that case, other types of 3276 IPv6 addresses (e.g., a Client's MNP-LLA, a Proxy/Server's ADM-LLA, 3277 etc.) can be used instead of HITs in the authentication signature as 3278 long as the address can be uniquely associated with the Sender/ 3279 Receiver. 3281 12.2.9. PIM-SM Message 3283 The Protocol Independent Multicast - Sparse Mode (PIM-SM) Message 3284 sub-option may be included in the OMNI options of IPv6 ND messages. 3285 PIM-SM messages are formatted as specified in Section 4.9 of 3286 [RFC7761], with the exception that the Checksum field is replaced by 3287 a Reserved field (set to 0) since the IPv6 ND message is already 3288 protected by the IPv6 ND message checksum, authentication signature 3289 and/or lower-layer authentication and integrity checks. The PIM-SM 3290 message sub-option format is shown in Figure 21: 3292 0 1 2 3 3293 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 3294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3295 | S-Type=8| Sub-length=N |PIM Ver| Type | Reserved | 3296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 | | 3298 / PIM-SM Message / 3299 / / 3300 | | 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3303 Figure 21: PIM-SM Message Option Format 3305 o Sub-Type is set to 8. If multiple instances appear in OMNI 3306 options of the same message all are processed. 3308 o Sub-Length is set to N, i.e., the length of the option in octets 3309 beginning immediately following the Sub-Length field and extending 3310 to the end of the PIM-SM message. The length of the entire PIM-SM 3311 message is therefore limited by the remaining available space for 3312 this OMNI option. 3314 o The PIM-SM message is coded exactly as specified in Section 4.9 of 3315 [RFC7761], except that the Checksum field is replaced by a 3316 Reserved field set to 0 on transmission and ignored on reception. 3317 The "PIM Ver" field MUST encode the value 2, and the "Type" field 3318 encodes the PIM message type. (See Section 4.9 of [RFC7761] for a 3319 list of PIM-SM message types and formats.) 3321 12.2.10. Fragmentation Report (FRAGREP) 3323 Fragmentation Report (FRAGREP) sub-options may be included in the 3324 OMNI options of uNA messages sent from an OAL destination to an OAL 3325 source. The message consists of (N / 12)-many (Identification, 3326 Bitmap)-tuples which include the Identification values of OAL 3327 fragments received plus a Bitmap marking the ordinal positions of 3328 individual fragments received and fragments missing. 3330 0 1 2 3 3331 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 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | S-Type=9| Sub-Length = N | Identification #1 (bits 0-15) | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | Identification #1 (bits 15-31)| Bitmap #1 (bits 0 - 15) | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | Bitmap #1 (bits 16 - 47) | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | Bitmap #1 (bits 48 - 63) | Identification #2 (bits 0-15) | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | Identification #2 (bits 15-31)| Bitmap #2 (bits 0 - 15) | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Bitmap #2 (bits 16 - 47) | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | Bitmap #2 (bits 48 - 63) | Identification #3 (bits 0-15) | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Identification #3 (bits 15-31)| Bitmap #3 (bits 0 - 15) | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 | Bitmap #3 (bits 16 - 47) | 3350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 | Bitmap #3 (bits 48 - 63) | ... | 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... + 3353 | ... | 3354 + ... + 3356 Figure 22: Fragmentation Report (FRAGREP) 3358 o Sub-Type is set to 9. If multiple instances appear in OMNI 3359 options of the same message all are processed. 3361 o Sub-Length is set to N, i.e., the length of the option in octets 3362 beginning immediately following the Sub-Length field and extending 3363 to the end of the sub-option. If N is not an integral multiple of 3364 12 octets, the sub-option is ignored. The length of the entire 3365 sub-option should not cause the entire IPv6 ND message to exceed 3366 the minimum IPv6 MTU. 3368 o Identification (i) includes the IPv6 Identification value found in 3369 the Fragment Header of a received OAL fragment. (Only those 3370 Identification values included represent fragments for which loss 3371 was unambiguously observed; any Identification values not included 3372 correspond to fragments that were either received in their 3373 entirety or may still be in transit.) 3375 o Bitmap (i) includes an ordinal checklist of fragments, with each 3376 bit set to 1 for a fragment received or 0 for a fragment missing. 3377 (Up to 64 ordinal numbered fragments for each packet may be 3378 recoded.) For example, for a 20-fragment OAL packet with ordinal 3379 fragments #3, #10, #13 and #17 missing and all other fragments 3380 received, Bitmap (i) encodes the following: 3382 0 1 2 3383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3385 |1|1|1|0|1|1|1|1|1|1|0|1|1|0|1|1|1|0|1|1|0|0|0|... 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3388 Figure 23 3390 (Note that loss of an OAL atomic fragment is indicated by a 3391 Bitmap(i) with all bits set to 0.) 3393 12.2.11. Node Identification 3395 0 1 2 3 3396 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 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3398 |S-Type=10| Sub-length=N | ID-Type | ~ 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 3400 ~ Node Identification Value (N-1 octets) ~ 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3403 Figure 24: Node Identification 3405 o Sub-Type is set to 10. If multiple instances appear in OMNI 3406 options of the same IPv6 ND message the first instance of a 3407 specific ID-Type is processed and all other instances of the same 3408 ID-Type are ignored. (It is therefore possible for a single IPv6 3409 ND message to convey multiple distinct Node Identifications - each 3410 with a different ID-Type.) 3412 o Sub-Length is set to N that encodes the number of Sub-Option Data 3413 octets that follow. The ID-Type field is always present; hence, 3414 the maximum Node Identification Value length is limited by the 3415 remaining available space in this OMNI option. 3417 o ID-Type is a 1 octet field that encodes the type of the Node 3418 Identification Value. The following ID-Type values are currently 3419 defined: 3421 * 0 - Universally Unique IDentifier (UUID) [RFC4122]. Indicates 3422 that Node Identification Value contains a 16 octet UUID. 3424 * 1 - Host Identity Tag (HIT) [RFC7401]. Indicates that Node 3425 Identification Value contains a 16 octet HIT. 3427 * 2 - Hierarchical HIT (HHIT) [I-D.ietf-drip-rid]. Indicates 3428 that Node Identification Value contains a 16 octet HHIT. 3430 * 3 - Network Access Identifier (NAI) [RFC7542]. Indicates that 3431 Node Identification Value contains an N-1 octet NAI. 3433 * 4 - Fully-Qualified Domain Name (FQDN) [RFC1035]. Indicates 3434 that Node Identification Value contains an N-1 octet FQDN. 3436 * 5 - IPv6 Address. Indicates that Node Identification contains 3437 a 16-octet IPv6 address that is not a (H)HIT. The IPv6 address 3438 type is determined according to the IPv6 addressing 3439 architecture [RFC4291]. 3441 * 6 - 252 - Unassigned. 3443 * 253-254 - Reserved for experimentation, as recommended in 3444 [RFC3692]. 3446 * 255 - reserved by IANA. 3448 o Node Identification Value is an (N - 1) octet field encoded 3449 according to the appropriate the "ID-Type" reference above. 3451 OMNI interfaces code Node Identification Values used for DHCPv6 3452 messaging purposes as a DHCP Unique IDentifier (DUID) using the 3453 "DUID-EN for OMNI" format with enterprise number 45282 (see: 3454 Section 25) as shown in Figure 25: 3456 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 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 | DUID-Type (2) | EN (high bits == 0) | 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3460 | EN (low bits = 45282) | ID-Type | | 3461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3462 . Node Identification Value . 3463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 Figure 25: DUID-EN for OMNI Format 3467 In this format, the OMNI interface codes the ID-Type and Node 3468 Identification Value fields from the OMNI sub-option following a 6 3469 octet DUID-EN header, then includes the entire "DUID-EN for OMNI" in 3470 a DHCPv6 message per [RFC8415]. 3472 12.2.12. ICMPv6 Error 3474 0 1 2 3 3475 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 3476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3477 |S-Type=11| Sub-length=N | Type | Code | 3478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 | | 3480 + Message Body + 3481 | | 3482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3484 Figure 26: ICMPv6 Error 3486 o Sub-Type is set to 11. If multiple instances appear in OMNI 3487 options of the same IPv6 ND message all are processed. 3489 o Sub-Length is set to N that encodes the number of Sub-Option Data 3490 octets that follow. 3492 o Sub-Option Data includes a one octet Type followed by a one octet 3493 Code followed by an (N-2)-octet Message Body encoded exactly as 3494 per Section 2.1 of [RFC4443]. OMNI interfaces include as much of 3495 the ICMPv6 error message body in the sub-option as possible 3496 without causing the entire IPv6 ND message to exceed the minimum 3497 IPv6 MTU. While all ICMPv6 error message types are supported, OAL 3498 destinations in particular may include ICMPv6 PTB messages in uNA 3499 messages to provide MTU feedback information via the OAL source 3500 (see: Section 6.8). Note: ICMPv6 informational messages must not 3501 be included and must be ignored if received. 3503 12.2.13. QUIC-TLS Message 3505 0 1 2 3 3506 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 3507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3508 |S-Type=12| Sub-length=N | ~ 3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ 3510 ~ QUIC-TLS Message ~ 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3513 Figure 27: QUIC-TLS Message 3515 o Sub-Type is set to 12. If multiple instances appear in OMNI 3516 options of the same IPv6 ND message, the first is processed and 3517 all others are ignored. 3519 o Sub-Length is set to N that encodes the number of Sub-Option Data 3520 octets that follow. 3522 o The QUIC-TLS message [RFC9000][RFC9001][RFC9002] encodes the QUIC 3523 and TLS message parameters necessary to support QUIC connection 3524 establishment. 3526 When present, the QUIC-TLS Message sub-option MUST appear immediately 3527 after the header of the first OMNI option in the IPv6 ND message; if 3528 the sub-option appears in any other location it MUST be ignored. 3529 IPv6 ND solicitation and advertisement messages serve as couriers to 3530 transport the QUIC and TLS parameters necessary to establish a 3531 secured QUIC connection. 3533 12.2.14. Proxy/Server Departure 3535 OMNI Clients include a Proxy/Server Departure sub-option in RS 3536 messages when they associate with a new FHS and/or Hub Proxy/Server 3537 and need to send a departure indication to an old FHS and/or Hub 3538 Proxy/Server. The Proxy/Server Departure sub-option is formatted as 3539 shown below: 3541 0 1 2 3 3542 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 3543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3544 |S-Type=13| Sub-length=8 |Old FHS Proxy/Server MSID (0-1)| 3545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3546 |Old FHS Proxy/Server MSID (2-3)|Old Hub Proxy/Server MSID (0-1)| 3547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3548 |Old Hub Proxy/Server MSID (2-3)| 3549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3551 Figure 28: Proxy/Server Departure 3553 o Sub-Type is set to 13. 3555 o Sub-Length is set to 8. 3557 o Sub-Option Data contains the 4-octet MSID for the "Old FHS Proxy/ 3558 Server" followed by a 4-octet MSID for an "Old Hub Proxy/Server. 3559 (If the Old FHS/Hub is unspecified, the corresponding MSID instead 3560 includes the value 0.) 3562 12.2.15. OMNI Header Extension 3564 IPv6 ND messages used for Prefix Length assertion, service 3565 coordination and/or Window Synchronization include an OMNI Header 3566 Extension sub-option. If an OMNI Header Extension sub-option is 3567 included, it must appear immediately after the authentication sub- 3568 option if present; otherwise, as the first (non-padding) sub-option 3569 of the first OMNI option. If multiple OMNI Header Extension sub- 3570 options are included (whether in a single OMNI option or multiple), 3571 only the first is processed and all others are ignored. 3573 The OMNI Header Extension sub-option is formatted as follows: 3575 0 1 2 3 3576 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 3577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3578 |S-Type=14| Sub-length=14 | Preflen |N|A|U| Reservd | 3579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3580 | Sequence Number | 3581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3582 | Acknowledgment Number | 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3584 |S|A|R|O|P| | | 3585 |Y|C|S|P|N| Res | Window | 3586 |N|K|T|T|G| | | 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3589 Figure 29: OMNI Header Extension 3591 o Sub-Type is set to 14. 3593 o Sub-Length is set to 14. 3595 o The first two octets of Sub-Option Data contains a 1-octet Prefix 3596 Length followed by a 1-octet flags field interpreted as follows: 3598 * Preflen is an 8 bit field that determines the length of prefix 3599 associated with an LLA. Values 0 through 128 specify a valid 3600 prefix length (if any other value appears the OMNI option must 3601 be ignored). For IPv6 ND messages sent from a Client to the 3602 MS, Preflen applies to the IPv6 source LLA and provides the 3603 length that the Client is requesting from or asserting to the 3604 MS. For IPv6 ND messages sent from the MS to the Client, 3605 Preflen applies to the IPv6 destination LLA and indicates the 3606 length that the MS is granting to the Client. For IPv6 ND 3607 messages sent between MS endpoints, Preflen provides the length 3608 associated with the source/target Client MNP that is subject of 3609 the ND message. When an IPv6 ND RS/RA message sets Preflen to 3610 0, the recipient regards the message as a prefix release 3611 indication. 3613 * The N/A/U flags are set or cleared in Client RS messages as 3614 directives to FHS and Hub Proxy/Servers and ignored in all 3615 other IPv6 ND messages. When an FHS Proxy/Server forwards or 3616 processes an RS with the N flag set, it responds directly to NS 3617 Neighbor Unreachability Detection (NUD) messages by returning 3618 NA(NUD) replies; otherwise, it forwards NS(NUD) messages to the 3619 Client. When the Hub Proxy/Server receives an RS with the A 3620 flag set, it responds directly to NS Address Resolution (AR) 3621 messages by returning NA(AR) replies; otherwise, it forwards 3622 NS(AR) messages to the Client. When the Hub Proxy/Server 3623 receives an RS with the U flag set, it maintains a Report List 3624 of recent NS(AR) message sources for this Client and sends uNA 3625 messages to all list members if any aspects of the Client's 3626 underlying interfaces change. Proxy/Servers function according 3627 to the N/A/U flag settings received in the most recent RS 3628 message to support dynamic Client updates. In all IPv6 ND 3629 messages, the remaining 5 flag bits are set to 0 on 3630 transmission and ignored on reception. 3632 o The remainder of Sub-Option Data contains a 4-octet Sequence 3633 Number, followed by a 4-octet Acknowledgement Number, followed by 3634 a 1-octet flags field followed by a 3-octet Window size modeled 3635 from the Transmission Control Protocol (TCP) header specified in 3636 Section 3.1 of [RFC0793]. The (SYN, ACK, RST) flags are used for 3637 TCP-like window synchronization, while the TCP (URG, PSH, FIN) 3638 flags are not used and therefore omitted. The (OPT, PNG) flags 3639 are OMNI-specific, and the remaining flags are Reserved. 3640 Together, these fields support the asymmetric and symmetric OAL 3641 window synchronization services specified in Section 6.6. 3643 12.2.16. Sub-Type Extension 3645 Since the Sub-Type field is only 5 bits in length, future 3646 specifications of major protocol functions may exhaust the remaining 3647 Sub-Type values available for assignment. This document therefore 3648 defines Sub-Type 30 as an "extension", meaning that the actual Sub- 3649 Option type is determined by examining a 1 octet "Extension-Type" 3650 field immediately following the Sub-Length field. The Sub-Type 3651 Extension is formatted as shown in Figure 30: 3653 0 1 2 3 3654 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 3655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 |S-Type=30| Sub-length=N | Extension-Type| ~ 3657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 3658 ~ ~ 3659 ~ Extension-Type Body ~ 3660 ~ ~ 3661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3663 Figure 30: Sub-Type Extension 3665 o Sub-Type is set to 30. If multiple instances appear in OMNI 3666 options of the same message all are processed, where each 3667 individual extension defines its own policy for processing 3668 multiple of that type. 3670 o Sub-Length is set to N that encodes the number of Sub-Option Data 3671 octets that follow. The Extension-Type field is always present, 3672 and the maximum Extension-Type Body length is limited by the 3673 remaining available space in this OMNI option. 3675 o Extension-Type contains a 1 octet Sub-Type Extension value between 3676 0 and 255. 3678 o Extension-Type Body contains an N-1 octet block with format 3679 defined by the given extension specification. 3681 Extension-Type values 0 and 1 are defined in the following 3682 subsections, while Extension-Type values 2 through 252 are available 3683 for assignment by future specifications which must also define the 3684 format of the Extension-Type Body and its processing rules. 3685 Extension-Type values 253 and 254 are reserved for experimentation, 3686 as recommended in [RFC3692], and value 255 is reserved by IANA. 3688 12.2.16.1. RFC4380 Header Extension Option 3690 0 1 2 3 3691 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 3692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3693 |S-Type=30| Sub-length=N | Ext-Type=0 | Header Type | 3694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3695 ~ Header Option Value ~ 3696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3698 Figure 31: RFC4380 Header Extension Option (Extension-Type 0) 3700 o Sub-Type is set to 30. 3702 o Sub-Length is set to N that encodes the number of Sub-Option Data 3703 octets that follow. The Extension-Type and Header Type fields are 3704 always present, and the Header Option Value is limited by the 3705 remaining available space in this OMNI option. 3707 o Extension-Type is set to 0. Each instance encodes exactly one 3708 header option per Section 5.1.1 of [RFC4380], with Ext-Type and 3709 Header Type representing the first two octets of the option. If 3710 multiple instances of the same Header Type appear in OMNI options 3711 of the same message the first instance is processed and all others 3712 are ignored. If Header Type indicates an Authentication 3713 Encapsulation (see below), the entire sub-option MUST appear as 3714 the first sub-option of the first OMNI option, which MUST appear 3715 immediately following the IPv6 ND message header. 3717 o Header Type and Header Option Value are coded exactly as specified 3718 in Section 5.1.1 of [RFC4380]; the following types are currently 3719 defined: 3721 * 0 - Origin Indication (IPv4) - value coded as a UDP port number 3722 followed by a 4-octet IPv4 address both in "obfuscated" form 3723 per Section 5.1.1 of [RFC4380]. 3725 * 1 - Authentication Encapsulation - value coded per 3726 Section 5.1.1 of [RFC4380]. 3728 * 2 - Origin Indication (IPv6) - value coded per Section 5.1.1 of 3729 [RFC4380], except that the address is a 16-octet IPv6 address 3730 instead of a 4-octet IPv4 address. 3732 o Header Type values 3 through 252 are available for assignment by 3733 future specifications, which must also define the format of the 3734 Header Option Value and its processing rules. Header Type values 3735 253 and 254 are reserved for experimentation, as recommended in 3736 [RFC3692], and value 255 is Reserved by IANA. 3738 12.2.16.2. RFC6081 Trailer Extension Option 3740 0 1 2 3 3741 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 3742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3743 |S-Type=30| Sub-length=N | Ext-Type=1 | Trailer Type | 3744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3745 ~ Trailer Option Value ~ 3746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3748 Figure 32: RFC6081 Trailer Extension Option (Extension-Type 1) 3750 o Sub-Type is set to 30. 3752 o Sub-Length is set to N that encodes the number of Sub-Option Data 3753 octets that follow. The Extension-Type and Trailer Type fields 3754 are always present, and the maximum-length Trailer Option Value is 3755 limited by the remaining available space in this OMNI option. 3757 o Extension-Type is set to 1. Each instance encodes exactly one 3758 trailer option per Section 4 of [RFC6081]. If multiple instances 3759 of the same Trailer Type appear in OMNI options of the same 3760 message the first instance is processed and all others ignored. 3762 o Trailer Type and Trailer Option Value are coded exactly as 3763 specified in Section 4 of [RFC6081]; the following Trailer Types 3764 are currently defined: 3766 * 0 - Unassigned 3768 * 1 - Nonce Trailer - value coded per Section 4.2 of [RFC6081]. 3770 * 2 - Unassigned 3772 * 3 - Alternate Address Trailer (IPv4) - value coded per 3773 Section 4.3 of [RFC6081]. 3775 * 4 - Neighbor Discovery Option Trailer - value coded per 3776 Section 4.4 of [RFC6081]. 3778 * 5 - Random Port Trailer - value coded per Section 4.5 of 3779 [RFC6081]. 3781 * 6 - Alternate Address Trailer (IPv6) - value coded per 3782 Section 4.3 of [RFC6081], except that each address is a 3783 16-octet IPv6 address instead of a 4-octet IPv4 address. 3785 o Trailer Type values 7 through 252 are available for assignment by 3786 future specifications, which must also define the format of the 3787 Trailer Option Value and its processing rules. Trailer Type 3788 values 253 and 254 are reserved for experimentation, as 3789 recommended in [RFC3692], and value 255 is Reserved by IANA. 3791 13. Address Mapping - Multicast 3793 The multicast address mapping of the native underlying interface 3794 applies. The Client mobile router also serves as an IGMP/MLD Proxy 3795 for its EUNs and/or hosted applications per [RFC4605]. 3797 The Client uses Multicast Listener Discovery (MLDv2) [RFC3810] to 3798 coordinate with Proxy/Servers, and *NET L2 elements use MLD snooping 3799 [RFC4541]. The Client can also employ multicast routing protocols to 3800 coordinate with network-based multicast sources as specified in 3801 [I-D.templin-6man-aero]. 3803 Since the OMNI link model is NBMA, OMNI links support link-scoped 3804 multicast through iterative unicast transmissions to individual 3805 multicast group members (i.e., unicast/multicast emulation). 3807 14. Multilink Conceptual Sending Algorithm 3809 The Client's IPv6 layer selects the outbound OMNI interface according 3810 to SBM considerations when forwarding original IP packets from local 3811 or EUN applications to external correspondents. Each OMNI interface 3812 maintains a neighbor cache the same as for any IPv6 interface, but 3813 includes additional state for multilink coordination. Each Client 3814 OMNI interface maintains default routes via Proxy/Servers discovered 3815 as discussed in Section 15, and may configure more-specific routes 3816 discovered through means outside the scope of this specification. 3818 For each original IP packet it forwards, the OMNI interface selects 3819 one or more source underlying interfaces based on PBM factors (e.g., 3820 traffic attributes, cost, performance, message size, etc.) and one or 3821 more target underlying interfaces for the neighbor based on Interface 3822 Attributes received in IPv6 ND messages (see: Section 12.2.3). 3823 Multilink forwarding may also direct packet replication across 3824 multiple underlying interface pairs for increased reliability at the 3825 expense of duplication. The set of all Interface Attributes and 3826 Traffic Selectors received in IPv6 ND messages determines the 3827 multilink forwarding profile for selecting target underlying 3828 interfaces. 3830 When the OMNI interface sends an original IP packet over a selected 3831 source underlying interface, it first employs OAL encapsulation and 3832 fragmentation as discussed in Section 5, then performs *NET 3833 encapsulation as directed by the appropriate MFV. The OMNI interface 3834 also performs *NET encapsulation (following OAL encapsulation) when 3835 the nearest Proxy/Server is located multiple hops away as discussed 3836 in Section 15.2. 3838 OMNI interface multilink service designers MUST observe the BCP 3839 guidance in Section 15 [RFC3819] in terms of implications for 3840 reordering when original IP packets from the same flow may be spread 3841 across multiple underlying interfaces having diverse properties. 3843 14.1. Multiple OMNI Interfaces 3845 Clients may connect to multiple independent OMNI links within the 3846 same or different OMNI domains to support SBM. The Client configures 3847 a separate OMNI interface for each link so that multiple interfaces 3848 (e.g., omni0, omni1, omni2, etc.) are exposed to the IP layer. Each 3849 OMNI interface configures one or more OMNI anycast addresses (see: 3850 Section 10), and the Client injects the corresponding anycast 3851 prefixes into the EUN routing system. Multiple distinct OMNI links 3852 can therefore be used to support fault tolerance, load balancing, 3853 reliability, etc. 3855 Applications in EUNs can use Segment Routing to select the desired 3856 OMNI interface based on SBM considerations. The application writes 3857 an OMNI anycast address into the original IP packet's destination 3858 address, and writes the actual destination (along with any additional 3859 intermediate hops) into the Segment Routing Header. Standard IP 3860 routing directs the packet to the Client's mobile router entity, 3861 where the anycast address identifies the correct OMNI interface for 3862 next hop forwarding. When the Client receives the packet, it 3863 replaces the IP destination address with the next hop found in the 3864 Segment Routing Header and forwards the message via the OMNI 3865 interface identified by the anycast address. 3867 14.2. Client-Proxy/Server Loop Prevention 3869 After a Proxy/Server has registered an MNP for a Client (see: 3870 Section 15), the Proxy/Server will forward all packets destined to an 3871 address within the MNP to the Client. The Client will under normal 3872 circumstances then forward the packet to the correct destination 3873 within its internal networks. 3875 If at some later time the Client loses state (e.g., after a reboot), 3876 it may begin returning packets with destinations corresponding to its 3877 MNP to the Proxy/Server as its default router. The Proxy/Server 3878 therefore drops any original IP packets received from the Client with 3879 a destination address that corresponds to the Client's MNP (i.e., 3880 whether LLA, ULA or GUA), and drops any carrier packets with both 3881 source and destination address corresponding to the same Client's MNP 3882 regardless of their origin. 3884 15. Router Discovery and Prefix Registration 3886 Clients engage the MS by sending RS messages with OMNI options under 3887 the assumption that one or more Proxy/Server will process the message 3888 and respond. The RS message is received by a FHS Proxy/Server, which 3889 may in turn forward a proxyed copy of the RS to a Hub Proxy/Server 3890 located on the same or different SRT segment. The Hub Proxy/Server 3891 then returns an RA message either directly to the Client or via an 3892 FHS Proxy/Server acting as a proxy. 3894 Clients and FHS Proxy/Servers include an authentication signature in 3895 their RS/RA exchanges when necessary; otherwise, they calculate and 3896 include a valid IPv6 ND message checksum (see: Section 12 and 3897 Appendix B). FHS and Hub Proxy/Server RS/RA message exchanges over 3898 the SRT secured spanning tree instead always include the checksum and 3899 omit the authentication signature. Clients and Proxy/Servers use the 3900 information included in RS/RA messages to establish NCE state and 3901 OMNI link autoconfiguration information as discussed in this section. 3903 For each underlying interface, the Client sends RS messages with OMNI 3904 options to coordinate with a (potentially different) FHS Proxy/Server 3905 for each interface and a single Hub Proxy/Server. All Proxy/Servers 3906 are identified by their MSIDs and accept carrier packets addressed to 3907 their anycast/unicast *NET INADDRs; the Hub Proxy/Server may be 3908 chosen among any of the Client's FHS Proxy/Servers or may be any 3909 other Proxy/Server for the OMNI link. Example MSID/INADDR discovery 3910 methods are given in [RFC5214] and include data link login 3911 parameters, name service lookups, static configuration, a static 3912 "hosts" file, etc. In the absence of other information, the Client 3913 can resolve the DNS Fully-Qualified Domain Name (FQDN) 3914 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 3915 text string and "[domainname]" is a DNS suffix for the OMNI link 3916 (e.g., "example.com"). 3918 Clients configure OMNI interfaces that observe the properties 3919 discussed in previous sections. The OMNI interface and its 3920 underlying interfaces are said to be in either the "UP" or "DOWN" 3921 state according to administrative actions in conjunction with the 3922 interface connectivity status. An OMNI interface transitions to UP 3923 or DOWN through administrative action and/or through state 3924 transitions of the underlying interfaces. When a first underlying 3925 interface transitions to UP, the OMNI interface also transitions to 3926 UP. When all underlying interfaces transition to DOWN, the OMNI 3927 interface also transitions to DOWN. 3929 When a Client OMNI interface transitions to UP, it sends RS messages 3930 to register its MNP and an initial set of underlying interfaces that 3931 are also UP. The Client sends additional RS messages to refresh 3932 lifetimes and to register/deregister underlying interfaces as they 3933 transition to UP or DOWN. The Client's OMNI interface sends initial 3934 RS messages over an UP underlying interface with its MNP-LLA as the 3935 source (or with the unspecified address (::) as the source if it does 3936 not yet have an MNP-LLA) and with destination set to link-scoped All- 3937 Routers multicast or the ADM-LLA of a specific Proxy/Server. The 3938 OMNI interface includes an OMNI option per Section 12 with an OMNI 3939 header extension with Preflen assertion, N/A/U flags, an Interface 3940 Attributes sub-option for the underlying interface and with any other 3941 necessary OMNI sub-options such as authentication, Proxy/Server 3942 Departure, Reassembly Limits, etc. 3944 The Client then calculates the authentication signature or checksum 3945 and prepares to forward the RS over the underlying interface using 3946 OAL encapsulation and fragmentation if necessary. If the Client uses 3947 OAL encapsulation for RS messages sent to an unsynchronized FHS 3948 Proxy/Server over an INET interface, the entire RS message must fit 3949 within a single carrier packet (i.e., an atomic fragment) so that the 3950 FHS Proxy/Server can verify the authentication signature without 3951 having to reassemble. The OMNI interface selects an Identification 3952 value (see: Section 6.6), sets the OAL source address to the ULA 3953 corresponding to the RS source (or a Temporary ULA or (H)HIT if the 3954 RS source is the unspecified address (::)), sets the OAL destination 3955 to an OMNI IPv6 anycast or ADM-ULA unicast address then performs 3956 fragmentation if necessary. When *NET encapsulation is used, the 3957 Client includes the discovered FHS Proxy/Server INADDR or an anycast 3958 address as the *NET destination then forwards the resulting carrier 3959 packet(s) into the *NET. 3961 When an FHS Proxy/Server receives the carrier packets containing an 3962 RS it sets aside the *NET headers, verifies the Identifications and 3963 reassembles if necessary, sets aside the OAL header, then verifies 3964 the RS authentication signature or checksum. The FHS Proxy/Server 3965 then caches the OMNI Window Synchronization parameters, Interface 3966 Attributes and any Traffic Selector sub-options in a NCE for the 3967 Client while also caching the *NET (UDP/IP) and OAL (ULA) source and 3968 destination address information. The FHS Proxy/Server next caches 3969 the OMNI option N flag to determine its role in processing NS(NUD) 3970 messages (see: Section 12.1) then examines the RS destination 3971 address. If the destination matches its own ADM-LLA, the FHS Proxy/ 3972 Server assumes the Hub role and acts as the sole entry point for 3973 injecting the Client's MNP into the MS routing system (i.e., after 3974 performing any necessary MNP prefix delegation operations) according 3975 to the RS source address and OMNI option Prefix Length. The FHS/Hub 3976 Proxy/Server then caches the OMNI option A/U flags to determine its 3977 role in processing NS(AR) messages and generating uNA messages (see: 3978 Section 12.1). 3980 The FHS/Hub Proxy/Server then prepares to return an RA message 3981 directly to the Client by first populating the Cur Hop Limit, Flags, 3982 Router Lifetime, Reachable Time and Retrans Timer fields with values 3983 appropriate for the OMNI link. The FHS/Hub Proxy/Server next 3984 includes as the first RA message option an OMNI option with Window 3985 Synchronization information, an authentication sub-option if 3986 necessary and a (proxyed) copy of the Client's original Interface 3987 Attributes sub-option with its INET-facing interface information 3988 written in the FMT/SRT and LHS Proxy/Server MSID/INADDR fields. If 3989 the RS *NET destination IP address was anycast, the FHS/Hub Proxy/ 3990 Server next includes a second Interface Attributes sub-option with 3991 omIndex set to '0' and with a unicast *NET IP address for its Client- 3992 facing interface in the INADDR field. 3994 The FHS/Hub Proxy/Server next includes an Origin Indication sub- 3995 option that includes the RS *NET source INADDR information (see: 3996 Section 12.2.16.1), then includes any other necessary OMNI sub- 3997 options (either within the same OMNI option or in additional OMNI 3998 options). Following the OMNI option(s), the FHS/Hub Proxy/Server 3999 next includes any other necessary RA options such as PIOs with (A; 4000 L=0) that include the OMNI link MSPs [RFC8028], RIOs [RFC4191] with 4001 more-specific routes, Nonce and Timestamp options, etc. The FHS/Hub 4002 Proxy/Server then sets the RA source address to its own ADM-LLA and 4003 destination address to the Client's MNP-LLA, then calculates the 4004 authentication signature or checksum. The FHS/Hub Proxy/Server 4005 finally performs OAL encapsulation with source set to its own ADM-ULA 4006 and destination set to the OAL source that appeared in the RS, then 4007 fragments if necessary, encapsulates each fragment in appropriate 4008 *NET headers with source and destination address information reversed 4009 from the RS *NET information and returns the resulting carrier 4010 packets to the Client over the same underlying interface the RS 4011 arrived on. 4013 When an FHS Proxy/Server receives an RS with a valid authentication 4014 signature or checksum and with destination set to link-scoped All- 4015 Routers multicast, it can either assume the Hub role the same as 4016 above or act as a proxy and select the ADM-LLA of another Proxy/ 4017 Server to serve as the Hub. When an FHS Proxy/Server assumes the 4018 proxy role or receives an RS with destination set to the ADM-LLA of 4019 another Proxy/Server, it proxys the message. The FHS Proxy/Server 4020 caches the Client's Window Synchronization, N flag, Interface 4021 Attributes and *NET/OAL address information as above then writes its 4022 own INET-facing FMT/SRT and LHS Proxy/Server MSID/INADDR information 4023 into the appropriate Interface Attributes sub-option fields. The FHS 4024 Proxy/Server then calculates and includes the checksum, performs OAL 4025 encapsulation with source set to its own ADM-ULA and destination set 4026 to the ADM-ULA of the Hub Proxy/Server, fragments if necessary, 4027 encapsulates each fragment in appropriate *NET headers and sends the 4028 resulting carrier packets into the SRT secured spanning tree. 4030 When the Hub Proxy/Server receives the carrier packets, it discards 4031 the *NET headers, reassembles if necessary to obtain the proxyed RS 4032 (i.e., one with an ADM-ULA source address) then caches any state 4033 (including the A/U flags, OAL addresses, Interface Attributes 4034 information and Traffic Selectors) in a NCE for the Client and 4035 performs any necessary prefix delegation and routing protocol 4036 injection. The Hub Proxy/Server then returns an RA that echoes the 4037 Client's (proxyed) Interface Attributes sub-option and with any RA 4038 parameters the same as specified above. The Hub Proxy/Server then 4039 sets the RA source address to its own ADM-LLA and destination address 4040 to the Client's MNP-LLA, calculates the checksum then encapsulates 4041 the RA as an OAL packet with source set to its own ADM-ULA and 4042 destination set to the ADM-ULA of the FHS Proxy/Server that sent the 4043 RS. The Hub Proxy/Server finally fragments if necessary, 4044 encapsulates each fragment in appropriate *NET headers and sends the 4045 resulting carrier packets into the secured spanning tree. 4047 When the FHS Proxy/Server receives the carrier packets it discards 4048 the *NET headers, reassembles to obtain the RA message, verifies the 4049 checksum then updates the OMNI interface NCEs for both the Hub and 4050 Client. The FHS Proxy/Server then proxies the RA by changing the OAL 4051 source to its own ADM-ULA and the OAL destination to the MNP-ULA or 4052 temporary ULA of the Client, then sets the P flag in the RA flags 4053 field [RFC4389]. The FHS Proxy/Server next includes Window 4054 Synchronization parameters responsive to those in the Client's RS, an 4055 Interface Attributes sub-option with omIndex '0' and with its unicast 4056 *NET IP address if necessary (see above), an Origin Indication sub- 4057 option with the Client's cached INADDR and an authentication sub- 4058 option if necessary. The FHS Proxy/Server finally selects an 4059 Identification value per Section 6.6, calculates the authentication 4060 signature or checksum, fragments if necessary, encapsulates each 4061 fragment in *NET headers with addresses taken from the Client's NCE 4062 and returns the resulting carrier packets via the same underlying 4063 interface over which the RS was received. 4065 When the Client receives the carrier packets, it discards the *NET 4066 headers, reassembles and removes the OAL header to obtain the RA 4067 message, verifies the authentication signature or checksum, then 4068 updates the OMNI interface NCEs for both the Hub and FHS Proxy/ 4069 Server. If the Client has multiple underlying interfaces, it creates 4070 additional FHS Proxy/Server NCEs as necessary when it receives RAs 4071 over those interfaces (noting that multiple of the Client's 4072 underlying interfaces may be serviced by the same FHS Proxy/Server). 4073 For each underlying interface, the Client caches the (filled-out) 4074 Interface Attributes for its own omIndex and Origin Indication 4075 information that it received in an RA message over that interface so 4076 that it can include them in future NS/NA messages to provide 4077 neighbors with accurate FMT/SRT/LHS information. (If the message 4078 includes an Interface Attributes sub-option with omIndex '0', the 4079 Client also caches the INADDR as the *NET-local unicast address of 4080 the FHS Proxy//Server via that underlying interface.) The Client 4081 then compares the Origin Indication INADDR information with its own 4082 underlying interface addresses to determine whether there may be NATs 4083 on the path to the FHS Proxy/Server; if the INADDR information 4084 differs, the Client is behind a NAT and must supply the Origin 4085 information in IPv6 ND message exchanges with prospective neighbors 4086 on the same SRT segment. The Client finally configures default 4087 routes and assigns the OMNI Subnet Router Anycast address 4088 corresponding to the MNP (e.g., 2001:db8:1:2::) to the OMNI 4089 interface. 4091 Following the initial exchange, the FHS Proxy/Server MAY later send 4092 additional periodic and/or event-driven unsolicited RA messages per 4093 [RFC4861]. (The unsolicited RAs may be initiated either by the FHS 4094 Proxy/Server itself or by the Hub via the FHS as a proxy.) The 4095 Client then continuously manages its underlying interfaces according 4096 to their states as follows: 4098 o When an underlying interface transitions to UP, the Client sends 4099 an RS over the underlying interface with an OMNI option with sub- 4100 options as specified above. 4102 o When an underlying interface transitions to DOWN, the Client sends 4103 unsolicited NA messages over any UP underlying interface with an 4104 OMNI option containing Interface Attributes sub-options for the 4105 DOWN underlying interface with Link set to '0'. The Client sends 4106 isolated unsolicited NAs when reliability is not thought to be a 4107 concern (e.g., if redundant transmissions are sent on multiple 4108 underlying interfaces), or may instead set the PNG flag in the 4109 OMNI header to trigger a uNA reply. 4111 o When the Router Lifetime for the Hub Proxy/Server nears 4112 expiration, the Client sends an RS over any underlying interface 4113 to receive a fresh RA from the Hub. If no RA messages are received 4114 over a first underlying interface (i.e., after retrying), the 4115 Client marks the underlying interface as DOWN and should attempt 4116 to contact the Hub Proxy/Server via a different underlying 4117 interface. If the Hub Proxy/Server is unresponsive over 4118 additional underlying interface, the Client selects a different 4119 FHS Proxy/Server and sends an RS message with destination set to 4120 the ADM-LLA of the FHS Proxy/Server which will then assume the Hub 4121 role. 4123 o When all of a Client's underlying interfaces have transitioned to 4124 DOWN (or if the prefix registration lifetime expires), the Hub 4125 Proxy/Server withdraws the MNP the same as if it had received a 4126 message with a release indication. 4128 The Client is responsible for retrying each RS exchange up to 4129 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 4130 seconds until an RA is received. If no RA is received over an UP 4131 underlying interface (i.e., even after attempting to contact 4132 alternate Proxy/Servers), the Client declares this underlying 4133 interface as DOWN. When changing to a new FHS or Hub Proxy/Server, 4134 the Client also includes a Proxy/Server Departure OMNI sub-option in 4135 new RS messages; the (new) FHS Proxy/Server will in turn send uNA 4136 messages to the old FHS and/or Hub Proxy/Server to announce the 4137 Client's departure as discussed in [I-D.templin-6man-aero]. 4139 The IPv6 layer sees the OMNI interface as an ordinary IPv6 interface. 4140 Therefore, when the IPv6 layer sends an RS message the OMNI interface 4141 returns an internally-generated RA message as though the message 4142 originated from an IPv6 router. The internally-generated RA message 4143 contains configuration information consistent with the information 4144 received from the RAs generated by the Hub Proxy/Server. Whether the 4145 OMNI interface IPv6 ND messaging process is initiated from the 4146 receipt of an RS message from the IPv6 layer or independently of the 4147 IPv6 layer is an implementation matter. Some implementations may 4148 elect to defer the OMNI interface internal RS/RA messaging process 4149 until an RS is received from the IPv6 layer, while others may elect 4150 to initiate the process proactively. Still other deployments may 4151 elect to administratively disable IPv6 layer RS/RA messaging over the 4152 OMNI interface, since the messages are not required to drive the OMNI 4153 interface internal RS/RA process. (Note that this same logic applies 4154 to IPv4 implementations that employ ICMP-based Router Discovery per 4155 [RFC1256].) 4157 Note: The Router Lifetime value in RA messages indicates the time 4158 before which the Client must send another RS message over this 4159 underlying interface (e.g., 600 seconds), however that timescale may 4160 be significantly longer than the lifetime the MS has committed to 4161 retain the prefix registration (e.g., REACHABLETIME seconds). Proxy/ 4162 Servers are therefore responsible for keeping MS state alive on a 4163 shorter timescale than the Client may be required to do on its own 4164 behalf. 4166 Note: On certain multicast-capable underlying interfaces, Clients 4167 should send periodic unsolicited multicast NA messages and Proxy/ 4168 Servers should send periodic unsolicited multicast RA messages as 4169 "beacons" that can be heard by other nodes on the link. If a node 4170 fails to receive a beacon after a timeout value specific to the link, 4171 it can initiate a unicast exchange to test reachability. 4173 Note: If a single FHS Proxy/Server services multiple of a Client's 4174 underlying interfaces, Window Synchronization will initially be 4175 repeated for the RS/RA exchange over each underlying interface, i.e., 4176 until the Client discovers the many-to-one relationship. 4178 Note: Although the Client's FHS Proxy/Server is a first-hop segment 4179 node from its own perspective, the Client stores the Proxy/Server's 4180 FMT/SRT/MSID/INADDR as last-hop segment (LHS) information. This 4181 allows both the Client and Hub Proxy/Server to supply the information 4182 to neighbors that will perceive it as LHS information on the return 4183 path to the Client. 4185 Note: The Hub Proxy/Server injects Client MNP-ULAs into the routing 4186 system by simply creating a route-to-interface forwarding table entry 4187 for the MNP-ULA via the OMNI interface. The dynamic routing protocol 4188 will notice the new entry and advertise the MNP-ULA to its peers. If 4189 the Hub receives additional RS messages, it need not re-create the 4190 MNP-ULA forwarding table entry (nor disturb the dynamic routing 4191 protocol) if an entry is already present. 4193 Note: If the Client's initial RS message includes an anycast *NET 4194 destination address, the FHS Proxy/Server returns the solicited RA 4195 using the same anycast address as the *NET source while including an 4196 Interface Attributes sub-option with omIndex '0' and its true unicast 4197 address in the INADDR. When the Client sends additional RS messages, 4198 it includes this FHS Proxy/Server unicast address as the *NET 4199 destination and the FHS Proxy/Server returns the solicited RA using 4200 the same unicast address as the *NET source. This will ensure that 4201 RS/RA exchanges are not impeded by any NATs on the path while 4202 avoiding long-term exposure of messages that use an anycast address 4203 as the source. 4205 Note: The Origin Indication sub-option is included only by the FHS 4206 Proxy/Server and not by the Hub (unless the Hub is also serving as an 4207 FHS). 4209 Note: Clients should set the N/A/U flags consistently in successive 4210 RS messages and only change those settings when an FHS/Hub Proxy/ 4211 Server service profile update is necessary. 4213 15.1. Window Synchronization 4215 In environments where Identification window synchronization is 4216 necessary, the RS/RA exchanges discussed above observe the principles 4217 specified in Section 6.6. Window synchronization is conducted 4218 between the Client and each FHS Proxy/Server used to contact the Hub 4219 Proxy/Server, i.e., and not between the Client and the Hub. This is 4220 due to the fact that the Hub Proxy/Server is responsible only for 4221 forwarding all control and data messages via the secured spanning 4222 tree to FHS Proxy/Servers, and is not responsible for forwarding 4223 messages directly to the Client under a synchronized window. Also, 4224 in the reverse direction the FHS Proxy/Servers handle all default 4225 forwarding actions without forwarding Client-initiated data to the 4226 Hub. 4228 When a Client needs to perform window synchronization via a new FHS 4229 Proxy/Server, it sets the RS source address to its own MNP-LLA and 4230 destination address to the ADM-LLA of the Hub Proxy/Server, then sets 4231 the SYN flag and includes an initial Sequence Number for Window 4232 Synchronization. The Client then performs OAL encapsulation using 4233 its own MNP-ULA as the source and the ADM-ULA of the FHS Proxy/Server 4234 as the destination and includes an Interface Attributes sub-option 4235 then forwards the resulting carrier packets to the FHS Proxy/Server. 4236 The FHS Proxy/Server then extracts the RS message and caches the 4237 Window Synchronization parameters then re-encapsulates with its own 4238 ADM-ULA as the source and the ADM-ULA of the Hub Proxy/Server as the 4239 target. 4241 The FHS Proxy/Server then forwards the resulting carrier packets via 4242 the secured spanning tree to the Hub Proxy/Server, which updates the 4243 Client's Interface Attributes and returns a unicast RA message with 4244 source set to its own ADM-LLA and destination set to the Client's 4245 MNP-LLA and with the Client's Interface Attributes echoed. The Hub 4246 Proxy/Server then performs OAL encapsulation using its own ADM-ULA as 4247 the source and the ADM-ULA of the FHS Proxy/Server as the 4248 destination, then forwards the carrier packets via the secured 4249 spanning tree to the FHS Proxy/Server. The FHS Proxy/Server then re- 4250 encapsulates the message using its own ADM-ULA as the source, the 4251 MNP-ULA of the Client as the destination and includes responsive 4252 Window Synchronization information. The FHS Proxy/Server then 4253 forwards the message to the Client which updates its window 4254 synchronization information for the FHS Proxy/Server as necessary. 4256 Following the initial RS/RA-driven window synchronization, the Client 4257 can re-assert new windows with specific FHS Proxy/Servers by 4258 performing NS/NA exchanges between its own MNP-LLA and the ADM-LLAs 4259 of the FHS Proxy/Servers without having to disturb the Hub. 4261 15.2. Router Discovery in IP Multihop and IPv4-Only Networks 4263 On some *NETs, a Client may be located multiple IP hops away from the 4264 nearest OMNI link Proxy/Server. Forwarding through IP multihop *NETs 4265 is conducted through the application of a routing protocol (e.g., a 4266 MANET/VANET routing protocol over omni-directional wireless 4267 interfaces, an inter-domain routing protocol in an enterprise 4268 network, etc.). 4270 A Client located potentially multiple *NET hops away from the nearest 4271 Proxy/Server prepares an RS message, sets the source address to its 4272 MNP-LLA (or to the unspecified address (::) if it does not yet have 4273 an MNP-LLA), and sets the destination to link-scoped All-Routers 4274 multicast or a unicast ADM-LLA the same as discussed above. The OMNI 4275 interface then employs OAL encapsulation, sets the OAL source address 4276 to the ULA corresponding to the RS source (or to a Temporary ULA if 4277 the RS source was the unspecified address (::)) and sets the OAL 4278 destination to an OMNI IPv6 anycast address based on either a native 4279 IPv6 or IPv4-mapped IPv6 prefix (see: Section 10). 4281 For IPv6-enabled *NETs, if the underlying interface does not 4282 configure an IPv6 GUA the Client forwards the message without further 4283 encapsulation. Otherwise, the Client encapsulates the message in 4284 UDP/IPv6 *NET headers, sets the source to the underlying interface 4285 GUA and sets the destination to the same OMNI IPv6 anycast address. 4286 The Client then forwards the message into the IPv6 multihop routing 4287 system which conveys it to the nearest Proxy/Server that advertises a 4288 matching OMNI IPv6 anycast prefix. 4290 For IPv4-only *NETs, the Client encapsulates the RS message in UDP/ 4291 IPv4 *NET headers, sets the source to the underlying interface IPv4 4292 address and sets the destination to the IPv4 anycast address TBD3 4293 (see: IANA Considerations). The Client then forwards the message 4294 into the IPv4 multihop routing system which conveys it to the nearest 4295 Proxy/Server that advertises the corresponding IPv4 prefix. If the 4296 nearest Proxy/Server is too busy and/or does not configure the 4297 specified OMNI IPv6 anycast address, it should forward (without 4298 Proxying) the OAL-encapsulated RS to another nearby Proxy/Server 4299 connected to the same IPv4 (multihop) network that configures the 4300 OMNI IPv6 anycast address. (In environments where reciprocal RS 4301 forwarding cannot be supported, the first Proxy/Server should instead 4302 return an RA based on its own MSP(s).) 4304 When an intermediate *NET hop that participates in the routing 4305 protocol receives the encapsulated RS, it forwards the message 4306 according to its routing tables (note that an intermediate node could 4307 be a fixed infrastructure element or another MANET/VANET node). This 4308 process repeats iteratively until the RS message is received by a 4309 penultimate *NET hop within single-hop communications range of a 4310 Proxy/Server, which forwards the message to the Proxy/Server. 4312 When a Proxy/Server that configures the OMNI IPv6 anycast OAL 4313 destination receives the message, it decapsulates the RS and assumes 4314 either the Hub or FHS role (in which case, it forwards the RS to a 4315 candidate Hub). The Hub Proxy/Server then prepares an RA message 4316 with source address set to its own ADM-LLA and destination address 4317 set to the Client MNP-LLA. The Hub Proxy/Server then performs OAL 4318 encapsulation with the RA OAL source/destination set to the RS OAL 4319 destination/source and forwards the RA to the FHS Proxy/Server or 4320 directly to the Client. 4322 When the Hub or FHS Proxy/Server forwards the RA to the Client, it 4323 encapsulates the message in *NET encapsulation headers (if necessary) 4324 with (src, dst) set to the (dst,src) of the RS *NET encapsulation 4325 headers. The Proxy/Server then forwards the message to a *NET node 4326 within communications range, which forwards the message according to 4327 its routing tables to an intermediate node. The multihop forwarding 4328 process within the *NET continues repetitively until the message is 4329 delivered to the original Client, which decapsulates the message and 4330 performs autoconfiguration the same as if it had received the RA 4331 directly from a Proxy/Server on the same physical link. 4333 Note: When the RS message includes anycast OAL and/or *NET 4334 encapsulation destinations, the FHS Proxy/Server must use the same 4335 anycast addresses as the OAL and/or *NET encapsulation sources to 4336 support forwarding of the RA message and any initial data packets 4337 over any NATs on the path. When the Client receives the RA, it will 4338 discover the unicast OAL and/or IPv4 encapsulation addresses and can 4339 forward future packets using the unicast (instead of anycast) 4340 addresses to populate NAT state in the forward path. (If the Client 4341 does not have immediate data to send to the FHS Proxy/Server, it can 4342 instead send an OAL "bubble" - see Section 6.12.) After the Client 4343 begins using unicast OAL/*NET encapsulation addresses in this way, 4344 the FHS Proxy/Server should also begin using the same unicast 4345 addresses in the reverse direction. 4347 Note: As an alternate approach to multihop forwarding via IPv6 4348 encapsulation, the Client and Proxy/Server could statelessly 4349 translate the IPv6 LLAs into ULAs and forward the RS/RA messages 4350 without encapsulation. This would violate the [RFC4861] requirement 4351 that certain IPv6 ND messages must use link-local addresses and must 4352 not be accepted if received with Hop Limit less than 255. This 4353 document therefore mandates encapsulation since the overhead is 4354 nominal considering the infrequent nature and small size of IPv6 ND 4355 messages. Future documents may consider encapsulation avoidance 4356 through translation while updating [RFC4861]. 4358 Note: An alternate approach to multihop forwarding via IPv4 4359 encapsulation would be to employ IPv6/IPv4 protocol translation. 4360 However, for IPv6 ND messages the LLAs would be truncated due to 4361 translation and the OMNI Router and Prefix Discovery services would 4362 not be able to function. The use of IPv4 encapsulation is therefore 4363 indicated. 4365 15.3. DHCPv6-based Prefix Registration 4367 When a Client is not pre-provisioned with an MNP-LLA (or, when the 4368 Client requires additional MNP delegations), it requests the MS to 4369 select MNPs on its behalf and set up the correct routing state. The 4370 DHCPv6 service [RFC8415] supports this requirement. 4372 When a Client requires the MS to select MNPs, it sends an RS message 4373 with source set to the unspecified address (::) if it has no 4374 MNP_LLAs. If the Client requires only a single MNP delegation, it 4375 can then include a Node Identification sub-option in the OMNI option 4376 and set the OMNI extension header Preflen to the length of the 4377 desired MNP. If the Client requires multiple MNP delegations and/or 4378 more complex DHCPv6 services, it instead includes a DHCPv6 Message 4379 sub-option containing a Client Identifier, one or more IA_PD options 4380 and a Rapid Commit option then sets the 'msg-type' field to 4381 "Solicit", and includes a 3 octet 'transaction-id'. The Client then 4382 sets the RS destination to link-scoped All-Routers multicast and 4383 sends the message using OAL encapsulation and fragmentation if 4384 necessary as discussed above. 4386 When the Hub Proxy/Server receives the RS message, it performs OAL 4387 reassembly if necessary. Next, if the RS source is the unspecified 4388 address (::) and/or the OMNI option includes a DHCPv6 message sub- 4389 option, the Hub Proxy/Server acts as a "Proxy DHCPv6 Client" in a 4390 message exchange with the locally-resident DHCPv6 server. If the RS 4391 did not contain a DHCPv6 message sub-option, the Hub Proxy/Server 4392 generates a DHCPv6 Solicit message on behalf of the Client using an 4393 IA_PD option with the prefix length set to the OMNI extension header 4394 Preflen value and with a Client Identifier formed from the OMNI 4395 option Node Identification sub-option; otherwise, the Hub Proxy/ 4396 Server uses the DHCPv6 Solicit message contained in the OMNI option. 4397 The Hub Proxy/Server then sends the DHCPv6 message to the DHCPv6 4398 Server, which delegates MNPs and returns a DHCPv6 Reply message with 4399 PD parameters. (If the Hub Proxy/Server wishes to defer creation of 4400 Client state until the DHCPv6 Reply is received, it can instead act 4401 as a Lightweight DHCPv6 Relay Agent per [RFC6221] by encapsulating 4402 the DHCPv6 message in a Relay-forward/reply exchange with Relay 4403 Message and Interface ID options. In the process, the Hub Proxy/ 4404 Server packs any state information needed to return an RA to the 4405 Client in the Relay-forward Interface ID option so that the 4406 information will be echoed back in the Relay-reply.) 4408 When the Hub Proxy/Server receives the DHCPv6 Reply, it create OMNI 4409 interface MNP-ULA forwarding table entries (i.e., to prompt the 4410 dynamic routing protocol) and creates MNP-LLAs based on the delegated 4411 MNPs. The Hub Proxy/Server then sends an RA back to the Client with 4412 the DHCPv6 Reply message included in an OMNI DHCPv6 message sub- 4413 option if and only if the RS message had included an explicit DHCPv6 4414 Solicit. If the RS message source was the unspecified address (::), 4415 the Hub Proxy/Server includes one of the (newly-created) MNP-LLAs as 4416 the RA destination address and sets the OMNI extension header Preflen 4417 accordingly; otherwise, the Hub Proxy/Server includes the RS source 4418 address as the RA destination address. The Hub Proxy/Server then 4419 sets the RA source address to its own ADM-LLA, performs OAL 4420 encapsulation and fragmentation, performs *NET encapsulation and 4421 sends the RA to the Client (i.e., either directly or via an FHS 4422 Proxy/Server as discussed above). When the Client receives the RA, 4423 it reassembles and discards the OAL encapsulation, then creates a 4424 default route, assigns Subnet Router Anycast addresses and uses the 4425 RA destination address as its primary MNP-LLA. The Client will then 4426 use this primary MNP-LLA as the source address of any IPv6 ND 4427 messages it sends as long as it retains ownership of the MNP. 4429 16. Secure Redirection 4431 If the *NET link model is multiple access, the FHS Proxy/Server is 4432 responsible for assuring that address duplication cannot corrupt the 4433 neighbor caches of other nodes on the link. When the Client sends an 4434 RS message on a multiple access *NET link, the Proxy/Server verifies 4435 that the Client is authorized to use the address and responds with an 4436 RA (or forwards the RS to the Hub) only if the Client is authorized. 4438 After verifying Client authorization and returning an RA, the Proxy/ 4439 Server MAY return IPv6 ND Redirect messages to direct Clients located 4440 on the same *NET link to exchange packets directly without transiting 4441 the Proxy/Server. In that case, the Clients can exchange packets 4442 according to their unicast L2 addresses discovered from the Redirect 4443 message instead of using the dogleg path through the Proxy/Server. 4444 In some *NET links, however, such direct communications may be 4445 undesirable and continued use of the dogleg path through the Proxy/ 4446 Server may provide better performance. In that case, the Proxy/ 4447 Server can refrain from sending Redirects, and/or Clients can ignore 4448 them. 4450 17. Proxy/Server Resilience 4452 *NETs SHOULD deploy Proxy/Servers in Virtual Router Redundancy 4453 Protocol (VRRP) [RFC5798] configurations so that service continuity 4454 is maintained even if one or more Proxy/Servers fail. Using VRRP, 4455 the Client is unaware which of the (redundant) FHS Proxy/Servers is 4456 currently providing service, and any service discontinuity will be 4457 limited to the failover time supported by VRRP. Widely deployed 4458 public domain implementations of VRRP are available. 4460 Proxy/Servers SHOULD use high availability clustering services so 4461 that multiple redundant systems can provide coordinated response to 4462 failures. As with VRRP, widely deployed public domain 4463 implementations of high availability clustering services are 4464 available. Note that special-purpose and expensive dedicated 4465 hardware is not necessary, and public domain implementations can be 4466 used even between lightweight virtual machines in cloud deployments. 4468 18. Detecting and Responding to Proxy/Server Failures 4470 In environments where fast recovery from Proxy/Server failure is 4471 required, FHS Proxy/Servers SHOULD use proactive Neighbor 4472 Unreachability Detection (NUD) in a manner that parallels 4473 Bidirectional Forwarding Detection (BFD) [RFC5880] to track Hub 4474 Proxy/Server reachability. FHS Proxy/Servers can then quickly detect 4475 and react to failures so that cached information is re-established 4476 through alternate paths. Proactive NUD control messaging is carried 4477 only over well-connected ground domain networks (i.e., and not low- 4478 end *NET links such as aeronautical radios) and can therefore be 4479 tuned for rapid response. 4481 FHS Proxy/Servers perform proactive NUD for Hub Proxy/Servers for 4482 which there are currently active Clients on the *NET. If a Hub 4483 Proxy/Server fails, the FHS Proxy/Server can quickly inform Clients 4484 of the outage by sending multicast RA messages on the *NET interface. 4485 The FHS Proxy/Server sends RA messages to Clients via the *NET 4486 interface with source set to the ADM-LLA of the Hub, with destination 4487 address set to All-Nodes multicast (ff02::1) [RFC4291] and with 4488 Router Lifetime set to 0. 4490 The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA 4491 messages separated by small delays [RFC4861]. Any Clients on the 4492 *NET interface that have been using the (now defunct) Hub Proxy/ 4493 Server will receive the RA messages. 4495 19. Transition Considerations 4497 When a Client connects to an *NET link for the first time, it sends 4498 an RS message with an OMNI option. If the first hop router 4499 recognizes the option, it responds according to the appropriate FHS/ 4500 Hub Proxy/Server role resulting in an RA message with an OMNI option 4501 returned to the Client. The Client then engages this FHS Proxy/Sever 4502 according to the OMNI link model specified above. If the first hop 4503 router is a legacy IPv6 router, however, it instead returns an RA 4504 message with no OMNI option and with a non-OMNI unicast source LLA as 4505 specified in [RFC4861]. In that case, the Client engages the *NET 4506 according to the legacy IPv6 link model and without the OMNI 4507 extensions specified in this document. 4509 If the *NET link model is multiple access, there must be assurance 4510 that address duplication cannot corrupt the neighbor caches of other 4511 nodes on the link. When the Client sends an RS message on a multiple 4512 access *NET link with an LLA source address and an OMNI option, first 4513 hop routers that recognize the OMNI option ensure that the Client is 4514 authorized to use the address and return an RA with a non-zero Router 4515 Lifetime only if the Client is authorized. First hop routers that do 4516 not recognize the OMNI option instead return an RA that makes no 4517 statement about the Client's authorization to use the source address. 4518 In that case, the Client should perform Duplicate Address Detection 4519 to ensure that it does not interfere with other nodes on the link. 4521 An alternative approach for multiple access *NET links to ensure 4522 isolation for Client-Proxy/Server communications is through L2 4523 address mappings as discussed in Appendix D. This arrangement 4524 imparts a (virtual) point-to-point link model over the (physical) 4525 multiple access link. 4527 20. OMNI Interfaces on Open Internetworks 4529 Client OMNI interfaces configured over IPv6-enabled underlying 4530 interfaces on an open Internetwork without an OMNI-aware first-hop 4531 router receive IPv6 RA messages with no OMNI options, while OMNI 4532 interfaces configured over IPv4-only underlying interfaces receive no 4533 IPv6 RA messages at all (but may receive IPv4 RA messages [RFC1256]). 4535 Client OMNI interfaces that receive RA messages with OMNI options 4536 configure addresses, on-link prefixes, etc. on the underlying 4537 interface that received the RA according to standard IPv6 ND and 4538 address resolution conventions [RFC4861] [RFC4862]. Client OMNI 4539 interfaces configured over IPv4-only underlying interfaces configure 4540 IPv4 address information on the underlying interfaces using 4541 mechanisms such as DHCPv4 [RFC2131]. 4543 Client OMNI interfaces configured over underlying interfaces 4544 connected to open Internetworks can apply security services such as 4545 VPNs to connect to a Proxy/Server, or can establish a direct link to 4546 the Proxy/Server through some other means (see Section 4). In 4547 environments where an explicit VPN or direct link may be impractical, 4548 Client OMNI interfaces can instead send IPv6 ND messages with OMNI 4549 options that include authentication signatures. 4551 OMNI interfaces use UDP/IP as *NET encapsulation headers for 4552 transmission over open Internetworks with UDP service port number 4553 8060 (see: Section 25.13 and Section 3.6 of [I-D.templin-6man-aero]) 4554 for both IPv4 and IPv6 underlying interfaces. The OMNI interface 4555 submits original IP packets for OAL encapsulation, then encapsulates 4556 the resulting OAL fragments in UDP/IP *NET headers to form carrier 4557 packets. (The first four bits following the UDP header determine 4558 whether the OAL headers are uncompressed/compressed as discussed in 4559 Section 6.4.) The OMNI interface sets the UDP length to the 4560 encapsulated OAL fragment length and sets the IP length to an 4561 appropriate value at least as large as the UDP datagram. 4563 For Client-Proxy/Server (e.g., "Vehicle-to-Infrastructure (V2I)") 4564 neighbor exchanges, the source must include an OMNI option with an 4565 authentication sub-option in all IPv6 ND messages. The source can 4566 apply HIP security services per [RFC7401] using the IPv6 ND message 4567 OMNI option as a "shipping container" to convey an authentication 4568 signature in a (unidirectional) HIP "Notify" message. For Client- 4569 Client (e.g., "Vehicle-to-Vehicle (V2V)") neighbor exchanges, two 4570 Clients can exchange HIP "Initiator/Responder" messages coded in OMNI 4571 options of multiple IPv6 NS/NA messages for mutual authentication 4572 according to the HIP protocol. (Note: a simple Hashed Message 4573 Authentication Code (HMAC) such as specified in [RFC4380] or the 4574 QUIC-TLS connection-oriented service [RFC9000] can be used as an 4575 alternate authentication service in some environments.) 4577 When an OMNI interface includes an authentication sub-option, it must 4578 appear as the first sub-option of the first OMNI option in the IPv6 4579 ND message which must appear immediately following the IPv6 ND 4580 message header. When an OMNI interface prepares a HIP message sub- 4581 option, it includes its own (H)HIT as the Sender's HIT and the 4582 neighbor's (H)HIT if known as the Receiver's HIT (otherwise 0). If 4583 (H)HITs are not available within the OMNI operational environment, 4584 the source can instead include other IPv6 address types instead of 4585 (H)HITs as long as the Sender and Receiver have some way to associate 4586 information embedded in the IPv6 address with the neighbor; such 4587 information could include a node identifier, vehicle identifier, MAC 4588 address, etc. 4590 Before calculating the authentication signature, the source includes 4591 any other necessary sub-options (such as Interface Attributes and 4592 Origin Indication) and sets both the IPv6 ND message Checksum and 4593 authentication signature fields to 0. The source then calculates the 4594 authentication signature over the full length of the IPv6 ND message 4595 beginning with a pseudo-header of the IPv6 header (i.e., the same as 4596 specified in [RFC4443]) and extending over the length of the message. 4597 (If the IPv6 ND message is part of an OAL super-packet, the source 4598 instead calculates the authentication signature over the remainder of 4599 the super-packet.) The source next writes the authentication 4600 signature into the sub-option signature field and forwards the 4601 message. 4603 After establishing a VPN or preparing for UDP/IP encapsulation, OMNI 4604 interfaces send RS/RA messages for Client-Proxy/Server coordination 4605 (see: Section 15) and NS/NA messages for route optimization, window 4606 synchronization and mobility management (see: 4607 [I-D.templin-6man-aero]). These control plane messages must be 4608 authenticated while other control and data plane messages are 4609 delivered the same as for ordinary best-effort traffic with source 4610 address and/or Identification window-based data origin verification. 4611 Upper layer protocol sessions over OMNI interfaces that connect over 4612 open Internetworks without an explicit VPN should therefore employ 4613 transport- or higher-layer security to ensure authentication, 4614 integrity and/or confidentiality. 4616 Clients should avoid using INET Proxy/Servers as general-purpose 4617 routers for steady streams of carrier packets that do not require 4618 authentication. Clients should instead coordinate with other INET 4619 nodes that can provide forwarding services instead of burdening the 4620 Proxy/Server (or preferably coordinate directly with peer Clients 4621 directly). Procedures for coordinating with peer Clients and 4622 discovering INET nodes that can provide better forwarding services 4623 are discussed in [I-D.templin-6man-aero]. 4625 Clients that attempt to contact peers over INET underlying interfaces 4626 often encounter NATs in the path. OMNI interfaces accommodate NAT 4627 traversal using UDP/IP encapsulation and the mechanisms discussed in 4628 [I-D.templin-6man-aero]. FHS Proxy/Servers include Origin 4629 Indications in RA messages to allow Clients to detect the presence of 4630 NATs. 4632 Note: Following the initial IPv6 ND message exchange, OMNI interfaces 4633 configured over INET underlying interfaces maintain neighbor 4634 relationships by transmitting periodic IPv6 ND messages with OMNI 4635 options that include HIP "Update" and/or "Notify" messages. When 4636 HMAC authentication is used instead of HIP, the Client and Proxy/ 4637 Server exchange all IPv6 ND messages with HMAC signatures included 4638 based on a shared-secret. When QUIC-TLS connections are used, the 4639 Client and Proxy/Server observe QUIC-TLS conventions 4640 [RFC9000][RFC9001]. 4642 Note: OMNI interfaces configured over INET underlying interfaces 4643 should employ the Identification window synchronization mechanisms 4644 specified in Section 6.6 in order to reject spurious carrier packets 4645 that might otherwise clutter the reassembly cache. This is 4646 especially important in environments where carrier packet spoofing 4647 and/or corruption is a threat. 4649 Note: NATs may be present on the path from a Client to its FHS Proxy/ 4650 Server, but never on the path from the FHS Proxy/Server to the Hub 4651 where only INET and/or spanning tree hops occur. Therefore, the FHS 4652 Proxy/Server does not communicate Client origin information to the 4653 Hub where it would serve no purpose. 4655 21. Time-Varying MNPs 4657 In some use cases, it is desirable, beneficial and efficient for the 4658 Client to receive a constant MNP that travels with the Client 4659 wherever it moves. For example, this would allow air traffic 4660 controllers to easily track aircraft, etc. In other cases, however 4661 (e.g., intelligent transportation systems), the Client may be willing 4662 to sacrifice a modicum of efficiency in order to have time-varying 4663 MNPs that can be changed every so often to defeat adversarial 4664 tracking. 4666 The prefix delegation services discussed in Section 15.3 allows 4667 Clients that desire time-varying MNPs to obtain short-lived prefixes 4668 to send RS messages with source set to the unspecified address (::) 4669 and/or with an OMNI option with DHCPv6 Option sub-options. The 4670 Client would then be obligated to renumber its internal networks 4671 whenever its MNP (and therefore also its OMNI address) changes. This 4672 should not present a challenge for Clients with automated network 4673 renumbering services, but may disrupt persistent sessions that would 4674 prefer to use a constant address. 4676 22. (H)HITs and Temporary ULAs 4678 Clients that generate (H)HITs but do not have pre-assigned MNPs can 4679 request MNP delegations by issuing IPv6 ND messages that use the 4680 (H)HIT instead of a Temporary ULA. In particular, when a Client 4681 creates an RS message it can set the source to the unspecified 4682 address (::) and destination to link-scoped All-Routers multicast. 4683 The IPv6 ND message includes an OMNI option with a HIP message sub- 4684 option, and need not include a Node Identification sub-option if the 4685 Client's HIT appears in the HIP message. The Client then 4686 encapsulates the message in an IPv6 header with the (H)HIT as the 4687 source address. The Client then sends the message as specified in 4688 Section 15.2. 4690 When a Proxy/Server receives the RS message, it notes that the source 4691 was the unspecified address (::), then examines the OAL encapsulation 4692 source address to determine that the source is a (H)HIT and not a 4693 Temporary ULA. The Proxy/Server next invokes the DHCPv6 protocol to 4694 request an MNP prefix delegation while using the HIT (in the form of 4695 a DUID) as the Client Identifier, then prepares an RA message with 4696 source address set to its own ADM-LLA and destination set to the MNP- 4697 LLA corresponding to the delegated MNP. The Proxy/Server next 4698 includes an OMNI option with a HIP message sub-option and any DHCPv6 4699 prefix delegation parameters. The Proxy/Server finally encapsulates 4700 the RA in an IPv6 header with source address set to its own ADM-ULA 4701 and destination set to the (H)HIT from the RS encapsulation source 4702 address, then returns the encapsulated RA to the Client. 4704 Clients can also use (H)HITs and/or Temporary ULAs for direct Client- 4705 to-Client communications outside the context of any OMNI link 4706 supporting infrastructure. When two Clients encounter one another 4707 they can use their (H)HITs and/or Temporary ULAs as original IPv6 4708 packet source and destination addresses to support direct 4709 communications. Clients can also inject their (H)HITs and/or 4710 Temporary ULAs into a MANET/VANET routing protocol to enable multihop 4711 communications. Clients can further exchange IPv6 ND messages (such 4712 as NS/NA) using their (H)HITs and/or Temporary ULAs as source and 4713 destination addresses. 4715 Lastly, when Clients are within the coverage range of OMNI link 4716 infrastructure a case could be made for injecting (H)HITs and/or 4717 Temporary ULAs into the global MS routing system. For example, when 4718 the Client sends an RS to an FHS Proxy/Server it could include a 4719 request to inject the (H)HIT / Temporary ULA into the routing system 4720 instead of requesting an MNP prefix delegation. This would 4721 potentially enable OMNI link-wide communications using only (H)HITs 4722 or Temporary ULAs, and not MNPs. This document notes the 4723 opportunity, but makes no recommendation. 4725 23. Address Selection 4727 Clients use LLAs only for link-scoped communications on the OMNI 4728 link. Typically, Clients use LLAs as source/destination IPv6 4729 addresses of IPv6 ND messages, but may also use them for addressing 4730 ordinary original IP packets exchanged with an OMNI link neighbor. 4732 Clients use MNP-ULAs as source/destination IPv6 addresses in the 4733 encapsulation headers of OAL packets. Clients use Temporary ULAs for 4734 OAL addressing when an MNP-ULA is not available, or as source/ 4735 destination IPv6 addresses for communications within a MANET/VANET 4736 local area. Clients can also use (H)HITs instead of Temporary ULAs 4737 when operation outside the context of a specific ULA domain and/or 4738 source address attestation is necessary. 4740 Clients use MNP-based GUAs as original IP packet source and 4741 destination addresses for communications with Internet destinations 4742 when they are within range of OMNI link supporting infrastructure 4743 that can inject the MNP into the routing system. 4745 Clients use anycast GUAs as OAL and/or *NET encapsulation destination 4746 addresses for RS messages used to discover the nearest FHS Proxy/ 4747 Server. When the Proxy/Server returns a solicited RA, it must also 4748 use the same anycast address as the RA OAL/*NET encapsulation source 4749 in order to successfully traverse any NATs in the path. The Client 4750 should then immediately transition to using the FHS Proxy/Server's 4751 discovered unicast OAL/*NET address as the destination in order to 4752 minimize dependence on the Proxy/Server's use of an anycast source 4753 address. 4755 24. Error Messages 4757 An OAL destination or intermediate node may need to return 4758 ICMPv6-like error messages (e.g., Destination Unreachable, Packet Too 4759 Big, Time Exceeded, etc.) [RFC4443] to an OAL source. Since ICMPv6 4760 error messages do not themselves include authentication codes, OAL 4761 nodes can return error messages as an OMNI ICMPv6 Error sub-option in 4762 a secured IPv6 ND uNA message. 4764 25. IANA Considerations 4766 The following IANA actions are requested in accordance with [RFC8126] 4767 and [RFC8726]: 4769 25.1. "Protocol Numbers" Registry 4771 The IANA is instructed to allocate an Internet Protocol number TBD1 4772 from the 'protocol numbers' registry for the Overlay Multilink 4773 Network Interface (OMNI) protocol. Guidance is found in [RFC5237] 4774 (registration procedure is IESG Approval or Standards Action). 4776 25.2. "IEEE 802 Numbers" Registry 4778 During final publication stages, the IESG will be requested to 4779 procure an IEEE EtherType value TBD2 for OMNI according to the 4780 statement found at https://www.ietf.org/about/groups/iesg/statements/ 4781 ethertypes/. 4783 Following this procurement, the IANA is instructed to register the 4784 value TBD2 in the 'ieee-802-numbers' registry for Overlay Multilink 4785 Network Interface (OMNI) encapsulation on Ethernet networks. 4786 Guidance is found in [RFC7042] (registration procedure is Expert 4787 Review). 4789 25.3. "IPv4 Special-Purpose Address" Registry 4791 The IANA is instructed to assign TBD3/N as an "OMNI IPv4 anycast" 4792 address/prefix in the "IPv4 Special-Purpose Address" registry. This 4793 specification recommends assigning the address 192.88.99.100/24 as 4794 the "OMNI IPv4 anycast" address/prefix, since the former use of the 4795 address/prefix 192.88.99.1/24 is deprecated by [RFC7526]. In the 4796 event that conflicts with the former use are deemed irreconcilable, 4797 the IANA is instructed to work with authors to determine an alternate 4798 TBD3/N address/prefix. 4800 25.4. "IPv6 Neighbor Discovery Option Formats" Registry 4802 The IANA is instructed to allocate an official Type number TBD4 from 4803 the "IPv6 Neighbor Discovery Option Formats" registry for the OMNI 4804 option (registration procedure is RFC required). Implementations set 4805 Type to 253 as an interim value [RFC4727]. 4807 25.5. "Ethernet Numbers" Registry 4809 The IANA is instructed to allocate one Ethernet unicast address TBD5 4810 (suggested value '00-52-14') in the 'ethernet-numbers' registry under 4811 "IANA Unicast 48-bit MAC Addresses" (registration procedure is Expert 4812 Review). The registration should appear as follows: 4814 Addresses Usage Reference 4815 --------- ----- --------- 4816 00-52-14 Overlay Multilink Network (OMNI) Interface [RFCXXXX] 4818 Figure 33: IANA Unicast 48-bit MAC Addresses 4820 25.6. "ICMPv6 Code Fields: Type 2 - Packet Too Big" Registry 4822 The IANA is instructed to assign two new Code values in the "ICMPv6 4823 Code Fields: Type 2 - Packet Too Big" registry (registration 4824 procedure is Standards Action or IESG Approval). The registry should 4825 appear as follows: 4827 Code Name Reference 4828 --- ---- --------- 4829 0 PTB Hard Error [RFC4443] 4830 1 PTB Soft Error (loss) [RFCXXXX] 4831 2 PTB Soft Error (no loss) [RFCXXXX] 4833 Figure 34: ICMPv6 Code Fields: Type 2 - Packet Too Big Values 4835 (Note: this registry also to be used to define values for setting the 4836 "unused" field of ICMPv4 "Destination Unreachable - Fragmentation 4837 Needed" messages.) 4839 25.7. "OMNI Option Sub-Type Values" (New Registry) 4841 The OMNI option defines a 5-bit Sub-Type field, for which IANA is 4842 instructed to create and maintain a new registry entitled "OMNI 4843 Option Sub-Type Values". Initial values are given below 4844 (registration procedure is RFC required): 4846 Value Sub-Type name Reference 4847 ----- ------------- ---------- 4848 0 Pad1 [RFCXXXX] 4849 1 PadN [RFCXXXX] 4850 2 Interface Attributes [RFCXXXX] 4851 3 Multilink Forwarding Params [RFCXXXX] 4852 4 Traffic Selector [RFCXXXX] 4853 5 Geo Coordinates [RFCXXXX] 4854 6 DHCPv6 Message [RFCXXXX] 4855 7 HIP Message [RFCXXXX] 4856 8 PIM-SM Message [RFCXXXX] 4857 9 Fragmentation Report [RFCXXXX] 4858 10 Node Identification [RFCXXXX] 4859 11 ICMPv6 Error [RFCXXXX] 4860 12 QUIC-TLS Message [RFCXXXX] 4861 13 Proxy/Server Departure [RFCXXXX] 4862 14 OMNI Header Extension [RFCXXXX] 4863 16-29 Unassigned 4864 30 Sub-Type Extension [RFCXXXX] 4865 31 Reserved by IANA [RFCXXXX] 4867 Figure 35: OMNI Option Sub-Type Values 4869 25.8. "OMNI Geo Coordinates Type Values" (New Registry) 4871 The OMNI Geo Coordinates sub-option (see: Section 12.2.6) contains an 4872 8-bit Type field, for which IANA is instructed to create and maintain 4873 a new registry entitled "OMNI Geo Coordinates Type Values". Initial 4874 values are given below (registration procedure is RFC required): 4876 Value Sub-Type name Reference 4877 ----- ------------- ---------- 4878 0 NULL [RFCXXXX] 4879 1-252 Unassigned [RFCXXXX] 4880 253-254 Reserved for Experimentation [RFCXXXX] 4881 255 Reserved by IANA [RFCXXXX] 4883 Figure 36: OMNI Geo Coordinates Type 4885 25.9. "OMNI Node Identification ID-Type Values" (New Registry) 4887 The OMNI Node Identification sub-option (see: Section 12.2.11) 4888 contains an 8-bit ID-Type field, for which IANA is instructed to 4889 create and maintain a new registry entitled "OMNI Node Identification 4890 ID-Type Values". Initial values are given below (registration 4891 procedure is RFC required): 4893 Value Sub-Type name Reference 4894 ----- ------------- ---------- 4895 0 UUID [RFCXXXX] 4896 1 HIT [RFCXXXX] 4897 2 HHIT [RFCXXXX] 4898 3 Network Access Identifier [RFCXXXX] 4899 4 FQDN [RFCXXXX] 4900 5 IPv6 Address [RFCXXXX] 4901 6-252 Unassigned [RFCXXXX] 4902 253-254 Reserved for Experimentation [RFCXXXX] 4903 255 Reserved by IANA [RFCXXXX] 4905 Figure 37: OMNI Node Identification ID-Type Values 4907 25.10. "OMNI Option Sub-Type Extension Values" (New Registry) 4909 The OMNI option defines an 8-bit Extension-Type field for Sub-Type 30 4910 (Sub-Type Extension), for which IANA is instructed to create and 4911 maintain a new registry entitled "OMNI Option Sub-Type Extension 4912 Values". Initial values are given below (registration procedure is 4913 RFC required): 4915 Value Sub-Type name Reference 4916 ----- ------------- ---------- 4917 0 RFC4380 UDP/IP Header Option [RFCXXXX] 4918 1 RFC6081 UDP/IP Trailer Option [RFCXXXX] 4919 2-252 Unassigned 4920 253-254 Reserved for Experimentation [RFCXXXX] 4921 255 Reserved by IANA [RFCXXXX] 4923 Figure 38: OMNI Option Sub-Type Extension Values 4925 25.11. "OMNI RFC4380 UDP/IP Header Option" (New Registry) 4927 The OMNI Sub-Type Extension "RFC4380 UDP/IP Header Option" defines an 4928 8-bit Header Type field, for which IANA is instructed to create and 4929 maintain a new registry entitled "OMNI RFC4380 UDP/IP Header Option". 4930 Initial registry values are given below (registration procedure is 4931 RFC required): 4933 Value Sub-Type name Reference 4934 ----- ------------- ---------- 4935 0 Origin Indication (IPv4) [RFC4380] 4936 1 Authentication Encapsulation [RFC4380] 4937 2 Origin Indication (IPv6) [RFCXXXX] 4938 3-252 Unassigned 4939 253-254 Reserved for Experimentation [RFCXXXX] 4940 255 Reserved by IANA [RFCXXXX] 4942 Figure 39: OMNI RFC4380 UDP/IP Header Option 4944 25.12. "OMNI RFC6081 UDP/IP Trailer Option" (New Registry) 4946 The OMNI Sub-Type Extension for "RFC6081 UDP/IP Trailer Option" 4947 defines an 8-bit Trailer Type field, for which IANA is instructed to 4948 create and maintain a new registry entitled "OMNI RFC6081 UDP/IP 4949 Trailer Option". Initial registry values are given below 4950 (registration procedure is RFC required): 4952 Value Sub-Type name Reference 4953 ----- ------------- ---------- 4954 0 Unassigned 4955 1 Nonce [RFC6081] 4956 2 Unassigned 4957 3 Alternate Address (IPv4) [RFC6081] 4958 4 Neighbor Discovery Option [RFC6081] 4959 5 Random Port [RFC6081] 4960 6 Alternate Address (IPv6) [RFCXXXX] 4961 7-252 Unassigned 4962 253-254 Reserved for Experimentation [RFCXXXX] 4963 255 Reserved by IANA [RFCXXXX] 4965 Figure 40: OMNI RFC6081 Trailer Option 4967 25.13. Additional Considerations 4969 The IANA has assigned the UDP port number "8060" for an earlier 4970 experimental version of AERO [RFC6706]. This document reclaims the 4971 UDP port number "8060" for 'aero' as the service port for UDP/IP 4972 encapsulation. (Note that, although [RFC6706] was not widely 4973 implemented or deployed, any messages coded to that specification can 4974 be easily distinguished and ignored since they use an invalid ICMPv6 4975 message type number '0'.) The IANA is therefore instructed to update 4976 the reference for UDP port number "8060" from "RFC6706" to "RFCXXXX" 4977 (i.e., this document) while retaining the existing name 'aero'. 4979 The IANA has assigned a 4 octet Private Enterprise Number (PEN) code 4980 "45282" in the "enterprise-numbers" registry. This document is the 4981 normative reference for using this code in DHCP Unique IDentifiers 4982 based on Enterprise Numbers ("DUID-EN for OMNI Interfaces") (see: 4983 Section 11). The IANA is therefore instructed to change the 4984 enterprise designation for PEN code "45282" from "LinkUp Networks" to 4985 "Overlay Multilink Network Interface (OMNI)". 4987 The IANA has assigned the ifType code "301 - omni - Overlay Multilink 4988 Network Interface (OMNI)" in accordance with Section 6 of [RFC8892]. 4989 The registration appears under the IANA "Structure of Management 4990 Information (SMI) Numbers (MIB Module Registrations) - Interface 4991 Types (ifType)" registry. 4993 No further IANA actions are required. 4995 26. Security Considerations 4997 Security considerations for IPv4 [RFC0791], IPv6 [RFC8200] and IPv6 4998 Neighbor Discovery [RFC4861] apply. OMNI interface IPv6 ND messages 4999 SHOULD include Nonce and Timestamp options [RFC3971] when transaction 5000 confirmation and/or time synchronization is needed. (Note however 5001 that when OAL encapsulation is used the (echoed) OAL Identification 5002 value can provide sufficient transaction confirmation.) 5004 Client OMNI interfaces configured over secured ANET interfaces 5005 inherit the physical and/or link-layer security properties (i.e., 5006 "protected spectrum") of the connected ANETs. Client OMNI interfaces 5007 configured over open INET interfaces can use symmetric securing 5008 services such as VPNs or can by some other means establish a direct 5009 link. When a VPN or direct link may be impractical, however, the 5010 security services specified in [RFC7401] and/or [RFC4380] can be 5011 employed. While the OMNI link protects control plane messaging, 5012 applications must still employ end-to-end transport- or higher-layer 5013 security services to protect the data plane. 5015 Strong network layer security for control plane messages and 5016 forwarding path integrity for data plane messages between Proxy/ 5017 Servers MUST be supported. In one example, the AERO service 5018 [I-D.templin-6man-aero] constructs an SRT spanning tree with Proxy/ 5019 Serves as leaf nodes and secures the spanning tree links with network 5020 layer security mechanisms such as IPsec [RFC4301] or WireGuard. 5021 Secured control plane messages are then constrained to travel only 5022 over the secured spanning tree paths and are therefore protected from 5023 attack or eavesdropping. Other control and data plane messages can 5024 travel over route optimized paths that do not strictly follow the 5025 secured spanning tree, therefore end-to-end sessions should employ 5026 transport- or higher-layer security services. Additionally, the OAL 5027 Identification value can provide a first level of data origin 5028 authentication to mitigate off-path spoofing in some environments. 5030 Identity-based key verification infrastructure services such as iPSK 5031 may be necessary for verifying the identities claimed by Clients. 5032 This requirement should be harmonized with the manner in which 5033 (H)HITs are attested in a given operational environment. 5035 Security considerations for specific access network interface types 5036 are covered under the corresponding IP-over-(foo) specification 5037 (e.g., [RFC2464], [RFC2492], etc.). 5039 Security considerations for IPv6 fragmentation and reassembly are 5040 discussed in Section 6.10. In environments where spoofing is 5041 considered a threat, OMNI nodes SHOULD employ Identification window 5042 synchronization and OAL destinations SHOULD configure an (end-system- 5043 based) firewall. 5045 27. Implementation Status 5047 AERO/OMNI Release-3.2 was tagged on March 30, 2021, and is undergoing 5048 internal testing. Additional internal releases expected within the 5049 coming months, with first public release expected end of 1H2021. 5051 Many AERO/OMNI functions are implemented and undergoing final 5052 integration. OAL fragmentation/reassembly buffer management code has 5053 been cleared for public release. 5055 28. Document Updates 5057 This document does not itself update other RFCs, but suggests that 5058 the following could be updated through future IETF initiatives: 5060 o [RFC1191] 5062 o [RFC4443] 5064 o [RFC8201] 5066 o [RFC7526] 5068 Updates can be through, e.g., standards action, the errata process, 5069 etc. as appropriate. 5071 29. Acknowledgements 5073 The first version of this document was prepared per the consensus 5074 decision at the 7th Conference of the International Civil Aviation 5075 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 5076 2019. Consensus to take the document forward to the IETF was reached 5077 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 5079 Attendees and contributors included: Guray Acar, Danny Bharj, 5080 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 5081 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 5082 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 5083 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 5084 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 5085 Fryderyk Wrobel and Dongsong Zeng. 5087 The following individuals are acknowledged for their useful comments: 5088 Amanda Barber, Stuart Card, Donald Eastlake, Michael Matyas, Robert 5089 Moskowitz, Madhu Niraula, Greg Saccone, Stephane Tamalet, Eduard 5090 Vasilenko, Eric Vyncke. Pavel Drasil, Zdenek Jaron and Michal 5091 Skorepa are especially recognized for their many helpful ideas and 5092 suggestions. Akash Agarwal, Madhuri Madhava Badgandi, Sean Dickson, 5093 Don Dillenburg, Joe Dudkowski, Vijayasarathy Rajagopalan, Ron 5094 Sackman, Bhargava Raman Sai Prakash and Katherine Tran are 5095 acknowledged for their hard work on the implementation and technical 5096 insights that led to improvements for the spec. 5098 Discussions on the IETF 6man and atn mailing lists during the fall of 5099 2020 suggested additional points to consider. The authors gratefully 5100 acknowledge the list members who contributed valuable insights 5101 through those discussions. Eric Vyncke and Erik Kline were the 5102 intarea ADs, while Bob Hinden and Ole Troan were the 6man WG chairs 5103 at the time the document was developed; they are all gratefully 5104 acknowledged for their many helpful insights. Many of the ideas in 5105 this document have further built on IETF experiences beginning in the 5106 1990s, with insights from colleagues including Ron Bonica, Brian 5107 Carpenter, Ralph Droms, Christian Huitema, Thomas Narten, Dave 5108 Thaler, Joe Touch, and many others who deserve recognition. 5110 Early observations on IP fragmentation performance implications were 5111 noted in the 1986 Digital Equipment Corporation (DEC) "qe reset" 5112 investigation, where fragment bursts from NFS UDP traffic triggered 5113 hardware resets resulting in communication failures. Jeff Chase, 5114 Fred Glover and Chet Juzsczak of the Ultrix Engineering Group led the 5115 investigation, and determined that setting a smaller NFS mount block 5116 size reduced the amount of fragmentation and suppressed the resets. 5117 Early observations on L2 media MTU issues were noted in the 1988 DEC 5118 FDDI investigation, where Raj Jain, KK Ramakrishnan and Kathy Wilde 5119 represented architectural considerations for FDDI networking in 5120 general including FDDI/Ethernet bridging. Jeff Mogul (who led the 5121 IETF Path MTU Discovery working group) and other DEC colleagues who 5122 supported these early investigations are also acknowledged. 5124 Throughout the 1990's and into the 2000's, many colleagues supported 5125 and encouraged continuation of the work. Beginning with the DEC 5126 Project Sequoia effort at the University of California, Berkeley, 5127 then moving to the DEC research lab offices in Palo Alto CA, then to 5128 Sterling Software at the NASA Ames Research Center, then to SRI in 5129 Menlo Park, CA, then to Nokia in Mountain View, CA and finally to the 5130 Boeing Company in 2005 the work saw continuous advancement through 5131 the encouragement of many. Those who offered their support and 5132 encouragement are gratefully acknowledged. 5134 This work is aligned with the NASA Safe Autonomous Systems Operation 5135 (SASO) program under NASA contract number NNA16BD84C. 5137 This work is aligned with the FAA as per the SE2025 contract number 5138 DTFAWA-15-D-00030. 5140 This work is aligned with the Boeing Information Technology (BIT) 5141 Mobility Vision Lab (MVL) program. 5143 30. References 5145 30.1. Normative References 5147 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 5148 DOI 10.17487/RFC0791, September 1981, 5149 . 5151 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 5152 RFC 793, DOI 10.17487/RFC0793, September 1981, 5153 . 5155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5156 Requirement Levels", BCP 14, RFC 2119, 5157 DOI 10.17487/RFC2119, March 1997, 5158 . 5160 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 5161 "Definition of the Differentiated Services Field (DS 5162 Field) in the IPv4 and IPv6 Headers", RFC 2474, 5163 DOI 10.17487/RFC2474, December 1998, 5164 . 5166 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 5167 "SEcure Neighbor Discovery (SEND)", RFC 3971, 5168 DOI 10.17487/RFC3971, March 2005, 5169 . 5171 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 5172 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 5173 November 2005, . 5175 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5176 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5177 . 5179 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5180 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5181 2006, . 5183 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 5184 Control Message Protocol (ICMPv6) for the Internet 5185 Protocol Version 6 (IPv6) Specification", STD 89, 5186 RFC 4443, DOI 10.17487/RFC4443, March 2006, 5187 . 5189 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 5190 ICMPv6, UDP, and TCP Headers", RFC 4727, 5191 DOI 10.17487/RFC4727, November 2006, 5192 . 5194 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5195 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5196 DOI 10.17487/RFC4861, September 2007, 5197 . 5199 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5200 Address Autoconfiguration", RFC 4862, 5201 DOI 10.17487/RFC4862, September 2007, 5202 . 5204 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 5205 "Traffic Selectors for Flow Bindings", RFC 6088, 5206 DOI 10.17487/RFC6088, January 2011, 5207 . 5209 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 5210 Hosts in a Multi-Prefix Network", RFC 8028, 5211 DOI 10.17487/RFC8028, November 2016, 5212 . 5214 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5215 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5216 May 2017, . 5218 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5219 (IPv6) Specification", STD 86, RFC 8200, 5220 DOI 10.17487/RFC8200, July 2017, 5221 . 5223 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5224 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5225 DOI 10.17487/RFC8201, July 2017, 5226 . 5228 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 5229 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 5230 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 5231 RFC 8415, DOI 10.17487/RFC8415, November 2018, 5232 . 5234 30.2. Informative References 5236 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 5237 Interface for Civil Aviation, IETF Liaison Statement 5238 #1676, https://datatracker.ietf.org/liaison/1676/", March 5239 2020. 5241 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 5242 Aeronautical Telecommunication Network (ATN) using 5243 Internet Protocol Suite (IPS) Standards and Protocol), 5244 Draft Edition 3 (work-in-progress)", December 2020. 5246 [CKSUM] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, 5247 "Performance of Checksums and CRC's Over Real Data, IEEE/ 5248 ACM Transactions on Networking, Vol. 6, No. 5", October 5249 1998. 5251 [CRC] Jain, R., "Error Characteristics of Fiber Distributed Data 5252 Interface (FDDI), IEEE Transactions on Communications", 5253 August 1990. 5255 [I-D.ietf-drip-rid] 5256 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 5257 Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft 5258 System Remote Identification (UAS RID)", draft-ietf-drip- 5259 rid-13 (work in progress), November 2021. 5261 [I-D.ietf-intarea-tunnels] 5262 Touch, J. and M. Townsley, "IP Tunnels in the Internet 5263 Architecture", draft-ietf-intarea-tunnels-10 (work in 5264 progress), September 2019. 5266 [I-D.ietf-ipwave-vehicular-networking] 5267 (editor), J. (. J., "IPv6 Wireless Access in Vehicular 5268 Environments (IPWAVE): Problem Statement and Use Cases", 5269 draft-ietf-ipwave-vehicular-networking-24 (work in 5270 progress), October 2021. 5272 [I-D.ietf-tsvwg-udp-options] 5273 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 5274 udp-options-13 (work in progress), June 2021. 5276 [I-D.templin-6man-aero] 5277 Templin, F. L., "Automatic Extended Route Optimization 5278 (AERO)", draft-templin-6man-aero-36 (work in progress), 5279 October 2021. 5281 [I-D.templin-6man-lla-type] 5282 Templin, F. L., "The IPv6 Link-Local Address Type Field", 5283 draft-templin-6man-lla-type-02 (work in progress), 5284 November 2020. 5286 [I-D.templin-6man-omni-interface] 5287 Templin, F. L. and T. Whyman, "Transmission of IP Packets 5288 over Overlay Multilink Network (OMNI) Interfaces", draft- 5289 templin-6man-omni-interface-99 (work in progress), March 5290 2021. 5292 [IPV4-GUA] 5293 Postel, J., "IPv4 Address Space Registry, 5294 https://www.iana.org/assignments/ipv4-address-space/ipv4- 5295 address-space.xhtml", December 2020. 5297 [IPV6-GUA] 5298 Postel, J., "IPv6 Global Unicast Address Assignments, 5299 https://www.iana.org/assignments/ipv6-unicast-address- 5300 assignments/ipv6-unicast-address-assignments.xhtml", 5301 December 2020. 5303 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5304 DOI 10.17487/RFC0768, August 1980, 5305 . 5307 [RFC1035] Mockapetris, P., "Domain names - implementation and 5308 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 5309 November 1987, . 5311 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 5312 Communication Layers", STD 3, RFC 1122, 5313 DOI 10.17487/RFC1122, October 1989, 5314 . 5316 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 5317 options", RFC 1146, DOI 10.17487/RFC1146, March 1990, 5318 . 5320 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5321 DOI 10.17487/RFC1191, November 1990, 5322 . 5324 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", 5325 RFC 1256, DOI 10.17487/RFC1256, September 1991, 5326 . 5328 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 5329 RFC 2131, DOI 10.17487/RFC2131, March 1997, 5330 . 5332 [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over 5333 ATM", RFC 2225, DOI 10.17487/RFC2225, April 1998, 5334 . 5336 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5337 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 5338 . 5340 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 5341 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 5342 December 1998, . 5344 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 5345 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 5346 . 5348 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 5349 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 5350 . 5352 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 5353 Domains without Explicit Tunnels", RFC 2529, 5354 DOI 10.17487/RFC2529, March 1999, 5355 . 5357 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 5358 RFC 2675, DOI 10.17487/RFC2675, August 1999, 5359 . 5361 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 5362 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 5363 . 5365 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 5366 RFC 2923, DOI 10.17487/RFC2923, September 2000, 5367 . 5369 [RFC2983] Black, D., "Differentiated Services and Tunnels", 5370 RFC 2983, DOI 10.17487/RFC2983, October 2000, 5371 . 5373 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 5374 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 5375 2001, . 5377 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5378 of Explicit Congestion Notification (ECN) to IP", 5379 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5380 . 5382 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 5383 DOI 10.17487/RFC3330, September 2002, 5384 . 5386 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 5387 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 5388 DOI 10.17487/RFC3366, August 2002, 5389 . 5391 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 5392 Considered Useful", BCP 82, RFC 3692, 5393 DOI 10.17487/RFC3692, January 2004, 5394 . 5396 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5397 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5398 DOI 10.17487/RFC3810, June 2004, 5399 . 5401 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 5402 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 5403 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 5404 RFC 3819, DOI 10.17487/RFC3819, July 2004, 5405 . 5407 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 5408 Addresses", RFC 3879, DOI 10.17487/RFC3879, September 5409 2004, . 5411 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 5412 Unique IDentifier (UUID) URN Namespace", RFC 4122, 5413 DOI 10.17487/RFC4122, July 2005, 5414 . 5416 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 5417 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 5418 DOI 10.17487/RFC4271, January 2006, 5419 . 5421 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5422 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 5423 December 2005, . 5425 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 5426 Network Address Translations (NATs)", RFC 4380, 5427 DOI 10.17487/RFC4380, February 2006, 5428 . 5430 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 5431 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 5432 2006, . 5434 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 5435 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 5436 . 5438 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 5439 "Considerations for Internet Group Management Protocol 5440 (IGMP) and Multicast Listener Discovery (MLD) Snooping 5441 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 5442 . 5444 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 5445 "Internet Group Management Protocol (IGMP) / Multicast 5446 Listener Discovery (MLD)-Based Multicast Forwarding 5447 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 5448 August 2006, . 5450 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 5451 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 5452 . 5454 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 5455 Errors at High Data Rates", RFC 4963, 5456 DOI 10.17487/RFC4963, July 2007, 5457 . 5459 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 5460 Advertisement Flags Option", RFC 5175, 5461 DOI 10.17487/RFC5175, March 2008, 5462 . 5464 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 5465 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 5466 RFC 5213, DOI 10.17487/RFC5213, August 2008, 5467 . 5469 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 5470 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 5471 DOI 10.17487/RFC5214, March 2008, 5472 . 5474 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 5475 the Protocol Field", BCP 37, RFC 5237, 5476 DOI 10.17487/RFC5237, February 2008, 5477 . 5479 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 5480 RFC 5558, DOI 10.17487/RFC5558, February 2010, 5481 . 5483 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 5484 Version 3 for IPv4 and IPv6", RFC 5798, 5485 DOI 10.17487/RFC5798, March 2010, 5486 . 5488 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 5489 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 5490 . 5492 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 5493 DOI 10.17487/RFC6081, January 2011, 5494 . 5496 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 5497 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 5498 DOI 10.17487/RFC6221, May 2011, 5499 . 5501 [RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 5502 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, 5503 RFC 1644, and RFC 1693 to Historic Status", RFC 6247, 5504 DOI 10.17487/RFC6247, May 2011, 5505 . 5507 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 5508 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 5509 DOI 10.17487/RFC6355, August 2011, 5510 . 5512 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 5513 for Equal Cost Multipath Routing and Link Aggregation in 5514 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 5515 . 5517 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 5518 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 5519 2012, . 5521 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 5522 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 5523 . 5525 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 5526 UDP Checksums for Tunneled Packets", RFC 6935, 5527 DOI 10.17487/RFC6935, April 2013, 5528 . 5530 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 5531 for the Use of IPv6 UDP Datagrams with Zero Checksums", 5532 RFC 6936, DOI 10.17487/RFC6936, April 2013, 5533 . 5535 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 5536 with IPv6 Neighbor Discovery", RFC 6980, 5537 DOI 10.17487/RFC6980, August 2013, 5538 . 5540 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 5541 IETF Protocol and Documentation Usage for IEEE 802 5542 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 5543 October 2013, . 5545 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 5546 Requirements for IPv6 Customer Edge Routers", RFC 7084, 5547 DOI 10.17487/RFC7084, November 2013, 5548 . 5550 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 5551 "Architectural Considerations of IP Anycast", RFC 7094, 5552 DOI 10.17487/RFC7094, January 2014, 5553 . 5555 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 5556 Scheffenegger, Ed., "TCP Extensions for High Performance", 5557 RFC 7323, DOI 10.17487/RFC7323, September 2014, 5558 . 5560 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 5561 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 5562 RFC 7401, DOI 10.17487/RFC7401, April 2015, 5563 . 5565 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 5566 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 5567 Boundary in IPv6 Addressing", RFC 7421, 5568 DOI 10.17487/RFC7421, January 2015, 5569 . 5571 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 5572 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 5573 DOI 10.17487/RFC7526, May 2015, 5574 . 5576 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 5577 DOI 10.17487/RFC7542, May 2015, 5578 . 5580 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 5581 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 5582 February 2016, . 5584 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 5585 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 5586 Multicast - Sparse Mode (PIM-SM): Protocol Specification 5587 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 5588 2016, . 5590 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 5591 Support for IP Hosts with Multi-Access Support", RFC 7847, 5592 DOI 10.17487/RFC7847, May 2016, 5593 . 5595 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5596 Writing an IANA Considerations Section in RFCs", BCP 26, 5597 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5598 . 5600 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 5601 Decraene, B., Litkowski, S., and R. Shakir, "Segment 5602 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 5603 July 2018, . 5605 [RFC8726] Farrel, A., "How Requests for IANA Action Will Be Handled 5606 on the Independent Stream", RFC 8726, 5607 DOI 10.17487/RFC8726, November 2020, 5608 . 5610 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 5611 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 5612 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 5613 . 5615 [RFC8892] Thaler, D. and D. Romascanu, "Guidelines and Registration 5616 Procedures for Interface Types and Tunnel Types", 5617 RFC 8892, DOI 10.17487/RFC8892, August 2020, 5618 . 5620 [RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 5621 T. Voelker, "Packetization Layer Path MTU Discovery for 5622 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 5623 September 2020, . 5625 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 5626 and F. Gont, "IP Fragmentation Considered Fragile", 5627 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 5628 . 5630 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 5631 "Temporary Address Extensions for Stateless Address 5632 Autoconfiguration in IPv6", RFC 8981, 5633 DOI 10.17487/RFC8981, February 2021, 5634 . 5636 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 5637 Multiplexed and Secure Transport", RFC 9000, 5638 DOI 10.17487/RFC9000, May 2021, 5639 . 5641 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 5642 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 5643 . 5645 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 5646 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 5647 May 2021, . 5649 Appendix A. OAL Checksum Algorithm 5651 The OAL Checksum Algorithm adopts the 8-bit Fletcher algorithm 5652 specified in Appendix I of [RFC1146] as also analyzed in [CKSUM]. 5653 [RFC6247] declared [RFC1146] historic for the reason that the 5654 algorithms had never seen widespread use with TCP, however this 5655 document adopts the 8-bit Fletcher algorithm for a different purpose. 5656 Quoting from Appendix I of [RFC1146], the OAL Checksum Algorithm 5657 proceeds as follows: 5659 "The 8-bit Fletcher Checksum Algorithm is calculated over a 5660 sequence of data octets (call them D[1] through D[N]) by 5661 maintaining 2 unsigned 1's-complement 8-bit accumulators A and B 5662 whose contents are initially zero, and performing the following 5663 loop where i ranges from 1 to N: 5665 A := A + D[i] 5667 B := B + A 5669 It can be shown that at the end of the loop A will contain the 5670 8-bit 1's complement sum of all octets in the datagram, and that B 5671 will contain (N)D[1] + (N-1)D[2] + ... + D[N]." 5673 To calculate the OAL checksum, the above algorithm is applied over 5674 the N-octet concatenation of the OAL pseudo-header and the 5675 encapsulated IP packet or packets. Specifically, the algorithm is 5676 first applied over the 40 octets of the OAL pseudo-header as data 5677 octets D[1] through D[40], then continues over the entire length of 5678 the original IP packet(s) as data octets D[41] through D[N]. 5680 Appendix B. IPv6 ND Message Authentication and Integrity 5682 OMNI interface IPv6 ND messages are subject to authentication and 5683 integrity checks at multiple levels. When an OMNI interface sends an 5684 IPv6 ND message over an INET interface, it includes an authentication 5685 sub-option with a valid signature but does not include an IPv6 ND 5686 message checksum. The OMNI interface that receives the message 5687 verifies the OAL checksum as a first-level integrity check, then 5688 verifies the authentication signature (while ignoring the IPv6 ND 5689 message checksum) to ensure IPv6 ND message authentication and 5690 integrity. 5692 When an OMNI interface sends an IPv6 ND message over an underlying 5693 interface connected to a secured network, it omits the authentication 5694 sub-option but instead calculates/includes an IPv6 ND message 5695 checksum. The OMNI interface that receives the message applies any 5696 lower-layer authentication and integrity checks, then verifies both 5697 the OAL checksum (if present) and the IPv6 ND message checksum. 5698 (Note that optimized implementations can verify both the OAL and IPv6 5699 ND message checksums in a single pass over the data.) When an OMNI 5700 interface sends IPv6 ND messages to a synchronized neighbor, it 5701 includes an authentication sub-option only if authentication is 5702 necessary; otherwise, it calculates/includes the IPv6 ND message 5703 checksum. 5705 When the OMNI interface calculates the authentication signature or 5706 IPv6 ND message checksum, it performs the calculation beginning with 5707 a pseudo-header of the IPv6 ND message header and extends over all 5708 following OAL packet data. In particular, for OAL super-packets any 5709 additional original IP packets included beyond the end of the IPv6 ND 5710 message are simply considered as extensions of the IPv6 ND message 5711 for the purpose of the calculation. 5713 OAL destinations discard carrier packets with unacceptable 5714 Identifications and submit the encapsulated fragments in others for 5715 reassembly. The reassembly algorithm rejects any fragments with 5716 unacceptable sizes, offsets, etc. and reassembles all others. 5717 Following reassembly, the OAL checksum algorithm provides an 5718 integrity assurance layer that compliments any integrity checks 5719 already applied by lower layers as well as a first-pass filter for 5720 any checks that will be applied later by upper layers. 5722 Appendix C. VDL Mode 2 Considerations 5724 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 5725 (VDLM2) that specifies an essential radio frequency data link service 5726 for aircraft and ground stations in worldwide civil aviation air 5727 traffic management. The VDLM2 link type is "multicast capable" 5728 [RFC4861], but with considerable differences from common multicast 5729 links such as Ethernet and IEEE 802.11. 5731 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 5732 magnitude less than most modern wireless networking gear. Second, 5733 due to the low available link bandwidth only VDLM2 ground stations 5734 (i.e., and not aircraft) are permitted to send broadcasts, and even 5735 so only as compact layer 2 "beacons". Third, aircraft employ the 5736 services of ground stations by performing unicast RS/RA exchanges 5737 upon receipt of beacons instead of listening for multicast RA 5738 messages and/or sending multicast RS messages. 5740 This beacon-oriented unicast RS/RA approach is necessary to conserve 5741 the already-scarce available link bandwidth. Moreover, since the 5742 numbers of beaconing ground stations operating within a given spatial 5743 range must be kept as sparse as possible, it would not be feasible to 5744 have different classes of ground stations within the same region 5745 observing different protocols. It is therefore highly desirable that 5746 all ground stations observe a common language of RS/RA as specified 5747 in this document. 5749 Note that links of this nature may benefit from compression 5750 techniques that reduce the bandwidth necessary for conveying the same 5751 amount of data. The IETF lpwan working group is considering possible 5752 alternatives: [https://datatracker.ietf.org/wg/lpwan/documents]. 5754 Appendix D. Client-Proxy/Server Isolation Through L2 Address Mapping 5756 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 5757 unicast link-scoped IPv6 destination address. However, IPv6 ND 5758 messaging should be coordinated between the Client and Proxy/Server 5759 only without invoking other nodes on the *NET. This implies that 5760 Client-Proxy/Server control messaging should be isolated and not 5761 overheard by other nodes on the link. 5763 To support Client-Proxy/Server isolation on some *NET links, Proxy/ 5764 Servers can maintain an OMNI-specific unicast L2 address ("MSADDR"). 5765 For Ethernet-compatible *NETs, this specification reserves one 5766 Ethernet unicast address TBD5 (see: IANA Considerations). For non- 5767 Ethernet statically-addressed *NETs, MSADDR is reserved per the 5768 assigned numbers authority for the *NET addressing space. For still 5769 other *NETs, MSADDR may be dynamically discovered through other 5770 means, e.g., L2 beacons. 5772 Clients map the L3 addresses of all IPv6 ND messages they send (i.e., 5773 both multicast and unicast) to MSADDR instead of to an ordinary 5774 unicast or multicast L2 address. In this way, all of the Client's 5775 IPv6 ND messages will be received by Proxy/Servers that are 5776 configured to accept packets destined to MSADDR. Note that multiple 5777 Proxy/Servers on the link could be configured to accept packets 5778 destined to MSADDR, e.g., as a basis for supporting redundancy. 5780 Therefore, Proxy/Servers must accept and process packets destined to 5781 MSADDR, while all other devices must not process packets destined to 5782 MSADDR. This model has well-established operational experience in 5783 Proxy Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 5785 Appendix E. Change Log 5787 << RFC Editor - remove prior to publication >> 5789 Differences from earlier versions to draft-templin-6man-omni-45: 5791 o New baseline version with corrections and section reorganizations 5792 to improve document flow. 5794 Authors' Addresses 5796 Fred L. Templin (editor) 5797 The Boeing Company 5798 P.O. Box 3707 5799 Seattle, WA 98124 5800 USA 5802 Email: fltemplin@acm.org 5804 Tony Whyman 5805 MWA Ltd c/o Inmarsat Global Ltd 5806 99 City Road 5807 London EC1Y 1AX 5808 England 5810 Email: tony.whyman@mccallumwhyman.com