Neighbor Discovery Proxies (ND Proxy)
RFC 4389
Document | Type | RFC - Experimental (April 2006; Errata) | |
---|---|---|---|
Authors | Mohit Talwar , Dave Thaler , Chirayu Patel | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4389 (Experimental) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | (None) |
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:Show full document text