draft-templin-intarea-omni2-04.txt | draft-templin-intarea-omni2-05.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 | |||
Updates: 4291 (if approved) 20 March 2024 | Updates: 4291 (if approved) 27 March 2024 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: 21 September 2024 | Expires: 28 September 2024 | |||
Transmission of IP Packets over Overlay Multilink Network (OMNI) | Transmission of IP Packets over Overlay Multilink Network (OMNI) | |||
Interfaces | Interfaces | |||
draft-templin-intarea-omni2-04 | draft-templin-intarea-omni2-05 | |||
Abstract | Abstract | |||
Air/land/sea/space mobile nodes (e.g., aircraft of various | Air/land/sea/space mobile nodes (e.g., aircraft of various | |||
configurations, terrestrial vehicles, seagoing vessels, space | configurations, terrestrial vehicles, seagoing vessels, space | |||
systems, enterprise wireless devices, pedestrians with cell phones, | systems, enterprise wireless devices, pedestrians with cell phones, | |||
etc.) communicate with networked correspondents over wireless and/or | etc.) communicate with networked correspondents over wireless and/or | |||
wired-line data links and configure mobile routers to connect end | wired-line data links and configure mobile routers to connect end | |||
user networks. This document presents a multilink virtual interface | user networks. This document presents a multilink virtual interface | |||
specification that enables mobile nodes to coordinate with a network- | specification that enables mobile nodes to coordinate with a network- | |||
skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 45 ¶ | |||
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 21 September 2024. | This Internet-Draft will expire on 28 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 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 3, line 11 ¶ | skipping to change at page 3, line 11 ¶ | |||
11. Node Identification . . . . . . . . . . . . . . . . . . . . . 71 | 11. Node Identification . . . . . . . . . . . . . . . . . . . . . 71 | |||
12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 72 | 12. Address Mapping - Unicast . . . . . . . . . . . . . . . . . . 72 | |||
12.1. The OMNI Option . . . . . . . . . . . . . . . . . . . . 73 | 12.1. The OMNI Option . . . . . . . . . . . . . . . . . . . . 73 | |||
12.2. OMNI Sub-Options . . . . . . . . . . . . . . . . . . . . 74 | 12.2. OMNI Sub-Options . . . . . . . . . . . . . . . . . . . . 74 | |||
12.2.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 76 | 12.2.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 76 | |||
12.2.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 77 | 12.2.2. PadN . . . . . . . . . . . . . . . . . . . . . . . . 77 | |||
12.2.3. Node Identification . . . . . . . . . . . . . . . . 77 | 12.2.3. Node Identification . . . . . . . . . . . . . . . . 77 | |||
12.2.4. Authentication . . . . . . . . . . . . . . . . . . . 79 | 12.2.4. Authentication . . . . . . . . . . . . . . . . . . . 79 | |||
12.2.5. Window Synchronization . . . . . . . . . . . . . . . 80 | 12.2.5. Window Synchronization . . . . . . . . . . . . . . . 80 | |||
12.2.6. Neighbor Control . . . . . . . . . . . . . . . . . . 81 | 12.2.6. Neighbor Control . . . . . . . . . . . . . . . . . . 81 | |||
12.2.7. Interface Attributes . . . . . . . . . . . . . . . . 83 | 12.2.7. Interface Attributes . . . . . . . . . . . . . . . . 82 | |||
12.2.8. Traffic Selector . . . . . . . . . . . . . . . . . . 87 | 12.2.8. Traffic Selector . . . . . . . . . . . . . . . . . . 86 | |||
12.2.9. AERO Forwarding Parameters . . . . . . . . . . . . . 89 | 12.2.9. AERO Forwarding Parameters . . . . . . . . . . . . . 88 | |||
12.2.10. Geo Coordinates . . . . . . . . . . . . . . . . . . 94 | 12.2.10. Geo Coordinates . . . . . . . . . . . . . . . . . . 93 | |||
12.2.11. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | 12.2.11. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | |||
Message . . . . . . . . . . . . . . . . . . . . . . . 94 | Message . . . . . . . . . . . . . . . . . . . . . . . 93 | |||
12.2.12. PIM-SM Message . . . . . . . . . . . . . . . . . . . 95 | 12.2.12. PIM-SM Message . . . . . . . . . . . . . . . . . . . 94 | |||
12.2.13. Host Identity Protocol (HIP) Message . . . . . . . . 96 | 12.2.13. Host Identity Protocol (HIP) Message . . . . . . . . 95 | |||
12.2.14. QUIC-TLS Message . . . . . . . . . . . . . . . . . . 98 | 12.2.14. QUIC-TLS Message . . . . . . . . . . . . . . . . . . 97 | |||
12.2.15. Fragmentation Report (FRAGREP) . . . . . . . . . . . 98 | 12.2.15. Fragmentation Report (FRAGREP) . . . . . . . . . . . 97 | |||
12.2.16. ICMPv6 Error . . . . . . . . . . . . . . . . . . . . 100 | 12.2.16. ICMPv6 Error . . . . . . . . . . . . . . . . . . . . 99 | |||
12.2.17. Proxy/Server Departure . . . . . . . . . . . . . . . 100 | 12.2.17. Proxy/Server Departure . . . . . . . . . . . . . . . 99 | |||
12.2.18. Sub-Type Extension . . . . . . . . . . . . . . . . . 101 | 12.2.18. Sub-Type Extension . . . . . . . . . . . . . . . . . 100 | |||
13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 104 | 13. Address Mapping - Multicast . . . . . . . . . . . . . . . . . 103 | |||
14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 105 | 14. Multilink Conceptual Sending Algorithm . . . . . . . . . . . 104 | |||
14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 105 | 14.1. Multiple OMNI Interfaces . . . . . . . . . . . . . . . . 104 | |||
14.2. Client-Proxy/Server Loop Prevention . . . . . . . . . . 106 | 14.2. Client-Proxy/Server Loop Prevention . . . . . . . . . . 105 | |||
15. Router Discovery and Prefix Delegation . . . . . . . . . . . 107 | 15. Router Discovery and Prefix Delegation . . . . . . . . . . . 106 | |||
15.1. Window Synchronization . . . . . . . . . . . . . . . . . 117 | 15.1. Window Synchronization . . . . . . . . . . . . . . . . . 115 | |||
15.2. Router Discovery in IP Multihop and IPv4-Only | 15.2. Router Discovery in IP Multihop and IPv4-Only | |||
Networks . . . . . . . . . . . . . . . . . . . . . . . . 118 | Networks . . . . . . . . . . . . . . . . . . . . . . . . 116 | |||
15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 120 | 15.3. DHCPv6-based Prefix Registration . . . . . . . . . . . . 119 | |||
15.4. OMNI Link Extension . . . . . . . . . . . . . . . . . . 121 | 15.4. OMNI Link Extension . . . . . . . . . . . . . . . . . . 119 | |||
16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 122 | 16. Secure Redirection . . . . . . . . . . . . . . . . . . . . . 120 | |||
17. Proxy/Server Resilience . . . . . . . . . . . . . . . . . . . 122 | 17. Proxy/Server Resilience . . . . . . . . . . . . . . . . . . . 121 | |||
18. Detecting and Responding to Proxy/Server Failures . . . . . . 123 | 18. Detecting and Responding to Proxy/Server Failures . . . . . . 121 | |||
19. Transition Considerations . . . . . . . . . . . . . . . . . . 123 | 19. Transition Considerations . . . . . . . . . . . . . . . . . . 122 | |||
20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 124 | 20. OMNI Interfaces on Open Internetworks . . . . . . . . . . . . 122 | |||
21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 126 | 21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . . . 125 | |||
22. Address Selection . . . . . . . . . . . . . . . . . . . . . . 127 | 22. Address Selection . . . . . . . . . . . . . . . . . . . . . . 125 | |||
23. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 127 | 23. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 126 | |||
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 127 | 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126 | |||
24.1. Protocol Numbers Registry . . . . . . . . . . . . . . . 128 | 24.1. Protocol Numbers Registry . . . . . . . . . . . . . . . 126 | |||
24.2. IEEE 802 Numbers Registry . . . . . . . . . . . . . . . 128 | 24.2. IEEE 802 Numbers Registry . . . . . . . . . . . . . . . 126 | |||
24.3. IPv4 Special-Purpose Address Registry . . . . . . . . . 128 | 24.3. IPv4 Special-Purpose Address Registry . . . . . . . . . 126 | |||
24.4. IPv6 Neighbor Discovery Option Formats Registry . . . . 128 | 24.4. IPv6 Neighbor Discovery Option Formats Registry . . . . 127 | |||
24.5. Ethernet Numbers Registry . . . . . . . . . . . . . . . 128 | 24.5. Ethernet Numbers Registry . . . . . . . . . . . . . . . 127 | |||
24.6. ICMPv6 Code Fields . . . . . . . . . . . . . . . . . . . 129 | 24.6. ICMPv6 Code Fields . . . . . . . . . . . . . . . . . . . 127 | |||
24.7. ICMPv4 PTB Messages . . . . . . . . . . . . . . . . . . 129 | 24.7. ICMPv4 PTB Messages . . . . . . . . . . . . . . . . . . 127 | |||
24.8. OMNI Option Sub-Types (New Registry) . . . . . . . . . . 129 | 24.8. OMNI Option Sub-Types (New Registry) . . . . . . . . . . 128 | |||
24.9. OMNI Node Identification ID-Types (New Registry) . . . . 130 | 24.9. OMNI Node Identification ID-Types (New Registry) . . . . 128 | |||
24.10. OMNI Geo Coordinates Types (New Registry) . . . . . . . 131 | 24.10. OMNI Geo Coordinates Types (New Registry) . . . . . . . 129 | |||
24.11. OMNI Option Sub-Type Extensions (New Registry) . . . . . 131 | 24.11. OMNI Option Sub-Type Extensions (New Registry) . . . . . 129 | |||
24.12. OMNI RFC4380 UDP/IP Header Option Types (New | 24.12. OMNI RFC4380 UDP/IP Header Option Types (New | |||
Registry) . . . . . . . . . . . . . . . . . . . . . . . 131 | Registry) . . . . . . . . . . . . . . . . . . . . . . . 130 | |||
24.13. OMNI RFC6081 UDP/IP Trailer Option Types (New | 24.13. OMNI RFC6081 UDP/IP Trailer Option Types (New | |||
Registry) . . . . . . . . . . . . . . . . . . . . . . . 132 | Registry) . . . . . . . . . . . . . . . . . . . . . . . 130 | |||
24.14. ICMPv6 Parameters - Trust Anchor Option . . . . . . . . 132 | 24.14. ICMPv6 Parameters - Trust Anchor Option . . . . . . . . 131 | |||
24.15. Additional Considerations . . . . . . . . . . . . . . . 133 | 24.15. Additional Considerations . . . . . . . . . . . . . . . 131 | |||
25. Security Considerations . . . . . . . . . . . . . . . . . . . 133 | 25. Security Considerations . . . . . . . . . . . . . . . . . . . 131 | |||
26. Implementation Status . . . . . . . . . . . . . . . . . . . . 134 | 26. Implementation Status . . . . . . . . . . . . . . . . . . . . 133 | |||
27. Document Updates . . . . . . . . . . . . . . . . . . . . . . 135 | 27. Document Updates . . . . . . . . . . . . . . . . . . . . . . 133 | |||
28. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 135 | 28. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 133 | |||
29. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 | 29. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 | |||
29.1. Normative References . . . . . . . . . . . . . . . . . . 137 | 29.1. Normative References . . . . . . . . . . . . . . . . . . 135 | |||
29.2. Informative References . . . . . . . . . . . . . . . . . 139 | 29.2. Informative References . . . . . . . . . . . . . . . . . 137 | |||
Appendix A. IPv4 Reassembly Checksum Algorithm . . . . . . . . . 150 | Appendix A. IPv4 Reassembly Checksum Algorithm . . . . . . . . . 148 | |||
Appendix B. IPv6 Compatible Addresses . . . . . . . . . . . . . 150 | Appendix B. IPv6 Compatible Addresses . . . . . . . . . . . . . 148 | |||
Appendix C. IPv6 ND Message Authentication and Integrity . . . . 151 | Appendix C. IPv6 ND Message Authentication and Integrity . . . . 149 | |||
Appendix D. VDL Mode 2 Considerations . . . . . . . . . . . . . 152 | Appendix D. VDL Mode 2 Considerations . . . . . . . . . . . . . 150 | |||
Appendix E. Client-Proxy/Server Isolation Through Link-Layer | Appendix E. Client-Proxy/Server Isolation Through Link-Layer | |||
Address Mapping . . . . . . . . . . . . . . . . . . . . . 153 | Address Mapping . . . . . . . . . . . . . . . . . . . . . 151 | |||
Appendix F. Change Log . . . . . . . . . . . . . . . . . . . . . 153 | Appendix F. Change Log . . . . . . . . . . . . . . . . . . . . . 151 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 154 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 152 | |||
1. Introduction | 1. Introduction | |||
Air/land/sea/space mobile nodes (e.g., aircraft of various | Air/land/sea/space mobile nodes (e.g., aircraft of various | |||
configurations, terrestrial vehicles, seagoing vessels, space | configurations, terrestrial vehicles, seagoing vessels, space | |||
systems, enterprise wireless devices, pedestrians with cellphones, | systems, enterprise wireless devices, pedestrians with cellphones, | |||
etc.) configure mobile routers with multiple interface connections to | etc.) configure mobile routers with multiple interface connections to | |||
wireless and/or wired-line data links. These data links may have | wireless and/or wired-line data links. These data links may have | |||
diverse performance, cost and availability properties that can change | diverse performance, cost and availability properties that can change | |||
dynamically according to mobility patterns, flight phases, proximity | dynamically according to mobility patterns, flight phases, proximity | |||
skipping to change at page 11, line 7 ¶ | skipping to change at page 11, line 7 ¶ | |||
over one or more INETs and their connected (M)ANETs/ENETs. An | over one or more INETs and their connected (M)ANETs/ENETs. An | |||
OMNI link may comprise multiple distinct "segments" joined by L2 | OMNI link may comprise multiple distinct "segments" joined by L2 | |||
forwarding devices the same as for any link; the addressing plans | forwarding devices the same as for any link; the addressing plans | |||
in each segment may be mutually exclusive and managed by different | in each segment may be mutually exclusive and managed by different | |||
administrative entities. Proxy/Servers and other infrastructure | administrative entities. Proxy/Servers and other infrastructure | |||
elements extend the link to support communications between Clients | elements extend the link to support communications between Clients | |||
as single-hop neighbors. | as single-hop neighbors. | |||
OMNI link segment | OMNI link segment | |||
a Proxy/Server and all of its constituent Clients within any | a Proxy/Server and all of its constituent Clients within any | |||
attached local networks. When the local networks of multiple | attached local networks is considered as a leaf OMNI link segment, | |||
Proxy/Servers overlap (e.g., due to network mobility), they | with each leaf interconnected via intermediate links and "bridge" | |||
combine to form a larger OMNI link segment but with no changes to | nodes. When the local networks of multiple leaf segments overlap | |||
Client-to-Proxy/Server relationships. The OMNI link consists of | (e.g., due to network mobility), they combine to form a larger | |||
the concatenation of all OMNI link segments, with Proxy/Servers | OMNI link segment but with no changes to Client-to-Proxy/Server | |||
acting as "bridges" that connect the segments. | relationships. The OMNI link consists of the concatenation of all | |||
OMNI link leaf and intermediate segments. | ||||
OMNI interface | OMNI interface | |||
a node's attachment to an OMNI link, and configured over one or | a node's attachment to an OMNI link, and configured over one or | |||
more underlay interfaces. If there are multiple OMNI links in an | more underlay interfaces. If there are multiple OMNI links in an | |||
OMNI domain, a separate OMNI interface is configured for each | OMNI domain, a separate OMNI interface is configured for each | |||
link. The OMNI interface configures a Maximum Transmission Unit | link. The OMNI interface configures a Maximum Transmission Unit | |||
(MTU) and an Effective MTU to Receive (EMTU_R) the same as any | (MTU) and an Effective MTU to Receive (EMTU_R) the same as any | |||
interface. | interface. | |||
OMNI Adaptation Layer (OAL) | OMNI Adaptation Layer (OAL) | |||
skipping to change at page 13, line 45 ¶ | skipping to change at page 13, line 45 ¶ | |||
a longer IP prefix delegated from an MSP (e.g., | a longer IP prefix delegated from an MSP (e.g., | |||
2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and assigned to a | 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and assigned to a | |||
Client. Clients receive MNPs from MAP Proxy/Servers and sub- | Client. Clients receive MNPs from MAP Proxy/Servers and sub- | |||
delegate them to routers, Hosts and other Clients located in | delegate them to routers, Hosts and other Clients located in | |||
ENETs. | ENETs. | |||
Stable Network Prefix (SNP) | Stable Network Prefix (SNP) | |||
a global IP and unique-local IP prefix pair assigned to one or | a global IP and unique-local IP prefix pair assigned to one or | |||
more Proxy/Servers that connect local (M)ANETs or INET Client | more Proxy/Servers that connect local (M)ANETs or INET Client | |||
groups to the rest of the OMNI link. Clients request address | groups to the rest of the OMNI link. Clients request address | |||
delegations from the SNP that can be used to support global | delegations from the SNP that can be used to support global and | |||
communications. Clients communicate internally within (M)ANETs | local-scoped communications. Clients communicate internally | |||
and INET groups using IPv6 Unique Local Addresses (ULAs) assigned | within (M)ANETs and INET groups using IPv6 Unique Local Addresses | |||
in correspondence to SNP Globally Unique Addresses (GUAs) made | (ULAs) assigned in 1x1 correspondence to SNP Globally Unique | |||
visible to external peers through IP network address/prefix | Addresses (GUAs) made visible to external peers through IP network | |||
translation | address/prefix translation | |||
[RFC6145][RFC6146][RFC6147][I-D.bctb-6man-rfc6296-bis]. | [RFC6145][RFC6146][RFC6147][I-D.bctb-6man-rfc6296-bis]. | |||
Subnet Router Anycast (SRA) Address | Subnet Router Anycast (SRA) Address | |||
An IPv6 address taken from an MNP or SNP in which the remainder of | An IPv6 address taken from an MNP or SNP in which the remainder of | |||
the address beyond the final bit of the prefix is set to the value | the address beyond the final bit of the prefix is set to the value | |||
"all-zeros". For example, the SRA for 2001:db8:1::/48 is simply | "all-zeros". For example, the SRA for 2001:db8:1::/48 is simply | |||
2001:db8:1:: (i.e., with the 80 least significant bits set to 0). | 2001:db8:1:: (i.e., with the 80 least significant bits set to 0). | |||
For IPv4, the IPv6 SRA corresponding to the IPv4 prefix | For IPv4, the IPv6 SRA corresponding to the IPv4 prefix | |||
192.0.2.0/24 is 2002:V4ADDR::/40, where "V4ADDR" is the | 192.0.2.0/24 is 2002:V4ADDR::/40, where "V4ADDR" is the | |||
hexadecimal value corresponding to 192.0.2.0 per [RFC3056]. | hexadecimal value corresponding to 192.0.2.0 per [RFC3056]. | |||
skipping to change at page 81, line 38 ¶ | skipping to change at page 81, line 38 ¶ | |||
by a 3-octet Window size. The TCP (ACK, RST, SYN) flags are used | by a 3-octet Window size. The TCP (ACK, RST, SYN) flags are used | |||
for TCP-like window synchronization, while the TCP (CWR, ECE, URG, | for TCP-like window synchronization, while the TCP (CWR, ECE, URG, | |||
PSH, FIN) flags are unused. The OPT flag (discussed in | PSH, FIN) flags are unused. The OPT flag (discussed in | |||
Section 6.7) is an OMNI-specific replacement for the TCP URG flag, | Section 6.7) is an OMNI-specific replacement for the TCP URG flag, | |||
and the four remaining unused flags appear as reserved (RES). | and the four remaining unused flags appear as reserved (RES). | |||
Together, these fields support the OAL window synchronization | Together, these fields support the OAL window synchronization | |||
services specified in Section 6.7. | services specified in Section 6.7. | |||
12.2.6. Neighbor Control | 12.2.6. Neighbor Control | |||
IPv6 ND messages that need to assert/request an MNP prefix length or | IPv6 ND messages that need to assert neighbor control flags can | |||
assert neighbor control flags can include a simple Neighbor Control | include a Neighbor Control sub-option formatted as follows: | |||
sub-option instead of a full DHCPv6 message and/or other large sub- | ||||
options. The Neighbor Control sub-option is formatted as follows: | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | |N|A|R|S| | | | | |N|A|R|S| | | | |||
| S-Type=5| Sub-length=N | Preflen |U|R|P|N| Resv1 | | | S-Type=5| Sub-length=N |U|R|P|N| Resv1 | Reserved2 | | |||
| | | |D|R|T|R| | | | | |D|R|T|R| | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | Reserved3 | Reserved4 | | |||
| Reserved2 | Reserved3 | Reserved4 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 25: Neighbor Control | Figure 25: Neighbor Control | |||
* Sub-Type is set to 5. If multiple instances appear in OMNI | * Sub-Type is set to 5. If multiple instances appear in OMNI | |||
options of the same message, the first is processed and all others | options of the same message, the first is processed and all others | |||
are ignored. | are ignored. | |||
* Sub-Length is set to a value N between 1 and 5; if any other value | * Sub-Length is set to a value N between 1 and 4; if any other value | |||
appears the sub-option is ignored. The Sub-Length value | appears the sub-option is ignored. | |||
determines the number of Preflen/flag bit fields that follow. | ||||
* Preflen is an 1-octet field that determines the length of a | ||||
subject MNP. Values 1 through 64 specify a valid MNP length; any | ||||
other value that appears must be ignored. Nodes should only | ||||
accept Preflen values in authentic IPv6 ND messages received | ||||
through trusted neighbors, since untrusted neighbors may assert | ||||
Preflen values they are not authorized to use. Preflen is | ||||
interpreted according to the specific IPv6 ND message type as | ||||
follows: | ||||
- For RS messages, when the source address contains an MNP | ||||
Preflen refers to the RS source address; otherwise it | ||||
determines the MNP delegation length the Client wishes to | ||||
receive from the service. | ||||
- For RA messages, Preflen refers to the MNP found in the RA | ||||
destination address. | ||||
- For NS messages, Preflen refers to the MNP found in the NS | ||||
source address. | ||||
- For NA messages, Preflen refers to the MNP found in the Target | ||||
Address field within the NA message body. | ||||
- For Redirect messages, Preflen refers to the MNP found in the | ||||
Destination Address field within the Redirect message body. | ||||
* For Sub-length values larger than 1, a first octet containing | * Clients set the Neighbor Unreachability Detection (NUD), Address | |||
neighbor control flags plus up to 3 additional octets follow. | ||||
Clients set the Neighbor Unreachability Detection (NUD), Address | ||||
Resolution Responder (ARR) and Report (RPT) flags in RS messages | Resolution Responder (ARR) and Report (RPT) flags in RS messages | |||
to control the operation of their Proxy/Server neighbors as | to control the operation of their Proxy/Server neighbors as | |||
discussed in Section 15. Nodes set the Synchronous (u)NA Required | discussed in Section 15. Nodes set the Synchronous (u)NA Required | |||
(SNR) flag in non-solicitation IPv6 ND messages (i.e., solicited/ | (SNR) flag in non-solicitation IPv6 ND messages (i.e., solicited/ | |||
unsolicited NA/RA and Redirects) for which they require a | unsolicited NA/RA and Redirects) for which they require a | |||
synchronous (but technically "unsolicited") NA reply (see: | synchronous (but technically "unsolicited") NA reply (see: | |||
[I-D.templin-intarea-aero2]). The next 4 bits following the | [I-D.templin-intarea-aero2]). | |||
neighbor control flags are (Reserved1) and up to 3 additional flag | ||||
octets (Reserved2 - Reserved4) follow. Any included Reserved | * The next 4 bits following the neighbor control flags are | |||
(Reserved1) and up to 3 additional flag octets (Reserved2 - | ||||
Reserved4) follow according to Sub-Length. Any included Reserved | ||||
flags must be set to zero on transmission and ignored on reception | flags must be set to zero on transmission and ignored on reception | |||
(future specifications may define new values). | (future specifications may define new values). | |||
12.2.7. Interface Attributes | 12.2.7. Interface Attributes | |||
The Interface Attributes sub-option provides neighbors with | The Interface Attributes sub-option provides neighbors with | |||
forwarding information for the multilink conceptual sending algorithm | forwarding information for the multilink conceptual sending algorithm | |||
discussed in Section 14. Neighbors use the forwarding information to | discussed in Section 14. Neighbors use the forwarding information to | |||
select among potentially multiple candidate underlay interfaces that | select among potentially multiple candidate underlay interfaces that | |||
can be used to forward carrier packets to the neighbor based on | can be used to forward carrier packets to the neighbor based on | |||
skipping to change at page 107, line 10 ¶ | skipping to change at page 106, line 10 ¶ | |||
segment. Proxy/Servers support this hair pinning according to | segment. Proxy/Servers support this hair pinning according to | |||
[I-D.bctb-6man-rfc6296-bis], however ULA-to-ULA addressing between | [I-D.bctb-6man-rfc6296-bis], however ULA-to-ULA addressing between | |||
peer nodes within the same OMNI link segment is preferred whenever | peer nodes within the same OMNI link segment is preferred whenever | |||
possible. | possible. | |||
15. Router Discovery and Prefix Delegation | 15. Router Discovery and Prefix Delegation | |||
Clients engage their FHS Proxy/Servers and the MS by sending RS | Clients engage their FHS Proxy/Servers and the MS by sending RS | |||
messages with OMNI options under the assumption that one or more | messages with OMNI options under the assumption that one or more | |||
Proxy/Server will process the message and respond. The RS message is | Proxy/Server will process the message and respond. The RS message is | |||
received by a FHS Proxy/Server, which may in turn forward a proxyed | received by a FHS Proxy/Server, which in turn forwards a proxyed copy | |||
copy of the RS to a MAP Proxy/Server located on the same or different | to a MAP Proxy/Server located on the same or different SRT segment if | |||
SRT segment. The MAP Proxy/Server then returns an RA message either | the Client requires MNP service. The MAP Proxy/Server then returns | |||
directly to the Client or via the original FHS Proxy/Server acting as | an RA message either directly to the Client or via the original FHS | |||
a proxy. | Proxy/Server acting as a proxy. | |||
To support Client to service coordination, OMNI defines flag bits in | To support Client to service coordination, OMNI defines flag bits in | |||
the OMNI Neighbor Coordination sub-option discussed in Figure 25. | the OMNI Neighbor Coordination sub-option discussed in Figure 25. | |||
Clients set or clear the NUD, ARR and/or RPT flags in RS messages as | Clients set or clear the NUD, ARR and/or RPT flags in RS messages as | |||
directives to the Mobility Service FHS and MAP Proxy/Servers. Proxy/ | directives to the Mobility Service FHS/MAP Proxy/Servers. Proxy/ | |||
Servers interpret the flags as follows: | Servers interpret the flags as follows: | |||
* When an FHS Proxy/Server forwards or processes an RS with the NUD | * When an FHS Proxy/Server forwards or processes an RS with the NUD | |||
flag set, it responds directly to future NS Neighbor | flag set, it responds directly to future NS Neighbor | |||
Unreachability Detection (NUD) messages with the Client as the | Unreachability Detection (NUD) messages with the Client as the | |||
target by returning NA(NUD) replies; otherwise, it forwards | target by returning NA(NUD) replies; otherwise, it forwards | |||
NS(NUD) messages to the Client. | NS(NUD) messages to the Client. | |||
* When the MAP Proxy/Server receives an RS with the ARR flag set, it | * When the MAP Proxy/Server receives an RS with the ARR flag set, it | |||
responds directly to future NS Address Resolution (AR) messages | responds directly to future NS Address Resolution (AR) messages | |||
skipping to change at page 108, line 52 ¶ | skipping to change at page 107, line 52 ¶ | |||
OMNI interface also transitions to UP. When all underlay interfaces | OMNI interface also transitions to UP. When all underlay interfaces | |||
transition to DOWN, the OMNI interface also transitions to DOWN. | transition to DOWN, the OMNI interface also transitions to 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 an initial set of underlay interfaces that are also UP | to register an initial set of underlay interfaces that are also UP | |||
and to optionally register/request an MNP. The Client sends | and to optionally register/request an MNP. The Client sends | |||
additional RS messages to refresh lifetimes and to register/ | additional RS messages to refresh lifetimes and to register/ | |||
deregister underlay interfaces as they transition to UP or DOWN. The | deregister underlay interfaces as they transition to UP or DOWN. The | |||
Client's OMNI interface sends initial RS messages over an UP underlay | Client's OMNI interface sends initial RS messages over an UP underlay | |||
interface with source set to a ULA delegation for the local OMNI link | interface with source set to a ULA delegation for the local OMNI link | |||
segment if it has one (otherwise to its HHIT)s and with destination | segment if it has one (otherwise with source set to the unspecified | |||
set to either the SRA GUA of a specific (MAP) Proxy/Server or link- | address "::" per [RFC4861]) and with destination set to either the | |||
scoped All-Routers multicast. The Client includes an OMNI option per | SRA GUA of a specific (MAP) Proxy/Server or link-scoped All-Routers | |||
Section 12 with a Neighbor Control sub-option with the RS NUD, ARR | multicast. The Client includes an OMNI option per Section 12 with a | |||
and RPT flags set or cleared as necessary, with an OMNI Window | Neighbor Control sub-option with the RS NUD, ARR and RPT flags set or | |||
Coordination sub-option, a DHCPv6 Solicit sub-option with IA_NA and | cleared as necessary, with an OMNI Window Coordination sub-option, a | |||
(optionally) IA_PD DHCPv6 options, an Interface Attributes sub-option | DHCPv6 Solicit sub-option with IA_NA and (optionally) IA_PD DHCPv6 | |||
for the underlay interface, and with any other necessary OMNI sub- | options, an Interface Attributes sub-option for the underlay | |||
options such as authentication, Proxy/Server Departure, etc. The | interface, and with any other necessary OMNI sub-options such as | |||
OMNI interface finally sets or clears the Interface Attributes FMT- | authentication, Proxy/Server Departure, etc. The OMNI interface | |||
Forward and FMT-Mode bits according to the behavior it would like to | finally sets or clears the Interface Attributes FMT-Forward and FMT- | |||
receive from the FHS Proxy/Server as described in Section 12.2.7. | Mode bits according to the behavior it would like to receive from the | |||
FHS Proxy/Server as described in Section 12.2.7. | ||||
The Client next prepares to forward the RS over the underlay | The Client next prepares to forward the RS over the underlay | |||
interface using OAL encapsulation. The OMNI interface first includes | interface using OAL encapsulation. The OMNI interface first includes | |||
a Nonce and/or Timestamp if necessary, then calculates and sets the | a Nonce and/or Timestamp if necessary, then calculates and sets the | |||
authentication signature followed by the RS message checksum. The | authentication signature followed by the RS message checksum. The | |||
OMNI interface next selects an Identification value (see: | OMNI interface next selects an Identification value (see: | |||
Section 6.7), sets the OAL source address to the ULA corresponding to | Section 6.7), sets the OAL source address to its SNP ULA previously | |||
the RS source if known (otherwise to its HHIT), sets the OAL | delegated by a Proxy/Server (otherwise to its HHIT), sets the OAL | |||
destination to fd00::/8 (i.e., the generic ULA SRA address) or to a | destination to fd00::/8 (i.e., the generic ULA SRA address) or to a | |||
known Proxy/Server SRA ULA/GUA, then performs OAL fragmentation if | known Proxy/Server SRA ULA, then performs OAL fragmentation if | |||
necessary. When L2 encapsulation is used, the Client next includes | necessary. When L2 encapsulation is used, the Client next includes | |||
the discovered FHS Proxy/Server L2ADDR or an anycast address as the | the discovered FHS Proxy/Server L2ADDR or an anycast address as the | |||
L2 destination then fragments if necessary and forwards the resulting | L2 destination then fragments if necessary and forwards the resulting | |||
carrier packet(s) into the underlay network. Note that the Client | carrier packet(s) into the underlay network. Note that the Client | |||
does not yet create a NCE, but instead caches the Identification, | does not yet create a NCE, but instead caches the Identification, | |||
Nonce and/or Timestamp values included in its RS message | Nonce and/or Timestamp values included in its RS message | |||
transmissions to 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 reassembles if necessary, sets aside the L2 headers, verifies | RS it reassembles if necessary, sets aside the L2 headers, verifies | |||
the Identifications, performs OAL reassembly if necessary, sets aside | the Identifications, performs OAL reassembly if necessary, sets aside | |||
the OAL header, then verifies the RS checksum/authentication | the OAL header, then verifies the RS checksum/authentication | |||
signature. The FHS Proxy/Server then creates/updates a NCE indexed | signature. The FHS Proxy/Server then creates/updates a NCE indexed | |||
by the Client's RS source address and caches the OMNI Interface | by the RS ULA source address unless unspecified; otherwise, indexed | |||
Attributes and any Traffic Selector sub-options while also caching | by the OAL source address. The FHS Proxy/Server then caches the OMNI | |||
the L2 (UDP/IP) and OAL source and destination address information. | Interface Attributes and any Traffic Selector sub-options while also | |||
The FHS Proxy/Server then examines the OMNI DHCPv6 sub-option and | caching the L2 (UDP/IP) and OAL source and destination address | |||
looks for DHCPv6 IA_NA options. If one or more are present, the FHS | information. The FHS Proxy/Server then examines the OMNI DHCPv6 sub- | |||
Proxy/Server coordinates with the local DHCPv6 server to either | option and looks for DHCPv6 IA_NA options. If any IA_NA options are | |||
allocate new SNP GUA/ULA pairs or extend the lease lifetime for | present, the FHS Proxy/Server coordinates with the local DHCPv6 | |||
existing SNP GUA/ULA pairs for the Client. The FHS Proxy/Server next | server to either allocate new SNP GUA/ULA pairs or extend the lease | |||
caches the RS NUD flag and Window Synchronization parameters (see: | lifetime for existing SNP GUA/ULA pairs for the Client. The FHS | |||
Section 12.1) then examines the RS destination address. | Proxy/Server next caches the SNP GUA/ULA in the (newly-created) NCE, | |||
then caches the RS NUD flag/Window Synchronization parameters (see: | ||||
Section 12.1) and examines the RS destination address. | ||||
If the destination matches one of its own unicast/anycast addresses | If the destination matches one of its own unicast/anycast addresses | |||
and the OMNI DHCPv6 sub-option includes one or more DHCPv6 IA_PD | and the OMNI DHCPv6 sub-option includes one or more DHCPv6 IA_PD | |||
options, the FHS Proxy/Server assumes the MAP role and acts as a | options, the FHS Proxy/Server assumes the MAP role and acts as a | |||
default router entry point for injecting the Client's MNP(s) into the | default router entry point for injecting the Client's MNP(s) into the | |||
OMNI link routing system (i.e., after performing any necessary prefix | OMNI link routing system (i.e., after performing any necessary prefix | |||
delegation operations). The FHS/MAP Proxy/Server then caches the RS | delegation operations). The FHS/MAP Proxy/Server then caches the RS | |||
ARR and RPT flags to determine its role in processing NS(AR) messages | ARR and RPT flags to determine its role in processing NS(AR) messages | |||
and generating uNA messages (see: Section 12.1). | and generating uNA messages (see: Section 12.1). | |||
skipping to change at page 110, line 27 ¶ | skipping to change at page 109, line 31 ¶ | |||
sub-option with its INET-facing interface information written in the | sub-option with its INET-facing interface information written in the | |||
FMT, SRT and LHS Proxy/Server GUA/L2ADDR fields. The Proxy/Server | FMT, SRT and LHS Proxy/Server GUA/L2ADDR fields. The Proxy/Server | |||
also includes a DHCPv6 Reply sub-option with any IA_NA/IA_PD options | also includes a DHCPv6 Reply sub-option with any IA_NA/IA_PD options | |||
that have been processed/populated by the DHCPv6 exchange(s). | that have been processed/populated by the DHCPv6 exchange(s). | |||
The FHS/MAP Proxy/Server next sets or clears the FMT-Forward and FMT- | The FHS/MAP Proxy/Server next sets or clears the FMT-Forward and FMT- | |||
Mode flags if necessary to convey its capabilities to the Client, | Mode flags if necessary to convey its capabilities to the Client, | |||
noting that it should honor the Client's stated preferences for those | noting that it should honor the Client's stated preferences for those | |||
parameters if possible or override otherwise. The FMT-Forward/Mode | parameters if possible or override otherwise. The FMT-Forward/Mode | |||
flags thereafter remain fixed unless and until a new RS/RA exchange | flags thereafter remain fixed unless and until a new RS/RA exchange | |||
produces different values (see: Section 12.2.7 for further | establishes different values (see: Section 12.2.7 for further | |||
discussion). If the FHS/MAP Proxy/Server's Client-facing interface | discussion). If the FHS/MAP Proxy/Server's Client-facing interface | |||
is different than its INET-facing interface, the Proxy/Server next | is different than its INET-facing interface, the Proxy/Server next | |||
includes a second Interface Attributes sub-option with ifIndex set to | includes a second Interface Attributes sub-option with ifIndex set to | |||
'0', with a unicast L2 address for its Client-facing interface in the | '0', with a unicast L2 address for its Client-facing interface in the | |||
L2ADDR field and with its SRA ULA in the GUA field. | L2ADDR field and with its SRA ULA in the GUA field. | |||
The FHS/MAP Proxy/Server next includes an Origin Indication sub- | The FHS/MAP Proxy/Server next includes an Origin Indication sub- | |||
option that includes the RS L2 source L2ADDR information (see: | option that includes the RS L2 source L2ADDR information (see: | |||
Section 12.2.18.1), then includes any other necessary OMNI sub- | Section 12.2.18.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/MAP Proxy/Server | options). Following the OMNI option(s), the FHS/MAP Proxy/Server | |||
next includes any other necessary RA options including two PIOs with | next includes any other necessary RA options including two PIOs with | |||
(A=0; L=0) that include the ULA and GUA prefixes for the segment per | (A=0; L=0) that include the ULA/GUA SNP prefixes for the segment per | |||
[RFC8028], RIOs with more-specific routes per [RFC4191], Nonce and | [RFC8028], RIOs with more-specific routes per [RFC4191], Nonce and | |||
Timestamp options, etc. The FHS/MAP Proxy/Server then sets the RA | Timestamp options, etc. The FHS/MAP Proxy/Server then sets the RA | |||
source address to its own SRA GUA and destination address to the | source address to its own SRA GUA and destination address to the | |||
(new) SNP ULA for the Client, while also recording the ULA as an | (new) SNP ULA for the Client, then calculates the authentication | |||
(alternate) index to the Client NCE, then calculates the | signature/checksum. The FHS/MAP Proxy/Server finally performs OAL | |||
authentication signature/checksum. The FHS/MAP Proxy/Server finally | encapsulation while setting the source to its own ULA and destination | |||
performs OAL encapsulation while setting the source to its own ULA | to the OAL source that appeared in the RS, then includes an | |||
and destination to the OAL source that appeared in the RS, then | appropriate Identification, performs OAL fragmentation if necessary, | |||
includes an appropriate Identification, performs OAL fragmentation if | performs L2 encapsulation/fragmentation with L2 source and | |||
necessary, performs L2 encapsulation/fragmentation with L2 source and | ||||
destination address information reversed from the RS L2 information | destination address information reversed from the RS L2 information | |||
and returns the resulting carrier packets to the Client over the same | and returns the resulting carrier packets to the Client over the same | |||
underlay interface the RS arrived on. | underlay interface the RS arrived on. | |||
When an FHS Proxy/Server receives an RS with a valid checksum and | When an FHS Proxy/Server receives an RS with a valid checksum and | |||
authentication signature with destination set to link-scoped All- | authentication signature with destination set to link-scoped All- | |||
Routers multicast, it can either assume the MAP role itself the same | Routers multicast, it can either assume the MAP role itself the same | |||
as above or act as a proxy and select the SNP SRA GUA of another | as above or act as a proxy and select the SNP SRA GUA of another | |||
Proxy/Server to serve as the MAP. When an FHS Proxy/Server assumes | Proxy/Server to serve as the MAP. When an FHS Proxy/Server assumes | |||
the proxy role or receives an RS with destination set to the SNP SRA | the proxy role or receives an RS with destination set to the SNP SRA | |||
skipping to change at page 112, line 36 ¶ | skipping to change at page 111, line 18 ¶ | |||
When the FHS Proxy/Server receives the carrier packets it performs L2 | When the FHS Proxy/Server receives the carrier packets it performs L2 | |||
reassembly/decapsulation followed by OAL reassembly/decapsulation to | reassembly/decapsulation followed by OAL reassembly/decapsulation to | |||
obtain the RA message, verifies checksums then updates the OMNI | obtain the RA message, verifies checksums then updates the OMNI | |||
interface NCE for the Client and creates/updates a NCE for the MAP. | interface NCE for the Client and creates/updates a NCE for the MAP. | |||
The FHS Proxy/Server then sets the P flag in the RA flags field | The FHS Proxy/Server then sets the P flag in the RA flags field | |||
[RFC4389] and proxys the RA by changing the OAL source to its SNP SRA | [RFC4389] and proxys the RA by changing the OAL source to its SNP SRA | |||
GUA and changing the OAL destination to the source address from the | GUA and changing the OAL destination to the source address from the | |||
Client's original RS message while also recording any DHCPv6 IA_NA | Client's original RS message while also recording any DHCPv6 IA_NA | |||
SNP GUA/ULA address pairs as alternate indexes into the Client NCE. | SNP GUA/ULA address pairs as alternate indexes into the Client NCE. | |||
The FHS Proxy/Server then includes two PIOs with (A=0; L=0) with the | The FHS Proxy/Server then includes two PIOs with (A=0; L=0) with the | |||
ULA and GUA prefixes for the segment per [RFC8028]. The FHS Proxy/ | SNP ULA/GUA prefixes for the segment per [RFC8028]. The FHS Proxy/ | |||
Server next includes Window Synchronization parameters responsive to | Server next includes Window Synchronization parameters responsive to | |||
those in the Client's RS, an Interface Attributes sub-option with | those in the Client's RS, an Interface Attributes sub-option with | |||
ifIndex '0' and with its Client-facing interface unicast L2 address | ifIndex '0' and with its Client-facing interface unicast L2 address | |||
if necessary (see above), an Origin Indication sub-option with the | if necessary (see above), an Origin Indication sub-option with the | |||
Client's cached L2ADDR and an authentication sub-option if necessary. | Client's cached L2ADDR and an authentication sub-option if necessary. | |||
The FHS Proxy/Server finally includes an Identification value per | The FHS Proxy/Server finally includes an Identification value per | |||
Section 6.7, calculates the authentication signature/checksum, | Section 6.7, calculates the authentication signature/checksum, | |||
performs OAL fragmentation, performs L2 encapsulation/fragmentation | performs OAL fragmentation, performs L2 encapsulation/fragmentation | |||
with addresses taken from the Client's NCE and sends the resulting | with addresses taken from the Client's NCE and sends the resulting | |||
carrier packets via the same underlay interface over which the RS was | carrier packets via the same underlay interface over which the RS was | |||
skipping to change at page 113, line 10 ¶ | skipping to change at page 111, line 41 ¶ | |||
When the Client receives the carrier packets, it performs L2 | When the Client receives the carrier packets, it performs L2 | |||
reassembly/decapsulation followed by OAL reassembly/decapsulation to | reassembly/decapsulation followed by OAL reassembly/decapsulation to | |||
obtain the RA message. The Client next verifies the authentication | obtain the RA message. The Client next verifies the authentication | |||
signature/checksum, then matches the RA message with its previously- | signature/checksum, then matches the RA message with its previously- | |||
sent RS by comparing the RS Sequence Number with the RA | 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 MAP and FHS Proxy/Server and | updates OMNI interface NCEs for both the MAP 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 MAP Proxy/Server SNP SRA GUA and | caches the RA source address as the MAP Proxy/Server SNP SRA GUA and | |||
uses the OAL source address to configure the SNP SRA GUA of this FHS | uses the OAL source address to configure the SNP SRA ULA of this FHS | |||
Proxy/Server. If the Client has multiple underlay interfaces, it | Proxy/Server. The Client also discovers its own SNP ULA by examining | |||
creates additional FHS Proxy/Server NCEs as necessary when it | the RA destination address, discovers its own SNP GUA by examining | |||
receives RAs over those interfaces (noting that multiple of the | the IA_NA DHCPv6 delegated addresses, and discovers the SNP ULA/GUA | |||
Client's underlay interfaces may be serviced by the same or different | PIO prefixes for the OMNI link segment per [RFC8028]. If the Client | |||
FHS Proxy/Servers). The Client finally adds the MAP Proxy/Server SRA | has multiple underlay interfaces, it creates additional FHS Proxy/ | |||
to the default router list if necessary. | Server NCEs as necessary when it receives RAs over those interfaces | |||
(noting that multiple of the Client's underlay interfaces may be | ||||
serviced by the same or different FHS Proxy/Servers). The Client | ||||
finally adds the MAP Proxy/Server SRA GUA 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 ifIndex and Origin Indication | Interface Attributes for its own ifIndex 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 ifIndex '0', the | includes an Interface Attributes sub-option with ifIndex '0', the | |||
Client also caches the L2ADDR as the underlay network-local unicast | Client also caches the L2ADDR 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 L2ADDR information with | Client then compares the Origin Indication L2ADDR information with | |||
skipping to change at page 115, line 16 ¶ | skipping to change at page 113, line 43 ¶ | |||
interface. Therefore, when the network layer sends an RS message the | interface. Therefore, when the network layer sends an RS message the | |||
OMNI interface returns an internally-generated RA message as though | OMNI interface returns an internally-generated RA message as though | |||
the message originated from an IPv6 router. The internally-generated | the message originated from an IPv6 router. The internally-generated | |||
RA message contains configuration information consistent with the | RA message contains configuration information consistent with the | |||
information received from the RAs generated by the MAP Proxy/Server. | information received from the RAs generated by the MAP Proxy/Server. | |||
Whether the OMNI interface IPv6 ND messaging process is initiated | Whether the OMNI interface IPv6 ND messaging process is initiated | |||
from the receipt of an RS message from the network layer or | from the receipt of an RS message from the network layer or | |||
independently of the network layer is an implementation matter. Some | independently of the network layer is an implementation matter. Some | |||
implementations may elect to defer the OMNI interface internal RS/RA | implementations may elect to defer the OMNI interface internal RS/RA | |||
messaging process until an RS is received from the network layer, | messaging process until an RS is received from the network layer, | |||
while others may elect to initiate the process proactively. Still | while others may elect to initiate the process independently. Still | |||
other deployments may elect to administratively disable network layer | other deployments may elect to administratively disable network layer | |||
RS/RA messaging over the OMNI interface, since the messages are not | RS/RA messaging over the OMNI interface, since the messages are not | |||
required to drive the OMNI interface internal RS/RA process. (Note | required to drive the OMNI interface internal RS/RA process. (Note | |||
that this same logic applies to IPv4 implementations that employ | that this same logic applies to IPv4 implementations that employ | |||
"ICMP Router Discovery" [RFC1256].) | "ICMP Router Discovery" [RFC1256].) | |||
Note: The Router Lifetime value in RA messages indicates the time | Note: The Router Lifetime value in RA messages indicates the time | |||
before which the Client must send another RS message over this | before which the Client must send another RS message over this | |||
underlay interface (e.g., 600 seconds), however that timescale may be | underlay interface (e.g., 600 seconds), however that timescale may be | |||
significantly longer than the lifetime the MS has committed to retain | significantly longer than the lifetime the MS has committed to retain | |||
skipping to change at page 117, line 20 ¶ | skipping to change at page 115, line 42 ¶ | |||
between the Client and each FHS Proxy/Server used to contact the MAP | between the Client and each FHS Proxy/Server used to contact the MAP | |||
Proxy/Server, i.e., and not between the Client and the MAP. This is | Proxy/Server, i.e., and not between the Client and the MAP. This is | |||
due to the fact that the MAP Proxy/Server is responsible only for | due to the fact that the MAP 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 MAP. | actions without forwarding Client-initiated data to the MAP. | |||
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 (or a ULA/ | Proxy/Server, it sets the RS source address to its own MNP SRA GUA or | |||
HHIT) and destination address to the ULA of the MAP Proxy/Server (or | SNP ULA and destination address to the SNP SRA ULA of the MAP Proxy/ | |||
to All-Routers multicast in an initial RS), then sets the SYN flag | Server (or to All-Routers multicast in an initial RS), then sets the | |||
and includes an initial Sequence Number for Window Synchronization. | SYN flag and includes an initial Sequence Number for Window | |||
The Client then performs OAL encapsulation/fragmentation using its | Synchronization. The Client then performs OAL encapsulation/ | |||
own MNP (or a ULA/HHIT) as the source and the ULA of the FHS Proxy/ | fragmentation using its own ULA/HHIT as the source and the ULA of the | |||
Server as the destination and includes an Interface Attributes sub- | FHS Proxy/Server as the destination. The Client finally includes an | |||
option then performs L2 encapsulation/fragmentation and sends the | Interface Attributes sub-option then performs L2 encapsulation/ | |||
resulting carrier packets to the FHS Proxy/Server. The FHS Proxy/ | fragmentation and sends the resulting carrier packets to the FHS | |||
Server then performs L2 and OAL reassembly/decapsulation to extract | Proxy/Server. When the FHS Proxy/Server receives the carrier | |||
packets, it performs L2 and OAL reassembly/decapsulation to extract | ||||
the RS message and caches the Window Synchronization parameters then | the RS message and caches the Window Synchronization parameters then | |||
re-encapsulates/fragments with its own ULA as the source and the ULA | re-encapsulates/fragments with its own SNP SRA GUA as the OAL source | |||
of the MAP Proxy/Server as the target. | and the SNP SRA GUA of the MAP Proxy/Server as the OAL destination. | |||
The FHS Proxy/Server then performs L2 encapsulation/fragmentation and | The FHS Proxy/Server then performs L2 encapsulation/fragmentation and | |||
sends the resulting carrier packets via the secured spanning tree to | sends the resulting carrier packets via the secured spanning tree to | |||
the MAP Proxy/Server, which updates the Client's Interface Attributes | the MAP Proxy/Server, which updates the Client's Interface Attributes | |||
and returns a unicast RA message with source set to its own ULA and | and returns a unicast RA message with source set to its own SNP SRA | |||
destination set to the RS source address and with the Client's | GUA and destination set to the RS source address and with the | |||
Interface Attributes echoed. The MAP Proxy/Server then performs OAL | Client's Interface Attributes echoed. The MAP Proxy/Server then | |||
encapsulation/fragmentation using its own ULA as the source and the | performs OAL encapsulation/fragmentation using its own SNP SRA GUA as | |||
ULA of the FHS Proxy/Server as the destination, then performs L2 | the source and the SNP SRA GUA of the FHS Proxy/Server as the | |||
encapsulation/fragmentation and sends the carrier packets via the | destination, then performs L2 encapsulation/fragmentation and sends | |||
secured spanning tree to the FHS Proxy/Server. The FHS Proxy/Server | the carrier packets via the secured spanning tree to the FHS Proxy/ | |||
then proxys the message as discussed in the previous section and | Server. The FHS Proxy/Server then proxys the message as discussed in | |||
includes responsive Window Synchronization information. The FHS | the previous section and includes responsive Window Synchronization | |||
Proxy/Server then forwards the message to the Client which updates | information. The FHS Proxy/Server then forwards the message to the | |||
its window synchronization information for the FHS Proxy/Server as | Client via OAL encapsulation with SNP ULAs which updates its window | |||
necessary. | synchronization 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 ULAs and the ULAs of the | performing RS/RA exchanges between its own ULAs and the ULAs of the | |||
FHS Proxy/Servers without having to disturb the MAP. | FHS Proxy/Servers without having to disturb the MAP. | |||
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 intermediate system | On some *NETs, a Client may be located multiple intermediate system | |||
hops away from the nearest OMNI link Proxy/Server. Clients in | hops away from the nearest OMNI link Proxy/Server. Clients in | |||
multihop networks perform route discovery through the application of | multihop networks perform route discovery through the application of | |||
a routing protocol (e.g., a MANET/VANET routing protocol over | a routing protocol (e.g., a MANET/VANET routing protocol over | |||
omnidirectional wireless interfaces, an inter-domain routing protocol | omnidirectional wireless interfaces, an inter-domain routing protocol | |||
in an enterprise network, etc.) then apply corresponding forwarding | in an enterprise network, etc.) then apply corresponding forwarding | |||
entries to the OMNI interface. Example routing protocols optimized | entries to the OMNI interface. Example routing protocols optimized | |||
for MANET/VANET operations include OSPFv3 [RFC5340] with MANET | for MANET/VANET operations include OSPFv3 [RFC5340] with MANET | |||
Designated Router (OSPF-MDR) extensions [RFC5614], OLSRv2 [RFC7181], | Designated Router (OSPF-MDR) extensions [RFC5614], OLSRv2 [RFC7181], | |||
AODVv2 [I-D.perkins-manet-aodvv2] and others. Clients employ the | AODVv2 [I-D.perkins-manet-aodvv2] and others. Clients employ the | |||
routing protocol according to the link model found in [RFC5889] and | routing protocol according to the link model found in [RFC5889] and | |||
subnet model articulated in [RFC5942]. For unique identification, | subnet model articulated in [RFC5942]. For unique identification, | |||
Clients use an HHIT as a Router ID or set an administrative value | Clients use an HHIT as a Router ID or set an administrative ULA value | |||
that is managed for uniqueness within the MANET/VANET. | that is managed for uniqueness within the MANET/VANET. | |||
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 | |||
HHIT/ULA, and sets the destination to link-scoped All-Routers | ULA or unspecified, and sets the destination to link-scoped All- | |||
multicast or the SRA address of a Proxy/Server the same as discussed | Routers multicast or the SNP SRA GUA of a Proxy/Server the same as | |||
above. The OMNI interface then employs OAL encapsulation, sets the | discussed above. The OMNI interface then employs OAL encapsulation, | |||
OAL source address to its HHIT/ULA and sets the OAL destination to an | sets the OAL source address to its HHIT/ULA and sets the OAL | |||
OMNI IPv6 SRA address based on either a native IPv6 or | destination to an SNP SRA ULA or a 6to4-encapsulated IPv4 address | |||
6to4-encapsulated IPv4 (see: Section 10). | (see: Section 10). | |||
For IPv6-enabled *NETs where the underlay interface observes the | For IPv6-enabled *NETs where the underlay interface observes the | |||
MANET properties discussed above, the Client injects the HHIT/ULA | MANET properties discussed above, the Client injects the HHIT/ULA | |||
into the IPv6 multihop routing system and forwards the message | into the IPv6 multihop routing system and forwards the message | |||
without further encapsulation. Otherwise, the Client encapsulates | without further encapsulation. Otherwise, the Client encapsulates | |||
the message in UDP/IPv6 L2 headers, sets the source to the underlay | the message in UDP/IPv6 L2 headers, sets the source to the underlay | |||
interface IPv6 address and sets the destination to the same OMNI IPv6 | interface IPv6 address and sets the destination to the same SNP SRA | |||
SRA address. The Client then forwards the message into the IPv6 | ULA address. The Client then forwards the message into the IPv6 | |||
multihop routing system which conveys it to the nearest Proxy/Server | multihop routing system which conveys it to the nearest Proxy/Server | |||
that advertises a matching OMNI IPv6 SRA address. If the nearest | that advertises a matching SNP SRA ULA address. If the nearest | |||
Proxy/Server is too busy, it should forward (without Proxying) the | Proxy/Server is too busy, it should forward (without Proxying) the | |||
OAL-encapsulated RS to another nearby Proxy/Server connected to the | OAL-encapsulated RS to another nearby Proxy/Server connected to the | |||
same IPv6 (multihop) network that also advertises the matching OMNI | same IPv6 (multihop) network that also advertises the matching OMNI | |||
IPv6 anycast prefix. | IPv6 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 | |||
TBD3. The Client then forwards the message into the IPv4 multihop | TBD3. The Client then forwards the message into the IPv4 multihop | |||
routing system which conveys it to the nearest Proxy/Server that | routing system which conveys it to the nearest Proxy/Server that | |||
skipping to change at page 120, line 37 ¶ | skipping to change at page 119, line 12 ¶ | |||
not be well positioned to perform multilink selections over multiple | not be well positioned to perform multilink selections over multiple | |||
underlay interfaces on behalf of multihop dependent peers. | underlay interfaces on behalf of multihop dependent peers. | |||
15.3. DHCPv6-based Prefix Registration | 15.3. DHCPv6-based Prefix Registration | |||
When a Client requires SNP ULA/GUA delegations via a specific Proxy/ | When a Client requires SNP ULA/GUA delegations via a specific Proxy/ | |||
Server (or, when the Client requires MNP delegations for the OMNI | Server (or, when the Client requires MNP delegations for the OMNI | |||
link), it invokes the DHCPv6 service [RFC8415] in conjunction with | link), it invokes the DHCPv6 service [RFC8415] in conjunction with | |||
its OMNI RS/RA message exchanges. | its OMNI RS/RA message exchanges. | |||
When a Client requires the MS to delegate PA addresses or PI MNPs, it | When a Client requires the MS to delegate PA ULA/GUA pairs or PI | |||
sends an RS message with source set to an HHIT. If the Client | MNPs, it sends an RS message to a FHS Proxy/Server. If the Client | |||
requires one or more address or MNP delegations, it includes a DHCPv6 | requires one or more address or MNP delegations, it includes a DHCPv6 | |||
Message sub-option containing a Client Identifier, one or more IA_NA/ | Message sub-option containing a Client Identifier, one or more IA_NA/ | |||
IA_PD options and a Rapid Commit option then sets the 'msg-type' | IA_PD options and a Rapid Commit option then sets the 'msg-type' | |||
field to "Solicit" and includes a 3-octet 'transaction-id'. The | field to "Solicit" and includes a 3-octet 'transaction-id'. The | |||
Client then sets the RS destination to link-scoped All-Routers | Client then sets the RS destination to link-scoped All-Routers | |||
multicast and sends the message using OAL encapsulation and | multicast and sends the message using OAL encapsulation and | |||
fragmentation if necessary as discussed above. | fragmentation if necessary as discussed above. | |||
When the FHS/MAP Proxy/Server receives the RS message, it performs | When the FHS/MAP Proxy/Server receives the RS message, it performs | |||
OAL reassembly if necessary. Next, if the OMNI option includes a | OAL reassembly if necessary. Next, if the OMNI option includes a | |||
DHCPv6 message sub-option, the FHS/MAP Proxy/Server acts as a "Proxy | DHCPv6 message sub-option, the FHS/MAP Proxy/Server acts as a "Proxy | |||
DHCPv6 Client" in a message exchange with the locally-resident DHCPv6 | DHCPv6 Client" in a message exchange with the locally-resident DHCPv6 | |||
server. The FHS/MAP Proxy/Server then sends the DHCPv6 message to | server. The FHS/MAP Proxy/Server then sends the DHCPv6 message to | |||
the DHCPv6 Server, which delegates SNP ULA/GUA pairs or MNPs and | the DHCPv6 Server, which delegates SNP ULA/GUA pairs or MNPs and | |||
returns a DHCPv6 Reply message with autoconfiguration parameters. | returns a DHCPv6 Reply message with autoconfiguration parameters. | |||
(If the FHS/MAP Proxy/Server wishes to defer creation of Client state | ||||
until the DHCPv6 Reply is received, it can instead act as a | ||||
Lightweight DHCPv6 Relay Agent per [RFC6221] by encapsulating the | ||||
DHCPv6 message in a Relay-forward/reply exchange with Relay Message | ||||
and Interface ID options. In the process, the FHS/MAP Proxy/Server | ||||
packs any state information needed to return an RA to the Client in | ||||
the Relay-forward Interface ID option so that the information will be | ||||
echoed back in the Relay-reply.) | ||||
When the FHS Proxy/Server receives a DHCPv6 Reply with delegated | When the FHS Proxy/Server receives a DHCPv6 Reply with delegated | |||
addresses, it records the delegated SNP ULA/GUA pairs in the NCE for | addresses, it records the delegated SNP ULA/GUA pairs in the NCE for | |||
the Client, then forwards the RS message to the MAP Proxy/Server for | the Client, then forwards the RS message to the MAP Proxy/Server for | |||
prefix delegation if necessary; otherwise, it returns an immediate RA | prefix delegation if necessary; otherwise, it returns an immediate RA | |||
message to the Client. | message to the Client. | |||
When the MAP Proxy/Server receives a DHCPv6 Reply with delegated | When the MAP Proxy/Server receives a DHCPv6 Reply with delegated | |||
prefixes, it creates OMNI interface MNP forwarding table entries | prefixes, it creates OMNI interface MNP forwarding table entries | |||
(i.e., to prompt the dynamic routing protocol). The MAP Proxy/Server | (i.e., to prompt the dynamic routing protocol). The MAP Proxy/Server | |||
then sends an RA back to the FHS Proxy/Server with the DHCPv6 Reply | then sends an RA back to the FHS Proxy/Server with the DHCPv6 Reply | |||
message included in an OMNI DHCPv6 message sub-option, and the FHS | message included in an OMNI DHCPv6 message sub-option, and the FHS | |||
Proxy/Server returns the RA to the Client. | Proxy/Server returns the RA to the Client. | |||
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) (M)ANET/INET Proxy/Server, | |||
B on an ENET serviced by Client A can send OAL-encapsulated RS | Client 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 SRA as the RA and OAL source addresses and performs (recursive) | MNP SRA GUA as the RA and OAL source addresses and performs | |||
DHCPv6 Prefix Delegation. The MNP delegation in the RA message must | (recursive) DHCPv6 Prefix Delegation. The MNP delegation in the RA | |||
be a sub-MNP from the MNP delegated to Client A. For example, if | message must be a sub-MNP from the MNP delegated to Client A. For | |||
Client A receives the MNP 2001:db8:1000::/48 it can provide a sub- | example, if Client A receives the MNP 2001:db8:1000::/48 it can | |||
delegation such as 2001:db8:1000:2000::/56 to Client B. Client B can | provide a sub-delegation such as 2001:db8:1000:2000::/56 to Client B. | |||
in turn sub-delegate 2001:db8:1000:2000::/56 to its own ENET(s), | Client B can in turn sub-delegate 2001:db8:1000:2000::/56 to its own | |||
where there may be a further prospective Client C that would in turn | ENET(s), where there may be a further prospective Client C that would | |||
request OMNI link services via Client B. | in turn 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 *NET | messages addressed to the OMNI link anycast address via their *NET | |||
(i.e., upstream) interfaces, but advertise the OMNI link anycast | (i.e., upstream) interfaces, but advertise the OMNI link anycast | |||
address into their ENET (i.e., downstream) networks where there may | address into their ENET (i.e., downstream) networks where there may | |||
be further prospective Clients wishing to join the chain. The ENET | be further prospective Clients wishing to join the chain. The ENET | |||
of the upstream Client is therefore seen as an ANET by downstream | of the upstream Client is therefore seen as an ANET by downstream | |||
Clients, and the upstream Client is seen as a Proxy/Server by | Clients, and the upstream Client is seen as a Proxy/Server by | |||
downstream Clients. | downstream Clients. | |||
skipping to change at page 126, line 45 ¶ | skipping to change at page 125, line 17 ¶ | |||
In some use cases, it is desirable, beneficial and efficient for the | In some use cases, it is desirable, beneficial and efficient for the | |||
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 occasionally to defeat adversarial tracking. | MNPs that can be changed occasionally to defeat adversarial 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 an HHIT/ULA source address and/or with an | to send RS messages with an OMNI option with DHCPv6 IA-PD sub- | |||
OMNI option with DHCPv6 Option sub-options. The Client would then be | options. The Client would then be obligated to renumber its internal | |||
obligated to renumber its internal networks whenever its MNP (and | networks whenever its MNPs change. 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. Address Selection | 22. 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/parcels exchanged with OMNI link | ordinary original IP packets/parcels exchanged with OMNI link | |||
neighbors. | neighbors. | |||
skipping to change at page 140, line 41 ¶ | skipping to change at page 138, line 47 ¶ | |||
[I-D.ietf-intarea-tunnels] | [I-D.ietf-intarea-tunnels] | |||
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet | Touch, J. D. 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-13, 26 March 2023, | ietf-intarea-tunnels-13, 26 March 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea- | <https://datatracker.ietf.org/doc/html/draft-ietf-intarea- | |||
tunnels-13>. | tunnels-13>. | |||
[I-D.ietf-tsvwg-udp-options] | [I-D.ietf-tsvwg-udp-options] | |||
Touch, J. D., "Transport Options for UDP", Work in | Touch, J. D., "Transport Options for UDP", Work in | |||
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-31, | Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-32, | |||
4 March 2024, <https://datatracker.ietf.org/doc/html/ | 21 March 2024, <https://datatracker.ietf.org/doc/html/ | |||
draft-ietf-tsvwg-udp-options-31>. | draft-ietf-tsvwg-udp-options-32>. | |||
[I-D.perkins-manet-aodvv2] | [I-D.perkins-manet-aodvv2] | |||
Perkins, C. E., Dowdell, J., Steenbrink, L., and V. | Perkins, C. E., Dowdell, J., Steenbrink, L., and V. | |||
Pritchard, "Ad Hoc On-demand Distance Vector Version 2 | Pritchard, "Ad Hoc On-demand Distance Vector Version 2 | |||
(AODVv2) Routing", Work in Progress, Internet-Draft, | (AODVv2) Routing", Work in Progress, Internet-Draft, | |||
draft-perkins-manet-aodvv2-04, 3 March 2024, | draft-perkins-manet-aodvv2-04, 3 March 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-perkins- | <https://datatracker.ietf.org/doc/html/draft-perkins- | |||
manet-aodvv2-04>. | manet-aodvv2-04>. | |||
[I-D.templin-intarea-aero2] | [I-D.templin-intarea-aero2] | |||
Templin, F., "Automatic Extended Route Optimization | Templin, F., "Automatic Extended Route Optimization | |||
(AERO)", Work in Progress, Internet-Draft, draft-templin- | (AERO)", Work in Progress, Internet-Draft, draft-templin- | |||
intarea-aero2-03, 22 February 2024, | intarea-aero2-04, 26 March 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-templin- | <https://datatracker.ietf.org/doc/html/draft-templin- | |||
intarea-aero2-03>. | intarea-aero2-04>. | |||
[IEEE802.1AX] | [IEEE802.1AX] | |||
"Institute of Electrical and Electronics Engineers, Link | "Institute of Electrical and Electronics Engineers, Link | |||
Aggregation, IEEE Standard 802.1AX-2008, | Aggregation, IEEE Standard 802.1AX-2008, | |||
https://standards.ieee.org/ieee/802.1AX/6768/", 29 May | https://standards.ieee.org/ieee/802.1AX/6768/", 29 May | |||
2020. | 2020. | |||
[IPV4-GUA] Postel, J., "IPv4 Address Space Registry, | [IPV4-GUA] Postel, J., "IPv4 Address Space Registry, | |||
https://www.iana.org/assignments/ipv4-address-space/ipv4- | https://www.iana.org/assignments/ipv4-address-space/ipv4- | |||
address-space.xhtml", 14 December 2020. | address-space.xhtml", 14 December 2020. | |||
skipping to change at page 146, line 15 ¶ | skipping to change at page 144, line 20 ¶ | |||
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van | [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van | |||
Beijnum, "DNS64: DNS Extensions for Network Address | Beijnum, "DNS64: DNS Extensions for Network Address | |||
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, | Translation from IPv6 Clients to IPv4 Servers", RFC 6147, | |||
DOI 10.17487/RFC6147, April 2011, | DOI 10.17487/RFC6147, April 2011, | |||
<https://www.rfc-editor.org/info/rfc6147>. | <https://www.rfc-editor.org/info/rfc6147>. | |||
[RFC6214] Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for | [RFC6214] Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for | |||
IPv6", RFC 6214, DOI 10.17487/RFC6214, April 2011, | IPv6", RFC 6214, DOI 10.17487/RFC6214, April 2011, | |||
<https://www.rfc-editor.org/info/rfc6214>. | <https://www.rfc-editor.org/info/rfc6214>. | |||
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. | ||||
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, | ||||
DOI 10.17487/RFC6221, May 2011, | ||||
<https://www.rfc-editor.org/info/rfc6221>. | ||||
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | |||
(SHA and SHA-based HMAC and HKDF)", RFC 6234, | (SHA and SHA-based HMAC and HKDF)", RFC 6234, | |||
DOI 10.17487/RFC6234, May 2011, | DOI 10.17487/RFC6234, May 2011, | |||
<https://www.rfc-editor.org/info/rfc6234>. | <https://www.rfc-editor.org/info/rfc6234>. | |||
[RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC | [RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC | |||
1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, | 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, | |||
RFC 1644, and RFC 1693 to Historic Status", RFC 6247, | RFC 1644, and RFC 1693 to Historic Status", RFC 6247, | |||
DOI 10.17487/RFC6247, May 2011, | DOI 10.17487/RFC6247, May 2011, | |||
<https://www.rfc-editor.org/info/rfc6247>. | <https://www.rfc-editor.org/info/rfc6247>. | |||
End of changes. 47 change blocks. | ||||
239 lines changed or deleted | 203 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |