RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 4389, "Neighbor Discovery Proxies (ND Proxy)", April 2006
Source of RFC: ipv6 (int)
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