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