IPv6 Neighbor Discovery Routing Proxy

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 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

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.¶

[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¶

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     |
|        |              |        |
+--------+              +--------+

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¶
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       |
   |                        +----------------------->|
   |                        |                        |

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.¶

4. Security Considerations

Authors' Addresses