One comment below...
On 29/06/2013 07:21, james woodyatt wrote:
> On Jun 28, 2013, at 08:36 , Erik Nygren <[email protected]> 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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
