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

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

Dan,

About the placement of the translator, in the IPv6->IPv4
direction the packet incurs a size reduction due to the
substitution of an IPv4 header in place of the IPv6 header.
In the IPv4->IPv6 direction, however, the size of the packet
is inflated. So, e.g., if the translator receives a 1500byte
IPv4 packet and has to translate it into a 1520byte IPv6
packet, there is a chance that it may be dropped due to a
link MTU restriction somewhere in the IPv6 network and an
ICMPv6 PTB sent back toward the translator. Presumably, the
translator would translate that into an ICMPv4 PTB message
that it forwards on to the IPv4 host.

If I have that right, there may be a concern for whether
the ICMPv4 PTB would be dropped in the IPv4 network before
it arrives at the IPv4 host. I ran some tests and found
that path MTU discovery in IPv4 seems to be problematic
for a substantial number of the top 1000 websites:

http://www.ietf.org/mail-archive/web/rrg/current/msg05907.html

This suggests to me that path MTU discovery in the IPv4
network "works" simply because it is rarely invoked. In
other words, the IPv4 network seems to be getting by
based on the good fortune that most links in the Internet
core configure an MTU of 1500 or larger. But, this state
of affairs may be disrupted if more and more translators
are used that cause IPv4 packets to be inflated in size
after they are translated into IPv6 packets.

So, if the translator were located at the site border of
the IPv4 host (i.e., rather than at the site border of
the IPv6 host) the bulk of the path would be over IPv6
instead of IPv4, hence the incidence of ICMPv4 filtering
would be isolated to the end site of the IPv4 host.

Has the translator deployment analysis taken IPv4 path
MTU-related black holing into consideration?

Fred
[e-mail]  

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]]
> Sent: Monday, February 08, 2010 5:16 PM
> To: Templin, Fred L; 'Iljitsch van Beijnum'
> Cc: [e-mail]
> Subject: RE: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Templin, Fred L
> > Sent: Monday, February 08, 2010 5:11 PM
> > To: Dan Wing; 'Iljitsch van Beijnum'
> > Cc: [e-mail]
> > Subject: Re: [BEHAVE] Fwd: IPv6 hosts sending <1280 byte packets
> >
> > Dan,
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Dan Wing
> > > Sent: Monday, February 08, 2010 4:24 PM
> > > 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.
> >
> > Yes, the concern is for same src,dst operating at line
> > rate. IPv6 apps assume that there is no possibility for
> > fragmentation in the network, hence they may not be as
> > shy as IPv4 apps when it comes to sending large packets
> > at high data rates. Having the translator set DF=0 can
> > break that assumption.
> 
> There are three approaches discussed in new text in
> http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-08#page-18,
> which only set DF=0 for "small packets" (packets that were
> less than 1280 on the IPv6 side).
> 
> I don't think that eliminates your concern, though.
> 
> > > Is there another approach that should be considered to
> > > avoid that concern?
> >
> > I still believe placement of the translator matters.
> > Placing the translator closer to the IPv4 host
> > reduces the portion of the path that is exposed to
> > IPv4 hops. This is true whether the DF=0 or DF=1
> > approach is used.
> 
> Agreed.
> 
> However, that isn't always possible.  For example,
> someone operating an IPv6-only network will have to
> place their IPv6/IPv4 translator at their network
> border.
> 
> But perhaps some text could be added to
> draft-ietf-behave-v6v4-xlate which highlighted
> this recommendation to place the translator as
> close to the IPv4 host as possible.  Or, similarly,
> to ensure the IPv4 network has an MTU greater than
> 1280 (minus whatever the IPv6/IPv4 header differences
> are).
> 
> -d
> 
> 
> > Fred
> > [e-mail]
> >
> > > > 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
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave