Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
draft-ietf-ipngwg-icmp-v3-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Allison Mankin |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Brian Carpenter |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Alex Zinin |
2005-08-16
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-08-11
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-08-11
|
07 | Amy Vezza | IESG has approved the document |
2005-08-11
|
07 | Amy Vezza | Closed "Approve" ballot |
2005-08-11
|
07 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-08-10
|
07 | Allison Mankin | [Ballot comment] ----- New comment I've cleared my Discuss. The document addressed my concern. But it did so some time back and the shepherding was … [Ballot comment] ----- New comment I've cleared my Discuss. The document addressed my concern. But it did so some time back and the shepherding was by the editor and the correspondence was lost. The chairs should consider close shepherding rather than expecting the Discussing ADs to keep documents not in their area in detailed context over many months. ----- Old comment below - still concerned, but given up on... It's unusual to have a document recycle at Draft Standard. The list of changes since 2460 includes testable aspects; just to pick from their list: find the embedded invoking packet even when the type is not recognized and handle the new Time Exceeded Code 1. This is the result of a no effort in looking. I'd be interested to hear that it was evident there are multiple implementations, and the consideration was made that an updated implementation report was not needed. |
2005-08-10
|
07 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin |
2005-07-28
|
07 | Brian Carpenter | [Ballot comment] Nit: The IANA considerations cite [RFC 3667] but it isn't in the references, and anyway it's replaced by 3978. Editorial comments … [Ballot comment] Nit: The IANA considerations cite [RFC 3667] but it isn't in the references, and anyway it's replaced by 3978. Editorial comments from Elwyn Davies: This seems to have fixed all my comments, however the removal of the error message format from s2.1 (which was more than I suggested) has left the last paragraph of 2.1 looking very exposed - it is strictly not needed here anymore.. I would suggest either deleteing it altogether or adding most of the text to the end of 2.4(c), viz. This 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. ARGHH! I just realised that the paragraph (3rd from the end) in s2.1 starting 'Type value 255' which talks about future expansion should be talking about type values 255 and 127 now. Thus s/Type value 255 is/Type values 127 and 255 are/ s/type equals 255/type equals 127 or 255/ Editorial nits: s1: s/chieve/achieve/ |
2005-07-15
|
07 | Alex Zinin | [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin |
2005-07-15
|
07 | Brian Carpenter | [Ballot comment] Editorial comments from Elwyn Davies: This seems to have fixed all my comments, however the removal of the error message format from s2.1 … [Ballot comment] Editorial comments from Elwyn Davies: This seems to have fixed all my comments, however the removal of the error message format from s2.1 (which was more than I suggested) has left the last paragraph of 2.1 looking very exposed - it is strictly not needed here anymore.. I would suggest either deleteing it altogether or adding most of the text to the end of 2.4(c), viz. This 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. ARGHH! I just realised that the paragraph (3rd from the end) in s2.1 starting 'Type value 255' which talks about future expansion should be talking about type values 255 and 127 now. Thus s/Type value 255 is/Type values 127 and 255 are/ s/type equals 255/type equals 127 or 255/ Editorial nits: s1: s/chieve/achieve/ |
2005-07-15
|
07 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter |
2005-07-14
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-07-14
|
07 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-07.txt |
2005-06-03
|
07 | Brian Carpenter | [Ballot discuss] Picking up Harald's DISCUSS. See review by Elwyn Davies down in the comments. |
2005-06-03
|
07 | Brian Carpenter | [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter |
2005-01-21
|
07 | (System) | Removed from agenda for telechat - 2005-01-20 |
2005-01-20
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2005-01-20
|
07 | Harald Alvestrand | [Ballot comment] Reviewed by Elwyn Davies, Gen-ART Complete review stored as comment. |
2005-01-20
|
07 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2005-01-20
|
07 | Harald Alvestrand | [Ballot discuss] Elwyn Davies (review in comments) has several points in his review that seem to require technical clarification in the document. I would like … [Ballot discuss] Elwyn Davies (review in comments) has several points in his review that seem to require technical clarification in the document. I would like to see these addressed before approval. |
2005-01-20
|
07 | Harald Alvestrand | [Ballot Position Update] Position for Harald Alvestrand has been changed to Discuss from Undefined by Harald Alvestrand |
2005-01-20
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2005-01-20
|
07 | Michelle Cotton | IANA Comments: Upon approval of this document the IANA will update the registration rules for the ICMPv6 Parameters. IANA will also update the following registry … IANA Comments: Upon approval of this document the IANA will update the registration rules for the ICMPv6 Parameters. IANA will also update the following registry per the IANA Considerations section of this document: http://www.iana.org/assignments/icmpv6-parameters |
2005-01-20
|
07 | Allison Mankin | [Ballot comment] It's unusual to have a document recycle at Draft Standard. The list of changes since 2460 includes testable aspects; just to pick from … [Ballot comment] It's unusual to have a document recycle at Draft Standard. The list of changes since 2460 includes testable aspects; just to pick from their list: find the embedded invoking packet even when the type is not recognized and handle the new Time Exceeded Code 1. This is the result of a no effort in looking. I'd be interested to hear that it was evident there are multiple implementations, and the consideration was made that an updated implementation report was not needed. |
2005-01-19
|
07 | Allison Mankin | [Ballot discuss] Couple easy to fix things, but they add up: 1. IPSec processing considerations about ICMP are enough different in the bis ESP and … [Ballot discuss] Couple easy to fix things, but they add up: 1. IPSec processing considerations about ICMP are enough different in the bis ESP and AH specs that I think this document should update to require these (just approved). 2. The document includes a ref to RFC 2780 but never mentions it. In the IANA considerations, it needs to state that it obsoletes 2780's IANA instructions on ICMPv6. The RFC Editor needs to be told that this RFC updates 2780, as well as obsoleting the previous ICMPv6 spec. I think the new IANA Considerations are great. We should make sure the loose ends are tied. |
2005-01-19
|
07 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from Undefined by Allison Mankin |
2005-01-19
|
07 | Allison Mankin | [Ballot comment] The IANA Considerations obsolete normative IANA Considerations for ICMPv6 that were set in RFC 2780, and this document needs to state this … [Ballot comment] The IANA Considerations obsolete normative IANA Considerations for ICMPv6 that were set in RFC 2780, and this document needs to state this - and the RFC Editor needs to record that the document updates RFC 2780, as well as obsoleting the previous ICMPv6 RFC). I like the new IANA Considerations btw, just want to make sure we tie up the loose ends. |
2005-01-19
|
07 | Alex Zinin | [Ballot discuss] > 3.1 Destination Unreachable Message For security reasons, could the spec say that the implementations MUST allow sending of Unreachables to be disabled, … [Ballot discuss] > 3.1 Destination Unreachable Message For security reasons, could the spec say that the implementations MUST allow sending of Unreachables to be disabled, preferably on a per-interface basis. |
2005-01-19
|
07 | Allison Mankin | [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin |
2005-01-19
|
07 | Alex Zinin | [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin |
2005-01-19
|
07 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-01-19
|
07 | Harald Alvestrand | Review by Elwyn Davies, Gen-ART Review Date: 14 January 2005 Intended status: Standards Track (Draft Standard level) Summary: This document appears to be in reasonable … Review by Elwyn Davies, Gen-ART 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. |
2005-01-19
|
07 | Harald Alvestrand | [Ballot comment] Reviewed by Elwyn Davies, Gen-ART Complete review stored as comment. I have not yet decided my position. |
2005-01-19
|
07 | Harald Alvestrand | [Ballot Position Update] New position, Undefined, has been recorded for Harald Alvestrand by Harald Alvestrand |
2005-01-17
|
07 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2005-01-16
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2005-01-15
|
07 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2005-01-06
|
07 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-01-04
|
07 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman |
2005-01-04
|
07 | Margaret Cullen | Placed on agenda for telechat - 2005-01-20 by Margaret Wasserman |
2005-01-04
|
07 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2005-01-04
|
07 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2005-01-04
|
07 | Margaret Cullen | Created "Approve" ballot |
2005-01-03
|
07 | Margaret Cullen | State Change Notice email list have been change to , , from , , |
2005-01-02
|
07 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-12-13
|
07 | Amy Vezza | Last call sent |
2004-12-13
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-12-12
|
07 | Margaret Cullen | State Change Notice email list have been change to , , from , |
2004-12-12
|
07 | Margaret Cullen | State Changes to Last Call Requested from Publication Requested by Margaret Wasserman |
2004-12-12
|
07 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-12-12
|
07 | (System) | Ballot writeup text was added |
2004-12-12
|
07 | (System) | Last call text was added |
2004-12-12
|
07 | (System) | Ballot approval text was added |
2004-12-09
|
07 | Margaret Cullen | Shepherding AD has been changed to Margaret Wasserman from Thomas Narten |
2004-12-09
|
07 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-11-29
|
07 | Barbara Fuller | State Changes to Publication Requested from AD is watching::AD Followup by Barbara Fuller |
2004-11-29
|
07 | Barbara Fuller | [Note]: 'Comments�sent�to�mailing�list�2002-02-10.�New�ID�needed. No response from WG in ages...' added by Barbara Fuller |
2004-11-22
|
06 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-06.txt |
2004-10-22
|
05 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-05.txt |
2004-06-03
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-06-03
|
04 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-04.txt |
2004-02-16
|
03 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-03.txt |
2003-06-23
|
07 | Thomas Narten | State Changes to AD is watching :: Revised ID Needed from AD is watching by Narten, Thomas |
2003-06-23
|
07 | Thomas Narten | from AD Evaluation by Narten, Thomas |
2002-10-22
|
07 | Thomas Narten | State Changes to AD Evaluation -- New ID Needed from AD Evaluation -- External Party by narten |
2002-06-11
|
07 | Thomas Narten | back in WG hands, per mail to ipng list February 10, 2002 |
2002-06-11
|
07 | Thomas Narten | A new comment added by narten |
2002-06-11
|
07 | Thomas Narten | State Changes to New Version Needed (WG/Author) from Pre AD Evaluation … State Changes to New Version Needed (WG/Author) from Pre AD Evaluation by narten |
2002-05-15
|
07 | Stephen Coya | Draft Added by scoya |
2001-11-29
|
02 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-02.txt |
2001-07-23
|
01 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-01.txt |
1999-06-29
|
00 | (System) | New version available: draft-ietf-ipngwg-icmp-v3-00.txt |