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

["Templin, Fred L" <[e-mail]>]

Ramji,

> -----Original Message-----
> From: Ramji Vaithianathan (rvaithia) [mailto:[e-mail]]
> Sent: Monday, February 08, 2010 7:04 PM
> To: Dan Wing (dwing); Templin, Fred L; Iljitsch van Beijnum
> Cc: [e-mail]
> Subject: RE: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> 
> 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.

I think it is reasonable to assume that the vast
majority of intermediate routers configure an MTU
of 1500 or greater. Where there might be a concern
for links with smaller MTUs is within end sites.

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

Right.

Fred
[e-mail]
 
> 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