Hi James, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > james woodyatt > Sent: Friday, June 28, 2013 12:22 PM > To: 6man > Subject: Re: New Version Notification for draft-bonica-6man-frag- > deprecate-00.txt > > 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:
Yes, that has already been pointed out on the intarea list where some parallel discussions have transpired. > >> 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. Right; it is already well established that tunnels over IPv6 MUST perform some form of frag/reass in order to meet the IPv6 minMTU. > 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. https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ Thanks - Fred [email protected] > -- > james woodyatt <[email protected]> > core os networking > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
