| < draft-templin-6man-omni-60.txt | draft-templin-6man-omni-61.txt > | |||
|---|---|---|---|---|
| Network Working Group F. L. Templin, Ed. | Network Working Group F. L. Templin, Ed. | |||
| Internet-Draft The Boeing Company | Internet-Draft The Boeing Company | |||
| Intended status: Informational 22 April 2022 | Intended status: Informational 25 April 2022 | |||
| Expires: 24 October 2022 | Expires: 27 October 2022 | |||
| Transmission of IP Packets over Overlay Multilink Network (OMNI) | Transmission of IP Packets over Overlay Multilink Network (OMNI) | |||
| Interfaces | Interfaces | |||
| draft-templin-6man-omni-60 | draft-templin-6man-omni-61 | |||
| Abstract | Abstract | |||
| Mobile nodes (e.g., aircraft of various configurations, terrestrial | Mobile nodes (e.g., aircraft of various configurations, terrestrial | |||
| vehicles, seagoing vessels, space systems, enterprise wireless | vehicles, seagoing vessels, space systems, enterprise wireless | |||
| devices, pedestrians with cell phones, etc.) communicate with | devices, pedestrians with cell phones, etc.) communicate with | |||
| networked correspondents over multiple access network data links and | networked correspondents over multiple access network data links and | |||
| configure mobile routers to connect end user networks. A multilink | configure mobile routers to connect end user networks. A multilink | |||
| virtual interface specification is presented that enables mobile | virtual interface specification is presented that enables mobile | |||
| nodes to coordinate with a network-based mobility service and/or with | nodes to coordinate with a network-based mobility service and/or with | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 24 October 2022. | This Internet-Draft will expire on 27 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 45 ¶ | skipping to change at page 2, line 45 ¶ | |||
| 6.12. OAL Fragmentation Security Implications . . . . . . . . . 51 | 6.12. OAL Fragmentation Security Implications . . . . . . . . . 51 | |||
| 6.13. OMNI Hosts . . . . . . . . . . . . . . . . . . . . . . . 52 | 6.13. OMNI Hosts . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
| 6.14. IP Parcels . . . . . . . . . . . . . . . . . . . . . . . 55 | 6.14. IP Parcels . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
| 7. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 58 | 7. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 58 | |||
| 8. Link-Local Addresses (LLAs) . . . . . . . . . . . . . . . . . 59 | 8. Link-Local Addresses (LLAs) . . . . . . . . . . . . . . . . . 59 | |||
| 9. Unique-Local Addresses (ULAs) . . . . . . . . . . . . . . . . 60 | 9. Unique-Local Addresses (ULAs) . . . . . . . . . . . . . . . . 60 | |||
| 10. Global Unicast Addresses (GUAs) . . . . . . . . . . . . . . . 63 | 10. Global Unicast Addresses (GUAs) . . . . . . . . . . . . . . . 63 | |||
| 11. Node Identification . . . . . . . . . . . . . . . . . . . . . 64 | 11. Node Identification . . . . . . . . . . . . . . . . . . . . . 64 | |||
| 12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 65 | 12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 65 | |||
| 12.1. The OMNI Option . . . . . . . . . . . . . . . . . . . . 66 | 12.1. The OMNI Option . . . . . . . . . . . . . . . . . . . . 66 | |||
| 12.2. OMNI Sub-Options . . . . . . . . . . . . . . . . . . . . 67 | 12.2. OMNI Sub-Options . . . . . . . . . . . . . . . . . . . . 66 | |||
| 12.2.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 69 | 12.2.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 69 | |||
| 12.2.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 69 | 12.2.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 69 | |||
| 12.2.3. Neighbor Coordination . . . . . . . . . . . . . . . 70 | 12.2.3. Neighbor Coordination . . . . . . . . . . . . . . . 70 | |||
| 12.2.4. Interface Attributes . . . . . . . . . . . . . . . . 72 | 12.2.4. Interface Attributes . . . . . . . . . . . . . . . . 72 | |||
| 12.2.5. Multilink Forwarding Parameters . . . . . . . . . . 75 | 12.2.5. Multilink Forwarding Parameters . . . . . . . . . . 75 | |||
| 12.2.6. Traffic Selector . . . . . . . . . . . . . . . . . . 80 | 12.2.6. Traffic Selector . . . . . . . . . . . . . . . . . . 80 | |||
| 12.2.7. Geo Coordinates . . . . . . . . . . . . . . . . . . 81 | 12.2.7. Geo Coordinates . . . . . . . . . . . . . . . . . . 81 | |||
| 12.2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | 12.2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | |||
| Message . . . . . . . . . . . . . . . . . . . . . . . 82 | Message . . . . . . . . . . . . . . . . . . . . . . . 82 | |||
| 12.2.9. Host Identity Protocol (HIP) Message . . . . . . . . 83 | 12.2.9. Host Identity Protocol (HIP) Message . . . . . . . . 83 | |||
| skipping to change at page 3, line 24 ¶ | skipping to change at page 3, line 24 ¶ | |||
| 13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 94 | 13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 94 | |||
| 14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 95 | 14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 95 | |||
| 14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 95 | 14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 95 | |||
| 14.2. Client-Proxy/Server Loop Prevention . . . . . . . . . . 96 | 14.2. Client-Proxy/Server Loop Prevention . . . . . . . . . . 96 | |||
| 15. Router Discovery and Prefix Registration . . . . . . . . . . 96 | 15. Router Discovery and Prefix Registration . . . . . . . . . . 96 | |||
| 15.1. Window Synchronization . . . . . . . . . . . . . . . . . 105 | 15.1. Window Synchronization . . . . . . . . . . . . . . . . . 105 | |||
| 15.2. Router Discovery in IP Multihop and IPv4-Only | 15.2. Router Discovery in IP Multihop and IPv4-Only | |||
| Networks . . . . . . . . . . . . . . . . . . . . . . . . 106 | Networks . . . . . . . . . . . . . . . . . . . . . . . . 106 | |||
| 15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 108 | 15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 108 | |||
| 15.4. OMNI Link Extension . . . . . . . . . . . . . . . . . . 110 | 15.4. OMNI Link Extension . . . . . . . . . . . . . . . . . . 110 | |||
| 16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 111 | 16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 110 | |||
| 17. Proxy/Server Resilience . . . . . . . . . . . . . . . . . . . 111 | 17. Proxy/Server Resilience . . . . . . . . . . . . . . . . . . . 111 | |||
| 18. Detecting and Responding to Proxy/Server Failures . . . . . . 111 | 18. Detecting and Responding to Proxy/Server Failures . . . . . . 111 | |||
| 19. Transition Considerations . . . . . . . . . . . . . . . . . . 112 | 19. Transition Considerations . . . . . . . . . . . . . . . . . . 112 | |||
| 20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 113 | 20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 113 | |||
| 21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 115 | 21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 115 | |||
| 22. (H)HITs and Temporary ULA (TMP-ULA)s . . . . . . . . . . . . 116 | 22. (H)HITs and Temporary ULA (TLA)s . . . . . . . . . . . . . . 116 | |||
| 23. Address Selection . . . . . . . . . . . . . . . . . . . . . . 117 | 23. Address Selection . . . . . . . . . . . . . . . . . . . . . . 117 | |||
| 24. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 118 | 24. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 118 | |||
| 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118 | 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118 | |||
| 25.1. "Protocol Numbers" Registry . . . . . . . . . . . . . . 118 | 25.1. "Protocol Numbers" Registry . . . . . . . . . . . . . . 118 | |||
| 25.2. "IEEE 802 Numbers" Registry . . . . . . . . . . . . . . 118 | 25.2. "IEEE 802 Numbers" Registry . . . . . . . . . . . . . . 118 | |||
| 25.3. "IPv4 Special-Purpose Address" Registry . . . . . . . . 118 | 25.3. "IPv4 Special-Purpose Address" Registry . . . . . . . . 118 | |||
| 25.4. "IPv6 Neighbor Discovery Option Formats" Registry . . . 119 | 25.4. "IPv6 Neighbor Discovery Option Formats" Registry . . . 119 | |||
| 25.5. "Ethernet Numbers" Registry . . . . . . . . . . . . . . 119 | 25.5. "Ethernet Numbers" Registry . . . . . . . . . . . . . . 119 | |||
| 25.6. "ICMPv6 Code Fields: Type 2 - Packet Too Big" | 25.6. "ICMPv6 Code Fields: Type 2 - Packet Too Big" | |||
| Registry . . . . . . . . . . . . . . . . . . . . . . . 119 | Registry . . . . . . . . . . . . . . . . . . . . . . . 119 | |||
| skipping to change at page 12, line 35 ¶ | skipping to change at page 12, line 35 ¶ | |||
| encapsulation headers and forwards them into the next segment. | encapsulation headers and forwards them into the next segment. | |||
| OMNI Option | OMNI Option | |||
| an IPv6 Neighbor Discovery option providing multilink parameters | an IPv6 Neighbor Discovery option providing multilink parameters | |||
| for the OMNI interface as specified in Section 12. | for the OMNI interface as specified in Section 12. | |||
| Interface Identifier (IID) | Interface Identifier (IID) | |||
| the least significant 64 bits of an IPv6 address, as specified in | the least significant 64 bits of an IPv6 address, as specified in | |||
| the IPv6 addressing architecture [RFC4291]. | the IPv6 addressing architecture [RFC4291]. | |||
| Mobile Network Prefix Link Local Address (MNP-LLA) | Link Local Address (LLA) | |||
| an IPv6 Link Local Address that embeds the most significant 64 | an IPv6 address beginning with fe80::/64 per the IPv6 addressing | |||
| bits of an MNP in the IID portion of fe80::/64, as specified in | architecture [RFC4291] and with either a 64-bit MNP (LLA-MNP) or a | |||
| 56-bit random value (LLA-RND) encoded in the IID as specified in | ||||
| Section 8. | Section 8. | |||
| Mobile Network Prefix Unique Local Address (MNP-ULA) | Unique Local Address (ULA) | |||
| an IPv6 Unique-Local Address derived from an MNP-LLA as discussed | an IPv6 address beginning with fd00::/8 followed by a 40-bit | |||
| in Section 9. | Global ID followed by a 16-bit Subnet ID per [RFC4193] and with | |||
| either a 64-bit MNP (ULA-MNP) or a 56-bit random value (ULA-RND) | ||||
| Mobile Network Prefix eXtended Local Address (MNP-XLA) | encoded in the IID as specified in Section 9. (Note that | |||
| an IPv6 Unique-Local Address that embeds the most significant 64 | [RFC4193] specifies a second form of ULAs based on the prefix | |||
| bits of an MNP in the IID portion of fd00::/64, as specified in | fc00::/8, which are referred to as "ULA-C" throughout this | |||
| Section 9. (Note that MNP-XLAs can be formed from MNP-LLAs simply | document to distinguish them from the ULAs defined here.) | |||
| by inverting bits 7 and 8 of 'fe80' to form 'fd00'.) | ||||
| Random Link Local Address (RND-LLA) | ||||
| an IPv6 Link Local Address that embeds a 56-bit randomly- | ||||
| initialized value in the lower 56 bits of the IID portion of | ||||
| fe80::/72, as specified in Section 8. | ||||
| Random Unique Local Address (RND-ULA) | ||||
| an IPv6 Unique-Local Address derived from a RND-LLA as discussed | ||||
| in Section 9. | ||||
| Temporary Unique Local Address (TMP-ULA) | Temporary Local Address (TLA) | |||
| an IPv6 Unique-Local Address configured by a Client that embeds a | a ULA beginning with fd00::/16 followed by a 48-bit randomly- | |||
| 48-bit randomly-initialized value following the prefix fd00:/16, | initialized value followed by an MNP-based (TLA-MNP) or random | |||
| followed by an MNP-based or random IID as specified in Section 9. | (TLA-RND) IID as specified in Section 9. Clients use TLAs to | |||
| Clients use TMP-ULAs (and/or MNP-XLAs) to bootstrap | bootstrap autoconfiguration in the presence of OMNI link | |||
| autoconfiguration in the presence of OMNI link infrastructure, | infrastructure or for sustained communications in the absence of | |||
| while continued use of TMP-ULAs may be necessary in the absence of | ||||
| infrastructure. (Note that in some environments Clients can | infrastructure. (Note that in some environments Clients can | |||
| instead use a (Hierarchical) Host Identity Tag ((H)HIT) instead of | instead use a (Hierarchical) Host Identity Tag ((H)HIT) instead of | |||
| a TMP-ULA - see: Section 22.) | a TLA - see: Section 22.) | |||
| eXtended Local Address (XLA) | ||||
| a TLA beginning with fd00::/64 followed by an MNP-based (XLA-MNP) | ||||
| or random (XLA-RND) IID as specified in Section 9. An XLA is | ||||
| simply a TLA with an all-0 48-bit value following fd00::/16, and | ||||
| can be used to supply a "wildcard match" for IPv6 ND cache | ||||
| entries, a routing table entry for the OMNI link routing system, | ||||
| etc. (Note that XLAs can also be statelessly formed from LLAs | ||||
| (and vice-versa) simply by inverting prefix bits 7 and 8.) | ||||
| Multilink | Multilink | |||
| a Client OMNI interface's manner of managing multiple diverse *NET | a Client OMNI interface's manner of managing multiple diverse *NET | |||
| underlay interfaces as a single logical unit. The OMNI interface | underlay interfaces as a single logical unit. The OMNI interface | |||
| provides a single unified interface to upper layers, while | provides a single unified interface to upper layers, while | |||
| underlay interface selections are performed on a per-packet basis | underlay interface selections are performed on a per-packet basis | |||
| considering traffic selectors such as DSCP, flow label, | considering traffic selectors such as DSCP, flow label, | |||
| application policy, signal quality, cost, etc. Multilink | application policy, signal quality, cost, etc. Multilink | |||
| selections are coordinated in both the outbound and inbound | selections are coordinated in both the outbound and inbound | |||
| directions based on source/target underlay interface pairs. | directions based on source/target underlay interface pairs. | |||
| skipping to change at page 18, line 47 ¶ | skipping to change at page 18, line 47 ¶ | |||
| +------+-------+--+-------+----+-------+-------------+-------+ v | +------+-------+--+-------+----+-------+-------------+-------+ v | |||
| | Underlay Interfaces | | | Underlay Interfaces | | |||
| +------------------------------------------------------------+ | +------------------------------------------------------------+ | |||
| Figure 2: OMNI Interface Layering | Figure 2: OMNI Interface Layering | |||
| The OMNI/OAL model gives rise to a number of opportunities: | The OMNI/OAL model gives rise to a number of opportunities: | |||
| * Clients receive MNPs from the MS, and coordinate with the MS | * Clients receive MNPs from the MS, and coordinate with the MS | |||
| through IPv6 ND message exchanges with Proxy/Servers. Clients use | through IPv6 ND message exchanges with Proxy/Servers. Clients use | |||
| the MNP to construct a unique Link-Local Address (MNP-LLA) through | the MNP to construct a unique Link-Local Address (LLA-MNP) through | |||
| the algorithmic derivation specified in Section 8 and assign the | the algorithmic derivation specified in Section 8 and assign the | |||
| LLA to the OMNI interface. Since MNP-LLAs are uniquely derived | LLA to the OMNI interface. Since LLA-MNPs are uniquely derived | |||
| from an MNP, no Duplicate Address Detection (DAD) or Multicast | from an MNP, no Duplicate Address Detection (DAD) or Multicast | |||
| Listener Discovery (MLD) messaging is necessary. | Listener Discovery (MLD) messaging is necessary. | |||
| * since Temporary ULAs (TMP-ULAs) are statistically unique, they can | * since Temporary ULAs with random IIDs (TLA-RNDs) are statistically | |||
| be used without DAD until an MNP is obtained. | unique, they can be used without DAD until an MNP is obtained. | |||
| * underlay interfaces on the same L2 link segment as a Proxy/Server | * underlay interfaces on the same L2 link segment as a Proxy/Server | |||
| do not require any L3 addresses (i.e., not even link-local) in | do not require any L3 addresses (i.e., not even link-local) in | |||
| environments where communications are coordinated entirely over | environments where communications are coordinated entirely over | |||
| the OMNI interface. | the OMNI interface. | |||
| * as underlay interface properties change (e.g., link quality, cost, | * as underlay interface properties change (e.g., link quality, cost, | |||
| availability, etc.), any active interface can be used to update | availability, etc.), any active interface can be used to update | |||
| the profiles of multiple additional interfaces in a single | the profiles of multiple additional interfaces in a single | |||
| message. This allows for timely adaptation and service continuity | message. This allows for timely adaptation and service continuity | |||
| skipping to change at page 20, line 7 ¶ | skipping to change at page 20, line 7 ¶ | |||
| * L3 sees the OMNI interface as a point of connection to the OMNI | * L3 sees the OMNI interface as a point of connection to the OMNI | |||
| link; if there are multiple OMNI links, L3 will see multiple OMNI | link; if there are multiple OMNI links, L3 will see multiple OMNI | |||
| interfaces. | interfaces. | |||
| * Multiple independent OMNI interfaces can be used for increased | * Multiple independent OMNI interfaces can be used for increased | |||
| fault tolerance through Safety-Based Multilink (SBM), with | fault tolerance through Safety-Based Multilink (SBM), with | |||
| Performance-Based Multilink (PBM) applied within each interface. | Performance-Based Multilink (PBM) applied within each interface. | |||
| * Multiple independent OMNI links can be joined together into a | * Multiple independent OMNI links can be joined together into a | |||
| single link without requiring renumbering of infrastructure | single link without requiring renumbering of infrastructure | |||
| elements, since the RND-ULAs assigned to the different links will | elements, since the ULAs assigned to the different links will be | |||
| be mutually exclusive. | mutually exclusive. | |||
| * the OMNI/OAL model supports transmission of a new form of IP | * the OMNI/OAL model supports transmission of a new form of IP | |||
| packets known as "IP Parcels" that improve performance and | packets known as "IP Parcels" that improve performance and | |||
| efficiency for both upper layer protocols and networked paths. | efficiency for both upper layer protocols and networked paths. | |||
| Note that even when the OMNI virtual interface is present, | Note that even when the OMNI virtual interface is present, | |||
| applications can still access underlay interfaces either through the | applications can still access underlay interfaces either through the | |||
| network protocol stack using an Internet socket or directly using a | network protocol stack using an Internet socket or directly using a | |||
| raw socket. This allows for intra-network (or point-to-point) | raw socket. This allows for intra-network (or point-to-point) | |||
| communications without invoking the OMNI interface and/or OAL. For | communications without invoking the OMNI interface and/or OAL. For | |||
| skipping to change at page 25, line 41 ¶ | skipping to change at page 25, line 41 ¶ | |||
| Notification (ECN)" [RFC3168] values in the original packet's IP | Notification (ECN)" [RFC3168] values in the original packet's IP | |||
| header into the corresponding fields in the OAL header, then sets the | header into the corresponding fields in the OAL header, then sets the | |||
| OAL header "Flow Label" as specified in [RFC6438]. The OAL source | OAL header "Flow Label" as specified in [RFC6438]. The OAL source | |||
| finally sets the OAL header IPv6 Payload Length to the length of the | finally sets the OAL header IPv6 Payload Length to the length of the | |||
| original IP packet and sets Hop Limit to a value that MUST NOT be | original IP packet and sets Hop Limit to a value that MUST NOT be | |||
| larger than 63 yet is still sufficiently large to enable loop-free | larger than 63 yet is still sufficiently large to enable loop-free | |||
| forwarding over multiple concatenated OMNI link intermediate hops. | forwarding over multiple concatenated OMNI link intermediate hops. | |||
| The OAL next selects OAL packet source and destination addresses. | The OAL next selects OAL packet source and destination addresses. | |||
| Client OMNI interfaces set the OAL source address to a Unique Local | Client OMNI interfaces set the OAL source address to a Unique Local | |||
| Address (ULA) based on the Mobile Network Prefix (MNP-ULA), while | Address (ULA) based on the Mobile Network Prefix (ULA-MNP). When a | |||
| Proxy/Server OMNI interfaces set the source address to a Random ULA | Client OMNI interface does not (yet) have a ULA prefix and/or an MNP | |||
| (RND-ULA) (see: Section 9). When a Client OMNI interface does not | suffix, it can instead use a Temporary ULA (TLA) (or a (Hierarchical) | |||
| (yet) have a ULA prefix and/or an MNP suffix, it can use a Temporary | Host Identity Tag ((H)HIT - see: Section 22) as an OAL address. | |||
| ULA (TMP-ULA) (see: Section 22) (or a (Hierarchical) Host Identity | Finally, when the Client needs to express its MNP outside the context | |||
| Tag ((H)HIT) instead (see: Section 22) as OAL addresses. (In | of a specific ULA prefix, it can use an eXtended ULA (XLA). Proxy/ | |||
| addition to RND-ULAs, Proxy/Servers also process packets with anycast | Server OMNI interfaces instead set the source address to a Random ULA | |||
| and/or multicast OAL addresses.) | (ULA-RND) (see: Section 9), but also process packets with anycast | |||
| and/or multicast OAL addresses that they are configured to | ||||
| recognize.) | ||||
| The OAL source next selects a 32-bit OAL packet Identification value | The OAL source next selects a 32-bit OAL packet Identification value | |||
| as specified in Section 6.6. The OAL then calculates a 2-octet OAL | as specified in Section 6.6. The OAL then calculates a 2-octet OAL | |||
| checksum using the algorithm specified in Appendix A. The OAL source | checksum using the algorithm specified in Appendix A. The OAL source | |||
| calculates the checksum over the OAL packet beginning with a pseudo- | calculates the checksum over the OAL packet beginning with a pseudo- | |||
| header of the OAL header similar to that found in Section 8.1 of | header of the OAL header similar to that found in Section 8.1 of | |||
| [RFC8200], then extending over the entire length of the original IP | [RFC8200], then extending over the entire length of the original IP | |||
| packet. The OAL pseudo-header is formed as shown in Figure 4: | packet. The OAL pseudo-header is formed as shown in Figure 4: | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| skipping to change at page 57, line 20 ¶ | skipping to change at page 57, line 20 ¶ | |||
| with the final containing any remaining segments. The OAL source | with the final containing any remaining segments. The OAL source | |||
| then appends an identical IP header plus extensions to each sub- | then appends an identical IP header plus extensions to each sub- | |||
| parcel while resetting M and N in each according to the above | parcel while resetting M and N in each according to the above | |||
| equations with J set to 3 and K set to L for each non-final sub- | equations with J set to 3 and K set to L for each non-final sub- | |||
| parcel and with J set to the remaining number of segments for the | parcel and with J set to the remaining number of segments for the | |||
| final sub-parcel. | final sub-parcel. | |||
| The OAL source next performs encapsulation on each sub-parcel with | The OAL source next performs encapsulation on each sub-parcel with | |||
| destination set to the next hop address. If the next hop is reached | destination set to the next hop address. If the next hop is reached | |||
| via an ANET/INET interface, the OAL source inserts an OAL header the | via an ANET/INET interface, the OAL source inserts an OAL header the | |||
| same as discussed in Section 6.1 and sets the destination to the MNP- | same as discussed in Section 6.1 and sets the destination to the ULA- | |||
| ULA of the target Client. If the next hop is reached via an ENET | MNP of the target Client. If the next hop is reached via an ENET | |||
| interface, the OAL source instead inserts an IP header of the | interface, the OAL source instead inserts an IP header of the | |||
| appropriate protocol version for the underlay ENET (i.e., even if the | appropriate protocol version for the underlay ENET (i.e., even if the | |||
| encapsulation header is IPv4) and sets the destination to the ENET IP | encapsulation header is IPv4) and sets the destination to the ENET IP | |||
| address of the next hop. The OAL source inserts the encapsulation | address of the next hop. The OAL source inserts the encapsulation | |||
| header even if no actual fragmentation is needed and/or even if the | header even if no actual fragmentation is needed and/or even if the | |||
| Jumbo Payload option is present. | Jumbo Payload option is present. | |||
| The OAL source next assigns an Identification number that is | The OAL source next assigns an Identification number that is | |||
| monotonically-incremented for each consecutive sub-parcel, calculates | monotonically-incremented for each consecutive sub-parcel, calculates | |||
| and appends the OAL checksum, then performs IPv6 fragmentation over | and appends the OAL checksum, then performs IPv6 fragmentation over | |||
| skipping to change at page 59, line 24 ¶ | skipping to change at page 59, line 24 ¶ | |||
| all interfaces, and that routers use their LLAs as the source address | all interfaces, and that routers use their LLAs as the source address | |||
| for RA and Redirect messages. OMNI interfaces honor the first | for RA and Redirect messages. OMNI interfaces honor the first | |||
| requirement, but do not honor the second since the OMNI link could | requirement, but do not honor the second since the OMNI link could | |||
| consist of the concatenation of multiple links with diverse ULA | consist of the concatenation of multiple links with diverse ULA | |||
| prefixes (see Section 9) but for which multiple nodes might configure | prefixes (see Section 9) but for which multiple nodes might configure | |||
| identical interface identifiers (IIDs). OMNI interface LLAs are | identical interface identifiers (IIDs). OMNI interface LLAs are | |||
| therefore considered only as context for IID formation as discussed | therefore considered only as context for IID formation as discussed | |||
| below and have no other operational role. | below and have no other operational role. | |||
| OMNI interfaces assign IPv6 LLAs through pre-service administrative | OMNI interfaces assign IPv6 LLAs through pre-service administrative | |||
| actions. Clients assign "MNP-LLAs" with IIDs that embed the Client's | actions. Clients assign "LLA-MNPs" with IIDs that embed the Client's | |||
| unique MNP, while Proxy/Servers assign "RND-LLAs" that include a | unique MNP, while Proxy/Servers assign "LLA-RNDs" that include a | |||
| randomly-generated IIDs generated as specified in [RFC7217]. LLAs | randomly-generated IIDs generated as specified in [RFC7217]. LLAs | |||
| are configured as follows: | are configured as follows: | |||
| * IPv6 MNP-LLAs encode the most-significant 64 bits of an MNP within | * IPv6 LLA-MNPs encode the most-significant 64 bits of an MNP within | |||
| the least-significant 64 bits of the IPv6 link-local prefix | the least-significant 64 bits of the IPv6 link-local prefix | |||
| fe80::/64, i.e., in the IID portion of the LLA. The LLA prefix | fe80::/64, i.e., in the IID portion of the LLA. The LLA prefix | |||
| length is determined by adding 64 to the MNP prefix length. e.g., | length is determined by adding 64 to the MNP prefix length. e.g., | |||
| for the MNP 2001:db8:1000:2000::/56 the corresponding MNP-LLA | for the MNP 2001:db8:1000:2000::/56 the corresponding LLA-MNP | |||
| prefix is fe80::2001:db8:1000:2000/120. (The base MNP-LLA for | prefix is fe80::2001:db8:1000:2000/120. (The base LLA-MNP for | |||
| each "/N" prefix sets the final 128-N bits to 0, but all MNP-LLAs | each "/N" prefix sets the final 128-N bits to 0, but all LLA-MNPs | |||
| that match the prefix are also accepted.) Non-MNP IPv6 prefix- | that match the prefix are also accepted.) Non-MNP IPv6 prefix- | |||
| based LLAs are also represented the same as for MNP-LLAs, but | based LLAs are also represented the same as for LLA-MNPs, but | |||
| include a GUA prefix that is not properly covered by the MSP. | include a GUA prefix that is not properly covered by the MSP. | |||
| * IPv4-Compatible MNP-LLAs are constructed as fe80::{IPv4-Prefix}, | * IPv4-Compatible LLA-MNPs are constructed as fe80::{IPv4-Prefix}, | |||
| i.e., the IID consists of 32 '0' bits followed by a 32 bit IPv4 | i.e., the IID consists of 32 '0' bits followed by a 32 bit IPv4 | |||
| address/prefix, which may be either public or private in | address/prefix, which may be either public or private in | |||
| correspondence with the network layer addressing plan. The prefix | correspondence with the network layer addressing plan. The | |||
| length for the IPv4-Compatible MNP-LLA is determined by adding 96 | IPv4-Compatible LLA-MNP prefix length is determined by adding 96 | |||
| to the IPv4 prefix length. For example, the IPv4-Compatible MNP- | to the IPv4 prefix length. For example, the IPv4-Compatible LLA- | |||
| LLA for 192.0.2.0/24 is fe80::192.0.2.0/120, also written as | MNP for 192.0.2.0/24 is fe80::192.0.2.0/120, also written as | |||
| fe80::c000:0200/120. (The base MNP-LLA for each "/N" prefix sets | fe80::c000:0200/120. (The base LLA-MNP for each "/N" prefix sets | |||
| the final 128-N bits to 0, but all MNP-LLAs that match the prefix | the final 128-N bits to 0, but all LLA-MNPs that match the prefix | |||
| are also accepted.) Non-MNP IPv4 prefix-based LLAs are also | are also accepted.) Non-MNP IPv4 prefix-based LLAs are also | |||
| represented the same as for MNP-LLAs, but include a GUA prefix | represented the same as for LLA-MNPs, but include a GUA prefix | |||
| that is not properly covered by the MSP. | that is not properly covered by the MSP. | |||
| * RND-LLAs are randomly-generated and assigned to Proxy/Servers and | * LLA-RNDs are randomly-generated and assigned to Proxy/Servers and | |||
| other SRT infrastructure elements. They may also be used by | other SRT infrastructure elements. They may also be assigned by | |||
| Clients to bootstrap the MNP delegation process. The upper 72 | Clients to support the MNP delegation process. The upper 72 bits | |||
| bits of the RND-LLA encode the prefix fe80::/72, and the lower 56 | of the LLA-RND encode the prefix fe80::/72, and the lower 56 bits | |||
| bits include a randomly-generated candidate pseudo-random value | include a randomly-generated candidate pseudo-random value | |||
| configured as specified in [RFC7217]; if the most significant 24 | configured as specified in [RFC7217]; if the most significant 24 | |||
| bits of the 56 bit candidate encodes the value '0', the node | bits of the 56 bit candidate encodes the value '0', the node | |||
| generates a new candidate to obtain one with a different most | generates a new candidate to obtain one with a different most | |||
| significant 24 bits. | significant 24 bits to avoid overlap with IPv4-Compatible LLAs. | |||
| * The address fe80::/128 (i.e., the LLA /64 prefix followed by an | * The address fe80::/128 (i.e., the LLA /64 prefix followed by an | |||
| all-zero IID) is considered the LLA Subnet Router Anycast address | all-zero IID) is considered the LLA Subnet Router Anycast address | |||
| Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no | Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no | |||
| MNPs can be allocated from that block ensuring that there is no | MNPs can be allocated from that block ensuring that there is no | |||
| possibility for overlap between the different MNP- and RND-LLA | possibility for overlap between the different MNP and RND LLA | |||
| constructs discussed above. | constructs discussed above. | |||
| Since MNP-LLAs are based on the distribution of administratively | Since LLA-MNPs are based on the distribution of administratively | |||
| assured unique MNPs, and since RND-LLAs are assumed unique through | assured unique MNPs, and since LLA-RNDs are assumed unique through | |||
| pseudo-random assignment, OMNI interfaces set the autoconfiguration | pseudo-random assignment, OMNI interfaces set the autoconfiguration | |||
| variable DupAddrDetectTransmits to 0 [RFC4862]. | variable DupAddrDetectTransmits to 0 [RFC4862]. | |||
| Note: If future protocol extensions relax the 64-bit boundary in IPv6 | Note: If future protocol extensions relax the 64-bit boundary in IPv6 | |||
| addressing, the additional prefix bits of an MNP could be encoded in | addressing, the additional prefix bits of an MNP could be encoded in | |||
| bits 16 through 63 of the MNP-LLA. (The most-significant 64 bits | bits 16 through 63 of the LLA-MNP. (The most-significant 64 bits | |||
| would therefore still be in bits 64-127, and the remaining bits would | would therefore still be in bits 64-127, and the remaining bits would | |||
| appear in bits 16 through 48.) However, this would interfere with | appear in bits 16 through 48.) However, this would interfere with | |||
| the relationship between OMNI LLAs and ULAs (see: Section 9) and | the relationship between OMNI LLAs and ULAs (see: Section 9) and | |||
| render many OMNI functions inoperable. The analysis provided in | render many OMNI functions inoperable. The analysis provided in | |||
| [RFC7421] furthermore suggests that the 64-bit boundary will remain | [RFC7421] furthermore suggests that the 64-bit boundary will remain | |||
| in the IPv6 architecture for the foreseeable future. | in the IPv6 architecture for the foreseeable future. | |||
| 9. Unique-Local Addresses (ULAs) | 9. Unique-Local Addresses (ULAs) | |||
| OMNI links use IPv6 Unique-Local Addresses (ULAs) as the source and | OMNI links use IPv6 Unique-Local Addresses (ULAs) as the source and | |||
| destination addresses in both IPv6 ND messages and OAL packet IPv6 | destination addresses in both IPv6 ND messages and OAL packet IPv6 | |||
| encapsulation headers. ULAs are routable only within the scope of an | encapsulation headers. ULAs are routable only within the scope of an | |||
| OMNI link, and are derived from the IPv6 Unique Local Address prefix | OMNI link, and are derived from the IPv6 Unique Local Address prefix | |||
| fc00::/7 followed by the L bit set to 1, i.e., as fd00::/8. When the | fd00::/8 (i.e., the prefix fc00::/7 followed by the L bit set to 1). | |||
| first 16 bits of the ULA encode the value fd00::/16, the address is | When the first 16 bits of the ULA encode the value fd00::/16, the | |||
| considered as either an MNP eXtended ULA (MNP-XLA) or a Temporary ULA | address is considered as either a Temporary ULA (TLA) or an eXtended | |||
| (TMP-ULA) - see below. For all other ULAs, the 56 bits following | ULA (XLA) - see below. For all other ULAs, the 56 bits following | |||
| fd00::/8 encode a 40-bit Global ID followed by a 16-bit Subnet ID as | fd00::/8 encode a 40-bit Global ID followed by a 16-bit Subnet ID as | |||
| specified in Section 3 of [RFC4193]. All OMNI link ULA types finally | specified in Section 3 of [RFC4193]. All OMNI link ULA types finally | |||
| include a 64-bit value in the IID portion of the address ULA::/64 as | include a 64-bit value in the IID portion of the address ULA::/64 as | |||
| specified below. | specified below. | |||
| For RND-ULAs, a node selects a 40-bit Global ID for the OMNI link | When a node configures a ULA for OMNI, it selects a 40-bit Global ID | |||
| initialized to a candidate pseudo-random value as specified in | for the OMNI link initialized to a candidate pseudo-random value as | |||
| Section 3 of [RFC4193]; if the most significant 8 bits of the | specified in Section 3 of [RFC4193]; if the most significant 8 bits | |||
| candidate encodes the value '0', the node selects a new candidate | of the candidate encodes the value '0', the node selects a new | |||
| until it obtains one with a different most significant 8 bits. All | candidate until it obtains one with a different most significant 8 | |||
| nodes on the same OMNI link use the same Global ID, and statistical | bits. All nodes on the same OMNI link use the same Global ID, and | |||
| uniqueness of the pseudo-random Global ID provides a unique OMNI link | statistical uniqueness of the pseudo-random Global ID provides a | |||
| identifier allowing different links to be joined together in the | unique OMNI link identifier allowing different links to be joined | |||
| future without requiring renumbering. | together in the future without requiring renumbering. | |||
| Next, for each logical segment of the same OMNI link the node selects | Next, for each logical segment of the same OMNI link the node selects | |||
| a 16-bit Subnet ID value between 0x0000 and 0xffff. Nodes on the | a 16-bit Subnet ID value between 0x0000 and 0xffff. Nodes on the | |||
| same logical segment configure the same Subnet ID, but nodes on | same logical segment configure the same Subnet ID, but nodes on | |||
| different segments of the same OMNI link can still exchange IPv6 ND | different segments of the same OMNI link can still exchange IPv6 ND | |||
| messages as single-hop neighbors even if they configure different | messages as single-hop neighbors even if they configure different | |||
| Subnet IDs. When a node moves to a different OMNI link segment, it | Subnet IDs. When a node moves to a different OMNI link segment, it | |||
| resets the Global ID and Subnet ID value according to the new segment | resets the Global ID and Subnet ID value according to the new segment | |||
| but need not change the IID. | but need not change the IID. | |||
| ULAs and their associated prefix lengths are configured in | ULAs and their associated prefix lengths are configured in | |||
| correspondence with LLAs through stateless prefix translation where | correspondence with LLAs through stateless prefix translation where | |||
| "MNP-ULAs" simply copy the IIDs of their corresponding MNP-LLAs and | "ULA-MNPs" simply copy the IIDs of their corresponding LLA-MNPs and | |||
| "RND-ULAs" simply copy the IIDs of their corresponding RND-LLAs. For | "ULA-RNDs" simply copy the IIDs of their corresponding LLA-RNDs. For | |||
| example, for the OMNI link ULA prefix fd{Global}:{Subnet}::/64: | example, for the OMNI link ULA prefix fd{Global}:{Subnet}::/64: | |||
| * the MNP-ULA corresponding to the MNP-LLA fe80::2001:db8:1:2 with a | * the ULA-MNP corresponding to the LLA-MNP fe80::2001:db8:1:2 with a | |||
| 56-bit MNP length is simply fd{Global}:{Subnet}:2001:db8:1:2/120 | 56-bit MNP length is simply fd{Global}:{Subnet}:2001:db8:1:2/120 | |||
| (where, the ULA prefix length becomes 64 plus the IPv6 MNP | (where, the ULA prefix length becomes 64 plus the IPv6 MNP | |||
| length). | length). | |||
| * the MNP-ULA corresponding to fe80::192.0.2.0 with a 28-bit MNP | * the ULA-MNP corresponding to fe80::192.0.2.0 with a 28-bit MNP | |||
| length is simply fd{Global}:{Subnet}::192.0.2.0/124 (where, the | length is simply fd{Global}:{Subnet}::192.0.2.0/124 (where, the | |||
| ULA prefix length is 64 plus 32 plus the IPv4 MNP length). | ULA prefix length becomes 96 plus the IPv4 MNP length). | |||
| * the RND-ULA corresponding to fe80::1234:5678:9abc is simply | * the ULA-RND corresponding to fe80::0012:3456:789a:bcde is simply | |||
| fd{Global}:{Subnet}::1234:5678:9abc. | fd{Global}:{Subnet}::0012:3456:789a:bcde/128. | |||
| * the Subnet Router Anycast ULA corresponding to fe80::/128 is | * the Subnet Router Anycast ULA corresponding to fe80::/128 is | |||
| simply fd{Global}:{Subnet}::/128. | simply fd{Global}:{Subnet}::/128. | |||
| The ULA presents an IPv6 address format that is routable within the | The ULA presents an IPv6 address format that is routable within the | |||
| OMNI link routing system and can be used to convey link-scoped (i.e., | OMNI link routing system and can be used to convey link-scoped (i.e., | |||
| single-hop) IPv6 ND messages across multiple hops through IPv6 | single-hop) IPv6 ND messages across multiple hops through IPv6 | |||
| encapsulation [RFC2473]. The OMNI link extends across one or more | encapsulation [RFC2473]. The OMNI link extends across one or more | |||
| underlying Internetworks to include all Proxy/Servers and other | underlying Internetworks to include all Proxy/Servers and other | |||
| service nodes. All Clients are also considered to be connected to | service nodes. All Clients are also considered to be connected to | |||
| the OMNI link, however unnecessary encapsulations are omitted | the OMNI link, however unnecessary encapsulations are omitted | |||
| whenever possible to conserve bandwidth (see: Section 14). | whenever possible to conserve bandwidth (see: Section 14). | |||
| OMNI nodes use MNP-XLAs as "default" ULAs for representing MNPs in | Clients can configure TLAs when they have no other ULA addresses by | |||
| routing protocols. MNP-XLAs use the ULA prefix fd00::/64 and include | setting the ULA prefix to fd00::/16 followed by a 48-bit randomly- | |||
| a 64-bit MNP in the IID the same as for MNP-{LLA,ULA}s. (Note that | generated number followed by a random or MNP-based IID as discussed | |||
| MNP-XLAs can be formed from MNP-LLAs simply by inverting bits 7 and 8 | in Section 8. XLAs are a special-case TLA that use the prefix | |||
| of 'fe80' to form 'fd00'.) Clients use MNP-XLAs when they already | fd00::/64. (Note that XLAs can also be formed from LLAs simply by | |||
| know their MNP but need to express it outside the context of a | inverting bits 7 and 8 of 'fe80' to form 'fd00'.) | |||
| specific ULA prefix, and Proxy/Servers advertise MNP-XLAs into the | ||||
| routing system instead of advertising fully-qualified MNP-ULAs and/or | ||||
| non-routable MNP-LLAs. | ||||
| Clients can also configure TMP-ULAs when they have no other ULA | OMNI nodes use XLA-MNPs as "default" ULAs for representing MNPs in | |||
| addresses by setting the ULA prefix to fd00::/16 followed by a 48-bit | the OMNI link routing system. Clients use {TLA,XLA}-MNPs when they | |||
| randomly-generated number followed by a random or MNP-based IID. | already know their MNP but need to express it outside the context of | |||
| Clients form TMP-ULAs when they do not already know the ULA prefix | a specific ULA prefix, and Proxy/Servers advertise XLA-MNPs into the | |||
| for the OMNI link segment by first generating a candidate 48 bit | OMNI link routing system instead of advertising fully-qualified | |||
| random value other than all-zeros, then appending an IID as discussed | {TLA,ULA}-MNPs and/or non-routable LLA-MNPs. | |||
| in Section 8. | ||||
| MNP-XLAs and TMP-ULAs provide initial "bootstrapping" addresses while | {TLAs,XLAs} provide initial "bootstrapping" addresses while the | |||
| the Client is in the process of procuring an MNP and/or identifying | Client is in the process of procuring an MNP and/or identifying the | |||
| the ULA prefix for the OMNI link segment; TMP-ULAs are not advertised | ULA prefix for the OMNI link segment; TLAs are not advertised into | |||
| into the OMNI link routing system but can be used for Client-to- | the OMNI link routing system but can be used for Client-to-Client | |||
| Client communications within a single *NET when no OMNI link | communications within a single {A,I,E}NET when no OMNI link | |||
| infrastructure is present. Within each individual *NET, random TMP- | infrastructure is present. Within each individual {A,I,E}NET, TLAs | |||
| ULAs employ optimistic DAD principles [RFC4429] since they are | employ optimistic DAD principles [RFC4429] since they are | |||
| statistically unique. | statistically unique. | |||
| Each OMNI link may be subdivided into SRT segments that often | Each OMNI link may be subdivided into SRT segments that often | |||
| correspond to different administrative domains or physical | correspond to different administrative domains or physical | |||
| partitions. Each SRT segment is identified by a different Subnet ID | partitions. Each SRT segment is identified by a different Subnet ID | |||
| within the same ULA ::/48 prefix. Multiple distinct OMNI links with | within the same ULA ::/48 prefix. Multiple distinct OMNI links with | |||
| different ULA ::/48 prefixes can also be joined together into a | different ULA ::/48 prefixes can also be joined together into a | |||
| single unified OMNI link through simple interconnection without | single unified OMNI link through simple interconnection without | |||
| requiring renumbering. In that case, the (larger) unified OMNI link | requiring renumbering. In that case, the (larger) unified OMNI link | |||
| routing system may carry multiple distinct ULA prefixes. | routing system may carry multiple distinct ULA prefixes. | |||
| OMNI nodes can use Segment Routing [RFC8402] to support efficient | OMNI nodes can use Segment Routing [RFC8402] to support efficient | |||
| forwarding to destinations located in other OMNI link segments. A | forwarding to destinations located in other OMNI link segments. A | |||
| full discussion of Segment Routing over the OMNI link appears in | full discussion of Segment Routing over the OMNI link appears in | |||
| [I-D.templin-6man-aero]. | [I-D.templin-6man-aero]. | |||
| Note: IPv6 ULAs taken from the prefix fc00::/7 followed by the L bit | Note: IPv6 ULAs taken from the prefix fc00::/7 followed by the L bit | |||
| set to 0 (i.e., as fc00::/8) are never used for OMNI OAL addressing, | set to 0 (i.e., as fc00::/8) are never used for OMNI OAL addressing, | |||
| however the range could be used for MSP/MNP addressing under certain | however the range could be used for MSP/MNP addressing under certain | |||
| limiting conditions (see: Section 10). | limiting conditions (see: Section 10). When used within the context | |||
| of OMNI, ULAs based on the prefix fc00::/8 are referred to as "ULA- | ||||
| C's". | ||||
| Note: When they appear in routing tables, RND-ULAs always use prefix | Note: When they appear in the OMNI link routing table, ULA-RNDs | |||
| lengths between /48 and /64 while MNP-ULAs and MNP-XLAs always use | always use prefix lengths between /48 and /64 (or, /128) while XLA- | |||
| prefix lengths between /65 and /128. RND-ULAs can also appear in | MNPs always use prefix lengths between /65 and /128. {TLA,ULA}-MNPs | |||
| routing tables as prefixes of length /128. | and {TLA,XLA}-RNDs should never appear in the OMNI link routing | |||
| table, but may appear in {A,I,E}NET routing tables. | ||||
| 10. Global Unicast Addresses (GUAs) | 10. Global Unicast Addresses (GUAs) | |||
| OMNI domains use IP Global Unicast Address (GUA) prefixes [RFC4291] | OMNI domains use IP Global Unicast Address (GUA) prefixes [RFC4291] | |||
| as Mobility Service Prefixes (MSPs) from which Mobile Network | as Mobility Service Prefixes (MSPs) from which Mobile Network | |||
| Prefixes (MNP) are delegated to Clients. Fixed correspondent node | Prefixes (MNP) are delegated to Clients. Fixed correspondent node | |||
| networks reachable from the OMNI link are represented by non-MNP GUA | networks reachable from the OMNI link are represented by non-MNP GUA | |||
| prefixes that are not derived from the MSP, but are treated in all | prefixes that are not derived from the MSP, but are treated in all | |||
| other ways the same as for MNPs. | other ways the same as for MNPs. | |||
| skipping to change at page 64, line 45 ¶ | skipping to change at page 64, line 45 ¶ | |||
| specified in [RFC7401], while Hierarchical HITs (HHITs) | specified in [RFC7401], while Hierarchical HITs (HHITs) | |||
| [I-D.ietf-drip-rid] may be more appropriate for certain domains such | [I-D.ietf-drip-rid] may be more appropriate for certain domains such | |||
| as the Unmanned (Air) Traffic Management (UTM) service for Unmanned | as the Unmanned (Air) Traffic Management (UTM) service for Unmanned | |||
| Air Systems (UAS). Another example is the Universally Unique | Air Systems (UAS). Another example is the Universally Unique | |||
| IDentifier (UUID) [RFC4122] which can be self-generated by a node | IDentifier (UUID) [RFC4122] which can be self-generated by a node | |||
| without supporting infrastructure with very low probability of | without supporting infrastructure with very low probability of | |||
| collision. | collision. | |||
| When a Client is truly outside the context of any infrastructure, it | When a Client is truly outside the context of any infrastructure, it | |||
| may have no MNP information at all. In that case, the Client can use | may have no MNP information at all. In that case, the Client can use | |||
| a TMP-ULA or (H)HIT as an IPv6 source/destination address for | a TLA or (H)HIT as an IPv6 source/destination address for sustained | |||
| sustained communications in Vehicle-to-Vehicle (V2V) and (multihop) | communications in Vehicle-to-Vehicle (V2V) and (multihop) Vehicle-to- | |||
| Vehicle-to-Infrastructure (V2I) scenarios. The Client can also | Infrastructure (V2I) scenarios. The Client can also propagate the | |||
| propagate the ULA/(H)HIT into the multihop routing tables of | ULA/(H)HIT into the multihop routing tables of (collective) Mobile/ | |||
| (collective) Mobile/Vehicular Ad-hoc Networks (MANETs/VANETs) using | Vehicular Ad-hoc Networks (MANETs/VANETs) using only the vehicles | |||
| only the vehicles themselves as communications relays. | themselves as communications relays. | |||
| When a Client connects via a protected-spectrum ANET, an alternate | When a Client connects via a protected-spectrum ANET, an alternate | |||
| form of node identification (e.g., MAC address, serial number, | form of node identification (e.g., MAC address, serial number, | |||
| airframe identification value, VIN, etc.) embedded in an LLA/ULA may | airframe identification value, VIN, etc.) embedded in a ULA may be | |||
| be sufficient. The Client can then include OMNI "Node | sufficient. The Client can then include OMNI "Node Identification" | |||
| Identification" sub-options (see: Section 12.2.12) in IPv6 ND | sub-options (see: Section 12.2.12) in IPv6 ND messages should the | |||
| messages should the need to transmit identification information over | need to transmit identification information over the network arise. | |||
| the network arise. | ||||
| 12. Address Mapping - Unicast | 12. Address Mapping - Unicast | |||
| OMNI interfaces maintain a neighbor cache for tracking per-neighbor | OMNI interfaces maintain a neighbor cache for tracking per-neighbor | |||
| state and use the link-local address format specified in Section 8. | state and use the link-local address format specified in Section 8. | |||
| IPv6 Neighbor Discovery (ND) [RFC4861] messages sent over OMNI | IPv6 Neighbor Discovery (ND) [RFC4861] messages sent over OMNI | |||
| interfaces without encapsulation observe the native underlay | interfaces without encapsulation observe the native underlay | |||
| interface Source/Target Link-Layer Address Option (S/TLLAO) format | interface Source/Target Link-Layer Address Option (S/TLLAO) format | |||
| (e.g., for Ethernet the S/TLLAO is specified in [RFC2464]). IPv6 ND | (e.g., for Ethernet the S/TLLAO is specified in [RFC2464]). IPv6 ND | |||
| messages sent over OMNI interfaces using encapsulation do not include | messages sent over OMNI interfaces using encapsulation do not include | |||
| skipping to change at page 97, line 13 ¶ | skipping to change at page 97, line 13 ¶ | |||
| include a valid IPv6 ND message checksum (see: Section 12 and | include a valid IPv6 ND message checksum (see: Section 12 and | |||
| Appendix B). FHS and Hub Proxy/Server RS/RA message exchanges over | Appendix B). FHS and Hub Proxy/Server RS/RA message exchanges over | |||
| the SRT secured spanning tree instead always include the checksum and | the SRT secured spanning tree instead always include the checksum and | |||
| omit the authentication signature. Clients and Proxy/Servers use the | omit the authentication signature. Clients and Proxy/Servers use the | |||
| information included in RS/RA messages to establish NCE state and | information included in RS/RA messages to establish NCE state and | |||
| OMNI link autoconfiguration information as discussed in this section. | OMNI link autoconfiguration information as discussed in this section. | |||
| For each underlay interface, the Client sends RS messages with OMNI | For each underlay interface, the Client sends RS messages with OMNI | |||
| options to coordinate with a (potentially) different FHS Proxy/Server | options to coordinate with a (potentially) different FHS Proxy/Server | |||
| for each interface but with a single Hub Proxy/Server. All Proxy/ | for each interface but with a single Hub Proxy/Server. All Proxy/ | |||
| Servers are identified by their RND-ULAs and accept carrier packets | Servers are identified by their ULA-RNDs and accept carrier packets | |||
| addressed to their anycast/unicast L2 INADDRs; the Hub Proxy/Server | addressed to their anycast/unicast L2 INADDRs; the Hub Proxy/Server | |||
| may be chosen among any of the Client's FHS Proxy/Servers or may be | may be chosen among any of the Client's FHS Proxy/Servers or may be | |||
| any other Proxy/Server for the OMNI link. Example ULA/INADDR | any other Proxy/Server for the OMNI link. Example ULA/INADDR | |||
| discovery methods are given in [RFC5214] and include data link login | discovery methods are given in [RFC5214] and include data link login | |||
| parameters, name service lookups, static configuration, a static | parameters, name service lookups, static configuration, a static | |||
| "hosts" file, etc. In the absence of other information, the Client | "hosts" file, etc. In the absence of other information, the Client | |||
| can resolve the DNS Fully-Qualified Domain Name (FQDN) | can resolve the DNS Fully-Qualified Domain Name (FQDN) | |||
| "linkupnetworks.[domainname]" where "linkupnetworks" is a constant | "linkupnetworks.[domainname]" where "linkupnetworks" is a constant | |||
| text string and "[domainname]" is a DNS suffix for the OMNI link | text string and "[domainname]" is a DNS suffix for the OMNI link | |||
| (e.g., "example.com"). The name resolution will retain a set of DNS | (e.g., "example.com"). The name resolution will retain a set of DNS | |||
| resource records with the addresses of Proxy/Servers for the domain. | resource records with the addresses of Proxy/Servers for the domain. | |||
| Each FHS Proxy/Server configures an RND-ULA based on a /64 ULA prefix | Each FHS Proxy/Server configures an ULA-RND based on a /64 ULA prefix | |||
| for the link/segment with randomly-generated Global ID to assure | for the link/segment with randomly-generated Global ID to assure | |||
| global uniqueness then administratively assigned to FHS Proxy/Servers | global uniqueness then administratively assigned to FHS Proxy/Servers | |||
| for the link to assure global consistency. The Client can then | for the link to assure global consistency. The Client can then | |||
| configure MNP-ULAs derived from the 64-bit ULA prefix assigned to a | configure ULA-MNPs derived from the 64-bit ULA prefix assigned to a | |||
| FHS Proxy/Server for each underlay interface. The FHS Proxy/Servers | FHS Proxy/Server for each underlay interface. The FHS Proxy/Servers | |||
| discovered over multiple of the Client's underlay interfaces may | discovered over multiple of the Client's underlay interfaces may | |||
| configure the same or different ULA prefixes, and the Client's MNP- | configure the same or different ULA prefixes, and the Client's ULA- | |||
| ULA for each underlay interface will fall within the ULA (multilink) | MNP for each underlay interface will fall within the ULA (multilink) | |||
| subnet relative to each FHS Proxy/Server. | subnet relative to each FHS Proxy/Server. | |||
| Clients configure OMNI interfaces that observe the properties | Clients configure OMNI interfaces that observe the properties | |||
| discussed in previous sections. The OMNI interface and its underlay | discussed in previous sections. The OMNI interface and its underlay | |||
| interfaces are said to be in either the "UP" or "DOWN" state | interfaces are said to be in either the "UP" or "DOWN" state | |||
| according to administrative actions in conjunction with the interface | according to administrative actions in conjunction with the interface | |||
| connectivity status. An OMNI interface transitions to UP or DOWN | connectivity status. An OMNI interface transitions to UP or DOWN | |||
| through administrative action and/or through state transitions of the | through administrative action and/or through state transitions of the | |||
| underlay interfaces. When a first underlay interface transitions to | underlay interfaces. When a first underlay interface transitions to | |||
| UP, the OMNI interface also transitions to UP. When all underlay | UP, the OMNI interface also transitions to UP. When all underlay | |||
| interfaces transition to DOWN, the OMNI interface also transitions to | interfaces transition to DOWN, the OMNI interface also transitions to | |||
| DOWN. | DOWN. | |||
| When a Client OMNI interface transitions to UP, it sends RS messages | When a Client OMNI interface transitions to UP, it sends RS messages | |||
| to register its MNP and an initial set of underlay interfaces that | to register its MNP and an initial set of underlay interfaces that | |||
| are also UP. The Client sends additional RS messages to refresh | are also UP. The Client sends additional RS messages to refresh | |||
| lifetimes and to register/deregister underlay interfaces as they | lifetimes and to register/deregister underlay interfaces as they | |||
| transition to UP or DOWN. The Client's OMNI interface sends initial | transition to UP or DOWN. The Client's OMNI interface sends initial | |||
| RS messages over an UP underlay interface with its MNP-XLA as the | RS messages over an UP underlay interface with its {TLA,XLA}-MNP as | |||
| source (or with a random TMP-ULA as the source if it does not yet | the source (or with a {TLA,XLA}-RND as the source if it does not yet | |||
| have an MNP) and with destination set to link-scoped All-Routers | have an MNP) and with destination set to link-scoped All-Routers | |||
| multicast or the RND-ULA of a specific (Hub) Proxy/Server. The OMNI | multicast or the ULA of a specific (Hub) Proxy/Server. The OMNI | |||
| interface includes an OMNI option per Section 12 with an OMNI | interface includes an OMNI option per Section 12 with an OMNI | |||
| Neighbor Coordination sub-option with (Preflen assertion, N/A/U flags | Neighbor Coordination sub-option with (Preflen assertion, N/A/U flags | |||
| and Window Synchronization parameters), an Interface Attributes sub- | and Window Synchronization parameters), an Interface Attributes sub- | |||
| option for the underlay interface, a DHCPv6 Solicit sub-option if | option for the underlay interface, a DHCPv6 Solicit sub-option if | |||
| necessary, and with any other necessary OMNI sub-options such as | necessary, and with any other necessary OMNI sub-options such as | |||
| authentication, Proxy/Server Departure, etc. | authentication, Proxy/Server Departure, etc. | |||
| The Client then calculates the authentication signature or checksum | The Client then calculates the authentication signature or checksum | |||
| and prepares to forward the RS over the underlay interface using OAL | and prepares to forward the RS over the underlay interface using OAL | |||
| encapsulation and fragmentation if necessary. If the Client uses OAL | encapsulation and fragmentation if necessary. If the Client uses OAL | |||
| encapsulation for RS messages sent to an unsynchronized FHS Proxy/ | encapsulation for RS messages sent to an unsynchronized FHS Proxy/ | |||
| Server over an INET interface, the entire RS message must fit within | Server over an INET interface, the entire RS message must fit within | |||
| a single carrier packet (i.e., an atomic fragment) so that the FHS | a single carrier packet (i.e., an atomic fragment) so that the FHS | |||
| Proxy/Server can verify the authentication signature without having | Proxy/Server can verify the authentication signature without having | |||
| to reassemble. The OMNI interface selects an Identification value | to reassemble. The OMNI interface selects an Identification value | |||
| (see: Section 6.6), sets the OAL source address to the MNP-ULA | (see: Section 6.6), sets the OAL source address to the ULA-MNP | |||
| corresponding to the RS source if known (otherwise to a TMP-ULA), | corresponding to the RS source if known (otherwise to a {TLA,XLA}- | |||
| sets the OAL destination to an OMNI IPv6 anycast or RND-ULA unicast | RND), sets the OAL destination to an OMNI IPv6 anycast address or a | |||
| address, optionally includes a Nonce and/or Timestamp, then performs | known Proxy/Server ULA, optionally includes a Nonce and/or Timestamp, | |||
| fragmentation if necessary. When L2 encapsulation is used, the | then performs fragmentation if necessary. When L2 encapsulation is | |||
| Client includes the discovered FHS Proxy/Server INADDR or an anycast | used, the Client includes the discovered FHS Proxy/Server INADDR or | |||
| address as the L2 destination then forwards the resulting carrier | an anycast address as the L2 destination then forwards the resulting | |||
| packet(s) into the underlay network. Note that the Client does not | carrier packet(s) into the underlay network. Note that the Client | |||
| yet create a NCE, but instead remembers the Identification, Nonce | does not yet create a NCE, but instead remembers the Identification, | |||
| and/or Timestamp values included in its RS message transmissions to | Nonce and/or Timestamp values included in its RS message | |||
| match against any received RA messages. | transmissions to match against any received RA messages. | |||
| When an FHS Proxy/Server receives the carrier packets containing an | When an FHS Proxy/Server receives the carrier packets containing an | |||
| RS it sets aside the L2 headers, verifies the Identifications and | RS it sets aside the L2 headers, verifies the Identifications and | |||
| reassembles if necessary, sets aside the OAL header, then verifies | reassembles if necessary, sets aside the OAL header, then verifies | |||
| the RS authentication signature or checksum. The FHS Proxy/Server | the RS authentication signature or checksum. The FHS Proxy/Server | |||
| then creates/updates a NCE indexed by the Client's RS source address | then creates/updates a NCE indexed by the Client's RS source address | |||
| and caches the OMNI Interface Attributes and any Traffic Selector | and caches the OMNI Interface Attributes and any Traffic Selector | |||
| sub-options while also caching the L2 (UDP/IP) and OAL (ULA) source | sub-options while also caching the L2 (UDP/IP) and OAL source and | |||
| and destination address information. The FHS Proxy/Server next | destination address information. The FHS Proxy/Server next caches | |||
| caches the OMNI Neighbor Coordination sub-option Window | the OMNI Neighbor Coordination sub-option Window Synchronization | |||
| Synchronization parameters and N flag to determine its role in | parameters and N flag to determine its role in processing NS(NUD) | |||
| processing NS(NUD) messages (see: Section 12.1) then examines the RS | messages (see: Section 12.1) then examines the RS destination | |||
| destination address. If the destination matches its own RND-ULA, the | address. If the destination matches its own ULA, the FHS Proxy/ | |||
| FHS Proxy/Server assumes the Hub role and acts as the sole entry | Server assumes the Hub role and acts as the sole entry point for | |||
| point for injecting the Client's MNP-XLA into the MS routing system | injecting the Client's XLA-MNP into the OMNI link routing system | |||
| (i.e., after performing any necessary prefix delegation operations) | (i.e., after performing any necessary prefix delegation operations) | |||
| while including a prefix length and setting the prefix to fd00::/64 | while including a prefix length and setting the prefix to fd00::/64 | |||
| and suffix to the 64-bit MNP. The FHS/Hub Proxy/Server then caches | and suffix to the 64-bit MNP. The FHS/Hub Proxy/Server then caches | |||
| the OMNI Neighbor Coordination sub-option A/U flags to determine its | the OMNI Neighbor Coordination sub-option A/U flags to determine its | |||
| role in processing NS(AR) messages and generating uNA messages (see: | role in processing NS(AR) messages and generating uNA messages (see: | |||
| Section 12.1). | Section 12.1). | |||
| The FHS/Hub Proxy/Server then prepares to return an RA message | The FHS/Hub Proxy/Server then prepares to return an RA message | |||
| directly to the Client by first populating the Cur Hop Limit, Flags, | directly to the Client by first populating the Cur Hop Limit, Flags, | |||
| Router Lifetime, Reachable Time and Retrans Timer fields with values | Router Lifetime, Reachable Time and Retrans Timer fields with values | |||
| skipping to change at page 99, line 32 ¶ | skipping to change at page 99, line 32 ¶ | |||
| INADDR field. | INADDR field. | |||
| The FHS/Hub Proxy/Server next includes an Origin Indication sub- | The FHS/Hub Proxy/Server next includes an Origin Indication sub- | |||
| option that includes the RS L2 source INADDR information (see: | option that includes the RS L2 source INADDR information (see: | |||
| Section 12.2.16.1), then includes any other necessary OMNI sub- | Section 12.2.16.1), then includes any other necessary OMNI sub- | |||
| options (either within the same OMNI option or in additional OMNI | options (either within the same OMNI option or in additional OMNI | |||
| options). Following the OMNI option(s), the FHS/Hub Proxy/Server | options). Following the OMNI option(s), the FHS/Hub Proxy/Server | |||
| next includes any other necessary RA options such as PIOs with (A; | next includes any other necessary RA options such as PIOs with (A; | |||
| L=0) that include the OMNI link MSPs [RFC8028], RIOs [RFC4191] with | L=0) that include the OMNI link MSPs [RFC8028], RIOs [RFC4191] with | |||
| more-specific routes, Nonce and Timestamp options, etc. The FHS/Hub | more-specific routes, Nonce and Timestamp options, etc. The FHS/Hub | |||
| Proxy/Server then sets the RA source address to its own RND-ULA and | Proxy/Server then sets the RA source address to its own ULA and | |||
| destination address to the Client's MNP-ULA (i.e., relative to the | destination address to the Client's ULA-MNP (i.e., relative to the | |||
| ULA /64 prefix for its Client-facing underlay interface) while also | ULA /64 prefix for its Client-facing underlay interface) while also | |||
| recording the MNP-XLA as an (alternate) index to the Client NCE, then | recording the corresponding XLA-MNP as an (alternate) index to the | |||
| calculates the authentication signature or checksum. The FHS/Hub | Client NCE, then calculates the authentication signature or checksum. | |||
| Proxy/Server finally performs OAL encapsulation with source set to | The FHS/Hub Proxy/Server finally performs OAL encapsulation with | |||
| its own RND-ULA and destination set to the OAL source that appeared | source set to its own ULA and destination set to the OAL source that | |||
| in the RS, then fragments if necessary, encapsulates each fragment in | appeared in the RS, then fragments if necessary, encapsulates each | |||
| appropriate L2 headers with source and destination address | fragment in appropriate L2 headers with source and destination | |||
| information reversed from the RS L2 information and returns the | address information reversed from the RS L2 information and returns | |||
| resulting carrier packets to the Client over the same underlay | the resulting carrier packets to the Client over the same underlay | |||
| interface the RS arrived on. | interface the RS arrived on. | |||
| When an FHS Proxy/Server receives an RS with a valid authentication | When an FHS Proxy/Server receives an RS with a valid authentication | |||
| signature or checksum and with destination set to link-scoped All- | signature or checksum and with destination set to link-scoped All- | |||
| Routers multicast, it can either assume the Hub role itself the same | Routers multicast, it can either assume the Hub role itself the same | |||
| as above or act as a proxy and select the RND-ULA of another Proxy/ | as above or act as a proxy and select the ULA of another Proxy/Server | |||
| Server to serve as the Hub. When an FHS Proxy/Server assumes the | to serve as the Hub. When an FHS Proxy/Server assumes the proxy role | |||
| proxy role or receives an RS with destination set to the RND-ULA of | or receives an RS with destination set to the ULA of another Proxy/ | |||
| another Proxy/Server, it forwards the message while acting as a | Server, it forwards the message while acting as a proxy. The FHS | |||
| proxy. The FHS Proxy/Server creates/updates a NCE for the Client | Proxy/Server creates/updates a NCE for the Client (i.e., based on the | |||
| (i.e., based on the RS source address) and caches the OAL source, | RS source address) and caches the OAL source, Window Synchronization, | |||
| Window Synchronization, N flag, Interface Attributes addressing | N flag, Interface Attributes addressing information as above then | |||
| information as above then writes its own INET-facing FMT/SRT and LHS | writes its own INET-facing FMT/SRT and LHS Proxy/Server ULA/INADDR | |||
| Proxy/Server ULA/INADDR information into the appropriate Interface | information into the appropriate Interface Attributes sub-option | |||
| Attributes sub-option fields. The FHS Proxy/Server then calculates | fields. The FHS Proxy/Server then calculates and includes the | |||
| and includes the checksum, performs OAL encapsulation with source set | checksum, performs OAL encapsulation with source set to its own ULA | |||
| to its own RND-ULA and destination set to the RND-ULA of the Hub | and destination set to the ULA of the Hub Proxy/Server, fragments if | |||
| Proxy/Server, fragments if necessary, encapsulates each fragment in | necessary, encapsulates each fragment in appropriate L2 headers and | |||
| appropriate L2 headers and sends the resulting carrier packets into | sends the resulting carrier packets into the SRT secured spanning | |||
| the SRT secured spanning tree. | tree. | |||
| When the Hub Proxy/Server receives the carrier packets, it discards | When the Hub Proxy/Server receives the carrier packets, it discards | |||
| the L2 headers, reassembles if necessary to obtain the proxyed RS, | the L2 headers, reassembles if necessary to obtain the proxyed RS, | |||
| then performs DHCPv6 Prefix Delegation (PD) to obtain the Client's | then performs DHCPv6 Prefix Delegation (PD) to obtain the Client's | |||
| MNP if the RS source is a TMP-ULA. The Hub Proxy/Server then | MNP if the RS source is a (TLA,XLA}-RND. The Hub Proxy/Server then | |||
| creates/updates a NCE for the Client's MNP-XLA and caches any state | creates/updates a NCE for the Client's XLA-MNP and caches any state | |||
| (including the A/U flags, OAL addresses, Interface Attributes | (including the A/U flags, OAL addresses, Interface Attributes | |||
| information and Traffic Selectors), then finally performs routing | information and Traffic Selectors), then finally performs routing | |||
| protocol injection. The Hub Proxy/Server then returns an RA that | protocol injection. The Hub Proxy/Server then returns an RA that | |||
| echoes the Client's (proxyed) Interface Attributes sub-option and | echoes the Client's (proxyed) Interface Attributes sub-option and | |||
| with any RA parameters the same as specified for the FHS/Hub Proxy/ | with any RA parameters the same as specified for the FHS/Hub Proxy/ | |||
| Server case above. The Hub Proxy/Server then sets the RA source | Server case above. The Hub Proxy/Server then sets the RA source | |||
| address to its own RND-ULA and destination address to the RS source | address to its own ULA and destination address to the RS source | |||
| address; if the RS source address is a TMP-ULA, the Hub Proxy/Server | address; if the RS source address is a {TLA,XLA}-RND, the Hub Proxy/ | |||
| also includes the MNP in a DHCPv6 PD Reply OMNI sub-option. The Hub | Server also includes the MNP in a DHCPv6 PD Reply OMNI sub-option. | |||
| Proxy/Server next calculates the checksum, then encapsulates the RA | The Hub Proxy/Server next calculates the checksum, then encapsulates | |||
| as an OAL packet with source set to its own RND-ULA and destination | the RA as an OAL packet with source set to its own ULA and | |||
| set to the RND-ULA of the FHS Proxy/Server that forwarded the RS. | destination set to the ULA of the FHS Proxy/Server that forwarded the | |||
| The Hub Proxy/Server finally fragments if necessary, encapsulates | RS. The Hub Proxy/Server finally fragments if necessary, | |||
| each fragment in appropriate L2 headers and sends the resulting | encapsulates each fragment in appropriate L2 headers and sends the | |||
| carrier packets into the secured spanning tree. | resulting carrier packets into the secured spanning tree. | |||
| When the FHS Proxy/Server receives the carrier packets it discards | When the FHS Proxy/Server receives the carrier packets it discards | |||
| the L2 headers, reassembles if necessary to obtain the RA message, | the L2 headers, reassembles if necessary to obtain the RA message, | |||
| verifies the checksum then updates the OMNI interface NCE for the | verifies the checksum then updates the OMNI interface NCE for the | |||
| Client and creates/updates a NCE for the Hub. The FHS Proxy/Server | Client and creates/updates a NCE for the Hub. The FHS Proxy/Server | |||
| then sets the P flag in the RA flags field [RFC4389] and proxys the | then sets the P flag in the RA flags field [RFC4389] and proxys the | |||
| RA by changing the OAL source to its own RND-ULA, changing the OAL | RA by changing the OAL source to its own ULA, changing the OAL | |||
| destination to the OAL address found in the Client's NCE, and | destination to the OAL address found in the Client's NCE, and | |||
| changing the RA destination address to the MNP-ULA of the Client | changing the RA destination address to the ULA-MNP of the Client | |||
| relative to its own /64 ULA prefix while also recording the MNP-XLA | relative to its own /64 ULA prefix while also recording the | |||
| as an alternate index into the Client NCE. (If the RA destination | corresponding XLA-MNP as an alternate index into the Client NCE. (If | |||
| address was a TMP-ULA, the FHS Proxy Server determines the MNP by | the RA destination address was a {TLA,XLA}-RND, the FHS Proxy Server | |||
| consulting the DHCPv6 PD Reply message sub-option.) The FHS Proxy/ | determines the MNP by consulting the DHCPv6 PD Reply message sub- | |||
| Server next includes Window Synchronization parameters responsive to | option.) The FHS Proxy/Server next includes Window Synchronization | |||
| those in the Client's RS, an Interface Attributes sub-option with | parameters responsive to those in the Client's RS, an Interface | |||
| omIndex '0' and with its unicast L2 IP address if necessary (see | Attributes sub-option with omIndex '0' and with its unicast L2 IP | |||
| above), an Origin Indication sub-option with the Client's cached | address if necessary (see above), an Origin Indication sub-option | |||
| INADDR and an authentication sub-option if necessary. The FHS Proxy/ | with the Client's cached INADDR and an authentication sub-option if | |||
| Server finally selects an Identification value per Section 6.6, | necessary. The FHS Proxy/Server finally selects an Identification | |||
| calculates the authentication signature or checksum, fragments if | value per Section 6.6, calculates the authentication signature or | |||
| necessary, encapsulates each fragment in L2 headers with addresses | checksum, fragments if necessary, encapsulates each fragment in L2 | |||
| taken from the Client's NCE and returns the resulting carrier packets | headers with addresses taken from the Client's NCE and returns the | |||
| via the same underlay interface over which the RS was received. | resulting carrier packets via the same underlay interface over which | |||
| the RS was received. | ||||
| When the Client receives the carrier packets, it discards the L2 | When the Client receives the carrier packets, it discards the L2 | |||
| headers, reassembles if necessary and removes the OAL header to | headers, reassembles if necessary and removes the OAL header to | |||
| obtain the RA message. The Client next verifies the authentication | obtain the RA message. The Client next verifies the authentication | |||
| signature or checksum, then matches the RA message with its | signature or checksum, then matches the RA message with its | |||
| previously-sent RS by comparing the RS Sequence Number with the RA | previously-sent RS by comparing the RS Sequence Number with the RA | |||
| Acknowledgement Number and also comparing the Nonce and/or Timestamp | Acknowledgement Number and also comparing the Nonce and/or Timestamp | |||
| values if present. If the values match, the Client then creates/ | values if present. If the values match, the Client then creates/ | |||
| updates OMNI interface NCEs for both the Hub and FHS Proxy/Server and | updates OMNI interface NCEs for both the Hub and FHS Proxy/Server and | |||
| caches the information in the RA message. In particular, the Client | caches the information in the RA message. In particular, the Client | |||
| caches the RA source address as the Hub Proxy/Server RND-ULA and uses | caches the RA source address as the Hub Proxy/Server ULA and uses the | |||
| the OAL source address to configure both an underlay interface- | OAL source address to configure both an underlay interface-specific | |||
| specific RND-ULA for the Hub Proxy/Server and the RND-ULA of this FHS | ULA for the Hub Proxy/Server and the ULA of this FHS Proxy/Server. | |||
| Proxy/Server. The Client then uses the MNP-ULA in the RA destination | The Client then uses the ULA-MNP in the RA destination address to | |||
| address to configure its address within the ULA (multilink) subnet | configure its address within the ULA (multilink) subnet prefix of the | |||
| prefix of the FHS Proxy/Server. If the Client has multiple underlay | FHS Proxy/Server. If the Client has multiple underlay interfaces, it | |||
| interfaces, it creates additional FHS Proxy/Server NCEs and MNP-ULAs | creates additional FHS Proxy/Server NCEs and ULA-MNPs as necessary | |||
| as necessary when it receives RAs over those interfaces (noting that | when it receives RAs over those interfaces (noting that multiple of | |||
| multiple of the Client's underlay interfaces may be serviced by the | the Client's underlay interfaces may be serviced by the same or | |||
| same or different FHS Proxy/Servers). The Client finally adds the | different FHS Proxy/Servers). The Client finally adds the Hub Proxy/ | |||
| Hub Proxy/Server RND-ULA to the default router list if necessary. | Server ULA to the default router list if necessary. | |||
| For each underlay interface, the Client next caches the (filled-out) | For each underlay interface, the Client next caches the (filled-out) | |||
| Interface Attributes for its own omIndex and Origin Indication | Interface Attributes for its own omIndex and Origin Indication | |||
| information that it received in an RA message over that interface so | information that it received in an RA message over that interface so | |||
| that it can include them in future NS/NA messages to provide | that it can include them in future NS/NA messages to provide | |||
| neighbors with accurate FMT/SRT/LHS information. (If the message | neighbors with accurate FMT/SRT/LHS information. (If the message | |||
| includes an Interface Attributes sub-option with omIndex '0', the | includes an Interface Attributes sub-option with omIndex '0', the | |||
| Client also caches the INADDR as the underlay network-local unicast | Client also caches the INADDR as the underlay network-local unicast | |||
| address of the FHS Proxy//Server via that underlay interface.) The | address of the FHS Proxy//Server via that underlay interface.) The | |||
| Client then compares the Origin Indication INADDR information with | Client then compares the Origin Indication INADDR information with | |||
| skipping to change at page 102, line 33 ¶ | skipping to change at page 102, line 33 ¶ | |||
| header to trigger a uNA reply. | header to trigger a uNA reply. | |||
| * When the Router Lifetime for the Hub Proxy/Server nears | * When the Router Lifetime for the Hub Proxy/Server nears | |||
| expiration, the Client sends an RS over any underlay interface to | expiration, the Client sends an RS over any underlay interface to | |||
| receive a fresh RA from the Hub. If no RA messages are received | receive a fresh RA from the Hub. If no RA messages are received | |||
| over a first underlay interface (i.e., after retrying), the Client | over a first underlay interface (i.e., after retrying), the Client | |||
| marks the underlay interface as DOWN and should attempt to contact | marks the underlay interface as DOWN and should attempt to contact | |||
| the Hub Proxy/Server via a different underlay interface. If the | the Hub Proxy/Server via a different underlay interface. If the | |||
| Hub Proxy/Server is unresponsive over additional underlay | Hub Proxy/Server is unresponsive over additional underlay | |||
| interfaces, the Client sends an RS message with destination set to | interfaces, the Client sends an RS message with destination set to | |||
| the RND-ULA of another Proxy/Server which will then assume the Hub | the ULA of another Proxy/Server which will then assume the Hub | |||
| role. | role. | |||
| * When all of a Client's underlay interfaces have transitioned to | * When all of a Client's underlay interfaces have transitioned to | |||
| DOWN (or if the prefix registration lifetime expires), the Hub | DOWN (or if the prefix registration lifetime expires), the Hub | |||
| Proxy/Server withdraws the MNP the same as if it had received a | Proxy/Server withdraws the MNP the same as if it had received a | |||
| message with a release indication. | message with a release indication. | |||
| The Client is responsible for retrying each RS exchange up to | The Client is responsible for retrying each RS exchange up to | |||
| MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL | MAX_RTR_SOLICITATIONS times separated by RTR_SOLICITATION_INTERVAL | |||
| seconds until an RA is received. If no RA is received over an UP | seconds until an RA is received. If no RA is received over an UP | |||
| skipping to change at page 104, line 5 ¶ | skipping to change at page 104, line 5 ¶ | |||
| the Client's multiple underlay interfaces for the same FHS Proxy/ | the Client's multiple underlay interfaces for the same FHS Proxy/ | |||
| Server. | Server. | |||
| Note: Although the Client's FHS Proxy/Server is a first-hop segment | Note: Although the Client's FHS Proxy/Server is a first-hop segment | |||
| node from its own perspective, the Client stores the Proxy/Server's | node from its own perspective, the Client stores the Proxy/Server's | |||
| FMT/SRT/ULA/INADDR as last-hop segment (LHS) information to supply to | FMT/SRT/ULA/INADDR as last-hop segment (LHS) information to supply to | |||
| neighbors. This allows both the Client and Hub Proxy/Server to | neighbors. This allows both the Client and Hub Proxy/Server to | |||
| supply the information to neighbors that will perceive it as LHS | supply the information to neighbors that will perceive it as LHS | |||
| information on the return path to the Client. | information on the return path to the Client. | |||
| Note: The Hub Proxy/Server injects Client MNP-XLA into the routing | Note: The Hub Proxy/Server injects Client XLA-MNP into the OMNI link | |||
| system by simply creating a route-to-interface forwarding table entry | routing system by simply creating a route-to-interface forwarding | |||
| for fd00::{MNP}/N via the OMNI interface. The dynamic routing | table entry for fd00::{MNP}/N via the OMNI interface. The dynamic | |||
| protocol will notice the new entry and advertise the route to its | routing protocol will notice the new entry and propagate the route to | |||
| peers. If the Hub receives additional RS messages, it need not re- | its peers. If the Hub receives additional RS messages, it need not | |||
| create the forwarding table entry (nor disturb the dynamic routing | re-create the forwarding table entry (nor disturb the dynamic routing | |||
| protocol) if an entry is already present. If the Hub ceases to | protocol) if an entry is already present. If the Hub ceases to | |||
| receive RS messages from any of the Client's interfaces, it removes | receive RS messages from any of the Client's interfaces, it removes | |||
| the Client MNP-XLA from the forwarding table (i.e., after a short | the Client XLA-MNP from the forwarding table (i.e., after a short | |||
| delay) resulting in its removal also from the routing system. | delay) resulting in its removal also from the routing system. | |||
| Note: If the Client's initial RS message includes an anycast L2 | Note: If the Client's initial RS message includes an anycast L2 | |||
| destination address, the FHS Proxy/Server returns the solicited RA | destination address, the FHS Proxy/Server returns the solicited RA | |||
| using the same anycast address as the L2 source while including an | using the same anycast address as the L2 source while including an | |||
| Interface Attributes sub-option with omIndex '0' and its true unicast | Interface Attributes sub-option with omIndex '0' and its true unicast | |||
| address in the INADDR. When the Client sends additional RS messages, | address in the INADDR. When the Client sends additional RS messages, | |||
| it includes this FHS Proxy/Server unicast address as the L2 | it includes this FHS Proxy/Server unicast address as the L2 | |||
| destination and the FHS Proxy/Server returns the solicited RA using | destination and the FHS Proxy/Server returns the solicited RA using | |||
| the same unicast address as the L2 source. This will ensure that RS/ | the same unicast address as the L2 source. This will ensure that RS/ | |||
| skipping to change at page 104, line 36 ¶ | skipping to change at page 104, line 36 ¶ | |||
| source. | source. | |||
| Note: The Origin Indication sub-option is included only by the FHS | Note: The Origin Indication sub-option is included only by the FHS | |||
| Proxy/Server and not by the Hub (unless the Hub is also serving as an | Proxy/Server and not by the Hub (unless the Hub is also serving as an | |||
| FHS). | FHS). | |||
| Note: Clients should set the N/A/U flags consistently in successive | Note: Clients should set the N/A/U flags consistently in successive | |||
| RS messages and only change those settings when an FHS/Hub Proxy/ | RS messages and only change those settings when an FHS/Hub Proxy/ | |||
| Server service profile update is necessary. | Server service profile update is necessary. | |||
| Note: After a Client has discovered its MNP-ULAs for a given set of | Note: After a Client has discovered its ULA-MNPs for a given set of | |||
| FHS Proxy/Servers, it should begin using its MNP-XLA as the IPv6 ND | FHS Proxy/Servers, it should begin using its XLA-MNP as the IPv6 ND | |||
| message source address and MNP-ULA as the OAL source address in | message source address and ULA-MNP as the OAL source address in | |||
| future IPv6 ND messages and refrain from further use of TMP-ULAs. In | future IPv6 ND messages and refrain from further use of TLAs. In any | |||
| any case, the Client SHOULD NOT gratuitously configure and use large | case, the Client SHOULD NOT gratuitously configure and use large | |||
| numbers of additional TMP-ULAs, as doing so would simply result in | numbers of additional TLAs, as doing so would simply result in | |||
| address change churn in neighbor cache entries with no operational | address change churn in neighbor cache entries with no operational | |||
| advantages. | advantages. | |||
| Note: Although the Client adds the Hub Proxy/Server RND-ULA to the | Note: Although the Client adds the Hub Proxy/Server ULA to the | |||
| default router list, it also caches the RND-ULAs of the FHS Proxy/ | default router list, it also caches the ULAs of the FHS Proxy/Servers | |||
| Servers on the path to the Hub over each underlying interface. When | on the path to the Hub over each underlying interface. When the | |||
| the Client needs to send a packet to a default router, it therefore | Client needs to send a packet to a default router, it therefore | |||
| selects an RND-ULA corresponding to the selected interface which | selects an ULA corresponding to the selected interface which directs | |||
| directs the packet to an FHS Proxy/Server for that interface. The | the packet to an FHS Proxy/Server for that interface. The FHS Proxy/ | |||
| FHS Proxy/Server then forwards the packet without disturbing the Hub. | Server then forwards the packet without disturbing the Hub. | |||
| 15.1. Window Synchronization | 15.1. Window Synchronization | |||
| In environments where Identification window synchronization is | In environments where Identification window synchronization is | |||
| necessary, the RS/RA exchanges discussed above observe the principles | necessary, the RS/RA exchanges discussed above observe the principles | |||
| specified in Section 6.6. Window synchronization is conducted | specified in Section 6.6. Window synchronization is conducted | |||
| between the Client and each FHS Proxy/Server used to contact the Hub | between the Client and each FHS Proxy/Server used to contact the Hub | |||
| Proxy/Server, i.e., and not between the Client and the Hub. This is | Proxy/Server, i.e., and not between the Client and the Hub. This is | |||
| due to the fact that the Hub Proxy/Server is responsible only for | due to the fact that the Hub Proxy/Server is responsible only for | |||
| forwarding control and data messages via the secured spanning tree to | forwarding control and data messages via the secured spanning tree to | |||
| FHS Proxy/Servers, and is not responsible for forwarding messages | FHS Proxy/Servers, and is not responsible for forwarding messages | |||
| directly to the Client under a synchronized window. Also, in the | directly to the Client under a synchronized window. Also, in the | |||
| reverse direction the FHS Proxy/Servers handle all default forwarding | reverse direction the FHS Proxy/Servers handle all default forwarding | |||
| actions without forwarding Client-initiated data to the Hub. | actions without forwarding Client-initiated data to the Hub. | |||
| When a Client needs to perform window synchronization via a new FHS | When a Client needs to perform window synchronization via a new FHS | |||
| Proxy/Server, it sets the RS source address to its own MNP-XLA (or a | Proxy/Server, it sets the RS source address to its own {TLA,XLA}-MNP | |||
| TMP-ULA) and destination address to the RND-ULA of the Hub Proxy/ | (or a {TLA,XLA}-RND) and destination address to the ULA of the Hub | |||
| Server (or to All-Routers multicast in an initial RS), then sets the | Proxy/Server (or to All-Routers multicast in an initial RS), then | |||
| SYN flag and includes an initial Sequence Number for Window | sets the SYN flag and includes an initial Sequence Number for Window | |||
| Synchronization. The Client then performs OAL encapsulation using | Synchronization. The Client then performs OAL encapsulation using | |||
| its own MNP-ULA (or a TMP-ULA) as the source and the RND-ULA of the | its own ULA-MNP (or the TLA-RND) as the source and the ULA of the FHS | |||
| FHS Proxy/Server as the destination and includes an Interface | Proxy/Server as the destination and includes an Interface Attributes | |||
| Attributes sub-option then forwards the resulting carrier packets to | sub-option then forwards the resulting carrier packets to the FHS | |||
| the FHS Proxy/Server. The FHS Proxy/Server then extracts the RS | Proxy/Server. The FHS Proxy/Server then extracts the RS message and | |||
| message and caches the Window Synchronization parameters then re- | caches the Window Synchronization parameters then re-encapsulates | |||
| encapsulates with its own RND-ULA as the source and the RND-ULA of | with its own ULA as the source and the ULA of the Hub Proxy/Server as | |||
| the Hub Proxy/Server as the target. | the target. | |||
| The FHS Proxy/Server then forwards the resulting carrier packets via | The FHS Proxy/Server then forwards the resulting carrier packets via | |||
| the secured spanning tree to the Hub Proxy/Server, which updates the | the secured spanning tree to the Hub Proxy/Server, which updates the | |||
| Client's Interface Attributes and returns a unicast RA message with | Client's Interface Attributes and returns a unicast RA message with | |||
| source set to its own RND-ULA and destination set to the RS source | source set to its own ULA and destination set to the RS source | |||
| address and with the Client's Interface Attributes echoed. The Hub | address and with the Client's Interface Attributes echoed. The Hub | |||
| Proxy/Server then performs OAL encapsulation using its own RND-ULA as | Proxy/Server then performs OAL encapsulation using its own ULA as the | |||
| the source and the RND-ULA of the FHS Proxy/Server as the | source and the ULA of the FHS Proxy/Server as the destination, then | |||
| destination, then forwards the carrier packets via the secured | forwards the carrier packets via the secured spanning tree to the FHS | |||
| spanning tree to the FHS Proxy/Server. The FHS Proxy/Server then | Proxy/Server. The FHS Proxy/Server then proxys the message as | |||
| proxys the message as discussed in the previous section and includes | discussed in the previous section and includes responsive Window | |||
| responsive Window Synchronization information. The FHS Proxy/Server | Synchronization information. The FHS Proxy/Server then forwards the | |||
| then forwards the message to the Client which updates its window | message to the Client which updates its window synchronization | |||
| synchronization information for the FHS Proxy/Server as necessary. | information for the FHS Proxy/Server as necessary. | |||
| Following the initial RS/RA-driven window synchronization, the Client | Following the initial RS/RA-driven window synchronization, the Client | |||
| can re-assert new windows with specific FHS Proxy/Servers by | can re-assert new windows with specific FHS Proxy/Servers by | |||
| performing NS/NA exchanges between its own MNP-XLAs and the RND-ULAs | performing NS/NA exchanges between its own XLA-MNPs and the ULAs of | |||
| of the FHS Proxy/Servers without having to disturb the Hub. | the FHS Proxy/Servers without having to disturb the Hub. | |||
| 15.2. Router Discovery in IP Multihop and IPv4-Only Networks | 15.2. Router Discovery in IP Multihop and IPv4-Only Networks | |||
| On some *NETs, a Client may be located multiple IP hops away from the | On some *NETs, a Client may be located multiple IP hops away from the | |||
| nearest OMNI link Proxy/Server. Forwarding through IP multihop *NETs | nearest OMNI link Proxy/Server. Forwarding through IP multihop *NETs | |||
| is conducted through the application of a routing protocol (e.g., a | is conducted through the application of a routing protocol (e.g., a | |||
| MANET/VANET routing protocol over omni-directional wireless | MANET/VANET routing protocol over omni-directional wireless | |||
| interfaces, an inter-domain routing protocol in an enterprise | interfaces, an inter-domain routing protocol in an enterprise | |||
| network, etc.). Example routing protocols optimized for MANET/VANET | network, etc.). Example routing protocols optimized for MANET/VANET | |||
| operations include [RFC3684] and [RFC5614] which operate according to | operations include [RFC3684] and [RFC5614] which operate according to | |||
| the link model articulated in [RFC5889] and subnet model articulated | the link model articulated in [RFC5889] and subnet model articulated | |||
| in [RFC5942]. | in [RFC5942]. | |||
| A Client located potentially multiple *NET hops away from the nearest | A Client located potentially multiple *NET hops away from the nearest | |||
| Proxy/Server prepares an RS message, sets the source address to its | Proxy/Server prepares an RS message, sets the source address to its | |||
| MNP-XLA (or to a TMP-ULA if it does not yet have an MNP), and sets | {TLA,XLA}-MNP (or to a {TLA,XLA}-RND if it does not yet have an MNP), | |||
| the destination to link-scoped All-Routers multicast or a unicast | and sets the destination to link-scoped All-Routers multicast or the | |||
| RND-ULA the same as discussed above. The OMNI interface then employs | unicast ULA of a Proxy/Server the same as discussed above. The OMNI | |||
| OAL encapsulation, sets the OAL source address to the TMP-ULA and | interface then employs OAL encapsulation, sets the OAL source address | |||
| sets the OAL destination to an OMNI IPv6 anycast address based on | to a TLA and sets the OAL destination to an OMNI IPv6 anycast address | |||
| either a native IPv6 or IPv4-Compatible IPv6 prefix (see: | based on either a native IPv6 or IPv4-Compatible IPv6 prefix (see: | |||
| Section 10). | Section 10). | |||
| For IPv6-enabled *NETs, if the underlay interface does not configure | For IPv6-enabled *NETs, if the underlay interface does not configure | |||
| an IPv6 GUA the Client injects the TMP-ULA into the IPv6 multihop | an IPv6 GUA the Client injects the TLA into the IPv6 multihop routing | |||
| routing system and forwards the message without further | system and forwards the message without further encapsulation. | |||
| encapsulation. Otherwise, the Client encapsulates the message in | Otherwise, the Client encapsulates the message in UDP/IPv6 L2 | |||
| UDP/IPv6 L2 headers, sets the source to the underlay interface IPv6 | headers, sets the source to the underlay interface IPv6 address and | |||
| address and sets the destination to the same OMNI IPv6 anycast | sets the destination to the same OMNI IPv6 anycast address. The | |||
| address. The Client then forwards the message into the IPv6 multihop | Client then forwards the message into the IPv6 multihop routing | |||
| routing system which conveys it to the nearest Proxy/Server that | system which conveys it to the nearest Proxy/Server that advertises a | |||
| advertises a matching OMNI IPv6 anycast prefix. If the nearest | matching OMNI IPv6 anycast prefix. If the nearest Proxy/Server is | |||
| Proxy/Server is too busy, it should forward (without Proxying) the | too busy, it should forward (without Proxying) the OAL-encapsulated | |||
| OAL-encapsulated RS to another nearby Proxy/Server connected to the | RS to another nearby Proxy/Server connected to the same IPv6 | |||
| same IPv6 (multihop) network that also advertises the matching OMNI | (multihop) network that also advertises the matching OMNI IPv6 | |||
| IPv6 anycast prefix. | anycast prefix. | |||
| For IPv4-only *NETs, the Client encapsulates the RS message in UDP/ | For IPv4-only *NETs, the Client encapsulates the RS message in UDP/ | |||
| IPv4 L2 headers, sets the source to the underlay interface IPv4 | IPv4 L2 headers, sets the source to the underlay interface IPv4 | |||
| address and sets the destination to the OMNI IPv4 anycast address. | address and sets the destination to the OMNI IPv4 anycast address. | |||
| The Client then forwards the message into the IPv4 multihop routing | The Client then forwards the message into the IPv4 multihop routing | |||
| system which conveys it to the nearest Proxy/Server that advertises | system which conveys it to the nearest Proxy/Server that advertises | |||
| the corresponding IPv4 prefix. If the nearest Proxy/Server is too | the corresponding IPv4 prefix. If the nearest Proxy/Server is too | |||
| busy and/or does not configure the specified OMNI IPv6 anycast | busy and/or does not configure the specified OMNI IPv6 anycast | |||
| address, it should forward (without Proxying) the OAL-encapsulated RS | address, it should forward (without Proxying) the OAL-encapsulated RS | |||
| to another nearby Proxy/Server connected to the same IPv4 (multihop) | to another nearby Proxy/Server connected to the same IPv4 (multihop) | |||
| skipping to change at page 107, line 32 ¶ | skipping to change at page 107, line 32 ¶ | |||
| be a fixed infrastructure element such as a roadside unit or another | be a fixed infrastructure element such as a roadside unit or another | |||
| MANET/VANET node). This process repeats iteratively until the RS | MANET/VANET node). This process repeats iteratively until the RS | |||
| message is received by a penultimate *NET hop within single-hop | message is received by a penultimate *NET hop within single-hop | |||
| communications range of a Proxy/Server, which forwards the message to | communications range of a Proxy/Server, which forwards the message to | |||
| the Proxy/Server. | the Proxy/Server. | |||
| When a Proxy/Server that configures the OMNI IPv6 anycast OAL | When a Proxy/Server that configures the OMNI IPv6 anycast OAL | |||
| destination receives the message, it decapsulates the RS and assumes | destination receives the message, it decapsulates the RS and assumes | |||
| either the Hub or FHS role (in which case, it forwards the RS to a | either the Hub or FHS role (in which case, it forwards the RS to a | |||
| candidate Hub). The Hub Proxy/Server then prepares an RA message | candidate Hub). The Hub Proxy/Server then prepares an RA message | |||
| with source address set to its own RND-ULA and destination address | with source address set to its own ULA and destination address set to | |||
| set to the RS source address if it is acting only as the Hub (or to | the RS source address if it is acting only as the Hub (or to the | |||
| the Client MNP-ULA within its ULA subnet prefix if it is also acting | Client ULA-MNP within its ULA subnet prefix if it is also acting as | |||
| as the FHS Proxy/Server). The Hub Proxy/Server then performs OAL | the FHS Proxy/Server). The Hub Proxy/Server then performs OAL | |||
| encapsulation with the RA OAL source/destination set to the RS OAL | encapsulation with the RA OAL source/destination set to the RS OAL | |||
| destination/source and forwards the RA either to the FHS Proxy/Server | destination/source and forwards the RA either to the FHS Proxy/Server | |||
| or directly to the Client. | or directly to the Client. | |||
| When the Hub or FHS Proxy/Server forwards the RA to the Client, it | When the Hub or FHS Proxy/Server forwards the RA to the Client, it | |||
| encapsulates the message in L2 encapsulation headers (if necessary) | encapsulates the message in L2 encapsulation headers (if necessary) | |||
| with (src, dst) set to the (dst, src) of the RS L2 encapsulation | with (src, dst) set to the (dst, src) of the RS L2 encapsulation | |||
| headers. The Proxy/Server then forwards the message to a *NET node | headers. The Proxy/Server then forwards the message to a *NET node | |||
| within communications range, which forwards the message according to | within communications range, which forwards the message according to | |||
| its routing tables to an intermediate node. The multihop forwarding | its routing tables to an intermediate node. The multihop forwarding | |||
| process within the *NET continues repetitively until the message is | process within the *NET continues repetitively until the message is | |||
| delivered to the original Client, which decapsulates the message and | delivered to the original Client, which decapsulates the message and | |||
| performs autoconfiguration the same as if it had received the RA | performs autoconfiguration the same as if it had received the RA | |||
| directly from a Proxy/Server on the same physical link. The Client | directly from a Proxy/Server on the same physical link. The Client | |||
| then injects the MNP-ULA into the IPv6 multihop routing system if | then injects the ULA-MNP into the IPv6 multihop routing system if | |||
| necessary, then begins using the MNP-ULA as its OAL source address | necessary, then begins using the ULA-MNP as its OAL source address | |||
| and suspends use of its TMP-ULA since it now has a unique address | and suspends use of its TLA since it now has a unique address within | |||
| within the FHS Proxy/Server's "Multilink Subnet". | the FHS Proxy/Server's "Multilink Subnet". | |||
| Note: When the RS message includes anycast OAL and/or L2 | Note: When the RS message includes anycast OAL and/or L2 | |||
| encapsulation destinations, the FHS Proxy/Server must use the same | encapsulation destinations, the FHS Proxy/Server must use the same | |||
| anycast addresses as the OAL and/or L2 encapsulation sources to | anycast addresses as the OAL and/or L2 encapsulation sources to | |||
| support forwarding of the RA message and any initial data packets | support forwarding of the RA message and any initial data packets | |||
| over any NATs on the path. When the Client receives the RA, it will | over any NATs on the path. When the Client receives the RA, it will | |||
| discover its unicast MNP-ULA and/or L2 encapsulation addresses and | discover its unicast ULA-MNP and/or L2 encapsulation addresses and | |||
| can forward future packets using the unicast (instead of anycast) | can forward future packets using the unicast (instead of anycast) | |||
| addresses to populate NAT state in the forward path. (If the Client | addresses to populate NAT state in the forward path. (If the Client | |||
| does not have immediate data to send to the FHS Proxy/Server, it can | does not have immediate data to send to the FHS Proxy/Server, it can | |||
| instead send an OAL "bubble" - see Section 6.10.) After the Client | instead send an OAL "bubble" - see Section 6.10.) After the Client | |||
| begins using unicast OAL/L2 encapsulation addresses in this way, the | begins using unicast OAL/L2 encapsulation addresses in this way, the | |||
| FHS Proxy/Server should also begin using the same unicast addresses | FHS Proxy/Server should also begin using the same unicast addresses | |||
| in the reverse direction. | in the reverse direction. | |||
| Note: When an OMNI interface configures a TMP-ULA, any nodes that | Note: When an OMNI interface configures a TLA, any nodes that forward | |||
| forward an encapsulated RS message with the ULA as the OAL source | an encapsulated RS message with the ULA as the OAL source must not | |||
| must not consider the message as being specific to a particular OMNI | consider the message as being specific to a particular OMNI link. | |||
| link. TMP-ULAs can therefore also serve as the source and | TLAs can therefore also serve as the source and destination addresses | |||
| destination addresses of unencapsulated IPv6 data communications | of unencapsulated IPv6 data communications within the local routing | |||
| within the local routing region, and if the TMP-ULAs are injected | region, and if the TLAs are injected into the local network routing | |||
| into the local network routing protocol their prefix length must be | protocol their prefix length must be set to 128. | |||
| set to 128. | ||||
| 15.3. DHCPv6-based Prefix Registration | 15.3. DHCPv6-based Prefix Registration | |||
| When a Client is not pre-provisioned with an MNP (or, when the Client | When a Client is not pre-provisioned with an MNP (or, when the Client | |||
| requires additional MNP delegations), it requests the MS to select | requires additional MNP delegations), it requests the MS to select | |||
| MNPs on its behalf and set up the correct routing state. The DHCPv6 | MNPs on its behalf and set up the correct routing state. The DHCPv6 | |||
| service [RFC8415] supports this requirement. | service [RFC8415] supports this requirement. | |||
| When a Client requires the MS to select MNPs, it sends an RS message | When a Client requires the MS to select MNPs, it sends an RS message | |||
| with source set to a TMP-ULA. If the Client requires only a single | with source set to a {TLA,XLA}-RND. If the Client requires only a | |||
| MNP delegation, it can then include a OMNI Node Identification sub- | single MNP delegation, it can then include a OMNI Node Identification | |||
| option plus an OMNI Neighbor Coordination sub-option with Preflen set | sub-option plus an OMNI Neighbor Coordination sub-option with Preflen | |||
| to the length of the desired MNP. If the Client requires multiple | set to the length of the desired MNP. If the Client requires | |||
| MNP delegations and/or more complex DHCPv6 services, it instead | multiple MNP delegations and/or more complex DHCPv6 services, it | |||
| includes a DHCPv6 Message sub-option containing a Client Identifier, | instead includes a DHCPv6 Message sub-option containing a Client | |||
| one or more IA_PD options and a Rapid Commit option then sets the | Identifier, one or more IA_PD options and a Rapid Commit option then | |||
| 'msg-type' field to "Solicit", and includes a 3 octet 'transaction- | sets the 'msg-type' field to "Solicit", and includes a 3 octet | |||
| id'. The Client then sets the RS destination to link-scoped All- | 'transaction-id'. The Client then sets the RS destination to link- | |||
| Routers multicast and sends the message using OAL encapsulation and | scoped All-Routers multicast and sends the message using OAL | |||
| fragmentation if necessary as discussed above. | encapsulation and fragmentation if necessary as discussed above. | |||
| When the Hub Proxy/Server receives the RS message, it performs OAL | When the Hub Proxy/Server receives the RS message, it performs OAL | |||
| reassembly if necessary. Next, if the RS source is a TMP-ULA and/or | reassembly if necessary. Next, if the RS source is a {TLA,XLA}-RND | |||
| the OMNI option includes a DHCPv6 message sub-option, the Hub Proxy/ | and/or the OMNI option includes a DHCPv6 message sub-option, the Hub | |||
| Server acts as a "Proxy DHCPv6 Client" in a message exchange with the | Proxy/Server acts as a "Proxy DHCPv6 Client" in a message exchange | |||
| locally-resident DHCPv6 server. If the RS did not contain a DHCPv6 | with the locally-resident DHCPv6 server. If the RS did not contain a | |||
| message sub-option, the Hub Proxy/Server generates a DHCPv6 Solicit | DHCPv6 message sub-option, the Hub Proxy/Server generates a DHCPv6 | |||
| message on behalf of the Client using an IA_PD option with the prefix | Solicit message on behalf of the Client using an IA_PD option with | |||
| length set to the OMNI Neighbor Coordination header Preflen value and | the prefix length set to the OMNI Neighbor Coordination header | |||
| with a Client Identifier formed from the OMNI option Node | Preflen value and with a Client Identifier formed from the OMNI | |||
| Identification sub-option; otherwise, the Hub Proxy/Server uses the | option Node Identification sub-option; otherwise, the Hub Proxy/ | |||
| DHCPv6 Solicit message contained in the OMNI option. The Hub Proxy/ | Server uses the DHCPv6 Solicit message contained in the OMNI option. | |||
| Server then sends the DHCPv6 message to the DHCPv6 Server, which | The Hub Proxy/Server then sends the DHCPv6 message to the DHCPv6 | |||
| delegates MNPs and returns a DHCPv6 Reply message with PD parameters. | Server, which delegates MNPs and returns a DHCPv6 Reply message with | |||
| (If the Hub Proxy/Server wishes to defer creation of Client state | PD parameters. (If the Hub Proxy/Server wishes to defer creation of | |||
| until the DHCPv6 Reply is received, it can instead act as a | Client state until the DHCPv6 Reply is received, it can instead act | |||
| Lightweight DHCPv6 Relay Agent per [RFC6221] by encapsulating the | as a Lightweight DHCPv6 Relay Agent per [RFC6221] by encapsulating | |||
| DHCPv6 message in a Relay-forward/reply exchange with Relay Message | the DHCPv6 message in a Relay-forward/reply exchange with Relay | |||
| and Interface ID options. In the process, the Hub Proxy/Server packs | Message and Interface ID options. In the process, the Hub Proxy/ | |||
| any state information needed to return an RA to the Client in the | Server packs any state information needed to return an RA to the | |||
| Relay-forward Interface ID option so that the information will be | Client in the Relay-forward Interface ID option so that the | |||
| echoed back in the Relay-reply.) | information will be echoed back in the Relay-reply.) | |||
| When the Hub Proxy/Server receives the DHCPv6 Reply, it creates MNP- | When the Hub Proxy/Server receives the DHCPv6 Reply, it creates XLA- | |||
| XLAs based on the delegated MNPs and creates OMNI interface MNP-XLA | MNPs based on the delegated MNPs and creates OMNI interface XLA-MNP | |||
| forwarding table entries (i.e., to prompt the dynamic routing | forwarding table entries (i.e., to prompt the dynamic routing | |||
| protocol). The Hub Proxy/Server then sends an RA back to the FHS | protocol). The Hub Proxy/Server then sends an RA back to the FHS | |||
| Proxy/Server with the DHCPv6 Reply message included in an OMNI DHCPv6 | Proxy/Server with the DHCPv6 Reply message included in an OMNI DHCPv6 | |||
| message sub-option. The Hub Proxy/Server sets the RA destination | message sub-option. The Hub Proxy/Server sets the RA destination | |||
| address to the RS source address, sets the RA source address to its | address to the RS source address, sets the RA source address to its | |||
| own RND-ULA, performs OAL encapsulation and fragmentation, performs | own ULA, performs OAL encapsulation and fragmentation, performs L2 | |||
| L2 encapsulation and sends the RA to the Client via the FHS Proxy/ | encapsulation and sends the RA to the Client via the FHS Proxy/Server | |||
| Server as discussed above. | as discussed above. | |||
| When the FHS Proxy/Server receives the RA, it changes the RA | When the FHS Proxy/Server receives the RA, it changes the RA | |||
| destination address to the MNP-ULA for the Client within its own ULA | destination address to the ULA-MNP for the Client within its own ULA | |||
| subnet prefix then forwards the RA to the Client. When the Client | subnet prefix then forwards the RA to the Client. When the Client | |||
| receives the RA, it reassembles and discards the OAL encapsulation | receives the RA, it reassembles and discards the OAL encapsulation | |||
| then creates a default route, assigns Subnet Router Anycast addresses | then creates a default route, assigns Subnet Router Anycast addresses | |||
| and uses the RA destination address or DHCPv6-delegated MNP to | and uses the RA destination address or DHCPv6-delegated MNP to | |||
| automatically configure its primary MNP-ULA. The Client will then | automatically configure its primary ULA-MNP. The Client will then | |||
| use these primary MNP-based addresses as the source address of any | use these primary MNP-based addresses as the source address of any | |||
| IPv6 ND messages it sends as long as it retains ownership of the MNP. | IPv6 ND messages it sends as long as it retains ownership of the MNP. | |||
| Note: when the Hub Proxy/Server is also the FHS Proxy/Server, it | Note: when the Hub Proxy/Server is also the FHS Proxy/Server, it | |||
| forwards the RA message directly to the Client with the destination | forwards the RA message directly to the Client with the destination | |||
| set to the Client's MNP-ULA (i.e., instead of forwarding via another | set to the Client's ULA-MNP (i.e., instead of forwarding via another | |||
| Proxy/Server). | Proxy/Server). | |||
| 15.4. OMNI Link Extension | 15.4. OMNI Link Extension | |||
| Clients can provide an OMNI link ingress point for other nodes on | Clients can provide an OMNI link ingress point for other nodes on | |||
| their (downstream) ENETs that also act as Clients. When Client A has | their (downstream) ENETs that also act as Clients. When Client A has | |||
| already coordinated with an (upstream) ANET/INET Proxy/Server, Client | already coordinated with an (upstream) ANET/INET Proxy/Server, Client | |||
| B on an ENET serviced by Client A can send OAL-encapsulated RS | B on an ENET serviced by Client A can send OAL-encapsulated RS | |||
| messages with addresses set the same as specified in Section 15.2. | messages with addresses set the same as specified in Section 15.2. | |||
| When Client A receives the RS message, it infers from the OAL | When Client A receives the RS message, it infers from the OAL | |||
| encapsulation that Client B is seeking to establish itself as a | encapsulation that Client B is seeking to establish itself as a | |||
| Client instead of just a simple ENET Host. | Client instead of just a simple ENET Host. | |||
| Client A then returns an RA message the same as a Proxy/Server would | Client A then returns an RA message the same as a Proxy/Server would | |||
| do as specified in Section 15.2 except that it instead uses its own | do as specified in Section 15.2 except that it instead uses its own | |||
| MNP-ULA as the RA and OAL source addresses and performs (recursive) | ULA-MNP as the RA and OAL source addresses and performs (recursive) | |||
| DHCPv6 Prefix Delegation. The MNP delegation in the RA message must | DHCPv6 Prefix Delegation. The MNP delegation in the RA message must | |||
| be a sub-MNP from the MNP delegated to Client A. For example, if | be a sub-MNP from the MNP delegated to Client A. For example, if | |||
| Client A receives the MNP 2001:db8:1000::/48 it can provide a sub- | Client A receives the MNP 2001:db8:1000::/48 it can provide a sub- | |||
| delegation such as 2001:db8:1000:2000::/56 to Client B. Client B can | delegation such as 2001:db8:1000:2000::/56 to Client B. Client B can | |||
| in turn sub-delegate 2001:db8:1000:2000::/56 to its own ENET(s), | in turn sub-delegate 2001:db8:1000:2000::/56 to its own ENET(s), | |||
| where there may be a further prospective Client C that would in turn | where there may be a further prospective Client C that would in turn | |||
| request OMNI link services via Client B. | request OMNI link services via Client B. | |||
| To support this Client-to-Client chaining, Clients send IPv6 ND | To support this Client-to-Client chaining, Clients send IPv6 ND | |||
| messages addressed to the OMNI link anycast address via their ANET/ | messages addressed to the OMNI link anycast address via their ANET/ | |||
| skipping to change at page 112, line 13 ¶ | skipping to change at page 112, line 5 ¶ | |||
| and react to failures so that cached information is re-established | and react to failures so that cached information is re-established | |||
| through alternate paths. Proactive NUD control messaging is carried | through alternate paths. Proactive NUD control messaging is carried | |||
| only over well-connected ground domain networks (i.e., and not low- | only over well-connected ground domain networks (i.e., and not low- | |||
| end links such as aeronautical radios) and can therefore be tuned for | end links such as aeronautical radios) and can therefore be tuned for | |||
| rapid response. | rapid response. | |||
| FHS Proxy/Servers perform proactive NUD for Hub Proxy/Servers for | FHS Proxy/Servers perform proactive NUD for Hub Proxy/Servers for | |||
| which there are currently active Clients. If a Hub Proxy/Server | which there are currently active Clients. If a Hub Proxy/Server | |||
| fails, the FHS Proxy/Server can quickly inform Clients of the outage | fails, the FHS Proxy/Server can quickly inform Clients of the outage | |||
| by sending multicast RA messages. The FHS Proxy/Server sends RA | by sending multicast RA messages. The FHS Proxy/Server sends RA | |||
| messages to Clients with source set to the RND-ULA of the Hub, with | messages to Clients with source set to the ULA of the Hub, with | |||
| destination address set to All-Nodes multicast (ff02::1) [RFC4291] | destination address set to All-Nodes multicast (ff02::1) [RFC4291] | |||
| and with Router Lifetime set to 0. | and with Router Lifetime set to 0. | |||
| The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA | The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA | |||
| messages separated by small delays [RFC4861]. Any Clients that have | messages separated by small delays [RFC4861]. Any Clients that have | |||
| been using the (now defunct) Hub Proxy/Server will receive the RA | been using the (now defunct) Hub Proxy/Server will receive the RA | |||
| messages. | messages. | |||
| 19. Transition Considerations | 19. Transition Considerations | |||
| skipping to change at page 116, line 8 ¶ | skipping to change at page 116, line 7 ¶ | |||
| Client to receive a constant MNP that travels with the Client | Client to receive a constant MNP that travels with the Client | |||
| wherever it moves. For example, this would allow air traffic | wherever it moves. For example, this would allow air traffic | |||
| controllers to easily track aircraft, etc. In other cases, however | controllers to easily track aircraft, etc. In other cases, however | |||
| (e.g., intelligent transportation systems), the Client may be willing | (e.g., intelligent transportation systems), the Client may be willing | |||
| to sacrifice a modicum of efficiency in order to have time-varying | to sacrifice a modicum of efficiency in order to have time-varying | |||
| MNPs that can be changed every so often to defeat adversarial | MNPs that can be changed every so often to defeat adversarial | |||
| tracking. | tracking. | |||
| The prefix delegation services discussed in Section 15.3 allows | The prefix delegation services discussed in Section 15.3 allows | |||
| Clients that desire time-varying MNPs to obtain short-lived prefixes | Clients that desire time-varying MNPs to obtain short-lived prefixes | |||
| to send RS messages with a TMP-ULA source address and/or with an OMNI | to send RS messages with a {TLA,XLA}-RND source address and/or with | |||
| option with DHCPv6 Option sub-options. The Client would then be | an OMNI option with DHCPv6 Option sub-options. The Client would then | |||
| obligated to renumber its internal networks whenever its MNP (and | be obligated to renumber its internal networks whenever its MNP (and | |||
| therefore also its OMNI address) changes. This should not present a | therefore also its OMNI address) changes. This should not present a | |||
| challenge for Clients with automated network renumbering services, | challenge for Clients with automated network renumbering services, | |||
| but may disrupt persistent sessions that would prefer to use a | but may disrupt persistent sessions that would prefer to use a | |||
| constant address. | constant address. | |||
| 22. (H)HITs and Temporary ULA (TMP-ULA)s | 22. (H)HITs and Temporary ULA (TLA)s | |||
| Clients that generate (H)HITs but do not have pre-assigned MNPs can | Clients that generate (H)HITs but do not have pre-assigned MNPs can | |||
| request MNP delegations by issuing IPv6 ND messages that use the | request MNP delegations by issuing IPv6 ND messages that use the | |||
| (H)HIT instead of a TMP-ULA. For example, when a Client creates an | (H)HIT instead of a TLA. For example, when a Client creates an RS | |||
| RS message it can set the source to a (H)HIT and destination to link- | message it can set the source to a (H)HIT and destination to link- | |||
| scoped All-Routers multicast. The IPv6 ND message includes an OMNI | scoped All-Routers multicast. The IPv6 ND message includes an OMNI | |||
| option with a HIP message sub-option, and need not include a Node | option with a HIP message sub-option, and need not include a Node | |||
| Identification sub-option if the Client's (H)HIT appears in the HIP | Identification sub-option if the Client's (H)HIT appears in the HIP | |||
| message. The Client then encapsulates the message in an IPv6 header | message. The Client then encapsulates the message in an IPv6 header | |||
| with the (H)HIT as the source address. The Client then sends the | with the (H)HIT as the source address. The Client then sends the | |||
| message as specified in Section 15.2. | message as specified in Section 15.2. | |||
| When the Hub Proxy/Server receives the RS message, it notes that the | When the Hub Proxy/Server receives the RS message, it notes that the | |||
| source was a (H)HIT, then invokes the DHCPv6 protocol to request an | source was a (H)HIT, then invokes the DHCPv6 protocol to request an | |||
| MNP prefix delegation while using the (H)HIT (in the form of a DUID) | MNP prefix delegation while using the (H)HIT (in the form of a DUID) | |||
| as the Client Identifier. The Hub Proxy/Server then prepares an RA | as the Client Identifier. The Hub Proxy/Server then prepares an RA | |||
| message with source address set to its own RND-ULA and destination | message with source address set to its own ULA and destination set to | |||
| set to the source of the RS message. The Hub Proxy/Server next | the source of the RS message. The Hub Proxy/Server next includes an | |||
| includes an OMNI option with a HIP message sub-option and any DHCPv6 | OMNI option with a HIP message sub-option and any DHCPv6 prefix | |||
| prefix delegation parameters. The Proxy/Server finally encapsulates | delegation parameters. The Proxy/Server finally encapsulates the RA | |||
| the RA in an OAL header with source address set to its own RND-ULA | in an OAL header with source address set to its own ULA and | |||
| and destination set to the RS OAL source address, then returns the | destination set to the RS OAL source address, then returns the | |||
| encapsulated RA to the Client either directly or by way of the FHS | encapsulated RA to the Client either directly or by way of the FHS | |||
| Proxy/Server as a proxy. | Proxy/Server as a proxy. | |||
| Clients can also use (H)HITs and/or TMP-ULAs for direct Client-to- | Clients can also use (H)HITs and/or TLAs for direct Client-to-Client | |||
| Client communications outside the context of any OMNI link supporting | communications outside the context of any OMNI link supporting | |||
| infrastructure. When two Clients encounter one another they can use | infrastructure. When two Clients encounter one another they can use | |||
| their (H)HITs and/or TMP-ULAs as original IPv6 packet source and | their (H)HITs and/or TLAs as original IPv6 packet source and | |||
| destination addresses to support direct communications. Clients can | destination addresses to support direct communications. Clients can | |||
| also inject their (H)HITs and/or TMP-ULAs into an IPv6 multihop | also inject their (H)HITs and/or TLAs into an IPv6 multihop routing | |||
| routing protocol to enable multihop communications as discussed in | protocol to enable multihop communications as discussed in | |||
| Section 15.2. Clients can further exchange other IPv6 ND messages | Section 15.2. Clients can further exchange other IPv6 ND messages | |||
| using their (H)HITs and/or TMP-ULAs as source and destination | using their (H)HITs and/or TLAs as source and destination addresses. | |||
| addresses. | ||||
| Lastly, when Clients are within the coverage range of OMNI link | Lastly, when Clients are within the coverage range of OMNI link | |||
| infrastructure a case could be made for injecting (H)HITs and/or TMP- | infrastructure a case could be made for injecting (H)HITs and/or TLAs | |||
| ULAs into the global MS routing system. For example, when the Client | into the global MS routing system. For example, when the Client | |||
| sends an RS to an FHS Proxy/Server it could include a request to | sends an RS to an FHS Proxy/Server it could include a request to | |||
| inject the (H)HIT / TMP-ULA into the routing system instead of | inject the (H)HIT / TLA into the routing system instead of requesting | |||
| requesting an MNP prefix delegation. This would potentially enable | an MNP prefix delegation. This would potentially enable OMNI link- | |||
| OMNI link-wide communications using only (H)HITs or TMP-ULAs, and not | wide communications using only (H)HITs or TLAs, and not MNPs. This | |||
| MNPs. This document notes the opportunity, but makes no | document notes the opportunity, but makes no recommendation. | |||
| recommendation. | ||||
| 23. Address Selection | 23. Address Selection | |||
| Clients assign LLAs to the OMNI interface, but do not use LLAs as | Clients assign LLAs to the OMNI interface, but do not use LLAs as | |||
| IPv6 ND message source/destination addresses nor for addressing | IPv6 ND message source/destination addresses nor for addressing | |||
| ordinary original IP packets exchanged with OMNI link neighbors. | ordinary original IP packets exchanged with OMNI link neighbors. | |||
| Clients use MNP-ULAs as source/destination IPv6 addresses in the | Clients use ULA-MNPs as source/destination IPv6 addresses in the | |||
| encapsulation headers of OAL packets and use MNP-XLAs as the IPv6 | encapsulation headers of OAL packets and use XLA-MNPs as the IPv6 | |||
| source addresses of the IPv6 ND messages themselves. Clients use | source addresses of the IPv6 ND messages themselves. Clients use | |||
| TMP-ULAs when an MNP is not available, or as source/destination IPv6 | TLAs when an MNP is not available, or as source/destination IPv6 | |||
| addresses for communications within a MANET/VANET local area. | addresses for communications within a MANET/VANET local area. | |||
| Clients can also use (H)HITs instead of ULAs for local communications | Clients can also use (H)HITs instead of ULAs for local communications | |||
| when operation outside the context of a specific ULA domain and/or | when operation outside the context of a specific ULA domain and/or | |||
| source address attestation is necessary. | source address attestation is necessary. | |||
| Clients use MNP-based GUAs as original IP packet source and | Clients use MNP-based GUAs as original IP packet source and | |||
| destination addresses for communications with Internet destinations | destination addresses for communications with Internet destinations | |||
| when they are within range of OMNI link supporting infrastructure | when they are within range of OMNI link supporting infrastructure | |||
| that can inject the MNP into the routing system. Clients can also | that can inject the MNP into the routing system. Clients can also | |||
| use MNP-based GUAs within multihop routing regions that are currently | use MNP-based GUAs within multihop routing regions that are currently | |||
| disconnected from infrastructure as long as the corresponding MNP- | disconnected from infrastructure as long as the corresponding ULA- | |||
| ULAs have been injected into the routing system. | MNPs have been injected into the routing system. | |||
| Clients use anycast GUAs as OAL and/or L2 encapsulation destination | Clients use anycast GUAs as OAL and/or L2 encapsulation destination | |||
| addresses for RS messages used to discover the nearest FHS Proxy/ | addresses for RS messages used to discover the nearest FHS Proxy/ | |||
| Server. When the Proxy/Server returns a solicited RA, it must also | Server. When the Proxy/Server returns a solicited RA, it must also | |||
| use the same anycast address as the RA OAL/L2 encapsulation source in | use the same anycast address as the RA OAL/L2 encapsulation source in | |||
| order to successfully traverse any NATs in the path. The Client | order to successfully traverse any NATs in the path. The Client | |||
| should then immediately transition to using the FHS Proxy/Server's | should then immediately transition to using the FHS Proxy/Server's | |||
| discovered unicast OAL/L2 address as the destination in order to | discovered unicast OAL/L2 address as the destination in order to | |||
| minimize dependence on the Proxy/Server's use of an anycast source | minimize dependence on the Proxy/Server's use of an anycast source | |||
| address. | address. | |||
| skipping to change at page 128, line 36 ¶ | skipping to change at page 128, line 36 ¶ | |||
| 1998. | 1998. | |||
| [CRC] Jain, R., "Error Characteristics of Fiber Distributed Data | [CRC] Jain, R., "Error Characteristics of Fiber Distributed Data | |||
| Interface (FDDI), IEEE Transactions on Communications", | Interface (FDDI), IEEE Transactions on Communications", | |||
| August 1990. | August 1990. | |||
| [I-D.ietf-drip-rid] | [I-D.ietf-drip-rid] | |||
| Moskowitz, R., Card, S. W., Wiethuechter, A., and A. | Moskowitz, R., Card, S. W., Wiethuechter, A., and A. | |||
| Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft | Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft | |||
| System Remote ID (UAS RID)", Work in Progress, Internet- | System Remote ID (UAS RID)", Work in Progress, Internet- | |||
| Draft, draft-ietf-drip-rid-22, 13 April 2022, | Draft, draft-ietf-drip-rid-24, 24 April 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-drip-rid- | <https://www.ietf.org/archive/id/draft-ietf-drip-rid- | |||
| 22.txt>. | 24.txt>. | |||
| [I-D.ietf-intarea-tunnels] | [I-D.ietf-intarea-tunnels] | |||
| Touch, J. and M. Townsley, "IP Tunnels in the Internet | Touch, J. and M. Townsley, "IP Tunnels in the Internet | |||
| Architecture", Work in Progress, Internet-Draft, draft- | Architecture", Work in Progress, Internet-Draft, draft- | |||
| ietf-intarea-tunnels-10, 12 September 2019, | ietf-intarea-tunnels-10, 12 September 2019, | |||
| <https://www.ietf.org/archive/id/draft-ietf-intarea- | <https://www.ietf.org/archive/id/draft-ietf-intarea- | |||
| tunnels-10.txt>. | tunnels-10.txt>. | |||
| [I-D.ietf-ipwave-vehicular-networking] | [I-D.ietf-ipwave-vehicular-networking] | |||
| Jeong, J. (., "IPv6 Wireless Access in Vehicular | Jeong, J. (., "IPv6 Wireless Access in Vehicular | |||
| Environments (IPWAVE): Problem Statement and Use Cases", | Environments (IPWAVE): Problem Statement and Use Cases", | |||
| Work in Progress, Internet-Draft, draft-ietf-ipwave- | Work in Progress, Internet-Draft, draft-ietf-ipwave- | |||
| vehicular-networking-28, 30 March 2022, | vehicular-networking-28, 30 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-ietf-ipwave- | <https://www.ietf.org/archive/id/draft-ietf-ipwave- | |||
| vehicular-networking-28.txt>. | vehicular-networking-28.txt>. | |||
| [I-D.templin-6man-aero] | [I-D.templin-6man-aero] | |||
| Templin, F. L., "Automatic Extended Route Optimization | Templin, F. L., "Automatic Extended Route Optimization | |||
| (AERO)", Work in Progress, Internet-Draft, draft-templin- | (AERO)", Work in Progress, Internet-Draft, draft-templin- | |||
| 6man-aero-42, 9 April 2022, | 6man-aero-45, 22 April 2022, | |||
| <https://www.ietf.org/archive/id/draft-templin-6man-aero- | <https://www.ietf.org/archive/id/draft-templin-6man-aero- | |||
| 42.txt>. | 45.txt>. | |||
| [I-D.templin-6man-fragrep] | [I-D.templin-6man-fragrep] | |||
| Templin, F. L., "IPv6 Fragment Retransmission and Path MTU | Templin, F. L., "IPv6 Fragment Retransmission and Path MTU | |||
| Discovery Soft Errors", Work in Progress, Internet-Draft, | Discovery Soft Errors", Work in Progress, Internet-Draft, | |||
| draft-templin-6man-fragrep-07, 29 March 2022, | draft-templin-6man-fragrep-07, 29 March 2022, | |||
| <https://www.ietf.org/archive/id/draft-templin-6man- | <https://www.ietf.org/archive/id/draft-templin-6man- | |||
| fragrep-07.txt>. | fragrep-07.txt>. | |||
| [I-D.templin-6man-lla-type] | [I-D.templin-6man-lla-type] | |||
| Templin, F. L., "The IPv6 Link-Local Address Type Field", | Templin, F. L., "The IPv6 Link-Local Address Type Field", | |||
| End of changes. 100 change blocks. | ||||
| 381 lines changed or deleted | 377 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||