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

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

 

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