[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: New Version Notification for	draft-bonica-6man-frag-deprecate-00.txt
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2013-06-28 20:57:35
Message-ID: 51CDF8BF.6060002 () gmail ! com
[Download RAW message or body]

One comment below...

On 29/06/2013 07:21, james woodyatt wrote:
> On Jun 28, 2013, at 08:36 , Erik Nygren <erik+ietf@nygren.org> wrote:
> > [...]
> > As such, I agree with other comments that it's important
> > to re-emphasize that any environment that both blocks ICMPv6 PTB
> > and at the same time doesn't allow 1500 byte packets through is broken
> > and needs to get fixed.  This also means that anyone deploying
> > or implementing a tunnel (or VPN) needs to carefully consider
> > how they'll deal with this.
> > [...]
> 
> And this is where I point at RFC 2473 "Generic Packet Tunneling in IPv6" section \
> 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote for handy reference \
> below: 
> > > 7.2 IPv4 Tunnel Packet Fragmentation
> > > 
> > > When an IPv4 original packet enters a tunnel, if the original packet
> > > size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
> > > entry-point and the tunnel exit-point, minus the size of the tunnel
> > > header(s)), it is handled as follows:
> > > 
> > > (a)  if in the original IPv4 packet header the Don't Fragment  -
> > > DF - bit flag is SET, the entry-point node discards the
> > > packet and returns an ICMP message.  The ICMP message has
> > > the type = "unreachable", the code = "packet too big", and
> > > the recommended MTU size field set to the size of the
> > > tunnel MTU - see sections 6.7 and 8.3.
> > > 
> > > (b)  if in the original packet header the Don't Fragment - DF  -
> > > bit flag is CLEAR, the tunnel entry-point node encapsulates
> > > the original packet, and subsequently fragments the
> > > resulting IPv6 tunnel packet into IPv6 fragments that do
> > > not exceed the Path MTU to the tunnel exit-point.
> 
> This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation and \
> Reassembly" which I will also quote for handy reference: 
> > > 5.3.  Fragmentation and Reassembly
> > > 
> > > Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
> > > traffic over IPv6 will reduce the effective MTU of the datagram.
> > > Unfortunately, path MTU discovery [RFC1191] is not a reliable method
> > > to deal with this problem.
> > > 
> > > A solution to deal with this problem is for the service provider to
> > > increase the MTU size of all the links between the B4 element and the
> > > AFTR elements by at least 40 bytes to accommodate both the IPv6
> > > encapsulation header and the IPv4 datagram without fragmenting the
> > > IPv6 packet.
> > > 
> > > However, as not all service providers will be able to increase their
> > > link MTU, the B4 element MUST perform fragmentation and reassembly if
> > > the outgoing link MTU cannot accommodate the extra IPv6 header.  The
> > > original IPv4 packet is not oversized.  The packet is oversized after
> > > the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
> > > fragmented.  Fragmentation MUST happen after the encapsulation of the
> > > IPv6 packet.  Reassembly MUST happen before the decapsulation of the
> > > IPv4 packet.  A detailed procedure has been specified in [RFC2473]
> > > Section 7.2.
> 
> Clearly, this proposal to deprecate IPv6 fragmentation headers entails an update to \
> RFC 2473 and RFC 6333 as well as RFC 2460.  The procedure for encapsulating IPv4 \
> packets with DF=0 in IPv6 tunnels where the path MTU is less than typical IPv4 path \
> MTU currently requires tunnel endpoints to use IPv6 fragment headers. I guess they \
> have to stop doing that if this RFC is published.

All this is why it seems reasonable to deprecate ("SHOULD NOT") fragmentation
by hosts without disabling reassembly, and leave a window for cases such as
foo-in-IPv6 tunnels where fragmentation is still useful. You just have to
know that those tunnels won't work across certain middleboxes.

> I'm also excited to learn about how we're going to add PLPMTUD to GRE and \
> tunnel-mode IPsec ESP so they have some hope of using path MTU larger than 1280 \
> octets.

You mean a better chance than they have today, except on carefully tailored
paths?

Let's face it, this train left the station a while back. (This doesn't
mean I'm happy, but it is what it is.)

    Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]