idnits 2.17.1 draft-templin-6man-omni-61.txt: -(6216): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 April 2022) is 729 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: 'RFCXXXX' is mentioned on line 5565, but not defined -- Looks like a reference, but probably isn't: '1' on line 6276 == Missing Reference: 'N' is mentioned on line 6277, but not defined -- Looks like a reference, but probably isn't: '2' on line 6270 -- Looks like a reference, but probably isn't: '40' on line 6276 -- Looks like a reference, but probably isn't: '41' on line 6277 == Unused Reference: 'I-D.templin-6man-lla-type' is defined on line 5895, but no explicit reference was found in the text == Unused Reference: 'RFC8981' is defined on line 6226, 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-24 == 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-28 == Outdated reference: A later version (-63) exists of draft-templin-6man-aero-45 == Outdated reference: A later version (-99) exists of draft-templin-intarea-parcels-10 -- Obsolete informational reference (is this intentional?): RFC 1146 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- 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 (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. L. Templin, Ed. 3 Internet-Draft The Boeing Company 4 Intended status: Informational 25 April 2022 5 Expires: 27 October 2022 7 Transmission of IP Packets over Overlay Multilink Network (OMNI) 8 Interfaces 9 draft-templin-6man-omni-61 11 Abstract 13 Mobile nodes (e.g., aircraft of various configurations, terrestrial 14 vehicles, seagoing vessels, space systems, enterprise wireless 15 devices, pedestrians with cell phones, etc.) communicate with 16 networked correspondents over multiple access network data links and 17 configure mobile routers to connect end user networks. A multilink 18 virtual interface specification is presented that enables mobile 19 nodes to coordinate with a network-based mobility service and/or with 20 other mobile node peers. The virtual interface provides an 21 adaptation layer service that also applies for more static 22 deployments such as enterprise and home networks. This document 23 specifies the transmission of IP packets over Overlay Multilink 24 Network (OMNI) Interfaces. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 27 October 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 62 4. Overlay Multilink Network (OMNI) Interface Model . . . . . . 15 63 5. OMNI Interface Maximum Transmission Unit (MTU) . . . . . . . 22 64 5.1. Jumbograms . . . . . . . . . . . . . . . . . . . . . . . 23 65 5.2. IPv6 Parcels . . . . . . . . . . . . . . . . . . . . . . 24 66 6. The OMNI Adaptation Layer (OAL) . . . . . . . . . . . . . . . 24 67 6.1. OAL Source Encapsulation and Fragmentation . . . . . . . 25 68 6.2. OAL L2 Encapsulation and Re-Encapsulation . . . . . . . . 30 69 6.3. OAL L2 Decapsulation and Reassembly . . . . . . . . . . . 33 70 6.4. OAL Header Compression . . . . . . . . . . . . . . . . . 34 71 6.5. OAL-in-OAL Encapsulation . . . . . . . . . . . . . . . . 38 72 6.6. OAL Identification Window Maintenance . . . . . . . . . . 40 73 6.7. OAL Fragment Retransmission . . . . . . . . . . . . . . . 45 74 6.8. OAL MTU Feedback Messaging . . . . . . . . . . . . . . . 46 75 6.9. OAL Super-Packets . . . . . . . . . . . . . . . . . . . . 48 76 6.10. OAL Bubbles . . . . . . . . . . . . . . . . . . . . . . . 49 77 6.11. OAL Requirements . . . . . . . . . . . . . . . . . . . . 50 78 6.12. OAL Fragmentation Security Implications . . . . . . . . . 51 79 6.13. OMNI Hosts . . . . . . . . . . . . . . . . . . . . . . . 52 80 6.14. IP Parcels . . . . . . . . . . . . . . . . . . . . . . . 55 81 7. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 58 82 8. Link-Local Addresses (LLAs) . . . . . . . . . . . . . . . . . 59 83 9. Unique-Local Addresses (ULAs) . . . . . . . . . . . . . . . . 60 84 10. Global Unicast Addresses (GUAs) . . . . . . . . . . . . . . . 63 85 11. Node Identification . . . . . . . . . . . . . . . . . . . . . 64 86 12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 65 87 12.1. The OMNI Option . . . . . . . . . . . . . . . . . . . . 66 88 12.2. OMNI Sub-Options . . . . . . . . . . . . . . . . . . . . 66 89 12.2.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 69 90 12.2.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 69 91 12.2.3. Neighbor Coordination . . . . . . . . . . . . . . . 70 92 12.2.4. Interface Attributes . . . . . . . . . . . . . . . . 72 93 12.2.5. Multilink Forwarding Parameters . . . . . . . . . . 75 94 12.2.6. Traffic Selector . . . . . . . . . . . . . . . . . . 80 95 12.2.7. Geo Coordinates . . . . . . . . . . . . . . . . . . 81 96 12.2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 97 Message . . . . . . . . . . . . . . . . . . . . . . . 82 98 12.2.9. Host Identity Protocol (HIP) Message . . . . . . . . 83 99 12.2.10. PIM-SM Message . . . . . . . . . . . . . . . . . . . 85 100 12.2.11. Fragmentation Report (FRAGREP) . . . . . . . . . . . 86 101 12.2.12. Node Identification . . . . . . . . . . . . . . . . 87 102 12.2.13. ICMPv6 Error . . . . . . . . . . . . . . . . . . . . 89 103 12.2.14. QUIC-TLS Message . . . . . . . . . . . . . . . . . . 90 104 12.2.15. Proxy/Server Departure . . . . . . . . . . . . . . . 90 105 12.2.16. Sub-Type Extension . . . . . . . . . . . . . . . . . 91 106 13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 94 107 14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 95 108 14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 95 109 14.2. Client-Proxy/Server Loop Prevention . . . . . . . . . . 96 110 15. Router Discovery and Prefix Registration . . . . . . . . . . 96 111 15.1. Window Synchronization . . . . . . . . . . . . . . . . . 105 112 15.2. Router Discovery in IP Multihop and IPv4-Only 113 Networks . . . . . . . . . . . . . . . . . . . . . . . . 106 114 15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 108 115 15.4. OMNI Link Extension . . . . . . . . . . . . . . . . . . 110 116 16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 110 117 17. Proxy/Server Resilience . . . . . . . . . . . . . . . . . . . 111 118 18. Detecting and Responding to Proxy/Server Failures . . . . . . 111 119 19. Transition Considerations . . . . . . . . . . . . . . . . . . 112 120 20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 113 121 21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 115 122 22. (H)HITs and Temporary ULA (TLA)s . . . . . . . . . . . . . . 116 123 23. Address Selection . . . . . . . . . . . . . . . . . . . . . . 117 124 24. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 118 125 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118 126 25.1. "Protocol Numbers" Registry . . . . . . . . . . . . . . 118 127 25.2. "IEEE 802 Numbers" Registry . . . . . . . . . . . . . . 118 128 25.3. "IPv4 Special-Purpose Address" Registry . . . . . . . . 118 129 25.4. "IPv6 Neighbor Discovery Option Formats" Registry . . . 119 130 25.5. "Ethernet Numbers" Registry . . . . . . . . . . . . . . 119 131 25.6. "ICMPv6 Code Fields: Type 2 - Packet Too Big" 132 Registry . . . . . . . . . . . . . . . . . . . . . . . 119 133 25.7. "OMNI Option Sub-Type Values" (New Registry) . . . . . . 119 134 25.8. "OMNI Geo Coordinates Type Values" (New Registry) . . . 120 135 25.9. "OMNI Node Identification ID-Type Values" (New 136 Registry) . . . . . . . . . . . . . . . . . . . . . . . 120 137 25.10. "OMNI Option Sub-Type Extension Values" (New 138 Registry) . . . . . . . . . . . . . . . . . . . . . . . 121 139 25.11. "OMNI RFC4380 UDP/IP Header Option" (New Registry) . . . 121 140 25.12. "OMNI RFC6081 UDP/IP Trailer Option" (New Registry) . . 122 141 25.13. Additional Considerations . . . . . . . . . . . . . . . 122 142 26. Security Considerations . . . . . . . . . . . . . . . . . . . 123 143 27. Implementation Status . . . . . . . . . . . . . . . . . . . . 124 144 28. Document Updates . . . . . . . . . . . . . . . . . . . . . . 124 145 29. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124 146 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 147 30.1. Normative References . . . . . . . . . . . . . . . . . . 126 148 30.2. Informative References . . . . . . . . . . . . . . . . . 128 149 Appendix A. OAL Checksum Algorithm . . . . . . . . . . . . . . . 137 150 Appendix B. IPv6 ND Message Authentication and Integrity . . . . 137 151 Appendix C. VDL Mode 2 Considerations . . . . . . . . . . . . . 138 152 Appendix D. Client-Proxy/Server Isolation Through Link-Layer 153 Address Mapping . . . . . . . . . . . . . . . . . . . . . 139 154 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 140 155 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 140 157 1. Introduction 159 Mobile nodes (e.g., aircraft of various configurations, terrestrial 160 vehicles, seagoing vessels, space systems, enterprise wireless 161 devices, pedestrians with cellphones, etc.) configure mobile routers 162 with multiple interface connections to wireless and/or wired-line 163 data links. These data links may have diverse performance, cost and 164 availability properties that can change dynamically according to 165 mobility patterns, flight phases, proximity to infrastructure, etc. 166 The mobile router acts as a Client of a network-based Mobility 167 Service (MS) by configuring a virtual interface over its underlay 168 interface data link connections to support the "6M's of modern 169 Internetworking" (see below). 171 Each Client configures a virtual interface (termed the "Overlay 172 Multilink Network Interface (OMNI)") as a thin layer over its 173 underlay network interfaces (which may themselves connect to virtual 174 or physical links). The OMNI interface is therefore the only 175 interface abstraction exposed to the IP layer and behaves according 176 to the Non-Broadcast, Multiple Access (NBMA) interface principle, 177 while underlay interfaces appear as link layer communication channels 178 in the architecture. The OMNI interface internally employs the "OMNI 179 Adaptation Layer (OAL)" to ensure that original IP packets are 180 adapted to diverse underlay interfaces with heterogeneous properties. 181 The OMNI interface connects to a virtual overlay known as the "OMNI 182 link". The OMNI link multinet service spans one or more 183 Internetworks that may include private-use infrastructures (e.g., 184 enterprise networks) and/or the global public Internet itself. 186 Client OMNI interfaces interact with the MS and/or other OMNI nodes 187 through IPv6 Neighbor Discovery (ND) control message exchanges 188 [RFC4861]. The MS consists of a distributed set of service nodes 189 (including Proxy/Servers and other infrastructure elements) that also 190 configure OMNI interfaces. Automatic Extended Route Optimization 191 (AERO) in particular provides a companion MS compatible with the OMNI 192 architecture [I-D.templin-6man-aero]. AERO discusses details of ND 193 message based route optimization, mobility management, and multinet 194 traversal while the fundamental aspects of OMNI link operation are 195 discussed in this document. 197 Each OMNI interface provides a multilink nexus for exchanging inbound 198 and outbound traffic via selected underlay interface(s). The IP 199 layer sees the OMNI interface as a point of connection to the OMNI 200 link. Each OMNI link has one or more associated Mobility Service 201 Prefixes (MSPs), which are typically IP Global Unicast Address (GUA) 202 prefixes assigned to the link and from which Mobile Network Prefixes 203 (MNPs) are derived. If there are multiple OMNI links, the IP layer 204 will see multiple OMNI interfaces. 206 Each Client receives an MNP through IPv6 ND control message exchanges 207 with Proxy/Servers over Access Networks (ANETs) and/or open 208 Internetworks (INETs). The Client sub-delegates the MNP to 209 downstream-attached End-user Networks (ENETs) independently of the 210 underlay interfaces selected for data transport. The Client acts as 211 a fixed or mobile router on behalf of peers on its ENETs, and uses 212 OMNI interface control messaging to coordinate with Hosts, Proxy/ 213 Servers and/or other Clients. The Client iterates its control 214 messaging over each of the OMNI interface's ANET/INET underlay 215 interfaces in order to register each interface with the MS (see 216 Section 15). The Client can also provide Proxy/Server-like services 217 for a recursively nested chain of other Clients located in 218 downstream-attached ENETs. 220 Clients may connect to multiple distinct OMNI links within the same 221 OMNI domain by configuring multiple OMNI interfaces, e.g., omni0, 222 omni1, omni2, etc. Each OMNI interface is configured over a set of 223 underlay interfaces and provides a nexus for Safety-Based Multilink 224 (SBM) operation. The IP layer applies SBM routing to select a 225 specific OMNI interface, then the selected OMNI interface applies 226 Performance-Based Multilink (PBM) internally to select appropriate 227 underlay interfaces. Applications select SBM topologies based on IP 228 layer Segment Routing [RFC8402], while each OMNI interface 229 orchestrates PBM internally based on OMNI layer Segment Routing. 231 OMNI provides a link model suitable for a wide range of use cases. 232 For example, the International Civil Aviation Organization (ICAO) 233 Working Group-I Mobility Subgroup is developing a future Aeronautical 234 Telecommunications Network with Internet Protocol Services (ATN/IPS) 235 and has issued a liaison statement requesting IETF adoption [ATN] in 236 support of ICAO Document 9896 [ATN-IPS]. The IETF IP Wireless Access 237 in Vehicular Environments (ipwave) working group has further included 238 problem statement and use case analysis for OMNI in a document now in 239 AD evaluation for RFC publication 241 [I-D.ietf-ipwave-vehicular-networking]. Still other communities of 242 interest include AEEC, RTCA Special Committee 228 (SC-228) and NASA 243 programs that examine commercial aviation, Urban Air Mobility (UAM) 244 and Unmanned Air Systems (UAS). Pedestrians with handheld devices 245 represent another large class of potential OMNI users. 247 OMNI supports the "6M's of modern Internetworking" including: 249 1. Multilink - a Client's ability to coordinate multiple diverse 250 underlay interfaces as a single logical unit (i.e., the OMNI 251 interface) to achieve the required communications performance and 252 reliability objectives. 254 2. Multinet - the ability to span the OMNI link over a segment 255 routing topology with multiple diverse administrative domain 256 network segments while maintaining seamless end-to-end 257 communications between mobile Clients and correspondents such as 258 air traffic controllers, fleet administrators, etc. 260 3. Mobility - a Client's ability to change network points of 261 attachment (e.g., moving between wireless base stations) which 262 may result in an underlay interface address change, but without 263 disruptions to ongoing communication sessions with peers over the 264 OMNI link. 266 4. Multicast - the ability to send a single network transmission 267 that reaches multiple Clients belonging to the same interest 268 group, but without disturbing other Clients not subscribed to the 269 interest group. 271 5. Multihop - a mobile Client vehicle-to-vehicle relaying capability 272 useful when multiple forwarding hops between vehicles may be 273 necessary to "reach back" to an infrastructure access point 274 connection to the OMNI link. 276 6. MTU assurance - the ability to deliver packets of various robust 277 sizes between peers without loss due to a link size restriction, 278 and to dynamically adjust packets sizes to achieve the optimal 279 performance for each independent traffic flow. 281 This document specifies the transmission of IP packets and control 282 messages over OMNI interfaces. The operation of both IP protocol 283 versions (i.e., IPv4 [RFC0791] and IPv6 [RFC8200]) is specified as 284 the network layer data plane, while OMNI interfaces use IPv6 ND 285 messaging in the control plane independently of the data plane 286 protocol(s). OMNI interfaces also provide an OAL based on 287 encapsulation and fragmentation over heterogeneous underlay 288 interfaces as an adaptation sublayer between L3 and L2. Both OMNI 289 and the OAL are specified in detail throughout the remainder of this 290 document. 292 2. Terminology 294 The terminology in the normative references applies; especially, the 295 terms "link" and "interface" are the same as defined in the IPv6 296 [RFC8200] and IPv6 Neighbor Discovery (ND) [RFC4861] specifications. 297 Additionally, this document assumes the following IPv6 ND message 298 types: Router Solicitation (RS), Router Advertisement (RA), Neighbor 299 Solicitation (NS), Neighbor Advertisement (NA) and Redirect. Hosts, 300 Clients and Proxy/Servers that implement IPv6 ND maintain per- 301 neighbor state in Neighbor Cache Entries (NCEs). Each NCE is indexed 302 by the neighbor's network layer address(es) while the neighbor's OAL 303 encapsulation address provides context for Identification 304 verification. 306 The Protocol Constants defined in Section 10 of [RFC4861] are used in 307 their same format and meaning in this document. The terms "All- 308 Routers multicast", "All-Nodes multicast" and "Subnet-Router anycast" 309 are the same as defined in [RFC4291] (with Link-Local scope assumed). 311 The term "IP" is used to refer collectively to either Internet 312 Protocol version (i.e., IPv4 [RFC0791] or IPv6 [RFC8200]) when a 313 specification at the layer in question applies equally to either 314 version. 316 The following terms are defined within the scope of this document: 318 L2 319 The Data Link layer in the OSI network model. Also known as 320 "layer-2", "link-layer", "sub-IP layer", etc. 322 L3 323 The Network layer in the OSI network model. Also known as "layer- 324 3", "IP layer", etc. 326 Adaptation layer 327 A mid-layer that adapts L3 to a diverse collection of L2 underlay 328 interfaces and their encapsulations. (No layer number is 329 assigned, since numbering was an artifact of the legacy reference 330 model that need not carry forward in the modern architecture.) 331 The adaptation layer sees the upper layer as "L3" and sees all 332 lower layer encapsulations as "L2 encapsulations", which may 333 include UDP, IP and true link-layer (e.g., Ethernet, etc.) 334 headers. 336 Access Network (ANET) 337 a connected network region (e.g., an aviation radio access 338 network, satellite service provider network, cellular operator 339 network, WiFi network, etc.) that connects Clients to the Mobility 340 Service. Physical and/or data link level security is assumed, and 341 sometimes referred to as "protected spectrum". Private enterprise 342 networks and ground domain aviation service networks may provide 343 multiple secured IP hops between the Client's point of connection 344 and the nearest Proxy/Server. 346 Internetwork (INET) 347 a connected network region with a coherent IP addressing plan that 348 provides transit forwarding services between ANETs and/or OMNI 349 nodes that coordinate with the Mobility Service over unprotected 350 media. Since physical and/or data link level security cannot 351 always be assumed, security must be applied by upper layers if 352 necessary. The global public Internet itself is an example. 354 End-user Network (ENET) 355 a simple or complex "downstream" network that travels with the 356 Client as a single logical unit. The ENET could be as simple as a 357 single link connecting a single Host, or as complex as a large 358 network with many links, routers, bridges and Hosts. The ENET 359 could also provide an "upstream" link in a recursively-descending 360 chain of additional Clients and ENETs. In this way, an ENET of an 361 upstream Client is seen as the ANET of a downstream Client. 363 {A,I,E}NET interface 364 a Client's attachment to a link in an {A,I,E}NET. 366 *NET 367 a "wildcard" term used when a given specification applies equally 368 to both ANET/INET cases. From the Client's perspective, *NET 369 interfaces are "upstream" interfaces that connect the Client to 370 the Mobility Service, while ENET interfaces are "downstream" 371 interfaces that the Client uses to connect downstream ENETs, Hosts 372 and/or other Clients. 374 underlay interface 375 an ANET/INET/ENET interface over which an OMNI interface is 376 configured. The OMNI interface is seen as a L3 interface by the 377 IP layer, and each underlay interface is seen as a L2 interface by 378 the OMNI interface. The underlay interface either connects 379 directly to the physical communications media or coordinates with 380 another node where the physical media is hosted. 382 OMNI link 383 a Non-Broadcast, Multiple Access (NBMA) virtual overlay configured 384 over one or more INETs and their connected ANETs/ENETs. An OMNI 385 link may comprise multiple distinct "segments" joined by L2 386 forwarding devices the same as for any link; the addressing plans 387 in each segment may be mutually exclusive and managed by different 388 administrative entities. Proxy/Servers and other infrastructure 389 elements extend the link to support communications between Clients 390 as single-hop neighbors. 392 OMNI interface 393 a node's attachment to an OMNI link, and configured over one or 394 more underlay interfaces. If there are multiple OMNI links in an 395 OMNI domain, a separate OMNI interface is configured for each 396 link. The OMNI interface configures a Maximum Transmission Unit 397 (MTU) and a Maximum Reassembly Unit (MRU) the same as any 398 interface. 400 OMNI Adaptation Layer (OAL) 401 an OMNI interface sublayer service that encapsulates original IP 402 packets admitted into the interface in an IPv6 header and/or 403 subjects them to fragmentation and reassembly. The OAL is also 404 responsible for generating MTU-related control messages as 405 necessary, and for providing addressing context for OMNI link SRT 406 traversal. The OAL presents a new layer in the Internet 407 architecture known simply as the "adaptation layer". 409 Host 410 an end user device that extends the OMNI link over an ENET 411 interface serviced by a Client. (As an implementation matter, the 412 Host either assigns the same IP address from the ENET (underlay) 413 interface to an (overlay) OMNI interface, or configures an OMNI- 414 like function as a virtual sublayer of the ENET interface itself.) 415 The IP addresses assigned to each Host ENET interface remain 416 stable even if the Client's upstream *NET interface connections 417 change. 419 Client 420 a network platform/device mobile router that configures one or 421 more OMNI interfaces over distinct sets of underlay interfaces 422 grouped as logical OMNI link units. The Client coordinates with 423 the Mobility Service via upstream networks over *NET interfaces, 424 and provides Proxy/Server services for Hosts and other Clients on 425 ENET interface downstream networks. The Client's *NET interface 426 addresses and performance characteristics may change over time 427 (e.g., due to node mobility, link quality, etc.) while downstream- 428 attached Hosts and other Clients see the ENET as a stable ANET. 430 Proxy/Server 431 a segment routing topology edge node that configures an OMNI 432 interface and connects Clients to the Mobility Service. As a 433 server, the Proxy/Server responds directly to some Client IPv6 ND 434 messages. As a proxy, the Proxy/Server forwards other Client IPv6 435 ND messages to other Proxy/Servers and Clients. As a router, the 436 Proxy/Server provides a forwarding service for ordinary data 437 packets that may be essential in some environments and a last 438 resort in others. Proxy/Servers at ANET boundaries configure both 439 an ANET downstream interface and *NET upstream interface, while 440 INET-based Proxy/Servers configure only an INET interface. 442 First-Hop Segment (FHS) Proxy/Server 443 a Proxy/Server connected to the source Client's *NET that forwards 444 packets sent by the source into the segment routing topology. FHS 445 Proxy/Servers also act as intermediate forwarding nodes to 446 facilitate RS/RA exchanges between Clients and Hub Proxy/Servers. 448 Last-Hop Segment (LHS) Proxy/Server 449 a Proxy/Server connected to the target Client's *NET that forwards 450 packets received from the segment routing topology to the target. 452 Hub Proxy/Server 453 a single Proxy/Server selected by the Client that provides a 454 designated router service for all of the Client's*NET underlay 455 networks. Since all Proxy/Servers provide equivalent services, 456 Clients normally select the first FHS Proxy/Server they coordinate 457 with to serve as the Hub. However, the Hub can also be any 458 available Proxy/Server for the OMNI link, i.e., and not 459 necessarily one of the Client's FHS Proxy/Servers. 461 Segment Routing Topology (SRT) 462 a multinet forwarding region configured over one or more INETs 463 between the FHS Proxy/Server and LHS Proxy/Server. The SRT spans 464 the OMNI link on behalf of source/target Client pairs using 465 segment routing in a manner outside the scope of this document 466 (see: [I-D.templin-6man-aero]). 468 Mobility Service (MS) 469 a mobile routing service that tracks Client movements and ensures 470 that Clients remain continuously reachable even across mobility 471 events. The MS consists of the set of all Proxy/Servers and any 472 other OMNI link supporting infrastructure nodes. Specific MS 473 details are out of scope for this document, with an example found 474 in [I-D.templin-6man-aero]. 476 Mobility Service Prefix (MSP) 477 an aggregated IP Global Unicast Address (GUA) prefix (e.g., 478 2001:db8::/32, 192.0.2.0/24, etc.) assigned to the OMNI link and 479 from which more-specific Mobile Network Prefixes (MNPs) are 480 delegated. OMNI link administrators typically obtain MSPs from an 481 Internet address registry, however private-use prefixes can also 482 be used subject to certain limitations (see: Section 10). OMNI 483 links that connect to the global Internet advertise their MSPs to 484 their interdomain routing peers. 486 Mobile Network Prefix (MNP) 487 a longer IP prefix delegated from an MSP (e.g., 488 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and assigned to a 489 Client. Clients receive MNPs from Proxy/Servers and sub-delegate 490 them to routers, Hosts and other Clients located in ENETs. 492 original IP packet 493 a whole IP packet or fragment admitted into the OMNI interface by 494 the network layer prior to OAL encapsulation and fragmentation, or 495 an IP packet delivered to the network layer by the OMNI interface 496 following OAL decapsulation and reassembly. 498 OAL packet 499 an original IP packet encapsulated in an IPv6 header (i.e., the 500 OAL header) then submitted for OAL fragmentation and reassembly. 502 OAL fragment 503 a portion of an OAL packet following fragmentation but prior to 504 encapsulation, or following encapsulation but prior to OAL 505 reassembly. 507 (OAL) atomic fragment 508 an OAL packet that does not require fragmentation is always 509 encapsulated as an "atomic fragment" with a Fragment Header with 510 Fragment Offset and More Fragments both set to 0, but with a valid 511 Identification value. 513 (OAL) carrier packet 514 an encapsulated OAL fragment following L2 encapsulation or prior 515 to L2 decapsulation. OAL sources and destinations exchange 516 carrier packets over underlay interfaces, and may be separated by 517 one or more OAL intermediate nodes. OAL intermediate nodes may 518 perform re-encapsulation on carrier packets by removing the L2 519 headers of the first hop network and replacing them with new L2 520 headers for the next hop network. (The term "carrier" honors 521 agents of the service postulated by [RFC1149] and [RFC6214].) 523 OAL source 524 an OMNI interface acts as an OAL source when it encapsulates 525 original IP packets to form OAL packets, then performs OAL 526 fragmentation and encapsulation to create carrier packets. 528 OAL destination 529 an OMNI interface acts as an OAL destination when it decapsulates 530 carrier packets, then performs OAL reassembly and decapsulation to 531 derive the original IP packet. 533 OAL intermediate node 534 an OMNI interface acts as an OAL intermediate node when it removes 535 the L2 encapsulation headers of carrier packets received on a 536 first segment, then re-encapsulates the carrier packets in new L2 537 encapsulation headers and forwards them into the next segment. 539 OMNI Option 540 an IPv6 Neighbor Discovery option providing multilink parameters 541 for the OMNI interface as specified in Section 12. 543 Interface Identifier (IID) 544 the least significant 64 bits of an IPv6 address, as specified in 545 the IPv6 addressing architecture [RFC4291]. 547 Link Local Address (LLA) 548 an IPv6 address beginning with fe80::/64 per the IPv6 addressing 549 architecture [RFC4291] and with either a 64-bit MNP (LLA-MNP) or a 550 56-bit random value (LLA-RND) encoded in the IID as specified in 551 Section 8. 553 Unique Local Address (ULA) 554 an IPv6 address beginning with fd00::/8 followed by a 40-bit 555 Global ID followed by a 16-bit Subnet ID per [RFC4193] and with 556 either a 64-bit MNP (ULA-MNP) or a 56-bit random value (ULA-RND) 557 encoded in the IID as specified in Section 9. (Note that 558 [RFC4193] specifies a second form of ULAs based on the prefix 559 fc00::/8, which are referred to as "ULA-C" throughout this 560 document to distinguish them from the ULAs defined here.) 562 Temporary Local Address (TLA) 563 a ULA beginning with fd00::/16 followed by a 48-bit randomly- 564 initialized value followed by an MNP-based (TLA-MNP) or random 565 (TLA-RND) IID as specified in Section 9. Clients use TLAs to 566 bootstrap autoconfiguration in the presence of OMNI link 567 infrastructure or for sustained communications in the absence of 568 infrastructure. (Note that in some environments Clients can 569 instead use a (Hierarchical) Host Identity Tag ((H)HIT) instead of 570 a TLA - see: Section 22.) 572 eXtended Local Address (XLA) 573 a TLA beginning with fd00::/64 followed by an MNP-based (XLA-MNP) 574 or random (XLA-RND) IID as specified in Section 9. An XLA is 575 simply a TLA with an all-0 48-bit value following fd00::/16, and 576 can be used to supply a "wildcard match" for IPv6 ND cache 577 entries, a routing table entry for the OMNI link routing system, 578 etc. (Note that XLAs can also be statelessly formed from LLAs 579 (and vice-versa) simply by inverting prefix bits 7 and 8.) 581 Multilink 582 a Client OMNI interface's manner of managing multiple diverse *NET 583 underlay interfaces as a single logical unit. The OMNI interface 584 provides a single unified interface to upper layers, while 585 underlay interface selections are performed on a per-packet basis 586 considering traffic selectors such as DSCP, flow label, 587 application policy, signal quality, cost, etc. Multilink 588 selections are coordinated in both the outbound and inbound 589 directions based on source/target underlay interface pairs. 591 Multinet 592 an intermediate node's manner of spanning multiple diverse IP 593 Internetwork and/or private enterprise network "segments" at the 594 OAL layer below IP. Through intermediate node concatenation of 595 SRT network segments, multiple diverse Internetworks (such as the 596 global public IPv4 and IPv6 Internets) can serve as transit 597 segments in an end-to-end L2 forwarding path. This OAL 598 concatenation capability provides benefits such as supporting 599 IPv4/IPv6 transition and coexistence, joining multiple diverse 600 operator networks into a cooperative single service network, etc. 601 See: [I-D.templin-6man-aero] for further information. 603 Multihop 604 an iterative relaying of IP packets between Client's over an OMNI 605 underlay interface technology (such as omnidirectional wireless) 606 without support of fixed infrastructure. Multihop services entail 607 Client-to-Client relaying within a Mobile/Vehicular Ad-hoc Network 608 (MANET/VANET) for Vehicle-to-Vehicle (V2V) communications and/or 609 for Vehicle-to-Infrastructure (V2I) "range extension" where 610 Clients within range of communications infrastructure elements 611 provide forwarding services for other Clients. 613 Mobility 614 any action that results in a change to a Client underlay interface 615 address. The change could be due to, e.g., a handover to a new 616 wireless base station, loss of link due to signal fading, an 617 actual physical node movement, etc. 619 Safety-Based Multilink (SBM) 620 A means for ensuring fault tolerance through redundancy by 621 connecting multiple OMNI interfaces within the same domain to 622 independent routing topologies (i.e., multiple independent OMNI 623 links). 625 Performance Based Multilink (PBM) 626 A means for selecting one or more underlay interface(s) for packet 627 transmission and reception within a single OMNI interface. 629 OMNI Domain 630 The set of all SBM/PBM OMNI links that collectively provides 631 services for a common set of MSPs. All OMNI links within the same 632 domain configure, advertise and respond to the same OMNI IPv6 633 Anycast address(es). 635 Multilink Forwarding Information Base (MFIB) 636 A forwarding table on each OMNI source, destination and 637 intermediate node that includes Multilink Forwarding Vectors (MFV) 638 with both next hop forwarding instructions and context for 639 reconstructing compressed headers for specific underlay interface 640 pairs used to communicate with peers. See: 641 [I-D.templin-6man-aero] for further discussion. 643 Multilink Forwarding Vector (MFV) 644 An MFIB entry that includes soft state for each underlay interface 645 pairwise communication session between peers. MFVs are identified 646 by both a next-hop and previous-hop MFV Index (MFVI), with the 647 next-hop established based on an IPv6 ND solicitation and the 648 previous hop established based on the solicited IPv6 ND 649 advertisement response. See: [I-D.templin-6man-aero] for further 650 discussion. 652 Multilink Forwarding Vector Index (MVFI) 653 A 4 octet value selected by an OMNI node when it creates an MFV, 654 then advertised to either a next-hop or previous-hop. OMNI 655 intermediate nodes assign two distinct MFVIs for each MFV and 656 advertise one to the next-hop and the other to the previous-hop. 657 OMNI end systems assign and advertise a single MFVI. See: 658 [I-D.templin-6man-aero] for further discussion. 660 IP Jumbogram 661 an IPv4 or IPv6 packet with a Jumbo Payload option that includes a 662 32-bit length field to be used instead of the 16-bit {Total, 663 Payload} Length field (see: Section 5.1). For IPv4, the Total 664 Length field must be set to the length of the IPv4 header only. 665 For IPv6, the Payload Length must be set to 0. 667 IP Parcel 668 a special form of an IP Jumbogram with a segment length value 669 included in the {Total, Payload} Length field and also with a 670 Jumbo Payload option (see: Section 5.2). 672 INADDR 673 the IP address (and also the UDP port number when UDP is used) 674 that appears in (L2) encapsulation headers in the data plane and 675 in IPv6 ND OMNI option sub-options in the control plane. 677 3. Requirements 679 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 680 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 681 "OPTIONAL" in this document are to be interpreted as described in BCP 682 14 [RFC2119][RFC8174] when, and only when, they appear in all 683 capitals, as shown here. 685 An implementation is not required to internally use the architectural 686 constructs described here so long as its external behavior is 687 consistent with that described in this document. 689 4. Overlay Multilink Network (OMNI) Interface Model 691 An OMNI interface is a virtual interface configured over one or more 692 underlay interfaces, which may be physical (e.g., an aeronautical 693 radio link, etc.) or virtual (e.g., an Internet or higher-layer 694 "tunnel"). The OMNI interface architectural layering model is the 695 same as in [RFC5558][RFC7847], and augmented as shown in Figure 1. 696 The IP layer therefore sees the OMNI interface as a single L3 697 interface nexus for multiple underlay interfaces that appear as L2 698 communication channels in the architecture. 700 +----------------------------+ 701 | Upper Layer Protocol | 702 Session-to-IP +---->| | 703 Address Binding | +----------------------------+ 704 +---->| IP (L3) | 705 IP Address +---->| | 706 Binding | +----------------------------+ 707 +---->| OMNI Interface | 708 Logical-to- +---->| (OMNI Adaptation Layer) | 709 Physical | +----------------------------+ 710 Interface +---->| L2 | L2 | | L2 | 711 Binding |(IF#1)|(IF#2)| ..... |(IF#n)| 712 +------+------+ +------+ 713 | L1 | L1 | | L1 | 714 | | | | | 715 +------+------+ +------+ 717 Figure 1: OMNI Interface Architectural Layering Model 719 Each underlay interface provides an L2/L1 abstraction according to 720 one of the following models: 722 * ANET interfaces connect to a protected and secured ANET that is 723 separated from the open INET by Proxy/Servers. The ANET interface 724 may be either on the same L2 link segment as a Proxy/Server, or 725 separated from a Proxy/Server by multiple IP hops. (Note that 726 NATs may appear internally within an ANET or on the Proxy/Server 727 itself and may require NAT traversal the same as for the INET 728 case.) 730 * INET interfaces connect to an INET either natively or through one 731 or several IPv4 Network Address Translators (NATs). Native INET 732 interfaces have global IP addresses that are reachable from any 733 INET correspondent. NATed INET interfaces typically configure 734 private IP addresses and connect to a private network behind one 735 or more NATs with the outermost NAT providing INET access. 737 * ENET interfaces connect a Client's downstream-attached networks, 738 where the Client provides forwarding services for ENET Host and 739 Client communications to remote peers. An ENET may be as simple 740 as a small stub network that travels with a mobile Client (e.g., 741 an Internet-of-Things) to as complex as a large private enterprise 742 network that the Client connects to a larger ANET or INET. 743 Downstream-attached Hosts and Clients see the ENET as an ANET and 744 see the (upstream) Client as a Proxy/Server. 746 * VPNed interfaces use security encapsulation over an underlay 747 network to a Client or Proxy/Server acting as a Virtual Private 748 Network (VPN) gateway. Other than the link-layer encapsulation 749 format, VPNed interfaces behave the same as for Direct interfaces. 751 * Direct (aka "point-to-point") interfaces connect directly to a 752 Client or Proxy/Server without crossing any networked paths. An 753 example is a line-of-sight link between a remote pilot and an 754 unmanned aircraft. 756 The OMNI interface forwards original IP packets from the network 757 layer (L3) using the OMNI Adaptation Layer (OAL) (see: Section 5) as 758 an encapsulation and fragmentation sublayer service. This "OAL 759 source" then further encapsulates the resulting OAL packets/fragments 760 in underlay network headers (e.g., UDP/IP, IP-only, Ethernet-only, 761 etc.) to create L2-encapsulated "carrier packets" for transmission 762 over underlay interfaces. The target OMNI interface receives the 763 carrier packets from underlay interfaces and discards the L2 764 encapsulation headers. If the resulting OAL packets/fragments are 765 addressed to itself, the OMNI interface acts as an "OAL destination" 766 and performs reassembly if necessary, discards the OAL encapsulation, 767 and delivers the original IP packet to the network layer. If the OAL 768 fragments are addressed to another node, the OMNI interface instead 769 acts as an "OAL intermediate node" by re-encapsulating the carrier 770 packets in new underlay network L2 headers and forwarding them over 771 an underlay interface without reassembling or discarding the OAL 772 encapsulation. The OAL source and OAL destination are seen as 773 "neighbors" on the OMNI link, while OAL intermediate nodes provide a 774 virtual bridging service that joins the segments of a (multinet) 775 Segment Routing Topology (SRT). 777 The OMNI interface can forward original IP packets over underlay 778 interfaces while including/omitting various lower layer 779 encapsulations including OAL, UDP, IP and Ethernet (ETH) or other 780 link-layer header. The network layer can also access the underlay 781 interfaces directly while bypassing the OMNI interface entirely when 782 necessary. This architectural flexibility may be beneficial for 783 underlay interfaces (e.g., some aviation data links) for which 784 encapsulation overhead may be a primary consideration. OMNI 785 interfaces that send original IP packets directly over underlay 786 interfaces without invoking the OAL can only reach peers located on 787 the same OMNI link segment. Source Clients can instead use the OAL 788 to coordinate with target Clients in the same or different OMNI link 789 segments by sending initial carrier packets to a First-Hop Segment 790 (FHS) Proxy/Server. The FHS Proxy/Sever then forwards the packets 791 into the SRT spanning tree, which transports them to a Last-Hop 792 Segment (LHS) Proxy/Server for the target Client. 794 Original IP packets sent directly over underlay interfaces are 795 subject to the same path MTU related issues as for any 796 Internetworking path, and do not include per-packet identifications 797 that can be used for data origin verification and/or link-layer 798 retransmissions. Original IP packets presented directly to an 799 underlay interface that exceed the underlay network path MTU are 800 dropped with an ordinary ICMPv6 Packet Too Big (PTB) message 801 returned. These PTB messages are subject to loss [RFC2923] the same 802 as for any non-OMNI IP interface. 804 The OMNI interface encapsulation/decapsulation layering possibilities 805 are shown in Figure 2 below. Imaginary vertical lines drawn between 806 the Network Layer and Underlay interfaces in the figure denote the 807 encapsulation/decapsulation layering combinations possible. Common 808 combinations include IP-only (i.e., direct access to underlay 809 interfaces with or without using the OMNI interface), IP/IP, IP/UDP/ 810 IP, IP/UDP/IP/ETH(ERNET), IP/OAL/UDP/IP, IP/OAL/UDP/ETH, etc. 812 +------------------------------------------------------------+ ^ 813 | Network Layer (Original IP packets) | | 814 +--+---------------------------------------------------------+ L3 815 | OMNI Interface (virtual sublayer nexus) | | 816 +--------------------------+------------------------------+ - 817 | OAL Encaps/Decaps | | 818 +------------------------------+ OAL 819 | OAL Frag/Reass | | 820 +------------+---------------+--------------+ - 821 | UDP Encaps/Decaps/Compress | | 822 +----+---+------------+--------+--+ +--------+ | 823 | IP E/D | | IP E/D | | IP E/D | L2 824 +----+-----+--+----+ +--+----+---+ +---+----+--+ | 825 |ETH E/D| |ETH E/D| |ETH E/D| |ETH E/D| | 826 +------+-------+--+-------+----+-------+-------------+-------+ v 827 | Underlay Interfaces | 828 +------------------------------------------------------------+ 830 Figure 2: OMNI Interface Layering 832 The OMNI/OAL model gives rise to a number of opportunities: 834 * Clients receive MNPs from the MS, and coordinate with the MS 835 through IPv6 ND message exchanges with Proxy/Servers. Clients use 836 the MNP to construct a unique Link-Local Address (LLA-MNP) through 837 the algorithmic derivation specified in Section 8 and assign the 838 LLA to the OMNI interface. Since LLA-MNPs are uniquely derived 839 from an MNP, no Duplicate Address Detection (DAD) or Multicast 840 Listener Discovery (MLD) messaging is necessary. 842 * since Temporary ULAs with random IIDs (TLA-RNDs) are statistically 843 unique, they can be used without DAD until an MNP is obtained. 845 * underlay interfaces on the same L2 link segment as a Proxy/Server 846 do not require any L3 addresses (i.e., not even link-local) in 847 environments where communications are coordinated entirely over 848 the OMNI interface. 850 * as underlay interface properties change (e.g., link quality, cost, 851 availability, etc.), any active interface can be used to update 852 the profiles of multiple additional interfaces in a single 853 message. This allows for timely adaptation and service continuity 854 under dynamically changing conditions. 856 * coordinating underlay interfaces in this way allows them to be 857 represented in a unified MS profile with provisions for mobility 858 and multilink operations. 860 * exposing a single virtual interface abstraction to the IPv6 layer 861 allows for multilink operation (including QoS based link 862 selection, packet replication, load balancing, etc.) at L2 while 863 still permitting L3 traffic shaping based on, e.g., DSCP, flow 864 label, etc. 866 * the OMNI interface allows multinet traversal over the SRT when 867 communications across different administrative domain network 868 segments are necessary. This mode of operation would not be 869 possible via direct communications over the underlay interfaces 870 themselves. 872 * the OAL supports lossless and adaptive path MTU mitigations not 873 available for communications directly over the underlay interfaces 874 themselves. The OAL supports "packing" of multiple IP payload 875 packets within a single OAL "super-packet" and also supports 876 transmission of IP packets and parcels of all sizes up to and 877 including Jumbograms. 879 * the OAL applies per-packet identification values that allow for 880 link-layer reliability and data origin authentication. 882 * L3 sees the OMNI interface as a point of connection to the OMNI 883 link; if there are multiple OMNI links, L3 will see multiple OMNI 884 interfaces. 886 * Multiple independent OMNI interfaces can be used for increased 887 fault tolerance through Safety-Based Multilink (SBM), with 888 Performance-Based Multilink (PBM) applied within each interface. 890 * Multiple independent OMNI links can be joined together into a 891 single link without requiring renumbering of infrastructure 892 elements, since the ULAs assigned to the different links will be 893 mutually exclusive. 895 * the OMNI/OAL model supports transmission of a new form of IP 896 packets known as "IP Parcels" that improve performance and 897 efficiency for both upper layer protocols and networked paths. 899 Note that even when the OMNI virtual interface is present, 900 applications can still access underlay interfaces either through the 901 network protocol stack using an Internet socket or directly using a 902 raw socket. This allows for intra-network (or point-to-point) 903 communications without invoking the OMNI interface and/or OAL. For 904 example, when an OMNI interface is configured over an underlay IP 905 interface, applications can still invoke intra-network IP 906 communications directly over the underlay interface as long as the 907 communicating endpoints are not subject to mobility dynamics. 909 Figure 3 depicts the architectural model for a source Client with an 910 attached ENET connecting to the OMNI link via multiple independent 911 ANETs/INETs (i.e., *NETs). The Client's OMNI interface sends IPv6 ND 912 solicitation messages over available *NET underlay interfaces using 913 any necessary L2 encapsulations. The IPv6 ND messages traverse the 914 *NETs until they reach an FHS Proxy/Server (FHS#1, FHS#2, ..., 915 FHS#n), which returns an IPv6 ND advertisement message and/or 916 forwards a proxyed version of the message over the SRT to an LHS 917 Proxy/Server near the target Client (LHS#1, LHS#2, ..., LHS#m). The 918 Hop Limit in IPv6 ND messages is not decremented due to 919 encapsulation; hence, the source and target Client OMNI interfaces 920 appear to be attached to a common link. 922 +--------------+ 923 |Source Client | 924 +--------------+ (:::)-. 925 |OMNI interface|<-->.-(::ENET::) 926 +----+----+----+ `-(::::)-' 927 +--------|IF#1|IF#2|IF#n|------ + 928 / +----+----+----+ \ 929 / | \ 930 / | \ 931 v v v 932 (:::)-. (:::)-. (:::)-. 933 .-(::*NET:::) .-(::*NET:::) .-(::*NET:::) 934 `-(::::)-' `-(::::)-' `-(::::)-' 935 +-----+ +-----+ +-----+ 936 ... |FHS#1| ......... |FHS#2| ......... |FHS#n| ... 937 . +--|--+ +--|--+ +--|--+ . 938 . | | | 939 . \ v / . 940 . \ / . 941 . v (:::)-. v . 942 . .-(::::::::) . 943 . .-(::: Segment :::)-. . 944 . (::::: Routing ::::) . 945 . `-(:: Topology ::)-' . 946 . `-(:::::::-' . 947 . / | \ . 948 . / | \ . 949 . v v v 950 . +-----+ +-----+ +-----+ . 951 ... |LHS#1| ......... |LHS#2| ......... |LHS#m| ... 952 +--|--+ +--|--+ +--|--+ 953 \ | / 954 v v v 955 <-- Target Clients --> 957 Figure 3: Source/Target Client Coordination over the OMNI Link 959 After the initial IPv6 ND message exchange, the source Client (as 960 well as any nodes on its attached ENETs) can send packets to the 961 target Client over the OMNI interface. OMNI interface multilink 962 services will forward the packets via FHS Proxy/Servers for the 963 correct underlay *NETs. The FHS Proxy/Server then forwards the 964 packets over the SRT which delivers them to an LHS Proxy/Server, and 965 the LHS Proxy/Server in turn forwards them to the target Client. 966 (Note that when the source and target Client are on the same SRT 967 segment, the FHS and LHS Proxy/Servers may be one and the same.) 968 Clients select a Hub Proxy/Server (not shown in the figure), which 969 will often be one of their FHS Proxy/Servers but could also be any 970 Proxy/Server on the OMNI link. Clients then register all of their 971 *NET underlay interfaces with the Hub Proxy/Server via the FHS Proxy/ 972 Server in a pure proxy role. The Hub Proxy/Server then provides a 973 designated router service for the Client, and the Client can quickly 974 migrate to a new Hub Proxy/Server if the first becomes unresponsive. 976 Clients therefore use Proxy/Servers as gateways into the SRT to reach 977 OMNI link correspondents via a spanning tree established in a manner 978 outside the scope of this document. Proxy/Servers forward critical 979 MS control messages via the secured spanning tree and forward other 980 messages via the unsecured spanning tree (see Security 981 Considerations). When route optimization is applied as discussed in 982 [I-D.templin-6man-aero], Clients can instead forward directly to SRT 983 intermediate nodes (or directly to correspondents in the same SRT 984 segment) to reduce Proxy/Server load. 986 Note: while not shown in the figure, a Client's ENET may connect many 987 additional Hosts and even other Clients in a recursive extension of 988 the OMNI link. This OMNI virtual link extension will be discussed 989 more fully throughout the document. 991 5. OMNI Interface Maximum Transmission Unit (MTU) 993 The OMNI interface observes the link nature of tunnels, including the 994 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 995 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 996 The OMNI interface is configured over one or more underlay interfaces 997 as discussed in Section 4, where the interfaces (and their associated 998 underlay network paths) may have diverse MTUs. OMNI interface 999 considerations for accommodating original IP packets of various sizes 1000 are discussed in the following sections. 1002 IPv6 underlay interfaces are REQUIRED to configure a minimum MTU of 1003 1280 octets and a minimum MRU of 1500 octets [RFC8200]. Therefore, 1004 the minimum IPv6 path MTU is 1280 octets since routers on the path 1005 are not permitted to perform network fragmentation even though the 1006 destination is required to reassemble more. The network therefore 1007 MUST forward original IP packets of at least 1280 octets without 1008 generating an IPv6 Path MTU Discovery (PMTUD) Packet Too Big (PTB) 1009 message [RFC8201]. (While the source can apply "source 1010 fragmentation" for locally-generated IPv6 packets up to 1500 octets 1011 and larger still if it knows the destination configures a larger MRU, 1012 this does not affect the minimum IPv6 path MTU.) 1013 IPv4 underlay interfaces are REQUIRED to configure a minimum MTU of 1014 68 octets [RFC0791] and a minimum MRU of 576 octets 1015 [RFC0791][RFC1122]. Therefore, when the Don't Fragment (DF) bit in 1016 the IPv4 header is set to 0 the minimum IPv4 path MTU is 576 octets 1017 since routers on the path support network fragmentation and the 1018 destination is required to reassemble at least that much. The OMNI 1019 interface therefore MUST set DF to 0 in the IPv4 encapsulation 1020 headers of carrier packets that are no larger than 576 octets, and 1021 SHOULD set DF to 1 in larger carrier packets unless it has a way to 1022 determine the encapsulation destination MRU and has carefully 1023 considered the issues discussed in Section 6.12. 1025 When the network layer admits an original IP packet into the OMNI 1026 interface the OAL prepends an IPv6 encapsulation header (see: 1027 Section 6) where the 16-bit Payload Length field limits the maximum- 1028 sized original IP packet to (2**16 -1) = 65535 octets; this is also 1029 the maximum size that the OAL can accommodate with IPv6 1030 fragmentation. The OMNI interface therefore sets an MTU and MRU of 1031 65535 octets to support assured delivery of original packets no 1032 larger than this size even if IPv6 fragmentation is required. (The 1033 OMNI interface MAY set a larger MTU to support best-effort delivery 1034 for larger packets; see below.) The OMNI interface then employs the 1035 OAL as an encapsulation sublayer service to transform original IP 1036 packets into OAL packets/fragments, and the OAL in turn uses underlay 1037 network encapsulation to forward carrier packets over underlay 1038 interfaces (see: Section 6). 1040 5.1. Jumbograms 1042 While the maximum-sized original IP packet that the OAL can 1043 accommodate using IPv6 fragmentation is 65535 octets, OMNI interfaces 1044 can forward still larger IPv6 packets as OAL "atomic fragments" 1045 through the application of IPv6 Jumbograms [RFC2675]. For such 1046 larger packets, the OMNI interface performs OAL encapsulation by 1047 appending an IPv6 header followed by an 8-octet Hop-By-Hop header 1048 with Jumbo Payload option followed by a Routing Header of no more 1049 than 40-octets (if necessary) and finally followed by an 8-octet 1050 Fragment Header. 1052 Since the Jumbo Payload option includes a 32-bit length field, OMNI 1053 interfaces can therefore configure a larger IP MTU up to a maximum of 1054 ((2**32 - 1) - 8 - 40 - 8) = 4294967239 octets. In that case, the 1055 OAL will still provide original IP packets no larger than 65535 with 1056 an IPv6 fragmentation-based assured delivery service while larger IP 1057 packets will receive a best-effort delivery service as atomic 1058 fragments (note that the OAL destination is permitted to accept 1059 atomic fragments that exceed the OMNI interface MRU). 1061 The OAL source forwards jumbo atomic fragments under the assumption 1062 that upper and lower layers will employ sufficient integrity 1063 assurance, noting that commonly-used 32-bit CRCs may be inadequate 1064 for these larger sizes [CRC]. If the packet is dropped along the 1065 path to the OAL destination, the OAL source must arrange to return a 1066 PTB "hard error" to the original source Section 6.8. 1068 This document notes that a Jumbogram service for IPv4 is also 1069 specified in [I-D.templin-intarea-parcels], where all OMNI link 1070 aspects of the service are conducted in a similar fashion as for IPv6 1071 above. 1073 5.2. IPv6 Parcels 1075 As specified in [I-D.templin-intarea-parcels], an IP Parcel is a 1076 variation of the IP Jumbogram construction beginning with an IP 1077 header with the length of the first upper layer protocol segment in 1078 the {Total, Payload} Length field, but with a Jumbo Payload option 1079 with a length that may be the same as or larger than the length in 1080 the IP header. The differences in these lengths determines the size 1081 and number of upper layer protocol segments within the parcel. 1083 The IP Parcel format and transmission/reception procedures for OMNI 1084 interfaces are specified in Section 6.14. End systems that implement 1085 either the full OMNI interface (i.e., Clients) or enough of the OAL 1086 to process parcels (i.e., Hosts) are permitted to exchange parcels 1087 with consenting peers. 1089 6. The OMNI Adaptation Layer (OAL) 1091 When an OMNI interface forwards an original IP packet from the 1092 network layer for transmission over one or more underlay interfaces, 1093 the OMNI Adaptation Layer (OAL) acting as the OAL source applies 1094 encapsulation to form OAL packets subject to fragmentation producing 1095 OAL fragments suitable for L2 encapsulation and transmission as 1096 carrier packets over underlay interfaces as described in Section 6.1. 1098 These carrier packets travel over one or more underlay networks 1099 spanned by OAL intermediate nodes in the SRT, which re-encapsulate by 1100 removing the L2 headers of the first underlay network and appending 1101 L2 headers appropriate for the next underlay network in succession. 1102 (This process supports the multinet concatenation capability needed 1103 for joining multiple diverse networks.) After re-encapsulation by 1104 zero or more OAL intermediate nodes, the carrier packets arrive at 1105 the OAL destination. 1107 When the OAL destination receives the carrier packets, it discards 1108 the L2 headers and reassembles the resulting OAL fragments (if 1109 necessary) into an OAL packet as described in Section 6.3. The OAL 1110 destination next decapsulates the OAL packet to obtain the original 1111 IP packet then delivers the original IP packet to the network layer. 1112 The OAL source may be either the source Client or its FHS Proxy/ 1113 Server, while the OAL destination may be either the LHS Proxy/Server 1114 or the target Client. Proxy/Servers (and SRT Gateways as discussed 1115 in [I-D.templin-6man-aero]) may also serve as OAL intermediate nodes. 1117 The OAL presents an OMNI sublayer abstraction similar to ATM 1118 Adaptation Layer 5 (AAL5). Unlike AAL5 which performs segmentation 1119 and reassembly with fixed-length 53 octet cells over ATM networks, 1120 however, the OAL uses IPv6 encapsulation, fragmentation and 1121 reassembly with larger variable-length cells over heterogeneous 1122 underlay networks. Detailed operations of the OAL are specified in 1123 the following sections. 1125 6.1. OAL Source Encapsulation and Fragmentation 1127 When the network layer forwards an original IP packet into the OMNI 1128 interface, the OAL source creates an "OAL packet" by prepending an 1129 IPv6 OAL encapsulation header per [RFC2473] but does not decrement 1130 the Hop Limit/TTL of the original IP packet since encapsulation 1131 occurs at a layer below IP forwarding. The OAL source copies the 1132 "Type of Service/Traffic Class" [RFC2983] and "Explicit Congestion 1133 Notification (ECN)" [RFC3168] values in the original packet's IP 1134 header into the corresponding fields in the OAL header, then sets the 1135 OAL header "Flow Label" as specified in [RFC6438]. The OAL source 1136 finally sets the OAL header IPv6 Payload Length to the length of the 1137 original IP packet and sets Hop Limit to a value that MUST NOT be 1138 larger than 63 yet is still sufficiently large to enable loop-free 1139 forwarding over multiple concatenated OMNI link intermediate hops. 1141 The OAL next selects OAL packet source and destination addresses. 1142 Client OMNI interfaces set the OAL source address to a Unique Local 1143 Address (ULA) based on the Mobile Network Prefix (ULA-MNP). When a 1144 Client OMNI interface does not (yet) have a ULA prefix and/or an MNP 1145 suffix, it can instead use a Temporary ULA (TLA) (or a (Hierarchical) 1146 Host Identity Tag ((H)HIT - see: Section 22) as an OAL address. 1147 Finally, when the Client needs to express its MNP outside the context 1148 of a specific ULA prefix, it can use an eXtended ULA (XLA). Proxy/ 1149 Server OMNI interfaces instead set the source address to a Random ULA 1150 (ULA-RND) (see: Section 9), but also process packets with anycast 1151 and/or multicast OAL addresses that they are configured to 1152 recognize.) 1153 The OAL source next selects a 32-bit OAL packet Identification value 1154 as specified in Section 6.6. The OAL then calculates a 2-octet OAL 1155 checksum using the algorithm specified in Appendix A. The OAL source 1156 calculates the checksum over the OAL packet beginning with a pseudo- 1157 header of the OAL header similar to that found in Section 8.1 of 1158 [RFC8200], then extending over the entire length of the original IP 1159 packet. The OAL pseudo-header is formed as shown in Figure 4: 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | | 1163 + + 1164 | | 1165 + OAL Source Address + 1166 | | 1167 + + 1168 | | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | | 1171 + + 1172 | | 1173 + OAL Destination Address + 1174 | | 1175 + + 1176 | | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | OAL Payload Length | zero | Next Header | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Identification | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 Figure 4: OAL Pseudo-Header 1185 After calculating the checksum, the OAL source next fragments the OAL 1186 packet if necessary while assuming the IPv4 minimum path MTU (i.e., 1187 576 octets) as the worst case for OAL fragmentation regardless of the 1188 underlay interface IP protocol version since IPv6/IPv4 protocol 1189 translation and/or IPv6-in-IPv4 encapsulation may occur in any 1190 underlay network path. By initially assuming the IPv4 minimum even 1191 for IPv6 underlay interfaces, the OAL source may produce smaller 1192 fragments with additional encapsulation overhead but avoids loss due 1193 to presenting an underlay interface with a carrier packet that 1194 exceeds its MRU. Additionally, the OAL path could traverse multiple 1195 SRT segments with intermediate OAL forwarding nodes performing re- 1196 encapsulation where the L2 encapsulation of the previous segment is 1197 replaced by the L2 encapsulation of the next segment which may be 1198 based on a different IP protocol version and/or encapsulation sizes. 1200 The OAL source therefore assumes a default minimum path MTU of 576 1201 octets at each SRT segment for the purpose of generating OAL 1202 fragments for L2 encapsulation and transmission as carrier packets. 1203 Each successive SRT intermediate node may include either a 20 octet 1204 IPv4 or 40 octet IPv6 header, an 8 octet UDP header and in some cases 1205 an IP security encapsulation (40 octets maximum assumed) during re- 1206 encapsulation. Intermediate nodes at any SRT segment may also insert 1207 or modify the Routing Header (40 octets maximum) following the 40 1208 octet OAL IPv6 header and preceding the 8 octet Fragment Header. 1209 Therefore, assuming a worst case of (40 + 40 + 8) = 88 octets for L2 1210 encapsulations plus (40 + 40 + 8) = 88 octets for OAL encapsulation 1211 leaves no less than (576 - 88 - 88) = 400 octets remaining to 1212 accommodate a portion of the original IP packet/fragment. The OAL 1213 source therefore sets a minimum Maximum Payload Size (MPS) of 400 1214 octets as the basis for the minimum-sized OAL fragment that can be 1215 assured of traversing all SRT segments without loss due to an MTU/MRU 1216 restriction. The Maximum Fragment Size (MFS) for OAL fragmentation 1217 is therefore determined by the MPS plus the size of the OAL 1218 encapsulation headers. 1220 The OAL source SHOULD maintain "path MPS" values for individual OAL 1221 destinations initialized to the minimum MPS and increased to larger 1222 values if better information is known or discovered. For example, 1223 when peers share a common underlay network link or a fixed path with 1224 a known larger MTU, the OAL source can set path MPS to a larger size 1225 (i.e., greater than 400 octets) as long as the peer reassembles 1226 before re-encapsulating and forwarding (while re-fragmenting if 1227 necessary). Also, if the OAL source has a way of knowing the maximum 1228 L2 encapsulation size for all SRT segments along the path it may be 1229 able to increase path MPS to reserve additional room for payload 1230 data. Even when OAL header compression is used, the OAL source must 1231 include the uncompressed OAL header size in its path MPS calculation 1232 since it may need to include a full header at any time. 1234 The OAL source can also optimistically set a larger path MPS and/or 1235 actively probe individual OAL destinations to discover larger sizes 1236 using packetization layer probes in a similar fashion as 1237 [RFC4821][RFC8899], but care must be taken to avoid setting static 1238 values for dynamically changing paths leading to black holes. The 1239 probe involves sending an OAL packet larger than the current path MPS 1240 and receiving a small acknowledgement response (with the possible 1241 receipt of link-layer error message when a probe is lost). For this 1242 purpose, the OAL source can send an NS message with one or more OMNI 1243 options with large PadN sub-options (see: Section 12) and/or with a 1244 trailing large NULL packet in a super-packet (see: Section 6.9) in 1245 order to receive a small NA response from the OAL destination. While 1246 observing the minimum MPS will always result in robust and secure 1247 behavior, the OAL source should optimize path MPS values when more 1248 efficient utilization may result in better performance (e.g. for 1249 wireless aviation data links). The OAL source should maintain 1250 separate path MPS values for each (source, target) underlay interface 1251 pair for the same OAL destination, since different underlay interface 1252 pairs may support differing path MPS values. 1254 When the OAL source performs fragmentation, it SHOULD produce the 1255 minimum number of non-overlapping fragments under current MPS 1256 constraints, where each non-final fragment MUST be at least as large 1257 as the minimum MPS, while the final fragment MAY be smaller. The OAL 1258 source also converts all original IP packets no larger than the 1259 current MPS (or larger than 65535 octets) into atomic fragments by 1260 including a Fragment Header with Fragment Offset and More Fragments 1261 both set to 0. The OAL source then inserts a Routing Header (if 1262 necessary) following the IPv6 encapsulation header and before the 1263 Fragment Header. If the original IP packet is larger than 65535, the 1264 OAL source also inserts a Hop-By-Hop header with Jumbo Payload option 1265 immediately following the IPv6 encapsulation header and before the 1266 Routing Header (if necessary), then includes an (atomic) Fragment 1267 Header. The header extension order for each fragment therefore 1268 appears as the OAL IPv6 header followed by Hop-By-Hop header followed 1269 by Routing Header followed by Fragment Header. 1271 The OAL source next appends the OAL checksum as the final two octets 1272 of the final fragment while increasing its (Jumbo) Payload Length by 1273 2. If appending the checksum would cause the final fragment to 1274 exceed the current MPS, the OAL source instead reduces this "former" 1275 final fragment's Payload Length (PL) by (N*8 + (PL mod 8)) octets, 1276 where N is an integer that would result in a non-zero reduction but 1277 without causing the former final fragment to become smaller than the 1278 minimum MPS. The OAL source then creates a "new" final fragment by 1279 copying the OAL IPv6 header and extension headers from the former 1280 final fragment, then copying the (N*8 + (PL mod 8)) octets from the 1281 end of the former final fragment immediately following the new final 1282 fragment extension headers. The OAL source then sets the former 1283 final fragment's More Fragments flag to 1, increments the new final 1284 fragment's fragment offset by the former final fragment's new (PL / 1285 8) and finally appends the checksum the same as discussed above. 1287 Next, the OAL source replaces the IPv6 Fragment Header 1-octet 1288 "Reserved" field (and for first fragments also the 2-bit "Reserved 1289 Flags" field) with OMNI-specific encodings as shown in: 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Next Header | Parcel ID |A| Fragment Offset |P|S|M| 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Identification | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 a) First fragment 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Next Header | Ordinal |A| Fragment Offset |Res|M| 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Identification | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 a) Non-first fragment 1305 Figure 5: IPv6 Fragment Header Reserved Fields Redefined 1307 For the first fragment, the OAL source sets the "(A)RQ" flag then 1308 sets "Parcel ID", "(P)arcel" and "(S)ub-Parcels" as specified in 1309 Section 6.14. For each non-first fragment, the OAL source instead 1310 sets the "(A)RQ" flag and writes a monotonically-increasing "Ordinal" 1311 value between 1 and 127. Specifically, the OAL source writes the 1312 ordinal number '1' for the first non-first fragment, '2' for the 1313 second, '3' for the third, etc. up to the final fragment or the 1314 ordinal value '127', whichever comes first. (For any additional non- 1315 first fragments beyond ordinal '127', the OAL source instead writes 1316 the value '0' in the Ordinal field and clears the "(A)RQ" flag. The 1317 first fragment is implicitly always considered ordinal number '0' 1318 even though the header does not include an explicit Ordinal field.) 1320 The OAL source finally encapsulates the fragments in L2 headers to 1321 form carrier packets and forwards them over an underlay interface, 1322 while retaining the fragments and their ordinal numbers (i.e., #0, 1323 #1, #2, etc. up to #127) for a brief period to support link-layer 1324 retransmissions (see: Section 6.7). OAL fragment and carrier packet 1325 formats are shown in Figure 6. 1327 +----------+----------------+ 1328 |OAL Header| Frag #0 | 1329 +----------+----------------+ 1330 +----------+----------------+ 1331 |OAL Header| Frag #1 | 1332 +----------+----------------+ 1333 +----------+----------------+ 1334 |OAL Header| Frag #2 | 1335 +----------+----------------+ 1336 .... 1337 +----------+----------------+----+ 1338 |OAL Header| Frag #(N-1) |Csum| 1339 +----------+----------------+----+ 1340 a) OAL fragmentation (Csum in final fragment) 1342 +----------+-----+-----+-----+-----+-----+----+ 1343 |OAL Header| Original IP packet |Csum| 1344 +----------+-----+-----+-----+-----+-----+----+ 1345 b) An OAL atomic fragment 1347 +--------+----------+----------------+ 1348 |L2 Hdrs |OAL Header| Frag #i | 1349 +--------+----------+----------------+ 1350 c) OAL carrier packet after L2 encapsulation 1352 Figure 6: OAL Fragments and Carrier Packets 1354 Note: the minimum MPS assumes that any middleboxes (e.g. IPv4 NATs) 1355 that connect private networks with path MTUs smaller than 576 octets 1356 must reassemble any fragmented (outbound) IPv4 carrier packets sent 1357 by OAL sources before forwarding them to external Internetworks since 1358 middleboxes that connect OAL destinations often unconditionally drop 1359 (inbound) IPv4 fragments. However, when the path MTU in the 1360 destination private network is small, the OAL destination itself will 1361 be able to reassemble any IPv4 fragmentation that occurs in the 1362 inbound path. 1364 6.2. OAL L2 Encapsulation and Re-Encapsulation 1366 The OAL source or intermediate node next encapsulates each OAL 1367 fragment (with either full or compressed headers) in L2 encapsulation 1368 headers to create a carrier packet. The OAL source or intermediate 1369 node (i.e., the L2 source) includes a UDP header as the innermost 1370 sublayer if NAT traversal and/or packet filtering middlebox traversal 1371 are required; otherwise, the L2 source includes either a full or 1372 compressed IP header and/or an actual link-layer header (e.g., such 1373 as for Ethernet-compatible links). The L2 source then appends any 1374 additional encapsulation sublayer headers necessary and presents the 1375 resulting carrier packet to an underlay interface, where the underlay 1376 network conveys it to a next-hop OAL intermediate node or destination 1377 (i.e., the L2 destination). 1379 The L2 source encapsulates the OAL information immediately following 1380 the innermost L2 sublayer header. If the first four bits of the 1381 encapsulated OAL information following the innermost sublayer header 1382 encode the value '6', the information must include an uncompressed 1383 IPv6 header (plus extensions) followed by upper layer protocol 1384 headers and data. If the first four bits encode the value '4', an 1385 uncompressed IPv4 header (plus extensions) followed by upper layer 1386 protocol headers and data follows. Otherwise, the first four bits 1387 include a "Type" value, and the OAL information appears in an 1388 alternate format as specified in Section 6.4 (Types '0' and '1' are 1389 currently specified while all other values are reserved for future 1390 use). Carrier packets that contain an unrecognized Type value are 1391 unconditionally dropped. 1393 The OAL node prepares the innermost L2 encapsulation header for OAL 1394 packets as follows: 1396 * For UDP encapsulation, the L2 source sets the UDP source port to 1397 8060 (i.e., the port number reserved for AERO/OMNI). When the L2 1398 destination is a Proxy/Server or Gateway, the L2 source sets the 1399 UDP destination port to 8060; otherwise, the L2 source sets the 1400 UDP destination port to its cached port number value for the peer. 1401 The L2 source finally sets the UDP Length the same as specified in 1402 [RFC0768]. (If the OAL packet includes an IP Jumbogram, the L2 1403 source instead sets the UDP length to 0 and includes a Jumbo 1404 Payload option in the L2 IP header.) 1406 * For IP encapsulation, the L2 source sets the IP {Protocol, Next- 1407 Header} to TBD1 (see: IANA Considerations) and sets the {Total, 1408 Payload} Length the same as specified in [RFC0791] or [RFC8200]. 1409 (If the OAL packet includes a true Jumbogram, the L2 source 1410 includes a Jumbo Payload option and sets {Total, Payload} Length 1411 plus the Jumbo Payload length according to the OAL length 1412 information.) 1414 * For direct encapsulations over Ethernet-compatible links, the 1415 EtherType is set to TBD2 (see: IANA Considerations). Since the 1416 Ethernet header does not include a length field, for the OMNI 1417 EtherType the Ethernet header is followed by a four-octet Payload 1418 Length field followed immediately by the encapsulated OAL 1419 information. The Payload Length field encodes the length in 1420 octets (in network byte order) of the OAL information exclusive of 1421 the lengths of the Ethernet header and trailer. 1423 When an L2 source includes a UDP header, it SHOULD calculate and 1424 include a UDP checksum in carrier packets with full OAL headers to 1425 prevent mis-delivery, and MAY disable UDP checksums in carrier 1426 packets with compressed OAL headers (see: Section 6.4). If the L2 1427 source discovers that a path is dropping carrier packets with UDP 1428 checksums disabled, it should enable UDP checksums in future carrier 1429 packets sent to the same L2 destination. If the L2 source discovers 1430 that a path is dropping carrier packets that do not include a UDP 1431 header, it should include a UDP header in future carrier packets. 1433 When an L2 source sends carrier packets with compressed OAL headers 1434 and with UDP checksums disabled, mis-delivery due to corruption of 1435 the 4-octet Multilink Forwarding Vector Index (MFVI) is possible but 1436 unlikely since the corrupted index would somehow have to match valid 1437 state in the (sparsely-populated) Multilink Forwarding Information 1438 Based (MFIB). In the unlikely event that a match occurs, an OAL 1439 destination may receive a mis-delivered carrier packet but can 1440 immediately reject packets with an incorrect Identification. If the 1441 Identification value is somehow accepted, the OAL destination may 1442 submit the mis-delivered carrier packet to the reassembly cache where 1443 it will most likely be rejected due to incorrect reassembly 1444 parameters. If a reassembly that includes the mis-delivered carrier 1445 packets somehow succeeds (or, for atomic fragments) the OAL 1446 destination will verify the OAL checksum to detect corruption. 1447 Finally, any spurious data that somehow eludes all prior checks will 1448 be detected and rejected by end-to-end upper layer integrity checks. 1449 See: [RFC6935][RFC6936] for further discussion. 1451 For L2 encapsulations over IP, when the L2 source is also the OAL 1452 source it next copies the "Type of Service/Traffic Class" [RFC2983] 1453 and "Explicit Congestion Notification (ECN)" [RFC3168] values in the 1454 OAL header into the corresponding fields in the L2 IP header, then 1455 (for IPv6) set the L2 IPv6 header "Flow Label" as specified in 1456 [RFC6438]. The L2 source then sets the L2 IP TTL/Hop Limit the same 1457 as for any host (i.e., it does not copy the Hop Limit value from the 1458 OAL header) and finally sets the source and destination IP addresses 1459 to direct the carrier packet to the next hop. For carrier packets 1460 undergoing re-encapsulation, the OAL intermediate node L2 source 1461 decrements the OAL header Hop Limit and discards the carrier packet 1462 if the value reaches 0. The L2 source then copies the "Type of 1463 Service/Traffic Class" and "Explicit Congestion Notification (ECN)" 1464 values from the previous hop L2 encapsulation header into the OAL 1465 header (if present), then finally sets the source and destination IP 1466 addresses the same as above. 1468 Following L2 encapsulation/re-encapsulation, the L2 source forwards 1469 the resulting carrier packets over one or more underlay interfaces. 1470 The underlay interfaces often connect directly to physical media on 1471 the local platform (e.g., a laptop computer with WiFi, etc.), but in 1472 some configurations the physical media may be hosted on a separate 1473 Local Area Network (LAN) node. In that case, the OMNI interface can 1474 establish a Layer-2 VLAN or a point-to-point tunnel (at a layer below 1475 the underlay interface) to the node hosting the physical media. The 1476 OMNI interface may also apply encapsulation at the underlay interface 1477 layer (e.g., as for a tunnel virtual interface) such that carrier 1478 packets would appear "double-encapsulated" on the LAN; the node 1479 hosting the physical media in turn removes the LAN encapsulation 1480 prior to transmission or inserts it following reception. Finally, 1481 the underlay interface must monitor the node hosting the physical 1482 media (e.g., through periodic keepalives) so that it can convey 1483 up/down/status information to the OMNI interface. 1485 6.3. OAL L2 Decapsulation and Reassembly 1487 When an OMNI interface receives a carrier packet from an underlay 1488 interface, it copies the ECN value from the L2 encapsulation headers 1489 into the OAL header if the carrier packet contains a first-fragment. 1490 The OMNI interface next discards the L2 encapsulation headers and 1491 examines the OAL header of the enclosed OAL fragment. If the OAL 1492 fragment is addressed to a different node, the OMNI interface (acting 1493 as an OAL intermediate node) re-encapsulates and forwards while 1494 decrementing the OAL Hop Limit as discussed in Section 6.2. If the 1495 OAL fragment is addressed to itself, the OMNI interface (acting as an 1496 OAL destination) accepts or drops the fragment based on the (Source, 1497 Destination, Identification)-tuple and/or integrity checks. 1499 The OAL destination next drops all non-final OAL fragments smaller 1500 than the minimum MPS and all fragments that would overlap or leave 1501 "holes" smaller than the minimum MPS with respect to other fragments 1502 already received. The OAL destination updates a checklist of 1503 accepted fragments of the same OAL packet that include an Ordinal 1504 number (i.e., Ordinals 0 through 127), but admits all accepted 1505 fragments into the reassembly cache after first removing any 1506 extension headers except for the fragment header itself. When the 1507 OAL destination receives the final fragment (i.e., the one with More 1508 Fragments set to 0), it caches the trailing checksum and reduces the 1509 Payload Length by 2. When reassembly is complete, the OAL 1510 destination verifies the OAL packet checksum and discards the packet 1511 if the checksum is incorrect. If the OAL packet was accepted, the 1512 OAL destination finally removes the OAL headers and delivers the 1513 original IP packet to the network layer. 1515 Carrier packets often travel over paths where all links in the path 1516 include CRC-32 integrity checks for effective hop-by-hop error 1517 detection for payload sizes up to 9180 octets [CRC], but other paths 1518 may traverse links (such as tunnels over IPv4) that do not include 1519 adequate integrity protection. The OAL checksum therefore allows OAL 1520 destinations to detect reassembly misassociation splicing errors and/ 1521 or carrier packet corruption caused by unprotected links [CKSUM]. 1523 The OAL checksum also provides algorithmic diversity with respect to 1524 both lower layer CRCs and upper layer Internet checksums as part of a 1525 complimentary multi-layer integrity assurance architecture. Any 1526 corruption not detected by lower layer integrity checks is therefore 1527 very likely to be detected by upper layer integrity checks that use 1528 diverse algorithms. 1530 6.4. OAL Header Compression 1532 OAL sources that send carrier packets with full OAL headers include a 1533 CRH-32 extension for segment-by-segment forwarding based on a 1534 Multilink Forwarding Information Base (MFIB) in each OAL intermediate 1535 node. OAL source, intermediate and destination nodes can instead 1536 establish header compression state through IPv6 ND NS/NA message 1537 exchanges. After an initial NS/NA exchange, OAL nodes can apply OAL 1538 Header Compression to significantly reduce encapsulation overhead. 1540 Each OAL node establishes MFIB soft state entries known as Multilink 1541 Forwarding Vectors (MVFs) which support both carrier packet 1542 forwarding and OAL header compression/decompression. For OAL 1543 sources, each MFV is referenced by a single Multilink Forwarding 1544 Vector Index (MFVI) that provides compression/decompression and 1545 forwarding context for the next hop. For OAL destinations, the MFV 1546 is referenced by a single MFVI that provides context for the previous 1547 hop. For OAL intermediate nodes, the MFV is referenced by two MFVIs 1548 - one for the previous hop and one for the next hop. 1550 When an OAL node forwards carrier packets to a next hop, it can 1551 include a full OAL header with a CRH-32 extension containing one or 1552 more MVFIs. Whenever possible, however, the OAL node should instead 1553 omit significant portions of the OAL header (including the CRH-32) 1554 while applying OAL header compression. The full or compressed OAL 1555 header follows immediately after the innermost L2 encapsulation 1556 (i.e., UDP, IP or L2) as discussed in Section 6.2. Two OAL 1557 compressed header types (Types '0' and '1') are currently specified 1558 below (note that the (A)RQ flag is always considered set and 1559 therefore omitted from the compressed headers themselves). 1561 For OAL first-fragments (including atomic fragments), the OAL node 1562 uses OMNI Compressed Header - Type 0 (OCH-0) format as shown in 1563 Figure 7: 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Type | Hop Limit |ECN| Parcel ID |R|X|P|S|M| Ident. (0) | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Identification (1-3) | MFVI (0) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | MFVI (1-3) | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Figure 7: OMNI Compressed Header - Type 0 (OCH-0) 1577 The format begins with a 4-bit Type, a 6-bit Hop Limit, a 2-bit 1578 Explicit Congestion Notification (ECN) field, a 7-bit Parcel ID and 5 1579 flag bits. The format concludes with a 4-octet Identification field 1580 followed (optionally) by a 4-octet MFVI field. The OAL node sets 1581 Type to the value 0, sets Hop Limit to the minimum of the 1582 uncompressed OAL header Hop Limit and 63, sets ECN the same as for an 1583 uncompressed OAL header, and sets (Parcel ID, (P)arcel, (S)ub- 1584 parcels, (M)ore Fragments, Identification) the same as for an 1585 uncompressed fragment header. The OAL node finally sets Inde(X) and 1586 includes an MFVI if necessary; otherwise, it clears Inde(X) and omits 1587 the MFVI. (The (R)eserved flag is set to 0 on transmission and 1588 ignored on reception.) 1589 The OAL first fragment (beginning with the original IP header) is 1590 then included immediately following the OCH-0 header, and the L2 1591 header length field is reduced by the difference in length between 1592 the compressed headers and full-length OAL IPv6 and Fragment headers. 1593 The OAL destination can therefore determine the Payload Length by 1594 examining the L2 header length field and/or the length field(s) in 1595 the original IP header. The OCH-0 format applies for first fragments 1596 only, which are always regarded as ordinal fragment 0 even though no 1597 explicit Ordinal field is included. The (A)RQ flag is always 1598 implicitly set, and therefore omitted from the OCH-0 header. 1600 For OAL non-first fragments (i.e., those with non-zero Fragment 1601 Offsets), the OAL uses OMNI Compressed Header - Type 1 (OCH-1) format 1602 as shown in Figure 8: 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Type | Hop Limit | Ordinal | Fragment Offset |X|M| 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Identification | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | MFVI | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 Figure 8: OMNI Compressed Header - Type 1 (OCH-1) 1616 The format begins with a 4-bit Type, a 6-bit Hop Limit, a 7-bit 1617 Ordinal, a 13-bit Fragment Offset and 2 flag bits. The format 1618 concludes with a 4-octet Identification field followed (optionally) 1619 by a 4-octet MFVI field. The OAL node sets Type to the value 1, sets 1620 Hop Limit to the minimum of the uncompressed OAL header Hop Limit and 1621 63, and sets (Ordinal, Fragment Offset, (M)ore Fragments, 1622 Identification) the same as for an uncompressed fragment header. If 1623 an MFVI is needed, the OAL node finally sets Inde(X) and includes an 1624 MFVI; otherwise, the node clears Inde(X) and omits the MFVI. 1626 The OAL non-first fragment body is then included immediately 1627 following the OCH-1 header, and the L2 header length field is reduced 1628 by the difference in length between the compressed headers and full- 1629 length OAL IPv6 and Fragment headers. The OAL destination will then 1630 be able to determine the Payload Length by examining the L2 header 1631 length field. The OCH-1 format applies for non-first fragments only; 1632 therefore, the OAL source sets Ordinal to a monotonically increasing 1633 value beginning with 1 for the first non-first fragment, 2 for the 1634 second non-first fragment, etc., up to and including the final 1635 fragment. If more than 127 non-first fragments are included, these 1636 additional fragments instead set Ordinal to 0. The (A)RQ flag is 1637 always implicitly set, and therefore omitted from the OCH-1 header. 1639 When an OAL destination or intermediate node receives a carrier 1640 packet, it determines the length of the encapsulated OAL information 1641 by examining the length field of the innermost L2 header, verifies 1642 that the innermost next header field indicates OMNI (see: 1643 Section 6.2), then examines the first four bits immediately following 1644 the innermost header. If the bits contain the value 4 or 6, the OAL 1645 node processes the remainder as an uncompressed OAL/IP header. If 1646 the bits contain a value 0 or 1, the OAL node instead processes the 1647 remainder of the header as an OCH-0/1 as specified above. 1649 For carrier packets with OCH or full OAL headers addressed to itself 1650 and with CRH-32 extensions, the OAL node then uses the MFVI to locate 1651 the cached MFV which determines the next hop. During forwarding, the 1652 OAL node changes the MFVI to the cached value for the MVF next hop. 1653 If the OAL node is the destination, it instead reconstructs the full 1654 OAL headers then adds the resulting OAL fragment to the reassembly 1655 cache if the Identification is acceptable. (Note that for carrier 1656 packets that include an OCH-0 with both the X and M flags set to 0, 1657 the OAL node can instead locate forwarding state by examining the 1658 original IP packet header information that appears immediately after 1659 the OCH-0 header.) 1661 Note: OAL header compression does not interfere with checksum 1662 calculation and verification, which must be applied according to the 1663 full OAL pseudo-header per Section 6.1 even when compression is used. 1665 Note: The OCH-0/1 formats do not include the Traffic Class and Flow 1666 Label information that appears in uncompressed OAL IPv6 headers. 1667 Therefore, when OAL header compression state is initialized the 1668 Traffic Class and Flow Label are considered fixed for as long as the 1669 flow uses OCH-0/1 headers. If the flow requires frequent changes to 1670 Traffic Class and/or Flow Label information, it can include 1671 uncompressed OAL headers either continuously or periodically to 1672 update header compression state. 1674 6.5. OAL-in-OAL Encapsulation 1676 When an OAL source is unable to forward carrier packets directly to 1677 an OAL destination without "tunneling" through a pair of OAL 1678 intermediate nodes, the OAL source must regard the intermediate nodes 1679 as ingress and egress tunnel endpoints. This will result in nested 1680 OAL-in-OAL encapsulation in which the OAL source performs 1681 fragmentation on the inner OAL packet then forwards the fragments to 1682 the ingress tunnel endpoint which encapsulates each resulting OAL 1683 fragment in an additional OAL header before performing fragmentation 1684 following encapsulation. 1686 For example, if the OAL source has an NCE for the OAL destination 1687 with MFVI 0x2376a7b5 and Identification 0x12345678 and the OAL 1688 ingress tunnel endpoint has an NCE for the OAL egress tunnel endpoint 1689 with MFVI 0xacdebf12 and Identification 0x98765432, the OAL source 1690 prepares the carrier packets using compressed/uncompressed OAL 1691 headers that include the MFVI and Identification corresponding to the 1692 OAL destination and with L2 header information addressed to the next 1693 hop toward the ingress tunnel endpoint. When the ingress tunnel 1694 endpoint receives the carrier packet, it recognizes the current MFVI 1695 included by the OAL source and determines the correct next hop MFVI. 1697 The ingress tunnel endpoint then discards the L2 headers from the 1698 previous hop and encapsulates the original compressed/uncompressed 1699 OAL header within a second compressed/uncompressed OAL header while 1700 including the next-hop MVFI in the outer OAL encapsulation header and 1701 omitting the MFVI in the inner header. The ingress tunnel endpoint 1702 then includes L2 encapsulation headers with destinations appropriate 1703 for the next hop on the path to the egress tunnel endpoint. The 1704 encapsulation appears as shown in Figure 9: 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | L2 headers (previous hop) | | L2 headers (next hop) | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Original OAL/OCH Hdr | | Encapsulation OAL/OCH Hdr | 1710 | Id=0x12345678 | | Id=0x98765432 | 1711 | MFVI=0x2376a7b5 | | MFVI=0xacdebf12 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | | | Original OAL/OCH Hdr | 1714 | | | Id=0x12345678 | 1715 | Carrier packet data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | | | | 1717 | | | | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Carrier packet data | 1719 | Original OAL Checksum | | | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1721 Original Carrier packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 from OAL source | Original OAL Checksum | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Encapsulation OAL Checksum | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 Carrier packet following OAL ingress 1728 (re)encapsulation before fragmentation 1730 Figure 9: Carrier Packet in Carrier Packet Encapsulation 1732 Note that only a single OAL-in-OAL encapsulation layer is supported, 1733 and that MFVIs appear only in the outer OAL header (i.e., either 1734 within a CRH-32 routing header when a full OAL header is used or 1735 within an OCH header with X set to 0). The inner OAL header should 1736 omit the CRH-32 header or use an OCH header with X set to 1, 1737 respectively. 1739 Note that OAL/OCH encapsulation may cause the payloads of OAL packets 1740 produced by the ingress tunnel endpoint to exceed the minimum MPS by 1741 a small amount. If the ingress has assurance that the path to the 1742 egress will include only links capable of transiting the resulting 1743 (slightly larger) carrier packets it should forward without further 1744 fragmentation. Otherwise, the ingress must perform fragmentation 1745 following encapsulation to produce two fragments such that the size 1746 of the first fragment matches the size of the original OAL packet, 1747 and with the remainder in a second fragment. The egress tunnel 1748 endpoint must then reassemble then decapsulate to arrive at the 1749 original OAL packet which is then subject to further forwarding. 1751 6.6. OAL Identification Window Maintenance 1753 The OAL encapsulates each original IP packet as an OAL packet then 1754 performs fragmentation to produce one or more carrier packets with 1755 the same 32-bit Identification value. In environments where spoofing 1756 is not considered a threat, OMNI interfaces send OAL packets with 1757 Identifications beginning with an unpredictable Initial Send Sequence 1758 (ISS) value [RFC7739] monotonically incremented (modulo 2**32) for 1759 each successive OAL packet sent to either a specific neighbor or to 1760 any neighbor. (The OMNI interface may later change to a new 1761 unpredictable ISS value as long as the Identifications are assured 1762 unique within a timeframe that would prevent the fragments of a first 1763 OAL packet from becoming associated with the reassembly of a second 1764 OAL packet.) In other environments, OMNI interfaces should maintain 1765 explicit per-neighbor send and receive windows to detect and exclude 1766 spurious carrier packets that might clutter the reassembly cache as 1767 discussed below. 1769 OMNI interface neighbors use TCP-like synchronization to maintain 1770 windows with unpredictable ISS values incremented (modulo 2**32) for 1771 each successive OAL packet and re-negotiate windows often enough to 1772 maintain an unpredictable profile. OMNI interface neighbors exchange 1773 IPv6 ND messages with OMNI options that include TCP-like information 1774 fields to manage streams of OAL packets instead of streams of octets. 1775 As a link-layer service, the OAL provides low-persistence best-effort 1776 retransmission with no mitigations for duplication, reordering or 1777 deterministic delivery. Since the service model is best-effort and 1778 only control message sequence numbers are acknowledged, OAL nodes can 1779 select unpredictable new initial sequence numbers outside of the 1780 current window without delaying for the Maximum Segment Lifetime 1781 (MSL). 1783 OMNI interface neighbors maintain current and previous window state 1784 in IPv6 ND neighbor cache entries (NCEs) to support dynamic rollover 1785 to a new window while still sending OAL packets and accepting carrier 1786 packets from the previous windows. Each NCE is indexed by the 1787 neighbor's ULA, while the OAL encapsulation ULA (which may be 1788 different) provides context for Identification verification. OMNI 1789 interface neighbors synchronize windows through asymmetric and/or 1790 symmetric IPv6 ND message exchanges. When a node receives an IPv6 ND 1791 message with new window information, it resets the previous window 1792 state based on the current window then resets the current window 1793 based on new and/or pending information. 1795 The IPv6 ND message OMNI option header extension sub-option includes 1796 TCP-like information fields including Sequence Number, 1797 Acknowledgement Number, Window and flags (see: Section 12). OMNI 1798 interface neighbors maintain the following TCP-like state variables 1799 in the NCE: 1801 Send Sequence Variables (current, previous and pending) 1803 SND.NXT - send next 1804 SND.WND - send window 1805 ISS - initial send sequence number 1807 Receive Sequence Variables (current and previous) 1809 RCV.NXT - receive next 1810 RCV.WND - receive window 1811 IRS - initial receive sequence number 1813 OMNI interface neighbors "OAL A" and "OAL B" exchange IPv6 ND 1814 messages per [RFC4861] with OMNI options that include TCP-like 1815 information fields. When OAL A synchronizes with OAL B, it maintains 1816 both a current and previous SND.WND beginning with a new 1817 unpredictable ISS and monotonically increments SND.NXT for each 1818 successive OAL packet transmission. OAL A initiates synchronization 1819 by including the new ISS in the Sequence Number of an authentic IPv6 1820 ND message with the SYN flag set and with Window set to M (up to 1821 2**24) as a tentative receive window size while creating a NCE in the 1822 INCOMPLETE state if necessary. OAL A caches the new ISS as pending, 1823 uses the new ISS as the Identification for OAL encapsulation, then 1824 sends the resulting OAL packet to OAL B and waits up to RetransTimer 1825 milliseconds to receive an IPv6 ND message response with the ACK flag 1826 set (retransmitting up to MAX_UNICAST_SOLICIT times if necessary). 1828 When OAL B receives the SYN, it creates a NCE in the STALE state if 1829 necessary, resets its RCV variables, caches the tentative (send) 1830 window size M, and selects a (receive) window size N (up to 2**24) to 1831 indicate the number of OAL packets it is willing to accept under the 1832 current RCV.WND. (The RCV.WND should be large enough to minimize 1833 control message overhead yet small enough to provide an effective 1834 filter for spurious carrier packets.) OAL B then prepares an IPv6 ND 1835 message with the ACK flag set, with the Acknowledgement Number set to 1836 OAL A's next sequence number, and with Window set to N. Since OAL B 1837 does not assert an ISS of its own, it uses the IRS it has cached for 1838 OAL A as the Identification for OAL encapsulation then sends the ACK 1839 to OAL A. 1841 When OAL A receives the ACK, it notes that the Identification in the 1842 OAL header matches its pending ISS. OAL A then sets the NCE state to 1843 REACHABLE and resets its SND variables based on the Window size and 1844 Acknowledgement Number (which must include the sequence number 1845 following the pending ISS). OAL A can then begin sending OAL packets 1846 to OAL B with Identification values within the (new) current SND.WND 1847 for up to ReachableTime milliseconds or until the NCE is updated by a 1848 new IPv6 ND message exchange. This implies that OAL A must send a 1849 new SYN before sending more than N OAL packets within the current 1850 SND.WND, i.e., even if ReachableTime is not nearing expiration. 1851 After OAL B returns the ACK, it accepts carrier packets received from 1852 OAL A within either the current or previous RCV.WND as well as any 1853 new authentic NS/RS SYN messages received from OAL A even if outside 1854 the windows. 1856 OMNI interface neighbors can employ asymmetric window synchronization 1857 as described above using two independent (SYN -> ACK) exchanges 1858 (i.e., a four-message exchange), or they can employ symmetric window 1859 synchronization using a modified version of the TCP three-way 1860 handshake as follows: 1862 * OAL A prepares a SYN with an unpredictable ISS not within the 1863 current SND.WND and with Window set to M as a tentative receive 1864 window size. OAL A caches the new ISS and Window size as pending 1865 information, uses the pending ISS as the Identification for OAL 1866 encapsulation, then sends the resulting OAL packet to OAL B and 1867 waits up to RetransTimer milliseconds to receive an ACK response 1868 (retransmitting up to MAX_UNICAST_SOLICIT times if necessary). 1870 * OAL B receives the SYN, then resets its RCV variables based on the 1871 Sequence Number while caching OAL A's tentative receive Window 1872 size M and a new unpredictable ISS outside of its current window 1873 as pending information. OAL B then prepares a response with 1874 Sequence Number set to the pending ISS and Acknowledgement Number 1875 set to OAL A's next sequence number. OAL B then sets both the SYN 1876 and ACK flags, sets Window to N and sets the OPT flag according to 1877 whether an explicit concluding ACK is optional or mandatory. OAL 1878 B then uses the pending ISS as the Identification for OAL 1879 encapsulation, sends the resulting OAL packet to OAL A and waits 1880 up to RetransTimer milliseconds to receive an acknowledgement 1881 (retransmitting up to MAX_UNICAST_SOLICIT times if necessary). 1883 * OAL A receives the SYN/ACK, then resets its SND variables based on 1884 the Acknowledgement Number (which must include the sequence number 1885 following the pending ISS) and OAL B's advertised Window N. OAL A 1886 then resets its RCV variables based on the Sequence Number and 1887 marks the NCE as REACHABLE. If the OPT flag is clear, OAL A next 1888 prepares an immediate solicited NA message with the ACK flag set, 1889 the Acknowledgement Number set to OAL B's next sequence number, 1890 with Window set a value that may be the same as or different than 1891 M, and with the OAL encapsulation Identification to SND.NXT, then 1892 sends the resulting OAL packet to OAL B. If the OPT flag is set 1893 and OAL A has OAL packets queued to send to OAL B, it can 1894 optionally begin sending their carrier packets under the (new) 1895 current SND.WND as implicit acknowledgements instead of returning 1896 an explicit ACK. In that case, the tentative Window size M 1897 becomes the current receive window size. 1899 * OAL B receives the implicit/explicit acknowledgement(s) then 1900 resets its SND state based on the pending/advertised values and 1901 marks the NCE as REACHABLE. If OAL B receives an explicit 1902 acknowledgement, it uses the advertised Window size and abandons 1903 the tentative size. (Note that OAL B sets the OPT flag in the 1904 SYN/ACK to assert that it will interpret timely receipt of carrier 1905 packets within the (new) current window as an implicit 1906 acknowledgement. Potential benefits include reduced delays and 1907 control message overhead, but use case analysis is outside the 1908 scope of this specification.) 1910 Following synchronization, OAL A and OAL B hold updated NCEs and can 1911 exchange OAL packets with Identifications set to SND.NXT while the 1912 state remains REACHABLE and there is available window capacity. 1913 Either neighbor may at any time send a new SYN to assert a new ISS. 1914 For example, if OAL A's current SND.WND for OAL B is nearing 1915 exhaustion and/or ReachableTime is nearing expiration, OAL A 1916 continues to send OAL packets under the current SND.WND while also 1917 sending a SYN with a new unpredictable ISS. When OAL B receives the 1918 SYN, it resets its RCV variables and may optionally return either an 1919 asymmetric ACK or a symmetric SYN/ACK to also assert a new ISS. 1920 While sending SYNs, both neighbors continue to send OAL packets with 1921 Identifications set to the current SND.NXT then reset the SND 1922 variables after an acknowledgement is received. 1924 While the optimal symmetric exchange is efficient, anomalous 1925 conditions such as receipt of old duplicate SYNs can cause confusion 1926 for the algorithm as discussed in Section 3.4 of [RFC0793]. For this 1927 reason, the OMNI option header includes an RST flag which OAL nodes 1928 set in solicited NA responses to ACKs received with incorrect 1929 acknowledgement numbers. The RST procedures (and subsequent 1930 synchronization recovery) are conducted exactly as specified in 1931 [RFC0793]. 1933 OMNI interfaces may set the PNG ("ping") flag when a reachability 1934 confirmation outside the context of the IPv6 ND protocol is needed 1935 (OMNI interfaces therefore most often set the PNG flag in 1936 advertisement messages and ignore it in solicitation messages). When 1937 an OMNI interface receives a PNG, it returns an unsolicited NA (uNA) 1938 ACK with the PNG message Identification in the Acknowledgment, but 1939 without updating RCV state variables. OMNI interfaces return unicast 1940 uNA ACKs even for multicast PNG destination addresses, since OMNI 1941 link multicast is based on unicast emulation. 1943 OMNI interfaces that employ the window synchronization procedures 1944 described above observe the following requirements: 1946 * OMNI interfaces MUST select new unpredictable ISS values that are 1947 at least a full window outside of the current SND.WND. 1949 * OMNI interfaces MUST set the initial SYN message Window field to a 1950 tentative value to be used only if no concluding NA ACK is sent. 1952 * OMNI interfaces that receive advertisements with the PNG and/or 1953 SYN flag set MUST NOT set the PNG and/or SYN flag in uNA 1954 responses. 1956 * OMNI interfaces that send advertisements with the PNG and/or SYN 1957 flag set MUST ignore uNA responses with the PNG and/or SYN flag 1958 set. 1960 * OMNI interfaces MUST send IPv6 ND messages used for window 1961 synchronization securely while using unpredictable initial 1962 Identification values until synchronization is complete. 1964 Note: Although OMNI interfaces employ TCP-like window synchronization 1965 and support uNA ACK responses to SYNs and PNGs, all other aspects of 1966 the IPv6 ND protocol (e.g., control message exchanges, NCE state 1967 management, timers, retransmission limits, etc.) are honored exactly 1968 per [RFC4861]. 1970 Note: Recipients of OAL-encapsulated IPv6 ND messages index the NCE 1971 based on the message source address, which also determines the 1972 carrier packet Identification window. However, IPv6 ND messages may 1973 contain a message source address that does not match the OMNI 1974 encapsulation source address when the recipient acts as a proxy. 1976 Note: OMNI interface neighbors apply the same send and receive 1977 windows for all of their (multilink) underlay interface pairs that 1978 exchange carrier packets. Each interface pair represents a distinct 1979 underlay network path, and the set of paths traversed may be highly 1980 diverse when multiple interface pairs are used. OMNI intermediate 1981 nodes therefore SHOULD NOT cache window synchronization parameters in 1982 IPv6 ND messages they forward since there is no way to ensure 1983 network-wide middlebox state consistency. 1985 6.7. OAL Fragment Retransmission 1987 When the OAL source sends carrier packets to an OAL destination, it 1988 should cache recently sent packets in case timely best-effort 1989 selective retransmission is requested. The OAL destination in turn 1990 maintains a checklist for the (Source, Destination, Identification)- 1991 tuple of recently received carrier packets and notes the ordinal 1992 numbers of OAL packet fragments already received (i.e., as Frag #0, 1993 Frag #1, Frag #2, etc.). The timeframe for maintaining the OAL 1994 source and destination caches determines the link persistence (see: 1995 [RFC3366]). 1997 If the OAL destination notices some fragments missing after most 1998 other fragments within the same link persistence timeframe have 1999 already arrived, it may issue an Automatic Repeat Request (ARQ) with 2000 Selective Repeat (SR) by sending a uNA message to the OAL source. 2001 The OAL destination creates a uNA message with an OMNI option with 2002 one or more Fragmentation Report (FRAGREP) sub-options that include a 2003 list of (Identification, Bitmap)-tuples for fragments received and 2004 missing from this OAL source (see: Section 12 and 2005 [I-D.templin-6man-fragrep]). The OAL destination includes an 2006 authentication signature if necessary, performs OAL encapsulation 2007 (with the its own address as the OAL source and the source address of 2008 the message that prompted the uNA as the OAL destination) and sends 2009 the message to the OAL source. 2011 When the OAL source receives the uNA message, it authenticates the 2012 message then examines the FRAGREP. For each (Source, Destination, 2013 Identification)-tuple, the OAL source determines whether it still 2014 holds the corresponding carrier packets in its cache and retransmits 2015 any for which the Bitmap indicates a loss event. For example, if the 2016 Bitmap indicates that ordinal fragments #3, #7, #10 and #13 from the 2017 OAL packet with Identification 0x12345678 are missing the OAL source 2018 only retransmits carrier packets containing those fragments. When 2019 the OAL destination receives the retransmitted carrier packets, it 2020 admits the enclosed fragments into the reassembly cache and updates 2021 its checklist. If some fragments are still missing, the OAL 2022 destination may send a small number of additional uNA ARQ/SRs within 2023 the link persistence timeframe. 2025 The OAL therefore provides a link-layer low-to-medium persistence 2026 ARQ/SR service consistent with [RFC3366] and Section 8.1 of 2027 [RFC3819]. The service provides the benefit of timely best-effort 2028 link-layer retransmissions which may reduce packet loss and avoid 2029 some unnecessary end-to-end delays. This best-effort network-based 2030 service therefore compliments higher layer end-to-end protocols 2031 responsible for true reliability. 2033 6.8. OAL MTU Feedback Messaging 2035 When the OMNI interface forwards original IP packets from the network 2036 layer, it invokes the OAL and returns internally-generated ICMPv4 2037 Fragmentation Needed [RFC1191] or ICMPv6 Path MTU Discovery (PMTUD) 2038 Packet Too Big (PTB) [RFC8201] messages as necessary. This document 2039 refers to both of these ICMPv4/ICMPv6 message types simply as "PTBs", 2040 and introduces a distinction between PTB "hard" and "soft" errors as 2041 discussed below and also in [I-D.templin-6man-fragrep]. 2043 Ordinary PTB messages with ICMPv4 header "unused" field or ICMPv6 2044 header Code field value 0 are hard errors that always indicate that a 2045 packet has been dropped due to a real MTU restriction. However, the 2046 OMNI interface can also forward large original IP packets via OAL 2047 encapsulation and fragmentation while at the same time returning PTB 2048 soft error messages (subject to rate limiting) if it deems the 2049 original IP packet too large according to factors such as link 2050 performance characteristics, number of fragments needed, reassembly 2051 congestion, etc. This ensures that the path MTU is adaptive and 2052 reflects the current path used for a given data flow. The OMNI 2053 interface can therefore continuously forward packets without loss 2054 while returning PTB soft error messages recommending a smaller size 2055 if necessary. Original sources that receive the soft errors in turn 2056 reduce the size of the packets they send (i.e., the same as for hard 2057 errors), but can soon resume sending larger packets if the soft 2058 errors subside. 2060 An OAL source sends PTB soft error messages by setting the ICMPv4 2061 header "unused" field or ICMPv6 header Code field to the value 1 if 2062 the packet was dropped or 2 if the packet was forwarded successfully. 2063 The OAL source sets the PTB destination address to the original IP 2064 packet source, and sets the source address to one of its OMNI 2065 interface addresses that is routable from the perspective of the 2066 original source. The OAL source then sets the MTU field to a value 2067 smaller than the original packet size but no smaller than 576 for 2068 ICMPv4 or 1280 for ICMPv6, writes the leading portion of the original 2069 IP packet first fragment into the "packet in error" field, and 2070 returns the PTB soft error to the original source. When the original 2071 source receives the PTB soft error, it temporarily reduces the size 2072 of the packets it sends the same as for hard errors but may seek to 2073 increase future packet sizes dynamically while no further soft errors 2074 are arriving. (If the original source does not recognize the soft 2075 error code, it regards the PTB the same as a hard error but should 2076 heed the retransmission advice given in [RFC8201] suggesting 2077 retransmission based on normal packetization layer retransmission 2078 timers.) 2079 An OAL destination may experience reassembly cache congestion, and 2080 can return uNA messages to the OAL source that originated the 2081 fragments (subject to rate limiting) that include OMNI encapsulated 2082 PTB messages with code 1 or 2. The OAL destination creates a uNA 2083 message with an OMNI option containing an authentication message sub- 2084 option if necessary followed optionally by a ICMPv6 Error sub-option 2085 that encodes a PTB message with a reduced value and with the leading 2086 portion an OAL first fragment containing the header of an original IP 2087 packet whose source must be notified (see: Section 12). The OAL 2088 destination encapsulates the leading portion of the OAL first 2089 fragment (beginning with the OAL header) in the PTB "packet in error" 2090 field, signs the message if an authentication sub-option is included, 2091 performs OAL encapsulation (with the its own address as the OAL 2092 source and the source address of the message that prompted the uNA as 2093 the OAL destination) and sends the message to the OAL source. 2095 When the OAL source receives the uNA message, it sends a 2096 corresponding network layer PTB soft error to the original source to 2097 recommend a smaller size. The OAL source crafts the PTB by 2098 extracting the leading portion of the original IP packet from the 2099 OMNI encapsulated PTB message (i.e., not including the OAL header) 2100 and writes it in the "packet in error" field of a network layer PTB 2101 with destination set to the original IP packet source and source set 2102 to one of its OMNI interface addresses that is routable from the 2103 perspective of the original source. 2105 Original sources that receive PTB soft errors can dynamically tune 2106 the size of the original IP packets they to send to produce the best 2107 possible throughput and latency, with the understanding that these 2108 parameters may change over time due to factors such as congestion, 2109 mobility, network path changes, etc. The receipt or absence of soft 2110 errors should be seen as hints of when increasing or decreasing 2111 packet sizes may be beneficial. The OMNI interface supports 2112 continuous transmission and reception of packets of various sizes in 2113 the face of dynamically changing network conditions. Moreover, since 2114 PTB soft errors do not indicate a hard limit, original sources that 2115 receive soft errors can resume sending larger packets without waiting 2116 for the recommended 10 minutes specified for PTB hard errors 2117 [RFC1191][RFC8201]. The OMNI interface therefore provides an 2118 adaptive service that accommodates MTU diversity especially well- 2119 suited for dynamic multilink environments. 2121 6.9. OAL Super-Packets 2123 By default, the OAL source includes a 40-octet IPv6 encapsulation 2124 header for each original IP packet during OAL encapsulation. The OAL 2125 source also calculates then performs fragmentation such that a copy 2126 of the 40-octet IPv6 header plus an 8-octet IPv6 Fragment Header is 2127 included in each OAL fragment (when a Routing Header is added, the 2128 OAL encapsulation headers become larger still). However, these 2129 encapsulations may represent excessive overhead in some environments. 2130 OAL header compression can dramatically reduce the amount of 2131 encapsulation overhead, however a complimentary technique known as 2132 "packing" (see: [I-D.ietf-intarea-tunnels]) supports encapsulation of 2133 multiple original IP packets and/or control messages within a single 2134 OAL "super-packet". 2136 When the OAL source has multiple original IP packets to send to the 2137 same OAL destination with total length no larger than the OAL 2138 destination MRU, it can concatenate them into a super-packet 2139 encapsulated in a single OAL header. Within the OAL super-packet, 2140 the IP header of the first original IP packet (iHa) followed by its 2141 data (iDa) is concatenated immediately following the OAL header, then 2142 the IP header of the next original packet (iHb) followed by its data 2143 (iDb) is concatenated immediately following the first original 2144 packet, etc. with a trailing checksum field included in the final 2145 fragment. The OAL super-packet format is transposed from 2146 [I-D.ietf-intarea-tunnels] and shown in Figure 10: 2148 <------- Original IP packets -------> 2149 +-----+-----+ 2150 | iHa | iDa | 2151 +-----+-----+ 2152 | 2153 | +-----+-----+ 2154 | | iHb | iDb | 2155 | +-----+-----+ 2156 | | 2157 | | +-----+-----+ 2158 | | | iHc | iDc | 2159 | | +-----+-----+ 2160 | | | 2161 v v v 2162 +----------+-----+-----+-----+-----+-----+-----+----+ 2163 | OAL Hdr | iHa | iDa | iHb | iDb | iHc | iDc |Csum| 2164 +----------+-----+-----+-----+-----+-----+-----+----+ 2165 <--- OAL "Super-Packet" with single OAL Hdr/Csum ---> 2167 Figure 10: OAL Super-Packet Format 2169 When the OAL source prepares a super-packet, it applies OAL 2170 fragmentation, includes a trailing checksum in the final fragment, 2171 applies L2 encapsulation to each fragment then sends the resulting 2172 carrier packets to the OAL destination. When the OAL destination 2173 receives the super-packet it sets aside the trailing checksum, 2174 reassembles if necessary, then verifies the checksum while regarding 2175 the remaining OAL header Payload Length as the sum of the lengths of 2176 all payload packets. The OAL destination then selectively extracts 2177 each original IP packet (e.g., by setting pointers into the super- 2178 packet buffer and maintaining a reference count, by copying each 2179 packet into a separate buffer, etc.) and forwards each packet to the 2180 network layer. During extraction, the OAL determines the IP protocol 2181 version of each successive original IP packet 'j' by examining the 2182 four most-significant bits of iH(j), and determines the length of the 2183 packet by examining the rest of iH(j) according to the IP protocol 2184 version. 2186 When an OAL source prepares a super-packet that includes an IPv6 ND 2187 message with an authentication signature or ICMPv6 message checksum 2188 as the first original IP packet (i.e., iHa/iDa), it calculates the 2189 authentication signature or checksum over the remainder of super- 2190 packet. Security and integrity for forwarding initial protocol data 2191 packets in conjunction with IPv6 ND messages used to establish NCE 2192 state are therefore supported. (A common use case entails a path MPS 2193 probe beginning with a signed IPv6 ND message followed by a NULL IPv6 2194 packet with a suitably large (Jumbo) Payload Length but with Next 2195 Header set to 59 for "No Next Header".) 2197 6.10. OAL Bubbles 2199 OAL sources may send NULL OAL packets known as "bubbles" for the 2200 purpose of establishing Network Address Translator (NAT) state on the 2201 path to the OAL destination. The OAL source prepares a bubble by 2202 crafting an OAL header with appropriate IPv6 source and destination 2203 ULAs, with the IPv6 Next Header field set to the value 59 ("No Next 2204 Header" - see [RFC8200]) and with only the trailing OAL Checksum 2205 field (i.e., and no protocol data) immediately following the IPv6 2206 header. 2208 The OAL source includes a random Identification value then 2209 encapsulates the OAL packet in L2 headers destined to either the 2210 mapped address of the OAL destination's first-hop ingress NAT or the 2211 L2 address of the OAL destination itself. When the OAL source sends 2212 the resulting carrier packet, any egress NATs in the path toward the 2213 L2 destination will establish state based on the activity but the 2214 bubble will be harmlessly discarded by either an ingress NAT on the 2215 path to the OAL destination or by the OAL destination itself. 2217 The bubble concept for establishing NAT state originated in [RFC4380] 2218 and was later updated by [RFC6081]. OAL bubbles may be employed by 2219 mobility services such as [I-D.templin-6man-aero]. 2221 6.11. OAL Requirements 2223 In light of the above, OAL sources, destinations and intermediate 2224 nodes observe the following normative requirements: 2226 * OAL sources MUST forward original IP packets either larger than 2227 the OMNI interface MRU or smaller than the minimum MPS minus the 2228 trailing checksum size as atomic fragments (i.e., and not as 2229 multiple fragments). 2231 * OAL sources MUST produce non-final fragments with payloads no 2232 smaller than the minimum MPS during fragmentation. 2234 * OAL intermediate nodes SHOULD and OAL destinations MUST 2235 unconditionally drop any non-final OAL fragments with payloads 2236 smaller than the minimum MPS. 2238 * OAL destinations MUST drop any new OAL fragments with offset and 2239 length that would overlap with other fragments and/or leave holes 2240 smaller than the minimum MPS between fragments that have already 2241 been received. 2243 Note: Under the minimum MPS, ordinary 1500 octet original IP packets 2244 would require at most 4 OAL fragments, with each non-final fragment 2245 containing 400 payload octets and the final fragment containing 302 2246 payload octets (i.e., the final 300 octets of the original IP packet 2247 plus the 2 octet trailing checksum). For all packet sizes, the 2248 likelihood of successful reassembly may improve when the OMNI 2249 interface sends all fragments of the same fragmented OAL packet 2250 consecutively over the same underlay interface pair instead of spread 2251 across multiple underlay interface pairs. Finally, an assured 2252 minimum/path MPS allows continuous operation over all paths including 2253 those that traverse bridged L2 media with dissimilar MTUs. 2255 Note: Certain legacy network hardware of the past millennium was 2256 unable to accept packet "bursts" resulting from an IP fragmentation 2257 event - even to the point that the hardware would reset itself when 2258 presented with a burst. This does not seem to be a common problem in 2259 the modern era, where fragmentation and reassembly can be readily 2260 demonstrated at line rate (e.g., using tools such as 'iperf3') even 2261 over fast links on ordinary hardware platforms. Even so, while the 2262 OAL destination is reporting reassembly congestion (see: Section 6.8) 2263 the OAL source could impose "pacing" by inserting an inter-fragment 2264 delay and increasing or decreasing the delay according to congestion 2265 indications. 2267 6.12. OAL Fragmentation Security Implications 2269 As discussed in Section 3.7 of [RFC8900], there are four basic 2270 threats concerning IPv6 fragmentation; each of which is addressed by 2271 effective mitigations as follows: 2273 1. Overlapping fragment attacks - reassembly of overlapping 2274 fragments is forbidden by [RFC8200]; therefore, this threat does 2275 not apply to the OAL. 2277 2. Resource exhaustion attacks - this threat is mitigated by 2278 providing a sufficiently large OAL reassembly cache and 2279 instituting "fast discard" of incomplete reassemblies that may be 2280 part of a buffer exhaustion attack. The reassembly cache should 2281 be sufficiently large so that a sustained attack does not cause 2282 excessive loss of good reassemblies but not so large that (timer- 2283 based) data structure management becomes computationally 2284 expensive. The cache should also be indexed based on the arrival 2285 underlay interface such that congestion experienced over a first 2286 underlay interface does not cause discard of incomplete 2287 reassemblies for uncongested underlay interfaces. 2289 3. Attacks based on predictable fragment identification values - in 2290 environments where spoofing is possible, this threat is mitigated 2291 through the use of Identification windows beginning with 2292 unpredictable values per Section 6.6. By maintaining windows of 2293 acceptable Identifications, OAL neighbors can quickly discard 2294 spurious carrier packets that might otherwise clutter the 2295 reassembly cache. The OAL additionally provides an integrity 2296 check to detect corruption that may be caused by spurious 2297 fragments received with in-window Identification values. 2299 4. Evasion of Network Intrusion Detection Systems (NIDS) - since the 2300 OAL source employs a robust MPS, network-based firewalls can 2301 inspect and drop OAL fragments containing malicious data thereby 2302 disabling reassembly by the OAL destination. However, since OAL 2303 fragments may take different paths through the network (some of 2304 which may not employ a firewall) each OAL destination must also 2305 employ a firewall. 2307 IPv4 includes a 16-bit Identification (IP ID) field with only 65535 2308 unique values such that at high data rates the field could wrap and 2309 apply to new carrier packets while the fragments of old packets using 2310 the same IP ID are still alive in the network [RFC4963]. Since 2311 carrier packets sent via an IPv4 path with DF=0 are normally no 2312 larger than 576 octets, IPv4 fragmentation is possible only at small- 2313 MTU links in the path which should support data rates low enough for 2314 safe reassembly [RFC3819]. (IPv4 carrier packets larger than 576 2315 octets with DF=0 may incur high data rate reassembly errors in the 2316 path, but the OAL checksum provides OAL destination integrity 2317 assurance.) Since IPv6 provides a 32-bit Identification value, IP ID 2318 wraparound at high data rates is not a concern for IPv6 2319 fragmentation. 2321 Fragmentation security concerns for large IPv6 ND messages are 2322 documented in [RFC6980]. These concerns are addressed when the OMNI 2323 interface employs the OAL instead of directly fragmenting the IPv6 ND 2324 message itself. For this reason, OMNI interfaces MUST NOT send IPv6 2325 ND messages larger than the OMNI interface MTU, and MUST employ OAL 2326 encapsulation and fragmentation for IPv6 ND messages larger than the 2327 minimum/path MPS for this OAL destination. 2329 Unless the path is secured at the network-layer or below (i.e., in 2330 environments where spoofing is possible), OMNI interfaces MUST NOT 2331 send ordinary carrier packets with Identification values outside the 2332 current window and MUST secure IPv6 ND messages used for address 2333 resolution or window state synchronization. OAL destinations SHOULD 2334 therefore discard without reassembling any out-of-window OAL 2335 fragments received over an unsecured path. 2337 6.13. OMNI Hosts 2339 OMNI Hosts are end systems that extend the OMNI link over ENET 2340 underlay interfaces (i.e., either as an OMNI interface or as a 2341 sublayer of the ENET interface itself). Each ENET is connected to 2342 the rest of the OMNI link by a Client that receives an MNP 2343 delegation. Clients delegate MNP addresses and/or sub-prefixes to 2344 ENET nodes (i.e., Hosts, other Clients, routers and non-OMNI hosts) 2345 using standard mechanisms such as DHCP [RFC8415][RFC2131] and IPv6 2346 Stateless Address AutoConfiguration (SLAAC) [RFC4862]. Clients 2347 forward packets between their ENET Hosts and peers on external 2348 networks acting as routers and/or OAL intermediate nodes. 2350 OMNI Hosts coordinate with Clients and/or other Hosts connected to 2351 the same ENET using IP-encapsulated IPv6 ND messages. The IP 2352 encapsulation headers and ND messages both use the MNP-based 2353 addresses assigned to ENET underlay interfaces as source and 2354 destination addresses (i.e., instead of ULAs). For IPv4 MNPs, the ND 2355 messages use IPv4-Compatible IPv6 addresses [RFC4291] in place of the 2356 IPv4 addresses. (Note that IPv4-Compatible IPv6 addresses are 2357 deprecated for all other uses by the aforementioned standard.) 2359 Hosts discover Clients by sending encapsulated RS messages using an 2360 OMNI link IP anycast address (or the unicast address of the Client) 2361 as the RS L2 encapsulation destination as specified in Section 15. 2362 The Client configures the IPv4 and/or IPv6 anycast addresses for the 2363 OMNI link on its ENET interface and advertises the address(es) into 2364 the ENET routing system. The Client then responds to the 2365 encapsulated RS messages by sending an encapsulated RA message that 2366 uses its ENET unicast address as the source. (To differentiate 2367 itself from an INET border Proxy/Server, the Client sets the RA 2368 message OMNI Interface Attributes sub-option LHS field to 0 for the 2369 Host's interface index. When the RS message includes an L2 anycast 2370 destination address, the Client also includes an Interface Attributes 2371 sub-option for interface index 0 to inform the Host of its L2 unicast 2372 address - see: Section 15 for full details on the RS and RA message 2373 contents.) 2375 Hosts coordinate with peer Hosts on the same ENET by sending 2376 encapsulated NS messages to receive an NA reply. (Hosts determine 2377 whether a peer is on the same ENET by matching the peer's IP address 2378 with the MNP (sub)-prefix for the ENET advertised in the Client's RA 2379 message [RFC8028].) Each ENET peer then creates a NCE and 2380 synchronizes Identification windows the same as for OMNI link 2381 neighbors, and the Host can then engage in OMNI link transactions 2382 with the Client and/or other ENET Hosts. By coordinating with the 2383 Client in this way, the Host treats the Client as if it were an ANET 2384 Proxy/Server, and the Client provides the same services that a Proxy/ 2385 Server would provide. By coordinating with other Hosts, the peer 2386 hosts can exchange large IP packets or parcels over the ENET using 2387 IPv6 fragmentation if necessary. 2389 When a Host prepares an IP packet or parcel, it uses the IP address 2390 of its native ENET interface as the source and the IP address of the 2391 (remote) peer as the destination. The Host next performs parcel 2392 segmentation if necessary (see: Section 6.14) then encapsulates the 2393 packet/parcel in an IP header of the version supported by the ENET 2394 while setting the source to the same address and destination to 2395 either the same address if the peer is on the local ENET, or to the 2396 IP address of the Client otherwise. The Host can then proceed to 2397 exchange packets/parcels with the destination, either directly or via 2398 the Client as an intermediate node. 2400 The encapsulation procedures are coordinated per Section 6.1, except 2401 that the IP encapsulation header version matches the native ENET IP 2402 protocol version and uses IPv6 GUA or public/private IPv4 addresses 2403 instead of ULAs. The Host sets the encapsulation IP header 2404 {Protocol, Next-Header} field to TBD1 to indicate that this is an OAL 2405 encapsulation and not an ordinary IP-in-IP encapsulation. When the 2406 inner header is IPv4-based, the Host next translates the 2407 encapsulation header into an IPv6 header with IPv4-Compatible 2408 addresses while setting the [IPv6 Traffic Class, Payload Length, Next 2409 Header, Hop Limit] fields according to the IPv4 {Type of Service, 2410 Total Length, Protocol, TTL} fields, respectively, while setting Flow 2411 Label to 0. The Host then calculates an OAL checksum, writes the 2412 value as the final two octets of the encapsulated packet then applies 2413 IPv6 fragmentation to the encapsulated packet to produce IPv6 2414 fragments no smaller than the MPS the same as described in 2415 Section 6.1. If the original encapsulation IP header was IPv4, the 2416 Host next translates the IPv6 encapsulation headers back to IPv4 2417 headers with Protocol value set to 44 since the immediately next 2418 header is the IPv6 Fragment Header. The Host finally sends the IP 2419 encapsulated fragments to the ENET peer. 2421 When the ENET peer receives IP encapsulated fragments, for IPv4 it 2422 first translates the encapsulation headers back to IPv6 headers with 2423 IPv4-Compatible addresses the same as above. The peer then 2424 reassembles and verifies the OAL checksum. If the checksum is 2425 correct, the peer next removes the encapsulation headers and applies 2426 parcel reassembly if necessary. The peer then either delivers the 2427 encapsulated packet/parcel to upper layers if the peer is the 2428 destination or forwards the packet/parcel toward the final 2429 destination if the peer is a Client acting as an intermediate node. 2431 Hosts and Clients that initiate OMNI-based packet/parcel transactions 2432 should first test the path toward the final destination using the 2433 parcel path qualification procedure specified in 2434 [I-D.templin-intarea-parcels]. An OMNI Host that sends and receives 2435 parcels need not implement the full OMNI interface abstraction but 2436 MUST implement enough of the OAL to be capable of fragmenting and 2437 reassembling maximum-length encapsulated IP packets/parcels and sub- 2438 parcels as discussed above and in the following section. 2440 6.14. IP Parcels 2442 IP parcels are specified in [I-D.templin-intarea-parcels], while 2443 details for their application over OMNI interfaces is specified here. 2444 IP parcels are formed by an OMNI Host or Client upper layer protocol 2445 entity (identified by the "5-tuple" source IP address/port number, 2446 destination IP address/port number and protocol number) when it 2447 produces a protocol data unit containing the concatenation of up to 2448 64 upper layer protocol segments. All non-final segments MUST be 2449 equal in length while the final segment MUST NOT be larger but MAY be 2450 smaller. Each non-final segment MUST be no larger than 65535 minus 2451 the length of the IP header plus extensions, minus the length of the 2452 OAL encapsulation header and trailer. The upper layer protocol then 2453 presents the buffer and non-final segment size to the IP layer which 2454 appends a single IP header (plus any extension headers) before 2455 presenting the parcel to the OMNI Interface. 2457 For IPv4, the IP layer prepares the parcel by appending an IPv4 2458 header with a Jumbo Payload option (see: Section 5.1) where "Jumbo 2459 Payload Length" is a 32-bit unsigned integer value (in network byte 2460 order) set to the lengths of the IPv4 header plus all concatenated 2461 segments. The IP layer next sets the IPv4 header DF bit to 1, then 2462 sets the IPv4 header Total Length field to the length of the IPv4 2463 header plus the length of the first segment only. (Note: the IP 2464 layer can form true IPv4 jumbograms (as opposed to parcels) by 2465 instead setting the Total Length field to the length of the IPv4 2466 header only.) 2468 For IPv6, the IP layer forms a parcel by appending an IPv6 header 2469 with a Jumbo Payload option the same as for IPv4 above where "Jumbo 2470 Payload Length" is set to the lengths of the IPv6 Hop-by-Hop Options 2471 header and any other extension headers present plus all concatenated 2472 segments. The IP layer next sets the IPv6 header Payload Length 2473 field to the lengths of the IPv6 Hop-by-Hop Options header and any 2474 other extension headers present plus the length of the first segment 2475 only. (Note: the IP layer can form true IPv6 jumbograms (as opposed 2476 to parcels) by instead setting the Payload Length field to 0.) 2478 An IP parcel therefore has the following structure: 2480 +--------+--------+--------+--------+ 2481 | | 2482 ~ Segment J (K octets) ~ 2483 | | 2484 +--------+--------+--------+--------+ 2485 ~ ~ 2486 ~ ~ 2487 +--------+--------+--------+--------+ 2488 | | 2489 ~ Segment 3 (L octets) ~ 2490 | | 2491 +--------+--------+--------+--------+ 2492 | | 2493 ~ Segment 2 (L octets) ~ 2494 | | 2495 +--------+--------+--------+--------+ 2496 | | 2497 ~ Segment 1 (L octets) ~ 2498 | | 2499 +--------+--------+--------+--------+ 2500 | IP Header Plus Extensions | 2501 ~ {Total, Payload} Length = M ~ 2502 | Jumbo Payload Length = N | 2503 +--------+--------+--------+--------+ 2505 Figure 11: OMNI Interface IP Parcels 2507 where J is the total number of segments (between 1 and 64), L is the 2508 length of each non-final segment which MUST NOT be larger than 65535 2509 (minus headers as above) and K is the length of the final segment 2510 which MUST NOT be larger than L. The values M and N are then set to 2511 the length of the IP header plus extensions for IPv4 or to the length 2512 of the extensions only for IPv6, then further calculated as follows: 2514 M = M + ((J-1) ? L : K) 2516 N = N + (((J-1) * L) + K) 2518 Note: a "singleton" parcel is one that includes only the IP header 2519 plus extensions with a single segment of length K, while a "null" 2520 parcel is a singleton with K=0, i.e., a parcel consisting of only the 2521 IP header plus extensions with no octets beyond. 2523 When the IP layer forwards a parcel, the OMNI interface invokes the 2524 OAL which forwards it to either a Client as an intermediate node or 2525 the final destination itself. The OAL source first assigns a 2526 monotonically-incrementing (modulo 127) "Parcel ID" and subdivides 2527 the parcel into sub-parcels no larger than the maximum of the path 2528 MTU to the next hop or 64KB (minus the length of encapsulation 2529 headers). The OAL source determines the number of segments of length 2530 L that can fit into each sub-parcel under these size constraints, 2531 e.g. if the OAL source determines that a sub-parcel can contain 3 2532 segments of length L, it creates sub-parcels with the first 2533 containing segments 1-3, the second containing segments 4-6, etc. and 2534 with the final containing any remaining segments. The OAL source 2535 then appends an identical IP header plus extensions to each sub- 2536 parcel while resetting M and N in each according to the above 2537 equations with J set to 3 and K set to L for each non-final sub- 2538 parcel and with J set to the remaining number of segments for the 2539 final sub-parcel. 2541 The OAL source next performs encapsulation on each sub-parcel with 2542 destination set to the next hop address. If the next hop is reached 2543 via an ANET/INET interface, the OAL source inserts an OAL header the 2544 same as discussed in Section 6.1 and sets the destination to the ULA- 2545 MNP of the target Client. If the next hop is reached via an ENET 2546 interface, the OAL source instead inserts an IP header of the 2547 appropriate protocol version for the underlay ENET (i.e., even if the 2548 encapsulation header is IPv4) and sets the destination to the ENET IP 2549 address of the next hop. The OAL source inserts the encapsulation 2550 header even if no actual fragmentation is needed and/or even if the 2551 Jumbo Payload option is present. 2553 The OAL source next assigns an Identification number that is 2554 monotonically-incremented for each consecutive sub-parcel, calculates 2555 and appends the OAL checksum, then performs IPv6 fragmentation over 2556 the sub-parcel if necessary to create fragments small enough to 2557 traverse the path to the next hop. (If the encapsulation header is 2558 IPv4, the OAL source first translates the encapsulation header into 2559 an IPv6 header with IPv4-Compatible IPv6 addresses before performing 2560 the fragmentation/reassembly operation while inserting an IPv6 2561 Fragment Header.) The OAL source then writes the "Parcel ID" and 2562 sets/clears the "(P)arcel" and "(More) (S)ub-Parcels" bits in the 2563 Fragment Header of the first fragment (see: Figure 5). (The OAL 2564 source sets P to 1 for a parcel or to 0 for a non-parcel. When P is 2565 1, the OAL next sets S to 1 for non-final sub-parcels or to 0 if the 2566 sub-parcel contains the final segment.) The OAL source then forwards 2567 each IP encapsulated packet/fragment to the next hop (i.e., after 2568 first translating the IPv6 encapsulation header back to IPv4 if 2569 necessary). 2571 When the next hop receives the encapsulated IP fragments or whole 2572 packets, it acts as an OAL destination and reassembles if necessary 2573 (i.e., after first translating the IPv4 encapsulation header to IPv6 2574 if necessary). If the P flag in the first fragment is 0, the OAL 2575 destination then processes the reassembled entity as an ordinary IP 2576 packet; otherwise it continues processing as a sub-parcel. If the 2577 OAL destination is not the final destination, it retains the sub- 2578 parcels along with their Parcel ID and Identification values for a 2579 brief time in hopes of re-combining with peer sub-parcels of the same 2580 original parcel identified by the 4-tuple consisting of the IP 2581 encapsulation source and destination, Identification and Parcel ID. 2582 The OAL destination re-combines peers by concatenating the segments 2583 included in sub-parcels with the same Parcel ID and with 2584 Identification values within 64 of one another to create a larger 2585 sub-parcel possibly even as large as the entire original parcel. 2586 Order of concatenation is not important, with the exception that the 2587 final sub-parcel (i.e., the one with S set to 0) must occur as the 2588 final concatenation before transmission. The OAL destination then 2589 appends a common IP header plus extensions to each re-combined sub- 2590 parcel while resetting M and N in each according to the above 2591 equations with J, K and L set accordingly. 2593 When the current OAL destination is an intermediate node, it next 2594 becomes an OAL source to forward the re-combined (sub-)parcel(s) to 2595 the next hop toward the final destination using encapsulation/ 2596 translation the same as specified above. (Each such intermediate 2597 node MUST ensure that the S flag remains set to 0 in the sub-parcel 2598 that contains the final segment.) When the parcel or sub-parcels 2599 arrive at the final OAL destination, it re-combines them into the 2600 largest possible (sub)-parcels while honoring the S flag then 2601 delivers them to upper layers which act on the enclosed 5-tuple 2602 information supplied by the original source. 2604 Note: while the final destination may be tempted to re-combine the 2605 sub-parcels of multiple different parcels with identical upper layer 2606 protocol 5-tuples and with non-final segments of identical length, 2607 this process could become complicated when the different parcels each 2608 have final segments of diverse lengths. Since this could possibly 2609 defeat any perceived performance advantages, the decision of whether 2610 and how to perform inter-parcel concatenation is an implementation 2611 matter. 2613 7. Frame Format 2615 When the OMNI interface forwards original IP packets from the network 2616 layer it first invokes the OAL to create OAL packets/fragments if 2617 necessary, then includes any L2 encapsulations and finally engages 2618 the native frame format of the underlay interface. For example, for 2619 Ethernet-compatible interfaces the frame format is specified in 2620 [RFC2464], for aeronautical radio interfaces the frame format is 2621 specified in standards such as ICAO Doc 9776 (VDL Mode 2 Technical 2622 Manual), for various forms of tunnels the frame format is found in 2623 the appropriate tunneling specification, etc. 2625 See Figure 2 for a map of the various L2 layering combinations 2626 possible. For any layering combination, the final layer (e.g., UDP, 2627 IP, Ethernet, etc.) must have an assigned number and frame format 2628 representation that is compatible with the selected underlay 2629 interface. 2631 8. Link-Local Addresses (LLAs) 2633 [RFC4861] requires that nodes assign Link-Local Addresses (LLAs) to 2634 all interfaces, and that routers use their LLAs as the source address 2635 for RA and Redirect messages. OMNI interfaces honor the first 2636 requirement, but do not honor the second since the OMNI link could 2637 consist of the concatenation of multiple links with diverse ULA 2638 prefixes (see Section 9) but for which multiple nodes might configure 2639 identical interface identifiers (IIDs). OMNI interface LLAs are 2640 therefore considered only as context for IID formation as discussed 2641 below and have no other operational role. 2643 OMNI interfaces assign IPv6 LLAs through pre-service administrative 2644 actions. Clients assign "LLA-MNPs" with IIDs that embed the Client's 2645 unique MNP, while Proxy/Servers assign "LLA-RNDs" that include a 2646 randomly-generated IIDs generated as specified in [RFC7217]. LLAs 2647 are configured as follows: 2649 * IPv6 LLA-MNPs encode the most-significant 64 bits of an MNP within 2650 the least-significant 64 bits of the IPv6 link-local prefix 2651 fe80::/64, i.e., in the IID portion of the LLA. The LLA prefix 2652 length is determined by adding 64 to the MNP prefix length. e.g., 2653 for the MNP 2001:db8:1000:2000::/56 the corresponding LLA-MNP 2654 prefix is fe80::2001:db8:1000:2000/120. (The base LLA-MNP for 2655 each "/N" prefix sets the final 128-N bits to 0, but all LLA-MNPs 2656 that match the prefix are also accepted.) Non-MNP IPv6 prefix- 2657 based LLAs are also represented the same as for LLA-MNPs, but 2658 include a GUA prefix that is not properly covered by the MSP. 2660 * IPv4-Compatible LLA-MNPs are constructed as fe80::{IPv4-Prefix}, 2661 i.e., the IID consists of 32 '0' bits followed by a 32 bit IPv4 2662 address/prefix, which may be either public or private in 2663 correspondence with the network layer addressing plan. The 2664 IPv4-Compatible LLA-MNP prefix length is determined by adding 96 2665 to the IPv4 prefix length. For example, the IPv4-Compatible LLA- 2666 MNP for 192.0.2.0/24 is fe80::192.0.2.0/120, also written as 2667 fe80::c000:0200/120. (The base LLA-MNP for each "/N" prefix sets 2668 the final 128-N bits to 0, but all LLA-MNPs that match the prefix 2669 are also accepted.) Non-MNP IPv4 prefix-based LLAs are also 2670 represented the same as for LLA-MNPs, but include a GUA prefix 2671 that is not properly covered by the MSP. 2673 * LLA-RNDs are randomly-generated and assigned to Proxy/Servers and 2674 other SRT infrastructure elements. They may also be assigned by 2675 Clients to support the MNP delegation process. The upper 72 bits 2676 of the LLA-RND encode the prefix fe80::/72, and the lower 56 bits 2677 include a randomly-generated candidate pseudo-random value 2678 configured as specified in [RFC7217]; if the most significant 24 2679 bits of the 56 bit candidate encodes the value '0', the node 2680 generates a new candidate to obtain one with a different most 2681 significant 24 bits to avoid overlap with IPv4-Compatible LLAs. 2683 * The address fe80::/128 (i.e., the LLA /64 prefix followed by an 2684 all-zero IID) is considered the LLA Subnet Router Anycast address 2686 Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 2687 MNPs can be allocated from that block ensuring that there is no 2688 possibility for overlap between the different MNP and RND LLA 2689 constructs discussed above. 2691 Since LLA-MNPs are based on the distribution of administratively 2692 assured unique MNPs, and since LLA-RNDs are assumed unique through 2693 pseudo-random assignment, OMNI interfaces set the autoconfiguration 2694 variable DupAddrDetectTransmits to 0 [RFC4862]. 2696 Note: If future protocol extensions relax the 64-bit boundary in IPv6 2697 addressing, the additional prefix bits of an MNP could be encoded in 2698 bits 16 through 63 of the LLA-MNP. (The most-significant 64 bits 2699 would therefore still be in bits 64-127, and the remaining bits would 2700 appear in bits 16 through 48.) However, this would interfere with 2701 the relationship between OMNI LLAs and ULAs (see: Section 9) and 2702 render many OMNI functions inoperable. The analysis provided in 2703 [RFC7421] furthermore suggests that the 64-bit boundary will remain 2704 in the IPv6 architecture for the foreseeable future. 2706 9. Unique-Local Addresses (ULAs) 2708 OMNI links use IPv6 Unique-Local Addresses (ULAs) as the source and 2709 destination addresses in both IPv6 ND messages and OAL packet IPv6 2710 encapsulation headers. ULAs are routable only within the scope of an 2711 OMNI link, and are derived from the IPv6 Unique Local Address prefix 2712 fd00::/8 (i.e., the prefix fc00::/7 followed by the L bit set to 1). 2713 When the first 16 bits of the ULA encode the value fd00::/16, the 2714 address is considered as either a Temporary ULA (TLA) or an eXtended 2715 ULA (XLA) - see below. For all other ULAs, the 56 bits following 2716 fd00::/8 encode a 40-bit Global ID followed by a 16-bit Subnet ID as 2717 specified in Section 3 of [RFC4193]. All OMNI link ULA types finally 2718 include a 64-bit value in the IID portion of the address ULA::/64 as 2719 specified below. 2721 When a node configures a ULA for OMNI, it selects a 40-bit Global ID 2722 for the OMNI link initialized to a candidate pseudo-random value as 2723 specified in Section 3 of [RFC4193]; if the most significant 8 bits 2724 of the candidate encodes the value '0', the node selects a new 2725 candidate until it obtains one with a different most significant 8 2726 bits. All nodes on the same OMNI link use the same Global ID, and 2727 statistical uniqueness of the pseudo-random Global ID provides a 2728 unique OMNI link identifier allowing different links to be joined 2729 together in the future without requiring renumbering. 2731 Next, for each logical segment of the same OMNI link the node selects 2732 a 16-bit Subnet ID value between 0x0000 and 0xffff. Nodes on the 2733 same logical segment configure the same Subnet ID, but nodes on 2734 different segments of the same OMNI link can still exchange IPv6 ND 2735 messages as single-hop neighbors even if they configure different 2736 Subnet IDs. When a node moves to a different OMNI link segment, it 2737 resets the Global ID and Subnet ID value according to the new segment 2738 but need not change the IID. 2740 ULAs and their associated prefix lengths are configured in 2741 correspondence with LLAs through stateless prefix translation where 2742 "ULA-MNPs" simply copy the IIDs of their corresponding LLA-MNPs and 2743 "ULA-RNDs" simply copy the IIDs of their corresponding LLA-RNDs. For 2744 example, for the OMNI link ULA prefix fd{Global}:{Subnet}::/64: 2746 * the ULA-MNP corresponding to the LLA-MNP fe80::2001:db8:1:2 with a 2747 56-bit MNP length is simply fd{Global}:{Subnet}:2001:db8:1:2/120 2748 (where, the ULA prefix length becomes 64 plus the IPv6 MNP 2749 length). 2751 * the ULA-MNP corresponding to fe80::192.0.2.0 with a 28-bit MNP 2752 length is simply fd{Global}:{Subnet}::192.0.2.0/124 (where, the 2753 ULA prefix length becomes 96 plus the IPv4 MNP length). 2755 * the ULA-RND corresponding to fe80::0012:3456:789a:bcde is simply 2756 fd{Global}:{Subnet}::0012:3456:789a:bcde/128. 2758 * the Subnet Router Anycast ULA corresponding to fe80::/128 is 2759 simply fd{Global}:{Subnet}::/128. 2761 The ULA presents an IPv6 address format that is routable within the 2762 OMNI link routing system and can be used to convey link-scoped (i.e., 2763 single-hop) IPv6 ND messages across multiple hops through IPv6 2764 encapsulation [RFC2473]. The OMNI link extends across one or more 2765 underlying Internetworks to include all Proxy/Servers and other 2766 service nodes. All Clients are also considered to be connected to 2767 the OMNI link, however unnecessary encapsulations are omitted 2768 whenever possible to conserve bandwidth (see: Section 14). 2770 Clients can configure TLAs when they have no other ULA addresses by 2771 setting the ULA prefix to fd00::/16 followed by a 48-bit randomly- 2772 generated number followed by a random or MNP-based IID as discussed 2773 in Section 8. XLAs are a special-case TLA that use the prefix 2774 fd00::/64. (Note that XLAs can also be formed from LLAs simply by 2775 inverting bits 7 and 8 of 'fe80' to form 'fd00'.) 2777 OMNI nodes use XLA-MNPs as "default" ULAs for representing MNPs in 2778 the OMNI link routing system. Clients use {TLA,XLA}-MNPs when they 2779 already know their MNP but need to express it outside the context of 2780 a specific ULA prefix, and Proxy/Servers advertise XLA-MNPs into the 2781 OMNI link routing system instead of advertising fully-qualified 2782 {TLA,ULA}-MNPs and/or non-routable LLA-MNPs. 2784 {TLAs,XLAs} provide initial "bootstrapping" addresses while the 2785 Client is in the process of procuring an MNP and/or identifying the 2786 ULA prefix for the OMNI link segment; TLAs are not advertised into 2787 the OMNI link routing system but can be used for Client-to-Client 2788 communications within a single {A,I,E}NET when no OMNI link 2789 infrastructure is present. Within each individual {A,I,E}NET, TLAs 2790 employ optimistic DAD principles [RFC4429] since they are 2791 statistically unique. 2793 Each OMNI link may be subdivided into SRT segments that often 2794 correspond to different administrative domains or physical 2795 partitions. Each SRT segment is identified by a different Subnet ID 2796 within the same ULA ::/48 prefix. Multiple distinct OMNI links with 2797 different ULA ::/48 prefixes can also be joined together into a 2798 single unified OMNI link through simple interconnection without 2799 requiring renumbering. In that case, the (larger) unified OMNI link 2800 routing system may carry multiple distinct ULA prefixes. 2802 OMNI nodes can use Segment Routing [RFC8402] to support efficient 2803 forwarding to destinations located in other OMNI link segments. A 2804 full discussion of Segment Routing over the OMNI link appears in 2805 [I-D.templin-6man-aero]. 2807 Note: IPv6 ULAs taken from the prefix fc00::/7 followed by the L bit 2808 set to 0 (i.e., as fc00::/8) are never used for OMNI OAL addressing, 2809 however the range could be used for MSP/MNP addressing under certain 2810 limiting conditions (see: Section 10). When used within the context 2811 of OMNI, ULAs based on the prefix fc00::/8 are referred to as "ULA- 2812 C's". 2814 Note: When they appear in the OMNI link routing table, ULA-RNDs 2815 always use prefix lengths between /48 and /64 (or, /128) while XLA- 2816 MNPs always use prefix lengths between /65 and /128. {TLA,ULA}-MNPs 2817 and {TLA,XLA}-RNDs should never appear in the OMNI link routing 2818 table, but may appear in {A,I,E}NET routing tables. 2820 10. Global Unicast Addresses (GUAs) 2822 OMNI domains use IP Global Unicast Address (GUA) prefixes [RFC4291] 2823 as Mobility Service Prefixes (MSPs) from which Mobile Network 2824 Prefixes (MNP) are delegated to Clients. Fixed correspondent node 2825 networks reachable from the OMNI link are represented by non-MNP GUA 2826 prefixes that are not derived from the MSP, but are treated in all 2827 other ways the same as for MNPs. 2829 For IPv6, GUA MSPs are assigned by IANA [IPV6-GUA] and/or an 2830 associated Regional Internet Registry (RIR) such that the OMNI link 2831 can be interconnected to the global IPv6 Internet without causing 2832 inconsistencies in the routing system. An OMNI link could instead 2833 use ULAs with the 'L' bit set to 0 (i.e., from the prefix 2834 fc00::/8)[RFC4193], however this would require IPv6 NAT if the domain 2835 were ever connected to the global IPv6 Internet. 2837 For IPv4, GUA MSPs are assigned by IANA [IPV4-GUA] and/or an 2838 associated RIR such that the OMNI link can be interconnected to the 2839 global IPv4 Internet without causing routing inconsistencies. An 2840 OMNI ANET/ENET could instead use private IPv4 prefixes (e.g., 2841 10.0.0.0/8, etc.) [RFC3330], however this would require IPv4 NAT at 2842 the INET-to-ANET/ENET boundary. OMNI interfaces advertise IPv4 MSPs 2843 into IPv6 routing systems as IPv4-Compatible IPv6 prefixes [RFC4291] 2844 (e.g., the IPv6 prefix for the IPv4 MSP 192.0.2.0/24 is 2845 ::192.0.2.0/120). 2847 OMNI interfaces assign the IPv4 anycast address TBD3 (see: IANA 2848 Considerations), and IPv4 routers that configure OMNI interfaces 2849 advertise the prefix TBD3/N into the routing system of other networks 2850 (see: IANA Considerations). OMNI interfaces also configure global 2851 IPv6 anycast addresses formed according to [RFC3056] as: 2853 2002:TBD3{32}:MSP{64}:Link-ID{16} 2855 where TBD3{32} is the 32 bit IPv4 anycast address and MSP{64} encodes 2856 an MSP zero-padded to 64 bits (if necessary). For example, the OMNI 2857 IPv6 anycast address for MSP 2001:db8::/32 is 2858 2002:TBD3{32}:2001:db8:0:0:{Link-ID}, the OMNI IPv6 anycast address 2859 for MSP 192.0.2.0/24 is 2002:TBD3{32}::c000:0200:{Link-ID}, etc.). 2861 The16-bit Link-ID in the OMNI IPv6 anycast address identifies a 2862 specific OMNI link within the domain that services the MSP. The 2863 special Link-ID value '0' is a wildcard that matches all links, while 2864 all other values identify specific links. Mappings between Link-ID 2865 values and the ULA Global IDs assigned to OMNI links are outside the 2866 scope of this document. 2868 OMNI interfaces assign OMNI IPv6 anycast addresses, and IPv6 routers 2869 that configure OMNI interfaces advertise the corresponding prefixes 2870 into the routing systems of other networks. An OMNI IPv6 anycast 2871 prefix is formed the same as for any IPv6 prefix; for example, the 2872 prefix 2002:TBD3{32}:2001:db8::/80 matches all OMNI IPv6 anycast 2873 addresses covered by the prefix. When IPv6 routers advertise OMNI 2874 IPv6 anycast prefixes in this way, Clients can locate and associate 2875 with either a specific OMNI link or any OMNI link within the domain 2876 that services the MSP of interest. 2878 OMNI interfaces use OMNI IPv6 and IPv4 anycast addresses to support 2879 Service Discovery in the spirit of [RFC7094], i.e., the addresses are 2880 not intended for use in long-term transport protocol sessions. 2881 Specific applications for OMNI IPv6 and IPv4 anycast addresses are 2882 discussed throughout the document as well as in 2883 [I-D.templin-6man-aero]. 2885 11. Node Identification 2887 OMNI Clients and Proxy/Servers that connect over open Internetworks 2888 include a unique node identification value for themselves in the OMNI 2889 options of their IPv6 ND messages (see: Section 12.2.12). An example 2890 identification value alternative is the Host Identity Tag (HIT) as 2891 specified in [RFC7401], while Hierarchical HITs (HHITs) 2892 [I-D.ietf-drip-rid] may be more appropriate for certain domains such 2893 as the Unmanned (Air) Traffic Management (UTM) service for Unmanned 2894 Air Systems (UAS). Another example is the Universally Unique 2895 IDentifier (UUID) [RFC4122] which can be self-generated by a node 2896 without supporting infrastructure with very low probability of 2897 collision. 2899 When a Client is truly outside the context of any infrastructure, it 2900 may have no MNP information at all. In that case, the Client can use 2901 a TLA or (H)HIT as an IPv6 source/destination address for sustained 2902 communications in Vehicle-to-Vehicle (V2V) and (multihop) Vehicle-to- 2903 Infrastructure (V2I) scenarios. The Client can also propagate the 2904 ULA/(H)HIT into the multihop routing tables of (collective) Mobile/ 2905 Vehicular Ad-hoc Networks (MANETs/VANETs) using only the vehicles 2906 themselves as communications relays. 2908 When a Client connects via a protected-spectrum ANET, an alternate 2909 form of node identification (e.g., MAC address, serial number, 2910 airframe identification value, VIN, etc.) embedded in a ULA may be 2911 sufficient. The Client can then include OMNI "Node Identification" 2912 sub-options (see: Section 12.2.12) in IPv6 ND messages should the 2913 need to transmit identification information over the network arise. 2915 12. Address Mapping - Unicast 2917 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 2918 state and use the link-local address format specified in Section 8. 2919 IPv6 Neighbor Discovery (ND) [RFC4861] messages sent over OMNI 2920 interfaces without encapsulation observe the native underlay 2921 interface Source/Target Link-Layer Address Option (S/TLLAO) format 2922 (e.g., for Ethernet the S/TLLAO is specified in [RFC2464]). IPv6 ND 2923 messages sent over OMNI interfaces using encapsulation do not include 2924 S/TLLAOs, but instead include a new option type that encodes 2925 encapsulation addresses, interface attributes and other OMNI link 2926 information. Hence, this document does not define an S/TLLAO format 2927 but instead defines a new option type termed the "OMNI option" 2928 designed for these purposes. (Note that OMNI interface IPv6 ND 2929 messages sent without encapsulation may include both OMNI options and 2930 S/TLLAOs, but the information conveyed in each is mutually 2931 exclusive.) 2933 OMNI interfaces prepare IPv6 ND messages that include one or more 2934 OMNI options (and any other IPv6 ND options) then completely populate 2935 all option information. If the OMNI interface includes an 2936 authentication signature, it sets the IPv6 ND message Checksum field 2937 to 0 and calculates the authentication signature over the length of 2938 the entire OAL packet or super-packet (beginning with a pseudo-header 2939 of the IPv6 ND message IPv6 header) but does not calculate/include 2940 the IPv6 ND message checksum itself. Otherwise, the OMNI interface 2941 calculates the standard IPv6 ND message checksum over the entire OAL 2942 packet or super-packet and writes the value in the Checksum field. 2943 OMNI interfaces verify authentication and/or integrity of each IPv6 2944 ND message received according to the specific check(s) included, and 2945 process the message further only following verification. 2947 OMNI interface Clients such as aircraft typically have multiple 2948 wireless data link types (e.g. satellite-based, cellular, 2949 terrestrial, air-to-air directional, etc.) with diverse performance, 2950 cost and availability properties. The OMNI interface would therefore 2951 appear to have multiple L2 connections, and may include information 2952 for multiple underlay interfaces in a single IPv6 ND message 2953 exchange. OMNI interfaces manage their dynamically-changing 2954 multilink profiles by including OMNI options in IPv6 ND messages as 2955 discussed in the following subsections. 2957 12.1. The OMNI Option 2959 OMNI options appear in IPv6 ND messages formatted as shown in 2960 Figure 12: 2962 0 1 2 3 2963 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 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | Type | Length | Sub-Options ~ 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 Figure 12: OMNI Option Format 2970 In this format: 2972 * Type is set to TBD4 (see: IANA Considerations). 2974 * Length is set to the number of 8 octet blocks in the option. The 2975 value 0 is invalid, while the values 1 through 255 (i.e., 8 2976 through 2040 octets, respectively) indicate the total length of 2977 the OMNI option. If multiple OMNI option instances appear in the 2978 same IPv6 ND message, the union of the contents of all OMNI 2979 options is accepted unless otherwise qualified for specific sub- 2980 options below. 2982 * Sub-Options is a Variable-length field padded if necessary such 2983 that the complete OMNI Option is an integer multiple of 8 octets 2984 long. Sub-Options contains zero or more sub-options as specified 2985 in Section 12.2. 2987 The OMNI option is included in all OMNI interface IPv6 ND messages; 2988 the option is processed by receiving interfaces that recognize it and 2989 otherwise ignored. The OMNI interface processes all OMNI option 2990 instances received in the same IPv6 ND message in the consecutive 2991 order in which they appear. The OMNI option(s) included in each IPv6 2992 ND message may include full or partial information for the neighbor. 2993 The OMNI interface therefore retains the union of the information in 2994 the most recently received OMNI options in the corresponding NCE. 2996 12.2. OMNI Sub-Options 2998 Each OMNI option includes a Sub-Options block containing zero or more 2999 individual sub-options. Each consecutive sub-option is concatenated 3000 immediately following its predecessor. All sub-options except Pad1 3001 (see below) are in an OMNI-specific type-length-value (TLV) format 3002 encoded as follows: 3004 0 1 2 3005 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 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3007 | Sub-Type| Sub-Length | Sub-Option Data ... 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3010 Figure 13: Sub-Option Format 3012 * Sub-Type is a 5-bit field that encodes the sub-option type. Sub- 3013 option types defined in this document are: 3015 Sub-Option Name Sub-Type 3016 Pad1 0 3017 PadN 1 3018 Neighbor Coordination 2 3019 Interface Attributes 3 3020 Multilink Forwarding Params 4 3021 Traffic Selector 5 3022 Geo Coordinates 6 3023 DHCPv6 Message 7 3024 HIP Message 8 3025 PIM-SM Message 9 3026 Fragmentation Report 10 3027 Node Identification 11 3028 ICMPv6 Error 12 3029 QUIC-TLS Message 13 3030 Proxy/Server Departure 14 3031 Sub-Type Extension 30 3033 Figure 14 3035 Sub-Types 15-29 are available for future assignment for major 3036 protocol functions, while Sub-Type 30 supports scalable extension 3037 to include other functions. Sub-Type 31 is reserved by IANA. 3039 * Sub-Length is an 11-bit field that encodes the length of the Sub- 3040 Option Data in octets. 3042 * Sub-Option Data is a block of data with format determined by Sub- 3043 Type and length determined by Sub-Length. Note that each 3044 individual sub-option may end on an arbitrary octet boundary, 3045 whereas the OMNI option itself must include padding if necessary 3046 for 8-octet alignment. 3048 The OMNI interface codes each sub-option with a 2 octet header that 3049 includes Sub-Type in the most significant 5 bits followed by Sub- 3050 Length in the next most significant 11 bits. Each sub-option encodes 3051 a maximum Sub-Length value of 2038 octets minus the lengths of the 3052 OMNI option header and any preceding sub-options. This allows ample 3053 Sub-Option Data space for coding large objects (e.g., ASCII strings, 3054 domain names, protocol messages, security codes, etc.), while a 3055 single OMNI option is limited to 2040 octets the same as for any IPv6 3056 ND option. 3058 The OMNI interface codes initial sub-options in a first OMNI option 3059 instance and subsequent sub-options in additional instances in the 3060 same IPv6 ND message in the intended order of processing. The OMNI 3061 interface can then code any remaining sub-options in additional IPv6 3062 ND messages if necessary. Implementations must observe these size 3063 limits and refrain from sending IPv6 ND messages larger than the OMNI 3064 interface MTU. 3066 The OMNI interface processes all OMNI option Sub-Options received in 3067 an IPv6 ND message while skipping over and ignoring any unrecognized 3068 sub-options. The OMNI interface processes the Sub-Options of all 3069 OMNI option instances in the consecutive order in which they appear 3070 in the IPv6 ND message, beginning with the first instance and 3071 continuing through any additional instances to the end of the 3072 message. If an individual sub-option length would cause processing 3073 to exceed the OMNI option instance and/or IPv6 ND message lengths, 3074 the OMNI interface accepts any sub-options already processed and 3075 ignores the remainder of that instance. The interface then processes 3076 any remaining OMNI option instances in the same fashion to the end of 3077 the IPv6 ND message. 3079 When an OMNI interface includes an authentication sub-option (e.g., 3080 see: Section 12.2.9), it MUST appear as the first sub-option of the 3081 first OMNI option which must appear immediately following the IPv6 ND 3082 message header (all other authentication sub-options are ignored). 3083 If the IPv6 ND message is the first packet in a combined OAL super- 3084 packet, the OMNI interface calculates the authentication signature 3085 over the entire length of the super-packet, i.e., and not just to the 3086 end of the IPv6 ND message itself. When the first sub-option is not 3087 authentication, the OMNI interface instead calculates the IPv6 ND 3088 message checksum over the entire length of the packet/super-packet. 3090 When a Client OMNI interface prepares a secured unicast RS message, 3091 it includes an Interface Attributes sub-option specific to the 3092 underlay interface that will transmit the RS (see: Section 12.2.4) 3093 immediately following the authentication and header extension sub- 3094 options if present; otherwise as the first sub-option of the first 3095 OMNI option which must appear immediately following the IPv6 ND 3096 message header. When a Client OMNI interface prepares a secured 3097 unicast NS message, it instead includes a Multilink Forwarding 3098 Parameters sub-option specific to the underlay interface that will 3099 transmit the NS (see: Section 12.2.5). 3101 Note: large objects that exceed the maximum Sub-Option Data length 3102 are not supported under the current specification; if this proves to 3103 be limiting in practice, future specifications may define support for 3104 fragmenting large sub-options across multiple OMNI options within the 3105 same IPv6 ND message (or even across multiple IPv6 ND messages, if 3106 necessary). 3108 The following sub-option types and formats are defined in this 3109 document: 3111 12.2.1. Pad1 3113 0 3114 0 1 2 3 4 5 6 7 3115 +-+-+-+-+-+-+-+-+ 3116 | S-Type=0|x|x|x| 3117 +-+-+-+-+-+-+-+-+ 3119 Figure 15: Pad1 3121 * Sub-Type is set to 0. If multiple instances appear in OMNI 3122 options of the same message all are processed. 3124 * Sub-Type is followed by 3 'x' bits, set to any value on 3125 transmission (typically all-zeros) and ignored on reception. Pad1 3126 therefore consists of 1 octet with the most significant 5 bits set 3127 to 0, and with no Sub-Length or Sub-Option Data fields following. 3129 If more than one octet of padding is required, the PadN option, 3130 described next, should be used, rather than multiple Pad1 options. 3132 12.2.2. PadN 3134 0 1 2 3135 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 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3137 | S-Type=1| Sub-length=N | N padding octets ... 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3140 Figure 16: PadN 3142 * Sub-Type is set to 1. If multiple instances appear in OMNI 3143 options of the same message all are processed. 3145 * Sub-Length is set to N that encodes the number of padding octets 3146 that follow. 3148 * Sub-Option Data consists of N octets, set to any value on 3149 transmission (typically all-zeros) and ignored on receipt. 3151 When a proxy forwards an IPv6 ND message with OMNI options, it can 3152 employ PadN to cancel any sub-options (other than Pad1) that should 3153 not be processed by the next hop by simply writing the value '1' over 3154 the Sub-Type. When the proxy alters the IPv6 ND message contents in 3155 this way, any included authentication and integrity checks are 3156 invalidated. See: Appendix B for a discussion of IPv6 ND message 3157 authentication and integrity. 3159 12.2.3. Neighbor Coordination 3161 IPv6 ND messages used for Prefix Length assertion, service 3162 coordination and/or Window Synchronization include a Neighbor 3163 Coordination sub-option. If a Neighbor Coordination sub-option is 3164 included, it must appear immediately after the authentication sub- 3165 option if present; otherwise, as the first (non-padding) sub-option 3166 of the first OMNI option. If multiple Neighbor Coordination sub- 3167 options are included (whether in a single OMNI option or multiple), 3168 only the first is processed and all others are ignored. 3170 The Neighbor Coordination sub-option is formatted as follows: 3172 0 1 2 3 3173 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 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 | S-Type=2| Sub-length=14 | Preflen |N|A|U| Reservd | 3176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3177 | Sequence Number | 3178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3179 | Acknowledgment Number | 3180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3181 |S|A|R|O|P| | | 3182 |Y|C|S|P|N| Res | Window | 3183 |N|K|T|T|G| | | 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 Figure 17: Neighbor Coordination 3188 * Sub-Type is set to 2. 3190 * Sub-Length is set to 14. 3192 * The first two octets of Sub-Option Data contains a 1-octet Prefix 3193 Length followed by a 1-octet flags field interpreted as follows: 3195 - Preflen is an 8 bit field that determines the length of prefix 3196 associated with a ULA. Values 0 through 128 specify a valid 3197 prefix length (if any other value appears the OMNI option must 3198 be ignored). For IPv6 ND messages sent from a Client to the 3199 MS, Preflen applies to the IPv6 source ULA and provides the 3200 length that the Client is requesting from or asserting to the 3201 MS. For IPv6 ND messages sent from the MS to the Client, 3202 Preflen applies to the IPv6 destination ULA and indicates the 3203 length that the MS is granting to the Client. For IPv6 ND 3204 messages sent between MS endpoints, Preflen provides the length 3205 associated with the source/target Client MNP that is subject of 3206 the ND message. When an IPv6 ND RS/RA message sets Preflen to 3207 0, the recipient regards the message as a prefix release 3208 indication. 3210 - The N/A/U flags are set or cleared in Client RS messages as 3211 directives to FHS and Hub Proxy/Servers and ignored in all 3212 other IPv6 ND messages. When an FHS Proxy/Server forwards or 3213 processes an RS with the N flag set, it responds directly to NS 3214 Neighbor Unreachability Detection (NUD) messages by returning 3215 NA(NUD) replies; otherwise, it forwards NS(NUD) messages to the 3216 Client. When the Hub Proxy/Server receives an RS with the A 3217 flag set, it responds directly to NS Address Resolution (AR) 3218 messages by returning NA(AR) replies; otherwise, it forwards 3219 NS(AR) messages to the Client. When the Hub Proxy/Server 3220 receives an RS with the U flag set, it maintains a Report List 3221 of recent NS(AR) message sources for this Client and sends uNA 3222 messages to all list members if any aspects of the Client's 3223 underlay interfaces change. Proxy/Servers function according 3224 to the N/A/U flag settings received in the most recent RS 3225 message to support dynamic Client updates. In all IPv6 ND 3226 messages, the remaining 5 flag bits are set to 0 on 3227 transmission and ignored on reception. 3229 * The remainder of Sub-Option Data contains a 4-octet Sequence 3230 Number, followed by a 4-octet Acknowledgement Number, followed by 3231 a 1-octet flags field followed by a 3-octet Window size modeled 3232 from the Transmission Control Protocol (TCP) header specified in 3233 Section 3.1 of [RFC0793]. The (SYN, ACK, RST) flags are used for 3234 TCP-like window synchronization, while the TCP (URG, PSH, FIN) 3235 flags are not used and therefore omitted. The (OPT, PNG) flags 3236 are OMNI-specific, and the remaining flags are Reserved. 3237 Together, these fields support the asymmetric and symmetric OAL 3238 window synchronization services specified in Section 6.6. 3240 12.2.4. Interface Attributes 3242 The Interface Attributes sub-option provides neighbors with 3243 forwarding information for the multilink conceptual sending algorithm 3244 discussed in Section 14. Neighbors use the forwarding information to 3245 selecting among potentially multiple candidate underlay interfaces 3246 that can be used to forward carrier packets to the neighbor based on 3247 factors such as traffic selectors and link quality. Interface 3248 Attributes further include link-layer address information to be used 3249 for either direct INET encapsulation for targets in the local SRT 3250 segment or spanning tree forwarding for targets in remote SRT 3251 segments. 3253 OMNI nodes include Interface Attributes for some/all of a target 3254 Client's underlay interfaces in NS/NA and uNA messages used to 3255 publish Client information (see: [I-D.templin-6man-aero]). At most 3256 one Interface Attributes sub-option for each distinct omIndex may be 3257 included; if an NS/NA message includes multiple Interface Attributes 3258 sub-options for the same omIndex, the first is processed and all 3259 others are ignored. OMNI nodes that receive NS/NA messages can use 3260 all of the included Interface Attributes and/or Traffic Selectors to 3261 formulate a map of the prospective target node as well as to seed the 3262 information to be populated in a Multilink Forwarding Parameters sub- 3263 option (see: Section 12.2.5). 3265 OMNI Clients and Proxy/Servers also include Interface Attributes sub- 3266 options in RS/RA messages used to initialize, discover and populate 3267 routing and addressing information. Each RS message MUST contain 3268 exactly one Interface Attributes sub-option with an omIndex 3269 corresponding to the Client's underlay interface used to transmit the 3270 message, and each RA message MUST echo the same Interface Attributes 3271 sub-option with any (proxyed) information populated by the FHS Proxy/ 3272 Server to provide operational context. 3274 OMNI Client RS and Proxy/Server RA messages MUST include the 3275 Interface Attributes sub-option for the Client underlay interface in 3276 the first OMNI option immediately following the Neighbor Coordination 3277 and/or authentication sub-option(s) if present; otherwise, 3278 immediately following the OMNI header. When an FHS Proxy/Server 3279 receives an RS message destined to an anycast L2 address, it MUST 3280 include an Interface Attributes sub-option with omIndex '0' that 3281 encodes its unicast L2 address relative to the Client's underlay 3282 interface immediately after the Interface Attributes sub-option in 3283 the solicited RA response. Any additional Interface Attributes sub- 3284 options that appear in RS/RA messages are ignored. 3286 The Interface Attributes sub-options are formatted as shown below: 3288 0 1 2 3 3289 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 3290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3291 | S-Type=3| Sub-length=N | omIndex | omType | 3292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3293 | Provider ID | Link | Resvd | FMT | SRT | ~ 3294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 3295 ~ LHS Proxy/Server ULA/INADDR ~ 3296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 Figure 18: Interface Attributes 3300 * Sub-Type is set to 3. 3302 * Sub-Length is set to N that encodes the number of Sub-Option Data 3303 octets that follow. 3305 * Sub-Option Data contains an "Interface Attributes" option encoded 3306 as follows: 3308 - omIndex is a 1-octet value corresponding to a specific underlay 3309 interface. Client OMNI interfaces MUST number each distinct 3310 underlay interface with an omIndex value between '1' and '255' 3311 that represents a Client-specific 8-bit mapping for the actual 3312 ifIndex value assigned by network management [RFC2863], then 3313 set omIndex to either a specific omIndex value or '0' to denote 3314 "unspecified". 3316 - omType is set to an 8-bit integer value corresponding to the 3317 underlay interface identified by omIndex. The value represents 3318 an OMNI interface-specific 8-bit mapping for the actual IANA 3319 ifType value registered in the 'IANAifType-MIB' registry 3320 [http://www.iana.org]. 3322 - Provider ID is set to an OMNI interface-specific 8-bit ID value 3323 for the network service provider associated with this omIndex. 3325 - Link encodes a 4-bit link metric. The value '0' means the link 3326 is DOWN, and the remaining values mean the link is UP with 3327 metric ranging from '1' ("lowest") to '15' ("highest"). 3329 - Resvd is a 4-bit Reserved field set to 0 on transmission and 3330 ignored on reception. 3332 - FMT - a 3-bit "Forward/Mode/Type" code interpreted as follows: 3334 o The most significant two bits (i.e., "FMT-Forward" and "FMT- 3335 Mode") are interpreted in conjunction with one another. 3336 When FMT-Forward is clear, the LHS Proxy/Server performs OAL 3337 reassembly and decapsulation to obtain the original IP 3338 packet before forwarding. If the FMT-Mode bit is clear, the 3339 LHS Proxy/Server then forwards the original IP packet at 3340 layer 3; otherwise, it invokes the OAL to re-encapsulate, 3341 re-fragment and forwards the resulting carrier packets to 3342 the Client via the selected underlay interface. When FMT- 3343 Forward is set, the LHS Proxy/Server forwards unsecured OAL 3344 fragments to the Client without reassembling, while 3345 reassembling secured OAL fragments before re-fragmenting and 3346 forwarding to the Client. If FMT-Mode is clear, all carrier 3347 packets destined to the Client must always be forwarded 3348 through the LHS Proxy/Server; otherwise the Client is 3349 eligible for direct forwarding over the open INET where it 3350 may be located behind one or more NATs. 3352 o The least significant bit (i.e., "FMT-Type") determines the 3353 length of the LHS Proxy/Server INADDR field. If FMT-Type is 3354 clear, INADDR includes a 4-octet IPv4 address; otherwise, a 3355 16-octet IPv6 address. (Note: the INADDR "short form" 3356 minimizes overhead for ND messages that include many 3357 Interface Attributes sub-options with IPv4 addresses.) 3359 - SRT - a 5-bit Segment Routing Topology prefix length value 3360 between 0 and 16 that (when added to 48) determines the prefix 3361 length associated with the LHS ULA Subnet ID. For example, the 3362 value 5 corresponds to the prefix ULA::/53. 3364 - LHS Proxy/Server ULA/INADDR - the first 15 octets following the 3365 "FMT/SRT" octet includes the 120 least significant bits of the 3366 ULA of the LHS Proxy/Server on the path from a source neighbor 3367 to the target Client's underlay interface. (Note that the FMT/ 3368 SRT code is replaced with the value "fd" after processing to 3369 form a proper Proxy/Server ULA.) When SRT and ULA are both set 3370 to 0, the LHS Proxy/Server is considered unspecified in this 3371 IPv6 ND message. FMT, SRT and LHS together provide guidance 3372 for the OMNI interface forwarding algorithm. Specifically, if 3373 SRT/LHS is located in the local OMNI link segment, then the 3374 source can reach the target Client either through its dependent 3375 Proxy/Server or through direct encapsulation following NAT 3376 traversal according to FMT. Otherwise, the target Client is 3377 located on a different SRT segment and the path from the source 3378 must employ a combination of route optimization and spanning 3379 tree hop traversals. INADDR identifies the LHS Proxy/Server's 3380 INET-facing interface not located behind NATs, therefore no UDP 3381 port number is included since port number 8060 is used when the 3382 L2 encapsulation includes a UDP header. Instead, INADDR 3383 includes only a 4-octet IPv4 or 16-octet IPv6 address with type 3384 and length determined by FMT-Type. The IP address is recorded 3385 in network byte order in ones-compliment "obfuscated" form per 3386 [RFC4380]. 3388 12.2.5. Multilink Forwarding Parameters 3390 OMNI nodes include the Multilink Forwarding Parameters sub-option in 3391 NS/NA messages used to coordinate with multilink route optimization 3392 targets. If an NS message includes the sub-option, the solicited NA 3393 response must also include the sub-option. The OMNI node MUST 3394 include the sub-option in the first OMNI option immediately following 3395 the Neighbor Coordination and/or authentication message sub-option(s) 3396 if present. Otherwise, the OMNI node MUST include the sub-option 3397 immediately following the OMNI header. Each NS/NA message may 3398 contain at most one Multilink Forwarding Parameters sub-option; if an 3399 NS/NA message contains additional Multilink Forwarding Parameters 3400 sub-options, the first is processed and all others are ignored. 3402 When an NS/NA message includes the sub-option, the FHS Client omIndex 3403 MUST correspond to the underlay interface used to transmit the 3404 message. When the NS/NA message also includes Interface Attributes 3405 sub-options any that include the same FHS/LHS Client omIndex are 3406 ignored while all others are processed. 3408 The Multilink Forwarding Parameters sub-option includes the necessary 3409 state for establishing Multilink Forwarding Vectors (MFVs) in the 3410 Multilink Forwarding Information Bases (MFIBs) of the OAL source, 3411 destination and intermediate nodes in the path. The sub-option also 3412 records addressing information for FHS/LHS nodes on the path, 3413 including "INADDRs" which MUST be unicast IP encapsulation addresses 3414 (i.e., and not anycast/multicast). The manner for populating 3415 multilink forwarding information is specified in detail in 3416 [I-D.templin-6man-aero]. 3418 The Multilink Forwarding Parameters sub-option is formatted as shown 3419 in Figure 19: 3421 0 1 2 3 3422 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 3423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 | S-Type=4| Sub-length=N | Reserved | A | B |Job| 3425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3426 ~ Multilink Forwarding Vector Index (MFVI) List ~ 3427 ~ (5 consecutive 4-octet MFVIs) ~ 3428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3429 ~ Tunnel Window Synchronization Parameters ~ 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3431 |FHS Cli omIndex| omType | Provider ID | Link | Resvd | 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3433 | FMT | SRT | ~ 3434 +-+-+-+-+-+-+-+-+ ~ 3435 ~ FHS Proxy/Server ULA/INADDR ~ 3436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3437 ~ FHS Gateway ULA/INADDR ~ 3438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3439 |LHS Cli omIndex| omType | Provider ID | Link | Resvd | 3440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 | FMT | SRT | ~ 3442 +-+-+-+-+-+-+-+-+ ~ 3443 ~ LHS Proxy/Server ULA/INADDR ~ 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3445 ~ LHS Gateway ULA/INADDR ~ 3446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 Figure 19: Multilink Forwarding Parameters 3450 * Sub-Type is set to 4. If multiple instances appear in the same 3451 message (i.e., whether in a single OMNI option or multiple) the 3452 first instance is processed and all others are ignored. 3454 * Sub-Length encodes the number of Sub-Option Data octets that 3455 follow. The length includes all fields up to and including the 3456 Tunnel Window Synchronization Parameters for all Job codes, while 3457 including the remaining fields only for Job codes "0" and "1" (see 3458 below). 3460 * Sub-Option Data contains Multilink Forwarding Parameters as 3461 follows: 3463 - Reserved is a 1-octet reserved field set to 0 on transmission 3464 and ignored on receipt. 3466 - A/B and Job are fields that determine per-hop processing of the 3467 MFVI List, where A is a 3-bit count of the number of "A" MVFI 3468 List entries and B is a 3-bit count of the number of "B" MVFI 3469 List entries (valid A/B values are 0-5). Job is a 2-bit code 3470 interpreted as follows: 3472 o '00' - "Initialize; Build B" - the FHS source sets this code 3473 in an NS used to initialize MFV state (any other messages 3474 that include this code MUST be dropped). The FHS source 3475 first sets A/B to 0, and the FHS source and each 3476 intermediate node along the path to the LHS destination that 3477 processes the message creates a new MFV. Each node that 3478 processes the message then assigns a unique 4-octet "B" MFVI 3479 to the MVF and also writes the value into list entry B, then 3480 increments B. When the message arrives at the LHS 3481 destination, B will contain the number of MFVI List "B" 3482 entries, with the FHS source entry first, followed by 3483 entries for each consecutive intermediate node and ending 3484 with an entry for the final intermediate node (i.e., the 3485 list is populated in the forward direction). 3487 o '01' - "Follow B; Build A" - the LHS source sets this code 3488 in a solicited NA response to a solicitation with Job code 3489 "0" (any other messages that include this code MUST be 3490 dropped). The LHS source first copies the MFVI List and B 3491 value from the code "0" solicitation into these fields and 3492 sets A to 0. The LHS source and each intermediate node 3493 along the path to the FHS destination that processes the 3494 message then uses MFVI List entry B to locate the 3495 corresponding MFV. Each node that processes the message 3496 then assigns a unique 4-octet "A" MFVI to the MVF and also 3497 writes the value into list entry B, then increments A and 3498 decrements B. When the message arrives at the FHS 3499 destination, A will contain the number of MFVI List "A" 3500 entries, with the LHS source entry last, preceded by entries 3501 for each consecutive intermediate node and beginning with an 3502 entry for the final intermediate node (i.e., the list is 3503 populated in the reverse direction). 3505 o '10' - "Follow A; Record B" - the FHS node that sent the 3506 original code "0" solicitation and received the 3507 corresponding code "1" advertisement sets this code in any 3508 subsequent NS/NA messages sent to the same LHS destination. 3509 The FHS source copies the MVFI List and A value from the 3510 code "1" advertisement into these fields and sets B to 0. 3511 The FHS source and each intermediate node along the path to 3512 the LHS destination that processes the message then uses the 3513 "A" MFVI found at list entry B to locate the corresponding 3514 MFV. Each node that processes the message then writes the 3515 MVF's "B" MFVI into list entry B, then decrements A and 3516 increments B. When the message arrives at the LHS 3517 destination, B will contain the number of MFVI List "B" 3518 entries populated in the forward direction. 3520 o '11' - "Follow B; Record A" - the LHS node that received the 3521 original code "0" solicitation and sent the corresponding 3522 code "1" advertisement sets this code in any subsequent NS/ 3523 NA messages sent to the same FHS destination. The LHS 3524 source copies the MVFI List and B values from the code "0" 3525 solicitation into these fields and sets A to 0. The LHS 3526 source and each intermediate node along the path to the FHS 3527 destination that processes the message then uses the "B" 3528 MFVI List entry found at list entry B to locate the 3529 corresponding MFV. Each node that processes the message 3530 then writes the MFV's "A" MFVI into list entry B, then 3531 increments A and decrements B. When the message arrives at 3532 the FHS destination, A will contain the number of MFVI List 3533 "A" entries populated in the reverse direction. 3535 Job and A/B together determine the per-hop behavior at each 3536 FHS/LHS source, intermediate node and destination that 3537 processes an IPv6 ND message. When a Job code specifies 3538 "Initialize", each FHS/LHS node that processes the message 3539 creates a new MVF. When a Job code specifies "Build", each 3540 node that processes the message assigns a new MFVI. When a Job 3541 code specifies "Follow", each node that processes the message 3542 uses an A/B MFVI List entry to locate an MFV (if the MFV cannot 3543 be located, the node returns a parameter problem and drops the 3544 message). Using this algorithm, FHS sources that send code 3545 '00' solicitations and receive code '01' advertisements 3546 discover only "A" information, while LHS sources that receive 3547 code '00' solicitations and return code '01' advertisements 3548 discover only "B" information. FHS/LHS intermediate nodes can 3549 instead examine A, B and the MFVI List to determine the number 3550 of previous hops, the number of remaining hops, and the A/B 3551 MFVIs associated with the previous/remaining hops. However, no 3552 intermediate nodes will discover inappropriate A/B MFVIs for 3553 their location in the multihop forwarding chain. See: 3554 [I-D.templin-6man-aero] for further discussion on A/B MFVI 3555 processing. 3557 - Multilink Forwarding Vector Index (MFVI) List is a 20-octet 3558 block that contains 5 consecutive 4-octet MFVI entries. The 3559 FHS/LHS source and each intermediate node on the path to the 3560 destination processes the list according to the Job and A/B 3561 codes (see above). Note that the reason the MFVI list contains 3562 at most 5 entries is that only the FHS (Client, Proxy/Server, 3563 Gateway) and LHS (Client, Proxy/Server, Gateway) nodes are 3564 eligible for OMNI link route optimization resulting in at most 3565 5 MFVIs "hops" that must be exposed. All other OMNI link nodes 3566 (i.e., downstream Clients that connect via an FHS/LHS Client) 3567 must forward through their upstream-dependent OMNI link 3568 neighbors without applying OMNI link route optimization. 3570 - Tunnel Window Synchronization Parameters is a 12-octet block 3571 that consists of a 4-octet Sequence Number followed by a 3572 4-octet Acknowledgement Number followed by a 1-octet Flags 3573 field followed by a 3-octet Window field (i.e., the same as for 3574 the OMNI header parameters). Tunnel endpoints use these 3575 parameters for simultaneous middlebox window synchronization in 3576 a single solicitation/advertisement message exchange. 3578 - For Job codes '00' and '01' only, two trailing state variable 3579 blocks are included for First-Hop Segment (FHS) followed by 3580 Last-Hop Segment (LHS) network elements. When present, each 3581 block encodes the following information: 3583 o Client omIndex, omType, Provider ID and Resvd/Link are 3584 1-octet fields (at offset 0 from the beginning of the Sub- 3585 Option Data) that include link parameters for the Client 3586 underlay interface. These fields are populated based on 3587 information discovered in Interface Attributes sub-options 3588 included in earlier RS/RA and/or NS/NA exchanges. 3590 o FMT/SRT is a 1-octet field with a 5-bit SRT prefix length 3591 that applies to all elements in the segment. The FMT- 3592 Forward/Mode bits determine the characteristics of the 3593 Proxy/Server relationship for this specific Client underlay 3594 interface (i.e., the same as described in Section 12.2.4), 3595 and the FMT-Type bits determine the IP address version for 3596 all INADDR fields relative to this SRT segment. Unlike the 3597 case for Interface Attributes, all INADDR fields are always 3598 16 bits in length regardless of the IP protocol version with 3599 IPv4 INADDRs encoded as IPv4-Compatible IPv6 addresses 3600 [RFC4291]. (Note: the INADDR "long-form" is used 3601 exclusively since there may be no a priori knowledge of the 3602 IP address version used at each hop.) The IP address is 3603 recoded in network byte order, and in ones-compliment 3604 "obfuscated" form the same as described in Section 12.2.4. 3606 o Proxy/Server ULA/INADDR includes a 15 octet value that 3607 encodes the 120 least significant bits of the Proxy/Server 3608 ULA followed by a 16 octet INADDR. (Note that the FMT/SRT 3609 code is replaced with the value "fd" after processing to 3610 form a proper Proxy/Server ULA.) INADDR identifies an open 3611 INET interface not located behind NATs, therefore no UDP 3612 port number is included since port number 8060 is used when 3613 the L2 encapsulation includes a UDP header. 3615 o Gateway ULA/INADDR encodes a 16 octet ULA followed by a 16 3616 octet INADDR exactly as for the Proxy/Server ULA/INADDR. 3617 (Note that the Gateway ULA simply encodes the value "fd" in 3618 the most significant bits, since the FMT/SRT code applies to 3619 both the Proxy/Server and Gateway.) 3621 12.2.6. Traffic Selector 3623 When used in conjunction with Interface Attributes and/or Multilink 3624 Forwarding Parameters information, the Traffic Selector sub-option 3625 provides forwarding information for the multilink conceptual sending 3626 algorithm discussed in Section 14. 3628 IPv6 ND messages include Traffic Selectors for some or all of the 3629 source/target Client's underlay interfaces. Traffic Selectors for 3630 some or all of a target Client's underlay interfaces are also 3631 included in uNA messages used to publish Client information changes. 3632 See: [I-D.templin-6man-aero] for more information. 3634 Traffic Selectors must be honored by all implementations in the 3635 format shown below: 3637 0 1 2 3 3638 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 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 | S-Type=5| Sub-length=N | omIndex | TS Format | 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 ~ ~ 3643 ~ RFC 6088 Format Traffic Selector ~ 3644 ~ ~ 3645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 Figure 20: Traffic Selector 3649 * Sub-Type is set to 5. Each IPv6 ND message may contain zero or 3650 more Traffic Selectors for each omIndex; when multiple Traffic 3651 Selectors for the same omIndex appear, all are processed and the 3652 cumulative information from all is accepted. 3654 * Sub-Length is set to N that encodes the number of Sub-Option Data 3655 octets that follow. 3657 * Sub-Option Data contains a "Traffic Selector" encoded as follows: 3659 - omIndex is a 1-octet value corresponding to a specific underlay 3660 interface the same as specified above for Interface Attributes 3661 and Multilink Forwarding Parameters above. The OMNI options of 3662 a single message may include multiple Traffic Selector sub- 3663 options; each with the same or different omIndex values. 3665 - TS Format is a 1-octet field that encodes a Traffic Selector 3666 version per [RFC6088]. If TS Format encodes the value 1 or 2, 3667 the Traffic Selector includes IPv4 or IPv6 information, 3668 respectively. If TS Format encodes any other value, the sub- 3669 option is ignored. 3671 - The remainder of the sub-option includes a traffic selector 3672 formatted per [RFC6088] beginning with the "Flags (A-N)" field, 3673 and with the Traffic Selector IP protocol version coded in the 3674 TS Format field. If a single interface identified by omIndex 3675 requires Traffic Selectors for multiple IP protocol versions, 3676 or if a Traffic Selector block would exceed the available 3677 space, the remaining information is coded in additional Traffic 3678 Selector sub-options that all encode the same omIndex. 3680 12.2.7. Geo Coordinates 3682 0 1 2 3 3683 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 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3685 | S-Type=6| Sub-length=N | Geo Type |Geo Coordinates 3686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 3688 Figure 21: Geo Coordinates Sub-option 3690 * Sub-Type is set to 6. If multiple instances appear in OMNI 3691 options of the same message all are processed. 3693 * Sub-Length is set to N that encodes the number of Sub-Option Data 3694 octets that follow. 3696 * Geo Type is a 1 octet field that encodes a type designator that 3697 determines the format and contents of the Geo Coordinates field 3698 that follows. The following types are currently defined: 3700 - 0 - NULL, i.e., the Geo Coordinates field is zero-length. 3702 * A set of Geo Coordinates of length up to the remaining available 3703 space for this OMNI option. New formats to be specified in future 3704 documents and may include attributes such as latitude/longitude, 3705 altitude, heading, speed, etc. 3707 12.2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Message 3709 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) sub-option 3710 may be included in the OMNI options of Client RS messages and Proxy/ 3711 Server RA messages. FHS Proxy/Servers that forward RS/RA messages 3712 between a Client and an LHS Proxy/Server also forward DHCPv6 Sub- 3713 Options unchanged. Note that DHCPv6 messages do not include a 3714 Checksum field since integrity is protected by the IPv6 ND message 3715 checksum, authentication signature and/or lower-layer authentication 3716 and integrity checks. 3718 0 1 2 3 3719 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 3720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3721 | S-Type=7| Sub-length=N | msg-type | id (octet 0) | 3722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3723 | transaction-id (octets 1-2) | | 3724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3725 | | 3726 . DHCPv6 options . 3727 . (variable number and length) . 3728 | | 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3731 Figure 22: DHCPv6 Message Sub-option 3733 * Sub-Type is set to 7. If multiple instances appear in OMNI 3734 options of the same message the first is processed and all others 3735 are ignored. 3737 * Sub-Length is set to N that encodes the number of Sub-Option Data 3738 octets that follow. The 'msg-type' and 'transaction-id' fields 3739 are always present; hence, the length of the DHCPv6 options is 3740 limited by the remaining available space for this OMNI option. 3742 * 'msg-type' and 'transaction-id' are coded according to Section 8 3743 of [RFC8415]. 3745 * A set of DHCPv6 options coded according to Section 21 of [RFC8415] 3746 follows. 3748 12.2.9. Host Identity Protocol (HIP) Message 3750 The Host Identity Protocol (HIP) Message sub-option (when present) 3751 provides authentication for IPv6 ND messages exchanged between 3752 Clients and FHS Proxy/Servers over an open Internetwork. FHS Proxy/ 3753 Servers authenticate the HIP authentication signatures in source 3754 Client IPv6 ND messages before securely forwarding them to other OMNI 3755 nodes. LHS Proxy/Servers that receive secured IPv6 ND messages from 3756 other OMNI nodes that do not already include a security sub-option 3757 insert HIP authentication signatures before forwarding them to the 3758 target Client. 3760 OMNI interfaces MUST include the HIP message (when present) as the 3761 first sub-option of the first OMNI option, which MUST appear 3762 immediately following the IPv6 ND message header. OMNI interfaces 3763 can therefore easily locate the HIP message and verify the 3764 authentication signature without applying deep inspection. OMNI 3765 interfaces that receive IPv6 ND messages without a HIP (or other 3766 authentication) sub-option as the first OMNI sub-option instead 3767 verify the IPv6 ND message checksum. 3769 OMNI interfaces include the HIP message sub-option when they forward 3770 IPv6 ND messages that require security over INET underlay interfaces, 3771 i.e., where authentication and integrity is not already assured by 3772 lower layers. The OMNI interface calculates the authentication 3773 signature over the entire length of the OAL packet (or super-packet) 3774 beginning with a pseudo-header of the IPv6 ND message header and 3775 extending over the remainder of the OAL packet. OMNI interfaces that 3776 process OAL packets that contain secured IPv6 ND messages verify the 3777 signature then either process the rest of the message locally or 3778 forward a proxyed copy to the next hop. 3780 When a FHS Client inserts a HIP message sub-option in an NS/NA 3781 message destined to a target in a remote spanning tree segment, it 3782 must ensure that the insertion does not cause the message to exceed 3783 the OMNI interface MTU. When the remote segment LHS Proxy/Server 3784 forwards the NS/NA message from the spanning tree to the target 3785 Client, it inserts a new HIP message sub-option if necessary while 3786 overwriting or cancelling the (now defunct) HIP message sub-option 3787 supplied by the FHS Client. 3789 If the defunct HIP sub-option size was smaller than the space needed 3790 for the LHS Client HIP message (or, if no defunct HIP sub-option is 3791 present), the LHS Proxy/Server adjusts the space immediately 3792 following the OMNI header by copying the preceding portion of the 3793 IPv6 ND message into buffer headroom free space or copying the 3794 remainder of the IPv6 ND message into buffer tailroom free space. 3795 The LHS Proxy/Server then insets the new HIP sub-option immediately 3796 after the OMNI header and immediately before the next sub-option 3797 while properly overwriting the defunct sub-option if present. 3799 If the defunct HIP sub-option size was larger than the space needed 3800 for the LHS Client HIP message, the LHS Proxy/Server instead 3801 overwrites the existing sub-option and writes a single Pad1 or PadN 3802 sub-option over the next 1-2 octets to cancel the remainder of the 3803 defunct sub-option. If the LHS Proxy/Server cannot create sufficient 3804 space through any means without causing the OMNI option to exceed 3805 2040 octets or causing the IPv6 ND message to exceed the OMNI 3806 interface MTU, it returns a suitable error (see: Section 12.2.13) and 3807 drops the message. 3809 The HIP message sub-option is formatted as shown below: 3811 0 1 2 3 3812 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 3813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3814 | S-Type=8| Sub-length=N |0| Packet Type |Version| RES.|1| 3815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3816 | Reserved | Controls | 3817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3818 | Sender's Host Identity Tag (HIT) | 3819 | | 3820 | | 3821 | | 3822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3823 | Receiver's Host Identity Tag (HIT) | 3824 | | 3825 | | 3826 | | 3827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3828 | | 3829 / HIP Parameters / 3830 / / 3831 | | 3832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3834 Figure 23: HIP Message Sub-option 3836 * Sub-Type is set to 8. If multiple instances appear in OMNI 3837 options of the same message the first is processed and all others 3838 are ignored. 3840 * Sub-Length is set to N, i.e., the length of the option in octets 3841 beginning immediately following the Sub-Length field and extending 3842 to the end of the HIP parameters. The length of the entire HIP 3843 message is therefore limited by the remaining available space for 3844 this OMNI option. 3846 * The HIP message is coded per Section 5 of [RFC7401], except that 3847 the OMNI "Sub-Type" and "Sub-Length" fields replace the first 2 3848 octets of the HIP message header (i.e., the Next Header and Header 3849 Length fields). Also, since the IPv6 ND message is already 3850 protected by the authentication signature and/or lower-layer 3851 authentication and integrity checks, the HIP message Checksum 3852 field is replaced by a Reserved field set to 0 on transmission and 3853 ignored on reception. 3855 Note: In some environments, maintenance of a Host Identity Tag (HIT) 3856 namespace may be unnecessary for securely associating an OMNI node 3857 with an IPv6 address-based identity. In that case, IPv6 ULAs can be 3858 used instead of HITs in the authentication signature as long as the 3859 address can be uniquely associated with the Sender/Receiver. 3861 12.2.10. PIM-SM Message 3863 The Protocol Independent Multicast - Sparse Mode (PIM-SM) Message 3864 sub-option may be included in the OMNI options of IPv6 ND messages. 3865 PIM-SM messages are formatted as specified in Section 4.9 of 3866 [RFC7761], with the exception that the Checksum field is replaced by 3867 a Reserved field (set to 0) since the IPv6 ND message is already 3868 protected by the IPv6 ND message checksum, authentication signature 3869 and/or lower-layer authentication and integrity checks. The PIM-SM 3870 message sub-option format is shown in Figure 24: 3872 0 1 2 3 3873 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 3874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3875 | S-Type=9| Sub-length=N |PIM Ver| Type | Reserved | 3876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3877 | | 3878 / PIM-SM Message / 3879 / / 3880 | | 3881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3883 Figure 24: PIM-SM Message Option Format 3885 * Sub-Type is set to 9. If multiple instances appear in OMNI 3886 options of the same message all are processed. 3888 * Sub-Length is set to N, i.e., the length of the option in octets 3889 beginning immediately following the Sub-Length field and extending 3890 to the end of the PIM-SM message. The length of the entire PIM-SM 3891 message is therefore limited by the remaining available space for 3892 this OMNI option. 3894 * The PIM-SM message is coded exactly as specified in Section 4.9 of 3895 [RFC7761], except that the Checksum field is replaced by a 3896 Reserved field set to 0 on transmission and ignored on reception. 3897 The "PIM Ver" field MUST encode the value 2, and the "Type" field 3898 encodes the PIM message type. (See Section 4.9 of [RFC7761] for a 3899 list of PIM-SM message types and formats.) 3901 12.2.11. Fragmentation Report (FRAGREP) 3903 Fragmentation Report (FRAGREP) sub-options may be included in the 3904 OMNI options of uNA messages sent from an OAL destination to an OAL 3905 source. The message consists of (N / 20)-many (Identification, 3906 Bitmap)-tuples which include the Identification values of OAL 3907 fragments received plus a Bitmap marking the ordinal positions of 3908 individual fragments received and fragments missing. 3910 0 1 2 3 3911 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 3912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3913 |S-Type=10| Sub-Length = N | Identification #1 (bits 0-15) | 3914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 | Identification #1 (bits 15-31)| | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 3917 | Bitmap #1 (bits 0 - 127) | 3918 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3919 | | Identification #2 (bits 0-15) | 3920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3921 | Identification #2 (bits 15-31)| | 3922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3923 | Bitmap #2 (bits 0 - 127) | 3924 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3925 | | | 3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 3927 | ... | 3928 + ... + 3930 Figure 25: Fragmentation Report (FRAGREP) 3932 * Sub-Type is set to 10. If multiple instances appear in OMNI 3933 options of the same message all are processed. 3935 * Sub-Length is set to N, i.e., the length of the option in octets 3936 beginning immediately following the Sub-Length field and extending 3937 to the end of the sub-option. If N is not an integral multiple of 3938 20 octets, the sub-option is ignored. The length of the entire 3939 sub-option should not cause the entire IPv6 ND message to exceed 3940 the minimum IPv6 MTU. 3942 * Identification (i) includes the IPv6 Identification value found in 3943 the Fragment Header of a received OAL fragment. (Only those 3944 Identification values included represent fragments for which loss 3945 was unambiguously observed; any Identification values not included 3946 correspond to fragments that were either received in their 3947 entirety or may still be in transit.) 3949 * Bitmap (i) includes an ordinal checklist of up to 128 fragments, 3950 with each bit set to 1 for a fragment received or 0 for a fragment 3951 missing. For example, for a 20-fragment OAL packet with ordinal 3952 fragments #3, #10, #13 and #17 missing and all other fragments 3953 received, Bitmap (i) encodes the following: 3955 0 1 2 3956 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3958 |1|1|1|0|1|1|1|1|1|1|0|1|1|0|1|1|1|0|1|1|0|0|0|... 3959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3961 Figure 26 3963 (Note that loss of an OAL atomic fragment is indicated by a 3964 Bitmap(i) with all bits set to 0.) 3966 12.2.12. Node Identification 3968 0 1 2 3 3969 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 3970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3971 |S-Type=11| Sub-length=N | ID-Type | ~ 3972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 3973 ~ Node Identification Value (N-1 octets) ~ 3974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3976 Figure 27: Node Identification 3978 * Sub-Type is set to 11. If multiple instances appear in OMNI 3979 options of the same IPv6 ND message the first instance of a 3980 specific ID-Type is processed and all other instances of the same 3981 ID-Type are ignored. (It is therefore possible for a single IPv6 3982 ND message to convey multiple distinct Node Identifications - each 3983 with a different ID-Type.) 3985 * Sub-Length is set to N that encodes the number of Sub-Option Data 3986 octets that follow. The ID-Type field is always present; hence, 3987 the maximum Node Identification Value length is limited by the 3988 remaining available space in this OMNI option. 3990 * ID-Type is a 1 octet field that encodes the type of the Node 3991 Identification Value. The following ID-Type values are currently 3992 defined: 3994 - 0 - Universally Unique IDentifier (UUID) [RFC4122]. Indicates 3995 that Node Identification Value contains a 16 octet UUID. 3997 - 1 - Host Identity Tag (HIT) [RFC7401]. Indicates that Node 3998 Identification Value contains a 16 octet HIT. 4000 - 2 - Hierarchical HIT (HHIT) [I-D.ietf-drip-rid]. Indicates 4001 that Node Identification Value contains a 16 octet HHIT. 4003 - 3 - Network Access Identifier (NAI) [RFC7542]. Indicates that 4004 Node Identification Value contains an N-1 octet NAI. 4006 - 4 - Fully-Qualified Domain Name (FQDN) [RFC1035]. Indicates 4007 that Node Identification Value contains an N-1 octet FQDN. 4009 - 5 - IPv6 Address. Indicates that Node Identification contains 4010 a 16-octet IPv6 address that is not a (H)HIT. The IPv6 address 4011 type is determined according to the IPv6 addressing 4012 architecture [RFC4291]. 4014 - 6 - 252 - Unassigned. 4016 - 253-254 - Reserved for experimentation, as recommended in 4017 [RFC3692]. 4019 - 255 - reserved by IANA. 4021 * Node Identification Value is an (N - 1) octet field encoded 4022 according to the appropriate the "ID-Type" reference above. 4024 OMNI interfaces code Node Identification Values used for DHCPv6 4025 messaging purposes as a DHCP Unique IDentifier (DUID) using the 4026 "DUID-EN for OMNI" format with enterprise number 45282 (see: 4027 Section 25) as shown in Figure 28: 4029 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 4030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4031 | DUID-Type (2) | EN (high bits == 0) | 4032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4033 | EN (low bits = 45282) | ID-Type | | 4034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4035 ~ Node Identification Value ~ 4036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4038 Figure 28: DUID-EN for OMNI Format 4040 In this format, the OMNI interface codes the ID-Type and Node 4041 Identification Value fields from the OMNI sub-option following a 6 4042 octet DUID-EN header, then includes the entire "DUID-EN for OMNI" in 4043 a DHCPv6 message per [RFC8415]. 4045 12.2.13. ICMPv6 Error 4047 0 1 2 3 4048 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 4049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4050 |S-Type=12| Sub-length=N | Type | Code | 4051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4052 | | 4053 + Message Body + 4054 | | 4055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4057 Figure 29: ICMPv6 Error 4059 * Sub-Type is set to 12. If multiple instances appear in OMNI 4060 options of the same IPv6 ND message all are processed. 4062 * Sub-Length is set to N that encodes the number of Sub-Option Data 4063 octets that follow. 4065 * Sub-Option Data includes a one octet Type followed by a one octet 4066 Code followed by an (N-2)-octet Message Body encoded exactly as 4067 per Section 2.1 of [RFC4443]. OMNI interfaces include as much of 4068 the ICMPv6 error message body in the sub-option as possible 4069 without causing the entire IPv6 ND message to exceed the minimum 4070 IPv6 MTU. While all ICMPv6 error message types are supported, OAL 4071 destinations in particular may include ICMPv6 PTB messages in uNA 4072 messages to provide MTU feedback information via the OAL source 4073 (see: Section 6.8). Note: ICMPv6 informational messages must not 4074 be included and must be ignored if received. 4076 12.2.14. QUIC-TLS Message 4078 0 1 2 3 4079 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 4080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 |S-Type=13| Sub-length=N | ~ 4082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ 4083 ~ QUIC-TLS Message ~ 4084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4086 Figure 30: QUIC-TLS Message 4088 * Sub-Type is set to 13. If multiple instances appear in OMNI 4089 options of the same IPv6 ND message, the first is processed and 4090 all others are ignored. 4092 * Sub-Length is set to N that encodes the number of Sub-Option Data 4093 octets that follow. 4095 * The QUIC-TLS message [RFC9000][RFC9001][RFC9002] encodes the QUIC 4096 and TLS message parameters necessary to support QUIC connection 4097 establishment. 4099 When present, the QUIC-TLS Message sub-option MUST appear immediately 4100 after the header of the first OMNI option in the IPv6 ND message; if 4101 the sub-option appears in any other location it MUST be ignored. 4102 IPv6 ND solicitation and advertisement messages serve as couriers to 4103 transport the QUIC and TLS parameters necessary to establish a 4104 secured QUIC connection. 4106 12.2.15. Proxy/Server Departure 4108 OMNI Clients include a Proxy/Server Departure sub-option in RS 4109 messages when they associate with a new FHS and/or Hub Proxy/Server 4110 and need to send a departure indication to an old FHS and/or Hub 4111 Proxy/Server. The Proxy/Server Departure sub-option is formatted as 4112 shown below: 4114 0 1 2 3 4115 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 4116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4117 |S-Type=14| Sub-length=32 | ~ 4118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 4119 ~ Old FHS Proxy/Server ULA (16 octets) ~ 4120 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4121 ~ | ~ 4122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 4123 ~ Old Hub Proxy/Server ULA (16 0ctets) ~ 4124 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4125 ~ | 4126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4128 Figure 31: Proxy/Server Departure 4130 * Sub-Type is set to 14. 4132 * Sub-Length is set to 32. 4134 * Sub-Option Data contains the 16 octet ULA for the "Old FHS Proxy/ 4135 Server" followed by a 16 octet ULA for an "Old Hub Proxy/Server. 4136 (If the Old FHS/Hub is unspecified, the corresponding ULA instead 4137 includes the value 0.) 4139 12.2.16. Sub-Type Extension 4141 Since the Sub-Type field is only 5 bits in length, future 4142 specifications of major protocol functions may exhaust the remaining 4143 Sub-Type values available for assignment. This document therefore 4144 defines Sub-Type 30 as an "extension", meaning that the actual Sub- 4145 Option type is determined by examining a 1 octet "Extension-Type" 4146 field immediately following the Sub-Length field. The Sub-Type 4147 Extension is formatted as shown in Figure 32: 4149 0 1 2 3 4150 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 4151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4152 |S-Type=30| Sub-length=N | Extension-Type| ~ 4153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 4154 ~ ~ 4155 ~ Extension-Type Body ~ 4156 ~ ~ 4157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4159 Figure 32: Sub-Type Extension 4161 * Sub-Type is set to 30. If multiple instances appear in OMNI 4162 options of the same message all are processed, where each 4163 individual extension defines its own policy for processing 4164 multiple of that type. 4166 * Sub-Length is set to N that encodes the number of Sub-Option Data 4167 octets that follow. The Extension-Type field is always present, 4168 and the maximum Extension-Type Body length is limited by the 4169 remaining available space in this OMNI option. 4171 * Extension-Type contains a 1 octet Sub-Type Extension value between 4172 0 and 255. 4174 * Extension-Type Body contains an N-1 octet block with format 4175 defined by the given extension specification. 4177 Extension-Type values 0 and 1 are defined in the following 4178 subsections, while Extension-Type values 2 through 252 are available 4179 for assignment by future specifications which must also define the 4180 format of the Extension-Type Body and its processing rules. 4181 Extension-Type values 253 and 254 are reserved for experimentation, 4182 as recommended in [RFC3692], and value 255 is reserved by IANA. 4184 12.2.16.1. RFC4380 Header Extension Option 4186 0 1 2 3 4187 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 4188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4189 |S-Type=30| Sub-length=N | Ext-Type=0 | Header Type | 4190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4191 ~ Header Option Value ~ 4192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4194 Figure 33: RFC4380 Header Extension Option (Extension-Type 0) 4196 * Sub-Type is set to 30. 4198 * Sub-Length is set to N that encodes the number of Sub-Option Data 4199 octets that follow. The Extension-Type and Header Type fields are 4200 always present, and the Header Option Value is limited by the 4201 remaining available space in this OMNI option. 4203 * Extension-Type is set to 0. Each instance encodes exactly one 4204 header option per Section 5.1.1 of [RFC4380], with Ext-Type and 4205 Header Type representing the first two octets of the option. If 4206 multiple instances of the same Header Type appear in OMNI options 4207 of the same message the first instance is processed and all others 4208 are ignored. If Header Type indicates an Authentication 4209 Encapsulation (see below), the entire sub-option MUST appear as 4210 the first sub-option of the first OMNI option, which MUST appear 4211 immediately following the IPv6 ND message header. 4213 * Header Type and Header Option Value are coded exactly as specified 4214 in Section 5.1.1 of [RFC4380]; the following types are currently 4215 defined: 4217 - 0 - Origin Indication (IPv4) - value coded as a UDP port number 4218 followed by a 4-octet IPv4 address both in "obfuscated" form 4219 per Section 5.1.1 of [RFC4380]. 4221 - 1 - Authentication Encapsulation - value coded per 4222 Section 5.1.1 of [RFC4380]. 4224 - 2 - Origin Indication (IPv6) - value coded per Section 5.1.1 of 4225 [RFC4380], except that the address is a 16-octet IPv6 address 4226 instead of a 4-octet IPv4 address. 4228 * Header Type values 3 through 252 are available for assignment by 4229 future specifications, which must also define the format of the 4230 Header Option Value and its processing rules. Header Type values 4231 253 and 254 are reserved for experimentation, as recommended in 4232 [RFC3692], and value 255 is Reserved by IANA. 4234 12.2.16.2. RFC6081 Trailer Extension Option 4236 0 1 2 3 4237 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 4238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4239 |S-Type=30| Sub-length=N | Ext-Type=1 | Trailer Type | 4240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4241 ~ Trailer Option Value ~ 4242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4244 Figure 34: RFC6081 Trailer Extension Option (Extension-Type 1) 4246 * Sub-Type is set to 30. 4248 * Sub-Length is set to N that encodes the number of Sub-Option Data 4249 octets that follow. The Extension-Type and Trailer Type fields 4250 are always present, and the maximum-length Trailer Option Value is 4251 limited by the remaining available space in this OMNI option. 4253 * Extension-Type is set to 1. Each instance encodes exactly one 4254 trailer option per Section 4 of [RFC6081]. If multiple instances 4255 of the same Trailer Type appear in OMNI options of the same 4256 message the first instance is processed and all others ignored. 4258 * Trailer Type and Trailer Option Value are coded exactly as 4259 specified in Section 4 of [RFC6081]; the following Trailer Types 4260 are currently defined: 4262 - 0 - Unassigned 4264 - 1 - Nonce Trailer - value coded per Section 4.2 of [RFC6081]. 4266 - 2 - Unassigned 4268 - 3 - Alternate Address Trailer (IPv4) - value coded per 4269 Section 4.3 of [RFC6081]. 4271 - 4 - Neighbor Discovery Option Trailer - value coded per 4272 Section 4.4 of [RFC6081]. 4274 - 5 - Random Port Trailer - value coded per Section 4.5 of 4275 [RFC6081]. 4277 - 6 - Alternate Address Trailer (IPv6) - value coded per 4278 Section 4.3 of [RFC6081], except that each address is a 4279 16-octet IPv6 address instead of a 4-octet IPv4 address. 4281 * Trailer Type values 7 through 252 are available for assignment by 4282 future specifications, which must also define the format of the 4283 Trailer Option Value and its processing rules. Trailer Type 4284 values 253 and 254 are reserved for experimentation, as 4285 recommended in [RFC3692], and value 255 is Reserved by IANA. 4287 13. Address Mapping - Multicast 4289 The multicast address mapping of the native underlay interface 4290 applies. The Client mobile router also serves as an IGMP/MLD Proxy 4291 for its ENETs and/or hosted applications per [RFC4605]. 4293 The Client uses Multicast Listener Discovery (MLDv2) [RFC3810] to 4294 coordinate with Proxy/Servers, and underlay network elements use MLD 4295 snooping [RFC4541]. The Client can also employ multicast routing 4296 protocols to coordinate with network-based multicast sources as 4297 specified in [I-D.templin-6man-aero]. 4299 Since the OMNI link model is NBMA, OMNI links support link-scoped 4300 multicast through iterative unicast transmissions to individual 4301 multicast group members (i.e., unicast/multicast emulation). 4303 14. Multilink Conceptual Sending Algorithm 4305 The Client's IPv6 layer selects the outbound OMNI interface according 4306 to SBM considerations when forwarding original IP packets from local 4307 or ENET applications to external correspondents. Each OMNI interface 4308 maintains a neighbor cache the same as for any IPv6 interface, but 4309 includes additional state for multilink coordination. Each Client 4310 OMNI interface maintains default routes via Proxy/Servers discovered 4311 as discussed in Section 15, and may configure more-specific routes 4312 discovered through means outside the scope of this specification. 4314 For each original IP packet it forwards, the OMNI interface selects 4315 one or more source underlay interfaces based on PBM factors (e.g., 4316 traffic attributes, cost, performance, message size, etc.) and one or 4317 more target underlay interfaces for the neighbor based on Interface 4318 Attributes received in IPv6 ND messages (see: Section 12.2.4). 4319 Multilink forwarding may also direct packet replication across 4320 multiple underlay interface pairs for increased reliability at the 4321 expense of duplication. The set of all Interface Attributes and 4322 Traffic Selectors received in IPv6 ND messages determines the 4323 multilink forwarding profile for selecting target underlay 4324 interfaces. 4326 When the OMNI interface sends an original IP packet over a selected 4327 source underlay interface, it first employs OAL encapsulation and 4328 fragmentation as discussed in Section 5, then performs L2 4329 encapsulation as directed by the appropriate MFV. The OMNI interface 4330 also performs L2 encapsulation (following OAL encapsulation) when the 4331 nearest Proxy/Server is located multiple hops away as discussed in 4332 Section 15.2. 4334 OMNI interface multilink service designers MUST observe the BCP 4335 guidance in Section 15 [RFC3819] in terms of implications for 4336 reordering when original IP packets from the same flow may be spread 4337 across multiple underlay interfaces having diverse properties. 4339 14.1. Multiple OMNI Interfaces 4341 Clients may connect to multiple independent OMNI links within the 4342 same or different OMNI domains to support SBM. The Client configures 4343 a separate OMNI interface for each link so that multiple interfaces 4344 (e.g., omni0, omni1, omni2, etc.) are exposed to the IP layer. Each 4345 OMNI interface configures one or more OMNI anycast addresses (see: 4346 Section 10), and the Client injects the corresponding anycast 4347 prefixes into the ENET routing system. Multiple distinct OMNI links 4348 can therefore be used to support fault tolerance, load balancing, 4349 reliability, etc. 4351 Applications in ENETs can use Segment Routing to select the desired 4352 OMNI interface based on SBM considerations. The application writes 4353 an OMNI anycast address into the original IP packet's destination 4354 address, and writes the actual destination (along with any additional 4355 intermediate hops) into the Segment Routing Header. Standard IP 4356 routing directs the packet to the Client's mobile router entity, 4357 where the anycast address identifies the correct OMNI interface for 4358 next hop forwarding. When the Client receives the packet, it 4359 replaces the IP destination address with the next hop found in the 4360 Segment Routing Header and forwards the message via the OMNI 4361 interface identified by the anycast address. 4363 Note: The Client need not configure its OMNI interface indexes in 4364 one-to-one correspondence with the global OMNI Link-IDs configured 4365 for OMNI domain administration since the Client's indexes (i.e., 4366 omni0, omni1, omni2, etc.) are used only for its own local interface 4367 management. 4369 14.2. Client-Proxy/Server Loop Prevention 4371 After a Proxy/Server has registered an MNP for a Client (see: 4372 Section 15), the Proxy/Server will forward all packets destined to an 4373 address within the MNP to the Client. The Client will under normal 4374 circumstances then forward the packet to the correct destination 4375 within its connected (downstream) ENETs. 4377 If at some later time the Client loses state (e.g., after a reboot), 4378 it may begin returning packets with destinations corresponding to its 4379 MNP to the Proxy/Server as its default router. The Proxy/Server 4380 therefore drops any original IP packets received from the Client with 4381 a destination address that corresponds to the Client's MNP (i.e., 4382 whether ULA or GUA), and drops any carrier packets with both source 4383 and destination address corresponding to the same Client's MNP 4384 regardless of their origin. 4386 15. Router Discovery and Prefix Registration 4388 Clients engage the MS by sending RS messages with OMNI options under 4389 the assumption that one or more Proxy/Server will process the message 4390 and respond. The RS message is received by a FHS Proxy/Server, which 4391 may in turn forward a proxyed copy of the RS to a Hub Proxy/Server 4392 located on the same or different SRT segment. The Hub Proxy/Server 4393 then returns an RA message either directly to the Client or via an 4394 FHS Proxy/Server acting as a proxy. 4396 Clients and FHS Proxy/Servers include an authentication signature in 4397 their RS/RA exchanges when necessary; otherwise, they calculate and 4398 include a valid IPv6 ND message checksum (see: Section 12 and 4399 Appendix B). FHS and Hub Proxy/Server RS/RA message exchanges over 4400 the SRT secured spanning tree instead always include the checksum and 4401 omit the authentication signature. Clients and Proxy/Servers use the 4402 information included in RS/RA messages to establish NCE state and 4403 OMNI link autoconfiguration information as discussed in this section. 4405 For each underlay interface, the Client sends RS messages with OMNI 4406 options to coordinate with a (potentially) different FHS Proxy/Server 4407 for each interface but with a single Hub Proxy/Server. All Proxy/ 4408 Servers are identified by their ULA-RNDs and accept carrier packets 4409 addressed to their anycast/unicast L2 INADDRs; the Hub Proxy/Server 4410 may be chosen among any of the Client's FHS Proxy/Servers or may be 4411 any other Proxy/Server for the OMNI link. Example ULA/INADDR 4412 discovery methods are given in [RFC5214] and include data link login 4413 parameters, name service lookups, static configuration, a static 4414 "hosts" file, etc. In the absence of other information, the Client 4415 can resolve the DNS Fully-Qualified Domain Name (FQDN) 4416 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 4417 text string and "[domainname]" is a DNS suffix for the OMNI link 4418 (e.g., "example.com"). The name resolution will retain a set of DNS 4419 resource records with the addresses of Proxy/Servers for the domain. 4421 Each FHS Proxy/Server configures an ULA-RND based on a /64 ULA prefix 4422 for the link/segment with randomly-generated Global ID to assure 4423 global uniqueness then administratively assigned to FHS Proxy/Servers 4424 for the link to assure global consistency. The Client can then 4425 configure ULA-MNPs derived from the 64-bit ULA prefix assigned to a 4426 FHS Proxy/Server for each underlay interface. The FHS Proxy/Servers 4427 discovered over multiple of the Client's underlay interfaces may 4428 configure the same or different ULA prefixes, and the Client's ULA- 4429 MNP for each underlay interface will fall within the ULA (multilink) 4430 subnet relative to each FHS Proxy/Server. 4432 Clients configure OMNI interfaces that observe the properties 4433 discussed in previous sections. The OMNI interface and its underlay 4434 interfaces are said to be in either the "UP" or "DOWN" state 4435 according to administrative actions in conjunction with the interface 4436 connectivity status. An OMNI interface transitions to UP or DOWN 4437 through administrative action and/or through state transitions of the 4438 underlay interfaces. When a first underlay interface transitions to 4439 UP, the OMNI interface also transitions to UP. When all underlay 4440 interfaces transition to DOWN, the OMNI interface also transitions to 4441 DOWN. 4443 When a Client OMNI interface transitions to UP, it sends RS messages 4444 to register its MNP and an initial set of underlay interfaces that 4445 are also UP. The Client sends additional RS messages to refresh 4446 lifetimes and to register/deregister underlay interfaces as they 4447 transition to UP or DOWN. The Client's OMNI interface sends initial 4448 RS messages over an UP underlay interface with its {TLA,XLA}-MNP as 4449 the source (or with a {TLA,XLA}-RND as the source if it does not yet 4450 have an MNP) and with destination set to link-scoped All-Routers 4451 multicast or the ULA of a specific (Hub) Proxy/Server. The OMNI 4452 interface includes an OMNI option per Section 12 with an OMNI 4453 Neighbor Coordination sub-option with (Preflen assertion, N/A/U flags 4454 and Window Synchronization parameters), an Interface Attributes sub- 4455 option for the underlay interface, a DHCPv6 Solicit sub-option if 4456 necessary, and with any other necessary OMNI sub-options such as 4457 authentication, Proxy/Server Departure, etc. 4459 The Client then calculates the authentication signature or checksum 4460 and prepares to forward the RS over the underlay interface using OAL 4461 encapsulation and fragmentation if necessary. If the Client uses OAL 4462 encapsulation for RS messages sent to an unsynchronized FHS Proxy/ 4463 Server over an INET interface, the entire RS message must fit within 4464 a single carrier packet (i.e., an atomic fragment) so that the FHS 4465 Proxy/Server can verify the authentication signature without having 4466 to reassemble. The OMNI interface selects an Identification value 4467 (see: Section 6.6), sets the OAL source address to the ULA-MNP 4468 corresponding to the RS source if known (otherwise to a {TLA,XLA}- 4469 RND), sets the OAL destination to an OMNI IPv6 anycast address or a 4470 known Proxy/Server ULA, optionally includes a Nonce and/or Timestamp, 4471 then performs fragmentation if necessary. When L2 encapsulation is 4472 used, the Client includes the discovered FHS Proxy/Server INADDR or 4473 an anycast address as the L2 destination then forwards the resulting 4474 carrier packet(s) into the underlay network. Note that the Client 4475 does not yet create a NCE, but instead remembers the Identification, 4476 Nonce and/or Timestamp values included in its RS message 4477 transmissions to match against any received RA messages. 4479 When an FHS Proxy/Server receives the carrier packets containing an 4480 RS it sets aside the L2 headers, verifies the Identifications and 4481 reassembles if necessary, sets aside the OAL header, then verifies 4482 the RS authentication signature or checksum. The FHS Proxy/Server 4483 then creates/updates a NCE indexed by the Client's RS source address 4484 and caches the OMNI Interface Attributes and any Traffic Selector 4485 sub-options while also caching the L2 (UDP/IP) and OAL source and 4486 destination address information. The FHS Proxy/Server next caches 4487 the OMNI Neighbor Coordination sub-option Window Synchronization 4488 parameters and N flag to determine its role in processing NS(NUD) 4489 messages (see: Section 12.1) then examines the RS destination 4490 address. If the destination matches its own ULA, the FHS Proxy/ 4491 Server assumes the Hub role and acts as the sole entry point for 4492 injecting the Client's XLA-MNP into the OMNI link routing system 4493 (i.e., after performing any necessary prefix delegation operations) 4494 while including a prefix length and setting the prefix to fd00::/64 4495 and suffix to the 64-bit MNP. The FHS/Hub Proxy/Server then caches 4496 the OMNI Neighbor Coordination sub-option A/U flags to determine its 4497 role in processing NS(AR) messages and generating uNA messages (see: 4498 Section 12.1). 4500 The FHS/Hub Proxy/Server then prepares to return an RA message 4501 directly to the Client by first populating the Cur Hop Limit, Flags, 4502 Router Lifetime, Reachable Time and Retrans Timer fields with values 4503 appropriate for the OMNI link. The FHS/Hub Proxy/Server next 4504 includes as the first RA message option an OMNI option with a 4505 neighbor coordination sub-option with Window Synchronization 4506 information, an authentication sub-option if necessary and a 4507 (proxyed) copy of the Client's original Interface Attributes sub- 4508 option with its INET-facing interface information written in the FMT/ 4509 SRT and LHS Proxy/Server ULA/INADDR fields. If the RS L2 destination 4510 IP address was anycast, the FHS/Hub Proxy/Server next includes a 4511 second Interface Attributes sub-option with omIndex set to '0' and 4512 with a unicast L2 IP address for its Client-facing interface in the 4513 INADDR field. 4515 The FHS/Hub Proxy/Server next includes an Origin Indication sub- 4516 option that includes the RS L2 source INADDR information (see: 4517 Section 12.2.16.1), then includes any other necessary OMNI sub- 4518 options (either within the same OMNI option or in additional OMNI 4519 options). Following the OMNI option(s), the FHS/Hub Proxy/Server 4520 next includes any other necessary RA options such as PIOs with (A; 4521 L=0) that include the OMNI link MSPs [RFC8028], RIOs [RFC4191] with 4522 more-specific routes, Nonce and Timestamp options, etc. The FHS/Hub 4523 Proxy/Server then sets the RA source address to its own ULA and 4524 destination address to the Client's ULA-MNP (i.e., relative to the 4525 ULA /64 prefix for its Client-facing underlay interface) while also 4526 recording the corresponding XLA-MNP as an (alternate) index to the 4527 Client NCE, then calculates the authentication signature or checksum. 4528 The FHS/Hub Proxy/Server finally performs OAL encapsulation with 4529 source set to its own ULA and destination set to the OAL source that 4530 appeared in the RS, then fragments if necessary, encapsulates each 4531 fragment in appropriate L2 headers with source and destination 4532 address information reversed from the RS L2 information and returns 4533 the resulting carrier packets to the Client over the same underlay 4534 interface the RS arrived on. 4536 When an FHS Proxy/Server receives an RS with a valid authentication 4537 signature or checksum and with destination set to link-scoped All- 4538 Routers multicast, it can either assume the Hub role itself the same 4539 as above or act as a proxy and select the ULA of another Proxy/Server 4540 to serve as the Hub. When an FHS Proxy/Server assumes the proxy role 4541 or receives an RS with destination set to the ULA of another Proxy/ 4542 Server, it forwards the message while acting as a proxy. The FHS 4543 Proxy/Server creates/updates a NCE for the Client (i.e., based on the 4544 RS source address) and caches the OAL source, Window Synchronization, 4545 N flag, Interface Attributes addressing information as above then 4546 writes its own INET-facing FMT/SRT and LHS Proxy/Server ULA/INADDR 4547 information into the appropriate Interface Attributes sub-option 4548 fields. The FHS Proxy/Server then calculates and includes the 4549 checksum, performs OAL encapsulation with source set to its own ULA 4550 and destination set to the ULA of the Hub Proxy/Server, fragments if 4551 necessary, encapsulates each fragment in appropriate L2 headers and 4552 sends the resulting carrier packets into the SRT secured spanning 4553 tree. 4555 When the Hub Proxy/Server receives the carrier packets, it discards 4556 the L2 headers, reassembles if necessary to obtain the proxyed RS, 4557 then performs DHCPv6 Prefix Delegation (PD) to obtain the Client's 4558 MNP if the RS source is a (TLA,XLA}-RND. The Hub Proxy/Server then 4559 creates/updates a NCE for the Client's XLA-MNP and caches any state 4560 (including the A/U flags, OAL addresses, Interface Attributes 4561 information and Traffic Selectors), then finally performs routing 4562 protocol injection. The Hub Proxy/Server then returns an RA that 4563 echoes the Client's (proxyed) Interface Attributes sub-option and 4564 with any RA parameters the same as specified for the FHS/Hub Proxy/ 4565 Server case above. The Hub Proxy/Server then sets the RA source 4566 address to its own ULA and destination address to the RS source 4567 address; if the RS source address is a {TLA,XLA}-RND, the Hub Proxy/ 4568 Server also includes the MNP in a DHCPv6 PD Reply OMNI sub-option. 4569 The Hub Proxy/Server next calculates the checksum, then encapsulates 4570 the RA as an OAL packet with source set to its own ULA and 4571 destination set to the ULA of the FHS Proxy/Server that forwarded the 4572 RS. The Hub Proxy/Server finally fragments if necessary, 4573 encapsulates each fragment in appropriate L2 headers and sends the 4574 resulting carrier packets into the secured spanning tree. 4576 When the FHS Proxy/Server receives the carrier packets it discards 4577 the L2 headers, reassembles if necessary to obtain the RA message, 4578 verifies the checksum then updates the OMNI interface NCE for the 4579 Client and creates/updates a NCE for the Hub. The FHS Proxy/Server 4580 then sets the P flag in the RA flags field [RFC4389] and proxys the 4581 RA by changing the OAL source to its own ULA, changing the OAL 4582 destination to the OAL address found in the Client's NCE, and 4583 changing the RA destination address to the ULA-MNP of the Client 4584 relative to its own /64 ULA prefix while also recording the 4585 corresponding XLA-MNP as an alternate index into the Client NCE. (If 4586 the RA destination address was a {TLA,XLA}-RND, the FHS Proxy Server 4587 determines the MNP by consulting the DHCPv6 PD Reply message sub- 4588 option.) The FHS Proxy/Server next includes Window Synchronization 4589 parameters responsive to those in the Client's RS, an Interface 4590 Attributes sub-option with omIndex '0' and with its unicast L2 IP 4591 address if necessary (see above), an Origin Indication sub-option 4592 with the Client's cached INADDR and an authentication sub-option if 4593 necessary. The FHS Proxy/Server finally selects an Identification 4594 value per Section 6.6, calculates the authentication signature or 4595 checksum, fragments if necessary, encapsulates each fragment in L2 4596 headers with addresses taken from the Client's NCE and returns the 4597 resulting carrier packets via the same underlay interface over which 4598 the RS was received. 4600 When the Client receives the carrier packets, it discards the L2 4601 headers, reassembles if necessary and removes the OAL header to 4602 obtain the RA message. The Client next verifies the authentication 4603 signature or checksum, then matches the RA message with its 4604 previously-sent RS by comparing the RS Sequence Number with the RA 4605 Acknowledgement Number and also comparing the Nonce and/or Timestamp 4606 values if present. If the values match, the Client then creates/ 4607 updates OMNI interface NCEs for both the Hub and FHS Proxy/Server and 4608 caches the information in the RA message. In particular, the Client 4609 caches the RA source address as the Hub Proxy/Server ULA and uses the 4610 OAL source address to configure both an underlay interface-specific 4611 ULA for the Hub Proxy/Server and the ULA of this FHS Proxy/Server. 4612 The Client then uses the ULA-MNP in the RA destination address to 4613 configure its address within the ULA (multilink) subnet prefix of the 4614 FHS Proxy/Server. If the Client has multiple underlay interfaces, it 4615 creates additional FHS Proxy/Server NCEs and ULA-MNPs as necessary 4616 when it receives RAs over those interfaces (noting that multiple of 4617 the Client's underlay interfaces may be serviced by the same or 4618 different FHS Proxy/Servers). The Client finally adds the Hub Proxy/ 4619 Server ULA to the default router list if necessary. 4621 For each underlay interface, the Client next caches the (filled-out) 4622 Interface Attributes for its own omIndex and Origin Indication 4623 information that it received in an RA message over that interface so 4624 that it can include them in future NS/NA messages to provide 4625 neighbors with accurate FMT/SRT/LHS information. (If the message 4626 includes an Interface Attributes sub-option with omIndex '0', the 4627 Client also caches the INADDR as the underlay network-local unicast 4628 address of the FHS Proxy//Server via that underlay interface.) The 4629 Client then compares the Origin Indication INADDR information with 4630 its own underlay interface addresses to determine whether there may 4631 be NATs on the path to the FHS Proxy/Server; if the INADDR 4632 information differs, the Client is behind a NAT and must supply the 4633 Origin information in IPv6 ND message exchanges with prospective 4634 neighbors on the same SRT segment. The Client finally configures 4635 default routes and assigns the OMNI Subnet Router Anycast address 4636 corresponding to the MNP (e.g., 2001:db8:1:2::) to the OMNI 4637 interface. 4639 Following the initial exchange, the FHS Proxy/Server MAY later send 4640 additional periodic and/or event-driven unsolicited RA messages per 4641 [RFC4861]. (The unsolicited RAs may be initiated either by the FHS 4642 Proxy/Server itself or by the Hub via the FHS as a proxy.) The 4643 Client then continuously manages its underlay interfaces according to 4644 their states as follows: 4646 * When an underlay interface transitions to UP, the Client sends an 4647 RS over the underlay interface with an OMNI option with sub- 4648 options as specified above. 4650 * When an underlay interface transitions to DOWN, the Client sends 4651 unsolicited NA messages over any UP underlay interface with an 4652 OMNI option containing Interface Attributes sub-options for the 4653 DOWN underlay interface with Link set to '0'. The Client sends 4654 isolated unsolicited NAs when reliability is not thought to be a 4655 concern (e.g., if redundant transmissions are sent on multiple 4656 underlay interfaces), or may instead set the PNG flag in the OMNI 4657 header to trigger a uNA reply. 4659 * When the Router Lifetime for the Hub Proxy/Server nears 4660 expiration, the Client sends an RS over any underlay interface to 4661 receive a fresh RA from the Hub. If no RA messages are received 4662 over a first underlay interface (i.e., after retrying), the Client 4663 marks the underlay interface as DOWN and should attempt to contact 4664 the Hub Proxy/Server via a different underlay interface. If the 4665 Hub Proxy/Server is unresponsive over additional underlay 4666 interfaces, the Client sends an RS message with destination set to 4667 the ULA of another Proxy/Server which will then assume the Hub 4668 role. 4670 * When all of a Client's underlay interfaces have transitioned to 4671 DOWN (or if the prefix registration lifetime expires), the Hub 4672 Proxy/Server withdraws the MNP the same as if it had received a 4673 message with a release indication. 4675 The Client is responsible for retrying each RS exchange up to 4676 MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL 4677 seconds until an RA is received. If no RA is received over an UP 4678 underlay interface (i.e., even after attempting to contact alternate 4679 Proxy/Servers), the Client declares this underlay interface as DOWN. 4680 When changing to a new FHS or Hub Proxy/Server, the Client also 4681 includes a Proxy/Server Departure OMNI sub-option in new RS messages; 4682 the (new) FHS Proxy/Server will in turn send uNA messages to the old 4683 FHS and/or Hub Proxy/Server to announce the Client's departure as 4684 discussed in [I-D.templin-6man-aero]. 4686 The IPv6 layer sees the OMNI interface as an ordinary IPv6 interface. 4687 Therefore, when the IPv6 layer sends an RS message the OMNI interface 4688 returns an internally-generated RA message as though the message 4689 originated from an IPv6 router. The internally-generated RA message 4690 contains configuration information consistent with the information 4691 received from the RAs generated by the Hub Proxy/Server. Whether the 4692 OMNI interface IPv6 ND messaging process is initiated from the 4693 receipt of an RS message from the IPv6 layer or independently of the 4694 IPv6 layer is an implementation matter. Some implementations may 4695 elect to defer the OMNI interface internal RS/RA messaging process 4696 until an RS is received from the IPv6 layer, while others may elect 4697 to initiate the process proactively. Still other deployments may 4698 elect to administratively disable IPv6 layer RS/RA messaging over the 4699 OMNI interface, since the messages are not required to drive the OMNI 4700 interface internal RS/RA process. (Note that this same logic applies 4701 to IPv4 implementations that employ "ICMP Router Discovery" 4702 [RFC1256].) 4704 Note: The Router Lifetime value in RA messages indicates the time 4705 before which the Client must send another RS message over this 4706 underlay interface (e.g., 600 seconds), however that timescale may be 4707 significantly longer than the lifetime the MS has committed to retain 4708 the prefix registration (e.g., REACHABLETIME seconds). Proxy/Servers 4709 are therefore responsible for keeping MS state alive on a shorter 4710 timescale than the Client may be required to do on its own behalf. 4712 Note: On certain multicast-capable underlay interfaces, Clients 4713 should send periodic unsolicited multicast NA messages and Proxy/ 4714 Servers should send periodic unsolicited multicast RA messages as 4715 "beacons" that can be heard by other nodes on the link. If a node 4716 fails to receive a beacon after a timeout value specific to the link, 4717 it can initiate Neighbor Unreachability Detection (NUD) exchanges to 4718 test reachability. 4720 Note: If a single FHS Proxy/Server services multiple of a Client's 4721 underlay interfaces, Window Synchronization will initially be 4722 repeated for the RS/RA exchange over each underlay interface, i.e., 4723 until the Client discovers the many-to-one relationship. This will 4724 naturally result in a single window synchronization that applies over 4725 the Client's multiple underlay interfaces for the same FHS Proxy/ 4726 Server. 4728 Note: Although the Client's FHS Proxy/Server is a first-hop segment 4729 node from its own perspective, the Client stores the Proxy/Server's 4730 FMT/SRT/ULA/INADDR as last-hop segment (LHS) information to supply to 4731 neighbors. This allows both the Client and Hub Proxy/Server to 4732 supply the information to neighbors that will perceive it as LHS 4733 information on the return path to the Client. 4735 Note: The Hub Proxy/Server injects Client XLA-MNP into the OMNI link 4736 routing system by simply creating a route-to-interface forwarding 4737 table entry for fd00::{MNP}/N via the OMNI interface. The dynamic 4738 routing protocol will notice the new entry and propagate the route to 4739 its peers. If the Hub receives additional RS messages, it need not 4740 re-create the forwarding table entry (nor disturb the dynamic routing 4741 protocol) if an entry is already present. If the Hub ceases to 4742 receive RS messages from any of the Client's interfaces, it removes 4743 the Client XLA-MNP from the forwarding table (i.e., after a short 4744 delay) resulting in its removal also from the routing system. 4746 Note: If the Client's initial RS message includes an anycast L2 4747 destination address, the FHS Proxy/Server returns the solicited RA 4748 using the same anycast address as the L2 source while including an 4749 Interface Attributes sub-option with omIndex '0' and its true unicast 4750 address in the INADDR. When the Client sends additional RS messages, 4751 it includes this FHS Proxy/Server unicast address as the L2 4752 destination and the FHS Proxy/Server returns the solicited RA using 4753 the same unicast address as the L2 source. This will ensure that RS/ 4754 RA exchanges are not impeded by any NATs on the path while avoiding 4755 long-term exposure of messages that use an anycast address as the 4756 source. 4758 Note: The Origin Indication sub-option is included only by the FHS 4759 Proxy/Server and not by the Hub (unless the Hub is also serving as an 4760 FHS). 4762 Note: Clients should set the N/A/U flags consistently in successive 4763 RS messages and only change those settings when an FHS/Hub Proxy/ 4764 Server service profile update is necessary. 4766 Note: After a Client has discovered its ULA-MNPs for a given set of 4767 FHS Proxy/Servers, it should begin using its XLA-MNP as the IPv6 ND 4768 message source address and ULA-MNP as the OAL source address in 4769 future IPv6 ND messages and refrain from further use of TLAs. In any 4770 case, the Client SHOULD NOT gratuitously configure and use large 4771 numbers of additional TLAs, as doing so would simply result in 4772 address change churn in neighbor cache entries with no operational 4773 advantages. 4775 Note: Although the Client adds the Hub Proxy/Server ULA to the 4776 default router list, it also caches the ULAs of the FHS Proxy/Servers 4777 on the path to the Hub over each underlying interface. When the 4778 Client needs to send a packet to a default router, it therefore 4779 selects an ULA corresponding to the selected interface which directs 4780 the packet to an FHS Proxy/Server for that interface. The FHS Proxy/ 4781 Server then forwards the packet without disturbing the Hub. 4783 15.1. Window Synchronization 4785 In environments where Identification window synchronization is 4786 necessary, the RS/RA exchanges discussed above observe the principles 4787 specified in Section 6.6. Window synchronization is conducted 4788 between the Client and each FHS Proxy/Server used to contact the Hub 4789 Proxy/Server, i.e., and not between the Client and the Hub. This is 4790 due to the fact that the Hub Proxy/Server is responsible only for 4791 forwarding control and data messages via the secured spanning tree to 4792 FHS Proxy/Servers, and is not responsible for forwarding messages 4793 directly to the Client under a synchronized window. Also, in the 4794 reverse direction the FHS Proxy/Servers handle all default forwarding 4795 actions without forwarding Client-initiated data to the Hub. 4797 When a Client needs to perform window synchronization via a new FHS 4798 Proxy/Server, it sets the RS source address to its own {TLA,XLA}-MNP 4799 (or a {TLA,XLA}-RND) and destination address to the ULA of the Hub 4800 Proxy/Server (or to All-Routers multicast in an initial RS), then 4801 sets the SYN flag and includes an initial Sequence Number for Window 4802 Synchronization. The Client then performs OAL encapsulation using 4803 its own ULA-MNP (or the TLA-RND) as the source and the ULA of the FHS 4804 Proxy/Server as the destination and includes an Interface Attributes 4805 sub-option then forwards the resulting carrier packets to the FHS 4806 Proxy/Server. The FHS Proxy/Server then extracts the RS message and 4807 caches the Window Synchronization parameters then re-encapsulates 4808 with its own ULA as the source and the ULA of the Hub Proxy/Server as 4809 the target. 4811 The FHS Proxy/Server then forwards the resulting carrier packets via 4812 the secured spanning tree to the Hub Proxy/Server, which updates the 4813 Client's Interface Attributes and returns a unicast RA message with 4814 source set to its own ULA and destination set to the RS source 4815 address and with the Client's Interface Attributes echoed. The Hub 4816 Proxy/Server then performs OAL encapsulation using its own ULA as the 4817 source and the ULA of the FHS Proxy/Server as the destination, then 4818 forwards the carrier packets via the secured spanning tree to the FHS 4819 Proxy/Server. The FHS Proxy/Server then proxys the message as 4820 discussed in the previous section and includes responsive Window 4821 Synchronization information. The FHS Proxy/Server then forwards the 4822 message to the Client which updates its window synchronization 4823 information for the FHS Proxy/Server as necessary. 4825 Following the initial RS/RA-driven window synchronization, the Client 4826 can re-assert new windows with specific FHS Proxy/Servers by 4827 performing NS/NA exchanges between its own XLA-MNPs and the ULAs of 4828 the FHS Proxy/Servers without having to disturb the Hub. 4830 15.2. Router Discovery in IP Multihop and IPv4-Only Networks 4832 On some *NETs, a Client may be located multiple IP hops away from the 4833 nearest OMNI link Proxy/Server. Forwarding through IP multihop *NETs 4834 is conducted through the application of a routing protocol (e.g., a 4835 MANET/VANET routing protocol over omni-directional wireless 4836 interfaces, an inter-domain routing protocol in an enterprise 4837 network, etc.). Example routing protocols optimized for MANET/VANET 4838 operations include [RFC3684] and [RFC5614] which operate according to 4839 the link model articulated in [RFC5889] and subnet model articulated 4840 in [RFC5942]. 4842 A Client located potentially multiple *NET hops away from the nearest 4843 Proxy/Server prepares an RS message, sets the source address to its 4844 {TLA,XLA}-MNP (or to a {TLA,XLA}-RND if it does not yet have an MNP), 4845 and sets the destination to link-scoped All-Routers multicast or the 4846 unicast ULA of a Proxy/Server the same as discussed above. The OMNI 4847 interface then employs OAL encapsulation, sets the OAL source address 4848 to a TLA and sets the OAL destination to an OMNI IPv6 anycast address 4849 based on either a native IPv6 or IPv4-Compatible IPv6 prefix (see: 4850 Section 10). 4852 For IPv6-enabled *NETs, if the underlay interface does not configure 4853 an IPv6 GUA the Client injects the TLA into the IPv6 multihop routing 4854 system and forwards the message without further encapsulation. 4855 Otherwise, the Client encapsulates the message in UDP/IPv6 L2 4856 headers, sets the source to the underlay interface IPv6 address and 4857 sets the destination to the same OMNI IPv6 anycast address. The 4858 Client then forwards the message into the IPv6 multihop routing 4859 system which conveys it to the nearest Proxy/Server that advertises a 4860 matching OMNI IPv6 anycast prefix. If the nearest Proxy/Server is 4861 too busy, it should forward (without Proxying) the OAL-encapsulated 4862 RS to another nearby Proxy/Server connected to the same IPv6 4863 (multihop) network that also advertises the matching OMNI IPv6 4864 anycast prefix. 4866 For IPv4-only *NETs, the Client encapsulates the RS message in UDP/ 4867 IPv4 L2 headers, sets the source to the underlay interface IPv4 4868 address and sets the destination to the OMNI IPv4 anycast address. 4869 The Client then forwards the message into the IPv4 multihop routing 4870 system which conveys it to the nearest Proxy/Server that advertises 4871 the corresponding IPv4 prefix. If the nearest Proxy/Server is too 4872 busy and/or does not configure the specified OMNI IPv6 anycast 4873 address, it should forward (without Proxying) the OAL-encapsulated RS 4874 to another nearby Proxy/Server connected to the same IPv4 (multihop) 4875 network that configures the OMNI IPv6 anycast address. (In 4876 environments where reciprocal RS forwarding cannot be supported, the 4877 first Proxy/Server should instead return an RA based on its own 4878 MSP(s).) 4880 When an intermediate *NET hop that participates in the routing 4881 protocol receives the encapsulated RS, it forwards the message 4882 according to its routing tables (note that an intermediate node could 4883 be a fixed infrastructure element such as a roadside unit or another 4884 MANET/VANET node). This process repeats iteratively until the RS 4885 message is received by a penultimate *NET hop within single-hop 4886 communications range of a Proxy/Server, which forwards the message to 4887 the Proxy/Server. 4889 When a Proxy/Server that configures the OMNI IPv6 anycast OAL 4890 destination receives the message, it decapsulates the RS and assumes 4891 either the Hub or FHS role (in which case, it forwards the RS to a 4892 candidate Hub). The Hub Proxy/Server then prepares an RA message 4893 with source address set to its own ULA and destination address set to 4894 the RS source address if it is acting only as the Hub (or to the 4895 Client ULA-MNP within its ULA subnet prefix if it is also acting as 4896 the FHS Proxy/Server). The Hub Proxy/Server then performs OAL 4897 encapsulation with the RA OAL source/destination set to the RS OAL 4898 destination/source and forwards the RA either to the FHS Proxy/Server 4899 or directly to the Client. 4901 When the Hub or FHS Proxy/Server forwards the RA to the Client, it 4902 encapsulates the message in L2 encapsulation headers (if necessary) 4903 with (src, dst) set to the (dst, src) of the RS L2 encapsulation 4904 headers. The Proxy/Server then forwards the message to a *NET node 4905 within communications range, which forwards the message according to 4906 its routing tables to an intermediate node. The multihop forwarding 4907 process within the *NET continues repetitively until the message is 4908 delivered to the original Client, which decapsulates the message and 4909 performs autoconfiguration the same as if it had received the RA 4910 directly from a Proxy/Server on the same physical link. The Client 4911 then injects the ULA-MNP into the IPv6 multihop routing system if 4912 necessary, then begins using the ULA-MNP as its OAL source address 4913 and suspends use of its TLA since it now has a unique address within 4914 the FHS Proxy/Server's "Multilink Subnet". 4916 Note: When the RS message includes anycast OAL and/or L2 4917 encapsulation destinations, the FHS Proxy/Server must use the same 4918 anycast addresses as the OAL and/or L2 encapsulation sources to 4919 support forwarding of the RA message and any initial data packets 4920 over any NATs on the path. When the Client receives the RA, it will 4921 discover its unicast ULA-MNP and/or L2 encapsulation addresses and 4922 can forward future packets using the unicast (instead of anycast) 4923 addresses to populate NAT state in the forward path. (If the Client 4924 does not have immediate data to send to the FHS Proxy/Server, it can 4925 instead send an OAL "bubble" - see Section 6.10.) After the Client 4926 begins using unicast OAL/L2 encapsulation addresses in this way, the 4927 FHS Proxy/Server should also begin using the same unicast addresses 4928 in the reverse direction. 4930 Note: When an OMNI interface configures a TLA, any nodes that forward 4931 an encapsulated RS message with the ULA as the OAL source must not 4932 consider the message as being specific to a particular OMNI link. 4933 TLAs can therefore also serve as the source and destination addresses 4934 of unencapsulated IPv6 data communications within the local routing 4935 region, and if the TLAs are injected into the local network routing 4936 protocol their prefix length must be set to 128. 4938 15.3. DHCPv6-based Prefix Registration 4940 When a Client is not pre-provisioned with an MNP (or, when the Client 4941 requires additional MNP delegations), it requests the MS to select 4942 MNPs on its behalf and set up the correct routing state. The DHCPv6 4943 service [RFC8415] supports this requirement. 4945 When a Client requires the MS to select MNPs, it sends an RS message 4946 with source set to a {TLA,XLA}-RND. If the Client requires only a 4947 single MNP delegation, it can then include a OMNI Node Identification 4948 sub-option plus an OMNI Neighbor Coordination sub-option with Preflen 4949 set to the length of the desired MNP. If the Client requires 4950 multiple MNP delegations and/or more complex DHCPv6 services, it 4951 instead includes a DHCPv6 Message sub-option containing a Client 4952 Identifier, one or more IA_PD options and a Rapid Commit option then 4953 sets the 'msg-type' field to "Solicit", and includes a 3 octet 4954 'transaction-id'. The Client then sets the RS destination to link- 4955 scoped All-Routers multicast and sends the message using OAL 4956 encapsulation and fragmentation if necessary as discussed above. 4958 When the Hub Proxy/Server receives the RS message, it performs OAL 4959 reassembly if necessary. Next, if the RS source is a {TLA,XLA}-RND 4960 and/or the OMNI option includes a DHCPv6 message sub-option, the Hub 4961 Proxy/Server acts as a "Proxy DHCPv6 Client" in a message exchange 4962 with the locally-resident DHCPv6 server. If the RS did not contain a 4963 DHCPv6 message sub-option, the Hub Proxy/Server generates a DHCPv6 4964 Solicit message on behalf of the Client using an IA_PD option with 4965 the prefix length set to the OMNI Neighbor Coordination header 4966 Preflen value and with a Client Identifier formed from the OMNI 4967 option Node Identification sub-option; otherwise, the Hub Proxy/ 4968 Server uses the DHCPv6 Solicit message contained in the OMNI option. 4969 The Hub Proxy/Server then sends the DHCPv6 message to the DHCPv6 4970 Server, which delegates MNPs and returns a DHCPv6 Reply message with 4971 PD parameters. (If the Hub Proxy/Server wishes to defer creation of 4972 Client state until the DHCPv6 Reply is received, it can instead act 4973 as a Lightweight DHCPv6 Relay Agent per [RFC6221] by encapsulating 4974 the DHCPv6 message in a Relay-forward/reply exchange with Relay 4975 Message and Interface ID options. In the process, the Hub Proxy/ 4976 Server packs any state information needed to return an RA to the 4977 Client in the Relay-forward Interface ID option so that the 4978 information will be echoed back in the Relay-reply.) 4980 When the Hub Proxy/Server receives the DHCPv6 Reply, it creates XLA- 4981 MNPs based on the delegated MNPs and creates OMNI interface XLA-MNP 4982 forwarding table entries (i.e., to prompt the dynamic routing 4983 protocol). The Hub Proxy/Server then sends an RA back to the FHS 4984 Proxy/Server with the DHCPv6 Reply message included in an OMNI DHCPv6 4985 message sub-option. The Hub Proxy/Server sets the RA destination 4986 address to the RS source address, sets the RA source address to its 4987 own ULA, performs OAL encapsulation and fragmentation, performs L2 4988 encapsulation and sends the RA to the Client via the FHS Proxy/Server 4989 as discussed above. 4991 When the FHS Proxy/Server receives the RA, it changes the RA 4992 destination address to the ULA-MNP for the Client within its own ULA 4993 subnet prefix then forwards the RA to the Client. When the Client 4994 receives the RA, it reassembles and discards the OAL encapsulation 4995 then creates a default route, assigns Subnet Router Anycast addresses 4996 and uses the RA destination address or DHCPv6-delegated MNP to 4997 automatically configure its primary ULA-MNP. The Client will then 4998 use these primary MNP-based addresses as the source address of any 4999 IPv6 ND messages it sends as long as it retains ownership of the MNP. 5001 Note: when the Hub Proxy/Server is also the FHS Proxy/Server, it 5002 forwards the RA message directly to the Client with the destination 5003 set to the Client's ULA-MNP (i.e., instead of forwarding via another 5004 Proxy/Server). 5006 15.4. OMNI Link Extension 5008 Clients can provide an OMNI link ingress point for other nodes on 5009 their (downstream) ENETs that also act as Clients. When Client A has 5010 already coordinated with an (upstream) ANET/INET Proxy/Server, Client 5011 B on an ENET serviced by Client A can send OAL-encapsulated RS 5012 messages with addresses set the same as specified in Section 15.2. 5013 When Client A receives the RS message, it infers from the OAL 5014 encapsulation that Client B is seeking to establish itself as a 5015 Client instead of just a simple ENET Host. 5017 Client A then returns an RA message the same as a Proxy/Server would 5018 do as specified in Section 15.2 except that it instead uses its own 5019 ULA-MNP as the RA and OAL source addresses and performs (recursive) 5020 DHCPv6 Prefix Delegation. The MNP delegation in the RA message must 5021 be a sub-MNP from the MNP delegated to Client A. For example, if 5022 Client A receives the MNP 2001:db8:1000::/48 it can provide a sub- 5023 delegation such as 2001:db8:1000:2000::/56 to Client B. Client B can 5024 in turn sub-delegate 2001:db8:1000:2000::/56 to its own ENET(s), 5025 where there may be a further prospective Client C that would in turn 5026 request OMNI link services via Client B. 5028 To support this Client-to-Client chaining, Clients send IPv6 ND 5029 messages addressed to the OMNI link anycast address via their ANET/ 5030 INET (i.e., upstream) interfaces, but advertise the OMNI link anycast 5031 address into their ENET (i.e., downstream) networks where there may 5032 be further prospective Clients wishing to join the chain. The ENET 5033 of the upstream Client is therefore seen as an ANET by downstream 5034 Clients, and the upstream Client is seen as a Proxy/Server by 5035 downstream Clients. 5037 16. Secure Redirection 5039 If the underlay network link model is multiple access, the FHS Proxy/ 5040 Server is responsible for assuring that address duplication cannot 5041 corrupt the neighbor caches of other nodes on the link. When the 5042 Client sends an RS message on a multiple access underlay network, the 5043 Proxy/Server verifies that the Client is authorized to use the 5044 address and responds with an RA (or forwards the RS to the Hub) only 5045 if the Client is authorized. 5047 After verifying Client authorization and returning an RA, the Proxy/ 5048 Server MAY return IPv6 ND Redirect messages to direct Clients located 5049 on the same underlay network to exchange packets directly without 5050 transiting the Proxy/Server. In that case, the Clients can exchange 5051 packets according to their unicast L2 addresses discovered from the 5052 Redirect message instead of using the dogleg path through the Proxy/ 5053 Server. In some underlay networks, however, such direct 5054 communications may be undesirable and continued use of the dogleg 5055 path through the Proxy/Server may provide better performance. In 5056 that case, the Proxy/Server can refrain from sending Redirects, and/ 5057 or Clients can ignore them. 5059 17. Proxy/Server Resilience 5061 *NETs SHOULD deploy Proxy/Servers in Virtual Router Redundancy 5062 Protocol (VRRP) [RFC5798] configurations so that service continuity 5063 is maintained even if one or more Proxy/Servers fail. Using VRRP, 5064 the Client is unaware which of the (redundant) FHS Proxy/Servers is 5065 currently providing service, and any service discontinuity will be 5066 limited to the failover time supported by VRRP. Widely deployed 5067 public domain implementations of VRRP are available. 5069 Proxy/Servers SHOULD use high availability clustering services so 5070 that multiple redundant systems can provide coordinated response to 5071 failures. As with VRRP, widely deployed public domain 5072 implementations of high availability clustering services are 5073 available. Note that special-purpose and expensive dedicated 5074 hardware is not necessary, and public domain implementations can be 5075 used even between lightweight virtual machines in cloud deployments. 5077 18. Detecting and Responding to Proxy/Server Failures 5079 In environments where fast recovery from Proxy/Server failure is 5080 required, FHS Proxy/Servers SHOULD use proactive Neighbor 5081 Unreachability Detection (NUD) in a manner that parallels 5082 Bidirectional Forwarding Detection (BFD) [RFC5880] to track Hub 5083 Proxy/Server reachability. FHS Proxy/Servers can then quickly detect 5084 and react to failures so that cached information is re-established 5085 through alternate paths. Proactive NUD control messaging is carried 5086 only over well-connected ground domain networks (i.e., and not low- 5087 end links such as aeronautical radios) and can therefore be tuned for 5088 rapid response. 5090 FHS Proxy/Servers perform proactive NUD for Hub Proxy/Servers for 5091 which there are currently active Clients. If a Hub Proxy/Server 5092 fails, the FHS Proxy/Server can quickly inform Clients of the outage 5093 by sending multicast RA messages. The FHS Proxy/Server sends RA 5094 messages to Clients with source set to the ULA of the Hub, with 5095 destination address set to All-Nodes multicast (ff02::1) [RFC4291] 5096 and with Router Lifetime set to 0. 5098 The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA 5099 messages separated by small delays [RFC4861]. Any Clients that have 5100 been using the (now defunct) Hub Proxy/Server will receive the RA 5101 messages. 5103 19. Transition Considerations 5105 When a Client connects to an *NET link for the first time, it sends 5106 an RS message with an OMNI option. If the first hop router 5107 recognizes the option, it responds according to the appropriate FHS/ 5108 Hub Proxy/Server role resulting in an RA message with an OMNI option 5109 returned to the Client. The Client then engages this FHS Proxy/Sever 5110 according to the OMNI link model specified above. If the first hop 5111 router is a legacy IPv6 router, however, it instead returns an RA 5112 message with no OMNI option and with a non-OMNI unicast source LLA as 5113 specified in [RFC4861]. In that case, the Client engages the *NET 5114 according to the legacy IPv6 link model and without the OMNI 5115 extensions specified in this document. 5117 If the *NET link model is multiple access, there must be assurance 5118 that address duplication cannot corrupt the neighbor caches of other 5119 nodes on the link. When the Client sends an RS message on a multiple 5120 access *NET link with an OMNI option, first hop routers that 5121 recognize the option ensure that the Client is authorized to use the 5122 address and return an RA with a non-zero Router Lifetime only if the 5123 Client is authorized. First hop routers that do not recognize the 5124 OMNI option instead return an RA that makes no statement about the 5125 Client's authorization to use the source address. In that case, the 5126 Client should perform Duplicate Address Detection to ensure that it 5127 does not interfere with other nodes on the link. 5129 An alternative approach for multiple access *NET links to ensure 5130 isolation for Client-Proxy/Server communications is through link- 5131 layer address mappings as discussed in Appendix D. This arrangement 5132 imparts a (virtual) point-to-point link model over the (physical) 5133 multiple access link. 5135 20. OMNI Interfaces on Open Internetworks 5137 Client OMNI interfaces configured over IPv6-enabled underlay 5138 interfaces on an open Internetwork without an OMNI-aware first-hop 5139 router receive IPv6 RA messages with no OMNI options, while OMNI 5140 interfaces configured over IPv4-only underlay interfaces receive no 5141 IPv6 RA messages at all (but may receive IPv4 RA messages [RFC1256]). 5142 Client OMNI interfaces that receive RA messages with OMNI options 5143 configure addresses, on-link prefixes, etc. on the underlay interface 5144 that received the RA according to standard IPv6 ND and address 5145 resolution conventions [RFC4861] [RFC4862]. Client OMNI interfaces 5146 configured over IPv4-only underlay interfaces configure IPv4 address 5147 information on the underlay interfaces using mechanisms such as 5148 DHCPv4 [RFC2131]. 5150 Client OMNI interfaces configured over underlay interfaces connected 5151 to open Internetworks can apply security services such as VPNs to 5152 connect to a Proxy/Server, or can establish a direct link to the 5153 Proxy/Server through some other means (see Section 4). In 5154 environments where an explicit VPN or direct link may be impractical 5155 or undesirable, Client OMNI interfaces can instead send IPv6 ND 5156 messages with OMNI options that include authentication signatures. 5158 OMNI interfaces use UDP/IP as L2 encapsulation headers for 5159 transmission over open Internetworks with UDP service port number 5160 8060 (see: Section 25.13 and Section 3.6 of [I-D.templin-6man-aero]) 5161 for both IPv4 and IPv6 underlay interfaces. The OMNI interface 5162 submits original IP packets for OAL encapsulation, then encapsulates 5163 the resulting OAL fragments in UDP/IP L2 headers to form carrier 5164 packets. (The first four bits following the UDP header determine 5165 whether the OAL headers are uncompressed/compressed as discussed in 5166 Section 6.4.) The OMNI interface sets the UDP length to the 5167 encapsulated OAL fragment length and sets the IP length to an 5168 appropriate value at least as large as the UDP datagram. 5170 For Client-Proxy/Server (e.g., "Vehicle-to-Infrastructure (V2I)") 5171 neighbor exchanges, the source must include an OMNI option with an 5172 authentication sub-option in all IPv6 ND messages. The source can 5173 apply HIP security services per [RFC7401] using the IPv6 ND message 5174 OMNI option as a "shipping container" to convey an authentication 5175 signature in a (unidirectional) HIP "Notify" message. For Client- 5176 Client (e.g., "Vehicle-to-Vehicle (V2V)") neighbor exchanges, two 5177 Clients can exchange HIP "Initiator/Responder" messages coded in OMNI 5178 options of multiple IPv6 NS/NA messages for mutual authentication 5179 according to the HIP protocol. (Note: a simple Hashed Message 5180 Authentication Code (HMAC) such as specified in [RFC4380] or the 5181 QUIC-TLS connection-oriented service [RFC9000] can be used as an 5182 alternate authentication service in some environments.) 5183 When an OMNI interface includes an authentication sub-option, it must 5184 appear as the first sub-option of the first OMNI option in the IPv6 5185 ND message which must appear immediately following the IPv6 ND 5186 message header. When an OMNI interface prepares a HIP message sub- 5187 option, it includes its own (H)HIT as the Sender's HIT and the 5188 neighbor's (H)HIT if known as the Receiver's HIT (otherwise 0). If 5189 (H)HITs are not available within the OMNI operational environment, 5190 the source can instead include other IPv6 address types instead of 5191 (H)HITs as long as the Sender and Receiver have some way to associate 5192 information embedded in the IPv6 address with the neighbor; such 5193 information could include a node identifier, vehicle identifier, MAC 5194 address, etc. 5196 Before calculating the authentication signature, the source includes 5197 any other necessary sub-options (such as Interface Attributes and 5198 Origin Indication) and sets both the IPv6 ND message Checksum and 5199 authentication signature fields to 0. The source then calculates the 5200 authentication signature over the full length of the IPv6 ND message 5201 beginning with a pseudo-header of the IPv6 header (i.e., the same as 5202 specified in [RFC4443]) and extending over the length of the message. 5203 (If the IPv6 ND message is part of an OAL super-packet, the source 5204 instead calculates the authentication signature over the remainder of 5205 the super-packet.) The source next writes the authentication 5206 signature into the sub-option signature field and forwards the 5207 message. 5209 After establishing a VPN or preparing for UDP/IP encapsulation, OMNI 5210 interfaces send RS/RA messages for Client-Proxy/Server coordination 5211 (see: Section 15) and NS/NA messages for route optimization, window 5212 synchronization and mobility management (see: 5213 [I-D.templin-6man-aero]). These control plane messages must be 5214 authenticated while other control and data plane messages are 5215 delivered the same as for ordinary best-effort traffic with source 5216 address and/or Identification window-based data origin verification. 5217 Upper layer protocol sessions over OMNI interfaces that connect over 5218 open Internetworks without an explicit VPN should therefore employ 5219 transport- or higher-layer security to ensure authentication, 5220 integrity and/or confidentiality. 5222 Clients should avoid using INET Proxy/Servers as general-purpose 5223 routers for steady streams of carrier packets that do not require 5224 authentication. Clients should instead perform route optimization to 5225 coordinate with other INET nodes that can provide forwarding services 5226 (or preferably coordinate directly with peer Clients directly) 5227 instead of burdening the Proxy/Server. Procedures for coordinating 5228 with peer Clients and discovering INET nodes that can provide better 5229 forwarding services are discussed in [I-D.templin-6man-aero]. 5231 Clients that attempt to contact peers over INET underlay interfaces 5232 often encounter NATs in the path. OMNI interfaces accommodate NAT 5233 traversal using UDP/IP encapsulation and the mechanisms discussed in 5234 [I-D.templin-6man-aero]. FHS Proxy/Servers include Origin 5235 Indications in RA messages to allow Clients to detect the presence of 5236 NATs. 5238 Note: Following the initial IPv6 ND message exchange, OMNI interfaces 5239 configured over INET underlay interfaces maintain neighbor 5240 relationships by transmitting periodic IPv6 ND messages with OMNI 5241 options that include HIP "Update" and/or "Notify" messages. When 5242 HMAC authentication is used instead of HIP, the Client and Proxy/ 5243 Server exchange all IPv6 ND messages with HMAC signatures included 5244 based on a shared-secret. When QUIC-TLS connections are used, the 5245 Client and Proxy/Server observe QUIC-TLS conventions 5246 [RFC9000][RFC9001]. 5248 Note: OMNI interfaces configured over INET underlay interfaces should 5249 employ the Identification window synchronization mechanisms specified 5250 in Section 6.6 in order to exclude spurious carrier packets that 5251 might otherwise clutter the reassembly cache. This is especially 5252 important in environments where carrier packet spoofing and/or 5253 corruption is a threat. 5255 Note: NATs may be present on the path from a Client to its FHS Proxy/ 5256 Server, but never on the path from the FHS Proxy/Server to the Hub 5257 where only INET and/or spanning tree hops occur. Therefore, the FHS 5258 Proxy/Server does not communicate Client origin information to the 5259 Hub where it would serve no purpose. 5261 21. Time-Varying MNPs 5263 In some use cases, it is desirable, beneficial and efficient for the 5264 Client to receive a constant MNP that travels with the Client 5265 wherever it moves. For example, this would allow air traffic 5266 controllers to easily track aircraft, etc. In other cases, however 5267 (e.g., intelligent transportation systems), the Client may be willing 5268 to sacrifice a modicum of efficiency in order to have time-varying 5269 MNPs that can be changed every so often to defeat adversarial 5270 tracking. 5272 The prefix delegation services discussed in Section 15.3 allows 5273 Clients that desire time-varying MNPs to obtain short-lived prefixes 5274 to send RS messages with a {TLA,XLA}-RND source address and/or with 5275 an OMNI option with DHCPv6 Option sub-options. The Client would then 5276 be obligated to renumber its internal networks whenever its MNP (and 5277 therefore also its OMNI address) changes. This should not present a 5278 challenge for Clients with automated network renumbering services, 5279 but may disrupt persistent sessions that would prefer to use a 5280 constant address. 5282 22. (H)HITs and Temporary ULA (TLA)s 5284 Clients that generate (H)HITs but do not have pre-assigned MNPs can 5285 request MNP delegations by issuing IPv6 ND messages that use the 5286 (H)HIT instead of a TLA. For example, when a Client creates an RS 5287 message it can set the source to a (H)HIT and destination to link- 5288 scoped All-Routers multicast. The IPv6 ND message includes an OMNI 5289 option with a HIP message sub-option, and need not include a Node 5290 Identification sub-option if the Client's (H)HIT appears in the HIP 5291 message. The Client then encapsulates the message in an IPv6 header 5292 with the (H)HIT as the source address. The Client then sends the 5293 message as specified in Section 15.2. 5295 When the Hub Proxy/Server receives the RS message, it notes that the 5296 source was a (H)HIT, then invokes the DHCPv6 protocol to request an 5297 MNP prefix delegation while using the (H)HIT (in the form of a DUID) 5298 as the Client Identifier. The Hub Proxy/Server then prepares an RA 5299 message with source address set to its own ULA and destination set to 5300 the source of the RS message. The Hub Proxy/Server next includes an 5301 OMNI option with a HIP message sub-option and any DHCPv6 prefix 5302 delegation parameters. The Proxy/Server finally encapsulates the RA 5303 in an OAL header with source address set to its own ULA and 5304 destination set to the RS OAL source address, then returns the 5305 encapsulated RA to the Client either directly or by way of the FHS 5306 Proxy/Server as a proxy. 5308 Clients can also use (H)HITs and/or TLAs for direct Client-to-Client 5309 communications outside the context of any OMNI link supporting 5310 infrastructure. When two Clients encounter one another they can use 5311 their (H)HITs and/or TLAs as original IPv6 packet source and 5312 destination addresses to support direct communications. Clients can 5313 also inject their (H)HITs and/or TLAs into an IPv6 multihop routing 5314 protocol to enable multihop communications as discussed in 5315 Section 15.2. Clients can further exchange other IPv6 ND messages 5316 using their (H)HITs and/or TLAs as source and destination addresses. 5318 Lastly, when Clients are within the coverage range of OMNI link 5319 infrastructure a case could be made for injecting (H)HITs and/or TLAs 5320 into the global MS routing system. For example, when the Client 5321 sends an RS to an FHS Proxy/Server it could include a request to 5322 inject the (H)HIT / TLA into the routing system instead of requesting 5323 an MNP prefix delegation. This would potentially enable OMNI link- 5324 wide communications using only (H)HITs or TLAs, and not MNPs. This 5325 document notes the opportunity, but makes no recommendation. 5327 23. Address Selection 5329 Clients assign LLAs to the OMNI interface, but do not use LLAs as 5330 IPv6 ND message source/destination addresses nor for addressing 5331 ordinary original IP packets exchanged with OMNI link neighbors. 5333 Clients use ULA-MNPs as source/destination IPv6 addresses in the 5334 encapsulation headers of OAL packets and use XLA-MNPs as the IPv6 5335 source addresses of the IPv6 ND messages themselves. Clients use 5336 TLAs when an MNP is not available, or as source/destination IPv6 5337 addresses for communications within a MANET/VANET local area. 5338 Clients can also use (H)HITs instead of ULAs for local communications 5339 when operation outside the context of a specific ULA domain and/or 5340 source address attestation is necessary. 5342 Clients use MNP-based GUAs as original IP packet source and 5343 destination addresses for communications with Internet destinations 5344 when they are within range of OMNI link supporting infrastructure 5345 that can inject the MNP into the routing system. Clients can also 5346 use MNP-based GUAs within multihop routing regions that are currently 5347 disconnected from infrastructure as long as the corresponding ULA- 5348 MNPs have been injected into the routing system. 5350 Clients use anycast GUAs as OAL and/or L2 encapsulation destination 5351 addresses for RS messages used to discover the nearest FHS Proxy/ 5352 Server. When the Proxy/Server returns a solicited RA, it must also 5353 use the same anycast address as the RA OAL/L2 encapsulation source in 5354 order to successfully traverse any NATs in the path. The Client 5355 should then immediately transition to using the FHS Proxy/Server's 5356 discovered unicast OAL/L2 address as the destination in order to 5357 minimize dependence on the Proxy/Server's use of an anycast source 5358 address. 5360 24. Error Messages 5362 An OAL destination or intermediate node may need to return 5363 ICMPv6-like error messages (e.g., Destination Unreachable, Packet Too 5364 Big, Time Exceeded, etc.) [RFC4443] to an OAL source. Since ICMPv6 5365 error messages do not themselves include authentication codes, OAL 5366 nodes can return error messages as an OMNI ICMPv6 Error sub-option in 5367 a secured IPv6 ND uNA message. 5369 25. IANA Considerations 5371 The following IANA actions are requested in accordance with [RFC8126] 5372 and [RFC8726]: 5374 25.1. "Protocol Numbers" Registry 5376 The IANA is instructed to allocate an Internet Protocol number TBD1 5377 from the 'protocol numbers' registry for the Overlay Multilink 5378 Network Interface (OMNI) protocol. Guidance is found in [RFC5237] 5379 (registration procedure is IESG Approval or Standards Action). 5381 25.2. "IEEE 802 Numbers" Registry 5383 During final publication stages, the IESG will be requested to 5384 procure an IEEE EtherType value TBD2 for OMNI according to the 5385 statement found at https://www.ietf.org/about/groups/iesg/statements/ 5386 ethertypes/. 5388 Following this procurement, the IANA is instructed to register the 5389 value TBD2 in the 'ieee-802-numbers' registry for Overlay Multilink 5390 Network Interface (OMNI) encapsulation on Ethernet networks. 5391 Guidance is found in [RFC7042] (registration procedure is Expert 5392 Review). 5394 25.3. "IPv4 Special-Purpose Address" Registry 5396 The IANA is instructed to assign TBD3/N as an "OMNI IPv4 anycast" 5397 address/prefix in the "IPv4 Special-Purpose Address" registry in a 5398 similar fashion as for [RFC3068]. The IANA is requested to work with 5399 the authors to obtain a TBD3/N public IPv4 prefix, whether through an 5400 RIR allocation, a delegation from IANA's "IPv4 Recovered Address 5401 Space" registry or through an unspecified third party donation. 5403 25.4. "IPv6 Neighbor Discovery Option Formats" Registry 5405 The IANA is instructed to allocate an official Type number TBD4 from 5406 the "IPv6 Neighbor Discovery Option Formats" registry for the OMNI 5407 option (registration procedure is RFC required). Implementations set 5408 Type to 253 as an interim value [RFC4727]. 5410 25.5. "Ethernet Numbers" Registry 5412 The IANA is instructed to allocate one Ethernet unicast address TBD5 5413 (suggested value '00-52-14') in the 'ethernet-numbers' registry under 5414 "IANA Unicast 48-bit MAC Addresses" (registration procedure is Expert 5415 Review). The registration should appear as follows: 5417 Addresses Usage Reference 5418 --------- ----- --------- 5419 00-52-14 Overlay Multilink Network (OMNI) Interface [RFCXXXX] 5421 Figure 35: IANA Unicast 48-bit MAC Addresses 5423 25.6. "ICMPv6 Code Fields: Type 2 - Packet Too Big" Registry 5425 The IANA is instructed to assign two new Code values in the "ICMPv6 5426 Code Fields: Type 2 - Packet Too Big" registry (registration 5427 procedure is Standards Action or IESG Approval). The registry should 5428 appear as follows: 5430 Code Name Reference 5431 --- ---- --------- 5432 0 PTB Hard Error [RFC4443] 5433 1 PTB Soft Error (loss) [RFCXXXX] 5434 2 PTB Soft Error (no loss) [RFCXXXX] 5436 Figure 36: ICMPv6 Code Fields: Type 2 - Packet Too Big Values 5438 (Note: this registry also to be used to define values for setting the 5439 "unused" field of ICMPv4 "Destination Unreachable - Fragmentation 5440 Needed" messages.) 5442 25.7. "OMNI Option Sub-Type Values" (New Registry) 5444 The OMNI option defines a 5-bit Sub-Type field, for which IANA is 5445 instructed to create and maintain a new registry entitled "OMNI 5446 Option Sub-Type Values". Initial values are given below 5447 (registration procedure is RFC required): 5449 Value Sub-Type name Reference 5450 ----- ------------- ---------- 5451 0 Pad1 [RFCXXXX] 5452 1 PadN [RFCXXXX] 5453 2 Neighbor Coordination [RFCXXXX] 5454 3 Interface Attributes [RFCXXXX] 5455 4 Multilink Forwarding Params [RFCXXXX] 5456 5 Traffic Selector [RFCXXXX] 5457 6 Geo Coordinates [RFCXXXX] 5458 7 DHCPv6 Message [RFCXXXX] 5459 8 HIP Message [RFCXXXX] 5460 9 PIM-SM Message [RFCXXXX] 5461 10 Fragmentation Report [RFCXXXX] 5462 11 Node Identification [RFCXXXX] 5463 12 ICMPv6 Error [RFCXXXX] 5464 13 QUIC-TLS Message [RFCXXXX] 5465 14 Proxy/Server Departure [RFCXXXX] 5466 15-29 Unassigned 5467 30 Sub-Type Extension [RFCXXXX] 5468 31 Reserved by IANA [RFCXXXX] 5470 Figure 37: OMNI Option Sub-Type Values 5472 25.8. "OMNI Geo Coordinates Type Values" (New Registry) 5474 The OMNI Geo Coordinates sub-option (see: Section 12.2.7) contains an 5475 8-bit Type field, for which IANA is instructed to create and maintain 5476 a new registry entitled "OMNI Geo Coordinates Type Values". Initial 5477 values are given below (registration procedure is RFC required): 5479 Value Sub-Type name Reference 5480 ----- ------------- ---------- 5481 0 NULL [RFCXXXX] 5482 1-252 Unassigned [RFCXXXX] 5483 253-254 Reserved for Experimentation [RFCXXXX] 5484 255 Reserved by IANA [RFCXXXX] 5486 Figure 38: OMNI Geo Coordinates Type 5488 25.9. "OMNI Node Identification ID-Type Values" (New Registry) 5490 The OMNI Node Identification sub-option (see: Section 12.2.12) 5491 contains an 8-bit ID-Type field, for which IANA is instructed to 5492 create and maintain a new registry entitled "OMNI Node Identification 5493 ID-Type Values". Initial values are given below (registration 5494 procedure is RFC required): 5496 Value Sub-Type name Reference 5497 ----- ------------- ---------- 5498 0 UUID [RFCXXXX] 5499 1 HIT [RFCXXXX] 5500 2 HHIT [RFCXXXX] 5501 3 Network Access Identifier [RFCXXXX] 5502 4 FQDN [RFCXXXX] 5503 5 IPv6 Address [RFCXXXX] 5504 6-252 Unassigned [RFCXXXX] 5505 253-254 Reserved for Experimentation [RFCXXXX] 5506 255 Reserved by IANA [RFCXXXX] 5508 Figure 39: OMNI Node Identification ID-Type Values 5510 25.10. "OMNI Option Sub-Type Extension Values" (New Registry) 5512 The OMNI option defines an 8-bit Extension-Type field for Sub-Type 30 5513 (Sub-Type Extension), for which IANA is instructed to create and 5514 maintain a new registry entitled "OMNI Option Sub-Type Extension 5515 Values". Initial values are given below (registration procedure is 5516 RFC required): 5518 Value Sub-Type name Reference 5519 ----- ------------- ---------- 5520 0 RFC4380 UDP/IP Header Option [RFCXXXX] 5521 1 RFC6081 UDP/IP Trailer Option [RFCXXXX] 5522 2-252 Unassigned 5523 253-254 Reserved for Experimentation [RFCXXXX] 5524 255 Reserved by IANA [RFCXXXX] 5526 Figure 40: OMNI Option Sub-Type Extension Values 5528 25.11. "OMNI RFC4380 UDP/IP Header Option" (New Registry) 5530 The OMNI Sub-Type Extension "RFC4380 UDP/IP Header Option" defines an 5531 8-bit Header Type field, for which IANA is instructed to create and 5532 maintain a new registry entitled "OMNI RFC4380 UDP/IP Header Option". 5533 Initial registry values are given below (registration procedure is 5534 RFC required): 5536 Value Sub-Type name Reference 5537 ----- ------------- ---------- 5538 0 Origin Indication (IPv4) [RFC4380] 5539 1 Authentication Encapsulation [RFC4380] 5540 2 Origin Indication (IPv6) [RFCXXXX] 5541 3-252 Unassigned 5542 253-254 Reserved for Experimentation [RFCXXXX] 5543 255 Reserved by IANA [RFCXXXX] 5544 Figure 41: OMNI RFC4380 UDP/IP Header Option 5546 25.12. "OMNI RFC6081 UDP/IP Trailer Option" (New Registry) 5548 The OMNI Sub-Type Extension for "RFC6081 UDP/IP Trailer Option" 5549 defines an 8-bit Trailer Type field, for which IANA is instructed to 5550 create and maintain a new registry entitled "OMNI RFC6081 UDP/IP 5551 Trailer Option". Initial registry values are given below 5552 (registration procedure is RFC required): 5554 Value Sub-Type name Reference 5555 ----- ------------- ---------- 5556 0 Unassigned 5557 1 Nonce [RFC6081] 5558 2 Unassigned 5559 3 Alternate Address (IPv4) [RFC6081] 5560 4 Neighbor Discovery Option [RFC6081] 5561 5 Random Port [RFC6081] 5562 6 Alternate Address (IPv6) [RFCXXXX] 5563 7-252 Unassigned 5564 253-254 Reserved for Experimentation [RFCXXXX] 5565 255 Reserved by IANA [RFCXXXX] 5567 Figure 42: OMNI RFC6081 Trailer Option 5569 25.13. Additional Considerations 5571 The IANA has assigned the UDP port number "8060" for an earlier 5572 experimental version of AERO [RFC6706]. This document reclaims the 5573 UDP port number "8060" for 'aero' as the service port for UDP/IP 5574 encapsulation. (Note that, although [RFC6706] is not widely 5575 implemented or deployed, any messages coded to that specification can 5576 be easily distinguished and ignored since they include an invalid 5577 ICMPv6 message type number '0'.) The IANA is therefore instructed to 5578 update the reference for UDP port number "8060" from "RFC6706" to 5579 "RFCXXXX" (i.e., this document) while retaining the existing name 5580 'aero'. 5582 The IANA has assigned a 4 octet Private Enterprise Number (PEN) code 5583 "45282" in the "enterprise-numbers" registry. This document is the 5584 normative reference for using this code in DHCP Unique IDentifiers 5585 based on Enterprise Numbers ("DUID-EN for OMNI Interfaces") (see: 5586 Section 11). The IANA is therefore instructed to change the 5587 enterprise designation for PEN code "45282" from "LinkUp Networks" to 5588 "Overlay Multilink Network Interface (OMNI)". 5590 The IANA has assigned the ifType code "301 - omni - Overlay Multilink 5591 Network Interface (OMNI)" in accordance with Section 6 of [RFC8892]. 5592 The registration appears under the IANA "Structure of Management 5593 Information (SMI) Numbers (MIB Module Registrations) - Interface 5594 Types (ifType)" registry. 5596 No further IANA actions are required. 5598 26. Security Considerations 5600 Security considerations for IPv4 [RFC0791], IPv6 [RFC8200] and IPv6 5601 Neighbor Discovery [RFC4861] apply. OMNI interface IPv6 ND messages 5602 SHOULD include Nonce and Timestamp options [RFC3971] when transaction 5603 confirmation and/or time synchronization is needed. (Note however 5604 that when OAL encapsulation is used the (echoed) OAL Identification 5605 value can provide sufficient transaction confirmation.) 5607 OMNI interfaces configured over secured ANET/ENET interfaces inherit 5608 the physical and/or link-layer security properties (i.e., "protected 5609 spectrum") of the connected networks. OMNI interfaces configured 5610 over open INET interfaces can use symmetric securing services such as 5611 VPNs or can by some other means establish a direct link. When a VPN 5612 or direct link may be impractical or undesirable, however, the 5613 security services specified in [RFC7401], [RFC4380] or [RFC9000] can 5614 be employed. While the OMNI link protects control plane messaging, 5615 applications must still employ end-to-end transport- or higher-layer 5616 security services to protect the data plane. 5618 Strong network layer security for control plane messages and 5619 forwarding path integrity for data plane messages between Proxy/ 5620 Servers MUST be supported. In one example, the AERO service 5621 [I-D.templin-6man-aero] constructs an SRT spanning tree with Proxy/ 5622 Serves as leaf nodes and secures the spanning tree links with network 5623 layer security mechanisms such as IPsec [RFC4301] or WireGuard [WG]. 5624 Secured control plane messages are then constrained to travel only 5625 over the secured spanning tree paths and are therefore protected from 5626 attack or eavesdropping. Other control and data plane messages can 5627 travel over route optimized paths that do not strictly follow the 5628 secured spanning tree, therefore end-to-end sessions should employ 5629 transport- or higher-layer security services. Additionally, the OAL 5630 Identification value can provide a first level of data origin 5631 authentication to mitigate off-path spoofing in some environments. 5633 Identity-based key verification infrastructure services such as iPSK 5634 may be necessary for verifying the identities claimed by Clients. 5635 This requirement should be harmonized with the manner in which 5636 (H)HITs are attested in a given operational environment. 5638 Security considerations for specific access network interface types 5639 are covered under the corresponding IP-over-(foo) specification 5640 (e.g., [RFC2464], [RFC2492], etc.). 5642 Security considerations for IPv6 fragmentation and reassembly are 5643 discussed in Section 6.12. In environments where spoofing is 5644 considered a threat, OMNI nodes SHOULD employ Identification window 5645 synchronization and OAL destinations SHOULD configure an (end-system- 5646 based) firewall. 5648 27. Implementation Status 5650 AERO/OMNI Release-3.2 was tagged on March 30, 2021, and is undergoing 5651 internal testing. Additional internal releases expected within the 5652 coming months, with first public release expected end of 1H2021. 5654 Many AERO/OMNI functions are implemented and undergoing final 5655 integration. OAL fragmentation/reassembly buffer management code has 5656 been cleared for public release. 5658 28. Document Updates 5660 This document does not itself update other RFCs, but suggests that 5661 the following could be updated through future IETF initiatives: 5663 * [RFC1191] 5665 * [RFC2675] 5667 * [RFC4291] 5669 * [RFC4443] 5671 * [RFC8201] 5673 Updates can be through, e.g., standards action, the errata process, 5674 etc. as appropriate. 5676 29. Acknowledgements 5678 The first version of this document was prepared per the consensus 5679 decision at the 7th Conference of the International Civil Aviation 5680 Organization (ICAO) Working Group-I Mobility Subgroup on March 22, 5681 2019. Consensus to take the document forward to the IETF was reached 5682 at the 9th Conference of the Mobility Subgroup on November 22, 2019. 5683 Attendees and contributors included: Guray Acar, Danny Bharj, 5684 Francois D'Humieres, Pavel Drasil, Nikos Fistas, Giovanni Garofolo, 5685 Bernhard Haindl, Vaughn Maiolla, Tom McParland, Victor Moreno, Madhu 5686 Niraula, Brent Phillips, Liviu Popescu, Jacky Pouzet, Aloke Roy, Greg 5687 Saccone, Robert Segers, Michal Skorepa, Michel Solery, Stephane 5688 Tamalet, Fred Templin, Jean-Marc Vacher, Bela Varkonyi, Tony Whyman, 5689 Fryderyk Wrobel and Dongsong Zeng. 5691 The following individuals are acknowledged for their useful comments: 5692 Amanda Baber, Stuart Card, Donald Eastlake, Adrian Farrel, Michael 5693 Matyas, Robert Moskowitz, Madhu Niraula, Greg Saccone, Stephane 5694 Tamalet, Eliot Lear, Eduard Vasilenko, Eric Vyncke. Pavel Drasil, 5695 Zdenek Jaron and Michal Skorepa are especially recognized for their 5696 many helpful ideas and suggestions. Akash Agarwal, Madhuri Madhava 5697 Badgandi, Sean Dickson, Don Dillenburg, Joe Dudkowski, Vijayasarathy 5698 Rajagopalan, Ron Sackman, Bhargava Raman Sai Prakash and Katherine 5699 Tran are acknowledged for their hard work on the implementation and 5700 technical insights that led to improvements for the spec. 5702 Discussions on the IETF 6man and atn mailing lists during the fall of 5703 2020 suggested additional points to consider. The authors gratefully 5704 acknowledge the list members who contributed valuable insights 5705 through those discussions. Eric Vyncke and Erik Kline were the 5706 intarea ADs, while Bob Hinden and Ole Troan were the 6man WG chairs 5707 at the time the document was developed; they are all gratefully 5708 acknowledged for their many helpful insights. Many of the ideas in 5709 this document have further built on IETF experiences beginning in the 5710 1990s, with insights from colleagues including Ron Bonica, Brian 5711 Carpenter, Ralph Droms, Christian Huitema, Thomas Narten, Dave 5712 Thaler, Joe Touch, Pascal Thubert, and many others who deserve 5713 recognition. 5715 Early observations on IP fragmentation performance implications were 5716 noted in the 1986 Digital Equipment Corporation (DEC) "qe reset" 5717 investigation, where fragment bursts from NFS UDP traffic triggered 5718 hardware resets resulting in communication failures. Jeff Chase, 5719 Fred Glover and Chet Juzsczak of the Ultrix Engineering Group led the 5720 investigation, and determined that setting a smaller NFS mount block 5721 size reduced the amount of fragmentation and suppressed the resets. 5722 Early observations on L2 media MTU issues were noted in the 1988 DEC 5723 FDDI investigation, where Raj Jain, KK Ramakrishnan and Kathy Wilde 5724 represented architectural considerations for FDDI networking in 5725 general including FDDI/Ethernet bridging. Jeff Mogul (who led the 5726 IETF Path MTU Discovery working group) and other DEC colleagues who 5727 supported these early investigations are also acknowledged. 5729 Throughout the 1990's and into the 2000's, many colleagues supported 5730 and encouraged continuation of the work. Beginning with the DEC 5731 Project Sequoia effort at the University of California, Berkeley, 5732 then moving to the DEC research lab offices in Palo Alto CA, then to 5733 Sterling Software at the NASA Ames Research Center, then to SRI in 5734 Menlo Park, CA, then to Nokia in Mountain View, CA and finally to the 5735 Boeing Company in 2005 the work saw continuous advancement through 5736 the encouragement of many. Those who offered their support and 5737 encouragement are gratefully acknowledged. 5739 This work is aligned with the NASA Safe Autonomous Systems Operation 5740 (SASO) program under NASA contract number NNA16BD84C. 5742 This work is aligned with the FAA as per the SE2025 contract number 5743 DTFAWA-15-D-00030. 5745 This work is aligned with the Boeing Information Technology (BIT) 5746 Mobility Vision Lab (MVL) program. 5748 30. References 5750 30.1. Normative References 5752 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 5753 DOI 10.17487/RFC0768, August 1980, 5754 . 5756 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 5757 DOI 10.17487/RFC0791, September 1981, 5758 . 5760 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 5761 RFC 793, DOI 10.17487/RFC0793, September 1981, 5762 . 5764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5765 Requirement Levels", BCP 14, RFC 2119, 5766 DOI 10.17487/RFC2119, March 1997, 5767 . 5769 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 5770 "SEcure Neighbor Discovery (SEND)", RFC 3971, 5771 DOI 10.17487/RFC3971, March 2005, 5772 . 5774 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 5775 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 5776 November 2005, . 5778 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5779 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5780 . 5782 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5783 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5784 2006, . 5786 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 5787 Control Message Protocol (ICMPv6) for the Internet 5788 Protocol Version 6 (IPv6) Specification", STD 89, 5789 RFC 4443, DOI 10.17487/RFC4443, March 2006, 5790 . 5792 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 5793 ICMPv6, UDP, and TCP Headers", RFC 4727, 5794 DOI 10.17487/RFC4727, November 2006, 5795 . 5797 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5798 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5799 DOI 10.17487/RFC4861, September 2007, 5800 . 5802 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5803 Address Autoconfiguration", RFC 4862, 5804 DOI 10.17487/RFC4862, September 2007, 5805 . 5807 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 5808 "Traffic Selectors for Flow Bindings", RFC 6088, 5809 DOI 10.17487/RFC6088, January 2011, 5810 . 5812 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 5813 Hosts in a Multi-Prefix Network", RFC 8028, 5814 DOI 10.17487/RFC8028, November 2016, 5815 . 5817 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5818 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5819 May 2017, . 5821 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 5822 (IPv6) Specification", STD 86, RFC 8200, 5823 DOI 10.17487/RFC8200, July 2017, 5824 . 5826 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 5827 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 5828 DOI 10.17487/RFC8201, July 2017, 5829 . 5831 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 5832 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 5833 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 5834 RFC 8415, DOI 10.17487/RFC8415, November 2018, 5835 . 5837 30.2. Informative References 5839 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 5840 Interface for Civil Aviation, IETF Liaison Statement 5841 #1676, https://datatracker.ietf.org/liaison/1676/", 3 5842 March 2020. 5844 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 5845 Aeronautical Telecommunication Network (ATN) using 5846 Internet Protocol Suite (IPS) Standards and Protocol), 5847 Draft Edition 3 (work-in-progress)", 10 December 2020. 5849 [CKSUM] Stone, J., Greenwald, M., Partridge, C., and J. Hughes, 5850 "Performance of Checksums and CRC's Over Real Data, IEEE/ 5851 ACM Transactions on Networking, Vol. 6, No. 5", October 5852 1998. 5854 [CRC] Jain, R., "Error Characteristics of Fiber Distributed Data 5855 Interface (FDDI), IEEE Transactions on Communications", 5856 August 1990. 5858 [I-D.ietf-drip-rid] 5859 Moskowitz, R., Card, S. W., Wiethuechter, A., and A. 5860 Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft 5861 System Remote ID (UAS RID)", Work in Progress, Internet- 5862 Draft, draft-ietf-drip-rid-24, 24 April 2022, 5863 . 5866 [I-D.ietf-intarea-tunnels] 5867 Touch, J. and M. Townsley, "IP Tunnels in the Internet 5868 Architecture", Work in Progress, Internet-Draft, draft- 5869 ietf-intarea-tunnels-10, 12 September 2019, 5870 . 5873 [I-D.ietf-ipwave-vehicular-networking] 5874 Jeong, J. (., "IPv6 Wireless Access in Vehicular 5875 Environments (IPWAVE): Problem Statement and Use Cases", 5876 Work in Progress, Internet-Draft, draft-ietf-ipwave- 5877 vehicular-networking-28, 30 March 2022, 5878 . 5881 [I-D.templin-6man-aero] 5882 Templin, F. L., "Automatic Extended Route Optimization 5883 (AERO)", Work in Progress, Internet-Draft, draft-templin- 5884 6man-aero-45, 22 April 2022, 5885 . 5888 [I-D.templin-6man-fragrep] 5889 Templin, F. L., "IPv6 Fragment Retransmission and Path MTU 5890 Discovery Soft Errors", Work in Progress, Internet-Draft, 5891 draft-templin-6man-fragrep-07, 29 March 2022, 5892 . 5895 [I-D.templin-6man-lla-type] 5896 Templin, F. L., "The IPv6 Link-Local Address Type Field", 5897 Work in Progress, Internet-Draft, draft-templin-6man-lla- 5898 type-02, 23 November 2020, 5899 . 5902 [I-D.templin-intarea-parcels] 5903 Templin, F. L., "IP Parcels", Work in Progress, Internet- 5904 Draft, draft-templin-intarea-parcels-10, 29 March 2022, 5905 . 5908 [IPV4-GUA] Postel, J., "IPv4 Address Space Registry, 5909 https://www.iana.org/assignments/ipv4-address-space/ipv4- 5910 address-space.xhtml", 14 December 2020. 5912 [IPV6-GUA] Postel, J., "IPv6 Global Unicast Address Assignments, 5913 https://www.iana.org/assignments/ipv6-unicast-address- 5914 assignments/ipv6-unicast-address-assignments.xhtml", 14 5915 December 2020. 5917 [RFC1035] Mockapetris, P., "Domain names - implementation and 5918 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 5919 November 1987, . 5921 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 5922 Communication Layers", STD 3, RFC 1122, 5923 DOI 10.17487/RFC1122, October 1989, 5924 . 5926 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 5927 options", RFC 1146, DOI 10.17487/RFC1146, March 1990, 5928 . 5930 [RFC1149] Waitzman, D., "Standard for the transmission of IP 5931 datagrams on avian carriers", RFC 1149, 5932 DOI 10.17487/RFC1149, April 1990, 5933 . 5935 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 5936 DOI 10.17487/RFC1191, November 1990, 5937 . 5939 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", 5940 RFC 1256, DOI 10.17487/RFC1256, September 1991, 5941 . 5943 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 5944 RFC 2131, DOI 10.17487/RFC2131, March 1997, 5945 . 5947 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 5948 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 5949 . 5951 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 5952 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 5953 December 1998, . 5955 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 5956 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 5957 . 5959 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 5960 RFC 2675, DOI 10.17487/RFC2675, August 1999, 5961 . 5963 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 5964 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 5965 . 5967 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 5968 RFC 2923, DOI 10.17487/RFC2923, September 2000, 5969 . 5971 [RFC2983] Black, D., "Differentiated Services and Tunnels", 5972 RFC 2983, DOI 10.17487/RFC2983, October 2000, 5973 . 5975 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 5976 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 5977 2001, . 5979 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 5980 RFC 3068, DOI 10.17487/RFC3068, June 2001, 5981 . 5983 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 5984 of Explicit Congestion Notification (ECN) to IP", 5985 RFC 3168, DOI 10.17487/RFC3168, September 2001, 5986 . 5988 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 5989 DOI 10.17487/RFC3330, September 2002, 5990 . 5992 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 5993 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 5994 DOI 10.17487/RFC3366, August 2002, 5995 . 5997 [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology 5998 Dissemination Based on Reverse-Path Forwarding (TBRPF)", 5999 RFC 3684, DOI 10.17487/RFC3684, February 2004, 6000 . 6002 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 6003 Considered Useful", BCP 82, RFC 3692, 6004 DOI 10.17487/RFC3692, January 2004, 6005 . 6007 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 6008 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 6009 DOI 10.17487/RFC3810, June 2004, 6010 . 6012 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 6013 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 6014 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 6015 RFC 3819, DOI 10.17487/RFC3819, July 2004, 6016 . 6018 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 6019 Unique IDentifier (UUID) URN Namespace", RFC 4122, 6020 DOI 10.17487/RFC4122, July 2005, 6021 . 6023 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6024 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6025 December 2005, . 6027 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 6028 Network Address Translations (NATs)", RFC 4380, 6029 DOI 10.17487/RFC4380, February 2006, 6030 . 6032 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 6033 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 6034 2006, . 6036 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6037 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6038 . 6040 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6041 "Considerations for Internet Group Management Protocol 6042 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6043 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6044 . 6046 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 6047 "Internet Group Management Protocol (IGMP) / Multicast 6048 Listener Discovery (MLD)-Based Multicast Forwarding 6049 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 6050 August 2006, . 6052 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 6053 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 6054 . 6056 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 6057 Errors at High Data Rates", RFC 4963, 6058 DOI 10.17487/RFC4963, July 2007, 6059 . 6061 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 6062 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 6063 RFC 5213, DOI 10.17487/RFC5213, August 2008, 6064 . 6066 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 6067 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 6068 DOI 10.17487/RFC5214, March 2008, 6069 . 6071 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 6072 the Protocol Field", BCP 37, RFC 5237, 6073 DOI 10.17487/RFC5237, February 2008, 6074 . 6076 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 6077 RFC 5558, DOI 10.17487/RFC5558, February 2010, 6078 . 6080 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 6081 Extension of OSPF Using Connected Dominating Set (CDS) 6082 Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, 6083 . 6085 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 6086 Version 3 for IPv4 and IPv6", RFC 5798, 6087 DOI 10.17487/RFC5798, March 2010, 6088 . 6090 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6091 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6092 . 6094 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 6095 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 6096 September 2010, . 6098 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 6099 Model: The Relationship between Links and Subnet 6100 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 6101 . 6103 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 6104 DOI 10.17487/RFC6081, January 2011, 6105 . 6107 [RFC6214] Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for 6108 IPv6", RFC 6214, DOI 10.17487/RFC6214, April 2011, 6109 . 6111 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 6112 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 6113 DOI 10.17487/RFC6221, May 2011, 6114 . 6116 [RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 6117 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, 6118 RFC 1644, and RFC 1693 to Historic Status", RFC 6247, 6119 DOI 10.17487/RFC6247, May 2011, 6120 . 6122 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 6123 for Equal Cost Multipath Routing and Link Aggregation in 6124 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 6125 . 6127 [RFC6543] Gundavelli, S., "Reserved IPv6 Interface Identifier for 6128 Proxy Mobile IPv6", RFC 6543, DOI 10.17487/RFC6543, May 6129 2012, . 6131 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 6132 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 6133 . 6135 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 6136 UDP Checksums for Tunneled Packets", RFC 6935, 6137 DOI 10.17487/RFC6935, April 2013, 6138 . 6140 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 6141 for the Use of IPv6 UDP Datagrams with Zero Checksums", 6142 RFC 6936, DOI 10.17487/RFC6936, April 2013, 6143 . 6145 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 6146 with IPv6 Neighbor Discovery", RFC 6980, 6147 DOI 10.17487/RFC6980, August 2013, 6148 . 6150 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 6151 IETF Protocol and Documentation Usage for IEEE 802 6152 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 6153 October 2013, . 6155 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 6156 "Architectural Considerations of IP Anycast", RFC 7094, 6157 DOI 10.17487/RFC7094, January 2014, 6158 . 6160 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 6161 Interface Identifiers with IPv6 Stateless Address 6162 Autoconfiguration (SLAAC)", RFC 7217, 6163 DOI 10.17487/RFC7217, April 2014, 6164 . 6166 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 6167 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 6168 RFC 7401, DOI 10.17487/RFC7401, April 2015, 6169 . 6171 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 6172 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 6173 Boundary in IPv6 Addressing", RFC 7421, 6174 DOI 10.17487/RFC7421, January 2015, 6175 . 6177 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 6178 DOI 10.17487/RFC7542, May 2015, 6179 . 6181 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 6182 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 6183 February 2016, . 6185 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6186 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6187 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6188 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6189 2016, . 6191 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 6192 Support for IP Hosts with Multi-Access Support", RFC 7847, 6193 DOI 10.17487/RFC7847, May 2016, 6194 . 6196 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6197 Writing an IANA Considerations Section in RFCs", BCP 26, 6198 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6199 . 6201 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 6202 Decraene, B., Litkowski, S., and R. Shakir, "Segment 6203 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 6204 July 2018, . 6206 [RFC8726] Farrel, A., "How Requests for IANA Action Will Be Handled 6207 on the Independent Stream", RFC 8726, 6208 DOI 10.17487/RFC8726, November 2020, 6209 . 6211 [RFC8892] Thaler, D. and D. Romascanu, "Guidelines and Registration 6212 Procedures for Interface Types and Tunnel Types", 6213 RFC 8892, DOI 10.17487/RFC8892, August 2020, 6214 . 6216 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 6217 Völker, "Packetization Layer Path MTU Discovery for 6218 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 6219 September 2020, . 6221 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 6222 and F. Gont, "IP Fragmentation Considered Fragile", 6223 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 6224 . 6226 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 6227 "Temporary Address Extensions for Stateless Address 6228 Autoconfiguration in IPv6", RFC 8981, 6229 DOI 10.17487/RFC8981, February 2021, 6230 . 6232 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 6233 Multiplexed and Secure Transport", RFC 9000, 6234 DOI 10.17487/RFC9000, May 2021, 6235 . 6237 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 6238 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 6239 . 6241 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 6242 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 6243 May 2021, . 6245 [WG] WireGuard, W., "WireGuard, Fast, Modern, Secure VPN 6246 Tunnel, https://wireguard.com/", 7 March 2022. 6248 Appendix A. OAL Checksum Algorithm 6250 The OAL Checksum Algorithm adopts the 8-bit Fletcher algorithm 6251 specified in Appendix I of [RFC1146] as also analyzed in [CKSUM]. 6252 [RFC6247] declared [RFC1146] historic for the reason that the 6253 algorithms had never seen widespread use with TCP, however this 6254 document adopts the 8-bit Fletcher algorithm for a different purpose. 6255 Quoting from Appendix I of [RFC1146], the OAL Checksum Algorithm 6256 proceeds as follows: 6258 "The 8-bit Fletcher Checksum Algorithm is calculated over a 6259 sequence of data octets (call them D[1] through D[N]) by 6260 maintaining 2 unsigned 1's-complement 8-bit accumulators A and B 6261 whose contents are initially zero, and performing the following 6262 loop where i ranges from 1 to N: 6264 A := A + D[i] 6266 B := B + A 6268 It can be shown that at the end of the loop A will contain the 6269 8-bit 1's complement sum of all octets in the datagram, and that B 6270 will contain (N)D[1] + (N-1)D[2] + ... + D[N]." 6272 To calculate the OAL checksum, the above algorithm is applied over 6273 the N-octet concatenation of the OAL pseudo-header and the 6274 encapsulated IP packet or packets. Specifically, the algorithm is 6275 first applied over the 40 octets of the OAL pseudo-header as data 6276 octets D[1] through D[40], then continues over the entire length of 6277 the original IP packet(s) as data octets D[41] through D[N]. 6279 Appendix B. IPv6 ND Message Authentication and Integrity 6281 OMNI interface IPv6 ND messages are subject to authentication and 6282 integrity checks at multiple levels. When an OMNI interface sends an 6283 IPv6 ND message over an INET interface, it includes an authentication 6284 sub-option with a valid signature but does not include an IPv6 ND 6285 message checksum. The OMNI interface that receives the message 6286 verifies the OAL checksum as a first-level integrity check, then 6287 verifies the authentication signature (while ignoring the IPv6 ND 6288 message checksum) to ensure IPv6 ND message authentication and 6289 integrity. 6291 When an OMNI interface sends an IPv6 ND message over an underlay 6292 interface connected to a secured network, it omits the authentication 6293 sub-option but instead calculates/includes an IPv6 ND message 6294 checksum. The OMNI interface that receives the message applies any 6295 lower-layer authentication and integrity checks, then verifies both 6296 the OAL checksum and the IPv6 ND message checksum. (Note that 6297 optimized implementations can verify both the OAL and IPv6 ND message 6298 checksums in a single pass over the data.) When an OMNI interface 6299 sends IPv6 ND messages to a synchronized neighbor, it includes an 6300 authentication sub-option only if authentication is necessary; 6301 otherwise, it calculates/includes the IPv6 ND message checksum. 6303 When the OMNI interface calculates the authentication signature or 6304 IPv6 ND message checksum, it performs the calculation beginning with 6305 a pseudo-header of the IPv6 ND message header and extends over all 6306 following OAL packet data. In particular, for OAL super-packets any 6307 additional original IP packets included beyond the end of the IPv6 ND 6308 message are simply considered as extensions of the IPv6 ND message 6309 for the purpose of the calculation. 6311 OAL destinations discard carrier packets with unacceptable 6312 Identifications and submit the encapsulated fragments in all others 6313 for reassembly. The reassembly algorithm rejects any fragments with 6314 unacceptable sizes, offsets, etc. and reassembles all others. 6315 Following reassembly, the OAL checksum algorithm provides an 6316 integrity assurance layer that compliments any integrity checks 6317 already applied by lower layers as well as a first-pass filter for 6318 any checks that will be applied later by upper layers. 6320 Appendix C. VDL Mode 2 Considerations 6322 ICAO Doc 9776 is the "Technical Manual for VHF Data Link Mode 2" 6323 (VDLM2) that specifies an essential radio frequency data link service 6324 for aircraft and ground stations in worldwide civil aviation air 6325 traffic management. The VDLM2 link type is "multicast capable" 6326 [RFC4861], but with considerable differences from common multicast 6327 links such as Ethernet and IEEE 802.11. 6329 First, the VDLM2 link data rate is only 31.5Kbps - multiple orders of 6330 magnitude less than most modern wireless networking gear. Second, 6331 due to the low available link bandwidth only VDLM2 ground stations 6332 (i.e., and not aircraft) are permitted to send broadcasts, and even 6333 so only as compact layer 2 "beacons". Third, aircraft employ the 6334 services of ground stations by performing unicast RS/RA exchanges 6335 upon receipt of beacons instead of listening for multicast RA 6336 messages and/or sending multicast RS messages. 6338 This beacon-oriented unicast RS/RA approach is necessary to conserve 6339 the already-scarce available link bandwidth. Moreover, since the 6340 numbers of beaconing ground stations operating within a given spatial 6341 range must be kept as sparse as possible, it would not be feasible to 6342 have different classes of ground stations within the same region 6343 observing different protocols. It is therefore highly desirable that 6344 all ground stations observe a common language of RS/RA as specified 6345 in this document. 6347 Note that links of this nature may benefit from compression 6348 techniques that reduce the bandwidth necessary for conveying the same 6349 amount of data. The IETF lpwan working group is considering possible 6350 alternatives: [https://datatracker.ietf.org/wg/lpwan/documents]. 6352 Appendix D. Client-Proxy/Server Isolation Through Link-Layer Address 6353 Mapping 6355 Per [RFC4861], IPv6 ND messages may be sent to either a multicast or 6356 unicast link-scoped IPv6 destination address. However, IPv6 ND 6357 messaging should be coordinated between the Client and Proxy/Server 6358 only without invoking other nodes on the underlay network. This 6359 implies that Client-Proxy/Server control messaging should be isolated 6360 and not overheard by other nodes on the link. 6362 To support Client-Proxy/Server isolation on some links, Proxy/Servers 6363 can maintain an OMNI-specific unicast link-layer address ("MSADDR"). 6364 For Ethernet-compatible links, this specification reserves one 6365 Ethernet unicast address TBD5 (see: IANA Considerations). For non- 6366 Ethernet statically-addressed links MSADDR is reserved per the 6367 assigned numbers authority for the link-layer addressing space. For 6368 still other links, MSADDR may be dynamically discovered through other 6369 means, e.g., link-layer beacons. 6371 Clients map the L3 addresses of all IPv6 ND messages they send (i.e., 6372 both multicast and unicast) to MSADDR instead of to an ordinary 6373 unicast or multicast link-layer address. In this way, all of the 6374 Client's IPv6 ND messages will be received by Proxy/Servers that are 6375 configured to accept packets destined to MSADDR. Note that multiple 6376 Proxy/Servers on the link could be configured to accept packets 6377 destined to MSADDR, e.g., as a basis for supporting redundancy. 6379 Therefore, Proxy/Servers must accept and process packets destined to 6380 MSADDR, while all other devices must not process packets destined to 6381 MSADDR. This model has well-established operational experience in 6382 Proxy Mobile IPv6 (PMIP) [RFC5213][RFC6543]. 6384 Appendix E. Change Log 6386 << RFC Editor - remove prior to publication >> 6388 Differences from earlier versions: 6390 * Submit for RFC publication. 6392 Author's Address 6394 Fred L. Templin (editor) 6395 The Boeing Company 6396 P.O. Box 3707 6397 Seattle, WA 98124 6398 United States of America 6399 Email: fltemplin@acm.org