Re: Non-Last Small IPv6 Fragments

On Mon, Jan 14, 2019 at 10:40 AM Bjoern A. Zeeb
<bzeeb-lists@lists.zabbadoz.net> wrote:
>
> On 14 Jan 2019, at 18:12, Nick Hilliard wrote:
>
> > Tom Herbert wrote on 14/01/2019 17:58:
> >> I don't know what it means to "reassemble fragments in the network".
> >> Reassembly is specified as an operation at destination end points.
> >
> > some types of stateful middleboxes do in-line reassembly.
> >
> > There are many horrors on the Internet.
>
> And maybe it’s time to call them out, say screw them, and either
> people have to live with broken stuff or get end-to-end connectivity
> again.   Maybe it’s time to stop catering for the brokenness and
> control of others.  Maybe it’s time to play it hard.
>
Bjoern,

I tend to agree in principle, however I think before playing hardball,
we should make it easier to be protocol compliant. One of the issues
that intermediate nodes (as well as end nodes) have with processing
IPv6 is the open endedness of the protocol mechanisms. By the spec,
end hosts are supposed to be able to reassemble a single packet
composed of over 8000 fragments. Before RFC8200, all intermediate
nodes were expected to process packets that could contain over 700
individual Hop-by-Hop options. Those simply aren't practical to
support in an implementation, and as Fernando points out no one is
going to spend money on fixing that. But, we can set reasonable
expections of support, such a minimum fragment size or allow a limit
on number of options in packet (eight is suggested for instance). With
such limits and improved packet processing tehniques and device
programmability, I think it's feasible and cost-effective for new
network devices to increase their protocol compliance.

Tom

> /bz
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------