6MAN E. Levy-Abegnoli Internet-Draft P. Thubert Intended status: Informational Cisco Systems Expires: 22 December 2023 20 June 2023 IPv6 Neighbor Discovery Routing Proxy draft-levy-abegnoli-6man-stateless-nd-proxy-00 Abstract A legacy or incorrect host implementation may assume an on-link prefix on an interface where it owns an address that matches the prefix. This mistake may prevent connectivity on networks where this is not the case, e.g., when the physical or logical connectivity of the network does not allow transitive connectivity, in which case all the traffic should transit via the router. This document proposes a stateless routing proxy operation in the router to force a "not-on- link" behavior on the misbehaving host and attract all the packets to the router. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 December 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 1] Internet-Draft IPv6 ND Routing Proxy June 2023 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Section 5.2 of "IPv6 Neighbor Discovery (ND)" [RFC4861] describes a conceptual sending algorithm for the host stack, which operation differs whether a destination is on-link or off-link, affecting the selection of the next hop to which to forward a packet. In the former case, the host lookups the address up over the link, whereas in the latter, the host simply forwards to the default router. While on-link determination is explicitly specified through a variety of criteria, there is no signaling for off-link and a prefix that not known as being on-link may still be on-link or off-link, so the host behavior is not clearly defined. In particular, a router on the link can refrain from announcing that a prefix is on-link, but it has no authoritative way to declare that the prefix is off-link, and whether to adopt an off-link or an on-link behavior by default is left to the host decision and stack implementation. This is problematic in the case of non-broacast multi-access (NBMA) links that was accepted to be left "for further study" at the time of [RFC4861]. "Architecture and Framework for IPv6 over Non-Broadcast Access" [I-D.ietf-6man-ipv6-over-wireless] presents a number of NBMA situations, including wireless access and meshes, Low-Power Lossy Networks, and multi-site overlays, where the physical or logical characteristics of the subnet mandates an off-link behavior by the hosts, even when the destination is in the same subnet as the sender. In these cases, a host that fails to adopt the off-link behavior is likely to attempt link-layer address resolution and fail to forward traffic via a router. Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 2] Internet-Draft IPv6 ND Routing Proxy June 2023 [RFC4943] provides historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in [RFC4861], in particular in the case whether the host is not aware of a default router. On that basis, [RFC5942] clarifies the relationship between subnet and link and update [RFC4861] to make off-link behavior the default and mandate on-link behavior to be driven by explicit means. However, legacy or non-complient stack implementations may continue to this day to assume that a prefix is on-link by default, leading to connectivity failures. This document proposes a stateless ND routing-proxy operation (see section 4.1 of [I-D.ietf-6man-ipv6-over-wireless]) as a stateless variation of the ND routing-proxy function defined in section 2.2 of [RFC8929]. enabling the router to obtain an off-link behavior from such stacks, by forcing hosts that attempt a link-layer address resolution by default to forward all their traffic to their default router. The routing proxy function is co-located with the Router, listens to ND messages sent on the link and, when appropriate, responds with NA announcing self as the owner of the address to attract the traffic. 2. Acronyms This document uses the following abbreviations: DAD: Duplicate address Detection LLN: Low-Power and Lossy Network LLA: link-local address MAC: Medium Access Control MLSN: Multi-link Subnet MLD: multicast Listener Discovery NA: Neighbor Advertisement (message) NBMA: Non-Broadcast Multi-Access NCE: Neighbor Cache Entry ND: Neighbor Discovery (protocol) NDP: Neighbor Discovery Protocol NUD: Neighbor Unreachability Detection NS: Neighbor Solicitation (message) P2P: Point-to-Point P2MP: Point-to-Multipoint RA: Router Advertisement (message) RS: Router Solicitation (message) ULP: Upper-Layer Protocol VLAN: Virtual Local Area Network VxLAN: Virtual Extensible LAN WAN: Wide Area Network WLAN: Wireless Local Area Network WPAN: Wireless Personal Area Network Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 3] Internet-Draft IPv6 ND Routing Proxy June 2023 3. Operations Assuming that two hosts sharing a common prefix can only communicate with each other via the router, due to physical or logical network constrains, as shown in Figure 1, the first action for the router would be to clear the L-flag for this prefix. However, it has been observed that some hosts implementations will continue to try to resolve destination within that prefix and as a consequence, will be unable to establish connectivity with each other. Note that this document does not cover the use cases where the hosts are not isolated from each other, and continue to run NDP on a prefix announced by the router as not on-link. +---------------+ | | | ROUTER | | | +--+-------+----+ | | | ( ) | ( | ) ( | | ) ( | | ) ( | | ) (( | | ) ( LAYER-2 NETWORK ) ( | | ) ( | | ) ( | | ) ( | | ) ( | | )) ( | | ) | ( ( ) ) +--------+ | | +--------+ | | | | | | | | | | | | | H1 +----+ +-+ H2 | | | | | +--------+ +--------+ Figure 1: Topology There are three types of NS that the proxy can get: 1. NS lookup: Multicast, sent from the node's LLA to the SNMA 2. NS NUD: Unicast, sent from the node's LLA to the target Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 4] Internet-Draft IPv6 ND Routing Proxy June 2023 3. NS DAD: Multicast, sent from the unspecified address to the SNMA NS DAD are ignored by the Proxy (passed to the router). Assuming the physical or logical topology does not provide layer-2 connectivity between hosts, another type of proxy (DAD-proxy, specified in [RFC6957] is required to detect and handle duplications. NS Lookup and NS NUD are responded unconditionally by the proxy. The response always carries the Router MAC in a TLLA option. In case the entry is not in router's ND cache, and upon receiving data packets from the host, the router will initiate address resolution before forwarding. The end result is going to be identical to a host implementing "not on-link" behavior. This flow is illustrated in Figure 2. HOST PROXY/ TARGET ROUTER |NS lookup (target) | | +----------------------->| | | | | | | | |NA, src=target, TLLA=ROUTER | |<-----------------------+ | | | | | | | |data, dst=target | | +----------------------->| | | | NS lookup (target) | | +----------------------> | | | NA, SLLA=target | | |<-----------------------+ | | | | | data, dst=target | | +----------------------->| | | | Figure 2: NS flow When the proxy sends the NA, the R/S/O flags are set as specified below: * S flag should be on (response to a solicitation) * O flag should be on (to update sender's cache, in case the MAC has changed) * R flag should be on if and only if the target is the router address, off otherwise. Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 5] Internet-Draft IPv6 ND Routing Proxy June 2023 4. Security Considerations 5. IANA Considerations This specification does not require IANA action. 6. Contributors 7. Acknowledgments 8. Normative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 2020, . 9. Informative References [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, DOI 10.17487/RFC1027, October 1987, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 6] Internet-Draft IPv6 ND Routing Proxy June 2023 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, . [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, DOI 10.17487/RFC4943, September 2007, . [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", RFC 5517, DOI 10.17487/RFC5517, February 2010, . [RFC6957] Costa, F., Combes, J., Ed., Pougnard, X., and H. Li, "Duplicate Address Detection Proxy", RFC 6957, DOI 10.17487/RFC6957, June 2013, . [I-D.ietf-6man-ipv6-over-wireless] Thubert, P. and M. Richardson, "Architecture and Framework for IPv6 over Non-Broadcast Access", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-over-wireless-03, 16 June 2023, . Authors' Addresses Eric Levy-Abegnoli Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 06254 Mougins - Sophia Antipolis France Phone: +33 497 23 26 20 Email: elevyabe@cisco.com Pascal Thubert Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 06254 Mougins - Sophia Antipolis France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Levy-Abegnoli & Thubert Expires 22 December 2023 [Page 7]