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

["Elwyn Davies" <elwynd@xxxxxxxxxxxxxxxxxx>]

Hi Mukesh.

Responses in-line...

> -----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; 
> ipv6@xxxxxxxx
> 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.

=> Fine.


> 
> > 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 
> packet.
> ==========
> 

=> that seems good.

<<snip>>

> 
> > 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.

Regards,
Elwyn
> 
> Regards
> Mukesh
> 
> 

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