Hi Elwyn, Sorry for responding late. Please see my comments inline..
> 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. Sounds reasonable. I will take it off in the next rev. > Section 2.1 would be better split into three sections and > reordered - it covers three things rather than just the > general message format: I understand your concern but IMHO this should not be done at this stage. The reasons is that we will have to renumber all the sections in section 2 and then we will have to fix all the cross references. If we miss to correct a cross reference, it will be bad. Also I have seen people referring to sections of RFCs in code and changing the section numbers will create some confusion there too. Do you (or anyone else in the WG) strongly feels that we should change this ?? > 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? I think, policy issues are out of the scope of this spec. Implementations allow to suppress all the protocols using policies (ACLs). So ICMP is no different. Do you have anything specific to add about this in the spec ? > 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. Good point. Here is the proposed replacement text. Let me know what you think.. ========== In the cases where it is not possible to retrieve the upper-layer protocol type from the ICMPv6 message, the ICMPv6 message is silently dropped after any IPv6-layer processing. One example of such a case is an ICMPv6 message with unusually large amount of extension headers that does not have the upper-layer protocol type due to truncation of the original packet to meet the minimum IPv6 MTU [IPv6] limit. Another example of such a case is an ICMPv6 message with ESP extension header where it is not possible to decrypt the original packet due to either truncation or the unavailability of the state necessary to decrypt the packet. ========== > > 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) Will correct it in next rev. > 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)). Will correct it in next rev. > 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. I think it is obvious from the descriptions of the codes. So unless you feel there is a strong need, I will prefer not adding anything extra. > 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? I think, it is consistent with the IPv6 base spec. The base spec talks about options in section 4.2. If other headers of the same kind are defined in future, this code will apply to the options inside them too. I am not able to see what exactly you want to add/modify here ? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
