Neighbor Discovery Proxies (ND Proxy)
RFC 4389
|
| Document |
Type |
|
RFC - Experimental
(April 2006; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4389 (Experimental)
|
|
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
Show full document text