[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last call comments for draft-ipngwg-icmp-v3-05
> -----Original Message-----
> From: Mukesh.K.Gupta@xxxxxxxxx [mailto:Mukesh.K.Gupta@xxxxxxxxx]
> Sent: 05 November 2004 21:32
> To: Davies, Elwyn [HAL02:0S00:EXCH]; hinden@xxxxxxxxxxxxxx;
> Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05
> 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 ??
=> I see that the renumbering might be a nuisance.. i still think the
section would be clearer reordered. i would be happy to divide 2.1 into
three 3rd level sections as suggested (ie 2.1.1, ...)
> > 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 ?
=> The spec already mentions policy in connection with error messages so we
can't totally punt on the 'out of scope' grounds;-). Is an implementation
of ICMP that (for example) doesn't generate Echo Responses when it receives
Echo Requests under some circumstances compliant with the standard or not?
There is a 'MUST' in 4.1. Or are we relying on statements elsewhere that
the packets can be filtered (and so we need not generate them in the first
place) - like node requirements (although this says nothing about ACLs and
filtering at present)?
> > 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
=> that seems good.
> > 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.
Echoing the wording in 3.1...
"Codes 1 and 2 are more informative subsets of Code 0."
> > 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 ?
=> Ok - forget the hypothetical futures. But 'IPv6 options' is not actually
*terminology* called out in RFC2460 although it is defined there (maybe it
ought to have been). I think putting a ref to RFC2460 (and maybe the
section) in at least one of the three places (2.4 (e.3), 3.4, 5.2 (5))where
'IPv6 option' is mentioned would be helpful.
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6