In your letter dated Fri, 27 Jan 2012 10:27:06 +0000 you wrote: >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.
The original use case was slightly different. It was about IPv6/IPv4 translators. The translator tries to forward an IPv6 packet or fragment over IPv4 where it requires fragmentation. Now we need a unique identifier for the IPv4 packet. Solution: require the host to insert a fragment header which contains a unique id. Given the current trends, just a random number would be good enough. But the old RFCs assumed that a sequence number was used to maintain uniqueness. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
