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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[e-mail]] 
> Sent: Monday, February 08, 2010 3:02 PM
> To: Dan Wing
> Cc: 'marcelo bagnulo braun'; [e-mail]
> Subject: Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> 
> 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.

A stateless translator cannot identify 'subsequent' packets,
because it doesn't remember previous state.  

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

So, I believe we are in agreement:  IPv6 packets less than
1280 need to be translated to IPv4 and sent with DF=0.

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

I agree the IPv6 host won't reduce its packet size below
1280.  But the IPv6 host becomes aware that the path MTU
is smaller than 1280.  I don't know if the IPv6 host finds
that useful/valuable to know the path MTU is less than the
IPv6 minimum MTU.

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

Don't know.  It is obviously easier for the 6/4 translator to
simply fragment the packet (or translate and send with DF=0) without 
informing the IPv6 host, but there is long-standing text in both
RFC2460 and its predecessor (RFC1883) that says to send back
ICMPv6 PTB and the IPv6 host is then supposed to send packets
with the fragmentation header.

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

draft-petithuguenin-behave-stun-pmtud does not rely on
ICMP packet too big messages.

> Not impossible, but I've never seen it happen.

Me, neither.  I'm just trying to temper the "only TCP does
PMTUD", because UDP can do PMTUD.  And of course there is value
in sending the largest packets possible.

> But if BitTorrent goes to UDP it's 
> likely they'll put this in in some way.

As of version 2.x, the most popular BitTorrent client on
Windows (uTorrent) has implemented uTP, for whatever that's
worth.  I don't know if they're doing PMTUD, though.  Beta
versions of uTorrent are available for OSX, too, and I expect
they will soon support uTP (if they aren't already).

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

-d