[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: icmpv6-v3 comments



Pekka,

Sorry that I am replying to this mail so late ! and Thanks
for reviewing the draft thoroughly. Please see my comments
inline..

> Process issue: Draft Standard may not refer normatively to
> specifications of lower standardization status.  See
> draft-ymbk-downref-01.txt for a bit of discussion.  That is,
> IPv6-ADDR, PMTU and IPsec documents are unsuitable for normative
> references.  So, some wiggling around will be needed..

Well, the draft draft-ymbk-downref-01.txt says 
====
   In the case of protocols, a reference is normative if it refers to
   packet formats or other protocol mechanisms that are needed to fully
   implement the protocol in the current specification.  For example, if
   a protocol relies on IPsec to provide security, one cannot fully
   implement the protocol without the specification for IPsec also being
   available; hence, the reference would be normative.
====

As ICMPv6 proposes to use IPsec for security, according to the above
paragraph, IPsec documents should be normative.  So how do we resolve
this ?

> ==> should add IPR and copyright boilerplates at the end.

Will do in the next draft.

> 2.2 Message Source Address Determination
> 
>    A node that sends an ICMPv6 message has to determine both 
> the Source
>    and Destination IPv6 Addresses in the IPv6 header before 
> calculating
>    the checksum.  If the node has more than one unicast 
> address, it must
>    choose the Source Address of the message as follows:
> [...]
> 
> ==> should this "must" (and the following statements) be appropriately
> uppercased?

Yeah, I think so.  Will take care of this in the next draft too.

>     (c) If the message is a response to a message sent to an address
>         that does not belong to the node, the Source Address should be
>         that unicast address belonging to the node that will be most
>         helpful in diagnosing the error. For example, if the message is
>         a response to a packet forwarding action that cannot complete
>         successfully, the Source Address should be a unicast address
>         belonging to the interface on which the packet forwarding
>         failed.
> 
> ==> not sure if this has been implemented, so the usability 
> of this generic rule seems questionable.

Are you proposing to remove this ?  

I think, all the implementations use the IP address of the egress 
interface for the ICMP packet as the source address of the packet.

The above paragraph suggests to use the IP address of the interface
on which the packet was supposed to be forwarded.  Now if we are 
unable to forward the packet, how would we know which interface it
was supposed to go out on :-/  So which IP address should be used
in that case !

> 
>     (c) Every ICMPv6 error message (type < 128) includes as much of the
>         IPv6 offending (invoking) packet (the packet that caused the  
>         error) as will fit without making the error message packet  
>         exceed the minimum IPv6 MTU [IPv6].
> 
> ==> s/includes/MUST include/ ?

Will correct this..

>    If the reason for the failure to deliver can not be mapped 
> to any of
>    the specific codes listed above, the Code field is set to 3.  The
>    example of such cases are inability to resolve the IPv6 destination
>    address into a corresponding link address, or a 
> link-specific problem
>    of some sort.
> 
> ==> reasons with codes 4, 5, and 6 are below this sentence.  
> Maybe those
> paragraphs should be moved up, earlier in this section, or 
> the language here
> reworded?

Actually, I wanted to keep the description of the codes in the numerical
order.  If this description sounds confusing, could you suggest how to 
re-word it such that it is clearer without moving the descriptions of 
4, 5 and 6 before this ?

>   If the reason for the failure to deliver is that packet with this
>    source address is not allowed due to ingress or egress filtering
>    policies, the Code field is set to 5.
> 
>    If the reason for the failure to deliver is that the route to the
>    destination is a reject route, the Code field is set to 6.  This may
>    occur if the router has been configured to reject all the traffic for
>    a specific prefix.
> 
> ==> as has already been mentioned, these two rules are in fact a more
> specific, more informative subsets of code 1 -- 
> administratively prohibited. 
> I persnally don't see much of an objection for adding these 
> codes, but it
> would IMHO make useful to spell this out explicitly here.

Would it help to add the following text:
====
Codes 5 and 6 are more informative subsets of code 1.  Thus code 1
MAY be used in place of code 5 and 6.
====

>    It SHOULD be possible for the system administrator to configure a
>    node to ignore any ICMP messages that are not authenticated using
>    either the Authentication Header or Encapsulating Security Payload.
>    Such a switch SHOULD default to allowing unauthenticated messages.
> 
> ==> has this even been implemented anywhere?  could maybe be 
> deleted?  This is completely unpractical, e.g., just consider 
> PMTU packets -- there is no way you'll ever be able to set 
> up security associations with everyone in the Internet to be 
> able to accept the packets :)

I completely agree with you that this is unpractical but it does
make sense to a completely paranoid administrator.  Whoever turns
this option ON might not be interested in using PMTU.  I don't
see any harm in keeping it.  We can make it a MAY from SHOULD.

What say ??

>    [IPv6-ADDR]  Hinden, R., S. Deering, "IP Version 6 Addressing
>                 Architecture", RFC2373, July 1998.
> 
> ==> update.  Note that this is not Draft Standard yet.  As there is 
> nothing in IPv6-ADDR that's required by that spec, it could be 
> informative as well.

Makes sense.  I will move this to informative.

>    [PMTU]       McCann, J., S. Deering, J. Mogul, "Path MTU Discovery
>                 for IP version 6", RFC1981, August 1996.
> 
>    [IPv6-SA]    Kent, S., R. Atkinson, "Security Architecture for the
>                 Internet Protocol", RFC1825, November 1998.
> 
> ==> These, and IPsec RFCs are PS's at the moment -- can't refer.  
> IPsec ones are being revised though, if that helps any.

As I referred from the draft-ymbk-downref-01.txt, IPsec RFCs should
be normative.  So what should we do now ?

Also should we refer to the old IPsec RFCs or we should refer to the
updated ones ?  If we want to refer to updated ones, how do we refer
to them because they are still drafts.

> editorial
> ---------
> 
>    (f) Finally, in order to limit the bandwidth and forwarding costs  
>         incurred sending ICMPv6 error messages, an IPv6 node 
> MUST limit 
>  
> ==> s/incurred/incurred by/

Will take care of this in the next rev.

Thanks again for reviewing the draft.

Regards
Mukesh

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