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).
AbstractBridging 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.
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 126.96.36.199. ICMPv6 Neighbor Solicitations ..............9 188.8.131.52. ICMPv6 Neighbor Advertisements .............9 184.108.40.206. ICMPv6 Router Advertisements ...............9 220.127.116.11. 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
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.
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. ICMPv6].
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. 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.
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.
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.
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. Section 18.104.22.168, 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.
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. 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.
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]. [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. [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.
PD] should be used instead.
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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).