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