On Jun 28, 2013, at 08:36 , Erik Nygren <erik+i...@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. 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. -- james woodyatt <j...@apple.com> core os networking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
