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