RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006Source of RFC: ipv6 (int)
Errata ID: 88
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-04-19
Held for Document Update by: Brian Haberman
(1) text omission ??? I suspect that something went wrong in the publication process for RFC 4443, leading to significant text omission. Symptoms: o Text on top of page 5 apparently *continues* specifications that are not in the published text; o Appendix A contains the change item: - Added specification that all ICMP error messages shall have exactly 32 bits of type-specific data, so that receivers can reliably find the embedded invoking packet even when they don't recognize the ICMP message Type. I could not find any text in the body of the RFC corresponding to this statement. Therefore, I suspect that general specifications for ICMPv6 error messages have been dropped inadvertently from the end of Section 2.1, at the bottom of page 4 in the published text, or that even a subsection dealing with the peculiar requirements for ICMPv6 error messages has been dropped, just leaving in the published text the single sentence at top of page 5. I expect the missing text to depict the general structure of the Message Body of ICMPv6 error messages with all related explanations, according to the above mentioned change note. Appendix A also states: - Removed the general packet format from Section 2.1. It refers to Sections 3 and 4 for packet formats now. This is not literally true. The general format *is* in Section 2.1. But in fact, it would be logical to have the (missing) specifications for error messages -- including the 4 lines of test on top of page 5 -- incorporated into (the start of) Section 3 (*before* the heading for Section 3.1.) instead of the end of Section 2.1. (2) possible textual improvement in the lower third of page 3, Section 2.1 says: The code field depends on the message type. It is used to create an additional level of message granularity. It should perhaps better say: The code field depends on the message type. It is used to create an additional level of message type granularity. ^^^^^^ (3) reference to old IPsec Architecture document Section 5.1, at the bottom of page 15, has been updated to point to the new IPsec Architecture document, RFC 4301, via the reference tag [SEC-ARCH]. But immediately below, in the first paragraph of Section 5.2, on top of page 16, the RFC text says: ICMP messages may be subject to various attacks. A complete discussion can be found in the IP Security Architecture [IPv6-SA]. [...] It remains unclear why the reference is made to the previous IPsec Architecture document, RFC 2401, in this case. In fact, RFC 4301 has simplified ICMP handling by the introduction of ICMP Type+Code as a Traffic Selector for the SPD, and therefore contains restructured text on ICMP message processing. Nevertheless, as far as I can see, RFC 4301 has not removed significant ICMP security related material from RFC 2401. Thus, IMHO there is no reason to explicitely refer to the obsoleted specification, RFC 2401 [IPv6-SA], instead of the current one, RFC 4301 [SEC-ARCH]. (4) more issues with references According to Appendix A, RFC 4443 has - Separated References into Normative and Informative. The latest RFC Authoring Internet draft revisions (cf. draft-rfc-editor-rfc2223bis-xx and draft-hoffman-rfc-author-guide-01) all have included the definition: Normative references specify documents that must be read to understand or implement the technology in the document, or whose technology must be present for the technology in the new RFC to work. [...] an informative reference might provide background or historical information to the reader. [...] The separation performed does not match this definition. (4a) RFC 4443 refers to RFC 792 and RFC 1122 to point out the analogy to ICMP[v4], but it is a self-contained specification, and ICMPv6 does not rely on the implementation of ICMP[v4] -- IPv6 only nodes are possible and even expected for the (far?) future. Therefore, the references [RFC-792] and [RFC-1122] should better have been placed into section 7.2, Informative References, instead of Section 7.1, Normative References. (4b) RFC 4443 also lists in Section 7.1, Normative References, the reference to its obsoleted predecessor, RFC 2463 [RFC-2463]. This is a fatal lock on the Standards Track for RFC 4443: RFC 4443 can *not* be advanced above the level of RFC 2463, if the written procedures are taken literally ! (Also, RFC 4443 contains all material from RFC 2463, and thus RFC 2463 is not needed to understand and/or implement RFC 4443.) Therefore, all references to obsoleted documents should be named Informative, and in the case of RFC 4443, [RFC-2463] should have been moved into Section 7.2 as well. (4c) The old IPv6 Addressing Architecture document, RFC 3513, has been replaced by RFC 4291, published more than 5 weeks before RFC 4443. Therefore, in Section 7.2 of RFC 4443, the Informative Reference [IPv6-ADDR] should be have been changed to point to RFC 4291 instead of the obsolete RFC 3513. (4d) When following my recommendations in item (3) above, the Informative Reference [IPv6-SA] is not needed any more; its role has been taken over by the Reference [SEC-ARCH]. (5) misleading change note The second bulleted item in Appendix A, - Corrected typos in Section 2.4, where references to sub-bullet e.2 were supposed to be references to e.3. apparently is not correct; it must have been introduced in the draft history, referring to a change in the draft. The references in RFC 2463 to sub-bullet (e.2) were correct. RFC 4443 has inserted a new item (e.2) into the list, incrementing the numbers of the previous sub-bullet (e.2) and all subsequent sub-bullets, thus making it necessary to increment the references. Perhaps, the latter had not been done in an early draft revision, and has then been corrected in a later one. Thus, the above change note should not have been included in RFC 4443.