Re: Non-Last Small IPv6 Fragments

[Mark Andrews <[e-mail]>]

> On 15 Jan 2019, at 6:06 am, Tom Herbert <[e-mail]> wrote:
> 
> On Mon, Jan 14, 2019 at 10:40 AM Bjoern A. Zeeb
> <[e-mail]> 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.

No, a node is required to support reassembly up to 1500 octets (the
limit in IPv4 was 576) which works out at 183 minimum sized fragments.
Most nodes support larger than minimum reassembly buffers.

> 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.

Again this was people being idiotic. Firstly there was never a requirement
to reassemble packets in routers.  So unless you actually had link packets
that were 2^16-1 bytes in size you would never see such counts on a packet.
Also given that it is impossible to process HBH options in other than the
0 offset fragment (you can’t know if the start of a non 0 offset fragment is
a HBH option) the practical count in a 1500 octet MTU network is considerably
smaller.  In practice any packet can have be fragmented down to 1280 so that
was always the practical limit into which HBH options needed to fit.  Thats
still a lot of HBH options but no hardware needed to handle 700 option.

Mark


> Tom
> 
>> /bz
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]