On Fri, 28 Jun 2013, Fernando Gont wrote: Fernando> I wanted to comment on some met-issues regarding the deprecation of the Fernando> IPv6 fragmentation function. Fernando> Fernando> ** On the motivation of deprecating the fragmentation function ** Fernando> Fernando> So far (and without having read Ron's recent I-D -- shame on me), it Fernando> looks like the main two reasons for deprecating the fragmentation Fernando> function are: Fernando> Fernando> 1) The inability of middle-boxes to parse past the first XXX bytes of a Fernando> packet Fernando> Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first Fernando> fragments.
I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013: Mark> One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment. The flow label, if properly set at or near the source, could plausibly address "2)" -- see https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/?include_text=1 However, it won't help middle boxes that implement stateless packet filters. Indeed, such boxes have fundamental problems with non-first fragments irrespective of how many bytes of extension headers they can parse or whether there are sufficient length limits on the extension header chain that guarantee that the L4 header always appears in the first fragment. As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether middle boxes that implement stateless packet filters with a "default-deny" policy will be a significant part of the landscape indefinitely, regardless of what the IETF says about their merits or lack thereof. If so, fragmented IP datagrams will continue be problematic in the general case; and since the job of this (or any other) IETF WG is to make the internet work better, it will be incumbent on the WG to deal with the issue. Ron Bonica and co-authors have made one proposal to do just that. Thinking aloud ... If we decide that the only path forward is to deprecate IPv6 fragmentation and reassambly (presumably not IPv4, since it's at end of life), the next question I see is what can or should be done to allow UDP and kin to send large datagrams. A UDP replacement with fragmentation and reassembly built in to the transport layer is one possibility. The questions that come to mind are (a) is this capability actually needed, and if so, (b) can it be incrementally deployed, in the face of middle boxes with "default deny" policies causing them to discard protocols that they don't know? //cmh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
