Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets

[Iljitsch van Beijnum <[e-mail]>]

On 8 feb 2010, at 23:34, Dan Wing wrote:

>> So essentially this means doing more work (keeping PMTUD 
>> state for the IPv4 path) in order to do even more work later 
>> (fragment). Not sure how that makes sense...

> Yes, it means the translator is doing the effort of fragmenting
> rather than the router immediately in front of the small-MTU
> link.  However, by doing it this way, we can maintain end-to-end
> PMTUD for those IPv6 hosts that receive ICMPv6 PTB and send
> packets with the fragmentation header.

No, the two issues are orthogonal.

At some point, an IPv6 host sends a packet that is larger than the IPv4 PMTU. A router sends back a too big message. Issue A is how to handle this too big message. Issue B is what happens to packets that the IPv6 host subsequently sends.

I think there is agreement that A should be handled by simply translating the IPv4 too big too IPv6 and adjusting it as per the header size differences, but otherwise let it through transparently. (I once argued for rewriting it to 1280, though.)

Nothing has changed here.

But now for part B. A stateless translator can't monitor the IPv4 PMTU. Not because it's stateful (we're talking per destination state, not per session state, it would be doable to track this) but because there may be more than one translator so any given translator may not see all packets. So for stateless translation when the translator has a < 1280 packet with no fragment header we don't know whether this is because PMTUD was succesful and the packet size fits in the PMTU, or the IPv6 host ignored the < 1280 too big message and is omitting the fragment header in violation of the relevant RFCs. In order to be compatible with the latter the only thing we can do is set DF to 0.

(I just realize that we don't know what happens when for instance the PMTU is 1000 and the IPv6 host wants to send a 1100-byte packet: does it include a fragment header or not?)

Note that for part B, if there _is_ a fragment header, that will also trigger the translator to set DF to 0. So in the case where the IPv6 hosts are well behaved there is no change to either parts A or B.

In the stateful case we know all packets flow through the same translator so we get to track the IPv4 PMTU so when there is an IPv6 packet that needs to be translated we know whether it's bigger or smaller than the PMTU so we can send packets that are bigger with DF=1 and packets that are smaller with DF=0 and if we are to, also immediately fragment them. However, there is no advantage to doing this extra work because even if we get to set DF=1 on some packets that are smaller than the PMTU that only lets us discover a reduction in the PMTU, but that discovery doesn't buy us anything because the IPv6 host isn't going to reduce its packet size. Fragmenting at the translator also doesn't buy the translator anything and it may even get the packet blocked or create more work if there's a firewall with a > 1280 MTU before the path hits the < 1280 MTU which would need to reassemble the packet to observe the port numbers. And it could be an attack vector: attackers could send too bigs with tiny MTUs to make the translator work harder.

> Certainly there was some
> perceived value in the IPv6 knowing its packets are being
> fragmented.

I don't think so. Even if the application somehow learns this information, what is it supposed to do then?

> I agree that nearly 100% of PMTUD on IPv4 is with TCP.

> But there isn't anything prohibiting PMTUD for UDP.

With sufficient thrust pigs fly just fine...

Generally, it's not easy for UDP applications to limit their packet sizes. So the protocol would have to support changing the packet size on the fly and then the application would have to react to too big messages. Not impossible, but I've never seen it happen. But if BitTorrent goes to UDP it's likely they'll put this in in some way.

> I tend to think, though, we don't want to figure this out
> for stateful translators at this point in time.  If it is
> found useful/necessary, it can be specified later.

Right.