* Florian Weimer:
> Actually, atomic fragments aren't the problem, but the technology that
> serves as a justification for them. [...]
This argument turns out to be entirely wrong. Sorry about that.
I'm still extremely bothered by atomic fragments. Their use case seems
to be something like this:
(1) A router receives a sufficiently large IPv6 packet for a
destination which lies behind a link with a sub-1280 MTU.
(2) The router sees that the packet lacks a Fragment extension header.
It sends a Packet Too Big ICMP message to the source address and
discards the original packet.
(3) The source retransmits the packet, this time with an extension
header describing it as an atomic fragment.
(4) It arrives at the router of step (1). The device now fragments
the atomic fragment packet into actual fragmented packets, and
forwards it over the sub-1280 link.
This is contrary to the IPv6 design because the network is not supposed
to fragment. But it has to, due to the sub-1280 link, or there wouldn't
be any IPv6 connectivity at all. Once you accept this deviation from
the IPv6 specification, why can't the router jump from step (1) to step
(4), after synthesizing a Fragment extension header locally? It's not
that the header contains valuable application data or something like
that.
It seems to me that this results in superior interoperability: it works
with nodes which do not support atomic fragments gracefully, and it
doesn't require updates to significant parts of the network, to generate
atomic fragments more reliably *and* to deal with the resulting increase
in atomic fragments.
--
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
--------------------------------------------------------------------
