Document: draft-ietf-ipngwg-icmp-v3-06.txt 
Trigger: IESG Telechat, 2005-01-20
Reviewer: Elwyn Davies
AD: Margaret Wasserman
Review Date: 14 January 2005

Intended status: Standards Track (Draft Standard level)

Summary:
This document appears to be in reasonable shape for approval as Draft
Standard.
There are a number of places that some clarification of what should
happen is (IMO) needed, as well as some wording improvements.  I
suspect this is at least partly due to the derivation of this document
from prior IPv4 work, where some functionality is different, the
'obviousness' of the specification in the light of this derivation and
the venerable age of the original document. (This review is a slightly
updated version of the one I did for IETF LC - extra comments
reflecting discussion of Section 2.2 - source address selection -
since the LC review came out).

Conclusion:
IMO the document needs technical revision to sort out the source
address selection issue (section 2.2 and related points).  Also since
this is one of the fundamental documents standardizing the IPv6
protocol, the wording relating to the various ICMPv6 sub-protocols
should be crystal clear (section 2).  The opportunity should be taken
to clear up the various other symptoms of advancing age shown by the
document.

Review:
The draft is in reasonable shape for progression to draft standard,
however I have identified a number of areas where there are some
corner cases and need for clarification of wording.  Part of this
stems from the venerable age of the original document: IPv6 and ICMPv6
have moved on a long way since this document was originally written
and there have been changes overall that are not fully reflected in
this document.

Substantive issues:
===================
Section 2: A particular issue is the proliferation of sub-protocols of
ICMPv6: There are statements about ICMPv6 being 'fully implemented' -
the exact meaning of this statement is unclear in the face of the
existence of the sub-protocols which use ICMPv6 message structure.
Does 'fully implemented' (Section 2, para
1) mean just the stuff in this draft or all the sub-protocols - some
   of the sub-
protocols are not necessarily mandatory (at least parts of Mobile
IPv6, SEND).

Section 2.1: The definition of the error message packet format does
not explain the relationship between inclusion of the start of the
offending packet and allowing the packet originator to notify the
packet sender.  This means that the terms 'upper-layer protocol' and
'upper-layer process' appear without explanation later in the
document.  I suggest a paragraph something like:

    Inclusion of, at least, the start of the invoking packet is
    intended to allow the originator of a packet that has resulted in
    an ICMPv6 error message to identify the upper-layer protocol and
    process that sent the packet.
at the end of Section 2.1 would help.

Section 2.2(b): The term 'anycast group' is not used elsewhere in the
mainstream IPv6 RFCs.  All the referenced documents refer to 'anycast
addresses'.  The term is used in the title of the magma WG but
actually is not used in any of their documents either!  Hence: s/sent
to a multicast or anycast group in which the node is a member/sent to
a multicast group of which the node is a member or an anycast address
that is implemented by the node/.  

Section 2.2: I have noted
previously (in connection with Neighbor Discovery) that the source
address selection rules can lead to situations in which the scopes of
the source and destination addresses are (legitimately) mismatched.
It should be noted here that such packets MUST not be dropped by the
packet transmission mechanisms in the node. Suggest adding the
following to the end of the section:

   Under some circumstances the scope of the chosen source address may 
   not match the scope of the destination address.  ICMPv6 messages MUST NOT
   be dropped in the node that generates the ICMPv6 packet on account of 
   such a mismatch.

However, there are also circumstances under which this mismatch can
occur and is unhelpful.  For example, if an interface on a router only
has a link local address, rule 2.2(b) may result in an ICMPv6 response
to a problem with a site or global scope multicast destination address
being sent with a link-local scope source address.  In the Neighbor
Discovery cases, this is not a problem because all messages are link
local anyway, but in other cases the ICMPv6 message may have to
traverse some routers on its way back to the originator of the
offending message: it is inconvenient to have to make special cases
for scope checking here, and the message is much less helpful when it
arrives back at the originator.  The problem could be considered to be
a misalignment between rules 2.2(b) and 2.2(c): some thought needs to
be put into what is the best solution, but the scope of the ICMPv6
destination address and the nature of the sub- protocol need to be
taken into account - 2.2(c) could be allowed to override 2.2(b) if the
result was unhelpful in the way described, and a global unicast
address belonging to the node could be used in place of the link local
if the packet is expected to traverse other routers.

Sections 2.2(c) and 2.2(d): There has been further discussion on the
mailing list, since I reviewed this document for IETF LC, of whether
2.2(c) is ever implemented, and suggesting that it could be deleted.
I would suggest that this is not a good idea, but that 2.2(d) does
need improving to avoid a link local address being used
inappropriately as discussed regarding 2.2(b).

Section 4.2, para 3 of Description: The potential issue with
link-local source addresses is reiterated here and needs to be cleaned
up if 2.2 is altered.

Section 2.4(a): Three points:
1. It is worth clarifying that this applies only at the destination.
2. The term upper layer needs expansion: as the draft stands, this is
   first mention of 'upper layer' {See above comment on Section 2).
3. The caveat of 2.4(d) applies.

Suggest rewording 2.4(a) as follows:
    (a) If an ICMPv6 error message of unknown type is received at its 
        destination, it MUST be passed to the upper-layer process that 
        originated the packet that caused the error, where this can be 
        identified (see Section 2.4(d)).


Editorial Nits/Semi-substantive:
================================

Section 1, para 3: s/Routing and Addressing specification/Addressing
Architecture specification/ (The referenced document has been retitled
somewhere along the line).

Section 2.1: This section contains three distinct topics:
1. Grouping of ICMPv6 messages (error messages and informational
   messages) and list of messages defined in this document.
2. General ICMPv6 packet format (starting at 'Every ICMPv6
   message...')
3. Specialisation of general packet format for error message group
   (starting at 'The subclass of ICMPv6...').

I have previously commented that this section should be split up but
the authors have resisted (on plausible grounds, partly related to the
venerable age of the document).  However, the current arrangement is
not helpful to a naive reader: The first topic contains a forward
reference to the 'Type' field which is not defined until the second
topic.  I think this problem could be solved(without section
renumbering as I previously suggested) by reordering the topics in the
order (2,1,3).

Section 2.4(f),para 4: s/traceroute/traffic resulting from a
traceroute process/

Section 2.4(f), para 5: s:small/mid-:small- or mid-:

Section 2.1, last para: The draft now lists more message types than
are actually defined in the document (some were added after this para
was drafted I think): Suggest rewording as:
   The following sections describe the message formats for the 
   ICMPv6 error message types 1 through 4 and informational message 
   types 128 and 129 listed in Section 4.1.

Sections 3 and 4: Section 3.3 contains the following (last para):
   The rules for selecting the Source Address of this message are
   defined in section 2.2.
The other sub-sections of Sections 3 and 4 don't mention source
address selection.  Suggest either this comment be moved to the
beginning of Section 3 and added to Section 4 with 'this message'
replaced by 'these messages'.  Alternatively, a note on source
selection can be added in the 'IPv6 Fields' part of each sub-section.

Section 4.1: Data field specification: Is it desirable to explicitly
note that there is no limit on the amount of data?  Much of the rest
of the document limits ICMPv6 messages to the guaranteed minimum MTU,
but these messages are intentionally allowed to be larger. Presumably
even needing jumbo packet support.