* Fernando Gont:

> On 01/27/2012 08:36 AM, Florian Weimer wrote:
>> And I see no functional difference between the gateway and the host
>> generating the fragment ID, except that the latter approach seems to
>> require network-wide software updates currently.
>
> Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by
> inserting a Fragment Header in subsequent packets, or what? (last time I
> checked, I think this was the case)

There are existing deployments which effectively filter ICMPv6 traffic.
Some of them do so explicitly, others simply to do not broadcast
incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to
make this work with behind a per-packet load balancer).  Naked host
behavior does not matter in such scenarios.

As soon as IPv6 traffic levels increase, all busy UDP sources will stop
generating atomic fragments reliably because at the time of retry, the
fact that an atomic fragment is required has expired from the
destination cache (if there is one in the first place, that is).
That's why Mark proposes to send atomic fragments unconditionally
and *that* is known to break stuff for sure.

> In any, please note the difference between *accepting* atomic fragments,
> generating ICMPv6 PTB when the MTU of the constricting link is < 1280,
> and reacting to ICMPv6 PTB by generating atomic fragments.

True, but why would it be important to accept atomic fragments, when the
system as a whole does not actually generate them properly?

I'm worried that we're imposing updates on significant parts of the
network to address an issue that could also be fixed locally,
maintaining full interoperability with the rest of the network as it
exists now.

-- 
Florian Weimer                <fwei...@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to