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

From: [email-masked]
Date: Fri, 5 Nov 2004 15:32:09 -0600

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

---

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 8 Nov 2004 23:24:30 +0100

Hi Mukesh.

Responses in-line...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 05 November 2004 21:32
> To: Davies, Elwyn [HAL02:0S00:EXCH]; [email-masked]; 
> [email-masked]
> Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05
> 
> 
> Hi Elwyn,
> 

=> Fine.

> Do you (or anyone else in the WG) strongly feels that

=> 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, ...)
> Do you have anything specific to add about this in the

=> 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)?

> Good point.  Here is the proposed replacement text.  Let me

=> that seems good.

<<snip>>

> not adding anything extra.

Echoing the wording in 3.1...
"Codes 1 and 2 are more informative subsets of Code 0."
> 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

---

From: [email-masked]
Date: Mon, 8 Nov 2004 18:10:12 -0600

Elwyn,

Responses inline..

> => 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, ...)

But won't that create inconsistency within the document?
People will be wondering about why this section was 
broken into the 3rd level?  Currently, we don't have 
any section with 3rd level of sub-sections.

> 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)?

Policy (ACL or filters) can be used to drop "any" packets.
IMHO, if we start adding disclaimers about the ACLs or 
filters, a disclaimer will be needed in almost every spec.
Right?

Please propose the specific modification (text and 
location) and then we can have a consensus call about if
we need to add it in the draft or not.

> "Codes 1 and 2 are more informative subsets of Code 0."

Ok if this makes it clearer, I will add this to the next rev.

> 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

Ok I will add a reference tag to make it clearer.

Regards
Mukesh