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

["Ramji Vaithianathan (rvaithia)" <[e-mail]>]

>From my understanding, this will be a problem only if the 
  1. MTU on some link on IPv4 side is less than 1280
  2. We have high speed traffic less than 1280 bytes but greater than
the above MTU value.

Generally most links on intermediate routers are 1500 or greater.  

So this may not be a common case, unless there is a link attached to an
end host is of smaller MTU (< 1280) and can take in high traffic as well
in the range MTU_value .. 1280. 

Regards,

Ramji
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Dan Wing (dwing)
Sent: Tuesday, February 09, 2010 5:54 AM
To: 'Templin, Fred L'; 'Iljitsch van Beijnum'
Cc: [e-mail]
Subject: Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets


 

> -----Original Message-----
> From: Templin, Fred L [mailto:[e-mail]]
> Sent: Monday, February 08, 2010 4:02 PM
> To: Dan Wing; 'Iljitsch van Beijnum'
> Cc: [e-mail]
> Subject: RE: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> 
> The concern with setting DF=0 on the IPv4 side for packets that are 
> 1280 or smaller on the IPv6 side is the possibility for RFC4963 data 
> corruption if we let it run at line rate.

At high speed with the same source/destination addresses, and when
fragmentation on the IPv4 network occurs.  That is, sending lots of
packets with DF=0 does not, by itself, cause a problem even if they are
fragmented on the same link -- so long as they have different source or
different destination addresses.  I agree we should make a note of that.


Is there another approach that should be considered to avoid that
concern?

> There are certainly plenty of websites on the IPv4 Internet that set 
> DF=0 on every packet they send, and many even use packet sizes larger 
> than 1280. But, how many of them send large packets at line rate?

Content delivery networks?

-d


> Fred
> [e-mail]
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Dan Wing
> > Sent: Monday, February 08, 2010 3:29 PM
> > To: 'Iljitsch van Beijnum'
> > Cc: [e-mail]
> > Subject: Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> > 
> > 
> > 
> > > -----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
> > 
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave