Found 1 record.

Status: Held for Document Update (1)

RFC 4389, "Neighbor Discovery Proxies (ND Proxy)", April 2006

Errata ID: 103
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-04-18
Held for Document Update by: Brian Haberman

(1)  typo??

The last paragraph of section 5 of RFC 4389, on page 12, says:

   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.

Since the packet described has been sent out by node P, on its
interface '1', to node A, and A has only a single interface
involved in the scenarion, with link layer address 'a' (as explained
at the beginning of section 5), "on interface 2" is improper in the
snippit above.  (This may be the result of incomplete adaptation
after a copy-and-paste operation.)  A minimal correction to resolve
this issue might be to name the receive interface by its link layer
address, hence changing the text above to say:

   A receives this NA, processing it as usual.  Hence it creates a
   neighbor entry for B on interface 'a' in the REACHABLE state and
   records the link-layer address p1.

or alternatively, more detailed:

   A receives this NA, processing it as usual.  Hence it creates a
   neighbor entry for B on the interface with link layer address 'a'
   in the REACHABLE state and records the link-layer address p1.


(2)  typo!

The 3rd paragraph of Section 9, on page 13, says:

   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.  [...]

It should perhaps better say ( applying 's/from/for/' ) :

   This document does not introduce any new mechanisms for the
   protection of proxy Neighbor Discovery.  That is, it does not provide
|  a mechanism for 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.  [...]


(3)  outdated reference

In Section 11, Normative References, RFC 4389 contains the entry
(on page 14) [ICMPv6], pointing to RFC 2463.
But exactly 3 weeks before RFC 4389, RFC 4443 has been published
obsoleting and replacing RFC 2463.  Hence that entry should have
been updated to properly point to RFC 4443 instead.


If you agree with my 'diagnosis', I recommend that you submit an
Author's Errata Note for RFC 4389 covering the three issues
listed above.  But if you prefer, I can instead submit an Errata
Note on my own, with your consent mailed to the RFC-Editor.

Notes:

from pending

Report New Errata