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:
[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
