Extended ICMP to Support Multi-Part Messages
draft-bonica-internet-icmp-16

IANA Last call Comments:

As described in the IANA Considerations section, the IANA
understands that it must create a new ICMP registry for
ICMP Extension Objects.

IANA proposes that the new ICMP registry for ICMP Extension
Objects be a subregistry of the ICMP registry located at:

http://www.iana.org/assignments/icmp-parameters

That new registry will contain ICMP Extension Object
Class-Num numbers. For each Class-Num there may be class
subtypes.

The IANA understands that for each Class-Num number there
will be an 8-bit number, a Object Class Description and a
reference to the document that establishes the Object Class.
For each class subtype there will be an 8-bit number, a
Subtype description and a reference to the document that
establishes the Subtype.

No initial registrations are being made in this new
registry.

Future registrations of Class-Num numbers are made on a
first-come, first-serve basis. The rules for future
registration of subtypes will be created by the document
that registers the associated Class-Num number.

Class-Num numbers in the range 0xF7 - 0xFF are reserved
for private use and are not maintained by IANA.

IANA understands that the creation of this registry is
the only action required by this document.

[Ballot discuss]
Section 13.1., paragraph 5:
>    [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
>              Address Translator (Traditional NAT)", RFC 3022,
>              January 2001.

  DISCUSS: Is a DOWNREF (PS->Informational).

[Ballot discuss]
I assume this formally updates RFC 792 and 4443. If so, this must be stated in the Abstract and an Updates (if approved): header.

[Ballot comment]
You say the "impact of this issue is considered to be minimal because many ICMP messages are discarded for". This really worried me. What you are saying here is the "the impact of turning off all ICMP is minimal" - I doubt you really mean that.

[Ballot discuss]
I'm concerned about the interaction of this and NATs. The NATs typically rewrite the checksums and it seems like a NAT that was not aware of this will do it a way that causes them to be invalid and then a stack that does support this will likely discard this. I could easily be confused about this - I'm not sure it is a problem - I just want to be convinced that it is not a problem.

Is the 8 bits enough for the length field? Would be nice if the document explained this. Again, I suspect the document is fine here, it was just not clear to me if it is o is not and I want to understand.

The security section says that software needs to check the ICMP message but does not say what to do if it fails, I presume you mean to discard the ICMP message but that needs to be clarified.

This document needs to define the IANA registry.

Read through the entire document again, and looked at the list
discussion. Its ready to go.

Someone should probably hold a discuss on the IANA
considerations, which are too relaxed, but we can
take care of that later.

Based on discussion in the INT area meeting at IETF-66, we need to add IPv6 support to this draft and improve the draft to satisfy PS quality criteria. ADs to work with the authors on the latter.

Reviews requested and provided from Joe Touch, Pekka Savola, and Pekka Nikander.
AD review performed and posted to the int-area list on June 4, 2006. Review points out two technical issues. We also guidance from the group regarding IPv6 side of this functionality, after it was clear that a major vendor had already implemented this for IPv6.

Taken on for an AD review. Comments received from reviewers Pekka Savola, Pekka Nikander, and Joe Touch. Information about IPv6 implementation status received from Mark Townsley and Ron Bonica.