One set of answers to your earlier message.. This is probably past its usefulness.
On Wed, 18 Aug 2004, Alex Conta wrote: > 1. IP forwarding and ICMP generation is done in one processor, which > also controls all interfaces. A host with multiple NICs can act as such > a router. Sure. I say these explicitly, just to be sure that my comments are not seen as me saying "there must be only one ICMP origination engine per node and it must be done on the CPU". I've not said that. If an implementation has multiple linecards and they generate ICMP's, it's just fine to put the generation on each line card -- you can even use the same algorithm on each card. > 2. IP forwarding is distributed on line cards, each line card > controlling its interfaces, while ICMP generation is done in one central > processor. Sure. > To send ICMP packets out, the central processor > forwards the ICMP packet to the appropriate output line card, similarly > to one line card forwarding a packet to another line card, so internally > there is no difference between forwarding and generating packets. I hope > this is clear. No - you may be using the term "forwarding" in a confusing manner here. In the context of IP documents such as ICMPv6 spec, we're interested of IP forwarding (TTL decrease, etc.). When you have message passing between linecards and/or central processor, that's an implementation specific approach to message passing. It might even be based on IP forwarding (and not just some implementation dependent message passing mechanism -- I've seen both, unfortunately) -- but we shouldn't need to care. The point is, we'll just assume that *whoever* generates the ICMP response (be it central processor, linecard or whatever) will perform the origination rate-limitng.. or that the implementation makes sure it will be done (and makes sure that it doesn't do rate-limiting for other kinds of ICMP traffic) -- but if so, that's an implementor's decision, not something we'll want to put in a spec. > 3. IP forwarding and ICMP are distributed on line cards, each line card > controlling its interfaces, while ICMP generation takes place on each > line card. Sure. > Packets are passed > internally from one processor to another almost, or identical to > forwarding. So the outputting of ICMP packets generated by the line card, > looks like forwarding. Good that you acknowledge that internal message passing is not IP forwarding. Remember, the IETF procudes protocol documents which describe the external behaviour. To do so, the architecture is often simplified, and described based on that simplified architecture. If an implementation has more complex architecture, the details with such architecture are beyond the scope of the specification, to be done as the implementor sees fit as long as the external behaviour is the same. > a.- Does sending ICMP packets start when an errored packet is passed to > the ICMP message output engine? > b.- Does sending the ICMP packet start when an ICMP message has been > assembled and is ready to be sent out? > c.- Does sending the ICMP packet start when an ICMP packet has passed > through the IP output engine? > e.- Does sending the ICMP packet start when it went to the wire? These use the ambiguous word "send". In any case, this is probably implementation-specific, not something we need to be all that concerned of. > When this question is asked in relationship to rate limiting, the answer > can depend one what the implementation choice is: > > A.- rate control the IP errored packets coming from a particular interface > > B.- rate control the ICMP messages supposed to go out on a certain > interface. > > C.- rate control the IP traffic, with ICMP protocol field, in a generic > IP traffic management as packets are going out on a certain interface, > Distinction between local or remote packets can done by adding as source > address filters the local IP addresses. > > D.- rate control the IP/ICMP packet, in a generic traffic management > engine implemented at L2, with IP and ICMP protocols as filters, when > the packet is ready to be output on the wire. Distinction between local > or remote packets can be done by adding as IP source address filters > filters the local IP addresses. > > Which one is a correct answer? A? B? C? D? Is one more correct than the > other? or all of them are equally correct? B seems like the obvious choice here. C and D are obviously not something to be done in the ICMP specifications (but one is of course free to do so internally as long as the behaviour is consistent). A is out of scope of ICMPv6 spec because the problem is addressed by B. > IMHO, all answers above are correct, as long as the implementations do > the right thing, and have the right or desired effect on the network. Approaches C & D impose constraints to the forwarded traffic. But of course, your implementation is free to do something like that (e.g., to rate-limit the ICMP origination by setting up generic traffic limiters which list all the IP addresses of the specific node), as long as it's externally consistent with the specification, but it's not something we need or want to specify. We want to keep the concept very simple... which it isn't, at the moment. > I think the ICMPv6 specification is and should be left vague enough to > leave room for multiple correct interpretations, i.e. implementations. > As an IETF specification, it MUST be a protocol and not implementation > standard. No, it must not be too vague (as it seems to be now) that it's making it too difficult to interpret the meaning appropriately. Even if we say that ICMP origination MUST be rate-limited, and IP forwarding rate-limiting is out of scope (or MUST NOT be rate-limited based on this specification), and we said nothing of interface-specific configuration, nothing would prevent the implementation the way you have described. It just wouldnt be in the spec to confuse matters. > I hope I explained clear enough that in some cases, there is no internal > distinction between forwarded and locally sourced packets. To make the > distinction, a source address filter can be applied, but is that always > necessary? As it turns out, it is not, and that is OK, as long as the > effect on the network is OK. I think the difference stems from the fact that you think of this kind of distributed model as (IP) forwarding. To the rest, it's just message passing, and even if it'd be done based on IP forwarding, it's just an implementation issue. > The rate control can be configured to filter locally generated, all > ICMP messages (local and forwarded), or only remotely generated (forwarded). I guess these ACLs are generated by an algorithm at the central processor which monitors which IP addresses the node has. Remember that many hardware implementations also have constraints on access-lists they can perform. Does this work well on a router with 100 or 1000 IP addresses? Maybe not. -- 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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
