[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Last call comments for draft-ipngwg-icmp-v3-05



Various points...

Section 1:  The first sentence (The Internet Protocol, version 6 (IPv6) is a
new version of IP.)  is not really useful for an ongoing standards document,
and could be deleted without loss.

Section 2.1 would be better split into three sections and reordered - it
covers three things rather than just the general message format:

2.1 Message General Format

   Every ICMPv6 message is preceded by an IPv6 header and zero or more
   IPv6 extension headers. The ICMPv6 header is identified by a Next
   Header value of 58 in the immediately preceding header.  (NOTE: this
   is different than the value used to identify ICMP for IPv4.)

   The ICMPv6 messages have the following general format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Message Body                          +
      |                                                               |

   The type field indicates the type of the message. Its value
   determines the format of the remaining data.

   The code field depends on the message type. It is used to create an
   additional level of message granularity.

   The checksum field is used to detect data corruption in the ICMPv6
   message and parts of the IPv6 header.

   ICMPv6 messages are grouped into two classes: error messages and
   informational messages.  Error messages are identified as such by
   having a zero in the high-order bit of their message Type field
   values.  Thus, error messages have message Types from 0 to 127;
   informational messages have message Types from 128 to 255.

2.2 ICMP Messages Defined in the Document

   This document defines the message formats and functions for the following
ICMPv6
   messages:

        ICMPv6 error messages:

             1    Destination Unreachable      (see section 3.1)
             2    Packet Too Big               (see section 3.2)
             3    Time Exceeded                (see section 3.3)
             4    Parameter Problem            (see section 3.4)

        ICMPv6 informational messages:

             128  Echo Request                 (see section 4.1)
             129  Echo Reply                   (see section 4.2)

2.3 Format of ICMP Error Messages

   The subclass of ICMPv6 messages used for reporting errors, i.e.,
   those with a Type value between 0 and 127, inclusive, all have the
   following, more specific format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  type-specific data (32 bits)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +                as will fit without the ICMPv6 packet          +
      |                exceeding the minimum IPv6 MTU [IPv6]          |

(Renumber remaining subsections of 2).

Section 2.4 [current numbering scheme]

Many implementations implement the ability to suppress responses to pings
and some error messages by policy choice.  Is this something that might be
documented given that it is considered to be a matter of security?

Section 2.4(d):

There is another related circumstance in which it may not be possible to
determine the protocol or port numbers: if the errored packet has an ESP, it
would be necessary to decrypt the packet to determine both.  This may not be
possible either because the packet is truncated or because the encryption
algorithm does not have the necessary state needed to decrypt this packet.
This situation may become much more relevant than the truncation of long
headers in future.

Section 2.4(e) - Editorial nit:
         (e.4) a packet sent as a link-layer multicast, (the exception
                                                             ----------
                                                             exceptions
               from e.3 applies to this case too), or
                        -------
                        apply
Similarly for (e.5)

Sections 3.1-3.4:

Given the caveat in Section 2.4(d)(and the extra, possibly more common case,
identified above), the comments on the individual messages about informing
the upper layer protocol should be qualified accordingly.  This affects the
last paragraphs of sections 3.1-3.4 - suggest changing to: 

   A node receiving the ICMPv6 [xxx error] message MUST
   notify the upper-layer process if the relevant process can be
   identified (see Section 2.4(d)).


Section 3.4 Parameter Problem message

It might be useful to add a note that (presumably) Code 0 is the fallback
case in case neither of the other two fit the bill.

The description of code 2 (IPv6 Option) could be improved - it is
(presumably) about options in hop-by-hop and destination extension headers
from the base standard.  Since, in principle, other headers of the same kind
could be defined, would this code be used for options in those headers?
----------------------------------------------------------------------------
------

Elwyn B Davies

        Routing and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO Office, Portfolio Integration		Solutions Ready


        Nortel Networks plc			Email:
elwynd@xxxxxxxxxxxxxxxxxx
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    			Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------