In reviewing this ID prior to approving the IETF Last Call, I have the
following questions/comments:
> Rate limiting:
>
> The limit parameters (e.g., T or F in the above examples) MUST
> be configurable for the node, with a conservative default value
> (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100
> percent).
T= 0.5 seems fairly high. Why not .1 or .01 (on today's links).
It might also be useful to point out that having too much rate
limiting (in routers) causes problems for traceroute, since this has
been experienced in practice. Indeed, if routers rate limit to one
message every .5 seconds, today's traceroute would seem to become
unusable in practice. Indeed, even at .1 seconds, traceroute won't
hardly work anymore. I.e., the first probe will get trigger an ICMP
error, the second one (some 20-30 ms later) will not, due to rate
limiting, etc.
Would it be better to move away completely from fixed time intervals
and just say as a percentage of the link traffic? at least in the case
of routers?
So, question for the WG: Is the current text on this topic adequate,
or should it be revised?
security considerations could perhaps use some updating. It seems largely
unchanged relative to RFC 2463. Has nothing really changed in our
thinking here since 2463 came out?
It doesn't seem to note that ESP can do authentication only
now. Should ESP (w/o encryption) also be used if an SA exists?
1. ICMP messages may be subject to actions intended to cause the
receiver to believe the message came from a different source than
the message originator. The protection against this attack can be
achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH]
to the ICMP message.
add "in some cases"? There is an authorization questioned buried
here. How does one know that a particular SA is authorized to speak on
behalf of a particular IP address (or actually came from the message
originator)? Note, this issue is one of the reasons why IPsec doesn't
automatically solve the problem of authenticating MIPv6 BUs.
2. ICMP messages may be subject to actions intended to cause the
message or the reply to it go to a destination different than the
message originator's intention. The ICMP checksum calculation
provides a protection mechanism against changes by a malicious
interceptor in the destination and source address of the IP packet
carrying that message, provided the ICMP checksum field is
protected against change by authentication [IPv6-AUTH] or
encryption [IPv6-ESP] of the ICMP message.
seems like if you have AH/ESP, that check alone provides you the
additional protection. That it also covers the ICMP checksum is not
really relevant...
needs an IANA Considerations Section.
Should probably say something like "IANA guidelines for the assignment
of ICMP types and values are given in Section 7 of RFC 2780." This
assumes that the IANA section there is appropriate and doesn't need
updating.
It would also be appropriate to indicate what the IANA guidelines
should be for assigning new values for types defined in this
document. (Some probably would just say that IANA won't need to define
any, but some others probably need something more.)
One sentence abstract. RFC editor will likely say you can do better.
see http://www.rfc-editor.org/policy.html.
In the introduction (not the abstract), please add a line saying that
this document updates/replaces RFC 2463 (and add to references).
The reference section should separate the normative references from
those that are non-normative (see http://www.rfc-editor.org/policy.html).
Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
