On Jun 12, 2013, at 2:44 PM, Robert Elz <[email protected]> wrote: > Date: Wed, 12 Jun 2013 19:49:08 +0200 > From: Gert Doering <[email protected]> > Message-ID: <[email protected]> > > | Loop back to about 50 messages earlier in this thread, > > I don't generally read this list (any more) - just happened to see the > past hour's worth of messages, so I have no idea what was 50 messages > earlier, but ... > > | 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.
You mean like: http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 ? Seeing as I filter on routers (which don't do reassembly) and I want to know what's actually in the packets I let into my network, they just get dropped on the floor. Ain't nobody noticed, so, if it ain't broke… W > 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. > > 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, or they can't look inside TCP properly (as while no-one sane > would ever split tcp segments in weird places, hackers will if the firewalls > can't handle it properly). Reassembling IP frags is childs play compared > to reassembling tcp segments. > > Again, no need to change anything in the IPv6 specs. > > 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. For one, in normal use, dest options should normally come > after a frag header, processing them before the packet is reassembled would > mean processing them before the packet is received correctly, which would be > 100% bogus (on the other hand, if options were even invented to allow the > sender some control over reassembly - perhaps to lower timeouts or something - > then a destopts header before the frag header would be rational.) > > Beyond that, I have had cases where a frag header before a routing header > made perfect sense - I know that routing headers are largely deprecated these > days, but before that, it was possible to send a fragmented packet over a > low MTU link, have it reassembled at the far side of that link, and then > the routing header (following the frag header) causes the packet to continue > over links with a larger MTU, so the penalties of fragmentation apply > only where they are really needed. What's more, for the remaining use of > routing headers (route opt for mobile IPv6) putting the frag header before > the routing header is also the sane way to run things (the routing header > there > is really just a fancy destination option). > > Lastly, consider that most v6 headers are allowed to be larger than the > MTU of the most common links in the internet at the time (and for that > matter, still) and certainly larger than the required MTU for v6 links, and > ask yourself how that would make any sense at all if all headers are > required to be before the frag header. > > Leave the specs alone, header chanins can have headers (other than hop by > hop opts of course) in whatever order makes sense to the application that > needs to send those headers. No more rules. Just deal with it. > > kre > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- After you'd known Christine for any length of time, you found yourself fighting a desire to look into her ear to see if you could spot daylight coming the other way. -- (Terry Pratchett, Maskerade) -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
