Date: Wed, 12 Jun 2013 19:49:08 +0200
From: Gert Doering <g...@space.net>
Message-ID: <20130612174908.gt2...@space.net>
| 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. 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 ...
fg...@si6networks.com 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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
