IPv6 Proxy ND: Cross-Segment Neighbor Discovery

IPv6 assumes that everything in a subnet is on the same link, and Neighbor Discovery enforces that assumption with multicast. The moment two hosts share a prefix but sit on different segments or different VLANs, they stop being able to reach each other even though the addressing plan says they should. Proxy Neighbor Discovery solves this by having a router answer NS messages on behalf of hosts that cannot hear each other, but it introduces its own failure modes if deployed carelessly. This article explains the proxy modes, the configurations, and the loop-prevention rules that keep the design safe.

When you actually need proxy ND

The IETF is blunt about scope: network-layer proxying should be used only when classic bridging is not possible, and it is not appropriate where loops exist in the physical topology or where routers exist on multiple segments. Use it for the narrow cases that keep appearing in real networks:

• Hosts in the same prefix on different physical media that cannot be bridged (wireless client isolation, some virtualisation stacks).
• Workloads that must keep their address while migrating between gateways — common with VM mobility.
• Hosts in the same prefix separated by VLAN with Layer 2 port isolation.
• Same segment, different VLAN, no re-addressing possible during a migration.

The mechanism in one paragraph

When the proxy receives a Neighbor Solicitation from host A asking for host B's link-layer address, and B is not local, the proxy answers with a Neighbor Advertisement carrying the proxy's own MAC but B's IPv6 address. A then sends frames addressed to the proxy, which forwards them toward B. Addresses are tracked per proxy interface in the neighbour cache, and the interface with the best neighbour state is used to forward. A packet is never forwarded back out the interface it arrived on; it is dropped instead.

Router configuration

# Huawei NE/AR style: routed proxy ND between two segments
interface GigabitEthernet0/0/1
 ipv6 enable
 ipv6 address 2001:db8:1::1 64
 ipv6 nd proxy route enable

interface GigabitEthernet0/0/2
 ipv6 enable
 ipv6 address 2001:db8:1::2 64
 ipv6 nd proxy route enable

# Any proxy ND (same gateway address on both sides, e.g. VM gateways)
interface Vlanif100
 ipv6 nd proxy anyway enable

# FortiGate style
config system interface
    edit "port1"
        config ipv6
            set autoconf enable
        end
    next
end
config system nd-proxy
    set status enable
    set member "port1" "port5"
end

The two examples illustrate the two dominant modes. Routed proxy ND is for hosts on the same prefix with different gateway addresses. Any proxy ND is for hosts whose gateways share one address, typically VMs that must stay reachable while moving between servers. Vendor implementations add intra-VLAN, inter-VLAN and local modes for the isolation cases; the configuration takes effect in descending order of priority, with "any proxy" winning.

Loop prevention is not optional

RFC 4389 defines a Proxy bit in the Router Advertisement flags field, and the rules that depend on it are mandatory:

• Only the upstream interface may receive RAs, and never an RA that already carries the Proxy bit.
• If an RA with the Proxy bit set arrives on any interface within the last 60 minutes, proxy functionality is disabled on that interface.
• As a consequence of the previous rule, different proxy functions cannot form loops through each other's advertisements — but vendor implementations need the detection implemented properly, so verify it rather than assuming.

Known limitations

• Proxy ND cannot be enabled on an interface with a CGA address; NA messages carrying the CGA option are discarded by the receiver.
• NS messages targeting a link-local address are not proxied, DAD NS messages with an all-zero source are not proxied, and NS for the device's own local addresses is handled normally rather than proxied.
• Multicast forwarding implied by proxy behaviour means broadcast and multicast volume increases across segments; size the links accordingly.

Verification

show ipv6 neighbors 2001:db8:1::/64
show ipv6 nd interface GigabitEthernet0/0/1
# From host A: confirm the proxy answers, not B
ndisc6 -r 2001:db8:1::50 eth0
ping6 -c 3 2001:db8:1::50

ndisc6 is the decisive test: the MAC returned should be the proxy's, and the address should be the remote host's. If the probe times out while unicast traffic flows, the proxy is working but not advertising, which usually means the upstream interface never learned the prefix.

Proxy ND is a targeted tool, not a substitute for a correct addressing plan. Where a host is genuinely on a different link, the cleaner long-term answer is a routed subnet, with the design considerations covered in our IPv6 SLAAC vs DHCPv6 decision guide. Where the prefix must stay stretched, prefer the proxy rather than extending Layer 2, which reintroduces every spanning-tree and broadcast-domain problem that modern designs work hard to remove.

For the addressing design that decides when proxy ND is even necessary, see IPv6 SLAAC versus DHCPv6.

原文链接：https://www.rfc-editor.org/rfc/rfc4389.html