| < draft-templin-6man-aero-45.txt | draft-templin-6man-aero-46.txt > | |||
|---|---|---|---|---|
| Network Working Group F. L. Templin, Ed. | Network Working Group F. L. Templin, Ed. | |||
| Internet-Draft Boeing Research & Technology | Internet-Draft Boeing Research & Technology | |||
| Intended status: Informational 22 April 2022 | Intended status: Informational 25 April 2022 | |||
| Expires: 24 October 2022 | Expires: 27 October 2022 | |||
| Automatic Extended Route Optimization (AERO) | Automatic Extended Route Optimization (AERO) | |||
| draft-templin-6man-aero-45 | draft-templin-6man-aero-46 | |||
| Abstract | Abstract | |||
| This document specifies an Automatic Extended Route Optimization | This document specifies an Automatic Extended Route Optimization | |||
| (AERO) service for IP internetworking over Overlay Multilink Network | (AERO) service for IP internetworking over Overlay Multilink Network | |||
| (OMNI) interfaces. AERO/OMNI use an IPv6 link-local address format | (OMNI) interfaces. AERO/OMNI use an IPv6 link-local address format | |||
| that supports operation of the IPv6 Neighbor Discovery (IPv6 ND) | that supports operation of the IPv6 Neighbor Discovery (IPv6 ND) | |||
| protocol. Prefix delegation/registration services are employed for | protocol. Prefix delegation/registration services are employed for | |||
| network admission and to manage the IP forwarding and routing | network admission and to manage the IP forwarding and routing | |||
| systems. Secure multilink operation, mobility management, multicast, | systems. Secure multilink operation, mobility management, multicast, | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| 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 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3. Automatic Extended Route Optimization (AERO) . . . . . . . . 15 | 3. Automatic Extended Route Optimization (AERO) . . . . . . . . 15 | |||
| 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 15 | 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 3.2. The AERO Service over OMNI Links . . . . . . . . . . . . 16 | 3.2. The AERO Service over OMNI Links . . . . . . . . . . . . 16 | |||
| 3.2.1. AERO/OMNI Reference Model . . . . . . . . . . . . . . 16 | 3.2.1. AERO/OMNI Reference Model . . . . . . . . . . . . . . 16 | |||
| 3.2.2. Addressing and Node Identification . . . . . . . . . 20 | 3.2.2. Addressing and Node Identification . . . . . . . . . 20 | |||
| 3.2.3. AERO Routing System . . . . . . . . . . . . . . . . . 21 | 3.2.3. AERO Routing System . . . . . . . . . . . . . . . . . 21 | |||
| 3.2.4. Segment Routing Topologies (SRTs) . . . . . . . . . . 22 | 3.2.4. Segment Routing Topologies (SRTs) . . . . . . . . . . 23 | |||
| 3.2.5. Segment Routing For OMNI Link Selection . . . . . . . 23 | 3.2.5. Segment Routing For OMNI Link Selection . . . . . . . 23 | |||
| 3.3. OMNI Interface Characteristics . . . . . . . . . . . . . 24 | 3.3. OMNI Interface Characteristics . . . . . . . . . . . . . 24 | |||
| 3.4. OMNI Interface Initialization . . . . . . . . . . . . . . 26 | 3.4. OMNI Interface Initialization . . . . . . . . . . . . . . 26 | |||
| 3.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 26 | 3.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 27 | |||
| 3.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 27 | 3.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 27 | |||
| 3.4.3. AERO Host Behavior . . . . . . . . . . . . . . . . . 27 | 3.4.3. AERO Host Behavior . . . . . . . . . . . . . . . . . 28 | |||
| 3.4.4. AERO Gateway Behavior . . . . . . . . . . . . . . . . 28 | 3.4.4. AERO Gateway Behavior . . . . . . . . . . . . . . . . 28 | |||
| 3.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 28 | 3.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 28 | |||
| 3.5.1. OMNI ND Messages . . . . . . . . . . . . . . . . . . 30 | 3.5.1. OMNI ND Messages . . . . . . . . . . . . . . . . . . 30 | |||
| 3.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 32 | 3.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 32 | |||
| 3.5.3. OMNI Neighbor Window Synchronization . . . . . . . . 32 | 3.5.3. OMNI Neighbor Window Synchronization . . . . . . . . 33 | |||
| 3.6. OMNI Interface Encapsulation and Fragmentation . . . . . 33 | 3.6. OMNI Interface Encapsulation and Fragmentation . . . . . 33 | |||
| 3.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 35 | 3.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 36 | |||
| 3.8. OMNI Interface Data Origin Authentication . . . . . . . . 36 | 3.8. OMNI Interface Data Origin Authentication . . . . . . . . 36 | |||
| 3.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 36 | 3.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 37 | |||
| 3.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 37 | 3.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 37 | |||
| 3.10.1. Host Forwarding Algorithm . . . . . . . . . . . . . 38 | 3.10.1. Host Forwarding Algorithm . . . . . . . . . . . . . 39 | |||
| 3.10.2. Client Forwarding Algorithm . . . . . . . . . . . . 39 | 3.10.2. Client Forwarding Algorithm . . . . . . . . . . . . 39 | |||
| 3.10.3. Proxy/Server and Relay Forwarding Algorithm . . . . 40 | 3.10.3. Proxy/Server and Relay Forwarding Algorithm . . . . 40 | |||
| 3.10.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 43 | 3.10.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 43 | |||
| 3.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 44 | 3.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 44 | |||
| 3.12. AERO Mobility Service Coordination . . . . . . . . . . . 47 | 3.12. AERO Mobility Service Coordination . . . . . . . . . . . 47 | |||
| 3.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 47 | 3.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 47 | |||
| 3.12.2. AERO Host and Client Behavior . . . . . . . . . . . 48 | 3.12.2. AERO Host and Client Behavior . . . . . . . . . . . 48 | |||
| 3.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 49 | 3.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 49 | |||
| 3.13. AERO Route Optimization . . . . . . . . . . . . . . . . . 56 | 3.13. AERO Route Optimization . . . . . . . . . . . . . . . . . 56 | |||
| 3.13.1. Multilink Address Resolution . . . . . . . . . . . . 57 | 3.13.1. Multilink Address Resolution . . . . . . . . . . . . 57 | |||
| 3.13.2. Multilink Route Optimization . . . . . . . . . . . . 61 | 3.13.2. Multilink Route Optimization . . . . . . . . . . . . 61 | |||
| 3.13.3. Rapid Commit Route Optimization . . . . . . . . . . 73 | 3.13.3. Rapid Commit Route Optimization . . . . . . . . . . 73 | |||
| 3.13.4. Client/Gateway Route Optimization . . . . . . . . . 74 | 3.13.4. Client/Gateway Route Optimization . . . . . . . . . 73 | |||
| 3.13.5. Client/Client Route Optimization . . . . . . . . . . 76 | 3.13.5. Client/Client Route Optimization . . . . . . . . . . 75 | |||
| 3.13.6. Client-to-Client OMNI Link Extension . . . . . . . . 77 | 3.13.6. Client-to-Client OMNI Link Extension . . . . . . . . 77 | |||
| 3.13.7. Intra-ANET/ENET Route Optimization for AERO Peers . 78 | 3.13.7. Intra-ANET/ENET Route Optimization for AERO Peers . 78 | |||
| 3.14. Neighbor Unreachability Detection (NUD) . . . . . . . . . 78 | 3.14. Neighbor Unreachability Detection (NUD) . . . . . . . . . 78 | |||
| 3.15. Mobility Management and Quality of Service (QoS) . . . . 80 | 3.15. Mobility Management and Quality of Service (QoS) . . . . 80 | |||
| 3.15.1. Mobility Update Messaging . . . . . . . . . . . . . 80 | 3.15.1. Mobility Update Messaging . . . . . . . . . . . . . 80 | |||
| 3.15.2. Announcing Link-Layer Information Changes . . . . . 81 | 3.15.2. Announcing Link-Layer Information Changes . . . . . 81 | |||
| 3.15.3. Bringing New Links Into Service . . . . . . . . . . 82 | 3.15.3. Bringing New Links Into Service . . . . . . . . . . 82 | |||
| 3.15.4. Deactivating Existing Links . . . . . . . . . . . . 82 | 3.15.4. Deactivating Existing Links . . . . . . . . . . . . 82 | |||
| 3.15.5. Moving Between Proxy/Servers . . . . . . . . . . . . 83 | 3.15.5. Moving Between Proxy/Servers . . . . . . . . . . . . 82 | |||
| 3.16. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 84 | 3.16. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 83 | |||
| 3.16.1. Source-Specific Multicast (SSM) . . . . . . . . . . 84 | 3.16.1. Source-Specific Multicast (SSM) . . . . . . . . . . 84 | |||
| 3.16.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 85 | 3.16.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 85 | |||
| 3.16.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 86 | 3.16.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 86 | |||
| 3.17. Operation over Multiple OMNI Links . . . . . . . . . . . 86 | 3.17. Operation over Multiple OMNI Links . . . . . . . . . . . 86 | |||
| 3.18. DNS Considerations . . . . . . . . . . . . . . . . . . . 87 | 3.18. DNS Considerations . . . . . . . . . . . . . . . . . . . 87 | |||
| 3.19. Transition/Coexistence Considerations . . . . . . . . . . 87 | 3.19. Transition/Coexistence Considerations . . . . . . . . . . 87 | |||
| 3.20. Proxy/Server-Gateway Bidirectional Forwarding | 3.20. Proxy/Server-Gateway Bidirectional Forwarding | |||
| Detection . . . . . . . . . . . . . . . . . . . . . . . 88 | Detection . . . . . . . . . . . . . . . . . . . . . . . 88 | |||
| 3.21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 88 | 3.21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 88 | |||
| 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 89 | 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 88 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 89 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 89 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 93 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 93 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 95 | 8.2. Informative References . . . . . . . . . . . . . . . . . 95 | |||
| Appendix A. Non-Normative Considerations . . . . . . . . . . . . 102 | Appendix A. Non-Normative Considerations . . . . . . . . . . . . 102 | |||
| A.1. Implementation Strategies for Route Optimization . . . . 103 | A.1. Implementation Strategies for Route Optimization . . . . 103 | |||
| A.2. Implicit Mobility Management . . . . . . . . . . . . . . 103 | A.2. Implicit Mobility Management . . . . . . . . . . . . . . 103 | |||
| A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 104 | A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 104 | |||
| A.4. AERO Critical Infrastructure Considerations . . . . . . . 104 | A.4. AERO Critical Infrastructure Considerations . . . . . . . 104 | |||
| A.5. AERO Server Failure Implications . . . . . . . . . . . . 105 | A.5. AERO Server Failure Implications . . . . . . . . . . . . 105 | |||
| A.6. AERO Client / Server Architecture . . . . . . . . . . . . 105 | A.6. AERO Client / Server Architecture . . . . . . . . . . . . 105 | |||
| skipping to change at page 10, line 24 ¶ | skipping to change at page 10, line 24 ¶ | |||
| Mobile Network Prefix (MNP) | Mobile Network Prefix (MNP) | |||
| a longer IP prefix delegated from an MSP (e.g., | a longer IP prefix delegated from an MSP (e.g., | |||
| 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and delegated to an | 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and delegated to an | |||
| AERO Client or Relay. | AERO Client or Relay. | |||
| 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 | ||||
| [I-D.templin-6man-omni]. | [I-D.templin-6man-omni]. | |||
| 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 [I-D.templin-6man-omni]. | 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 [I-D.templin-6man-omni]. (Note | |||
| an IPv6 Unique-Local Address that embeds the most significant 64 | that [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 | |||
| [I-D.templin-6man-omni]. (Note that MNP-XLAs can be formed from | document to distinguish them from the ULAs defined here.) | |||
| MNP-LLAs simply 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 [I-D.templin-6man-omni]. | ||||
| Random Unique Local Address (RND-ULA) | ||||
| an IPv6 Unique-Local Address derived from a RND-LLA as discussed | ||||
| in [I-D.templin-6man-omni]. | ||||
| 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 | (TLA-RND) IID as specified in [I-D.templin-6man-omni]. Clients | |||
| use TLAs to bootstrap autoconfiguration in the presence of OMNI | ||||
| link infrastructure or for sustained communications in the absence | ||||
| of infrastructure. (Note that in some environments Clients can | ||||
| instead use a (Hierarchical) Host Identity Tag ((H)HIT) instead of | ||||
| a TLA - see: [I-D.templin-6man-omni].) | ||||
| [I-D.templin-6man-omni]. Clients use TMP-ULAs (and/or MNP-XLAs) | eXtended Local Address (XLA) | |||
| to bootstrap autoconfiguration in the presence of OMNI link | a TLA beginning with fd00::/64 followed by an MNP-based (XLA-MNP) | |||
| infrastructure, while continued use of TMP-ULAs may be necessary | or random (XLA-RND) IID as specified in [I-D.templin-6man-omni]. | |||
| in the absence of infrastructure. (Note that in some environments | An XLA is simply a TLA with an all-0 48-bit value following | |||
| Clients can instead use a (Hierarchical) Host Identity Tag | fd00::/16, and can be used to supply a "wildcard match" for IPv6 | |||
| ((H)HIT) instead of a TMP-ULA - see: [I-D.templin-6man-omni].) | 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.) | ||||
| AERO node | AERO node | |||
| a node that is connected to an OMNI link and participates in the | a node that is connected to an OMNI link and participates in the | |||
| AERO internetworking and mobility service. | AERO internetworking and mobility service. | |||
| AERO Host ("Host") | AERO Host ("Host") | |||
| an AERO node that configures an OMNI interface over an ENET | an AERO node that configures an OMNI interface over an ENET | |||
| underlying interface serviced by an upstream Client. The Host | underlying interface serviced by an upstream Client. The Host | |||
| does not assign an {ADM, MNP}-LLA or -ULA to the OMNI interface, | does not assign an LLA or ULA to the OMNI interface, but instead | |||
| but instead assigns the address taken from the ENET underlying | assigns the address taken from the ENET underlying interface. (As | |||
| interface. (As an implementation matter, the Host may instead | an implementation matter, the Host may instead configure the "OMNI | |||
| configure the "OMNI interface" as a virtual sublayer of the | interface" as a virtual sublayer of the underlay interface | |||
| underlay interface itself.) When an AERO host forwards an | itself.) When an AERO host forwards an original IP packet to | |||
| original IP packet to another AERO node on the same ENET, it uses | another AERO node on the same ENET, it uses simple IP-in-IP | |||
| simple IP-in-IP encapsulation without including an OAL | encapsulation without including an OAL encapsulation header. The | |||
| encapsulation header. The Host is therefore an OMNI link | Host is therefore an OMNI link termination endpoint. | |||
| termination endpoint. | ||||
| AERO Client ("Client") | AERO Client ("Client") | |||
| an AERO node that configures an OMNI interface over one or more | an AERO node that configures an OMNI interface over one or more | |||
| underlay interfaces and requests MNP delegation/registration | underlay interfaces and requests MNP delegation/registration | |||
| service from AERO Proxy/Servers. The Client assigns an MNP-XLA to | service from AERO Proxy/Servers. The Client assigns an XLA-MNP | |||
| the OMNI interface for use in IPv6 ND exchanges with other AERO | (as well as Proxy/Server-specific ULA-MNPs) to the OMNI interface | |||
| nodes and forwards original IP packets to correspondents according | for use in IPv6 ND exchanges with other AERO nodes and forwards | |||
| to OMNI interface neighbor cache state. The Client coordinates | original IP packets to correspondents according to OMNI interface | |||
| with Proxy/Servers and/or other Clients over upstream ANET/INET | neighbor cache state. The Client coordinates with Proxy/Servers | |||
| interfaces and may also provide Proxy/Server services for Hosts | and/or other Clients over upstream ANET/INET interfaces and may | |||
| and/or other Clients over downstream ENET interfaces. | also provide Proxy/Server services for Hosts and/or other Clients | |||
| over downstream ENET interfaces. | ||||
| AERO Proxy/Server ("Proxy/Server") | AERO Proxy/Server ("Proxy/Server") | |||
| a node that provides a proxying service between AERO Clients and | a node that provides a proxying service between AERO Clients and | |||
| external peers on its Client-facing ANET interfaces (i.e., in the | external peers on its Client-facing ANET interfaces (i.e., in the | |||
| same fashion as for an enterprise network proxy) as well as | same fashion as for an enterprise network proxy) as well as | |||
| designated router services for coordination with correspondents on | designated router services for coordination with correspondents on | |||
| its INET-facing interfaces. (Proxy/Servers in the open INET | its INET-facing interfaces. (Proxy/Servers in the open INET | |||
| instead configure only a single INET interface and no ANET | instead configure only a single INET interface and no ANET | |||
| interfaces.) The Proxy/Server configures an OMNI interface and | interfaces.) The Proxy/Server configures an OMNI interface and | |||
| assigns a RND-ULA to support the operation of IPv6 ND services, | assigns a ULA-RND to support the operation of IPv6 ND services, | |||
| while advertising any associated MNPs for which it is acting as a | while advertising any associated MNPs for which it is acting as a | |||
| hub via BGP peerings with AERO Gateways. | hub via BGP peerings with AERO Gateways. | |||
| AERO Relay ("Relay") | AERO Relay ("Relay") | |||
| a Proxy/Server that provides forwarding services between nodes | a Proxy/Server that provides forwarding services between nodes | |||
| reached via the OMNI link and correspondents on other links/ | reached via the OMNI link and correspondents on other links/ | |||
| networks. AERO Relays configure an OMNI interface, assign a RND- | networks. AERO Relays configure an OMNI interface, assign a ULA- | |||
| ULA and maintain BGP peerings with Gateways the same as Proxy/ | RND and maintain BGP peerings with Gateways the same as Proxy/ | |||
| Servers and run a dynamic routing protocol to discover any non-MNP | Servers and run a dynamic routing protocol to discover any non-MNP | |||
| IP GUA routes in service on other links/networks. The Relay | IP GUA routes in service on other links/networks. The Relay | |||
| advertises the MSP(s) to its other links/networks, and | advertises the MSP(s) to its other links/networks, and | |||
| redistributes routes discovered on other links/networks into the | redistributes routes discovered on other links/networks into the | |||
| OMNI link BGP routing system the same as for Proxy/Servers. | OMNI link BGP routing system the same as for Proxy/Servers. | |||
| (Relays that connect to major Internetworks such as the global | (Relays that connect to major Internetworks such as the global | |||
| IPv6 or IPv4 Internet can also be configured to advertise | IPv6 or IPv4 Internet can also be configured to advertise | |||
| "default" routes into the OMNI link BGP routing system.) | "default" routes into the OMNI link BGP routing system.) | |||
| AERO Gateway ("Gateway") | AERO Gateway ("Gateway") | |||
| skipping to change at page 20, line 17 ¶ | skipping to change at page 20, line 17 ¶ | |||
| in the "Catenet Model for Internetworking" [IEN48]; especially | in the "Catenet Model for Internetworking" [IEN48]; especially | |||
| Figure 2 follows directly from the illustrations in [IEN48-2]. The | Figure 2 follows directly from the illustrations in [IEN48-2]. The | |||
| Catenet model inspired the global public Internet as it is known | Catenet model inspired the global public Internet as it is known | |||
| today, while AERO applies the Catenet concepts to provide true | today, while AERO applies the Catenet concepts to provide true | |||
| Multinet services for the future architecture. | Multinet services for the future architecture. | |||
| 3.2.2. Addressing and Node Identification | 3.2.2. Addressing and Node Identification | |||
| AERO nodes on OMNI links use the Link-Local Address (LLA) prefix | AERO nodes on OMNI links use the Link-Local Address (LLA) prefix | |||
| fe80::/64 [RFC4291] to assign LLAs to the OMNI interface in a latent | fe80::/64 [RFC4291] to assign LLAs to the OMNI interface in a latent | |||
| state and do not employ LLAs for any operational purposes. (Instead, | state and do not employ LLAs for any operational purposes (instead, | |||
| the LLAs are assigned solely to satisfy the requirements of | the LLAs are assigned solely to satisfy the requirements of | |||
| [RFC4861].) AERO Clients configure LLAs constructed from MNPs (i.e., | [RFC4861]). AERO Clients configure LLAs constructed from MNPs (i.e., | |||
| "MNP-LLAs") while AERO infrastructure nodes construct LLAs based on | "LLA-MNPs") while AERO infrastructure nodes construct LLAs based on | |||
| 56-bit random values ("RND-LLAs") per [I-D.templin-6man-omni]. Non- | 56-bit random values ("LLA-RNDs") per [I-D.templin-6man-omni]. Non- | |||
| MNP routes are also represented the same as for MNPs, but may include | MNP routes are also represented the same as for MNPs, but may include | |||
| a prefix that is not properly covered by an MSP. | a prefix that is not properly covered by an MSP. | |||
| AERO nodes also use the Unique Local Address (ULA) prefix fd00::/8 | AERO nodes also use the Unique Local Address (ULA) prefix fd00::/8 | |||
| followed by a pseudo-random 40-bit Global ID to form the prefix | followed by a pseudo-random 40-bit Global ID to form the prefix | |||
| {ULA}::/48, then include a 16-bit Subnet ID '*' to form the prefix | {ULA}::/48, then include a 16-bit Subnet ID '*' to form the prefix | |||
| {ULA*}::/64 [RFC4291]. The AERO node then uses the prefix | {ULA*}::/64 [RFC4291]. The AERO node then uses the prefix | |||
| {ULA*}::/64 to form "MNP-ULAs" or "RND-ULA"s as specified in | {ULA*}::/64 to form "ULA-MNPs" or "ULA-RNDs" as specified in | |||
| [I-D.templin-6man-omni] to support OAL addressing. (The prefix | [I-D.templin-6man-omni] to support OAL addressing. (The prefix | |||
| {ULA*}::/64 appearing alone and with no suffix represents "default" | {ULA*}::/64 appearing alone and with no suffix represents "default" | |||
| for that prefix.) AERO Clients also use MNP-based eXtended Local | for that prefix.) | |||
| Addresses (MNP-XLAs) and Temporary ULAs (TMP-ULAs) constructed per | ||||
| [I-D.templin-6man-omni], where TMP-ULAs are typically used only in | AERO Clients also use Temporary Local Addresses (TLAs) and eXtended | |||
| initial control message exchanges until a stable MNP-ULA is assigned | Local Addresses (XLAs) constructed per [I-D.templin-6man-omni], where | |||
| (and may sometimes be used for sustained communications within a | TLAs are distinguished from ordinary ULAs based on the prefix | |||
| local routing region). | fd00::/16 and XLAs are distinguished from ULAs/TLAs based on the | |||
| prefix fd00::/64. Clients use TLA-RNDs only in initial control | ||||
| message exchanges until a stable MNP is assigned, but may sometimes | ||||
| also use them for sustained communications within a local routing | ||||
| region. AERO nodes use XLA-MNPs to provide forwarding information | ||||
| for the global routing table as well as IPv6 ND message and OAL | ||||
| addressing information. | ||||
| AERO MSPs, MNPs and non-MNP routes are typically based on Global | AERO MSPs, MNPs and non-MNP routes are typically based on Global | |||
| Unicast Addresses (GUAs), but in some cases may be based on private- | Unicast Addresses (GUAs), but in some cases may be based on IPv4 | |||
| use addresses. A GUA block is also reserved for OMNI link anycast | private addresses [RFC1918] or IPv6 ULA-D's [RFC4193]. A GUA block | |||
| purposes. See [I-D.templin-6man-omni] for a full specification of | is also reserved for OMNI link anycast purposes. See | |||
| LLAs, ULAs and GUAs used by AERO nodes on OMNI links. | [I-D.templin-6man-omni] for a full specification of LLAs, ULAs, TLAs, | |||
| XLAs, GUAs and anycast addresses used by AERO nodes on OMNI links. | ||||
| Finally, AERO Clients and Proxy/Servers configure node identification | Finally, AERO Clients and Proxy/Servers configure node identification | |||
| values as specified in [I-D.templin-6man-omni]. | values as specified in [I-D.templin-6man-omni]. | |||
| 3.2.3. AERO Routing System | 3.2.3. AERO Routing System | |||
| The AERO routing system comprises a private Border Gateway Protocol | The AERO routing system comprises a private Border Gateway Protocol | |||
| (BGP) [RFC4271] service coordinated between Gateways and Proxy/ | (BGP) [RFC4271] service coordinated between Gateways and Proxy/ | |||
| Servers (Relays also engage in the routing system as simplified | Servers (Relays also engage in the routing system as simplified | |||
| Proxy/Servers). The service supports carrier packet forwarding at a | Proxy/Servers). The service supports carrier packet forwarding at a | |||
| skipping to change at page 21, line 27 ¶ | skipping to change at page 21, line 30 ¶ | |||
| (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within | (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within | |||
| the BGP instance, and each Proxy/Server further uses eBGP to peer | the BGP instance, and each Proxy/Server further uses eBGP to peer | |||
| with one or more Gateways but does not peer with other Proxy/Servers. | with one or more Gateways but does not peer with other Proxy/Servers. | |||
| Each SRT segment in the OMNI link must include one or more Gateways | Each SRT segment in the OMNI link must include one or more Gateways | |||
| in a "hub" AS, which peer with the Proxy/Servers within that segment | in a "hub" AS, which peer with the Proxy/Servers within that segment | |||
| as "spoke" ASes. All Gateways within the same segment are members of | as "spoke" ASes. All Gateways within the same segment are members of | |||
| the same hub AS, and use iBGP to maintain a consistent view of all | the same hub AS, and use iBGP to maintain a consistent view of all | |||
| active routes currently in service. The Gateways of different | active routes currently in service. The Gateways of different | |||
| segments peer with one another using eBGP. | segments peer with one another using eBGP. | |||
| Gateways maintain forwarding table entries only for MNP-XLAs | Gateways maintain forwarding table entries only for ULA prefixes for | |||
| corresponding to MNP and non-MNP routes that are currently active, | infrastrucutre elements and XLA-MNPs corresponding to MNP and non-MNP | |||
| and also maintain black-hole routes for the OMNI link MSPs so that | routes that are currently active; Gateways also maintain black-hole | |||
| carrier packets destined to non-existent more-specific routes are | routes for the OMNI link MSPs so that carrier packets destined to | |||
| dropped with a Destination Unreachable message returned. In this | non-existent more-specific routes are dropped with a Destination | |||
| way, Proxy/Servers and Relays have only partial topology knowledge | Unreachable message returned. In this way, Proxy/Servers and Relays | |||
| (i.e., they only maintain routing information for their directly | have only partial topology knowledge (i.e., they only maintain | |||
| associated Clients and non-AERO links) and they forward all other | routing information for their directly associated Clients and non- | |||
| carrier packets to Gateways which have full topology knowledge. | AERO links) and they forward all other carrier packets to Gateways | |||
| which have full topology knowledge. | ||||
| Each OMNI link segment assigns a unique RND-ULA sub-prefix of | Each OMNI link segment assigns a unique sub-prefix of {ULA}::/48 | |||
| {ULA}::/48 known as the "SRT prefix". For example, a first segment | known as the "SRT prefix". For example, a first segment could assign | |||
| could assign {ULA}:1000::/56, a second could assign {ULA}:2000::/56, | {ULA}:1000::/56, a second could assign {ULA}:2000::/56, a third could | |||
| a third could assign {ULA}:3000::/56, etc. Within each segment, each | assign {ULA}:3000::/56, etc. Within each segment, each Proxy/Server | |||
| Proxy/Server configures a RND-ULA within the segment's SRT prefix | configures a ULA-RND within the segment's SRT prefix with a 56-bit | |||
| with a 56-bit random value in the interface identifier as specified | random value in the interface identifier as specified in | |||
| in [I-D.templin-6man-omni]. | [I-D.templin-6man-omni]. | |||
| The administrative authorities for each segment must therefore | The administrative authorities for each segment must therefore | |||
| coordinate to assure mutually-exclusive RND-ULA prefix assignments, | coordinate to assure mutually-exclusive ULA prefix assignments, but | |||
| but internal provisioning of RND-ULAs is an independent local | internal provisioning of ULAs is an independent local consideration | |||
| consideration for each administrative authority. For each RND-ULA | for each administrative authority. For each ULA prefix, the | |||
| prefix, the Gateway(s) that connect that segment assign the all- | Gateway(s) that connect that segment assign the all-zero's address of | |||
| zero's address of the prefix as a Subnet Router Anycast address. For | the prefix as a Subnet Router Anycast address. For example, the | |||
| example, the Subnet Router Anycast address for {ULA}:1023::/64 is | Subnet Router Anycast address for {ULA}:1023::/64 is simply | |||
| simply {ULA}:1023::/64. | {ULA}:1023::/64. | |||
| RND-ULA prefixes are statically represented in Gateway forwarding | ULA prefixes are statically represented in Gateway forwarding tables. | |||
| tables. Gateways join multiple SRT segments into a unified OMNI link | Gateways join multiple SRT segments into a unified OMNI link over | |||
| over multiple diverse network administrative domains. They support a | multiple diverse network administrative domains. They support a | |||
| virtual bridging service by first establishing forwarding table | virtual bridging service by first establishing forwarding table | |||
| entries for their RND-ULA prefixes either via standard BGP routing or | entries for their ULA prefixes either via standard BGP routing or | |||
| static routes. For example, if three Gateways ('A', 'B' and 'C') | static routes. For example, if three Gateways ('A', 'B' and 'C') | |||
| from different segments serviced {ULA}:1000::/60, {ULA}:2000::/56 and | from different segments serviced {ULA}:1000::/60, {ULA}:2000::/56 and | |||
| {ULA}:3000::/56 respectively, then the forwarding tables in each | {ULA}:3000::/56 respectively, then the forwarding tables in each | |||
| Gateway appear as follows: | Gateway appear as follows: | |||
| A: {ULA}:1000::/56->local, {ULA}:2000::/56->B, {ULA}:3000::/56->C | A: {ULA}:1000::/56->local, {ULA}:2000::/56->B, {ULA}:3000::/56->C | |||
| B: {ULA}:1000::/56->A, {ULA}:2000::/56->local, {ULA}:3000::/56->C | B: {ULA}:1000::/56->A, {ULA}:2000::/56->local, {ULA}:3000::/56->C | |||
| C: {ULA}:1000::/56->A, {ULA}:2000::/56->B, {ULA}:3000::/56->local | C: {ULA}:1000::/56->A, {ULA}:2000::/56->B, {ULA}:3000::/56->local | |||
| These forwarding table entries rarely change, since they correspond | These forwarding table entries rarely change, since they correspond | |||
| to fixed infrastructure elements in their respective segments. | to fixed infrastructure elements in their respective segments. | |||
| MNP (and non-MNP) ULA routes are instead dynamically advertised in | MNP (and non-MNP) ULA routes are instead dynamically advertised in | |||
| the AERO routing system by Proxy/Servers and Relays that provide | the AERO routing system by Proxy/Servers and Relays that provide | |||
| service for their corresponding MNPs. The routes are advertised as | service for their corresponding MNPs. The routes are advertised as | |||
| MNP-XLA prefixes, i.e., as fd00::{MNP} (see: | XLA-MNP prefixes, i.e., as fd00::{MNP} (see: | |||
| [I-D.templin-6man-omni]). For example, if three Proxy/Servers ('D', | [I-D.templin-6man-omni]). For example, if three Proxy/Servers ('D', | |||
| 'E' and 'F') service the MNPs 2001:db8:1000:2000::/56, | 'E' and 'F') service the MNPs 2001:db8:1000:2000::/56, | |||
| 2001:db8:3000:4000::/56 and 2001:db8:5000:6000::/56 then the routing | 2001:db8:3000:4000::/56 and 2001:db8:5000:6000::/56 then the routing | |||
| system would include: | system would include: | |||
| D: fd00::2001:db8:1000:2000/120 | D: fd00::2001:db8:1000:2000/120 | |||
| E: fd00::2001:db8:3000:4000/120 | E: fd00::2001:db8:3000:4000/120 | |||
| F: fd00::2001:db8:5000:6000/120 | F: fd00::2001:db8:5000:6000/120 | |||
| skipping to change at page 23, line 19 ¶ | skipping to change at page 23, line 30 ¶ | |||
| Performance-Based Multilink (PBM) internally. | Performance-Based Multilink (PBM) internally. | |||
| The Gateways and Proxy/Servers of each independent SRT engage in BGP | The Gateways and Proxy/Servers of each independent SRT engage in BGP | |||
| peerings to form a spanning tree with the Gateways in non-leaf nodes | peerings to form a spanning tree with the Gateways in non-leaf nodes | |||
| and the Proxy/Servers in leaf nodes. The spanning tree is configured | and the Proxy/Servers in leaf nodes. The spanning tree is configured | |||
| over both secured and unsecured underlay network paths. The secured | over both secured and unsecured underlay network paths. The secured | |||
| spanning tree is used to convey secured control messages between | spanning tree is used to convey secured control messages between | |||
| Proxy/Servers and Gateways, while the unsecured spanning tree | Proxy/Servers and Gateways, while the unsecured spanning tree | |||
| forwards data messages and/or unsecured control messages. | forwards data messages and/or unsecured control messages. | |||
| Each SRT segment is identified by a unique RND-ULA prefix used by all | Each SRT segment is identified by a unique ULA prefix used by all | |||
| Proxy/Servers and Gateways in the segment. Each AERO node must | Proxy/Servers and Gateways in the segment. Each AERO node must | |||
| therefore discover an SRT prefix that correspondents can use to | therefore discover an SRT prefix that correspondents can use to | |||
| determine the correct segment, and must publish the SRT prefix in | determine the correct segment, and must publish the SRT prefix in | |||
| IPv6 ND messages. | IPv6 ND messages. | |||
| Note: The distinct ULA prefixes in an OMNI link domain can be carried | Note: The distinct ULA prefixes in an OMNI link domain can be carried | |||
| either in a common BGP routing protocol instance for all OMNI links | either in a common BGP routing protocol instance for all OMNI links | |||
| or in distinct BGP routing protocol instances for different OMNI | or in distinct BGP routing protocol instances for different OMNI | |||
| links. In some SBM environments, such separation may be necessary to | links. In some SBM environments, such separation may be necessary to | |||
| ensure that distinct OMNI links do not include any common | ensure that distinct OMNI links do not include any common | |||
| skipping to change at page 26, line 15 ¶ | skipping to change at page 26, line 29 ¶ | |||
| Proxy/Servers on the open Internet include only a single INET | Proxy/Servers on the open Internet include only a single INET | |||
| underlay interface. INET Clients therefore discover only the INADDR | underlay interface. INET Clients therefore discover only the INADDR | |||
| information for the Proxy/Server's INET interface. Proxy/Servers on | information for the Proxy/Server's INET interface. Proxy/Servers on | |||
| an ANET/INET boundary include both an ANET and INET underlay | an ANET/INET boundary include both an ANET and INET underlay | |||
| interface. ANET Clients therefore must discover both the ANET and | interface. ANET Clients therefore must discover both the ANET and | |||
| INET INADDR information for the Proxy/Server. | INET INADDR information for the Proxy/Server. | |||
| Gateway and Proxy/Server OMNI interfaces are configured over underlay | Gateway and Proxy/Server OMNI interfaces are configured over underlay | |||
| interfaces that provide both secured tunnels for carrying IPv6 ND and | interfaces that provide both secured tunnels for carrying IPv6 ND and | |||
| BGP protocol control plane messages and open INET access for carrying | BGP protocol control plane messages and open INET access for carrying | |||
| unsecured messages. The OMNI interface configures an RND-ULA and | unsecured messages. The OMNI interface configures a ULA-RND and acts | |||
| acts as an OAL source to encapsulate and fragment original IP packets | as an OAL source to encapsulate and fragment original IP packets | |||
| while presenting the resulting carrier packets over the secured or | while presenting the resulting carrier packets over the secured or | |||
| unsecured underlay paths. Note that Gateway and Proxy/Server end-to- | unsecured underlay paths. Note that Gateway and Proxy/Server end-to- | |||
| end transport protocol sessions used by the BGP are run directly over | end transport protocol sessions used by the BGP are run directly over | |||
| the OMNI interface and use RND-ULA source and destination addresses. | the OMNI interface and use ULA-RND source and destination addresses. | |||
| The OMNI interface employs the OAL to encapsulate the original IP | The OMNI interface employs the OAL to encapsulate the original IP | |||
| packets for these sessions as carrier packets (i.e., even though the | packets for these sessions as carrier packets (i.e., even though the | |||
| OAL header may use the same RND-ULAs as the original IP header) and | OAL header may use the same ULAs as the original IP header) and | |||
| forwards them over the secured underlay path. | forwards them over the secured underlay path. | |||
| 3.4. OMNI Interface Initialization | 3.4. OMNI Interface Initialization | |||
| AERO Proxy/Servers, Clients and Hosts configure OMNI interfaces as | AERO Proxy/Servers, Clients and Hosts configure OMNI interfaces as | |||
| their point of attachment to the OMNI link. AERO nodes assign the | their point of attachment to the OMNI link. AERO nodes assign the | |||
| MSPs for the link to their OMNI interfaces (i.e., as a "route-to- | MSPs for the link to their OMNI interfaces (i.e., as a "route-to- | |||
| interface") to ensure that original IP packets with destination | interface") to ensure that original IP packets with destination | |||
| addresses covered by an MNP not explicitly associated with another | addresses covered by an MNP not explicitly associated with another | |||
| interface are directed to an OMNI interface. | interface are directed to an OMNI interface. | |||
| OMNI interface initialization procedures for Proxy/Servers, Clients | OMNI interface initialization procedures for Proxy/Servers, Clients | |||
| Hosts and Gateways are discussed in the following sections. | Hosts and Gateways are discussed in the following sections. | |||
| 3.4.1. AERO Proxy/Server and Relay Behavior | 3.4.1. AERO Proxy/Server and Relay Behavior | |||
| When a Proxy/Server enables an OMNI interface, it assigns a RND-ULA | When a Proxy/Server enables an OMNI interface, it assigns a ULA-RND | |||
| appropriate for the given OMNI link SRT segment. The Proxy/Server | appropriate for the given OMNI link SRT segment. The Proxy/Server | |||
| also configures secured tunnels and engages in BGP routing protocol | also configures secured tunnels and engages in BGP routing protocol | |||
| sessions with one or more neighboring Gateways. | sessions with one or more neighboring Gateways. | |||
| The OMNI interface provides a single interface abstraction to the IP | The OMNI interface provides a single interface abstraction to the IP | |||
| layer, but internally includes an NBMA nexus for sending carrier | layer, but internally includes an NBMA nexus for sending carrier | |||
| packets to OMNI interface neighbors over underlay INET interfaces and | packets to OMNI interface neighbors over underlay INET interfaces and | |||
| secured tunnels. The Proxy/Server further configures a service to | secured tunnels. The Proxy/Server further configures a service to | |||
| facilitate IPv6 ND exchanges with AERO Clients and manages per-Client | facilitate IPv6 ND exchanges with AERO Clients and manages per-Client | |||
| neighbor cache entries and IP forwarding table entries based on | neighbor cache entries and IP forwarding table entries based on | |||
| skipping to change at page 27, line 15 ¶ | skipping to change at page 27, line 30 ¶ | |||
| Relays are simply Proxy/Servers that run a dynamic routing protocol | Relays are simply Proxy/Servers that run a dynamic routing protocol | |||
| to redistribute routes between the OMNI interface and INET/ENET | to redistribute routes between the OMNI interface and INET/ENET | |||
| interfaces (see: Section 3.2.3). The Relay provisions MNPs to | interfaces (see: Section 3.2.3). The Relay provisions MNPs to | |||
| networks on the INET/ENET interfaces (i.e., the same as a Client | networks on the INET/ENET interfaces (i.e., the same as a Client | |||
| would do) and advertises the MSP(s) for the OMNI link over the INET/ | would do) and advertises the MSP(s) for the OMNI link over the INET/ | |||
| ENET interfaces. The Relay further provides an attachment point of | ENET interfaces. The Relay further provides an attachment point of | |||
| the OMNI link to a non-MNP-based global topology. | the OMNI link to a non-MNP-based global topology. | |||
| 3.4.2. AERO Client Behavior | 3.4.2. AERO Client Behavior | |||
| When a Client enables an OMNI interface, it assigns either an MNP-XLA | When a Client enables an OMNI interface, it assigns either an XLA-MNP | |||
| or a TMP-ULA and sends OMNI-encapsulated RS messages over its ANET/ | or a TLA and sends OMNI-encapsulated RS messages over its ANET/INET | |||
| INET underlay interfaces to an FHS Proxy/Server, which coordinates | underlay interfaces to an FHS Proxy/Server, which coordinates with a | |||
| with a Hub Proxy/Server that returns an RA message with corresponding | Hub Proxy/Server that returns an RA message with corresponding | |||
| parameters. The RS/RA messages may pass through one or more NATs in | parameters. The RS/RA messages may pass through one or more NATs in | |||
| the path between the Client and FHS Proxy/Server. (Note: if the | the path between the Client and FHS Proxy/Server. (Note: if the | |||
| Client used a TMP-ULA in its initial RS messages, it may discover | Client used a TLA in its initial RS messages, it may discover ULA- | |||
| MNP-ULAs in the corresponding RAs that it receives from FHS Proxy/ | MNPs in the corresponding RAs that it receives from FHS Proxy/Servers | |||
| Servers and begin using these new addresses. If the Client is | and begin using these new addresses. If the Client is operating | |||
| operating outside the context of AERO infrastructure such as in a | outside the context of AERO infrastructure such as in a Mobile Ad-hoc | |||
| Mobile Ad-hoc Network (MANET), however, it may continue using TMP- | Network (MANET), however, it may continue using TLAs for Client-to- | |||
| ULAs for Client-to-Client communications until it encounters an | Client communications until it encounters an infrastructure element | |||
| infrastructure element that can delegate MNPs.) | that can delegate MNPs.) | |||
| A Client can further extend the OMNI link over its (downstream) ENET | A Client can further extend the OMNI link over its (downstream) ENET | |||
| interfaces where it provides a first-hop router for Hosts and other | interfaces where it provides a first-hop router for Hosts and other | |||
| AERO Clients connected to the ENET. A downstream Client that | AERO Clients connected to the ENET. A downstream Client that | |||
| connects via the ENET serviced by an upstream Client can in turn | connects via the ENET serviced by an upstream Client can in turn | |||
| service further downstream ENETs that connect other Hosts and | service further downstream ENETs that connect other Hosts and | |||
| Clients. This OMNI link extension can be applied recursively over a | Clients. This OMNI link extension can be applied recursively over a | |||
| "chain" of ENET Clients. | "chain" of ENET Clients. | |||
| 3.4.3. AERO Host Behavior | 3.4.3. AERO Host Behavior | |||
| skipping to change at page 28, line 7 ¶ | skipping to change at page 28, line 24 ¶ | |||
| The Host sends OMNI-encapsulated RS messages over its ENET underlay | The Host sends OMNI-encapsulated RS messages over its ENET underlay | |||
| interface to the upstream Client, which returns encapsulated RAs and | interface to the upstream Client, which returns encapsulated RAs and | |||
| provides routing services in the same fashion that Proxy/Servers | provides routing services in the same fashion that Proxy/Servers | |||
| provides services for Clients. Hosts represent the leaf end systems | provides services for Clients. Hosts represent the leaf end systems | |||
| in recursively-nested chain of concatenated ENETs, i.e., they | in recursively-nested chain of concatenated ENETs, i.e., they | |||
| represent terminating endpoints for the OMNI link. | represent terminating endpoints for the OMNI link. | |||
| 3.4.4. AERO Gateway Behavior | 3.4.4. AERO Gateway Behavior | |||
| AERO Gateways configure an OMNI interface and assign a RND-ULA and | AERO Gateways configure an OMNI interface and assign a ULA-RND and | |||
| corresponding Subnet Router Anycast address for each OMNI link SRT | corresponding Subnet Router Anycast address for each OMNI link SRT | |||
| segment they connect to. Gateways configure secured tunnels with | segment they connect to. Gateways configure secured tunnels with | |||
| Proxy/Servers in the same SRT segment and other Gateways in the same | Proxy/Servers in the same SRT segment and other Gateways in the same | |||
| (or an adjacent) SRT segment. Gateways then engage in a BGP routing | (or an adjacent) SRT segment. Gateways then engage in a BGP routing | |||
| protocol session with neighbors over the secured spanning tree (see: | protocol session with neighbors over the secured spanning tree (see: | |||
| Section 3.2.3). | Section 3.2.3). | |||
| 3.5. OMNI Interface Neighbor Cache Maintenance | 3.5. OMNI Interface Neighbor Cache Maintenance | |||
| Each Client, Proxy/Server and Gateway OMNI interface maintains a | Each Client, Proxy/Server and Gateway OMNI interface maintains a | |||
| skipping to change at page 31, line 21 ¶ | skipping to change at page 31, line 44 ¶ | |||
| OMNI interface IPv6 ND messages may also include other IPv6 ND | OMNI interface IPv6 ND messages may also include other IPv6 ND | |||
| options. In particular, solicitation messages may include a Nonce | options. In particular, solicitation messages may include a Nonce | |||
| option if required for verification of advertisement replies. If an | option if required for verification of advertisement replies. If an | |||
| OMNI IPv6 ND solicitation message includes a Nonce option, the | OMNI IPv6 ND solicitation message includes a Nonce option, the | |||
| advertisement reply must echo the same Nonce. If an OMNI IPv6 ND | advertisement reply must echo the same Nonce. If an OMNI IPv6 ND | |||
| advertisement message includes a Timestamp option, the recipient | advertisement message includes a Timestamp option, the recipient | |||
| should check the Timestamp to determine if the message is current. | should check the Timestamp to determine if the message is current. | |||
| AERO Clients send RS messages to the link-scoped All-Routers | AERO Clients send RS messages to the link-scoped All-Routers | |||
| multicast address or a RND-ULA while using unicast or anycast L2 | multicast address or a ULA-RND while using unicast or anycast L2 | |||
| addresses. AERO Proxy/Servers respond by returning unicast RA | addresses. AERO Proxy/Servers respond by returning unicast RA | |||
| messages. During the RS/RA exchange, AERO Clients and Proxy/Servers | messages. During the RS/RA exchange, AERO Clients and Proxy/Servers | |||
| include state synchronization parameters to establish Identification | include state synchronization parameters to establish Identification | |||
| windows and other state. | windows and other state. | |||
| AERO Hosts and Clients on ENET underlay networks send RS messages to | AERO Hosts and Clients on ENET underlay networks send RS messages to | |||
| the link-scoped All-Routers multicast address, a RND-ULA of a remote | the link-scoped All-Routers multicast address, a ULA-RND of a remote | |||
| Hub Proxy/Server or the MNP-ULA of an upstream Client while using | Hub Proxy/Server or the ULA-MNP of an upstream Client while using | |||
| unicast or anycast L2 addresses. The upstream AERO Client responds | unicast or anycast L2 addresses. The upstream AERO Client responds | |||
| by returning a unicast RA message. | by returning a unicast RA message. | |||
| AERO nodes use NS/NA messages for the following purposes: | AERO nodes use NS/NA messages for the following purposes: | |||
| * NS/NA(AR) messages are used for address resolution and optionally | * NS/NA(AR) messages are used for address resolution and optionally | |||
| to establish sequence number windows. The ROS sends an NS(AR) to | to establish sequence number windows. The ROS sends an NS(AR) to | |||
| the solicited-node multicast address of the target, and an ROR | the solicited-node multicast address of the target, and an ROR | |||
| with addressing information for the target returns a unicast | with addressing information for the target returns a unicast | |||
| NA(AR) that contains current, consistent and authentic target | NA(AR) that contains current, consistent and authentic target | |||
| skipping to change at page 32, line 37 ¶ | skipping to change at page 33, line 17 ¶ | |||
| not occur on the OMNI link itself, but may occur on the downstream | not occur on the OMNI link itself, but may occur on the downstream | |||
| links of Clients and Relays. | links of Clients and Relays. | |||
| * S: The S ("Solicited") flag is set exactly as specified in | * S: The S ("Solicited") flag is set exactly as specified in | |||
| Section 4.4. of [RFC4861], i.e., it is set to 1 for Solicited NAs | Section 4.4. of [RFC4861], i.e., it is set to 1 for Solicited NAs | |||
| and set to 0 for uNAs (both unicast and multicast). | and set to 0 for uNAs (both unicast and multicast). | |||
| * O: The O ("Override") flag is set to 0 for solicited NAs returned | * O: The O ("Override") flag is set to 0 for solicited NAs returned | |||
| by a Proxy/Server ROR and set to 1 for all other solicited and | by a Proxy/Server ROR and set to 1 for all other solicited and | |||
| unsolicited NAs. For further study is whether solicited NAs for | unsolicited NAs. For further study is whether solicited NAs for | |||
| anycast targets apply for OMNI links. Since MNP-XLAs must be | anycast targets apply for OMNI links. Since XLA-MNPs must be | |||
| uniquely assigned to Clients to support correct IPv6 ND protocol | uniquely assigned to Clients to support correct IPv6 ND protocol | |||
| operation, however, no role is currently seen for assigning the | operation, however, no role is currently seen for assigning the | |||
| same MNP-XLA to multiple Clients. | same XLA-MNP to multiple Clients. | |||
| 3.5.3. OMNI Neighbor Window Synchronization | 3.5.3. OMNI Neighbor Window Synchronization | |||
| In secured environments (e.g., between secured spanning tree | In secured environments (e.g., between secured spanning tree | |||
| neighbors, between neighbors on the same secured ANET, etc.), OMNI | neighbors, between neighbors on the same secured ANET, etc.), OMNI | |||
| interface neighbors can exchange OAL packets using randomly- | interface neighbors can exchange OAL packets using randomly- | |||
| initialized and monotonically-increasing Identification values | initialized and monotonically-increasing Identification values | |||
| (modulo 2**32) without window synchronization. In environments where | (modulo 2**32) without window synchronization. In environments where | |||
| spoofing is considered a threat, OMNI interface neighbors instead | spoofing is considered a threat, OMNI interface neighbors instead | |||
| invoke window synchronization in NS/NA message exchanges to maintain | invoke window synchronization in NS/NA message exchanges to maintain | |||
| skipping to change at page 33, line 15 ¶ | skipping to change at page 33, line 44 ¶ | |||
| 3.6. OMNI Interface Encapsulation and Fragmentation | 3.6. OMNI Interface Encapsulation and Fragmentation | |||
| When the network layer forwards an original IP packet into an OMNI | When the network layer forwards an original IP packet into an OMNI | |||
| interface, the interface locates or creates a Neighbor Cache Entry | interface, the interface locates or creates a Neighbor Cache Entry | |||
| (NCE) that matches the destination. The OMNI interface then invokes | (NCE) that matches the destination. The OMNI interface then invokes | |||
| the OMNI Adaptation Layer (OAL) as discussed in | the OMNI Adaptation Layer (OAL) as discussed in | |||
| [I-D.templin-6man-omni] which encapsulates the packet in an IPv6 | [I-D.templin-6man-omni] which encapsulates the packet in an IPv6 | |||
| header to produce an OAL packet. For example, an original IP packet | header to produce an OAL packet. For example, an original IP packet | |||
| with source address 2001:db8:1:2::1 and destination address | with source address 2001:db8:1:2::1 and destination address | |||
| 2001:db8:1234:5678::1 might cause the OAL encapsulation header to | 2001:db8:1234:5678::1 might cause the OAL encapsulation header to | |||
| include source address {ULA*}::2001:db8:1:2 (i.e., an MNP-ULA) and | include source address {XLA*}::2001:db8:1:2 (i.e., an XLA-MNP) and | |||
| destination address {ULA*}::3000:0000 (i.e., a RND-ULA). | destination address {ULA*}::0012:3456:789a:bcde (i.e., a ULA-RND). | |||
| Following encapsulation, the OAL source then calculates a 2-octet | Following encapsulation, the OAL source then calculates a 2-octet | |||
| checksum and fragments the OAL packet while including an identical | checksum and fragments the OAL packet while including an identical | |||
| Identification value for each fragment that must be within the window | Identification value for each fragment that must be within the window | |||
| for the LHS Proxy/Server or the target Client itself. The OAL source | for the LHS Proxy/Server or the target Client itself. The OAL source | |||
| finally includes the checksum as the final 2 octets of the final | finally includes the checksum as the final 2 octets of the final | |||
| fragment, i.e., as a "trailer". | fragment, i.e., as a "trailer". | |||
| The OAL source next includes an identical Compressed Routing Header | The OAL source next includes an identical Compressed Routing Header | |||
| with 32-bit ID fields (CRH-32) [I-D.bonica-6man-comp-rtg-hdr] with | with 32-bit ID fields (CRH-32) [I-D.bonica-6man-comp-rtg-hdr] with | |||
| skipping to change at page 34, line 11 ¶ | skipping to change at page 34, line 26 ¶ | |||
| address of the next hop OAL intermediate node or destination (e.g., | address of the next hop OAL intermediate node or destination (e.g., | |||
| 192.0.2.1). The carrier packet encapsulation format in the above | 192.0.2.1). The carrier packet encapsulation format in the above | |||
| example is shown in Figure 3: | example is shown in Figure 3: | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | L2 Headers | | | L2 Headers | | |||
| | src = 192.0.2.100 | | | src = 192.0.2.100 | | |||
| | dst = 192.0.2.1 | | | dst = 192.0.2.1 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | OAL IPv6 Header | | | OAL IPv6 Header | | |||
| | src = {ULA*}::2001:db8:1:2 | | | src = {XLA*}::2001:db8:1:2 | | |||
| | dst= {ULA*}::3000:0000 | | |dst={ULA*}::0012:3456:789a:bcde| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | CRH-32 (if necessary) | | | CRH-32 (if necessary) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | OAL Fragment Header | | | OAL Fragment Header | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Original IP Header | | | Original IP Header | | |||
| | (first-fragment only) | | | (first-fragment only) | | |||
| | src = 2001:db8:1:2::1 | | | src = 2001:db8:1:2::1 | | |||
| | dst = 2001:db8:1234:5678::1 | | | dst = 2001:db8:1234:5678::1 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 34, line 48 ¶ | skipping to change at page 35, line 14 ¶ | |||
| In this format, the OAL source encapsulates the original IP header | In this format, the OAL source encapsulates the original IP header | |||
| and packet body/fragment in an OAL IPv6 header prepared according to | and packet body/fragment in an OAL IPv6 header prepared according to | |||
| [RFC2473], the CRH-32 is a Routing Header extension of the OAL | [RFC2473], the CRH-32 is a Routing Header extension of the OAL | |||
| header, the Fragment Header identifies each fragment, and the L2 | header, the Fragment Header identifies each fragment, and the L2 | |||
| headers are prepared as discussed in [I-D.templin-6man-omni]. The | headers are prepared as discussed in [I-D.templin-6man-omni]. The | |||
| OAL source transmits each such carrier packet into the SRT spanning | OAL source transmits each such carrier packet into the SRT spanning | |||
| tree, where they are forwarded over possibly multiple OAL | tree, where they are forwarded over possibly multiple OAL | |||
| intermediate nodes until they arrive at the OAL destination. | intermediate nodes until they arrive at the OAL destination. | |||
| The OMNI link control plane service distributes Client MNP-ULA prefix | The OMNI link control plane service distributes Client XLA-MNP prefix | |||
| information that may change dynamically due to regional node mobility | information that may change dynamically due to regional node mobility | |||
| as well as Relay non-MNP-ULA and per-segment RND-ULA prefix | as well as XLA-MNP prefix information for Relay non-MNPs and per- | |||
| information that rarely changes. OMNI link Gateways and Proxy/ | segment ULA prefix information that rarely changes. OMNI link | |||
| Servers use the information to establish and maintain a forwarding | Gateways and Proxy/Servers use the information to establish and | |||
| plane spanning tree that connects all nodes on the link. The | maintain a forwarding plane spanning tree that connects all nodes on | |||
| spanning tree supports a carrier packet virtual bridging service | the link. The spanning tree supports a carrier packet virtual | |||
| according to link-layer (instead of network-layer) information, but | bridging service according to link-layer (instead of network-layer) | |||
| may often include longer paths than necessary. | information, but may often include longer paths than necessary. | |||
| Each OMNI interface therefore also includes a Multilink Forwarding | Each OMNI interface therefore also includes a Multilink Forwarding | |||
| Information Base (MFIB) with Multilink Forwarding Vectors (MFVs) that | Information Base (MFIB) with Multilink Forwarding Vectors (MFVs) that | |||
| can often provide more direct forwarding "shortcuts" that avoid | can often provide more direct forwarding "shortcuts" that avoid | |||
| strict spanning tree paths. As a result, the spanning tree is always | strict spanning tree paths. As a result, the spanning tree is always | |||
| available but OMNI interfaces can often use the MFIB to greatly | available but OMNI interfaces can often use the MFIB to greatly | |||
| improve performance and reduce load on critical infrastructure | improve performance and reduce load on critical infrastructure | |||
| elements. | elements. | |||
| For carrier packets undergoing re-encapsulation at an OAL | For carrier packets undergoing re-encapsulation at an OAL | |||
| skipping to change at page 38, line 18 ¶ | skipping to change at page 38, line 35 ¶ | |||
| interface pairs; otherwise, it sends a single copy of the OAL packet | interface pairs; otherwise, it sends a single copy of the OAL packet | |||
| via an interface with the best matching Traffic Selector. (While not | via an interface with the best matching Traffic Selector. (While not | |||
| strictly required, the likelihood of successful reassembly may | strictly required, the likelihood of successful reassembly may | |||
| improve when the OMNI interface sends all fragments of the same | improve when the OMNI interface sends all fragments of the same | |||
| fragmented OAL packet consecutively over the same underlay interface | fragmented OAL packet consecutively over the same underlay interface | |||
| pair to avoid complicating factors such as delay variance and | pair to avoid complicating factors such as delay variance and | |||
| reordering.) AERO nodes keep track of which underlay interfaces are | reordering.) AERO nodes keep track of which underlay interfaces are | |||
| currently "reachable" or "unreachable", and only use "reachable" | currently "reachable" or "unreachable", and only use "reachable" | |||
| interfaces for forwarding purposes. | interfaces for forwarding purposes. | |||
| The Subnet ID value in {ADM,MNP}-ULAs is used only for subnet | The Subnet ID value in ULAs is used only for subnet coordination | |||
| coordination within a local OMNI link segment. When a node forwards | within a local OMNI link segment. When a node forwards a packet with | |||
| a packet with an {ADM,MNP}-ULA with a foreign Global and/or Subnet ID | a ULA with a foreign Global and/or Subnet ID value it forwards the | |||
| value it forwards the packet based solely on the OMNI link routing | packet based solely on the OMNI link routing information. For this | |||
| information. For this reason, OMNI link routing and forwarding table | reason, OMNI link routing and forwarding table entries always include | |||
| entries always include both RND-ULAs with their associated prefix | both ULAs with their associated prefix lengths and XLA-MNPs which | |||
| lengths and MNP-XLAs which leave the Global and Subnet ID values set | encode an MNP while leaving the Global and Subnet ID values set to 0. | |||
| to 0. | ||||
| The following sections discuss the OMNI interface forwarding | The following sections discuss the OMNI interface forwarding | |||
| algorithms for Hosts, Clients, Proxy/Servers and Gateways. In the | algorithms for Hosts, Clients, Proxy/Servers and Gateways. In the | |||
| following discussion, an original IP packet's destination address is | following discussion, an original IP packet's destination address is | |||
| said to "match" if it is the same as a cached address, or if it is | said to "match" if it is the same as a cached address, or if it is | |||
| covered by a cached prefix (which may be encoded in an MNP-ULA). | covered by a cached prefix (which may be encoded in a *LA-MNP). | |||
| 3.10.1. Host Forwarding Algorithm | 3.10.1. Host Forwarding Algorithm | |||
| When an original IP packet enters a Host's OMNI interface from the | When an original IP packet enters a Host's OMNI interface from the | |||
| network layer the Host searches for a NCE that matches the | network layer the Host searches for a NCE that matches the | |||
| destination. If there is a matching NCE, the Host performs L2 | destination. If there is a matching NCE, the Host performs L2 | |||
| encapsulation, fragments the encapsulated packet if necessary and | encapsulation, fragments the encapsulated packet if necessary and | |||
| forwards the packets into the ENET addressed to the L2 address of the | forwards the packets into the ENET addressed to the L2 address of the | |||
| neighbor. | neighbor. | |||
| skipping to change at page 39, line 19 ¶ | skipping to change at page 39, line 33 ¶ | |||
| destination. If there is a matching NCE on an ANET/INET interface | destination. If there is a matching NCE on an ANET/INET interface | |||
| (i.e., an upstream interface), the Client selects one or more | (i.e., an upstream interface), the Client selects one or more | |||
| "reachable" neighbor interfaces in the entry for forwarding purposes. | "reachable" neighbor interfaces in the entry for forwarding purposes. | |||
| Otherwise, the Client invokes route optimization per Section 3.13 and | Otherwise, the Client invokes route optimization per Section 3.13 and | |||
| follows the multilink forwarding procedures outlined there. If there | follows the multilink forwarding procedures outlined there. If there | |||
| is a matching NCE on an ENET interface (i.e., a downstream | is a matching NCE on an ENET interface (i.e., a downstream | |||
| interface), the Client instead performs OAL and/or L2 encapsulation | interface), the Client instead performs OAL and/or L2 encapsulation | |||
| and forwards the packet to the downstream Host or Client. | and forwards the packet to the downstream Host or Client. | |||
| When a carrier packet enters a Client's OMNI interface from the link- | When a carrier packet enters a Client's OMNI interface from the link- | |||
| layer, if the OAL destination matches one of the Client's ULAs the | layer, if the OAL destination matches one of the Client's *LAs the | |||
| Client (acting as an OAL destination) verifies that the | Client (acting as an OAL destination) verifies that the | |||
| Identification is in-window for this OAL source, then reassembles and | Identification is in-window for this OAL source, then reassembles and | |||
| decapsulates as necessary and delivers the original IP packet to the | decapsulates as necessary and delivers the original IP packet to the | |||
| network layer. If the OAL destination matches a NCE for a Host or | network layer. If the OAL destination matches a NCE for a Host or | |||
| Client on an ENET interface, the Client instead forwards the carrier | Client on an ENET interface, the Client instead forwards the carrier | |||
| packet to the Host/Client. If the OAL destination does not match, | packet to the Host/Client. If the OAL destination does not match, | |||
| the Client drops the original IP packet and MAY return a network- | the Client drops the original IP packet and MAY return a network- | |||
| layer ICMP Destination Unreachable message subject to rate limiting | layer ICMP Destination Unreachable message subject to rate limiting | |||
| (see: Section 3.11). | (see: Section 3.11). | |||
| skipping to change at page 40, line 4 ¶ | skipping to change at page 40, line 17 ¶ | |||
| ANET. Moreover, the original IP packets do not include either the | ANET. Moreover, the original IP packets do not include either the | |||
| OAL integrity check or per-packet Identification values that can be | OAL integrity check or per-packet Identification values that can be | |||
| used for data origin authentication and link-layer retransmissions. | used for data origin authentication and link-layer retransmissions. | |||
| The tradeoff therefore involves an assessment of the per-packet | The tradeoff therefore involves an assessment of the per-packet | |||
| encapsulation overhead saved by bypassing the OAL vs. inheritance of | encapsulation overhead saved by bypassing the OAL vs. inheritance of | |||
| classical network "brittleness". (Note however that ANET peers can | classical network "brittleness". (Note however that ANET peers can | |||
| send small original IP packets without invoking the OAL, while | send small original IP packets without invoking the OAL, while | |||
| invoking the OAL for larger packets. This presents the beneficial | invoking the OAL for larger packets. This presents the beneficial | |||
| aspects of both small packet efficiency and large packet robustness, | aspects of both small packet efficiency and large packet robustness, | |||
| with delay variance and reordering as possible side effects.) | with delay variance and reordering as possible side effects.) | |||
| Note: The forwarding table entries established in peer Clients of a | Note: The forwarding table entries established in peer Clients of a | |||
| multihop forwarding region are based on MNP-ULAs and/or TMP-ULAs used | multihop forwarding region are based on ULA-MNPs and/or TLAs used to | |||
| to seed the multihop routing protocols. When MNP-ULAs are used, the | seed the multihop routing protocols. When ULA-MNPs are used, the ULA | |||
| ULA /64 prefix provides topological relevance for the multihop | /64 prefix provides topological relevance for the multihop forwarding | |||
| forwarding region, while the 64-bit Interface Identifier encodes the | region, while the 64-bit Interface Identifier encodes the Client MNP. | |||
| Client MNP. Therefore, Clients can forward atomic fragments with | Therefore, Clients can forward atomic fragments with compressed OAL | |||
| compressed OAL headers that do not include ULA or MFVI information by | headers that do not include ULA or MFVI information by examining the | |||
| examining the MNP-based addresses in the actual IP packet header. In | MNP-based addresses in the actual IP packet header. In other words, | |||
| other words, each forwarding table entry contains two pieces of | each forwarding table entry contains two pieces of forwarding | |||
| forwarding information - the ULA information in the prefix and the | information - the ULA information in the prefix and the MNP | |||
| MNP information in the interface identifier. | information in the interface identifier. | |||
| 3.10.3. Proxy/Server and Relay Forwarding Algorithm | 3.10.3. Proxy/Server and Relay Forwarding Algorithm | |||
| When a Proxy/Server receives an original IP packet from the network | When a Proxy/Server receives an original IP packet from the network | |||
| layer, it drops the packet if routing indicates that it should be | layer, it drops the packet if routing indicates that it should be | |||
| forwarded back to the network layer to avoid looping. Otherwise, the | forwarded back to the network layer to avoid looping. Otherwise, the | |||
| Proxy/Server regards the original IP packet the same as if it had | Proxy/Server regards the original IP packet the same as if it had | |||
| arrived as carrier packets with OAL destination set to its own RND- | arrived as carrier packets with OAL destination set to its own ULA. | |||
| ULA. When the Proxy/Server receives carrier packets on underlay | When the Proxy/Server receives carrier packets on underlay interfaces | |||
| interfaces with OAL destination set to its own RND-ULA, it performs | with OAL destination set to its own ULA, it performs OAL reassembly | |||
| OAL reassembly if necessary to obtain the original IP packet. The | if necessary to obtain the original IP packet. The Proxy/Server then | |||
| Proxy/Server then supports multilink forwarding procedures as | supports multilink forwarding procedures as specified in | |||
| specified in Section 3.13.2 and/or acts as an ROS to initiate route | Section 3.13.2 and/or acts as an ROS to initiate route optimization | |||
| optimization as specified in Section 3.13. | as specified in Section 3.13. | |||
| When the Proxy/Server receives a carrier packet with OAL destination | When the Proxy/Server receives a carrier packet with OAL destination | |||
| set to an MNP-ULA that does not match the MSP, it accepts the carrier | set to a *LA-MNP that does not match the MSP, it accepts the carrier | |||
| packet only if data origin authentication succeeds and if there is a | packet only if data origin authentication succeeds and if there is a | |||
| network layer routing table entry for a GUA route that matches the | network layer routing table entry for a GUA route that matches the | |||
| MNP-ULA. If there is no route, the Proxy/Server drops the carrier | *LA-MNP. If there is no route, the Proxy/Server drops the carrier | |||
| packet; otherwise, it reassembles and decapsulates to obtain the | packet; otherwise, it reassembles and decapsulates to obtain the | |||
| original IP packet then acts as a Relay to present it to the network | original IP packet then acts as a Relay to present it to the network | |||
| layer where it will be delivered according to standard IP forwarding. | layer where it will be delivered according to standard IP forwarding. | |||
| When a Proxy/Server receives a carrier packet from one of its Client | When a Proxy/Server receives a carrier packet from one of its Client | |||
| neighbors with OAL destination set to another node, it forwards the | neighbors with OAL destination set to another node, it forwards the | |||
| packets via a matching NCE or via the spanning tree if there is no | packets via a matching NCE or via the spanning tree if there is no | |||
| matching entry. When the Proxy/Server receives a carrier packet with | matching entry. When the Proxy/Server receives a carrier packet with | |||
| OAL destination set to an MNP-ULA of one of its Client neighbors | OAL destination set to a *LA-MNP of one of its Client neighbors | |||
| established through RS/RA exchanges, it accepts the carrier packet | established through RS/RA exchanges, it accepts the carrier packet | |||
| only if data origin authentication succeeds. If the NCE state is | only if data origin authentication succeeds. If the NCE state is | |||
| DEPARTED, the Proxy/Server changes the OAL destination address to the | DEPARTED, the Proxy/Server changes the OAL destination address to the | |||
| RND-ULA of the new Proxy/Server, then re-encapsulates the carrier | ULA of the new Proxy/Server, then re-encapsulates the carrier packet | |||
| packet and forwards it to a Gateway which will eventually deliver it | and forwards it to a Gateway which will eventually deliver it to the | |||
| to the new Proxy/Server. If the neighbor cache state for the Client | new Proxy/Server. If the neighbor cache state for the Client is | |||
| is REACHABLE, the Proxy/Server forwards the carrier packets to the | REACHABLE, the Proxy/Server forwards the carrier packets to the | |||
| Client which then must reassemble. (Note that the Proxy/Server does | Client which then must reassemble. (Note that the Proxy/Server does | |||
| not reassemble carrier packets not explicitly addressed to its own | not reassemble carrier packets not explicitly addressed to its own | |||
| RND-ULA, since some of the carrier packets of the same original IP | ULA, since some of the carrier packets of the same original IP packet | |||
| packet could be forwarded through a different Proxy/Server.) In that | could be forwarded through a different Proxy/Server.) In that case, | |||
| case, the Client may receive fragments that are smaller than its link | the Client may receive fragments that are smaller than its link MTU | |||
| MTU but that can still be reassembled. | but that can still be reassembled. | |||
| Proxy/Servers process carrier packets with OAL destinations that do | Proxy/Servers process carrier packets with OAL destinations that do | |||
| not match their RND-ULA in the same manner as for traditional IP | not match their ULA in the same manner as for traditional IP | |||
| forwarding within the OAL, i.e., nodes use IP forwarding to forward | forwarding within the OAL, i.e., nodes use IP forwarding to forward | |||
| packets not explicitly addressed to themselves. (Proxy/Servers | packets not explicitly addressed to themselves. (Proxy/Servers | |||
| include a special case that accepts and reassembles carrier packets | include a special case that accepts and reassembles carrier packets | |||
| destined to an MNP-XLA or MNP-ULA of one of their Clients received | destined to a *LA-MNP of one of their Clients received over the | |||
| over the secured spanning tree.) Proxy/Servers process carrier | secured spanning tree.) Proxy/Servers process carrier packets with | |||
| packets with their RND-ULA as the destination by first examining the | their ULA as the destination by first examining the packet for a | |||
| packet for a CRH-32 header or an OCH header. In that case, the | CRH-32 header or an OCH header. In that case, the Proxy/Server | |||
| Proxy/Server examines the next MFVI in the carrier packet to locate | examines the next MFVI in the carrier packet to locate the MFV entry | |||
| the MFV entry in the MFIB for next hop forwarding (i.e., without | in the MFIB for next hop forwarding (i.e., without examining IP | |||
| examining IP addresses). When the Proxy/Server forwards the carrier | addresses). When the Proxy/Server forwards the carrier packet, it | |||
| packet, it changes the destination address according to the MFVI | changes the destination address according to the MFVI value for the | |||
| value for the next hop found either in the CRH-32 header or in the | next hop found either in the CRH-32 header or in the node's own MFIB. | |||
| node's own MFIB. Proxy/Servers must verify that the L2 addresses of | Proxy/Servers must verify that the L2 addresses of carrier packets | |||
| carrier packets not received from the secured spanning tree are | not received from the secured spanning tree are "trusted" before | |||
| "trusted" before forwarding according to an MFV (otherwise, the | forwarding according to an MFV (otherwise, the carrier packet must be | |||
| carrier packet must be dropped). | dropped). | |||
| Note: Proxy/Servers may receive carrier packets addressed to their | Note: Proxy/Servers may receive carrier packets addressed to their | |||
| own RND-ULA with CRH-32s that include additional forwarding | own ULA with CRH-32s that include additional forwarding information. | |||
| information. Proxy/Servers use the forwarding information to | Proxy/Servers use the forwarding information to determine the correct | |||
| determine the correct NCE and underlay interface for forwarding to | NCE and underlay interface for forwarding to the target Client, then | |||
| the target Client, then remove the CRH-32 and forward the carrier | remove the CRH-32 and forward the carrier packet. If necessary, the | |||
| packet. If necessary, the Proxy/Server reassembles first before re- | Proxy/Server reassembles first before re-encapsulating (and possibly | |||
| encapsulating (and possibly also re-fragmenting) then forwards to the | also re-fragmenting) then forwards to the target Client. | |||
| target Client. | ||||
| Note: Clients and their FHS Proxy/Server peers can exchange original | Note: Clients and their FHS Proxy/Server peers can exchange original | |||
| IP packets over ANET underlay interfaces without invoking the OAL, | IP packets over ANET underlay interfaces without invoking the OAL, | |||
| since the ANET is secured at the link and physical layers. By | since the ANET is secured at the link and physical layers. By | |||
| forwarding original IP packets without invoking the OAL, however, the | forwarding original IP packets without invoking the OAL, however, the | |||
| Client and Proxy/Server can engage only in classical path MTU | Client and Proxy/Server can engage only in classical path MTU | |||
| discovery since the packets are subject to loss and/or corruption due | discovery since the packets are subject to loss and/or corruption due | |||
| to the various per-link MTU limitations that may occur within the | to the various per-link MTU limitations that may occur within the | |||
| ANET. Moreover, the original IP packets do not include either the | ANET. Moreover, the original IP packets do not include either the | |||
| OAL integrity check or per-packet Identification values that can be | OAL integrity check or per-packet Identification values that can be | |||
| used for data origin authentication and link-layer retransmissions. | used for data origin authentication and link-layer retransmissions. | |||
| The tradeoff therefore involves an assessment of the per-packet | The tradeoff therefore involves an assessment of the per-packet | |||
| encapsulation overhead saved by bypassing the OAL vs. inheritance of | encapsulation overhead saved by bypassing the OAL vs. inheritance of | |||
| classical network "brittleness". (Note however that ANET peers can | classical network "brittleness". (Note however that ANET peers can | |||
| send small original IP packets without invoking the OAL, while | send small original IP packets without invoking the OAL, while | |||
| invoking the OAL for larger packets. This presents the beneficial | invoking the OAL for larger packets. This presents the beneficial | |||
| aspects of both small packet efficiency and large packet robustness.) | aspects of both small packet efficiency and large packet robustness.) | |||
| Note: When a Proxy/Server receives a (non-OAL) original IP packet | Note: When a Proxy/Server receives a (non-OAL) original IP packet | |||
| from an ANET Client, or a carrier packet with OAL destination set to | from an ANET Client, or a carrier packet with OAL destination set to | |||
| its own RND-ULA from any Client, the Proxy/Server reassembles if | its own ULA from any Client, the Proxy/Server reassembles if | |||
| necessary then performs ROS functions on behalf of the Client. The | necessary then performs ROS functions on behalf of the Client. The | |||
| Client may at some later time begin sending carrier packets to the | Client may at some later time begin sending carrier packets to the | |||
| OAL address of the actual target instead of the Proxy/Server, at | OAL address of the actual target instead of the Proxy/Server, at | |||
| which point it may begin functioning as an ROS on its own behalf and | which point it may begin functioning as an ROS on its own behalf and | |||
| thereby "override" the Proxy/Server's ROS role. | thereby "override" the Proxy/Server's ROS role. | |||
| Note; Proxy/Servers drop any original IP packets (received either | Note; Proxy/Servers drop any original IP packets (received either | |||
| directly from an ANET Client or following reassembly of carrier | directly from an ANET Client or following reassembly of carrier | |||
| packets received from an ANET/INET Client) with a destination that | packets received from an ANET/INET Client) with a destination that | |||
| corresponds to the Client's delegated MNP. Similarly, Proxy/Servers | corresponds to the Client's delegated MNP. Similarly, Proxy/Servers | |||
| skipping to change at page 43, line 23 ¶ | skipping to change at page 43, line 23 ¶ | |||
| Gateways convey carrier packets that encapsulate critical IPv6 ND | Gateways convey carrier packets that encapsulate critical IPv6 ND | |||
| control messages or routing protocol control messages via the SRT | control messages or routing protocol control messages via the SRT | |||
| secured spanning tree, and may convey other carrier packets via the | secured spanning tree, and may convey other carrier packets via the | |||
| secured/unsecured spanning tree or via more direct paths according to | secured/unsecured spanning tree or via more direct paths according to | |||
| MFIB information. When the Gateway receives a carrier packet, it | MFIB information. When the Gateway receives a carrier packet, it | |||
| removes the L2 headers and searches for an MFIB entry that matches an | removes the L2 headers and searches for an MFIB entry that matches an | |||
| MFVI or an IP forwarding table entry that matches the OAL destination | MFVI or an IP forwarding table entry that matches the OAL destination | |||
| address. | address. | |||
| Gateways process carrier packets with OAL destinations that do not | Gateways process carrier packets with OAL destinations that do not | |||
| match their RND-ULA or the SRT Subnet Router Anycast address in the | match their ULA or the SRT Subnet Router Anycast address in the same | |||
| same manner as for traditional IP forwarding within the OAL, i.e., | manner as for traditional IP forwarding within the OAL, i.e., nodes | |||
| nodes use IP forwarding to forward packets not explicitly addressed | use IP forwarding to forward packets not explicitly addressed to | |||
| to themselves. Gateways process carrier packets with their RND-ULA | themselves. Gateways process carrier packets with their ULA or the | |||
| or the SRT Subnet Router Anycast address as the destination by first | SRT Subnet Router Anycast address as the destination by first | |||
| examining the packet for a full OAL header with a CRH-32 extension or | examining the packet for a full OAL header with a CRH-32 extension or | |||
| an OCH header. In that case, the Gateway examines the next MFVI in | an OCH header. In that case, the Gateway examines the next MFVI in | |||
| the carrier packet to locate the MFV entry in the MFIB for next hop | the carrier packet to locate the MFV entry in the MFIB for next hop | |||
| forwarding (i.e., without examining IP addresses). When the Gateway | forwarding (i.e., without examining IP addresses). When the Gateway | |||
| forwards the carrier packet, it changes the destination address | forwards the carrier packet, it changes the destination address | |||
| according to the MFVI value for the next hop found either in the | according to the MFVI value for the next hop found either in the | |||
| CRH-32 header or in the node's own MFIB. If the Gateway has a NCE | CRH-32 header or in the node's own MFIB. If the Gateway has a NCE | |||
| for the target Client with an entry for the target underlay interface | for the target Client with an entry for the target underlay interface | |||
| and current L2 addresses, the Gateway instead forwards directly to | and current L2 addresses, the Gateway instead forwards directly to | |||
| the target Client while using the final hop MFVI instead of the next | the target Client while using the final hop MFVI instead of the next | |||
| skipping to change at page 47, line 38 ¶ | skipping to change at page 47, line 38 ¶ | |||
| one among them to serve as the Hub Proxy/Server (the Client may | one among them to serve as the Hub Proxy/Server (the Client may | |||
| instead select a "third-party" Hub Proxy/Server that does not | instead select a "third-party" Hub Proxy/Server that does not | |||
| directly service any of its underlay interfaces). All of the | directly service any of its underlay interfaces). All of the | |||
| Client's other FHS Proxy/Servers forward proxyed copies of RS/RA | Client's other FHS Proxy/Servers forward proxyed copies of RS/RA | |||
| messages between the Hub Proxy/Server and Client without assuming the | messages between the Hub Proxy/Server and Client without assuming the | |||
| Hub role functions themselves. | Hub role functions themselves. | |||
| Each Client associates with a single Hub Proxy/Server at a time, | Each Client associates with a single Hub Proxy/Server at a time, | |||
| while all other Proxy/Servers are candidates for providing the Hub | while all other Proxy/Servers are candidates for providing the Hub | |||
| role for other Clients. An FHS Proxy/Server assumes the Hub role | role for other Clients. An FHS Proxy/Server assumes the Hub role | |||
| when it receives an RS message with its own RND-ULA or link-scoped | when it receives an RS message with its own ULA or link-scoped All- | |||
| All-Routers multicast as the destination. An FHS Proxy/Server | Routers multicast as the destination. An FHS Proxy/Server assumes | |||
| assumes the proxy role when it receives an RS message with the RND- | the proxy role when it receives an RS message with the ULA of another | |||
| ULA of another Proxy/Server as the destination. (An FHS Proxy/Server | Proxy/Server as the destination. (An FHS Proxy/Server can also | |||
| can also assume the proxy role when it receives an RS message | assume the proxy role when it receives an RS message addressed to | |||
| addressed to link-scoped All-Routers multicast if it can determine | link-scoped All-Routers multicast if it can determine the ULA of | |||
| the RND-ULA of another Proxy/Server to serve as a Hub.) | another Proxy/Server to serve as a Hub.) | |||
| Hosts and Clients on ENET interfaces associate with an upstream | Hosts and Clients on ENET interfaces associate with an upstream | |||
| Client on the ENET the same as a Client would associate with an ANET | Client on the ENET the same as a Client would associate with an ANET | |||
| Proxy/Server. In particular, the Host/Client sends an RS message via | Proxy/Server. In particular, the Host/Client sends an RS message via | |||
| the ENET which directs the message to the upstream Client. The | the ENET which directs the message to the upstream Client. The | |||
| upstream Client returns an RA message. In this way, the downstream | upstream Client returns an RA message. In this way, the downstream | |||
| nodes see the ENET as an ANET and see the upstream Client as a Proxy/ | nodes see the ENET as an ANET and see the upstream Client as a Proxy/ | |||
| Server for that ANET. | Server for that ANET. | |||
| AERO Hosts, Clients and Proxy/Servers use IPv6 ND messages to | AERO Hosts, Clients and Proxy/Servers use IPv6 ND messages to | |||
| skipping to change at page 48, line 18 ¶ | skipping to change at page 48, line 18 ¶ | |||
| unicast RA messages with a short Router Lifetime value (e.g., | unicast RA messages with a short Router Lifetime value (e.g., | |||
| ReachableTime seconds) in response to a Client's RS message. | ReachableTime seconds) in response to a Client's RS message. | |||
| Thereafter, Clients send additional RS messages to keep Proxy/Server | Thereafter, Clients send additional RS messages to keep Proxy/Server | |||
| state alive. | state alive. | |||
| AERO Clients and Hub Proxy/Servers include prefix delegation and/or | AERO Clients and Hub Proxy/Servers include prefix delegation and/or | |||
| registration parameters in RS/RA messages. The IPv6 ND messages are | registration parameters in RS/RA messages. The IPv6 ND messages are | |||
| exchanged between the Client and Hub Proxy/Server (via any FHS Proxy/ | exchanged between the Client and Hub Proxy/Server (via any FHS Proxy/ | |||
| Servers acting as proxys) according to the prefix management schedule | Servers acting as proxys) according to the prefix management schedule | |||
| required by the service. If the Client knows its MNP in advance, it | required by the service. If the Client knows its MNP in advance, it | |||
| can employ prefix registration by including its MNP-XLA as the source | can employ prefix registration by including its XLA-MNP as the source | |||
| address of an RS message and with an OMNI option with valid prefix | address of an RS message and with an OMNI option with valid prefix | |||
| registration information for the MNP. If the Hub Proxy/Server | registration information for the MNP. If the Hub Proxy/Server | |||
| accepts the Client's MNP assertion, it injects the MNP into the | accepts the Client's MNP assertion, it injects the MNP into the | |||
| routing system and establishes the necessary neighbor cache state. | routing system and establishes the necessary neighbor cache state. | |||
| If the Client does not have a pre-assigned MNP, it can instead employ | If the Client does not have a pre-assigned MNP, it can instead employ | |||
| prefix delegation by including a TMP-ULA as the source address of an | prefix delegation by including a TLA as the source address of an RS | |||
| RS message and with an OMNI option with prefix delegation parameters | message and with an OMNI option with prefix delegation parameters to | |||
| to request an MNP. | request an MNP. | |||
| The following sections outlines Host, Client and Proxy/Server | The following sections outlines Host, Client and Proxy/Server | |||
| behaviors based on the Router Discovery and Prefix Registration | behaviors based on the Router Discovery and Prefix Registration | |||
| specifications found in Section 15 of [I-D.templin-6man-omni]. These | specifications found in Section 15 of [I-D.templin-6man-omni]. These | |||
| sections observe all of the OMNI specifications, and include | sections observe all of the OMNI specifications, and include | |||
| additional specifications of the interactions of Client-Proxy/Server | additional specifications of the interactions of Client-Proxy/Server | |||
| RS/RA exchanges with the AERO mobility service. | RS/RA exchanges with the AERO mobility service. | |||
| 3.12.2. AERO Host and Client Behavior | 3.12.2. AERO Host and Client Behavior | |||
| skipping to change at page 49, line 46 ¶ | skipping to change at page 49, line 46 ¶ | |||
| Proxy/Server withdraws the MNP from the routing system. | Proxy/Server withdraws the MNP from the routing system. | |||
| (Alternatively, when the Host/Client associates with a new FHS/Hub | (Alternatively, when the Host/Client associates with a new FHS/Hub | |||
| Proxy/Server it can include an OMNI "Proxy/Server Departure" sub- | Proxy/Server it can include an OMNI "Proxy/Server Departure" sub- | |||
| option in RS messages with the ULAs of the Old FHS/Hub Proxy/ | option in RS messages with the ULAs of the Old FHS/Hub Proxy/ | |||
| Servers.) | Servers.) | |||
| 3.12.3. AERO Proxy/Server Behavior | 3.12.3. AERO Proxy/Server Behavior | |||
| AERO Proxy/Servers act as both IP routers and IPv6 ND proxys, and | AERO Proxy/Servers act as both IP routers and IPv6 ND proxys, and | |||
| support a prefix delegation/registration service for Clients. Proxy/ | support a prefix delegation/registration service for Clients. Proxy/ | |||
| Servers arrange to add their RND-ULAs to the PRL maintained in a | Servers arrange to add their ULAs to the PRL maintained in a static | |||
| static map of Proxy/Server addresses for the link, the DNS resource | map of Proxy/Server addresses for the link, the DNS resource records | |||
| records for the FQDN "linkupnetworks.[domainname]", etc. before | for the FQDN "linkupnetworks.[domainname]", etc. before entering | |||
| entering service. The PRL should be arranged such that Clients can | service. The PRL should be arranged such that Clients can discover | |||
| discover the addresses of Proxy/Servers that are geographically and/ | the addresses of Proxy/Servers that are geographically and/or | |||
| or topologically "close" to their underlay network connections. | topologically "close" to their underlay network connections. | |||
| When a FHS/Hub Proxy/Server receives a prospective Client's RS | When a FHS/Hub Proxy/Server receives a prospective Client's RS | |||
| message, it SHOULD return an immediate RA reply with Router Lifetime | message, it SHOULD return an immediate RA reply with Router Lifetime | |||
| set to 0 if it is currently too busy or otherwise unable to service | set to 0 if it is currently too busy or otherwise unable to service | |||
| the Client; otherwise, it processes the RS as specified in Section 15 | the Client; otherwise, it processes the RS as specified in Section 15 | |||
| of [I-D.templin-6man-omni]. When the Hub Proxy/Server receives the | of [I-D.templin-6man-omni]. When the Hub Proxy/Server receives the | |||
| RS, it determines the correct MNPs to provide to the Client by | RS, it determines the correct MNPs to provide to the Client by | |||
| processing the MNP-XLA prefix parameters and/or the DHCPv6 OMNI sub- | processing the XLA-MNP prefix parameters and/or the DHCPv6 OMNI sub- | |||
| option. When the Hub Proxy/Server returns the MNPs, it also creates | option. When the Hub Proxy/Server returns the MNPs, it also creates | |||
| a forwarding table entry for the MNP resulting in a BGP update (see: | an XLA-MNP forwarding table entry for the MNP resulting in a BGP | |||
| Section 3.2.3). For IPv6, the Hub Proxy/Server creates an IPv6 | update (see: Section 3.2.3). The Hub Proxy/Server then returns an RA | |||
| forwarding table entry based on a standard IPv6 GUA of ULA prefix no | to the Client with destination set to the source of the RS (if an FHS | |||
| longer than /64. For IPv4, the Hub Proxy/Server creates an IPv6 | Proxy/Server on the return path proxys the RA, it changes the | |||
| forwarding table entry based on an IPv4-Compatible IPv6 prefix | destination to the Client's ULA-MNP). | |||
| corresponding to the IPv4 address. The Hub Proxy/Server then returns | ||||
| an RA to the Client with destination set to the source of the RS (if | ||||
| an FHS Proxy/Server on the return path proxys the RA, it changes the | ||||
| destination to the Client's MNP-ULA). | ||||
| After the initial RS/RA exchange, the Hub Proxy/Server maintains a | After the initial RS/RA exchange, the Hub Proxy/Server maintains a | |||
| ReachableTime timer for each of the Client's underlay interfaces | ReachableTime timer for each of the Client's underlay interfaces | |||
| individually (and for the Client's NCE collectively) set to expire | individually (and for the Client's NCE collectively) set to expire | |||
| after ReachableTime seconds. If the Client (or an FHS Proxy/Server) | after ReachableTime seconds. If the Client (or an FHS Proxy/Server) | |||
| issues additional RS messages, the Hub Proxy/Server sends an RA | issues additional RS messages, the Hub Proxy/Server sends an RA | |||
| response and resets ReachableTime. If the Hub Proxy/Server receives | response and resets ReachableTime. If the Hub Proxy/Server receives | |||
| an IPv6 ND message with a prefix release indication it sets the | an IPv6 ND message with a prefix release indication it sets the | |||
| Client's NCE to the DEPARTED state and withdraws the MNP route from | Client's NCE to the DEPARTED state and withdraws the MNP route from | |||
| the routing system after a short delay (e.g., 2 seconds). If | the routing system after a short delay (e.g., 2 seconds). If | |||
| ReachableTime expires before a new RS is received on an individual | ReachableTime expires before a new RS is received on an individual | |||
| underlay interface, the Hub Proxy/Server marks the interface as DOWN. | underlay interface, the Hub Proxy/Server marks the interface as DOWN. | |||
| If ReachableTime expires before any new RS is received on any | If ReachableTime expires before any new RS is received on any | |||
| individual underlay interface, the Hub Proxy/Server sets the NCE | individual underlay interface, the Hub Proxy/Server sets the NCE | |||
| state to STALE and sets a 10 second timer. If the Hub Proxy/Server | state to STALE and sets a 10 second timer. If the Hub Proxy/Server | |||
| has not received a new RS or uNA message with a prefix release | has not received a new RS or uNA message with a prefix release | |||
| indication before the 10 second timer expires, it deletes the NCE and | indication before the 10 second timer expires, it deletes the NCE and | |||
| withdraws the MNP-XLA from the routing system. | withdraws the XLA-MNP from the routing system. | |||
| The Hub Proxy/Server processes any IPv6 ND messages pertaining to the | The Hub Proxy/Server processes any IPv6 ND messages pertaining to the | |||
| Client while forwarding to the Client or responding on the Client's | Client while forwarding to the Client or responding on the Client's | |||
| behalf as necessary. The Hub Proxy/Server may also issue unsolicited | behalf as necessary. The Hub Proxy/Server may also issue unsolicited | |||
| RA messages, e.g., with reconfigure parameters to cause the Client to | RA messages, e.g., with reconfigure parameters to cause the Client to | |||
| renegotiate its prefix delegation/registrations, with Router Lifetime | renegotiate its prefix delegation/registrations, with Router Lifetime | |||
| set to 0 if it can no longer service this Client, etc. The Hub | set to 0 if it can no longer service this Client, etc. The Hub | |||
| Proxy/Server may also receive carrier packets via the secured | Proxy/Server may also receive carrier packets via the secured | |||
| spanning tree that contain initial data packets sent while route | spanning tree that contain initial data packets sent while route | |||
| optimization is in progress. The Hub Proxy/Server reassembles, then | optimization is in progress. The Hub Proxy/Server reassembles, then | |||
| re-encapsulates/re-fragments and forwards the packets to the target | re-encapsulates/re-fragments and forwards the packets to the target | |||
| Client via an FHS Proxy/Server if necessary. Finally, If the NCE is | Client via an FHS Proxy/Server if necessary. Finally, If the NCE is | |||
| in the DEPARTED state, the old Hub Proxy/Server forwards any carrier | in the DEPARTED state, the old Hub Proxy/Server forwards any carrier | |||
| packets it receives from the secured spanning tree and destined to | packets it receives from the secured spanning tree and destined to | |||
| the Client to the new Hub Proxy/Server, then deletes the entry after | the Client to the new Hub Proxy/Server, then deletes the entry after | |||
| DepartTime expires. | DepartTime expires. | |||
| Note: Clients SHOULD arrange to notify former Hub Proxy/Servers of | Note: Clients SHOULD arrange to notify former Hub Proxy/Servers of | |||
| their departures, but Hub Proxy/Servers are responsible for expiring | their departures, but Hub Proxy/Servers are responsible for expiring | |||
| neighbor cache entries and withdrawing MNP-XLA routes even if no | neighbor cache entries and withdrawing XLA-MNP routes even if no | |||
| departure notification is received (e.g., if the Client leaves the | departure notification is received (e.g., if the Client leaves the | |||
| network unexpectedly). Hub Proxy/Servers SHOULD therefore set Router | network unexpectedly). Hub Proxy/Servers SHOULD therefore set Router | |||
| Lifetime to ReachableTime seconds in solicited RA messages to | Lifetime to ReachableTime seconds in solicited RA messages to | |||
| minimize persistent stale cache information in the absence of Client | minimize persistent stale cache information in the absence of Client | |||
| departure notifications. A short Router Lifetime also ensures that | departure notifications. A short Router Lifetime also ensures that | |||
| proactive RS/RA messaging between Clients and FHS Proxy/Servers will | proactive RS/RA messaging between Clients and FHS Proxy/Servers will | |||
| keep any NAT state alive (see above). | keep any NAT state alive (see above). | |||
| Note: All Proxy/Servers on an OMNI link MUST advertise consistent | Note: All Proxy/Servers on an OMNI link MUST advertise consistent | |||
| values in the RA Cur Hop Limit, M and O flags, Reachable Time and | values in the RA Cur Hop Limit, M and O flags, Reachable Time and | |||
| skipping to change at page 51, line 42 ¶ | skipping to change at page 52, line 7 ¶ | |||
| Clients on ANET underlay interfaces the FHS Proxy/Server is located | Clients on ANET underlay interfaces the FHS Proxy/Server is located | |||
| on the ANET/INET boundary, and for Clients on INET underlay | on the ANET/INET boundary, and for Clients on INET underlay | |||
| interfaces the FHS Proxy/Server is located somewhere in the connected | interfaces the FHS Proxy/Server is located somewhere in the connected | |||
| Internetwork. When FHS Proxy/Server "B" processes a Client | Internetwork. When FHS Proxy/Server "B" processes a Client | |||
| registration, it must either assume the Hub role or forward a proxyed | registration, it must either assume the Hub role or forward a proxyed | |||
| registration to another Proxy/Server "A" acting as the Hub. Proxy/ | registration to another Proxy/Server "A" acting as the Hub. Proxy/ | |||
| Servers satisfy these requirements as follows: | Servers satisfy these requirements as follows: | |||
| * when FHS Proxy/Server "B" receives a Client RS message, it first | * when FHS Proxy/Server "B" receives a Client RS message, it first | |||
| verifies that the OAL Identification is within the window for the | verifies that the OAL Identification is within the window for the | |||
| NCE that matches the MNP-ULA for this Client neighbor and | NCE that matches the *LA-MNP for this Client neighbor and | |||
| authenticates the message. If no NCE was found, Proxy/Server "B" | authenticates the message. If no NCE was found, Proxy/Server "B" | |||
| instead creates one in the STALE state and caches the Client- | instead creates one in the STALE state and caches the Client- | |||
| supplied Interface Attributes, Origin Indication and OMNI Neighbor | supplied Interface Attributes, Origin Indication and OMNI Neighbor | |||
| Coordination header window synchronization parameters as well as | Coordination header window synchronization parameters as well as | |||
| the Client's observed L2 addresses (noting that they may differ | the Client's observed L2 addresses (noting that they may differ | |||
| from the Origin addresses if there were NATs on the path). Proxy/ | from the Origin addresses if there were NATs on the path). Proxy/ | |||
| Server "B" then examines the network-layer destination address. | Server "B" then examines the network-layer destination address. | |||
| If the destination address is the RND-ULA of a different Proxy/ | If the destination address is the ULA of a different Proxy/Server | |||
| Server "A", Proxy/Server "B" prepares a separate proxyed version | "A", Proxy/Server "B" prepares a separate proxyed version of the | |||
| of the RS message with an OAL header with source set to its own | RS message with an OAL header with source set to its own ULA and | |||
| RND-ULA and destination set to Proxy/Server B's RND-ULA. Proxy/ | destination set to Proxy/Server B's ULA. Proxy/Server "B" also | |||
| Server "B" also writes its own information over the Interface | writes its own information over the Interface Attributes sub- | |||
| Attributes sub-option supplied by the Client, omits or zeros the | option supplied by the Client, omits or zeros the Origin | |||
| Origin Indication sub-option then forwards the message into the | Indication sub-option then forwards the message into the OMNI link | |||
| OMNI link secured spanning tree. | secured spanning tree. | |||
| * when Hub Proxy/Server "A" receives the RS, it assume the Hub role | * when Hub Proxy/Server "A" receives the RS, it assume the Hub role | |||
| and creates/updates a NCE for the Client with FHS Proxy/Server | and creates/updates a NCE for the Client with FHS Proxy/Server | |||
| "B"'s Interface Attributes as the link-layer address information | "B"'s Interface Attributes as the link-layer address information | |||
| for this FHS omIndex. Hub Proxy/Server "A" then prepares an RA | for this FHS omIndex. Hub Proxy/Server "A" then prepares an RA | |||
| message with source set to its own RND-ULA and destination set to | message with source set to its own ULA and destination set to the | |||
| the source of the RS message, then encapsulates the RA in an OAL | source of the RS message, then encapsulates the RA in an OAL | |||
| header with source set to its own RND-ULA and destination set to | header with source set to its own ULA and destination set to the | |||
| the RND-ULA of FHS Proxy/Server "B". Hub Proxy/Server "A" then | ULA of FHS Proxy/Server "B". Hub Proxy/Server "A" then performs | |||
| performs fragmentation if necessary and sends the resulting | fragmentation if necessary and sends the resulting carrier packets | |||
| carrier packets into the secured spanning tree. | into the secured spanning tree. | |||
| * when FHS Proxy/Server "B" reassembles the RA, it locates the | * when FHS Proxy/Server "B" reassembles the RA, it locates the | |||
| Client NCE based on the RA destination. If the RA message | Client NCE based on the RA destination. If the RA message | |||
| includes an OMNI "Proxy/Server Departure" sub-option, Proxy/Server | includes an OMNI "Proxy/Server Departure" sub-option, Proxy/Server | |||
| "B" first sends a uNA to the old FHS/Hub Proxy/Servers named in | "B" first sends a uNA to the old FHS/Hub Proxy/Servers named in | |||
| the sub-option. Proxy/Server "B" then changes the RA destination | the sub-option. Proxy/Server "B" then changes the RA destination | |||
| address to the MNP-ULA of the Client, then re-encapsulates the | address to the ULA-MNP of the Client, then re-encapsulates the | |||
| message with OAL source set to its own RND-ULA and OAL destination | message with OAL source set to its own ULA and OAL destination set | |||
| set to ULA that appeared in the Client's RS source, with an | to ULA that appeared in the Client's RS source, with an | |||
| appropriate Identification value, with an authentication signature | appropriate Identification value, with an authentication signature | |||
| if necessary, with the Client's Interface Attributes sub-option | if necessary, with the Client's Interface Attributes sub-option | |||
| echoed and with the cached observed L2 addresses written into an | echoed and with the cached observed L2 addresses written into an | |||
| Origin Indication sub-option. Proxy/Server "B" sets the P flag in | Origin Indication sub-option. Proxy/Server "B" sets the P flag in | |||
| the RA flags field to indicate that the message has passed through | the RA flags field to indicate that the message has passed through | |||
| a proxy [RFC4389], includes responsive window synchronization | a proxy [RFC4389], includes responsive window synchronization | |||
| parameters, then fragments the RA if necessary and returns the | parameters, then fragments the RA if necessary and returns the | |||
| fragments to the Client. | fragments to the Client. | |||
| * The Client repeats this process over each of its additional | * The Client repeats this process over each of its additional | |||
| underlay interfaces while treating each additional FHS Proxy/ | underlay interfaces while treating each additional FHS Proxy/ | |||
| Server "C", "D", "E", etc. as a proxy to facilitate RS/RA | Server "C", "D", "E", etc. as a proxy to facilitate RS/RA | |||
| exchanges between the Hub and the Client. The Client creates/ | exchanges between the Hub and the Client. The Client creates/ | |||
| updates NCEs for each such FHS Proxy/Server as well as the Hub | updates NCEs for each such FHS Proxy/Server as well as the Hub | |||
| Proxy/Server in the process. | Proxy/Server in the process. | |||
| After the initial RS/RA exchanges each FHS Proxy/Server forwards any | After the initial RS/RA exchanges each FHS Proxy/Server forwards any | |||
| of the Client's carrier packets with OAL destinations for which there | of the Client's carrier packets with OAL destinations for which there | |||
| is no matching NCE to a Gateway using OAL encapsulation with its own | is no matching NCE to a Gateway using OAL encapsulation with its own | |||
| RND-ULA as the source and with destination determined by the Client. | ULA as the source and with destination determined by the Client. The | |||
| The Proxy/Server instead forwards any carrier packets destined to a | Proxy/Server instead forwards any carrier packets destined to a | |||
| neighbor cache target directly to the target according to the OAL/ | neighbor cache target directly to the target according to the OAL/ | |||
| link-layer information - the process of establishing neighbor cache | link-layer information - the process of establishing neighbor cache | |||
| entries is specified in Section 3.13. | entries is specified in Section 3.13. | |||
| While the Client is still associated with FHS Proxy/Servers "B", "C", | While the Client is still associated with FHS Proxy/Servers "B", "C", | |||
| "D", etc., each FHS Proxy/Server can send NS, RS and/or unsolicited | "D", etc., each FHS Proxy/Server can send NS, RS and/or unsolicited | |||
| NA messages to update the neighbor cache entries of other AERO nodes | NA messages to update the neighbor cache entries of other AERO nodes | |||
| on behalf of the Client based on changes in Interface Attributes, | on behalf of the Client based on changes in Interface Attributes, | |||
| Traffic Selectors, etc. This allows for higher-frequency Proxy- | Traffic Selectors, etc. This allows for higher-frequency Proxy- | |||
| initiated RS/RA messaging over well-connected INET infrastructure | initiated RS/RA messaging over well-connected INET infrastructure | |||
| skipping to change at page 53, line 31 ¶ | skipping to change at page 53, line 38 ¶ | |||
| constrained ANET data links. | constrained ANET data links. | |||
| If the Hub Proxy/Server "A" ceases to send solicited RAs, FHS Proxy/ | If the Hub Proxy/Server "A" ceases to send solicited RAs, FHS Proxy/ | |||
| Servers "B", "C", "D" can send unsolicited RAs over the Client's | Servers "B", "C", "D" can send unsolicited RAs over the Client's | |||
| underlay interface with destination set to (link-local) All-Nodes | underlay interface with destination set to (link-local) All-Nodes | |||
| multicast and with Router Lifetime set to zero to inform Clients that | multicast and with Router Lifetime set to zero to inform Clients that | |||
| the Hub Proxy/Server has failed. Although FHS Proxy/Servers "B", "C" | the Hub Proxy/Server has failed. Although FHS Proxy/Servers "B", "C" | |||
| and "D" can engage in IPv6 ND exchanges on behalf of the Client, the | and "D" can engage in IPv6 ND exchanges on behalf of the Client, the | |||
| Client can also send IPv6 ND messages on its own behalf, e.g., if it | Client can also send IPv6 ND messages on its own behalf, e.g., if it | |||
| is in a better position to convey state changes. The IPv6 ND | is in a better position to convey state changes. The IPv6 ND | |||
| messages sent by the Client include the Client's MNP-ULA as the | messages sent by the Client include the Client's XLA-MNP as the | |||
| source in order to differentiate them from the IPv6 ND messages sent | source in order to differentiate them from the IPv6 ND messages sent | |||
| by a FHS Proxy/Server. | by a FHS Proxy/Server. | |||
| If the Client becomes unreachable over all underlay interface it | If the Client becomes unreachable over all underlay interface it | |||
| serves, the Hub Proxy/Server sets the NCE state to DEPARTED and | serves, the Hub Proxy/Server sets the NCE state to DEPARTED and | |||
| retains the entry for DepartTime seconds. While the state is | retains the entry for DepartTime seconds. While the state is | |||
| DEPARTED, the Hub Proxy/Server forwards any carrier packets destined | DEPARTED, the Hub Proxy/Server forwards any carrier packets destined | |||
| to the Client to a Gateway via OAL encapsulation. When DepartTime | to the Client to a Gateway via OAL encapsulation. When DepartTime | |||
| expires, the Hub Proxy/Server deletes the NCE, withdraws the MNP-XLA | expires, the Hub Proxy/Server deletes the NCE, withdraws the XLA-MNP | |||
| route and discards any further carrier packets destined to the former | route and discards any further carrier packets destined to the former | |||
| Client. | Client. | |||
| In some ANETs that employ a Proxy/Server, the Client's MNP can be | In some ANETs that employ a Proxy/Server, the Client's MNP can be | |||
| injected into the ANET routing system. In that case, the Client can | injected into the ANET routing system. In that case, the Client can | |||
| send original IP packets without invoking the OAL so that the ANET | send original IP packets without invoking the OAL so that the ANET | |||
| routing system transports the original IP packets to the Proxy/ | routing system transports the original IP packets to the Proxy/ | |||
| Server. This can be beneficial, e.g., if the Client connects to the | Server. This can be beneficial, e.g., if the Client connects to the | |||
| ANET via low-end data links such as some aviation wireless links. | ANET via low-end data links such as some aviation wireless links. | |||
| If the ANET first-hop access router is on the same underlay link as | If the ANET first-hop access router is on the same underlay link as | |||
| the Client and recognizes the AERO/OMNI protocol, the Client can | the Client and recognizes the AERO/OMNI protocol, the Client can | |||
| avoid OAL encapsulation for both its control and data messages. When | avoid OAL encapsulation for both its control and data messages. When | |||
| the Client connects to the link, it can send an unencapsulated RS | the Client connects to the link, it can send an unencapsulated RS | |||
| message with source address set to its own MNP-XLA (or to a TMP-ULA), | message with source address set to its own XLA-MNP (or to a TLA), and | |||
| and with destination address set to the RND-ULA of the Client's | with destination address set to the ULA of the Client's selected | |||
| selected Proxy/Server or to link-scoped All-Routers multicast. The | Proxy/Server or to link-scoped All-Routers multicast. The Client | |||
| Client includes an OMNI option formatted as specified in | includes an OMNI option formatted as specified in | |||
| [I-D.templin-6man-omni]. The Client then sends the unencapsulated RS | [I-D.templin-6man-omni]. The Client then sends the unencapsulated RS | |||
| message, which will be intercepted by the AERO-aware ANET access | message, which will be intercepted by the AERO-aware ANET access | |||
| router. | router. | |||
| The ANET access router then performs OAL encapsulation on the RS | The ANET access router then performs OAL encapsulation on the RS | |||
| message and forwards it to a Proxy/Server at the ANET/INET boundary. | message and forwards it to a Proxy/Server at the ANET/INET boundary. | |||
| When the access router and Proxy/Server are one and the same node, | When the access router and Proxy/Server are one and the same node, | |||
| the Proxy/Server would share an underlay link with the Client but its | the Proxy/Server would share an underlay link with the Client but its | |||
| message exchanges with outside correspondents would need to pass | message exchanges with outside correspondents would need to pass | |||
| through a security gateway at the ANET/INET border. The method for | through a security gateway at the ANET/INET border. The method for | |||
| skipping to change at page 55, line 4 ¶ | skipping to change at page 55, line 11 ¶ | |||
| [RFC5880]. Each FHS Proxy/Server can then quickly detect and react | [RFC5880]. Each FHS Proxy/Server can then quickly detect and react | |||
| to failures so that cached information is re-established through | to failures so that cached information is re-established through | |||
| alternate paths. The NS/NA(NUD) control messaging is carried only | alternate paths. The NS/NA(NUD) control messaging is carried only | |||
| over well-connected ground domain networks (i.e., and not low-end | over well-connected ground domain networks (i.e., and not low-end | |||
| aeronautical radio links) and can therefore be tuned for rapid | aeronautical radio links) and can therefore be tuned for rapid | |||
| response. | response. | |||
| FHS Proxy/Servers perform continuous NS/NA(NUD) exchanges with the | FHS Proxy/Servers perform continuous NS/NA(NUD) exchanges with the | |||
| Hub Proxy/Server, e.g., one exchange per second. The FHS Proxy/ | Hub Proxy/Server, e.g., one exchange per second. The FHS Proxy/ | |||
| Server sends the NS(NUD) message via the spanning tree with its own | Server sends the NS(NUD) message via the spanning tree with its own | |||
| RND-ULA as the source and the RND-ULA of the Hub Proxy/Server as the | ULA as the source and the ULA of the Hub Proxy/Server as the | |||
| destination, and the Hub Proxy/Server responds with an NA(NUD). When | destination, and the Hub Proxy/Server responds with an NA(NUD). When | |||
| the FHS Proxy/Server is also sending RS messages to a Hub Proxy/ | the FHS Proxy/Server is also sending RS messages to a Hub Proxy/ | |||
| Server on behalf of Clients, the resulting RA responses can be | Server on behalf of Clients, the resulting RA responses can be | |||
| considered as equivalent hints of forward progress. This means that | considered as equivalent hints of forward progress. This means that | |||
| the FHS Proxy/Server need not also send a periodic NS(NUD) if it has | the FHS Proxy/Server need not also send a periodic NS(NUD) if it has | |||
| already sent an RS within the same period. If the Hub Proxy/Server | already sent an RS within the same period. If the Hub Proxy/Server | |||
| fails (i.e., if the FHS Proxy/Server ceases to receive | fails (i.e., if the FHS Proxy/Server ceases to receive | |||
| advertisements), the FHS Proxy/Server can quickly inform Clients by | advertisements), the FHS Proxy/Server can quickly inform Clients by | |||
| sending unsolicited RA messages | sending unsolicited RA messages | |||
| The FHS Proxy/Server sends unsolicited RA messages with source | The FHS Proxy/Server sends unsolicited RA messages with source | |||
| address set to the Hub Proxy/Server's address, destination address | address set to the Hub Proxy/Server's address, destination address | |||
| set to (link-local) All-Nodes multicast, and Router Lifetime set to | set to (link-local) All-Nodes multicast, and Router Lifetime set to | |||
| 0. The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA | 0. The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA | |||
| messages separated by small delays [RFC4861]. Any Clients that had | messages separated by small delays [RFC4861]. Any Clients that had | |||
| been using the failed Hub Proxy/Server will receive the RA messages | been using the failed Hub Proxy/Server will receive the RA messages | |||
| and select one of its other FHS Proxy/Servers to assume the Hub role | and select one of its other FHS Proxy/Servers to assume the Hub role | |||
| (i.e., by sending an RS with destination set to the RND-ULA of the | (i.e., by sending an RS with destination set to the ULA of the new | |||
| new Hub). | Hub). | |||
| 3.12.3.3. DHCPv6-Based Prefix Registration | 3.12.3.3. DHCPv6-Based Prefix Registration | |||
| When a Client is not pre-provisioned with an MNP, it will need for | When a Client is not pre-provisioned with an MNP, it will need for | |||
| the Hub Proxy/Server to select one or more MNPs on its behalf and set | the Hub Proxy/Server to select one or more MNPs on its behalf and set | |||
| up the correct state in the AERO routing service. (A Client with a | up the correct state in the AERO routing service. (A Client with a | |||
| pre-provisioned MNP may also request the Hub Proxy/Server to select | pre-provisioned MNP may also request the Hub Proxy/Server to select | |||
| additional MNPs.) The DHCPv6 service [RFC8415] is used to support | additional MNPs.) The DHCPv6 service [RFC8415] is used to support | |||
| this requirement. | this requirement. | |||
| When a Client needs to have the Hub Proxy/Server select MNPs, it | When a Client needs to have the Hub Proxy/Server select MNPs, it | |||
| sends an RS message with source address set to a TMP-ULA and with an | sends an RS message with source address set to a TLA and with an OMNI | |||
| OMNI option that includes a DHCPv6 message sub-option with DHCPv6 | option that includes a DHCPv6 message sub-option with DHCPv6 Prefix | |||
| Prefix Delegation (DHCPv6-PD) parameters. When the Hub Proxy/Server | Delegation (DHCPv6-PD) parameters. When the Hub Proxy/Server | |||
| receives the RS message, it extracts the DHCPv6-PD message from the | receives the RS message, it extracts the DHCPv6-PD message from the | |||
| OMNI option. | OMNI option. | |||
| The Hub Proxy/Server then acts as a "Proxy DHCPv6 Client" in a | The Hub Proxy/Server then acts as a "Proxy DHCPv6 Client" in a | |||
| message exchange with the locally-resident DHCPv6 server, which | message exchange with the locally-resident DHCPv6 server, which | |||
| delegates MNPs and returns a DHCPv6-PD Reply message. (If the Hub | delegates MNPs and returns a DHCPv6-PD Reply message. (If the Hub | |||
| Proxy/Server wishes to defer creation of MN state until the DHCPv6-PD | Proxy/Server wishes to defer creation of MN state until the DHCPv6-PD | |||
| Reply is received, it can instead act as a Lightweight DHCPv6 Relay | Reply is received, it can instead act as a Lightweight DHCPv6 Relay | |||
| Agent per [RFC6221] by encapsulating the DHCPv6-PD message in a | Agent per [RFC6221] by encapsulating the DHCPv6-PD message in a | |||
| Relay-forward/reply exchange with Relay Message and Interface ID | Relay-forward/reply exchange with Relay Message and Interface ID | |||
| skipping to change at page 56, line 4 ¶ | skipping to change at page 56, line 8 ¶ | |||
| OMNI option. | OMNI option. | |||
| The Hub Proxy/Server then acts as a "Proxy DHCPv6 Client" in a | The Hub Proxy/Server then acts as a "Proxy DHCPv6 Client" in a | |||
| message exchange with the locally-resident DHCPv6 server, which | message exchange with the locally-resident DHCPv6 server, which | |||
| delegates MNPs and returns a DHCPv6-PD Reply message. (If the Hub | delegates MNPs and returns a DHCPv6-PD Reply message. (If the Hub | |||
| Proxy/Server wishes to defer creation of MN state until the DHCPv6-PD | Proxy/Server wishes to defer creation of MN state until the DHCPv6-PD | |||
| Reply is received, it can instead act as a Lightweight DHCPv6 Relay | Reply is received, it can instead act as a Lightweight DHCPv6 Relay | |||
| Agent per [RFC6221] by encapsulating the DHCPv6-PD message in a | Agent per [RFC6221] by encapsulating the DHCPv6-PD message in a | |||
| Relay-forward/reply exchange with Relay Message and Interface ID | Relay-forward/reply exchange with Relay Message and Interface ID | |||
| options.) | options.) | |||
| When the Hub Proxy/Server receives the DHCPv6-PD Reply, it creates an | When the Hub Proxy/Server receives the DHCPv6-PD Reply, it creates an | |||
| MNP-XLA based on the delegated MNP adds an MNP-XLA route to the | XLA based on the delegated MNP adds an XLA-MNP route to the routing | |||
| routing system. The Hub Proxy/Server then sends an RA back to the | system. The Hub Proxy/Server then sends an RA back to the Client | |||
| Client either directly or via an FHS Proxy/Server acting as a proxy. | either directly or via an FHS Proxy/Server acting as a proxy. The | |||
| The Proxy/Server that returns the RA directly to the Client sets the | Proxy/Server that returns the RA directly to the Client sets the | |||
| (newly-created) MNP-ULA as the destination address and with the | (newly-created) ULA-MNP as the destination address and with the | |||
| DHCPv6-PD Reply message and OMNI Neighbor Coordination header Preflen | DHCPv6-PD Reply message and OMNI Neighbor Coordination header Preflen | |||
| coded in the OMNI option. When the Client receives the RA, it | coded in the OMNI option. When the Client receives the RA, it | |||
| creates a default route, assigns the Subnet Router Anycast address | creates a default route, assigns the Subnet Router Anycast address | |||
| and sets its MNP-ULA and MNP-XLA based on the delegated MNP. | and sets its {ULA,XLA}-MNP based on the delegated MNP. | |||
| Note: Further details of the DHCPv6-PD based MNP registration (as | Note: Further details of the DHCPv6-PD based MNP registration (as | |||
| well as a minimal MNP delegation alternative that avoids including a | well as a minimal MNP delegation alternative that avoids including a | |||
| DHCPv6 message sub-option in the RS) are found in | DHCPv6 message sub-option in the RS) are found in | |||
| [I-D.templin-6man-omni]. | [I-D.templin-6man-omni]. | |||
| Note: when the Hub Proxy/Server forwards an RA to the Client via a | Note: when the Hub Proxy/Server forwards an RA to the Client via a | |||
| different node acting as a FHS Proxy/Server, the Hub sets the RA | different node acting as a FHS Proxy/Server, the Hub sets the RA | |||
| destination to the same address that appeared in the RS source. The | destination to the same address that appeared in the RS source. The | |||
| FHS Proxy/Server then subsequently sets the RA destination to the | FHS Proxy/Server then subsequently sets the RA destination to the | |||
| MNP-ULA when it forwards the Proxyed version of the RA to the Client | ULA-MNP when it forwards the Proxyed version of the RA to the Client | |||
| - see [I-D.templin-6man-omni] for further details. | - see [I-D.templin-6man-omni] for further details. | |||
| 3.13. AERO Route Optimization | 3.13. AERO Route Optimization | |||
| AERO nodes invoke route optimization when they need to forward | AERO nodes invoke route optimization when they need to forward | |||
| initial packets to new target destinations over ANET/INET interfaces | initial packets to new target destinations over ANET/INET interfaces | |||
| and for ongoing multilink forwarding for current destinations. Route | and for ongoing multilink forwarding for current destinations. Route | |||
| optimization is based on IPv6 ND Address Resolution messaging between | optimization is based on IPv6 ND Address Resolution messaging between | |||
| a Route Optimization Source (ROS) and a Relay or the target Client | a Route Optimization Source (ROS) and a Relay or the target Client | |||
| itself (reached via the current Hub Proxy/Server) acting as a Route | itself (reached via the current Hub Proxy/Server) acting as a Route | |||
| skipping to change at page 57, line 23 ¶ | skipping to change at page 57, line 29 ¶ | |||
| ROS of any changes. Following address resolution, the ROS and ROR | ROS of any changes. Following address resolution, the ROS and ROR | |||
| perform ongoing multilink route optimizations to maintain optimal | perform ongoing multilink route optimizations to maintain optimal | |||
| forwarding profiles. | forwarding profiles. | |||
| The route optimization procedures are specified in the following | The route optimization procedures are specified in the following | |||
| sections. | sections. | |||
| 3.13.1. Multilink Address Resolution | 3.13.1. Multilink Address Resolution | |||
| When one or more original IP packets from a source node destined to a | When one or more original IP packets from a source node destined to a | |||
| target node arrives, the ROS checks for a NCE with an MNP-XLA that | target node arrives, the ROS checks for a NCE with an XLA that | |||
| matches the target destination. If there is a NCE in the REACHABLE | matches the target destination. If there is a NCE in the REACHABLE | |||
| state, the ROS invokes the OAL and forwards the resulting carrier | state, the ROS invokes the OAL and forwards the resulting carrier | |||
| packets according to the cached state then returns from processing. | packets according to the cached state then returns from processing. | |||
| Otherwise, if there is no NCE the ROS creates one in the INCOMPLETE | Otherwise, if there is no NCE the ROS creates one in the INCOMPLETE | |||
| state. | state. | |||
| The ROS next prepares an NS message for Address Resolution (NS(AR)) | The ROS next prepares an NS message for Address Resolution (NS(AR)) | |||
| to send toward an ROR while including the original IP packet(s) as | to send toward an ROR while including the original IP packet(s) as | |||
| trailing data following the NS(AR) in an OAL super-packet | trailing data following the NS(AR) in an OAL super-packet | |||
| [I-D.templin-6man-omni]. The resulting NS(AR) message must be sent | [I-D.templin-6man-omni]. The resulting NS(AR) message must be sent | |||
| securely, and includes: | securely, and includes: | |||
| * the ULA of the ROS as the source address. | * the ULA of the ROS as the source address. | |||
| * the MNP-XLA corresponding to the original IP packet's destination | * the XLA corresponding to the original IP packet's destination as | |||
| as the Target Address, e.g., for 2001:db8:1:2::10:2000 the Target | the Target Address, e.g., for 2001:db8:1:2::10:2000 the Target | |||
| Address is fd00::2001:db8:1:2. | Address is fd00::2001:db8:1:2. | |||
| * the Solicited-Node multicast address [RFC4291] formed from the | * the Solicited-Node multicast address [RFC4291] formed from the | |||
| lower 24 bits of the original IP packet's destination as the | lower 24 bits of the original IP packet's destination as the | |||
| destination address, e.g., for 2001:db8:1:2::10:2000 the NS(AR) | destination address, e.g., for 2001:db8:1:2::10:2000 the NS(AR) | |||
| destination address is ff02:0:0:0:0:1:ff10:2000. | destination address is ff02:0:0:0:0:1:ff10:2000. | |||
| The NS(AR) message also includes an OMNI option with an | The NS(AR) message also includes an OMNI option with an | |||
| authentication sub-option if necessary and with OMNI extension header | authentication sub-option if necessary and with OMNI extension header | |||
| Preflen set to the prefix length associated with the NS(AR) source. | Preflen set to the prefix length associated with the NS(AR) source. | |||
| The ROS also includes Interface Attributes and Traffic Selectors for | The ROS also includes Interface Attributes and Traffic Selectors for | |||
| all of the source Client's underlay interfaces, calculates the | all of the source Client's underlay interfaces, calculates the | |||
| authentication signature or checksum, then selects an Identification | authentication signature or checksum, then selects an Identification | |||
| value and submits the NS(AR) message for OAL encapsulation with OAL | value and submits the NS(AR) message for OAL encapsulation with OAL | |||
| source set to its own {ADM,MNP}-ULA and OAL destination set to the | source set to its own ULA and OAL destination set to the XLA | |||
| MNP-XLA corresponding to the target and with window synchronization | corresponding to the target and with window synchronization | |||
| parameters. The ROS then inserts a fragment header, performs | parameters. The ROS then inserts a fragment header, performs | |||
| fragmentation and L2 encapsulation, then sends the resulting carrier | fragmentation and L2 encapsulation, then sends the resulting carrier | |||
| packets into the SRT secured spanning tree without decrementing the | packets into the SRT secured spanning tree without decrementing the | |||
| network-layer TTL/Hop Limit field. | network-layer TTL/Hop Limit field. | |||
| When the ROS is a Client, it must instead use the RND-ULA of one of | When the ROS is a Client, it must instead use the ULA of one of its | |||
| its FHS Proxy/Servers as the OAL destination. The ROS Client then | FHS Proxy/Servers as the OAL destination. The ROS Client then | |||
| fragments, performs L2 encapsulation and forwards the carrier packets | fragments, performs L2 encapsulation and forwards the carrier packets | |||
| to the FHS Proxy/Server. The FHS Proxy/Server then reassembles, | to the FHS Proxy/Server. The FHS Proxy/Server then reassembles, | |||
| verifies the NS(AR) authentication signature or checksum, changes the | verifies the NS(AR) authentication signature or checksum, changes the | |||
| OAL source to its own RND-ULA, changes the OAL destination to the | OAL source to its own ULA, changes the OAL destination to the XLA | |||
| MNP-XLA corresponding to the target, selects an appropriate | corresponding to the target, selects an appropriate Identification, | |||
| Identification, then re-fragments and forwards the resulting carrier | then re-fragments and forwards the resulting carrier packets into the | |||
| packets into the secured spanning tree on behalf of the Client. | secured spanning tree on behalf of the Client. | |||
| Note: both the target Client and its Hub Proxy/Server include current | Note: both the target Client and its Hub Proxy/Server include current | |||
| and accurate information for the Client's multilink Interface | and accurate information for the Client's multilink Interface | |||
| Attributes profile. The Hub Proxy/Server can be trusted to provide | Attributes profile. The Hub Proxy/Server can be trusted to provide | |||
| an authoritative response on behalf of the Client should the need | an authoritative response on behalf of the Client should the need | |||
| arise. While the Client has no such trust basis, any attempt by the | arise. While the Client has no such trust basis, any attempt by the | |||
| Client to mount an attack by providing false Interface Attributes | Client to mount an attack by providing false Interface Attributes | |||
| information would only result in black-holing of return traffic, | information would only result in black-holing of return traffic, | |||
| i.e., the "attack" could only result in denial of service to the | i.e., the "attack" could only result in denial of service to the | |||
| Client itself. Therefore, the Client's asserted Interface Attributes | Client itself. Therefore, the Client's asserted Interface Attributes | |||
| skipping to change at page 59, line 8 ¶ | skipping to change at page 59, line 8 ¶ | |||
| address. The Gateway then decrements the OAL header Hop-Limit, then | address. The Gateway then decrements the OAL header Hop-Limit, then | |||
| re-encapsulates and forwards the carrier packet(s) via the secured | re-encapsulates and forwards the carrier packet(s) via the secured | |||
| spanning tree the same as for any IPv6 router, where they may | spanning tree the same as for any IPv6 router, where they may | |||
| traverse multiple OMNI link segments. The final-hop Gateway will | traverse multiple OMNI link segments. The final-hop Gateway will | |||
| deliver the carrier packet via the secured spanning tree to the Hub | deliver the carrier packet via the secured spanning tree to the Hub | |||
| Proxy/Server (or Relay) that services the target. | Proxy/Server (or Relay) that services the target. | |||
| 3.13.1.2. Processing and Responding to the NS(AR) | 3.13.1.2. Processing and Responding to the NS(AR) | |||
| When the Hub Proxy/Server for the target receives the NS(AR) secured | When the Hub Proxy/Server for the target receives the NS(AR) secured | |||
| carrier packets with the MNP-XLA of the target as the OAL | carrier packets with the XLA of the target as the OAL destination, it | |||
| destination, it reassembles then forwards the message to the target | reassembles then forwards the message to the target Client (while | |||
| Client (while including an authentication signature and encapsulation | including an authentication signature and encapsulation if necessary) | |||
| if necessary) or processes the NS(AR) locally if it is acting as a | or processes the NS(AR) locally if it is acting as a Relay/IP router | |||
| Relay/IP router or the Client's designated ROR. The Hub Proxy/Server | or the Client's designated ROR. The Hub Proxy/Server processes the | |||
| processes the message as follows: | message as follows: | |||
| * if the NS(AR) target matches a Client NCE in the DEPARTED state, | * if the NS(AR) target matches a Client NCE in the DEPARTED state, | |||
| the (old) Hub Proxy/Server re-encapsulates by setting the OAL | the (old) Hub Proxy/Server re-encapsulates by setting the OAL | |||
| destination address to the RND-ULA of the Client's new Hub Proxy/ | destination address to the ULA of the Client's new Hub Proxy/ | |||
| Server. The old Hub Proxy/Server then re-fragments and re- | Server. The old Hub Proxy/Server then re-fragments and re- | |||
| encapsulates, then forwards the resulting carrier packets over the | encapsulates, then forwards the resulting carrier packets over the | |||
| secured spanning tree. | secured spanning tree. | |||
| * If the NS(AR) target matches a Client NCE in the REACHABLE state, | * If the NS(AR) target matches a Client NCE in the REACHABLE state, | |||
| the Hub Proxy/Server notes whether the NS(AR) arrived from the | the Hub Proxy/Server notes whether the NS(AR) arrived from the | |||
| secured spanning tree then sets the OAL destination address to the | secured spanning tree then sets the OAL destination address to the | |||
| MNP-ULA of the Client or the RND-ULA of the selected FHS Proxy/ | ULA-MNP of the Client or the ULA of the selected FHS Proxy/Server | |||
| Server for the Client (i.e., if the Hub is not also the FHS Proxy/ | for the Client (i.e., if the Hub is not also the FHS Proxy/Server | |||
| Server for the selected underlay interface). If the message | for the selected underlay interface). If the message arrived via | |||
| arrived via the secured spanning tree the Hub Proxy/Server | the secured spanning tree the Hub Proxy/Server verifies the | |||
| verifies the checksum; otherwise, it must verify the message | checksum; otherwise, it must verify the message authentication | |||
| authentication signature before forwarding. When the Hub Proxy/ | signature before forwarding. When the Hub Proxy/Server determines | |||
| Server determines the underlay interface for the target Client, it | the underlay interface for the target Client, it then changes the | |||
| then changes the OAL destination to the RND-ULA of the target | OAL destination to the ULA of the target Client's FHS Proxy/ | |||
| Client's FHS Proxy/Server, re-fragments and forwards the resulting | Server, re-fragments and forwards the resulting carrier packets | |||
| carrier packets into the secured spanning tree. When the FHS | into the secured spanning tree. When the FHS Proxy/Server | |||
| Proxy/Server receives the carrier packets, it reassembles and | receives the carrier packets, it reassembles and verifies the | |||
| verifies the checksum, then includes an authentication signature | checksum, then includes an authentication signature if necessary, | |||
| if necessary, changes the OAL source to its own RND-ULA and | changes the OAL source to its own ULA and destination to the ULA- | |||
| destination to the MNP-ULA of the target Client, includes an | MNP of the target Client, includes an Identification value within | |||
| Identification value within the current window, then re-fragments | the current window, then re-fragments and forwards the resulting | |||
| and forwards the resulting carrier packets to the target Client | carrier packets to the target Client ROR. (Note that if the Hub | |||
| ROR. (Note that if the Hub and FHS Proxy/Server are one and the | and FHS Proxy/Server are one and the same the Hub itself will | |||
| same the Hub itself will perform the FHS procedures.) | perform the FHS procedures.) | |||
| * If the NS(AR) target matches one of its non-MNP routes, the Hub | * If the NS(AR) target matches one of its non-MNP routes, the Hub | |||
| Proxy/Server serves as both a Relay and a ROR, since the Relay | Proxy/Server serves as both a Relay and a ROR, since the Relay | |||
| forwards IP packets toward the (fixed network) target at the | forwards IP packets toward the (fixed network) target at the | |||
| network layer. | network layer. | |||
| The ROR then creates a NCE for the NS(AR) source address if | The ROR then creates a NCE for the NS(AR) source address if | |||
| necessary, processes the window synchronization parameters, caches | necessary, processes the window synchronization parameters, caches | |||
| all Interface Attributes and Traffic Selector information, and | all Interface Attributes and Traffic Selector information, and | |||
| prepares a (solicited) NA(AR) message to return to the ROS with the | prepares a (solicited) NA(AR) message to return to the ROS with the | |||
| source address set to its own MNP-ULA, the destination address set to | source address set to its own ULA-MNP, the destination address set to | |||
| the NS(AR) ULA source address and the Target Address set to the same | the NS(AR) ULA source address and the Target Address set to the same | |||
| value that appeared in the NS(AR) Target Address. The ROR includes | value that appeared in the NS(AR) Target Address. The ROR includes | |||
| an OMNI option with OMNI Neighbor Coordination header Preflen set to | an OMNI option with OMNI Neighbor Coordination header Preflen set to | |||
| the prefix length associated with the NA(AR) source address. | the prefix length associated with the NA(AR) source address. | |||
| The ROR then sets the NA(AR) message R flag to 1 (as a router) and S | The ROR then sets the NA(AR) message R flag to 1 (as a router) and S | |||
| flag to 1 (as a response to a solicitation) and sets the O flag to 1 | flag to 1 (as a response to a solicitation) and sets the O flag to 1 | |||
| (as an authoritative responder). The ROR finally submits the NA(AR) | (as an authoritative responder). The ROR finally submits the NA(AR) | |||
| for OAL encapsulation with source set to its own ULA and destination | for OAL encapsulation with source set to its own ULA and destination | |||
| set to either the ULA corresponding to the NS(AR) source or the RND- | set to either the ULA corresponding to the NS(AR) source or the ULA | |||
| ULA of its FHS Proxy/Server, selects an appropriate Identification, | of its FHS Proxy/Server, selects an appropriate Identification, and | |||
| and includes window synchronization parameters and authentication | includes window synchronization parameters and authentication | |||
| signature or checksum. The ROR then includes Interface Attributes | signature or checksum. The ROR then includes Interface Attributes | |||
| and Traffic Selector sub-options for all of the target's underlay | and Traffic Selector sub-options for all of the target's underlay | |||
| interfaces with current information for each interface, fragments and | interfaces with current information for each interface, fragments and | |||
| encapsulates each fragment in appropriate L2 headers, then forwards | encapsulates each fragment in appropriate L2 headers, then forwards | |||
| the resulting (L2-encapsulated) carrier packets to the FHS Proxy/ | the resulting (L2-encapsulated) carrier packets to the FHS Proxy/ | |||
| Server. | Server. | |||
| When the FHS Proxy/Server receives the carrier packets, it | When the FHS Proxy/Server receives the carrier packets, it | |||
| reassembles if necessary and verifies the authentication signature or | reassembles if necessary and verifies the authentication signature or | |||
| checksum. The FHS Proxy/Server then changes the OAL source address | checksum. The FHS Proxy/Server then changes the OAL source address | |||
| to its own RND-ULA, changes the destination to the RND-ULA or MNP-XLA | to its own ULA, changes the destination to the ULA or XLA | |||
| corresponding to the NA(AR) destination, includes an appropriate | corresponding to the NA(AR) destination, includes an appropriate | |||
| Identification, then fragments and forwards the carrier packets into | Identification, then fragments and forwards the carrier packets into | |||
| the secured spanning tree. | the secured spanning tree. | |||
| Note: If the Hub Proxy/Server is acting as the Client's ROR but not | Note: If the Hub Proxy/Server is acting as the Client's ROR but not | |||
| as a Relay/IP router (i.e., by virtue of receipt of an RS message | as a Relay/IP router (i.e., by virtue of receipt of an RS message | |||
| with the A flag set), it prepares the NS(AR) with the R flag set to 0 | with the A flag set), it prepares the NS(AR) with the R flag set to 0 | |||
| but without setting the SYN flag in the OMNI Neighbor Coordination | but without setting the SYN flag in the OMNI Neighbor Coordination | |||
| header window synchronization parameters. This informs the ROS that | header window synchronization parameters. This informs the ROS that | |||
| it must initiate multilink route optimization to synchronize with the | it must initiate multilink route optimization to synchronize with the | |||
| skipping to change at page 61, line 11 ¶ | skipping to change at page 61, line 11 ¶ | |||
| may traverse multiple OMNI link segments. The final-hop Gateway will | may traverse multiple OMNI link segments. The final-hop Gateway will | |||
| deliver the carrier packet via the secured spanning tree to a Proxy/ | deliver the carrier packet via the secured spanning tree to a Proxy/ | |||
| Server for the ROS. | Server for the ROS. | |||
| 3.13.1.4. Processing the NA(AR) | 3.13.1.4. Processing the NA(AR) | |||
| When the ROS receives the NA(AR) message, it first searches for a NCE | When the ROS receives the NA(AR) message, it first searches for a NCE | |||
| that matches the NA(AR) target address. The ROS then processes the | that matches the NA(AR) target address. The ROS then processes the | |||
| message the same as for standard IPv6 Address Resolution [RFC4861]. | message the same as for standard IPv6 Address Resolution [RFC4861]. | |||
| In the process, it caches all OMNI option information in the target | In the process, it caches all OMNI option information in the target | |||
| NCE (including all Interface Attributes), and caches the NA(AR) MNP- | NCE (including all Interface Attributes), and caches the NA(AR) XLA | |||
| XLA source address as the address of the target Client. | source address as the address of the target Client. | |||
| When the ROS is a Client, the SRT secured spanning tree will first | When the ROS is a Client, the SRT secured spanning tree will first | |||
| deliver the solicited NA(AR) message to the FHS Proxy/Server, which | deliver the solicited NA(AR) message to the FHS Proxy/Server, which | |||
| re-encapsulates and forwards the message to the Client. If the | re-encapsulates and forwards the message to the Client. If the | |||
| Client is on a well-managed ANET, physical security and protected | Client is on a well-managed ANET, physical security and protected | |||
| spectrum ensures security for the NA(AR) without needing an | spectrum ensures security for the NA(AR) without needing an | |||
| additional authentication signature; if the Client is on the open | additional authentication signature; if the Client is on the open | |||
| INET the Proxy/Server must instead include an authentication | INET the Proxy/Server must instead include an authentication | |||
| signature (while adjusting the OMNI option size, if necessary). The | signature (while adjusting the OMNI option size, if necessary). The | |||
| Proxy/Server uses its own RND-ULA as the OAL source and the MNP-ULA | Proxy/Server uses its own ULA as the OAL source and the ULA-MNP of | |||
| of the Client as the OAL destination. | the Client as the OAL destination. | |||
| 3.13.2. Multilink Route Optimization | 3.13.2. Multilink Route Optimization | |||
| Following address resolution, the ROS and ROR can assert multilink | Following address resolution, the ROS and ROR can assert multilink | |||
| paths through underlay interface pairs serviced by the same source/ | paths through underlay interface pairs serviced by the same source/ | |||
| destination ULAs by sending unicast NS/NA messages with Multilink | destination ULAs by sending unicast NS/NA messages with Multilink | |||
| Forwarding Parameters and OMNI Neighbor Coordination window | Forwarding Parameters and OMNI Neighbor Coordination window | |||
| synchronization parameters when necessary. The unicast NS/NA | synchronization parameters when necessary. The unicast NS/NA | |||
| messages establish multilink forwarding state in intermediate nodes | messages establish multilink forwarding state in intermediate nodes | |||
| in the path between the ROS and ROR. | in the path between the ROS and ROR. | |||
| skipping to change at page 63, line 23 ¶ | skipping to change at page 63, line 23 ¶ | |||
| with Job code '00' that originated from an FHS OAL source. B2 | with Job code '00' that originated from an FHS OAL source. B2 | |||
| values MUST NOT be tested for uniqueness within the OAL node's | values MUST NOT be tested for uniqueness within the OAL node's | |||
| local context. | local context. | |||
| When an FHS OAL source has an original IP packet to send to an LHS | When an FHS OAL source has an original IP packet to send to an LHS | |||
| OAL destination discovered via multilink address resolution, it first | OAL destination discovered via multilink address resolution, it first | |||
| selects a source and target underlay interface pair. The OAL source | selects a source and target underlay interface pair. The OAL source | |||
| uses its cached information for the target underlay interface as LHS | uses its cached information for the target underlay interface as LHS | |||
| information then prepares an NS message with an OMNI Multilink | information then prepares an NS message with an OMNI Multilink | |||
| Forwarding Parameters sub-option with Job code '00' and with source | Forwarding Parameters sub-option with Job code '00' and with source | |||
| set to its own RND-ULA or MNP-XLA. If the LHS FMT-Forward and FMT- | set to its own ULA or XLA. If the LHS FMT-Forward and FMT-Mode bits | |||
| Mode bits are both clear, the OAL source sets the destination to the | are both clear, the OAL source sets the destination to the ULA of the | |||
| RND-ULA of the LHS Proxy/Server; otherwise, it sets the destination | LHS Proxy/Server; otherwise, it sets the destination to the XLA of | |||
| to the MNP-XLA of the target Client. The OAL source then sets window | the target Client. The OAL source then sets window synchronization | |||
| synchronization information in the OMNI Neighbor Coordination header | information in the OMNI Neighbor Coordination header and creates a | |||
| and creates a NCE for the selected destination RND-ULA or MNP-XLA in | NCE for the selected destination ULA or XLA in the INCOMPLETE state. | |||
| the INCOMPLETE state. The OAL source next creates an MFV based on | The OAL source next creates an MFV based on the NS source and | |||
| the NS source and destination ULAs, then generates a "B1" MFVI and | destination ULAs, then generates a "B1" MFVI and assigns it to the | |||
| assigns it to the MFV while also including it as the first B entry in | MFV while also including it as the first B entry in the MFVI List. | |||
| the MFVI List. The OAL source then populates the NS Multilink | The OAL source then populates the NS Multilink Forwarding Parameters | |||
| Forwarding Parameters based on any FHS/LHS information it knows | based on any FHS/LHS information it knows locally. OAL intermediate | |||
| locally. OAL intermediate nodes on the path to the OAL destination | nodes on the path to the OAL destination may populate additional FHS/ | |||
| may populate additional FHS/LHS information on a hop-by-hop basis. | LHS information on a hop-by-hop basis. | |||
| If the OAL source is the FHS Proxy/Server, it then performs OAL | If the OAL source is the FHS Proxy/Server, it then performs OAL | |||
| encapsulation/fragmentation while setting the source to its own RND- | encapsulation/fragmentation while setting the source to its own ULA | |||
| ULA and setting the destination to the FHS Subnet Router Anycast ULA | and setting the destination to the FHS Subnet Router Anycast ULA | |||
| determined by applying the FHS SRT prefix length to its RND-ULA. The | determined by applying the FHS SRT prefix length to its ULA. The FHS | |||
| FHS Proxy/Server next examines the LHS FMT code. If FMT-Forward is | Proxy/Server next examines the LHS FMT code. If FMT-Forward is clear | |||
| clear and FMT-Mode is set, the FHS Proxy/Server checks for a NCE for | and FMT-Mode is set, the FHS Proxy/Server checks for a NCE for the | |||
| the RND-ULA of the LHS Proxy/Server. If there is no NCE, the FHS | ULA of the LHS Proxy/Server. If there is no NCE, the FHS Proxy/ | |||
| Proxy/Server creates one in the INCOMPLETE state. If a new NCE was | Server creates one in the INCOMPLETE state. If a new NCE was created | |||
| created (or if the existing NCE requires fresh window | (or if the existing NCE requires fresh window synchronization), the | |||
| synchronization), the FHS Proxy/Server then writes window | FHS Proxy/Server then writes window synchronization parameters into | |||
| synchronization parameters into the OMNI Multilink Forwarding | the OMNI Multilink Forwarding Parameters Tunnel Window | |||
| Parameters Tunnel Window Synchronization fields. The FHS Proxy/ | Synchronization fields. The FHS Proxy/Server then selects an | |||
| Server then selects an appropriate Identification value and L2 | appropriate Identification value and L2 headers and forwards the | |||
| headers and forwards the resulting carrier packets into the secured | resulting carrier packets into the secured spanning tree which will | |||
| spanning tree which will deliver them to a Gateway interface that | deliver them to a Gateway interface that assigns the FHS Subnet | |||
| assigns the FHS Subnet Router Anycast ULA. | Router Anycast ULA. | |||
| If the OAL source is the FHS Client, it instead includes an | If the OAL source is the FHS Client, it instead includes an | |||
| authentication signature if necessary, performs OAL encapsulation, | authentication signature if necessary, performs OAL encapsulation, | |||
| sets the source to its own MNP-ULA, sets the destination to the RND- | sets the source to its own ULA-MNP, sets the destination to the ULA | |||
| ULA of the FHS Proxy/Server and selects an appropriate Identification | of the FHS Proxy/Server and selects an appropriate Identification | |||
| value for the FHS Proxy/Server. If FHS FMT-Forward is set and LHS | value for the FHS Proxy/Server. If FHS FMT-Forward is set and LHS | |||
| FMT-Forward is clear, the FHS Client creates/updates a NCE for the | FMT-Forward is clear, the FHS Client creates/updates a NCE for the | |||
| RND-ULA of the LHS Proxy/Server as above and includes Tunnel Window | ULA of the LHS Proxy/Server as above and includes Tunnel Window | |||
| Synchronization parameters. The FHS Client then fragments and | Synchronization parameters. The FHS Client then fragments and | |||
| encapsulates in appropriate L2 headers then forwards the carrier | encapsulates in appropriate L2 headers then forwards the carrier | |||
| packets to the FHS Proxy/Server. When the FHS Proxy/Server receives | packets to the FHS Proxy/Server. When the FHS Proxy/Server receives | |||
| the carrier packets, it verifies the Identification, reassembles/ | the carrier packets, it verifies the Identification, reassembles/ | |||
| decapsulates to obtain the NS then verifies the authentication | decapsulates to obtain the NS then verifies the authentication | |||
| signature or checksum. The FHS Proxy/Server then creates an MFV | signature or checksum. The FHS Proxy/Server then creates an MFV | |||
| (i.e., the same as the FHS Client had done) while assigning the | (i.e., the same as the FHS Client had done) while assigning the | |||
| current B entry in the MFVI List (i.e., the one included by the FHS | current B entry in the MFVI List (i.e., the one included by the FHS | |||
| Client) as the "B2" MFVI for this MVF. The FHS Proxy/Server next | Client) as the "B2" MFVI for this MVF. The FHS Proxy/Server next | |||
| generates a new unique "B1" MFVI, then both assigns it to the MFV and | generates a new unique "B1" MFVI, then both assigns it to the MFV and | |||
| writes it as the next B entry in the OMNI Multilink Forwarding | writes it as the next B entry in the OMNI Multilink Forwarding | |||
| Parameters MFVI List (while also writing any FHS Client and Proxy/ | Parameters MFVI List (while also writing any FHS Client and Proxy/ | |||
| Server addressing information). The FHS Proxy/Server then checks | Server addressing information). The FHS Proxy/Server then checks | |||
| FHS/LHS FMT-Forward/Mode to determine whether to create a NCE for the | FHS/LHS FMT-Forward/Mode to determine whether to create a NCE for the | |||
| LHS Proxy/Server RND-ULA and include Tunnel Window Synchronization | LHS Proxy/Server ULA and include Tunnel Window Synchronization | |||
| parameters the same as above. The FHS Proxy/Server then calculates | parameters the same as above. The FHS Proxy/Server then calculates | |||
| the checksum, re-fragments while setting the OAL source address to | the checksum, re-fragments while setting the OAL source address to | |||
| its own RND-ULA and destination address to the FHS Subnet Router | its own ULA and destination address to the FHS Subnet Router Anycast | |||
| Anycast ULA, and includes an Identification appropriate for the | ULA, and includes an Identification appropriate for the secured | |||
| secured spanning tree. The FHS Proxy/Server finally includes | spanning tree. The FHS Proxy/Server finally includes appropriate L2 | |||
| appropriate L2 headers and forwards the carrier packets into the | headers and forwards the carrier packets into the secured spanning | |||
| secured spanning tree the same as above. | tree the same as above. | |||
| Gateways in the spanning tree forward carrier packets not explicitly | Gateways in the spanning tree forward carrier packets not explicitly | |||
| addressed to themselves, while forwarding those that arrived via the | addressed to themselves, while forwarding those that arrived via the | |||
| secured spanning tree to the next hop also via the secured spanning | secured spanning tree to the next hop also via the secured spanning | |||
| tree and forwarding all others via the unsecured spanning tree. When | tree and forwarding all others via the unsecured spanning tree. When | |||
| an FHS Gateway receives a carrier packet over the secured spanning | an FHS Gateway receives a carrier packet over the secured spanning | |||
| tree addressed to its RND-ULA or the FHS Subnet Router Anycast ULA, | tree addressed to its ULA or the FHS Subnet Router Anycast ULA, it | |||
| it instead reassembles/decapsulates to obtain the NS then verifies | instead reassembles/decapsulates to obtain the NS then verifies the | |||
| the checksum. The FHS Gateway next creates an MFV (i.e., the same as | checksum. The FHS Gateway next creates an MFV (i.e., the same as the | |||
| the FHS Proxy/Server had done) while assigning the current B entry in | FHS Proxy/Server had done) while assigning the current B entry in the | |||
| the MFVI List as the MFV "B2" index. The FHS Gateway also caches the | MFVI List as the MFV "B2" index. The FHS Gateway also caches the NS | |||
| NS Multilink Forwarding Parameters FHS information in the MFV, and | Multilink Forwarding Parameters FHS information in the MFV, and also | |||
| also caches the first B entry in the MFVI List as "FHS-Client" when | caches the first B entry in the MFVI List as "FHS-Client" when FHS | |||
| FHS FMT-Forward/Mode are both set to enable future direct forwarding | FMT-Forward/Mode are both set to enable future direct forwarding to | |||
| to this FHS Client. The FHS Gateway then generates a "B1" MFVI for | this FHS Client. The FHS Gateway then generates a "B1" MFVI for the | |||
| the MFV and also writes it as the next B entry in the NS's MFVI List. | MFV and also writes it as the next B entry in the NS's MFVI List. | |||
| The FHS Gateway then examines the SRT prefixes corresponding to both | The FHS Gateway then examines the SRT prefixes corresponding to both | |||
| FHS and LHS. If the FHS Gateway has a local interface connection to | FHS and LHS. If the FHS Gateway has a local interface connection to | |||
| both the FHS and LHS (whether they are the same or different | both the FHS and LHS (whether they are the same or different | |||
| segments), the FHS/LHS Gateway caches the NS LHS information, writes | segments), the FHS/LHS Gateway caches the NS LHS information, writes | |||
| its RND-ULA suffix and LHS INADDR into the NS OMNI Multilink | its ULA suffix and LHS INADDR into the NS OMNI Multilink Forwarding | |||
| Forwarding Parameters LHS fields, then sets its own RND-ULA as the | Parameters LHS fields, then sets its own ULA as the source and the | |||
| source and the RND-ULA of the LHS Proxy/Server as the destination | ULA of the LHS Proxy/Server as the destination while selecting an | |||
| while selecting an appropriate identification. If the FHS and LHS | appropriate identification. If the FHS and LHS prefixes are | |||
| prefixes are different, the FHS Gateway instead sets the LHS Subnet | different, the FHS Gateway instead sets the LHS Subnet Router Anycast | |||
| Router Anycast ULA as the destination. The FHS Gateway then | ULA as the destination. The FHS Gateway then recalculates the NS | |||
| recalculates the NS checksum, selects an appropriate Identification | checksum, selects an appropriate Identification and L2 headers as | |||
| and L2 headers as above then forwards the carrier packets into the | above then forwards the carrier packets into the secured spanning | |||
| secured spanning tree. | tree. | |||
| When the FHS and LHS Gateways are different, the LHS Gateway will | When the FHS and LHS Gateways are different, the LHS Gateway will | |||
| receive carrier packets over the secured spanning tree from the FHS | receive carrier packets over the secured spanning tree from the FHS | |||
| Gateway. The LHS Gateway reassembles/decapsulates to obtain the NS | Gateway. The LHS Gateway reassembles/decapsulates to obtain the NS | |||
| then verifies the checksum and creates an MFV (i.e., the same as the | then verifies the checksum and creates an MFV (i.e., the same as the | |||
| FHS Gateway had done) while assigning the current B entry in the MFVI | FHS Gateway had done) while assigning the current B entry in the MFVI | |||
| List as the MFV "B2" index. The LHS Gateway also caches the RND-ULA | List as the MFV "B2" index. The LHS Gateway also caches the ULA of | |||
| of the FHS Gateway found in the Multilink Forwarding Parameters as | the FHS Gateway found in the Multilink Forwarding Parameters as the | |||
| the spanning tree address for "B2", caches the NS Multilink | spanning tree address for "B2", caches the NS Multilink Forwarding | |||
| Forwarding Parameters LHS information then generates a "B1" MFVI for | Parameters LHS information then generates a "B1" MFVI for the MFV | |||
| the MFV while also writing it as the next B entry in the MFVI List. | while also writing it as the next B entry in the MFVI List. The LHS | |||
| The LHS Gateway also writes its own RND-ULA suffix and LHS INADDR | Gateway also writes its own ULA suffix and LHS INADDR into the OMNI | |||
| into the OMNI Multilink Forwarding Parameters. The LHS Gateway then | Multilink Forwarding Parameters. The LHS Gateway then sets the its | |||
| sets the its own RND-ULA as the source and the RND-ULA of the LHS | own ULA as the source and the ULA of the LHS Proxy/Server as the OAL | |||
| Proxy/Server as the OAL destination, recalculates the checksum, | destination, recalculates the checksum, selects an appropriate | |||
| selects an appropriate Identification, then fragments while including | Identification, then fragments while including appropriate L2 headers | |||
| appropriate L2 headers and forwards the carrier packets into the | and forwards the carrier packets into the secured spanning tree. | |||
| secured spanning tree. | ||||
| When the LHS Proxy/Server receives the carrier packets from the | When the LHS Proxy/Server receives the carrier packets from the | |||
| secured spanning tree, it reassembles/decapsulates to obtain the NS, | secured spanning tree, it reassembles/decapsulates to obtain the NS, | |||
| verifies the checksum then verifies that the LHS information supplied | verifies the checksum then verifies that the LHS information supplied | |||
| by the FHS source is consistent with its own cached information. If | by the FHS source is consistent with its own cached information. If | |||
| the information is consistent, the LHS Proxy/Server then creates an | the information is consistent, the LHS Proxy/Server then creates an | |||
| MFV and assigns the current B entry in the MFVI List as the "B2" MFVI | MFV and assigns the current B entry in the MFVI List as the "B2" MFVI | |||
| the same as for the prior hop. If the NS destination is the MNP-XLA | the same as for the prior hop. If the NS destination is the XLA of | |||
| of the target Client, the LHS Proxy/Server also generates a "B1" MFVI | the target Client, the LHS Proxy/Server also generates a "B1" MFVI | |||
| and assigns it both to the MFVI and as the next B entry in the MFVI | and assigns it both to the MFVI and as the next B entry in the MFVI | |||
| List. The LHS Proxy/Server then examines FHS FMT; if FMT-Forward is | List. The LHS Proxy/Server then examines FHS FMT; if FMT-Forward is | |||
| clear and FMT-Mode is set, the LHS Proxy/Server creates a NCE for the | clear and FMT-Mode is set, the LHS Proxy/Server creates a NCE for the | |||
| RND-ULA of the FHS Proxy/Server (if necessary) and sets the state to | ULA of the FHS Proxy/Server (if necessary) and sets the state to | |||
| STALE, then caches any Tunnel Window Synchronization parameters. | STALE, then caches any Tunnel Window Synchronization parameters. | |||
| If the NS destination is its own RND-ULA, the LHS Proxy/Server next | If the NS destination is its own ULA, the LHS Proxy/Server next | |||
| prepares to return a solicited NA with Job code '01'. If the NS | prepares to return a solicited NA with Job code '01'. If the NS | |||
| source was the MNP-XLA of the FHS Client, the LHS Proxy/Server first | source was the XLA of the FHS Client, the LHS Proxy/Server first | |||
| creates or updates an NCE for the MNP-XLA with state set to STALE. | creates or updates an NCE for the XLA with state set to STALE. The | |||
| The LHS Proxy/Server next caches the NS OMNI Neighbor Coordination | LHS Proxy/Server next caches the NS OMNI Neighbor Coordination header | |||
| header window synchronization parameters and Multilink Forwarding | window synchronization parameters and Multilink Forwarding Parameters | |||
| Parameters information (including the MFVI List) in the NCE | information (including the MFVI List) in the NCE corresponding to the | |||
| corresponding to the ULA source. When the LHS Proxy/Server forwards | ULA source. When the LHS Proxy/Server forwards future carrier | |||
| future carrier packets based on the NCE, it can populate reverse-path | packets based on the NCE, it can populate reverse-path forwarding | |||
| forwarding information in a CRH-32 routing header to enable | information in a CRH-32 routing header to enable forwarding based on | |||
| forwarding based on the cached MFVI List B entries instead of ULA | the cached MFVI List B entries instead of ULA addresses. | |||
| addresses. | ||||
| The LHS Proxy/Server then creates an NA with Job code '01' while | The LHS Proxy/Server then creates an NA with Job code '01' while | |||
| copying the NS OMNI Multilink Forwarding Parameters FHS/LHS | copying the NS OMNI Multilink Forwarding Parameters FHS/LHS | |||
| information into the corresponding fields in the NA. The LHS Proxy/ | information into the corresponding fields in the NA. The LHS Proxy/ | |||
| Server then generates an "A1" MFVI and both assigns it to the MFV and | Server then generates an "A1" MFVI and both assigns it to the MFV and | |||
| includes it as the first A entry in NA's MFVI List (see: | includes it as the first A entry in NA's MFVI List (see: | |||
| [I-D.templin-6man-omni] for details on MFVI List A/B processing). | [I-D.templin-6man-omni] for details on MFVI List A/B processing). | |||
| The LHS Proxy/Server then includes end-to-end window synchronization | The LHS Proxy/Server then includes end-to-end window synchronization | |||
| parameters in the OMNI Neighbor Coordination header (if necessary) | parameters in the OMNI Neighbor Coordination header (if necessary) | |||
| and also tunnel window synchronization parameters in the Multilink | and also tunnel window synchronization parameters in the Multilink | |||
| Forwarding Parameters (if necessary). The LHS Proxy/Server then | Forwarding Parameters (if necessary). The LHS Proxy/Server then | |||
| encapsulates the NA, calculates the checksum, sets the source to its | encapsulates the NA, calculates the checksum, sets the source to its | |||
| own RND-ULA, sets the destination to the RND-ULA of the LHS Gateway, | own ULA, sets the destination to the ULA of the LHS Gateway, selects | |||
| selects an appropriate Identification value and L2 headers then | an appropriate Identification value and L2 headers then forwards the | |||
| forwards the carrier packets into the secured spanning tree. | carrier packets into the secured spanning tree. | |||
| If the NS destination was the MNP-XLA of the LHS Client, the LHS | If the NS destination was the XLA of the LHS Client, the LHS Proxy/ | |||
| Proxy/Server instead includes an authentication signature in the NS | Server instead includes an authentication signature in the NS if | |||
| if necessary (otherwise recalculates the checksum), then changes the | necessary (otherwise recalculates the checksum), then changes the OAL | |||
| OAL source to its own RND-ULA and changes the destination to the MNP- | source to its own ULA and changes the destination to the ULA-MNP of | |||
| ULA of the LHS Client. The LHS Proxy/Server then selects an | the LHS Client. The LHS Proxy/Server then selects an appropriate | |||
| appropriate Identification value, fragments if necessary, includes | Identification value, fragments if necessary, includes appropriate L2 | |||
| appropriate L2 headers and forwards the carrier packets to the LHS | headers and forwards the carrier packets to the LHS Client. When the | |||
| Client. When the LHS Client receives the carrier packets, it | LHS Client receives the carrier packets, it verifies the | |||
| verifies the Identification and reassembles/decapsulates to obtain | Identification and reassembles/decapsulates to obtain the NS then | |||
| the NS then verifies the authentication signature or checksum. The | verifies the authentication signature or checksum. The LHS Client | |||
| LHS Client then creates a NCE for the NS ULA source address in the | then creates a NCE for the NS ULA source address in the STALE state. | |||
| STALE state. If LHS FMT-Forward is set, FHS FMT-Forward is clear and | If LHS FMT-Forward is set, FHS FMT-Forward is clear and the NS source | |||
| the NS source was an MNP-XLA, the Client also creates a NCE for the | was an XLA, the Client also creates a NCE for the ULA of the FHS | |||
| RND-ULA of the FHS Proxy/Server in the STALE state and caches any | Proxy/Server in the STALE state and caches any Tunnel Window | |||
| Tunnel Window Synchronization parameters. The Client then caches the | Synchronization parameters. The Client then caches the NS OMNI | |||
| NS OMNI Neighbor Coordination header window synchronization | Neighbor Coordination header window synchronization parameters and | |||
| parameters and Multilink Forwarding Parameters in the NCE | Multilink Forwarding Parameters in the NCE corresponding to the NS | |||
| corresponding to the NS ULA source, then creates an MFV and assigns | ULA source, then creates an MFV and assigns both the current MFVI | |||
| both the current MFVI List B entry as "B2" and a locally generated | List B entry as "B2" and a locally generated "A1" MFVI the same as | |||
| "A1" MFVI the same as for previous hops (the LHS Client also includes | for previous hops (the LHS Client also includes the "A1" value in the | |||
| the "A1" value in the solicited NA - see above and below). The LHS | solicited NA - see above and below). The LHS Client also caches the | |||
| Client also caches the previous MFVI List B entry as "LHS-Gateway" | previous MFVI List B entry as "LHS-Gateway" since it can include this | |||
| since it can include this value when it sends future carrier packets | value when it sends future carrier packets directly to the Gateway | |||
| directly to the Gateway (following appropriate neighbor | (following appropriate neighbor coordination). | |||
| coordination). | ||||
| The LHS Client then prepares an NA using exactly the same procedures | The LHS Client then prepares an NA using exactly the same procedures | |||
| as for the LHS Proxy/Server above, except that it uses its MNP-XLA as | as for the LHS Proxy/Server above, except that it uses its XLA as the | |||
| the source and the RND-ULA or MNP-XLA of the FHS correspondent as the | source and the ULA or XLA of the FHS correspondent as the | |||
| destination. The LHS Client also includes an authentication | destination. The LHS Client also includes an authentication | |||
| signature if necessary (otherwise calculates the checksum), then | signature if necessary (otherwise calculates the checksum), then | |||
| encapsulates the NA with OAL source set to its own MNP-ULA and | encapsulates the NA with OAL source set to its own ULA-MNP and | |||
| destination set to the RND-ULA of the LHS Proxy/Server, includes an | destination set to the ULA of the LHS Proxy/Server, includes an | |||
| appropriate Identification and L2 headers and forwards the carrier | appropriate Identification and L2 headers and forwards the carrier | |||
| packets to the LHS Proxy/Server. When the LHS Proxy/Server receives | packets to the LHS Proxy/Server. When the LHS Proxy/Server receives | |||
| the carrier packets, it verifies the Identifications, reassembles/ | the carrier packets, it verifies the Identifications, reassembles/ | |||
| decapsulates to obtain the NA, verifies the authentication signature | decapsulates to obtain the NA, verifies the authentication signature | |||
| or checksum, then uses the current MVFI List B entry to locate the | or checksum, then uses the current MVFI List B entry to locate the | |||
| MFV. The LHS Proxy/Server then writes the current MFVI List A entry | MFV. The LHS Proxy/Server then writes the current MFVI List A entry | |||
| as the "A2" value for the MVF, generates an "A1" MFVI and both | as the "A2" value for the MVF, generates an "A1" MFVI and both | |||
| assigns it to the MFV and writes it as the next MFVI List A entry. | assigns it to the MFV and writes it as the next MFVI List A entry. | |||
| The LHS Proxy/Server then examines the FHS/LHS FMT codes to determine | The LHS Proxy/Server then examines the FHS/LHS FMT codes to determine | |||
| if it needs to include Tunnel Window Synchronization parameters. The | if it needs to include Tunnel Window Synchronization parameters. The | |||
| LHS Proxy/Server then recalculates the checksum, re-fragments the NA | LHS Proxy/Server then recalculates the checksum, re-fragments the NA | |||
| while setting the OAL source to its own RND-ULA and destination to | while setting the OAL source to its own ULA and destination to the | |||
| the RND-ULA of the LHS Gateway, includes an appropriate | ULA of the LHS Gateway, includes an appropriate Identification and L2 | |||
| Identification and L2 headers and forwards the carrier packets into | headers and forwards the carrier packets into the secured spanning | |||
| the secured spanning tree. | tree. | |||
| When the LHS Gateway receives the carrier packets, it reassembles/ | When the LHS Gateway receives the carrier packets, it reassembles/ | |||
| decapsulates to obtain the NA while verifying the checksum then uses | decapsulates to obtain the NA while verifying the checksum then uses | |||
| the current MFVI List B entry to locate the MFV. The LHS Gateway | the current MFVI List B entry to locate the MFV. The LHS Gateway | |||
| then writes the current MFVI List A entry as the MFV "A2" index and | then writes the current MFVI List A entry as the MFV "A2" index and | |||
| generates a new "A1" value which it both assigns the MFV and writes | generates a new "A1" value which it both assigns the MFV and writes | |||
| as the next MFVI List A entry. (The LHS Gateway also caches the | as the next MFVI List A entry. (The LHS Gateway also caches the | |||
| first A entry in the MFVI List as "LHS-Client" when LHS FMT-Forward/ | first A entry in the MFVI List as "LHS-Client" when LHS FMT-Forward/ | |||
| Mode are both set to enable future direct forwarding to this LHS | Mode are both set to enable future direct forwarding to this LHS | |||
| Client.) If the LHS Gateway is connected directly to both the FHS | Client.) If the LHS Gateway is connected directly to both the FHS | |||
| and LHS segments (whether the segments are the same or different), | and LHS segments (whether the segments are the same or different), | |||
| the FHS/LHS Gateway will have already cached the FHS/LHS information | the FHS/LHS Gateway will have already cached the FHS/LHS information | |||
| based on the original NS. The FHS/LHS Gateway recalculates the | based on the original NS. The FHS/LHS Gateway recalculates the | |||
| checksum then re-fragments the NA while setting the OAL source to its | checksum then re-fragments the NA while setting the OAL source to its | |||
| own RND-ULA and destination to the RND-ULA of the FHS Proxy/Server. | own ULA and destination to the ULA of the FHS Proxy/Server. If the | |||
| If the FHS and LHS prefixes are different, the FHS Gateway instead | FHS and LHS prefixes are different, the FHS Gateway instead re- | |||
| re-fragments while setting the destination to the RND-ULA of the FHS | fragments while setting the destination to the ULA of the FHS | |||
| Gateway. The LHS Gateway selects an appropriate Identification and | Gateway. The LHS Gateway selects an appropriate Identification and | |||
| L2 headers then forwards the carrier packets into the secured | L2 headers then forwards the carrier packets into the secured | |||
| spanning tree. | spanning tree. | |||
| When the FHS and LHS Gateways are different, the FHS Gateway will | When the FHS and LHS Gateways are different, the FHS Gateway will | |||
| receive the carrier packets from the LHS Gateway over the secured | receive the carrier packets from the LHS Gateway over the secured | |||
| spanning tree. The FHS Gateway reassembles/decapsulates to obtain | spanning tree. The FHS Gateway reassembles/decapsulates to obtain | |||
| the NA while verifying the checksum, then locates the MFV based on | the NA while verifying the checksum, then locates the MFV based on | |||
| the current MFVI List B entry. The FHS Gateway then assigns the | the current MFVI List B entry. The FHS Gateway then assigns the | |||
| current MFVI List A entry as the MFV "A2" index and caches the RND- | current MFVI List A entry as the MFV "A2" index and caches the ULA of | |||
| ULA of the LHS Gateway as the spanning tree address for "A2". The | the LHS Gateway as the spanning tree address for "A2". The FHS | |||
| FHS Gateway then generates an "A1" MVFI and both assigns it to the | Gateway then generates an "A1" MVFI and both assigns it to the MVF | |||
| MVF and writes it as the next MFVI List A entry while also writing | and writes it as the next MFVI List A entry while also writing its | |||
| its RND-ULA and INADDR in the NA FHS Gateway fields. The FHS Gateway | ULA and INADDR in the NA FHS Gateway fields. The FHS Gateway then | |||
| then recalculates the checksum, re-encapsulates/re-fragments with its | recalculates the checksum, re-encapsulates/re-fragments with its own | |||
| own RND-ULA as the source, with the RND-ULA of the FHS Proxy/Server | ULA as the source, with the ULA of the FHS Proxy/Server as the | |||
| as the destination, then selects an appropriate Identification value | destination, then selects an appropriate Identification value and L2 | |||
| and L2 headers and forwards the carrier packets into the secured | headers and forwards the carrier packets into the secured spanning | |||
| spanning tree. | tree. | |||
| When the FHS Proxy/Server receives the carrier packets from the | When the FHS Proxy/Server receives the carrier packets from the | |||
| secured spanning tree, it reassembles/decapsulates to obtain the NA | secured spanning tree, it reassembles/decapsulates to obtain the NA | |||
| while verifying the checksum then locates the MFV based on the | while verifying the checksum then locates the MFV based on the | |||
| current MFVI List B entry. The FHS Proxy/Server then assigns the | current MFVI List B entry. The FHS Proxy/Server then assigns the | |||
| current MFVI List A entry as the "A2" MFVI the same as for the prior | current MFVI List A entry as the "A2" MFVI the same as for the prior | |||
| hop. If the NA destination is its own RND-ULA, the FHS Proxy/Server | hop. If the NA destination is its own ULA, the FHS Proxy/Server then | |||
| then caches the NA Multilink Forwarding Parameters with the MFV and | caches the NA Multilink Forwarding Parameters with the MFV and | |||
| examines LHS FMT. If FMT-Forward is clear, the FHS Proxy/Server | examines LHS FMT. If FMT-Forward is clear, the FHS Proxy/Server | |||
| locates the NCE for the RND-ULA of the LHS Proxy/Server and sets the | locates the NCE for the ULA of the LHS Proxy/Server and sets the | |||
| state to REACHABLE then caches any Tunnel Window Synchronization | state to REACHABLE then caches any Tunnel Window Synchronization | |||
| parameters. If the NA source is the MNP-XLA of the LHS Client, the | parameters. If the NA source is the XLA of the LHS Client, the FHS | |||
| FHS Proxy/Server then locates the LHS Client NCE and sets the state | Proxy/Server then locates the LHS Client NCE and sets the state to | |||
| to REACHABLE then caches the OMNI Neighbor Coordination header window | REACHABLE then caches the OMNI Neighbor Coordination header window | |||
| synchronization parameters and prepares to return an NA | synchronization parameters and prepares to return an NA | |||
| acknowledgement, if necessary. | acknowledgement, if necessary. | |||
| If the NA destination is the MNP-XLA of the FHS Client, the FHS | If the NA destination is the XLA of the FHS Client, the FHS Proxy/ | |||
| Proxy/Server also searches for and updates the NCE for the RND-ULA of | Server also searches for and updates the NCE for the ULA of the LHS | |||
| the LHS Proxy/Server if necessary the same as above. The FHS Proxy/ | Proxy/Server if necessary the same as above. The FHS Proxy/Server | |||
| Server then generates an "A1" MFVI and assigns it both to the MFVI | then generates an "A1" MFVI and assigns it both to the MFVI and as | |||
| and as the next MFVI List A entry, then includes an authentication | the next MFVI List A entry, then includes an authentication signature | |||
| signature or checksum in the NA message. The FHS Proxy/Server then | or checksum in the NA message. The FHS Proxy/Server then sets the | |||
| sets the OAL source to its own RND-ULA and sets the destination to | OAL source to its own ULA and sets the destination to the ULA-MNP of | |||
| the MNP-ULA of the FHS Client, then selects an appropriate | the FHS Client, then selects an appropriate Identification value and | |||
| Identification value and L2headers and forwards the carrier packets | L2 headers and forwards the carrier packets to the FHS Client. | |||
| to the FHS Client. | ||||
| When the FHS Client receives the carrier packets, it verifies the | When the FHS Client receives the carrier packets, it verifies the | |||
| Identification, reassembles/decapsulates to obtain the NA, verifies | Identification, reassembles/decapsulates to obtain the NA, verifies | |||
| the authentication signature or checksum, then locates the MFV based | the authentication signature or checksum, then locates the MFV based | |||
| on the current MFVI List B entry. The FHS Client then assigns the | on the current MFVI List B entry. The FHS Client then assigns the | |||
| current MFVI List A entry as the "A2" MFVI the same as for the prior | current MFVI List A entry as the "A2" MFVI the same as for the prior | |||
| hop. The FHS Client then caches the NA Multilink Forwarding | hop. The FHS Client then caches the NA Multilink Forwarding | |||
| Parameters (including the MFVI List) with the MFV and examines LHS | Parameters (including the MFVI List) with the MFV and examines LHS | |||
| FMT. If FMT-Forward is clear, the FHS Client locates the NCE for the | FMT. If FMT-Forward is clear, the FHS Client locates the NCE for the | |||
| RND-ULA of the LHS Proxy/Server and sets the state to REACHABLE then | ULA of the LHS Proxy/Server and sets the state to REACHABLE then | |||
| caches any Tunnel Window Synchronization parameters. If the NA | caches any Tunnel Window Synchronization parameters. If the NA | |||
| source is the MNP-XLA of the LHS Client, the FHS Proxy/Server then | source is the XLA of the LHS Client, the FHS Proxy/Server then | |||
| locates the LHS Client NCE and sets the state to REACHABLE then | locates the LHS Client NCE and sets the state to REACHABLE then | |||
| caches the OMNI Neighbor Coordination header window synchronization | caches the OMNI Neighbor Coordination header window synchronization | |||
| parameters and prepares to return an NA acknowledgement, if | parameters and prepares to return an NA acknowledgement, if | |||
| necessary. The FHS Client also caches the previous MFVI List A entry | necessary. The FHS Client also caches the previous MFVI List A entry | |||
| as "FHS-Gateway" since it can include this value when it sends future | as "FHS-Gateway" since it can include this value when it sends future | |||
| carrier packets directly to the Gateway (following appropriate | carrier packets directly to the Gateway (following appropriate | |||
| neighbor coordination). | neighbor coordination). | |||
| If either the FHS Client or FHS Proxy/Server needs to return an | If either the FHS Client or FHS Proxy/Server needs to return an | |||
| acknowledgement to complete window synchronization, it prepares a uNA | acknowledgement to complete window synchronization, it prepares a uNA | |||
| message with an OMNI Multilink Forwarding Parameters sub-option with | message with an OMNI Multilink Forwarding Parameters sub-option with | |||
| Job code set to '10' (Follow A; Record B) (note that this step is | Job code set to '10' (Follow A; Record B) (note that this step is | |||
| unnecessary when Rapid Commit route optimization is used per | unnecessary when Rapid Commit route optimization is used per | |||
| Section 3.13.3). The FHS node sets the source to its own RND-ULA or | Section 3.13.3). The FHS node sets the source to its own ULA or XLA, | |||
| MNP-XLA, sets the destination to the RND-ULA or MNP-XLA of the LHS | sets the destination to the ULA or XLA of the LHS node then includes | |||
| node then includes Tunnel Window Synchronization parameters if | Tunnel Window Synchronization parameters if necessary. The FHS node | |||
| necessary. The FHS node next sets the MFVI List to the cached list | next sets the MFVI List to the cached list of A entries received in | |||
| of A entries received in the Job code '01' NA, but need not set any | the Job code '01' NA, but need not set any other FHS/LHS information. | |||
| other FHS/LHS information. The FHS node then encapsulates the uNA | The FHS node then encapsulates the uNA message in an OAL header with | |||
| message in an OAL header with its own {ADM,MNP}-ULA as the source. | its own ULA as the source. If the FHS node is the Client, it next | |||
| If the FHS node is the Client, it next sets the RND-ULA of the FHS | sets the ULA of the FHS Proxy/Server as the OAL destination, includes | |||
| Proxy/Server as the OAL destination, includes an authentication | an authentication signature or checksum, selects an appropriate | |||
| signature or checksum, selects an appropriate Identification value | Identification value and L2 headers and forwards the carrier packets | |||
| and L2 headers and forwards the carrier packets to the FHS Proxy/ | to the FHS Proxy/Server. The FHS Proxy/Server then verifies the | |||
| Server. The FHS Proxy/Server then verifies the Identification, | Identification, reassembles/decapsulates, verifies the authentication | |||
| reassembles/decapsulates, verifies the authentication signature or | signature or checksum, then uses the current MFVI List A entry to | |||
| checksum, then uses the current MFVI List A entry to locate the MFV. | locate the MFV. The FHS Proxy/Server then writes its "B1" MFVI as | |||
| The FHS Proxy/Server then writes its "B1" MFVI as the next MFVI List | the next MFVI List B entry and determines whether it needs to include | |||
| B entry and determines whether it needs to include Tunnel Window | Tunnel Window Synchronization parameters the same as it had done when | |||
| Synchronization parameters the same as it had done when it forwarded | it forwarded the original NS. | |||
| the original NS. | ||||
| The FHS Proxy/Server recalculates the uNA checksum then re-fragments | The FHS Proxy/Server recalculates the uNA checksum then re-fragments | |||
| while setting its own RND-ULA as the source and the RND-ULA of the | while setting its own ULA as the source and the ULA of the FHS | |||
| FHS Gateway as the destination, then selects an appropriate | Gateway as the destination, then selects an appropriate | |||
| Identification and L2 headers and forwards the carrier packets into | Identification and L2 headers and forwards the carrier packets into | |||
| the secured spanning tree. When the FHS Gateway receives the carrier | the secured spanning tree. When the FHS Gateway receives the carrier | |||
| packets, it reassembles/decapsulates to obtain the uNA while | packets, it reassembles/decapsulates to obtain the uNA while | |||
| verifying the checksum then uses the current MFVI List A entry to | verifying the checksum then uses the current MFVI List A entry to | |||
| locate the MFV. The FHS Gateway then writes its "B1" MFVI as the | locate the MFV. The FHS Gateway then writes its "B1" MFVI as the | |||
| next MFVI List B entry, then re-fragments while setting the OAL | next MFVI List B entry, then re-fragments while setting the OAL | |||
| source and destination. If the FHS Gateway is also the LHS Gateway, | source and destination. If the FHS Gateway is also the LHS Gateway, | |||
| it sets the RND-ULA of the LHS Proxy/Server as the destination; | it sets the ULA of the LHS Proxy/Server as the destination; otherwise | |||
| otherwise it sets the RND-ULA of the LHS Gateway. The FHS Gateway | it sets the ULA of the LHS Gateway. The FHS Gateway recalculates the | |||
| recalculates the checksum then selects an appropriate Identification | checksum then selects an appropriate Identification and L2 headers, | |||
| and L2 headers, re-fragments/forwards the carrier packets into the | re-fragments/forwards the carrier packets into the secured spanning | |||
| secured spanning tree. If an LHS Gateway receives the carrier | tree. If an LHS Gateway receives the carrier packets, it processes | |||
| packets, it processes them exactly the same as the FHS Gateway had | them exactly the same as the FHS Gateway had done while setting the | |||
| done while setting the carrier packet destination to the RND-ULA of | carrier packet destination to the ULA of the LHS Proxy/Server. | |||
| the LHS Proxy/Server. | ||||
| When the LHS Proxy/Server receives the carrier packets, it | When the LHS Proxy/Server receives the carrier packets, it | |||
| reassembles/decapsulates to obtain the uNA message while verifying | reassembles/decapsulates to obtain the uNA message while verifying | |||
| the checksum. The LHS Proxy/Server then locates the MFV based on the | the checksum. The LHS Proxy/Server then locates the MFV based on the | |||
| current MFVI List A entry then determines whether it is a tunnel | current MFVI List A entry then determines whether it is a tunnel | |||
| ingress the same as for the original NS. If it is a tunnel ingress, | ingress the same as for the original NS. If it is a tunnel ingress, | |||
| the LHS Proxy/Server updates the NCE for the tunnel far-end based on | the LHS Proxy/Server updates the NCE for the tunnel far-end based on | |||
| the Tunnel Window Synchronization parameters. If the uNA destination | the Tunnel Window Synchronization parameters. If the uNA destination | |||
| is its own RND-ULA, the LHS Proxy/Server next updates the NCE for the | is its own ULA, the LHS Proxy/Server next updates the NCE for the | |||
| source ULA based on the OMNI Neighbor Coordination header window | source ULA based on the OMNI Neighbor Coordination header window | |||
| synchronization parameters and MAY compare the MVFI List to the | synchronization parameters and MAY compare the MVFI List to the | |||
| version it had cached in the MFV based on the original NS. | version it had cached in the MFV based on the original NS. | |||
| If the uNA destination is the MNP-XLA of the LHS Client, the LHS | If the uNA destination is the XLA of the LHS Client, the LHS Proxy/ | |||
| Proxy/Server instead writes its "B1" MFV as the next MFVI List B | Server instead writes its "B1" MFV as the next MFVI List B entry, | |||
| entry, includes an authentication signature or checksum, writes its | includes an authentication signature or checksum, writes its own ULA | |||
| own RND-ULA as the OAL source and the MNP-ULA of the Client as the | as the OAL source and the ULA-MNP of the Client as the OAL | |||
| OAL destination then selects an appropriate Identification and L2 | destination then selects an appropriate Identification and L2 headers | |||
| headers and forwards the resulting carrier packets to the LHS Client. | and forwards the resulting carrier packets to the LHS Client. When | |||
| When the LHS Client receives the carrier packets, it verifies the | the LHS Client receives the carrier packets, it verifies the | |||
| Identification, reassembles/decapsulates to obtain the uNA, verifies | Identification, reassembles/decapsulates to obtain the uNA, verifies | |||
| the authentication signature or checksum then processes the message | the authentication signature or checksum then processes the message | |||
| exactly the same as for the LHS Proxy/Server case above. | exactly the same as for the LHS Proxy/Server case above. | |||
| Following the NS/NA exchange with Multilink Forwarding Parameters, | Following the NS/NA exchange with Multilink Forwarding Parameters, | |||
| OAL end systems and tunnel endpoints can begin exchanging ordinary | OAL end systems and tunnel endpoints can begin exchanging ordinary | |||
| carrier packets with Identification values within their respective | carrier packets with Identification values within their respective | |||
| send/receive windows without requiring security signatures and/or | send/receive windows without requiring security signatures and/or | |||
| secured spanning tree traversal. Either peer can refresh window | secured spanning tree traversal. Either peer can refresh window | |||
| synchronization parameters and/or send other carrier packets | synchronization parameters and/or send other carrier packets | |||
| skipping to change at page 71, line 46 ¶ | skipping to change at page 71, line 35 ¶ | |||
| while forwarding outbound secured carrier packets via the secured | while forwarding outbound secured carrier packets via the secured | |||
| spanning tree and forwarding inbound secured carrier packets while | spanning tree and forwarding inbound secured carrier packets while | |||
| including an authentication signature or checksum. For ordinary | including an authentication signature or checksum. For ordinary | |||
| carrier packets, the Proxy/Server uses the same MFV if directed by | carrier packets, the Proxy/Server uses the same MFV if directed by | |||
| MFVI and/or OAL addressing. Otherwise it locates an MFV established | MFVI and/or OAL addressing. Otherwise it locates an MFV established | |||
| through an NS/NA exchange between the Client and the remote peer, and | through an NS/NA exchange between the Client and the remote peer, and | |||
| forwards the carrier packets without first reassembling/ | forwards the carrier packets without first reassembling/ | |||
| decapsulating. | decapsulating. | |||
| When a Proxy/Server or Client configured as a tunnel ingress receives | When a Proxy/Server or Client configured as a tunnel ingress receives | |||
| a carrier packet with a full OAL header with an MNP-ULA source and | a carrier packet with a full OAL header with a ULA-MNP source and | |||
| CRH-32 routing header, or an OCH header with an MFVI that matches an | CRH-32 routing header, or an OCH header with an MFVI that matches an | |||
| MFV, the ingress encapsulates the carrier packet in a new full OAL | MFV, the ingress encapsulates the carrier packet in a new full OAL | |||
| header or an OCH header containing the next hop MVFI and an | header or an OCH header containing the next hop MVFI and an | |||
| Identification value appropriate for the end-to-end window and the | Identification value appropriate for the end-to-end window and the | |||
| outer header containing an Identification value appropriate for the | outer header containing an Identification value appropriate for the | |||
| tunnel endpoints. When a Proxy/Server or Client configured as a | tunnel endpoints. When a Proxy/Server or Client configured as a | |||
| tunnel egress receives an encapsulated carrier packet, it verifies | tunnel egress receives an encapsulated carrier packet, it verifies | |||
| the Identification in the outer header, then discards the outer | the Identification in the outer header, then discards the outer | |||
| header and forwards the inner carrier packet to the final | header and forwards the inner carrier packet to the final | |||
| destination. | destination. | |||
| skipping to change at page 74, line 19 ¶ | skipping to change at page 73, line 46 ¶ | |||
| handshake connection with minimal messaging and delay (i.e., as | handshake connection with minimal messaging and delay (i.e., as | |||
| opposed to a four-message exchange). | opposed to a four-message exchange). | |||
| 3.13.4. Client/Gateway Route Optimization | 3.13.4. Client/Gateway Route Optimization | |||
| Following multilink route optimization for specific underlay | Following multilink route optimization for specific underlay | |||
| interface pairs, ROS/ROR Clients located on open INETs can invoke | interface pairs, ROS/ROR Clients located on open INETs can invoke | |||
| Client/Gateway route optimization to improve performance and reduce | Client/Gateway route optimization to improve performance and reduce | |||
| load and congestion on their respective FHS/LHS Proxy/Servers. To | load and congestion on their respective FHS/LHS Proxy/Servers. To | |||
| initiate Client/Gateway route optimization, the Client prepares an NS | initiate Client/Gateway route optimization, the Client prepares an NS | |||
| message with its own MNP-XLA address as the source and the RND-ULA of | message with its own XLA address as the source and the ULA of its | |||
| its Gateway as the destination while creating a NCE for the Gateway | Gateway as the destination while creating a NCE for the Gateway if | |||
| if necessary. The NS message must be no larger than the minimum MPS | necessary. The NS message must be no larger than the minimum MPS and | |||
| and encapsulated as an atomic fragment. | encapsulated as an atomic fragment. | |||
| The Client then includes an Interface Attributes sub-option for its | The Client then includes an Interface Attributes sub-option for its | |||
| underlay interface as well as an authentication signature but does | underlay interface as well as an authentication signature but does | |||
| not include window synchronization parameters. The Client then | not include window synchronization parameters. The Client then | |||
| performs OAL encapsulation with its own MNP-ULA as the source and the | performs OAL encapsulation with its own ULA-MNP as the source and the | |||
| RND-ULA of the Gateway as the destination while including a randomly- | ULA of the Gateway as the destination while including a randomly- | |||
| chosen Identification value, then performs L2 encapsulation on the | chosen Identification value, then performs L2 encapsulation on the | |||
| atomic fragment and sends the resulting carrier packet directly to | atomic fragment and sends the resulting carrier packet directly to | |||
| the Gateway. | the Gateway. | |||
| When the Gateway receives the carrier packet, it verifies the | When the Gateway receives the carrier packet, it verifies the | |||
| authentication signature then creates a NCE for the Client. The | authentication signature then creates a NCE for the Client. The | |||
| Gateway then caches the L2 encapsulation addresses (which may have | Gateway then caches the L2 encapsulation addresses (which may have | |||
| been altered by one or more NATs on the path) as well as the | been altered by one or more NATs on the path) as well as the | |||
| Interface Attributes for this Client omIndex, and marks this Client | Interface Attributes for this Client omIndex, and marks this Client | |||
| underlay interface as "trusted". The Gateway then prepares an NA | underlay interface as "trusted". The Gateway then prepares an NA | |||
| reply with its own RND-ULA as the source and the MNP-XLA of the | reply with its own ULA as the source and the XLA of the Client as the | |||
| Client as the destination where the NA again must be no larger than | destination where the NA again must be no larger than the minimum | |||
| the minimum MPS. | MPS. | |||
| The Gateway then echoes the Client's Interface Attributes, includes | The Gateway then echoes the Client's Interface Attributes, includes | |||
| an Origin Indication with the Client's observed L2 addresses and | an Origin Indication with the Client's observed L2 addresses and | |||
| includes an authentication signature. The Gateway then performs OAL | includes an authentication signature. The Gateway then performs OAL | |||
| encapsulation with its own RND-ULA as the source and the MNP-ULA of | encapsulation with its own ULA as the source and the ULA-MNP of the | |||
| the Client as the destination while using the same Identification | Client as the destination while using the same Identification value | |||
| value that appeared in the NS, then performs L2 encapsulation on the | that appeared in the NS, then performs L2 encapsulation on the atomic | |||
| atomic fragment and sends the resulting carrier packet directly to | fragment and sends the resulting carrier packet directly to the | |||
| the Client. | Client. | |||
| When the Client receives the NA reply, it caches the carrier packet | When the Client receives the NA reply, it caches the carrier packet | |||
| L2 source address information as the Gateway target address via this | L2 source address information as the Gateway target address via this | |||
| underlay interface while marking the interface as "trusted". The | underlay interface while marking the interface as "trusted". The | |||
| Client also caches the Origin Indication L2 address information as | Client also caches the Origin Indication L2 address information as | |||
| its own (external) source address for this underlay interface. | its own (external) source address for this underlay interface. | |||
| After the Client and Gateway have established NCEs as well as | After the Client and Gateway have established NCEs as well as | |||
| "trusted" status for a particular underlay interface pair, each node | "trusted" status for a particular underlay interface pair, each node | |||
| can begin forwarding ordinary carrier packets intended for this | can begin forwarding ordinary carrier packets intended for this | |||
| skipping to change at page 75, line 43 ¶ | skipping to change at page 75, line 25 ¶ | |||
| the NCE may aggregate multiple underlay interface pairs. Each | the NCE may aggregate multiple underlay interface pairs. Each | |||
| underlay interface pair may use differing source and target L2 | underlay interface pair may use differing source and target L2 | |||
| addresses according to NAT mappings, and the "trusted/untrusted" | addresses according to NAT mappings, and the "trusted/untrusted" | |||
| status of each pair must be tested independently. When no "trusted" | status of each pair must be tested independently. When no "trusted" | |||
| pairs remain, the NCE is deleted. | pairs remain, the NCE is deleted. | |||
| Note that the above method requires Gateways to participate in NS/NA | Note that the above method requires Gateways to participate in NS/NA | |||
| message authentication signature application and verification. In an | message authentication signature application and verification. In an | |||
| alternate approach, the Client could instead exchange NS/NA messages | alternate approach, the Client could instead exchange NS/NA messages | |||
| with authentication signatures via its Proxy/Server but addressed to | with authentication signatures via its Proxy/Server but addressed to | |||
| the RND-ULA of the Gateway, and the Proxy/Server and Gateway could | the ULA of the Gateway, and the Proxy/Server and Gateway could relay | |||
| relay the messages over the secured spanning tree. However, this | the messages over the secured spanning tree. However, this would | |||
| would still require the Client to send additional messages toward the | still require the Client to send additional messages toward the L2 | |||
| L2 address of the Gateway to populate NAT state; hence the savings in | address of the Gateway to populate NAT state; hence the savings in | |||
| complexity for Gateways would result in increased message overhead | complexity for Gateways would result in increased message overhead | |||
| for Clients. | for Clients. | |||
| 3.13.5. Client/Client Route Optimization | 3.13.5. Client/Client Route Optimization | |||
| When the ROS/ROR Clients are both located on the same SRT segment, | When the ROS/ROR Clients are both located on the same SRT segment, | |||
| Client-to-Client route optimization is possible following the | Client-to-Client route optimization is possible following the | |||
| establishment of any necessary state in NATs in the path. Both | establishment of any necessary state in NATs in the path. Both | |||
| Clients will have already established state via their respective | Clients will have already established state via their respective | |||
| shared segment Proxy/Servers (and possibly also the shared segment | shared segment Proxy/Servers (and possibly also the shared segment | |||
| skipping to change at page 76, line 28 ¶ | skipping to change at page 76, line 9 ¶ | |||
| Forwarding Parameters) with the mapped addresses discovered during | Forwarding Parameters) with the mapped addresses discovered during | |||
| the RS/RA exchanges with their respective Proxy/Servers. After the | the RS/RA exchanges with their respective Proxy/Servers. After the | |||
| MFV paths have been established, both Clients can begin sending | MFV paths have been established, both Clients can begin sending | |||
| packets via strict MFV paths while establishing a direct path for | packets via strict MFV paths while establishing a direct path for | |||
| Client-to-Client route optimization. | Client-to-Client route optimization. | |||
| To establish the direct path, either Client (acting as the source) | To establish the direct path, either Client (acting as the source) | |||
| transmits a bubble to the mapped L2 address for the target Client | transmits a bubble to the mapped L2 address for the target Client | |||
| which primes its local chain of NATs for reception of future packets | which primes its local chain of NATs for reception of future packets | |||
| from that L2 address (see: [RFC4380] and [I-D.templin-6man-omni]). | from that L2 address (see: [RFC4380] and [I-D.templin-6man-omni]). | |||
| The source Client then prepares an NS message with its own MNP-XLA as | The source Client then prepares an NS message with its own XLA as the | |||
| the source, with the MNP-XLA of the target as the destination and | source, with the XLA of the target as the destination and with an | |||
| with an OMNI option with an Interface Attributes sub-option. The | OMNI option with an Interface Attributes sub-option. The source | |||
| source Client then encapsulates the NS in an OAL header with its own | Client then encapsulates the NS in an OAL header with its own ULA-MNP | |||
| MNP-ULA as the source, with the MNP-ULA of the target Client as the | as the source, with the ULA-MNP of the target Client as the | |||
| destination and with an in-window Identification for the target. The | destination and with an in-window Identification for the target. The | |||
| source Client then fragments and encapsulates in L2 headers addressed | source Client then fragments and encapsulates in L2 headers addressed | |||
| to its FHS Proxy/Server then forwards the resulting carrier packets | to its FHS Proxy/Server then forwards the resulting carrier packets | |||
| to the Proxy/Server. | to the Proxy/Server. | |||
| When the FHS Proxy/Server receives the carrier packets, it re- | When the FHS Proxy/Server receives the carrier packets, it re- | |||
| encapsulates and forwards them as unsecured carrier packets according | encapsulates and forwards them as unsecured carrier packets according | |||
| to MFV state where they will eventually arrive at the target Client | to MFV state where they will eventually arrive at the target Client | |||
| which can verify that the identifications are within the acceptable | which can verify that the identifications are within the acceptable | |||
| window and reassemble if necessary. Following reassembly, the target | window and reassemble if necessary. Following reassembly, the target | |||
| Client prepares an NA message with its own MNP-XLA as the source, | Client prepares an NA message with its own XLA as the source, with | |||
| with the MNP-XLA of the source Client as the destination and with an | the XLA of the source Client as the destination and with an OMNI | |||
| OMNI option with an Interface Attributes sub-option. The target | option with an Interface Attributes sub-option. The target Client | |||
| Client then encapsulates the NA in an OAL header with its own MNP-ULA | then encapsulates the NA in an OAL header with its own ULA-MNP as the | |||
| as the source, with the MNP-ULA of the source Client as the | source, with the ULA-MNP of the source Client as the destination and | |||
| destination and with an in-window Identification for the source | with an in-window Identification for the source Client. The target | |||
| Client. The target Client then fragments and encapsulates in L2 | Client then fragments and encapsulates in L2 headers addressed to the | |||
| headers addressed to the source Client's Origin addresses then | source Client's Origin addresses then forwards the resulting carrier | |||
| forwards the resulting carrier packets directly to the source Client. | packets directly to the source Client. | |||
| Following the initial NS/NA exchange, both Clients mark their | Following the initial NS/NA exchange, both Clients mark their | |||
| respective (source, target) underlay interface pairs as "trusted" for | respective (source, target) underlay interface pairs as "trusted" for | |||
| no more than ReachableTime seconds. While the Clients continue to | no more than ReachableTime seconds. While the Clients continue to | |||
| exchange carrier packets via the direct path avoiding all Proxy/ | exchange carrier packets via the direct path avoiding all Proxy/ | |||
| Servers and Gateways, they should perform additional NS/NA exchanges | Servers and Gateways, they should perform additional NS/NA exchanges | |||
| via their local Proxy/Servers to refresh NCE state as well as send | via their local Proxy/Servers to refresh NCE state as well as send | |||
| additional bubbles to the peer's Origin address information if | additional bubbles to the peer's Origin address information if | |||
| necessary to refresh NAT state. | necessary to refresh NAT state. | |||
| skipping to change at page 79, line 32 ¶ | skipping to change at page 79, line 13 ¶ | |||
| the SRT secured or unsecured spanning tree, or through NS(NUD) | the SRT secured or unsecured spanning tree, or through NS(NUD) | |||
| messages sent directly to an underlay interface of the target itself. | messages sent directly to an underlay interface of the target itself. | |||
| While testing a target underlay interface, the source can optionally | While testing a target underlay interface, the source can optionally | |||
| continue to forward carrier packets via alternate interfaces, | continue to forward carrier packets via alternate interfaces, | |||
| maintain a small queue of carrier packets until target reachability | maintain a small queue of carrier packets until target reachability | |||
| is confirmed or include them as trailing data with the NS(NUD) in an | is confirmed or include them as trailing data with the NS(NUD) in an | |||
| OAL super-packet [I-D.templin-6man-omni]. | OAL super-packet [I-D.templin-6man-omni]. | |||
| NS(NUD) messages are encapsulated, fragmented and transmitted as | NS(NUD) messages are encapsulated, fragmented and transmitted as | |||
| carrier packets the same as for ordinary original IP data packets, | carrier packets the same as for ordinary original IP data packets, | |||
| however the encapsulated destinations are either the RND-ULA or MNP- | however the encapsulated destinations are either the ULA or XLA of | |||
| XLA of the source and either the RND-ULA of the LHS Proxy/Server or | the source and either the ULA of the LHS Proxy/Server or the XLA of | |||
| the MNP-XLA of the target itself. The source encapsulates the | the target itself. The source encapsulates the NS(NUD) message the | |||
| NS(NUD) message the same as described in Section 3.13.2 and includes | same as described in Section 3.13.2 and includes an Interface | |||
| an Interface Attributes sub-option with omIndex set to identify its | Attributes sub-option with omIndex set to identify its underlay | |||
| underlay interface used for forwarding. The source then includes an | interface used for forwarding. The source then includes an in-window | |||
| in-window Identification, fragments the OAL packet and forwards the | Identification, fragments the OAL packet and forwards the resulting | |||
| resulting carrier packets into the unsecured spanning tree, directly | carrier packets into the unsecured spanning tree, directly to the | |||
| to the target if it is in the local segment or directly to a Gateway | target if it is in the local segment or directly to a Gateway in the | |||
| in the local segment. | local segment. | |||
| When the target receives the NS(NUD) carrier packets, it verifies | When the target receives the NS(NUD) carrier packets, it verifies | |||
| that it has a NCE for this source and that the Identification is in- | that it has a NCE for this source and that the Identification is in- | |||
| window, then submits the carrier packets for reassembly. The target | window, then submits the carrier packets for reassembly. The target | |||
| then verifies the authentication signature or checksum, then searches | then verifies the authentication signature or checksum, then searches | |||
| for Interface Attributes in its NCE for the source that match the | for Interface Attributes in its NCE for the source that match the | |||
| NS(NUD) for the NA(NUD) reply. The target then prepares the NA(NUD) | NS(NUD) for the NA(NUD) reply. The target then prepares the NA(NUD) | |||
| with the source and destination addresses reversed, encapsulates and | with the source and destination addresses reversed, encapsulates and | |||
| sets the OAL source and destination, includes an Interface Attributes | sets the OAL source and destination, includes an Interface Attributes | |||
| sub-option in the NA(NUD) to identify the omIndex of the underlay | sub-option in the NA(NUD) to identify the omIndex of the underlay | |||
| skipping to change at page 80, line 49 ¶ | skipping to change at page 80, line 36 ¶ | |||
| without consuming bandwidth on the Client underlay interface. | without consuming bandwidth on the Client underlay interface. | |||
| Mobility management considerations are specified in the following | Mobility management considerations are specified in the following | |||
| sections. | sections. | |||
| 3.15.1. Mobility Update Messaging | 3.15.1. Mobility Update Messaging | |||
| RORs and ROSs accommodate Client mobility and/or multilink change | RORs and ROSs accommodate Client mobility and/or multilink change | |||
| events by sending secured uNA messages to each active neighbor. When | events by sending secured uNA messages to each active neighbor. When | |||
| an ROR/ROS sends a uNA message, it sets the IPv6 source address to | an ROR/ROS sends a uNA message, it sets the IPv6 source address to | |||
| the its own RND-ULA or MNP-XLA, sets the destination address to the | the its own ULA or XLA, sets the destination address to the | |||
| neighbor's RND-ULA or MNP-XLA and sets the Target Address to the | neighbor's ULA or XLA and sets the Target Address to the Client's | |||
| Client's MNP-XLA. The ROR/ROS also includes an OMNI option with OMNI | XLA. The ROR/ROS also includes an OMNI option with OMNI Neighbor | |||
| Neighbor Coordination header Preflen set to the prefix length | Coordination header Preflen set to the prefix length associated with | |||
| associated with the Client's MNP-XLA, includes Interface Attributes | the Client's XLA, includes Interface Attributes and Traffic Selectors | |||
| and Traffic Selectors for the Client's underlay interfaces and | for the Client's underlay interfaces and includes an authentication | |||
| includes an authentication signature if necessary. The ROR then sets | signature if necessary. The ROR then sets the uNA R flag to 1, S | |||
| the uNA R flag to 1, S flag to 0 and O flag to 1, then encapsulates | flag to 0 and O flag to 1, then encapsulates the message in an OAL | |||
| the message in an OAL header with source set to its own ULA and | header with source set to its own ULA and destination set to its FHS | |||
| destination set to its FHS Proxy/Server's RND-ULA. When the FHS | Proxy/Server's ULA. When the FHS Proxy/Server receives the uNA, it | |||
| Proxy/Server receives the uNA, it reassembles, verifies the | reassembles, verifies the authentication signature, then changes the | |||
| authentication signature, then changes the destination to the ULA | destination to the ULA corresponding to the uNA destination and | |||
| corresponding to the uNA destination and forwards the uNA into the | forwards the uNA into the secured spanning tree. | |||
| secured spanning tree. | ||||
| As discussed in Section 7.2.6 of [RFC4861], the transmission and | As discussed in Section 7.2.6 of [RFC4861], the transmission and | |||
| reception of uNA messages is unreliable but provides a useful | reception of uNA messages is unreliable but provides a useful | |||
| optimization. In well-connected Internetworks with robust data links | optimization. In well-connected Internetworks with robust data links | |||
| uNA messages will be delivered with high probability, but in any case | uNA messages will be delivered with high probability, but in any case | |||
| the ROR/ROS can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT uNAs | the ROR/ROS can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT uNAs | |||
| to each neighbor to increase the likelihood that at least one will be | to each neighbor to increase the likelihood that at least one will be | |||
| received. Alternatively, the ROR/ROS can set the PNG flag in the uNA | received. Alternatively, the ROR/ROS can set the PNG flag in the uNA | |||
| OMNI option header to request a uNA acknowledgement as specified in | OMNI option header to request a uNA acknowledgement as specified in | |||
| [I-D.templin-6man-omni]. | [I-D.templin-6man-omni]. | |||
| When the ROR/ROS Proxy/Server receives a uNA message prepared as | When the ROR/ROS Proxy/Server receives a uNA message prepared as | |||
| above, if the uNA destination was its own RND-ULA the Proxy/Server | above, if the uNA destination was its own ULA the Proxy/Server uses | |||
| uses the included OMNI option information to update its NCE for the | the included OMNI option information to update its NCE for the target | |||
| target but does not reset ReachableTime since the receipt of a uNA | but does not reset ReachableTime since the receipt of a uNA message | |||
| message does not provide confirmation that any forward paths to the | does not provide confirmation that any forward paths to the target | |||
| target Client are working. If the destination was the MNP-XLA of the | Client are working. If the destination was the XLA of the ROR/ROS | |||
| ROR/ROS Client, the Proxy/Server instead changes the OAL source to | Client, the Proxy/Server instead changes the OAL source to its own | |||
| its own RND-ULA, includes an authentication signature if necessary, | ULA, includes an authentication signature if necessary, and includes | |||
| and includes an in-window Identification for this Client. Finally, | an in-window Identification for this Client. Finally, if the uNA | |||
| if the uNA message PNG flag was set, the node that processes the uNA | message PNG flag was set, the node that processes the uNA returns a | |||
| returns a uNA acknowledgement as specified in | uNA acknowledgement as specified in [I-D.templin-6man-omni]. | |||
| [I-D.templin-6man-omni]. | ||||
| 3.15.2. Announcing Link-Layer Information Changes | 3.15.2. Announcing Link-Layer Information Changes | |||
| When a Client needs to change its underlay Interface Attributes and/ | When a Client needs to change its underlay Interface Attributes and/ | |||
| or Traffic Selectors (e.g., due to a mobility event), the Client | or Traffic Selectors (e.g., due to a mobility event), the Client | |||
| sends an RS message to its Hub Proxy/Server via a first-hop FHS | sends an RS message to its Hub Proxy/Server via a first-hop FHS | |||
| Proxy/Server, if necessary. The RS includes an OMNI option with an | Proxy/Server, if necessary. The RS includes an OMNI option with an | |||
| Interface Attributes sub-option with the omIndex and with new link | Interface Attributes sub-option with the omIndex and with new link | |||
| quality and any other information. | quality and any other information. | |||
| skipping to change at page 83, line 13 ¶ | skipping to change at page 82, line 46 ¶ | |||
| neighbors. | neighbors. | |||
| 3.15.5. Moving Between Proxy/Servers | 3.15.5. Moving Between Proxy/Servers | |||
| The Client performs the procedures specified in Section 3.12.2 when | The Client performs the procedures specified in Section 3.12.2 when | |||
| it first associates with a new Hub Proxy/Server or renews its | it first associates with a new Hub Proxy/Server or renews its | |||
| association with an existing Hub Proxy/Server. | association with an existing Hub Proxy/Server. | |||
| When a Client associates with a new Hub Proxy/Server, it sends RS | When a Client associates with a new Hub Proxy/Server, it sends RS | |||
| messages to register its underlay interfaces with the new Hub while | messages to register its underlay interfaces with the new Hub while | |||
| including the old Hub's RND-ULA in the "Old Hub Proxy/Server ULA" | including the old Hub's ULA in the "Old Hub Proxy/Server ULA" field | |||
| field of a Proxy/Server Departure OMNI sub-option. When the new Hub | of a Proxy/Server Departure OMNI sub-option. When the new Hub Proxy/ | |||
| Proxy/Server returns the RA message via the FHS Proxy/Server (acting | Server returns the RA message via the FHS Proxy/Server (acting as a | |||
| as a Proxy), the FHS Proxy/Server sends a uNA to the old Hub Proxy/ | Proxy), the FHS Proxy/Server sends a uNA to the old Hub Proxy/Server | |||
| Server (i.e., if the ULA is non-zero and different from its own). | (i.e., if the ULA is non-zero and different from its own). The uNA | |||
| The uNA has the MNP-XLA of the Client as the source and the RND-ULA | has the XLA of the Client as the source and the ULA of the old hub as | |||
| of the old hub as the destination and with OMNI Neighbor Coordination | the destination and with OMNI Neighbor Coordination header Preflen | |||
| header Preflen set to 0. The FHS Proxy/Server encapsulates the uNA | set to 0. The FHS Proxy/Server encapsulates the uNA in an OAL header | |||
| in an OAL header with the RND-ULA of the new Hub as the source and | with the ULA of the new Hub as the source and the ULA of the old Hub | |||
| the RND-ULA of the old Hub as the destination, the fragments and | as the destination, the fragments and sends the carrier packets via | |||
| sends the carrier packets via the secured spanning tree. | the secured spanning tree. | |||
| When the old Hub Proxy/Server receives the uNA, it changes the | When the old Hub Proxy/Server receives the uNA, it changes the | |||
| Client's NCE state to DEPARTED, resets DepartTime and caches the new | Client's NCE state to DEPARTED, resets DepartTime and caches the new | |||
| Hub Proxy/Server RND-ULA. After a short delay (e.g., 2 seconds) the | Hub Proxy/Server ULA. After a short delay (e.g., 2 seconds) the old | |||
| old Hub Proxy/Server withdraws the Client's MNP from the routing | Hub Proxy/Server withdraws the Client's MNP from the routing system. | |||
| system. While in the DEPARTED state, the old Hub Proxy/Server | While in the DEPARTED state, the old Hub Proxy/Server forwards any | |||
| forwards any carrier packets received via the secured spanning tree | carrier packets received via the secured spanning tree destined to | |||
| destined to the Client's MNP-ULA to the new Hub Proxy/Server's RND- | the Client's ULA-MNP to the new Hub Proxy/Server's ULA. After | |||
| ULA. After DepartTime expires, the old Hub Proxy/Server deletes the | DepartTime expires, the old Hub Proxy/Server deletes the Client's | |||
| Client's NCE. | NCE. | |||
| Mobility events may also cause a Client to change to a new FHS Proxy/ | Mobility events may also cause a Client to change to a new FHS Proxy/ | |||
| Server over a specific underlay interface at any time such that a | Server over a specific underlay interface at any time such that a | |||
| Client RS/RA exchange over the underlay interface will engage the new | Client RS/RA exchange over the underlay interface will engage the new | |||
| FHS Proxy/Server instead of the old. The Client can arrange to | FHS Proxy/Server instead of the old. The Client can arrange to | |||
| inform the old FHS Proxy/Server of the departure by including a | inform the old FHS Proxy/Server of the departure by including a | |||
| Proxy/Server Departure sub-option with an RND-ULA for the "Old FHS | Proxy/Server Departure sub-option with a ULA for the "Old FHS Proxy/ | |||
| Proxy/Server ULA", and the new FHS Proxy/Server will issue a uNA | Server ULA", and the new FHS Proxy/Server will issue a uNA using the | |||
| using the same procedures as outlined for the Hub above while using | same procedures as outlined for the Hub above while using its own ULA | |||
| its own RND-ULA as the source address. This can often result in | as the source address. This can often result in successful delivery | |||
| successful delivery of packets that would otherwise be lost due to | of packets that would otherwise be lost due to the mobility event. | |||
| the mobility event. | ||||
| Clients SHOULD NOT move rapidly between Hub Proxy/Servers in order to | Clients SHOULD NOT move rapidly between Hub Proxy/Servers in order to | |||
| avoid causing excessive oscillations in the AERO routing system. | avoid causing excessive oscillations in the AERO routing system. | |||
| Examples of when a Client might wish to change to a different Hub | Examples of when a Client might wish to change to a different Hub | |||
| Proxy/Server include a Hub Proxy/Server that has gone unreachable, | Proxy/Server include a Hub Proxy/Server that has gone unreachable, | |||
| topological movements of significant distance, movement to a new | topological movements of significant distance, movement to a new | |||
| geographic region, movement to a new OMNI link segment, etc. | geographic region, movement to a new OMNI link segment, etc. | |||
| 3.16. Multicast | 3.16. Multicast | |||
| skipping to change at page 84, line 40 ¶ | skipping to change at page 84, line 24 ¶ | |||
| When an ROS "X" (i.e., either a Client or Proxy/Server) acting as PIM | When an ROS "X" (i.e., either a Client or Proxy/Server) acting as PIM | |||
| router receives a Join/Prune message from a node on its downstream | router receives a Join/Prune message from a node on its downstream | |||
| interfaces containing one or more ((S)ource, (G)roup) pairs, it | interfaces containing one or more ((S)ource, (G)roup) pairs, it | |||
| updates its Multicast Routing Information Base (MRIB) accordingly. | updates its Multicast Routing Information Base (MRIB) accordingly. | |||
| For each S belonging to a prefix reachable via X's non-OMNI | For each S belonging to a prefix reachable via X's non-OMNI | |||
| interfaces, X then forwards the (S, G) Join/Prune to any PIM routers | interfaces, X then forwards the (S, G) Join/Prune to any PIM routers | |||
| on those interfaces per [RFC7761]. | on those interfaces per [RFC7761]. | |||
| For each S belonging to a prefix reachable via X's OMNI interface, X | For each S belonging to a prefix reachable via X's OMNI interface, X | |||
| sends an NS(AR) message (see: Section 3.13) using its own RND-ULA or | sends an NS(AR) message (see: Section 3.13) using its own ULA or XLA | |||
| MNP-XLA as the source address, the solicited node multicast address | as the source address, the solicited node multicast address | |||
| corresponding to S as the destination and the MNP-XLA of S as the | corresponding to S as the destination and the XLA of S as the target | |||
| target address. X then encapsulates the NS(AR) in an OAL header with | address. X then encapsulates the NS(AR) in an OAL header with source | |||
| source address set to its own ULA and destination address set to the | address set to its own ULA and destination address set to the ULA for | |||
| ULA for S, then forwards the message into the secured spanning tree | S, then forwards the message into the secured spanning tree which | |||
| which delivers it to ROR "Y" that services S. The resulting NA(AR) | delivers it to ROR "Y" that services S. The resulting NA(AR) will | |||
| will return an OMNI option with Interface Attributes for any underlay | return an OMNI option with Interface Attributes for any underlay | |||
| interfaces that are currently servicing S. | interfaces that are currently servicing S. | |||
| When X processes the NA(AR) it selects one or more underlay | When X processes the NA(AR) it selects one or more underlay | |||
| interfaces for S and performs an NS/NA multilink route optimization | interfaces for S and performs an NS/NA multilink route optimization | |||
| exchange over the secured spanning tree while including a PIM Join/ | exchange over the secured spanning tree while including a PIM Join/ | |||
| Prune message for each multicast group of interest in the OMNI | Prune message for each multicast group of interest in the OMNI | |||
| option. If S is located behind any Proxys "Z"*, each Z* then updates | option. If S is located behind any Proxys "Z"*, each Z* then updates | |||
| its MRIB accordingly and maintains the MNP-XLA of X as the next hop | its MRIB accordingly and maintains the XLA of X as the next hop in | |||
| in the reverse path. Since Gateways forward messages not addressed | the reverse path. Since Gateways forward messages not addressed to | |||
| to themselves without examining them, this means that the (reverse) | themselves without examining them, this means that the (reverse) | |||
| multicast tree path is simply from each Z* (and/or S) to X with no | multicast tree path is simply from each Z* (and/or S) to X with no | |||
| other multicast-aware routers in the path. | other multicast-aware routers in the path. | |||
| Following the initial combined Join/Prune and NS/NA messaging, X | Following the initial combined Join/Prune and NS/NA messaging, X | |||
| maintains a NCE for each S the same as if X was sending unicast data | maintains a NCE for each S the same as if X was sending unicast data | |||
| traffic to S. In particular, X performs additional NS/NA exchanges | traffic to S. In particular, X performs additional NS/NA exchanges | |||
| to keep the NCE alive for up to t_periodic seconds [RFC7761]. If no | to keep the NCE alive for up to t_periodic seconds [RFC7761]. If no | |||
| new Joins are received within t_periodic seconds, X allows the NCE to | new Joins are received within t_periodic seconds, X allows the NCE to | |||
| expire. Finally, if X receives any additional Join/Prune messages | expire. Finally, if X receives any additional Join/Prune messages | |||
| for (S,G) it forwards the messages over the secured spanning tree. | for (S,G) it forwards the messages over the secured spanning tree. | |||
| Client C that holds an MNP for source S may later depart from a first | Client C that holds an MNP for source S may later depart from a first | |||
| Proxy/Server Z1 and/or connect via a new Proxy/Server Z2. In that | Proxy/Server Z1 and/or connect via a new Proxy/Server Z2. In that | |||
| case, Y sends a uNA message to X the same as specified for unicast | case, Y sends a uNA message to X the same as specified for unicast | |||
| mobility in Section 3.15. When X receives the uNA message, it | mobility in Section 3.15. When X receives the uNA message, it | |||
| updates its NCE for the MNP-XLA for source S and sends new Join | updates its NCE for the XLA for source S and sends new Join messages | |||
| messages in NS/NA exchanges addressed to the new target Client | in NS/NA exchanges addressed to the new target Client underlay | |||
| underlay interface connection for S. There is no requirement to send | interface connection for S. There is no requirement to send any | |||
| any Prune messages to old Proxy/Server Z1 since source S will no | Prune messages to old Proxy/Server Z1 since source S will no longer | |||
| longer source any multicast data traffic via Z1. Instead, the | source any multicast data traffic via Z1. Instead, the multicast | |||
| multicast state for (S,G) in Proxy/Server Z1 will soon expire since | state for (S,G) in Proxy/Server Z1 will soon expire since no new | |||
| no new Joins will arrive. | Joins will arrive. | |||
| 3.16.2. Any-Source Multicast (ASM) | 3.16.2. Any-Source Multicast (ASM) | |||
| When an ROS X acting as a PIM router receives Join/Prune messages | When an ROS X acting as a PIM router receives Join/Prune messages | |||
| from a node on its downstream interfaces containing one or more (*,G) | from a node on its downstream interfaces containing one or more (*,G) | |||
| pairs, it updates its Multicast Routing Information Base (MRIB) | pairs, it updates its Multicast Routing Information Base (MRIB) | |||
| accordingly. X first performs an NS/NA(AR) exchange to receive route | accordingly. X first performs an NS/NA(AR) exchange to receive route | |||
| optimization information for Rendezvous Point (RP) R for each G. X | optimization information for Rendezvous Point (RP) R for each G. X | |||
| then includes a copy of each Join/Prune message in the OMNI option of | then includes a copy of each Join/Prune message in the OMNI option of | |||
| an NS message with its own RND-ULA or MNP-XLA as the source address | an NS message with its own ULA or XLA as the source address and the | |||
| and the RND-ULA or MNP-XLA for R as the destination address, then | ULA or XLA for R as the destination address, then encapsulates the NS | |||
| encapsulates the NS message in an OAL header with its own ULA as the | message in an OAL header with its own ULA as the source and the ULA | |||
| source and the RND-ULA of R's Proxy/Server as the destination then | of R's Proxy/Server as the destination then sends the message into | |||
| sends the message into the secured spanning tree. | the secured spanning tree. | |||
| For each source S that sends multicast traffic to group G via R, | For each source S that sends multicast traffic to group G via R, | |||
| Client S* that aggregates S (or its Proxy/Server) encapsulates the | Client S* that aggregates S (or its Proxy/Server) encapsulates the | |||
| original IP packets in PIM Register messages, includes the PIM | original IP packets in PIM Register messages, includes the PIM | |||
| Register messages in the OMNI options of uNA messages, performs OAL | Register messages in the OMNI options of uNA messages, performs OAL | |||
| encapsulation and fragmentation then forwards the resulting carrier | encapsulation and fragmentation then forwards the resulting carrier | |||
| packets with Identification values within the receive window for | packets with Identification values within the receive window for | |||
| Client R* that aggregates R. Client R* may then elect to send a PIM | Client R* that aggregates R. Client R* may then elect to send a PIM | |||
| Join to S* in the OMNI option of a uNA over the secured spanning | Join to S* in the OMNI option of a uNA over the secured spanning | |||
| tree. This will result in an (S,G) tree rooted at S* with R as the | tree. This will result in an (S,G) tree rooted at S* with R as the | |||
| skipping to change at page 89, line 12 ¶ | skipping to change at page 88, line 39 ¶ | |||
| sacrifice a modicum of efficiency in order to have time-varying MNPs | sacrifice a modicum of efficiency in order to have time-varying MNPs | |||
| that can be changed every so often to defeat adversarial tracking. | that can be changed every so often to defeat adversarial tracking. | |||
| The DHCPv6 service offers a way for Clients that desire time-varying | The DHCPv6 service offers a way for Clients that desire time-varying | |||
| MNPs to obtain short-lived prefixes (e.g., on the order of a small | MNPs to obtain short-lived prefixes (e.g., on the order of a small | |||
| number of minutes). In that case, the identity of the Client would | number of minutes). In that case, the identity of the Client would | |||
| not be bound to the MNP but rather to a Node Identification value | not be bound to the MNP but rather to a Node Identification value | |||
| (see: [I-D.templin-6man-omni]) to be used as the Client ID seed for | (see: [I-D.templin-6man-omni]) to be used as the Client ID seed for | |||
| MNP prefix delegation. The Client would then be obligated to | MNP prefix delegation. The Client would then be obligated to | |||
| renumber its internal networks whenever its MNP (and therefore also | renumber its internal networks whenever its MNP (and therefore also | |||
| its MNP-XLA) changes. This should not present a challenge for | its XLA) changes. This should not present a challenge for Clients | |||
| Clients with automated network renumbering services, however presents | with automated network renumbering services, however presents limits | |||
| limits for the durations of ongoing sessions that would prefer to use | for the durations of ongoing sessions that would prefer to use a | |||
| a constant address. | constant address. | |||
| 4. Implementation Status | 4. Implementation Status | |||
| An early AERO implementation based on OpenVPN (https://openvpn.net/) | An early AERO implementation based on OpenVPN (https://openvpn.net/) | |||
| was announced on the v6ops mailing list on January 10, 2018 and an | was announced on the v6ops mailing list on January 10, 2018 and an | |||
| initial public release of the AERO proof-of-concept source code was | initial public release of the AERO proof-of-concept source code was | |||
| announced on the intarea mailing list on August 21, 2015. | announced on the intarea mailing list on August 21, 2015. | |||
| Many AERO/OMNI functions are implemented and undergoing final | Many AERO/OMNI functions are implemented and undergoing final | |||
| integration. OAL fragmentation/reassembly buffer management code has | integration. OAL fragmentation/reassembly buffer management code has | |||
| skipping to change at page 94, line 8 ¶ | skipping to change at page 93, line 45 ¶ | |||
| This work is aligned with the Boeing Information Technology (BIT) | This work is aligned with the Boeing Information Technology (BIT) | |||
| MobileNet program. | MobileNet program. | |||
| 8. References | 8. References | |||
| 8.1. Normative References | 8.1. Normative References | |||
| [I-D.templin-6man-omni] | [I-D.templin-6man-omni] | |||
| Templin, F. L., "Transmission of IP Packets over Overlay | Templin, F. L., "Transmission of IP Packets over Overlay | |||
| Multilink Network (OMNI) Interfaces", Work in Progress, | Multilink Network (OMNI) Interfaces", Work in Progress, | |||
| Internet-Draft, draft-templin-6man-omni-57, 9 April 2022, | Internet-Draft, draft-templin-6man-omni-60, 22 April 2022, | |||
| <https://www.ietf.org/archive/id/draft-templin-6man-omni- | <https://www.ietf.org/archive/id/draft-templin-6man-omni- | |||
| 57.txt>. | 60.txt>. | |||
| [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
| [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
| RFC 792, DOI 10.17487/RFC0792, September 1981, | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc792>. | <https://www.rfc-editor.org/info/rfc792>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| skipping to change at page 96, line 46 ¶ | skipping to change at page 96, line 32 ¶ | |||
| 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.ietf-rtgwg-atn-bgp] | [I-D.ietf-rtgwg-atn-bgp] | |||
| Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. | Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. | |||
| Moreno, "A Simple BGP-based Mobile Routing System for the | Moreno, "A Simple BGP-based Mobile Routing System for the | |||
| Aeronautical Telecommunications Network", Work in | Aeronautical Telecommunications Network", Work in | |||
| Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-16, 7 | Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-17, 19 | |||
| April 2022, <https://www.ietf.org/archive/id/draft-ietf- | April 2022, <https://www.ietf.org/archive/id/draft-ietf- | |||
| rtgwg-atn-bgp-16.txt>. | rtgwg-atn-bgp-17.txt>. | |||
| [I-D.templin-6man-dhcpv6-ndopt] | [I-D.templin-6man-dhcpv6-ndopt] | |||
| Templin, F. L., "A Unified Stateful/Stateless | Templin, F. L., "A Unified Stateful/Stateless | |||
| Configuration Service for IPv6", Work in Progress, | Configuration Service for IPv6", Work in Progress, | |||
| Internet-Draft, draft-templin-6man-dhcpv6-ndopt-11, 1 | Internet-Draft, draft-templin-6man-dhcpv6-ndopt-11, 1 | |||
| January 2021, <https://www.ietf.org/archive/id/draft- | January 2021, <https://www.ietf.org/archive/id/draft- | |||
| templin-6man-dhcpv6-ndopt-11.txt>. | templin-6man-dhcpv6-ndopt-11.txt>. | |||
| [I-D.templin-intarea-seal] | [I-D.templin-intarea-seal] | |||
| Templin, F. L., "The Subnetwork Encapsulation and | Templin, F. L., "The Subnetwork Encapsulation and | |||
| skipping to change at page 98, line 13 ¶ | skipping to change at page 97, line 49 ¶ | |||
| [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. | [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. | |||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", | [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", | |||
| RFC 1812, DOI 10.17487/RFC1812, June 1995, | RFC 1812, DOI 10.17487/RFC1812, June 1995, | |||
| <https://www.rfc-editor.org/info/rfc1812>. | <https://www.rfc-editor.org/info/rfc1812>. | |||
| [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. | ||||
| J., and E. Lear, "Address Allocation for Private | ||||
| Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, | ||||
| February 1996, <https://www.rfc-editor.org/info/rfc1918>. | ||||
| [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, | [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, | |||
| DOI 10.17487/RFC2003, October 1996, | DOI 10.17487/RFC2003, October 1996, | |||
| <https://www.rfc-editor.org/info/rfc2003>. | <https://www.rfc-editor.org/info/rfc2003>. | |||
| [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, | [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, | |||
| DOI 10.17487/RFC2004, October 1996, | DOI 10.17487/RFC2004, October 1996, | |||
| <https://www.rfc-editor.org/info/rfc2004>. | <https://www.rfc-editor.org/info/rfc2004>. | |||
| [RFC2236] Fenner, W., "Internet Group Management Protocol, Version | [RFC2236] Fenner, W., "Internet Group Management Protocol, Version | |||
| 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, | 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, | |||
| skipping to change at page 107, line 35 ¶ | skipping to change at page 107, line 35 ¶ | |||
| Extended Virtual Synchrony or Paxos. Such an arrangement has | Extended Virtual Synchrony or Paxos. Such an arrangement has | |||
| precedence in common Internet service deployments in lightweight | precedence in common Internet service deployments in lightweight | |||
| virtual machines without requiring expensive hardware deployment. | virtual machines without requiring expensive hardware deployment. | |||
| Similarly, common Internet service deployments set service IP | Similarly, common Internet service deployments set service IP | |||
| addresses on service distribution points that may relay requests to | addresses on service distribution points that may relay requests to | |||
| many different servers. | many different servers. | |||
| For AERO, the expectation is that a combination of the Google/IETF | For AERO, the expectation is that a combination of the Google/IETF | |||
| and Yahoo/Amazon philosophies would be employed. The AERO Client | and Yahoo/Amazon philosophies would be employed. The AERO Client | |||
| connects to different ANET access points and can receive 1-2 Proxy/ | connects to different ANET access points and can receive 1-2 Proxy/ | |||
| Server RND-ULAs at each point. It then selects one AERO Proxy/Server | Server ULAs at each point. It then selects one AERO Proxy/Server | |||
| address, and engages in RS/RA exchanges with the same Proxy/Server | address, and engages in RS/RA exchanges with the same Proxy/Server | |||
| from all ANET connections. The Client remains with this Proxy/Server | from all ANET connections. The Client remains with this Proxy/Server | |||
| unless or until the Proxy/Server fails, in which case it can switch | unless or until the Proxy/Server fails, in which case it can switch | |||
| over to an alternate Proxy/Server. The Client can likewise switch | over to an alternate Proxy/Server. The Client can likewise switch | |||
| over to a different Proxy/Server at any time if there is some reason | over to a different Proxy/Server at any time if there is some reason | |||
| for it to do so. So, the AERO expectation is for a balance of | for it to do so. So, the AERO expectation is for a balance of | |||
| function in the network and end system, with fault tolerance and | function in the network and end system, with fault tolerance and | |||
| resilience at both levels. | resilience at both levels. | |||
| Appendix B. Change Log | Appendix B. Change Log | |||
| End of changes. 157 change blocks. | ||||
| 633 lines changed or deleted | 630 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/ | ||||