icmpv6-v3 comments

[Pekka Savola <pekkas at netcore.fi>]

Thanks for the update.  There are a couple of issues which probably require
a bit of discussion; some others should be more straightforward
modifications.  Comments below.

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

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

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?

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

    (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/ ?

   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?

  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.

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

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

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

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/


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings




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