RFC 4389

Neighbor Discovery Proxies (ND Proxy)

📅 published April 2006, from ietf

RFC 4389: Neighbor Discovery Proxies (ND Proxy) 🎀

Okay bestie, the title block is giving everything 💅 This is RFC 4389 from the Network Working Group. It's titled Neighbor Discovery Proxies (ND Proxy), dated April 2006. The authors are D. Thaler, M. Talwar, and C. Patel, all at Microsoft. Its category is Experimental. The title block doesn't list anything it obsoletes or updates. The header also says "All Play, No Work," which is lowkey iconic 😭

Status of This Memo ✨

So this one is an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The authors want discussion and suggestions for improvement, and distribution of this memo is unlimited 🦋

Copyright Notice

Abstract

Bridging multiple links into a single entity has some really nice operational perks 🌸 One single subnet prefix is enough to cover multiple physical links, so you don't have to allocate subnet numbers to each network. That makes management way simpler. Bridging some types of media needs network-layer support though, and this document covers those cases and specifies the IP-layer support that makes bridging work in them.

   1. Introduction ....................................................3
      1.1. SCENARIO 1: Wireless Upstream ..............................3
      1.2. SCENARIO 2: PPP Upstream ...................................4
      1.3. Inapplicable Scenarios .....................................5
   2. Terminology .....................................................5
   3. Requirements ....................................................5
      3.1. Non-requirements ...........................................6
   4. Proxy Behavior ..................................................7
      4.1. Forwarding Packets .........................................7
           4.1.1. Sending Packet Too Big Messages .....................8
           4.1.2. Proxying Packets with Link-Layer Addresses ..........8
           4.1.3. IPv6 ND Proxying ....................................9
                  4.1.3.1. ICMPv6 Neighbor Solicitations ..............9
                  4.1.3.2. ICMPv6 Neighbor Advertisements .............9
                  4.1.3.3. ICMPv6 Router Advertisements ...............9
                  4.1.3.4. ICMPv6 Redirects ..........................10
      4.2. Originating Packets .......................................10
   5. Example ........................................................11
   6. Loop Prevention ................................................12
   7. Guidelines to Proxy Developers .................................12
   8. IANA Considerations ............................................13
   9. Security Considerations ........................................13
   10. Acknowledgements ..............................................14
   11. Normative References ..........................................14
   12. Informative References ........................................15
   Appendix A: Comparison with Naive RA Proxy ........................16

1. Introduction ✨

Here's the vibe: on the IPv4 Internet today, people often use Network Address Translators (NATs) [NAT] to hook up one or more leaf links to an existing network, and they don't need to coordinate with the network service provider to do it. The catch is that NATs rewrite IP addresses in packets, which breaks a lot of IP applications. So it would be great to solve this for both IPv4 and IPv6 without NATs, while still keeping the property that the router doesn't need to explicitly cooperate 🫶

One common solution is IEEE 802 bridging, as specified in [BRIDGE]. Whenever possible, links are expected to be bridged at the link layer with classic bridge technology [BRIDGE] instead of using the mechanisms in this document. Classic data-link bridging has some limitations though (among others):

It requires the ports to support promiscuous mode.
It requires all ports to support the same type of link-layer addressing (in particular, IEEE 802 addressing).

So two common scenarios don't get solved, and those are the two this document focuses on. The mechanism could apply to other scenarios too, but we'll mostly talk about these two 💜

1.1. SCENARIO 1: Wireless Upstream 🦋

Here's a likely example:

            |         +-------+           +--------+
      local |Ethernet |       | Wireless  | Access |
            +---------+   A   +-)))   (((-+        +--> rest of network
      hosts |         |       |   link    | Point  |
            |         +-------+           +--------+

In this scenario the access point has assigned an IPv6 subnet prefix to the wireless link, and it uses link-layer encryption so wireless clients can't see each other's data 🙈

Classic bridging needs the bridge (node A in the diagram above) to be in promiscuous mode. But in this wireless setup, A can't put its wireless interface into promiscuous mode, since one wireless node can't see traffic to or from other wireless nodes. Not it 💀

IPv4 Address Resolution Protocol (ARP) proxying has been used for years to solve this without NAT and without changing the access point or the router. This document describes equivalent functionality for IPv6, so there's less incentive to deploy NATs in IPv6 🌈

Prefix Delegation [PD] could also solve this scenario, but there are two downsides. First, if an implementation already supports IPv4 ARP proxying (which a number of implementations do today), then IPv6 Prefix Delegation would result in separate IPv6 subnets on either side of the device, while a single IPv4 subnet would span both segments. That topological mismatch can complicate applications and protocols that rely on the concept of a local subnet. Second, how far Prefix Delegation is supported for any particular subscriber class is up to the service provider. So there's no guarantee it works without explicit configuration or an additional charge.

Bridging, on the other hand, lets the device work with zero configuration no matter what the service provider's policies are, just like a NAT does. That means bridging avoids the incentive to NAT IPv6 just to skip paying for another prefix, or to skip configuring one. Iconic behavior 👑

1.2. SCENARIO 2: PPP Upstream 🍓

Here's another likely example:

            |         +-------+           +--------+
      local |Ethernet |       | PPP link  |        |
            +---------+   A   +-----------+ Router +--> rest of network
      hosts |         |       |           |        |
            |         +-------+           +--------+

In this scenario the router has assigned a /64 to the PPP link and advertises it in an IPv6 Router Advertisement ✨

Classic bridging doesn't support non-802 media. The PPP Bridging Control Protocol [BCP] defines a way to support bridging over PPP, but it requires both ends to be configured for it. So IPv4 connectivity is often solved by making the proxy (node A in the diagram) a NAT or an IPv4 ARP proxy. This document specifies an IPv6 solution that doesn't involve NAT or require any change to the router 🧚

1.3. Inapplicable Scenarios 🙅‍♀️

This document isn't applicable to scenarios with loops in the physical topology, or where routers exist on multiple segments. Those cases get detected and proxying is disabled (see Section 6).

It's also not appropriate for scenarios where classic bridging can be applied, or where the router can be configured.

2. Terminology 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS].

"Proxy interface" is the term for an interface (which could itself be a bridge interface) over which network-layer proxying is done as defined here.

Quick note: this document doesn't distinguish between a "link" (in the classic IPv6 sense) and a "subnet." The term "segment" refers to a bridged component of the link ✨

Last thing: functionality like this might be achieved by nodes that don't meet all the requirements in [NODEREQ]. But the rest of the document describes behavior in terms of an IPv6 node as defined in that document 🫶

3. Requirements 🎀

Proxy behavior is designed with the following requirements in mind:

Support connecting multiple segments with a single subnet prefix.
Support media that cannot be bridged at the link layer.
Do not require any changes to existing routers. That is, routers on the subnet may be unaware that the subnet is being bridged.
Provide full connectivity between all nodes in the subnet. For example, if there are existing nodes (such as any routers on the subnet) that have addresses in the subnet prefix, adding a proxy must allow bridged nodes to have full connectivity with existing nodes on the subnet.
Prevent loops.
Also work in the absence of any routers.
Support nodes moving between segments. For example, a node should be able to keep its address without seeing its address as a duplicate due to any cache maintained at the proxy.
Allow dynamic addition of a proxy without adversely disrupting the network.
The proxy behavior should not break any existing classic bridges in use on a network segment.

3.1. Non-requirements 🌸

These items are not considered requirements, since classic bridges don't meet them either:

Show up as a hop in a traceroute.
Use the shortest path between two nodes on different segments.
Be able to use all available interfaces simultaneously. Instead, bridging technology relies on disabling redundant interfaces to prevent loops.
Support connecting media on which Neighbor Discovery is not possible. For example, some technologies such as [6TO4] use an algorithmic mapping from IPv6 address to the underlying link-layer (IPv4 in this case) address, and hence cannot support bridging arbitrary IP addresses.

These additional items are also not considered requirements for this document:

Support network-layer protocols other than IPv6. We do not preclude such support, but it is not specified in this document.
Support Redirects for off-subnet destinations that point to a router on a different segment from the redirected host. While this scenario may be desirable, no solution is currently known that does not have undesirable side effects outside the subnet. As a result, this scenario is outside the scope of this document.

4. Proxy Behavior ✨

okay so network-layer proxying between multiple interfaces SHOULD only be used when classic bridging is not possible 🌸 bridging is the go-to, and proxying is the backup plan.

when a proxy interface comes up, the node switches it into "all-multicast" mode so it catches every multicast packet 🦋 lots of interfaces don't do full promiscuous mode (wireless clients, I'm looking at you 🙈), but all-multicast mode is usually still supported, so it's giving everyone a fair shot.

and just like every other interface, IPv6 keeps a neighbor cache for each proxy interface too, which gets used in the ways described below 💅

4.1. Forwarding Packets

when a packet from any IPv6 source address (except the unspecified address) lands on a proxy interface, that interface's neighbor cache SHOULD be checked for an entry for the source IPv6 address. if there's no entry, one gets created in the STALE state ✨

any IPv6 packet that hits a proxy interface must be parsed to see if it's a type that negotiates link-layer addresses. this doc covers Neighbor Solicitations, Neighbor Advertisements, Router Advertisements, and Redirects 🎀 these carry link-layer addresses, so they must be proxied (more on that below) so that packets between nodes on different segments can be received by the proxy and have the correct link-layer address type on each segment. the link-layer address stuff is a whole thing 😭

when any other IPv6 multicast packet shows up on a proxy interface, it gets its normal IPv6 treatment (like being delivered locally) and it's also forwarded unchanged (just with a new link-layer header) out all the other proxy interfaces on the same link. ([BRIDGE] says the proxy may instead support multicast learning and filtering, but that part is OPTIONAL 🧚) the IPv6 Hop Limit isn't updated, and no ICMP errors get sent because of this forwarding (except the ones noted in Section 4.1.1 below) 🍓

when any other IPv6 unicast packet arrives on a proxy interface and it's not locally destined, it gets forwarded unchanged (new link-layer header and all) to the proxy interface where the next hop address shows up in the neighbor cache 💖 again, the Hop Limit isn't updated, and no ICMP errors get sent (except as noted in Section 4.1.1 below). to pick the proxy interface to forward to, the neighbor cache gets checked, and the interface with the neighbor entry in the "best" state wins 👑 going from least to most preferred, the states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE. a packet is never forwarded back out the interface it came in on. instead it's silently dropped, no drama 🙅‍♀️

if there's no cache entry (which can happen if the proxy evicted it earlier or if the proxy got restarted), the proxy SHOULD queue the packet and kick off Neighbor Discovery like the packet was generated locally 🔥 the proxy MAY instead just silently drop the packet. either way, the entry will eventually get re-created when the sender tries Neighbor Discovery again ✨

the link-layer header and the link-layer address inside the payload for each forwarded packet get modified like this:

the source address becomes the address of the outgoing interface.
the destination address becomes the address in the neighbor entry that matches the destination IPv6 address.
the link-layer address inside the payload gets swapped out for the address of the outgoing interface.

4.1.1. Sending Packet Too Big Messages

whenever an IPv6 packet is about to be forwarded out an interface whose MTU is smaller than the packet's size, the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6] 🙈 no packet gets to be too big for the room, bestie.

4.1.2. Proxying Packets with Link-Layer Addresses

once it's decided the packet is either multicast or not locally destined (if it's unicast), the special types listed above (ARP, etc.) that carry link-layer addresses get handled by generating a proxy packet. that proxy packet has the proxy's link-layer address on the outgoing interface instead 💅 these link-layer addresses can show up in the link-layer header itself, and also inside the payloads of some protocols. as with all forwarded packets, the link-layer header is new.

Section 4.1.3 lists the cases we currently know about where link-layer addresses have to change in payloads. for handling future protocols, Section 7, "Guidelines to Proxy Developers", describes the scenarios where the link-layer address substitution in the payload should be performed 🧚 also, if a proxied packet's length changes (like when the link-layer address length changes), the IPv6 Payload Length field needs a matching update. don't forget that one 😭

4.1.3. IPv6 ND Proxying

when any IPv6 packet is received on a proxy interface, it must be parsed to see if it's one of these types: Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, or Redirect 🦋

4.1.3.1. ICMPv6 Neighbor Solicitations

if the received packet is an ICMPv6 Neighbor Solicitation (NS), the NS gets processed locally as described in Section 7.2.3 of [ND], but no NA is generated right away. instead, the NS is proxied as described above, and the NA gets proxied when it comes back 🫶 this way the proxy never answers an NS from its own cache, so hosts moving between segments aren't messed with. the proxy stays out of the way, iykyk 💖

4.1.3.2. ICMPv6 Neighbor Advertisements

if the received packet is an ICMPv6 Neighbor Advertisement (NA), the neighbor cache on the receiving interface gets updated first, as if the NA were locally destined. then the NA gets proxied as described in 4.1.2 above 🎀

4.1.3.3. ICMPv6 Router Advertisements

here's the special processing for IPv6 Router Advertisements (RAs) 🌈

a new "Proxy" bit is defined in the existing Router Advertisement flags field, and it looks like this:

+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|Rsv|
+-+-+-+-+-+-+-+-+

where "P" shows where the Proxy bit lives, and "Rsv" shows the remaining reserved bits ✨

the proxy picks an "upstream" proxy interface. this is usually a zero-configuration physical choice dictated by the scenario (see Scenarios 1 and 2 above), or it can be set by manual configuration 🍓

when an RA with the P bit clear arrives on the upstream interface, the P bit gets set when the RA is proxied out all the other ("downstream") proxy interfaces (see Section 6) 💅

if an RA with the P bit set has arrived on a given interface (including the upstream interface) within the last 60 minutes, that interface MUST NOT be used as a proxy interface. so, proxy functionality is turned off on that interface 🙅‍♀️ no double proxying, babe.

also, if any RA (no matter what the P bit says) has arrived on a "downstream" proxy interface within the last 60 minutes, that interface MUST NOT be used as a proxy interface 💀

the RA gets processed locally AND proxied as described in Section 4.1.2, unless proxying was disabled as noted above 👑

4.1.3.4. ICMPv6 Redirects

if the received packet is an ICMPv6 Redirect message, the proxied packet should be modified like this. if the proxy has a valid (i.e., not INCOMPLETE) neighbor entry for the target address on the same interface as the redirected host, then the Target Link-Layer Address (TLLA) option in the proxied Redirect just contains the target's link-layer address from the proxy's neighbor entry. that's because the redirected host can reach the target address directly 🦋

otherwise, if the proxy has a valid neighbor entry for the target address on some other interface, then the TLLA option in the proxied packet contains the proxy's link-layer address on the sending interface. this is because the redirected host has to reach the target address through the proxy 🧚

otherwise, if the proxy has no valid neighbor entry for the target address, the proxied packet has no TLLA option at all. that makes the redirected host do Neighbor Discovery for the target address 🙈

4.2. Originating Packets

locally originated packets that get sent on a proxy interface follow the same rules as packets received on a proxy interface 💖 if no neighbor entry exists when a unicast packet is about to be locally originated, an interface can be picked in any implementation-specific way. once the neighbor is resolved, the actual interface gets discovered and the packet is sent out that interface ✨ when a multicast packet is locally originated, an interface can be picked in any implementation-specific way too, and then the packet gets forwarded out the other proxy interfaces on the same link, as described in Section 4.1 above 🫶

5. Example 🎀

okay so picture this topology, where A and B are nodes on separate segments that are connected by a proxy P 🦋

        A---|---P---|---B
         a    p1 p2    b

A has link-layer address a and B has link-layer address b. P has link-layer addresses p1 and p2 on its two segments. now let's walk through what happens when A tries to send an initial IPv6 packet to B 👀

first, A does a route lookup on the destination address B. it matches the on-link subnet prefix, so a destination cache entry gets created, along with a neighbor cache entry in the INCOMPLETE state 🌸 before the packet can be sent, A needs to resolve B's link-layer address, so it sends a Neighbor Solicitation (NS) to the solicited-node multicast address for B. the Source Link-Layer Address (SLLA) option in the solicitation contains A's link-layer address 💅

P receives the solicitation (since it gets all link-layer multicast packets) and handles it like any multicast packet by forwarding it out to other segments on the link ✨ but before actually sending it, P checks whether the packet needs proxying. since it's an NS, P creates a neighbor entry for A on interface 1 and records A's link-layer address. it also creates a neighbor entry for B (on an arbitrary proxy interface) in the INCOMPLETE state 🧚 since the packet is multicast, P then needs to proxy the NS out all the other proxy interfaces on the subnet. before sending the packet out interface 2, P replaces the link-layer address in the SLLA option with its own link-layer address, p2 💖

B receives this NS and processes it as usual. so it creates a neighbor entry for A mapping it to the link-layer address p2. then B responds with a Neighbor Advertisement (NA) sent to A, containing B's link-layer address b. the NA is sent using A's neighbor entry, which means it goes to the link-layer address p2 🙈

the NA gets received by P, which processes it like any unicast packet, meaning it forwards it out interface 1 based on the neighbor cache. but before actually sending the packet, P inspects it to see whether it needs proxying. since it's an NA, P updates its neighbor entry for B to REACHABLE and records the link-layer address b. then P replaces the link-layer address in the TLLA option with its own link-layer address on the outgoing interface, p1. the packet is then sent out interface 1 🔥

finally, A receives this NA and processes it as usual. so it creates a neighbor entry for B on interface 2 in the REACHABLE state and records the link-layer address p1 🎉

6. Loop Prevention 🔁

Okay bestie, loops are the chaos we're stopping, and the P bit in RAs is our bouncer 💅 An implementation MUST ensure that loops are prevented by using the P bit in RAs as follows. The proxy works out an "upstream" proxy interface, usually through a (zero-configuration) physical choice dictated by the scenario (see Scenarios 1 and 2 above), or through manual configuration. As described in Section 4.1.3.3, only the upstream interface is allowed to receive RAs, and it's never allowed to take them from other proxies 🙅‍♀️ Proxy functionality is disabled on any other interface. Finally, a proxy MUST wait until it has sent two P bit RAs on a given "downstream" interface before it turns on forwarding on that interface. Patience is a virtue, babe 🌸

7. Guidelines to Proxy Developers 🧑‍💻

Proxy devs are gonna have to deal with protocols and protocol options that don't exist yet (like new ICMP messages), plus protocols this document never mentions (like proprietary ones) 😭 This section gives you guidelines for handling those protocols that aren't mentioned here, so you're not left guessing.

If a link-layer address carried in the payload of the protocol can be used in the link-layer header of future messages, then the proxy should substitute it with its own address. For example, the link-layer address in NA messages is used in the link-layer header for future messages, and, hence, the proxy substitutes it with its own address. ✨

For multicast packets, the link-layer address substituted within the payload will be different for each outgoing interface. Each interface gets its own version, girl 🦋

If the link-layer address in the payload of the protocol will never be used in any link-layer header, then the proxy should not substitute it with its own address. No special actions are required for supporting these protocols. For example, [DHCPv6] is in this category. Lowkey the easy mode 🍓

8. IANA Considerations 📋

This document defines a new bit in the RA flags (the P bit) 🎀 There is currently no registration procedure for such bits, so IANA should not take any action. Nothing to register, nothing to touch 💅

9. Security Considerations 🚨

Okay, this section is SERIOUS, bestie. Read every word. 😭

Unsecured Neighbor Discovery has a bunch of security issues, which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security mechanisms that can protect Neighbor Discovery 🔐

Proxies are open to the same kinds of security problems that plague hosts using unsecured Neighbor Discovery. These include traffic hijacking and denial-of-service within the subnet. Malicious nodes inside the subnet can take advantage of this and hijack traffic. On top of that, a Neighbor Discovery proxy is basically a legitimate man-in-the-middle, which means we need a way to tell proxies apart from unwanted man-in-the-middle attackers 👀 Not it.

This document does not introduce any new mechanisms for protecting proxy Neighbor Discovery. That is, it does not provide a mechanism for authorizing certain devices to act as proxies, and it does not provide extensions to SEND to make it possible to use both SEND and proxies at the same time. We note that RFC 2461 [ND] already defines the ability to proxy Neighbor Advertisements, and extensions to SEND are already needed to cover that case, independent of this document.

Note also that using proxy Neighbor Discovery may make it impossible to use SEND both on the leaf subnet and on the external subnet. This is because the modifications the proxy makes will invalidate the RSA Signature Option in a secured Neighbor Discovery message, and cause SEND-capable nodes to either discard the messages or treat them as unsecured. The latter is the desired operation when SEND is used together with this specification, and it ensures that SEND nodes within this environment can selectively downgrade themselves to unsecure Neighbor Discovery when proxies are present 🫶

In the following, we outline some potential paths to follow when defining a secure proxy mechanism 🧚

It's reasonable for nodes on the leaf subnet to have a secure relationship with the proxy, and to accept ND packets either from the owner of a specific address (normal SEND) or from a trusted proxy that it can verify (see below).

For nodes on the external subnet, there's a trade-off between security (where all nodes have a secure relationship with the proxy) and privacy (where no nodes are aware that the proxy is a proxy). In the case of a point-to-point external link (Scenario 2), however, SEND may not be a requirement on that link.

Verifying that ND packets come from a trusted proxy requires an extension to the SEND protocol and is left for future work [SPND], but it's similar to the problem of securing Router Advertisements that is supported today. For example, a rogue node can send a Router Advertisement to cause a proxy to disable its proxy behavior, and hence cause denial-of-service to other nodes. This threat is covered in Section 4.2.1 of [PSREQ] 💀

Alternative designs might involve schemes where the right to represent a particular host is delegated to the proxy, or where multiple nodes can make statements on behalf of one address [RINGSIG] ✨

10. Acknowledgements 💜

The authors wish to thank Jari Arkko for contributing portions of the Security Considerations text. Thank you, Jari 🙌

11. Normative References 📚

[BRIDGE]    T. Jeffree, editor, "Media Access Control (MAC) Bridges",
            ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/
            getieee802/download/802.1D-2004.pdf.

[ICMPv6]    Conta, A. and S. Deering, "Internet Control Message
            Protocol (ICMPv6) for the Internet Protocol Version 6
            (IPv6) Specification", RFC 2463, December 1998.

[KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[ND]        Narten, T., Nordmark, E., and W. Simpson, "Neighbor
            Discovery for IP Version 6 (IPv6)", RFC 2461, December
            1998.

[NODEREQ]   Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,
            April 2006.

12. Informative References 🧠

[6TO4]      Carpenter, B. and K. Moore, "Connection of IPv6 Domains
            via IPv4 Clouds", RFC 3056, February 2001.

[BCP]       Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point
            Protocol (PPP) Bridging Control Protocol (BCP)", RFC
            3518, April 2003.

[DHCPv6]    Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
            C., and M. Carney, "Dynamic Host Configuration Protocol
            for IPv6 (DHCPv6)", RFC 3315, July 2003.

[NAT]       Srisuresh, P. and K. Egevang, "Traditional IP Network
            Address Translator (Traditional NAT)", RFC 3022, January
            2001.

[PD]        Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
            Host Configuration Protocol (DHCP) version 6", RFC 3633,
            December 2003.

[PSREQ]     Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
            Discovery (ND) Trust Models and Threats", RFC 3756, May
            2004.

[RINGSIG]   Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying
            using Multi-Key Cryptographically Generated Addresses
            (MCGAs)", Work in Progress, August 2005.

[SEND]      Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
            "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[SPND]      Daley, G., "Securing Proxy Neighbour Discovery Problem
            Statement", Work in Progress, February 2005.

Appendix A: Comparison with Naive RA Proxy 🫧

It's been suggested that a simple Router Advertisement (RA) proxy would be sufficient, where the subnet prefix in an RA is "stolen" by the proxy and applied to a downstream link instead of an upstream link. Other ND messages are not proxied. Sounds easy, right? It's not 😩

There are many problems with this approach. First, it requires cooperation from all nodes on the upstream link. No node (including the router sending the RA) can have an address in the subnet, or it will not have connectivity with nodes on the downstream link. This is because when a node on a downstream link tries to do Neighbor Discovery, and the proxy does not send the NS on the upstream link, it will never discover the neighbor on the upstream link. Similarly, if messages are not proxied during Duplicate Address Detection (DAD), conflicts can occur.

Second, if the proxy assumes that no nodes on the upstream link have addresses in the prefix, such a proxy could not be safely deployed without cooperation from the network administrator, since it introduces a requirement that the router itself not have an address in the prefix. This rules out use in situations where bridges and Network Address Translators (NATs) are used today, which is the problem this document is directly addressing. Instead, where a prefix is desired for use on one or more downstream links in cooperation with the network administrator, Prefix Delegation [PD] should be used instead. Use the right tool, friend 🧰

Authors' Addresses 📮

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052-6399

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com


Mohit Talwar
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052-6399

Phone: +1 425 705 3131
EMail: mohitt@microsoft.com


Chirayu Patel
All Play, No Work
Bangalore, Karnataka 560038

Phone: +91-98452-88078
EMail: chirayu@chirayu.org

Full Copyright Statement ⚖️

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔏

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🎀

📦 where this page comes from

ietf: rfc4389 2006-04
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms