Skip to main content

Neighbor Discovery Proxies (ND Proxy)
RFC 4389

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>
Subject: Document Action: 'Neighbor Discovery Proxies (ND 
         Proxy)' to Experimental RFC 

The IESG has approved the following document:

- 'Neighbor Discovery Proxies (ND Proxy) '
   <draft-ietf-ipv6-ndproxy-05.txt> as an Experimental RFC

This document is the product of the IP Version 6 Working Group. 

The IESG contact persons are Margaret Wasserman and Mark Townsley.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

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.

The behavior of one common type of IPv4 ARP Proxy deployed today
is documented herein for informational purposes, but this document
concentrates on describing similar behavior for IPv6.
Working Group Summary
This document is a work item of the IPv6 WG.

This document has been in the WG for a long time in various forms, 
including earlier, more complex versions that did not gain consensus
within the WG.  The current version takes a minimalist approach to 
allow the use of ND Proxy for single-hop prefix extension.  There 
seems to be solid consensus within the IPv6 WG to publish this 
mechanism, as currently documented, as an Experimental RFC.
Protocol Quality
This document has been reviewed for the IESG by Margaret Wasserman.

RFC Editor Note

Dear RFC Editor,

Please make the following two changes:


   Secondly, the extent to which Prefix Delegation is supported, and 
   supported without additional charge, is up to the service provider.

   Secondly, the extent to which Prefix Delegation is supported for any 
   particular subscriber class is up to the service provider.


   This document has no actions for IANA.

   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.



RFC Editor Note