Hi Elwyn,
I am trying to address your comments in the IESG
review of the ICMPv6 draft. Please see my comments
inline. Please note that I am on vacation in india
for a month. So I might not be able to respond to
your replies for a while :)
Sorry if the message is not very well formatted.
Right. My question was an attempt to see how many implementations
support IPSec AH today.
We have one that supports IPsec AH for IPv6 and I am pretty sure
that there are many more :)
IETF IPv6 working group mailing list
Fred,
Let me make sure that I understand your preference clearly.
Are you saying that we should leave the section 2.4 (f) as
it was in RFC 2463 ?
I think, we already discussed a lot about this and decided
that we will remove the Timer-based and the Bandwidth-based
rate limiting mechanisms and
Multiplying the ICMP rate a node originates by the number of
interfaces should not make much of a difference
operationally, and if
a router has many interfaces it also has more paths to spread this
traffic over. On the other hand, for a strictly software based
router, having to
I think the discussion about the ICMPv6 rate limiting is
going in all directions and we are not going anywhere
near the consensus. This email is my effort to bring
some consensus on the issues.
I think everyone agrees that per-interface configuration
would be a perfect solution and will provide
Fred,
That's definitely out of scope of this *protocol* specification.
They're just forwarded IP packets. More often than not, the router
doesn't even know it's ICMPv6 (because it just looks at the
destination address), and *cannot* even know that (e.g., there are
extension headers,
Thomas,
Comments inline..
1. The IANA should allocate and permanently register new ICMPv6 type
codes from IETF RFC publication. This is for all RFC types
including standards track, informational, experimental status,
etc.
With the IESG approval of
Thomas,
IMO, what you should do is write an ID, and take it to the appropriate
WG. If you can't find interest, you probably should drop the idea.
If the WG accepts my idea or IESG approves it as an individual
draft, it becomes an internal (for IETF) request and then point
3 of section 6.1 does
Pekka,
Do we need two implementations even for SHOULD items ?
I don't know of any. I don't claim to know a lot of
ICMP implementations though ;)
If we don't have 2 implementations, what should we do ?
Should we make per node as SHOULD and per interface
as MAY ?
Regards
Mukesh
-Original
Alex,
Thanks for pointing this out. What do you think about the following
as the replacement text?
=
The rate-limiting parameters SHOULD be configurable. In the
case of a token-bucket implementation, the best defaults depend
on the computational power of the
Bob,
3. Requests for new type value assignments from outside of the
IETF should be sent to the IETF for review at [EMAIL PROTECTED].
The general guideline for this review is that the assignment for
a single type value should be made if there is public and open
Fred,
Sorry for replying late. I don't have any objections to the
change that you are suggesting and I agree that it will make
it clearer.
If I don't hear any objections, I will make this change in the
next revision.
Regards
Mukesh
-Original Message-
From: [EMAIL PROTECTED]
Pekka,
Please consider my mail earlier today on IANA Considerations as part
of WG LC. That part needs a lot more baking, I fear.
Bob has already replied to the other mail. So I would skip this
part.
Further, my earlier issue still stands -- I'd prefer to remove an
unimplemented ICMP
Gabriel,
I have submitted the updated version of the ICMPv6 draft
(draft-ietf-ipngwg-icmp-v3-04.txt) today. The draft is available at
http://sonic.net/~mukesh77/draft-ietf-ipngwg-icmp-v3-04.txt till it
appears on the IETF website.
Please look at section 2.1 (Message General Format). The
Jinmei,
I agree that we should not try to remove already
documented features in recycling work if it is
not causing any harm.
But the current RFC says If the node has more than one
unicast address, it must choose the Source Address of the
message as follows:. It is not MUST in all caps but
Hi All,
[Please express your opinion. It is needed to make
the informed decision.]
Pekka raised a concern about the usability of one of the
methods (section 2.2 (c)) to select the source address
of the ICMPv3 packet. I want to know if anyone has
implemented it ? or how useful and practical
Note that setting up Security Associations to deal with all the
required ICMP packets is a very difficult task (e.g., consider
the PMTUD packets). So PMTUD (and possibly some others) may not
work if the node only allows authenticated ICMP packet.
s/packet/packets/
I'm
Jari,
There may be some additional ICMP issues related to DoS that you
should mention. There are two exceptions in the multicast rule
e.2 in Section 2.4. In theory, you could cause a very large number
of nodes to send you Packet Too Bigs or Parameter Problems. For
instance, just send a
Jari,
Your points are valid. See my comments inline..
The primary problem with this is that while you may know well your
peer and even be able to set up a security association with him, it
may not be easy to set up security associations with all the routers
(and their operators) in between.
I agree with Christian and Pekka here.
So I think, we mostly agree upon the text that I had sent out
and I don't have to make any changes to that.
-Original Message-
From: ext Christian Huitema [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 31, 2004 1:04 PM
To: Pekka Savola;
If I am not wrong, if we wanted the router to send the correct
prefix to the host in the ICMP message, we will have to change
the format of the ICMPv6 Destination Unreachable message.
Currently, we just have 4 bytes unused in the message format and
this prefix can't fit in there.
So the question
Reject Route case is a specific case of the more general
administrative prohibition.
The administrative prohibition case might include other reasons
like source not allowed, destination not allowed, protocol
not allowed, port not allowed, in-secure packets not allowed,
etc.
Second paragraph of
Fred,
I mostly agree with Pekka here.
Specific comments inline:
I think we may have glossed over this in earlier discussion,
but I believe
'B' should be allowed as an expression of either messages OR bytes.
Size *does* matter in certain cases, and expressing 'B'
only in terms
of a
Here is the final revision of the text that everyone seems to agree
upon. I will put this in the draft. Please let me know if anyone has
anymore comments on this.
===
(f) Finally, in order to limit the bandwidth and forwarding costs
Julian,
do you completely want to remove back-to-back or ..back-to-back
ICMP error messages.. will be agreeable ??
I don't mind removing back-to-back if it is creating confusion ?
Let me know.
Regards
Mukesh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
Values of T that are higher than 20-30 might break legitimate
functionality that requires timely delivery of ICMPv6 error
messages (e.g., traceroute), while smaller values might cause
saturation of slow links.
The text definitely looks better than mine. I will use the above
text.
Hi Zachary,
It seems to me that back to back is ill-defined. It is highly
unlikely that the ICMP error packets will be transmitted with
no other
transmissions in between, which back to back seems to imply. The
burst allowance should probably be defined as allowing a burst of N
Hi All,
As I sensed after all the discussion we had, the WG will prefer
to expand the text to prefer token-bucket method and describe
the limitations of the other two. If my conclusion is wrong,
feel free to scream :) Otherwise, here is the revised text.
Please review the text and let me know if
Hi Margaret,
I'm not sure if these are logical reasons, but... I am
concerned about making a change that will invalidate any
existing ICMPv6 implementations, unless that change is
absolutely necessary (e.g. to block a serious security
hole or to prevent a significant operational problem).
Fred,
I don't quite understand why the Timer-based method need to
consider the source but Token-bucket based method or the
Bandwidth-based method don't (as the draft suggests).
Why not limit the rate of ICMPv6 error messages to a particular
source by using even the token-bucket based method ?
Fred,
I agree that the parameters do matter and should be chosen
wisely.
As the methods are being listed as examples, the draft
can only suggest suitable values and can not mandate them.
I think, even Pekka agrees that we could provide some hint
to the implementors by listing some suitable
I'm worried about the same thing -- and I don't think source-based
token-bucket is justified. Sure, feel free to do so, but a regular
one should work just as well with sufficiently large burst allowance
(e.g., 50-100 packets).
If someone is DoS'ing you it may actually be a feature that you
Fred,
Rethinking about the following example of yours. Do we need to
consider
the
asymmetric paths between A and B ? I guess, the problem can be
seen
with even
symmetric path. Let say the network is
like
A ---
1gig --- C --- 56 kbps -- D --- 1 gig ---
B
Now A
starts sending some
Oops !! stupid
mistake of mine :)
The number of
packets from A to B will be limited by the thin link and
thus
B won't have to send
ICMP back at a higher rate.
Regards
Mukesh
-Original Message-From: Gupta Mukesh
(Nokia-NET/MtView) Sent: Wednesday, January 07, 2004 4:19
If we decide to keep the Timer-based method, another problem
is to decide the value of T (not more than one icmp to a given
source every T milliseconds). 1 ms might be overwhelming for
a 64 kpbs link and 100 ms will be over-restricting for 10
gbps link.
What about we keep the Timer-based method,
Hi All,
I have taken the responsibility of being the editor for
the draft draft-ietf-ipngwg-icmp-v3-02.txt and I am trying
to address the issues raised by Thomas.
One of the issues raised was about rate limiting methods
suggested by the draft. The draft suggests Timer-based,
Bandwidth-based and
36 matches
Mail list logo
