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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/