doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc4389.txt b/doc/rfc/rfc4389.txt
new file mode 100644
index 0000000..5e0f8e0
--- /dev/null
+++ b/doc/rfc/rfc4389.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+