On 06/12/2013 08:44 PM, Robert Elz wrote: > | We're not talking ivory tower theoretical routers. We're talking about > | devices that can stand the heat out there, like "be able to apply > different > | rate limiting classes to incoming BGP SYNs from trusted networks, and to > | ICMP packets from the world". This MUST be done by the hardware, and it > | MUST be able to look at *Layer 4* information. > > If that's the issue, then the routers should just be treating any packet with > a frag header like dirt.
That's not what the discussion is about. We're talking about long IPv6 header chains... which might not contain a fragment header (e.g., simply the fixed IPv6 header, plus one long (or a few) dest options header, and then the real payload). > That's what they deserve. Lowest sched priority, > and most likely to be dropped. That's easy to accomplish in hardware (well > as easy as anything else that involves looking down header chains) > and perfectly acceptable - everyone knows that if one sends fragmented packets > performance goes out the window. Perfectly acceptable result, and no > changes at all to v6 specs are needed to get to that. It is not quite acceptable if the specs say one thing, and the real world says another. > On the other hand, if the real issue is firewalls, then there really should be > no issue at all - firewalls already need to be able to reassemble packet > chains, There are stateless filters, too. > Lastly, this comment caught my eye ... > > [email protected] said: > | It doesn't change how fragmentation works. It just clarifies a corner case > | which was allowed by the standard, but is not employed in practice, and > none > | expected to happen. > > Huh? Is that really claimimng that no-one ever thought that the frag > header would be anywhere but last in the header chain? That would be > absurd. I have no idea what you're talking about. The current version of draft-ietf-6man-oversized-header-chain essentially bans packets such as thos in page 5 of <http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07> Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
