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/