Neighbor Discovery Proxies (ND Proxy)
RFC 4389

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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: