path: root/doc/rfc/rfc4389.txt

Network Working Group                                          D. Thaler
Request for Comments: 4389                                     M. Talwar
Category: Experimental                                         Microsoft
                                                                C. Patel
                                                       All Play, No Work
                                                              April 2006


                 Neighbor Discovery Proxies (ND Proxy)

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Bridging multiple links into a single entity has several operational
   advantages.  A single subnet prefix is sufficient to support multiple
   physical links.  There is no need to allocate subnet numbers to the
   different networks, simplifying management.  Bridging some types of
   media requires network-layer support, however.  This document
   describes these cases and specifies the IP-layer support that enables
   bridging under these circumstances.





















Thaler, et al.                Experimental                      [Page 1]
^L
RFC 4389                        ND Proxy                      April 2006


Table of Contents

   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























Thaler, et al.                Experimental                      [Page 2]
^L
RFC 4389                        ND Proxy                      April 2006


1.  Introduction

   In the IPv4 Internet today, it is common for Network Address
   Translators (NATs) [NAT] to be used to easily connect one or more
   leaf links to an existing network without requiring any coordination
   with the network service provider.  Since NATs modify IP addresses in
   packets, they are problematic for many IP applications.  As a result,
   it is desirable to address the problem (for both IPv4 and IPv6)
   without the need for NATs, while still maintaining the property that
   no explicit cooperation from the router is needed.

   One common solution is IEEE 802 bridging, as specified in [BRIDGE].
   It is expected that whenever possible links will be bridged at the
   link layer using classic bridge technology [BRIDGE] as opposed to
   using the mechanisms herein.  However, classic bridging at the data-
   link layer has the following limitations (among others):

   o    It requires the ports to support promiscuous mode.

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

   As a result, two common scenarios, described below, are not solved,
   and it is these two scenarios we specifically target in this
   document.  While the mechanism described herein may apply to other
   scenarios as well, we will concentrate our discussion on these two
   scenarios.

1.1.  SCENARIO 1: Wireless Upstream

   The following figure illustrates 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 uses link-layer encryption so that wireless
   clients may not see each other's data.

   Classic bridging requires the bridge (node A in the above diagram) to
   be in promiscuous mode.  In this wireless scenario, A cannot put its
   wireless interface into promiscuous mode, since one wireless node
   cannot see traffic to/from other wireless nodes.





Thaler, et al.                Experimental                      [Page 3]
^L
RFC 4389                        ND Proxy                      April 2006


   IPv4 Address Resolution Protocol (ARP) proxying has been used for
   some years to solve this problem without involving NAT or requiring
   any change to the access point or router.  In this document, we
   describe equivalent functionality for IPv6 to remove this incentive
   to deploy NATs in IPv6.

   We also note that Prefix Delegation [PD] could also be used to solve
   this scenario.  There are, however, two disadvantages to this.
   First, if an implementation already supports IPv4 ARP proxying (which
   is indeed the case in a number of implementations 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.  This topological discrepancy can complicate applications
   and protocols that use the concept of a local subnet.  Second, the
   extent to which Prefix Delegation is supported for any particular
   subscriber class is up to the service provider.  Hence, there is no
   guarantee that Prefix Delegation will work without explicit
   configuration or additional charge.  Bridging, on the other hand,
   allows the device to work with zero configuration, regardless of the
   service provider's policies, just as a NAT does.  Hence bridging
   avoids the incentive to NAT IPv6 just to avoid paying for, or
   requiring configuration to get, another prefix.

1.2.  SCENARIO 2: PPP Upstream

   The following figure illustrates 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 does not support non-802 media.  The PPP Bridging
   Control Protocol [BCP] defines a mechanism for supporting bridging
   over PPP, but it requires both ends to be configured to support it.
   Hence IPv4 connectivity is often solved by making the proxy (node A
   in the above diagram) be a NAT or an IPv4 ARP proxy.  This document
   specifies a solution for IPv6 that does not involve NAT or require
   any change to the router.








Thaler, et al.                Experimental                      [Page 4]
^L
RFC 4389                        ND Proxy                      April 2006


1.3.  Inapplicable Scenarios

   This document is not applicable to scenarios with loops in the
   physical topology, or where routers exist on multiple segments.
   These cases are detected and proxying is disabled (see Section 6).

   In addition, this document is not appropriate for scenarios where
   classic bridging can be applied, or when configuration of the router
   can be done.

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

   The term "proxy interface" will be used to refer to an interface
   (which could itself be a bridge interface) over which network-layer
   proxying is done as defined herein.

   In this document, we make no distinction between a "link" (in the
   classic IPv6 sense) and a "subnet".  We use the term "segment" to
   apply to a bridged component of the link.

   Finally, while it is possible that functionality equivalent to that
   described herein may be achieved by nodes that do not fulfill all the
   requirements in [NODEREQ], in the remainder of this document we will
   describe behavior in terms of an IPv6 node as defined in that
   document.

3.  Requirements

   Proxy behavior is designed with the following requirements in mind:

   o    Support connecting multiple segments with a single subnet
        prefix.

   o    Support media that cannot be bridged at the link layer.

   o    Do not require any changes to existing routers.  That is,
        routers on the subnet may be unaware that the subnet is being
        bridged.








Thaler, et al.                Experimental                      [Page 5]
^L
RFC 4389                        ND Proxy                      April 2006


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

   o    Prevent loops.

   o    Also work in the absence of any routers.

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

   o    Allow dynamic addition of a proxy without adversely
        disrupting the network.

   o    The proxy behavior should not break any existing classic
        bridges in use on a network segment.

3.1.  Non-requirements

   The following items are not considered requirements, as they are not
   met by classic bridges:

   o    Show up as a hop in a traceroute.

   o    Use the shortest path between two nodes on different
        segments.

   o    Be able to use all available interfaces simultaneously.
        Instead, bridging technology relies on disabling redundant
        interfaces to prevent loops.

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

   The following additional items are not considered requirements for
   this document:

   o    Support network-layer protocols other than IPv6.  We do not
        preclude such support, but it is not specified in this
        document.





Thaler, et al.                Experimental                      [Page 6]
^L
RFC 4389                        ND Proxy                      April 2006


   o    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

   Network-layer support for proxying between multiple interfaces SHOULD
   be used only when classic bridging is not possible.

   When a proxy interface comes up, the node puts it in "all-multicast"
   mode so that it will receive all multicast packets.  It is common for
   interfaces not to support full promiscuous mode (e.g., on a wireless
   client), but all-multicast mode is generally still supported.

   As with all other interfaces, IPv6 maintains a neighbor cache for
   each proxy interface, which will be used as described below.

4.1.  Forwarding Packets

   When a packet from any IPv6 source address other than the unspecified
   address is received on a proxy interface, the neighbor cache of that
   interface SHOULD be consulted to find an entry for the source IPv6
   address.  If no entry exists, one is created in the STALE state.

   When any IPv6 packet is received on a proxy interface, it must be
   parsed to see whether it is known to be of a type that negotiates
   link-layer addresses.  This document covers the following types:
   Neighbor Solicitations, Neighbor Advertisements, Router
   Advertisements, and Redirects.  These packets are ones that can carry
   link-layer addresses, and hence must be proxied (as described 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.

   When any other IPv6 multicast packet is received on a proxy
   interface, in addition to any normal IPv6 behavior such as being
   delivered locally, it is forwarded unchanged (other than using a new
   link-layer header) out all other proxy interfaces on the same link.
   (As specified in [BRIDGE], the proxy may instead support multicast
   learning and filtering, but this is OPTIONAL.)  In particular, the
   IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in
   Section 4.1.1 below) are sent as a result of attempting this
   forwarding.





Thaler, et al.                Experimental                      [Page 7]
^L
RFC 4389                        ND Proxy                      April 2006


   When any other IPv6 unicast packet is received on a proxy interface,
   if it is not locally destined then it is forwarded unchanged (other
   than using a new link-layer header) to the proxy interface for which
   the next hop address appears in the neighbor cache.  Again the IPv6
   Hop Limit is not updated, and no ICMP errors (except as noted in
   Section 4.1.1 below) are sent as a result of attempting this
   forwarding.  To choose a proxy interface to forward to, the neighbor
   cache is consulted, and the interface with the neighbor entry in the
   "best" state is used.  In order of least to most preferred, the
   states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE.  A
   packet is never forwarded back out the same interface on which it
   arrived; such a packet is instead silently dropped.

   If no cache entry exists (as may happen if the proxy has previously
   evicted the cache entry or if the proxy is restarted), the proxy
   SHOULD queue the packet and initiate Neighbor Discovery as if the
   packet were being locally generated.  The proxy MAY instead silently
   drop the packet.  In this case, the entry will eventually be re-
   created when the sender re-attempts Neighbor Discovery.

   The link-layer header and the link-layer address within the payload
   for each forwarded packet will be modified as follows:

   1)   The source address will be the address of the outgoing
        interface.

   2)   The destination address will be the address in the neighbor
        entry corresponding to the destination IPv6 address.

   3)   The link-layer address within the payload is substituted with
        the address of the outgoing interface.

4.1.1.  Sending Packet Too Big Messages

   Whenever any IPv6 packet is to be forwarded out an interface whose
   MTU is smaller than the size of the packet, the ND proxy drops the
   packet and sends a Packet Too Big message back to the source, as
   described in [ICMPv6].

4.1.2.  Proxying Packets with Link-Layer Addresses

   Once it is determined that the packet is either multicast or else is
   not locally destined (if unicast), the special types enumerated above
   (ARP, etc.) that carry link-layer addresses are handled by generating
   a proxy packet that contains the proxy's link-layer address on the
   outgoing interface instead.  Such link-layer addresses occur in the





Thaler, et al.                Experimental                      [Page 8]
^L
RFC 4389                        ND Proxy                      April 2006


   link-layer header itself, as well as in the payloads of some
   protocols.  As with all forwarded packets, the link-layer header is
   new.

   Section 4.1.3 enumerates the currently known cases where link-layer
   addresses must be changed in payloads.  For guidance on handling
   future protocols, Section 7, "Guidelines to Proxy Developers",
   describes the scenarios in which the link-layer address substitution
   in the payload should be performed.  Note that any change to the
   length of a proxied packet, such as when the link-layer address
   length changes, will require a corresponding change to the IPv6
   Payload Length field.

4.1.3.  IPv6 ND Proxying

   When any IPv6 packet is received on a proxy interface, it must be
   parsed to see whether it is known to be one of the following 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 is processed locally as described in Section 7.2.3 of [ND] but no
   NA is generated immediately.  Instead the NS is proxied as described
   above and the NA will be proxied when it is received.  This ensures
   that the proxy does not interfere with hosts moving from one segment
   to another since it never responds to an NS based on its own cache.

4.1.3.2.  ICMPv6 Neighbor Advertisements

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

4.1.3.3.  ICMPv6 Router Advertisements

   The following special processing is done for IPv6 Router
   Advertisements (RAs).

   A new "Proxy" bit is defined in the existing Router Advertisement
   flags field as follows:

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




Thaler, et al.                Experimental                      [Page 9]
^L
RFC 4389                        ND Proxy                      April 2006


   where "P" indicates the location of the Proxy bit, and "Rsv"
   indicates the remaining reserved bits.

   The proxy determines an "upstream" proxy interface, typically through
   a (zero-configuration) physical choice dictated by the scenario (see
   Scenarios 1 and 2 above), or through manual configuration.

   When an RA with the P bit clear arrives on the upstream interface,
   the P bit is set when the RA is proxied out all 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; i.e., proxy
   functionality is disabled on that interface.

   Furthermore, if any RA (regardless of the value of the P bit) has
   arrived on a "downstream" proxy interface within the last 60 minutes,
   that interface MUST NOT be used as a proxy interface.

   The RA is processed locally as well as proxied as described in
   Section 4.1.2, unless such proxying is disabled as noted above.

4.1.3.4.  ICMPv6 Redirects

   If the received packet is an ICMPv6 Redirect message, then the
   proxied packet should be modified as follows.  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 simply contains the
   link-layer address of the target as found in the proxy's neighbor
   entry, since the redirected host may 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 link-layer address of the proxy on the
   sending interface, since the redirected host must reach the target
   address through the proxy.  Otherwise, the proxy has no valid
   neighbor entry for the target address, and the proxied packet
   contains no TLLA option, which will cause the redirected host to
   perform Neighbor Discovery for the target address.

4.2.  Originating Packets

   Locally originated packets that are sent on a proxy interface also
   follow the same rules as packets received on a proxy interface.  If
   no neighbor entry exists when a unicast packet is to be locally
   originated, an interface can be chosen in any implementation-specific
   fashion.  Once the neighbor is resolved, the actual interface will be



Thaler, et al.                Experimental                     [Page 10]
^L
RFC 4389                        ND Proxy                      April 2006


   discovered and the packet will be sent on that interface.  When a
   multicast packet is to be locally originated, an interface can be
   chosen in any implementation-specific fashion, and the packet will
   then be forwarded out other proxy interfaces on the same link as
   described in Section 4.1 above.

5.  Example

   Consider the following topology, where A and B are nodes on separate
   segments which are connected by a proxy P:

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

   A and B have link-layer addresses a and b, respectively.  P has
   link-layer addresses p1 and p2 on the two segments.  We now walk
   through the actions that happen when A attempts to send an initial
   IPv6 packet to B.

   A first does a route lookup on the destination address B.  This
   matches the on-link subnet prefix, and a destination cache entry is
   created as well as a neighbor cache entry in the INCOMPLETE state.
   Before the packet can be sent, A needs to resolve B's link-layer
   address and 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 is receiving all link-layer
   multicast packets) and processes it as it would any multicast packet
   by forwarding it out to other segments on the link.  However, before
   actually sending the packet, it determines if the packet being sent
   is one that requires proxying.  Since it is an NS, it creates a
   neighbor entry for A on interface 1 and records its 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 other proxy
   interfaces on the subnet.  Before sending the packet out interface 2,
   it replaces the link-layer address in the SLLA option with its own
   link-layer address, p2.

   B receives this NS, processing it as usual.  Hence it creates a
   neighbor entry for A mapping it to the link-layer address p2.  It
   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, i.e.,
   to the link-layer address p2.






Thaler, et al.                Experimental                     [Page 11]
^L
RFC 4389                        ND Proxy                      April 2006


   The NA is received by P, which then processes it as it would any
   unicast packet; i.e., it forwards this out interface 1, based on the
   neighbor cache.  However, before actually sending the packet out, it
   inspects it to determine if the packet being sent is one that
   requires proxying.  Since it is an NA, it updates its neighbor entry
   for B to be REACHABLE and records the link-layer address b.  P then
   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.

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

6.  Loop Prevention

   An implementation MUST ensure that loops are prevented by using the P
   bit in RAs as follows.  The proxy determines an "upstream" proxy
   interface, typically 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 never from other
   proxies.  Proxy functionality is disabled on an interface otherwise.
   Finally, a proxy MUST wait until it has sent two P bit RAs on a given
   "downstream" interface before it enables forwarding on that
   interface.

7.  Guidelines to Proxy Developers

   Proxy developers will have to accommodate protocols or protocol
   options (for example, new ICMP messages) that are developed in the
   future, or protocols that are not mentioned in this document (for
   example, proprietary protocols).  This section prescribes guidelines
   that can be used by proxy developers to accommodate protocols that
   are not mentioned herein.

   1)   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.





Thaler, et al.                Experimental                     [Page 12]
^L
RFC 4389                        ND Proxy                      April 2006


   2)   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.

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.

9.  Security Considerations

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

   Proxies are susceptible to the same kind of security issues that
   plague hosts using unsecured Neighbor Discovery.  These issues
   include hijacking traffic and denial-of-service within the subnet.
   Malicious nodes within the subnet can take advantage of this
   property, and hijack traffic.  In addition, a Neighbor Discovery
   proxy is essentially a legitimate man-in-the-middle, which implies
   that there is a need to distinguish proxies from unwanted man-in-
   the-middle attackers.

   This document does not introduce any new mechanisms for the
   protection of proxy Neighbor Discovery.  That is, it does not provide
   a mechanism from 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 the use of proxy Neighbor Discovery may render it
   impossible to use SEND both on the leaf subnet and on the external
   subnet.  This is because the modifications performed by the proxy
   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.





Thaler, et al.                Experimental                     [Page 13]
^L
RFC 4389                        ND Proxy                      April 2006


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

   It is 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 is 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 is 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 for
   representing 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.

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.



Thaler, et al.                Experimental                     [Page 14]
^L
RFC 4389                        ND Proxy                      April 2006


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














Thaler, et al.                Experimental                     [Page 15]
^L
RFC 4389                        ND Proxy                      April 2006


Appendix A: Comparison with Naive RA Proxy

   It has 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.

   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.
























Thaler, et al.                Experimental                     [Page 16]
^L
RFC 4389                        ND Proxy                      April 2006


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

























Thaler, et al.                Experimental                     [Page 17]
^L
RFC 4389                        ND Proxy                      April 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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







Thaler, et al.                Experimental                     [Page 18]
^L