RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", March 2006

Note: This RFC has been updated by RFC 4884

Errata ID: 88
Status: Held for Document Update
Type: Technical
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.

Notes:

from pending

Report New Errata