Subject: RE: can you be constructive? Re: pls read the specs Re: Section 2.4, item (f) of draft-ietf-ipngwg-icmp-v3-04.txt

From: [email-masked]
Date: Wed, 18 Aug 2004 14:57:30 -0500

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, encryption, etc.).
> >
> 
> If the router can know that they are error messages and can also know,
> e.g., that the errors are arriving at a disproportionally 
> high rate with
> respect to the IPv6 packets that could have possibly generated them,
> then it should perform rate limiting. (That would be per-interface
> rate limiting, I suppose.)

If the router starts looking the protocol type field in the IPv6
header and behave differently for each type of packet, IMHO it 
will become a firewall or a packet filter :)

I agree with Pekka and Havard.  This will be fixing (or
rather patching) the problem at the wrong place.  

As Pekka already said that this issue is not just with
ICMPv6 but with any bad traffic.  For what all bad traffic 
a router should perform rate limiting for is a general
question and should be completely outside the scope of
the ICMPv6 Protocol spec.

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Wed, 18 Aug 2004 13:27:16 -0700

Hello Mukesh,

[email-masked] wrote:

>Fred

Please re-read my message; I did not say that the router must
look at IPv6 headers to identify and distinguish  error messages.

Thanks - Fred
[email-masked]

---

From: Alex Conta <[email-masked]>
Date: Wed, 18 Aug 2004 23:20:39 -0400

Mukesh,

[email-masked] wrote:

> [...]

Routers are designed for traffic policing and shaping, and so
the router would just do this as part of its job.
No firewall, or packet filter though (-:...

> rather patching) the problem at the wrong place.  

Yes. But one could ask so what? Blaming the host, and shaping
the traffic have both their role here.

> the ICMPv6 Protocol spec.

Does this ICMPv6 scope conform with the reality of the spec, or just 
with some thinking of how the spec should be? Do we need to use some 
magic for instance to see in the text the word "originate" instead of 
"send"?

So then we write a separate ICMP specification just
to help us figure out how/howmuch to rate limit the forwarded ICMP 
messages, right?

Imagine we have written that. How would that be different from Section 
2.4 (f)?

And then let's imagine that we merge the two together.

How would that look? Would look like Section 2.4 (f)? Is there a good 
probability?

If technically the rate limiting operation for forwarding ICMP is pretty 
much the same as for ICMP origination, why can't we have it in one 
document?

Why can't we have it in the ICMP spec?

Or maybe we have it already and we had it there for the longest time.... 
What is wrong with that?  In my view nothing.

Regards,
Alex

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Aug 2004 09:56:57 +0300 (EEST)

> magic for instance to see in the text the word "originate" instead of 

Definitely "originate", and similar other tweaking to make sure the
spec can only be interpreted one way.

> to help us figure out how/howmuch to rate limit the forwarded ICMP 

You can write it if you want :-).  But being frank, I doubt it'll
receive sufficient interest to move forward except possibly as an
Informational RFC in an operational working group, so the next steps
are more of an academic question.

(read: do we have a specification how routers do other kinds of
rate-limiting for other kind of traffic?  not that I'm aware of!)
 
> much the same as for ICMP origination, why can't we have it in one 

It isn't the same thing at all.  The parameters and mechanisms how to
achieve the different goals are entirely different, as are the reasons
for their configuration; forwarding limiters are an issue for network
operators, origination limiters are an issue for protocol developers.

> Why can't we have it in the ICMP spec?

Should the IETF specify how routers forward or shape TCP SYN's, ACK's,
or RST packets in the TCP specifications?  NO!

This is the same thing!

> What is wrong with that?  In my view nothing.

I guess that no one except you read the word "send" like that (well, I
don't know about Fred) *) -- so this argument doesn't hold.  To
everyone else, it was clear that the limiter was solely designed for
origination, and everything else is out of scope.

*) the fact that all the implementations I know of implement ICMP
*origination* rate-limits, not *ICMP forwarding* rate-limits should
speak of that.  Can you name implementations which perform ICMP
forwarding rate-limiting by default (as required for compliance
according to the way you read it)?  (Note that whether or not an
implementation supports an administrator configuring generic
rate-limiters is a separate issue altogether.)

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