Hi Brett,
-----Original Message----- From: Brett Frankenberger [mailto:rbf+nanog@panix.com] Sent: Monday, June 04, 2012 9:35 AM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels
On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote:
https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
3) For IPv6 packets between 1281-1500, break the packet into two (roughly) equal-sized pieces and admit each piece into the tunnel. (In other words, intentionally violate the IPv6 deprecation of router fragmentation.) Assumption is that the final destination can reassemble at least 1500, and that the 32-bit Identification value inserted by the tunnel provides sufficient assurance against reassembly mis-associations.
Fragmenting the outer packet, rather than the inner packet, gets around the problem of router fragmentation of packets. The outer packet is a new packet and there's nothing wrong with the originator of that packet fragmenting it.
Of course, that forces reassembly on the other tunnel endpoint, rather than on the ultimate end system, which might be problematic with some endpoints and traffic volumes.
There are a number of issues with fragmenting the outer packet. First, as you say, fragmenting the outer packet requires the tunnel egress to perform reassembly. This may be difficult for tunnel egresses that are configured on core routers. Also, when IPv4 is used as the outer encapsulation layer, the 16-bit ID field can result in reassembly errors at high data rates [RFC4963]. Additionally, encapsulating a 1500 inner packet in an outer IP header results in a 1500+ outer packet - and the ingress has no way of knowing whether the egress is capable of reassembling larger than 1500.
(With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte MTU on the tunnel, fragment the outer packet, let the other end of the tunnel do the reassembly. Not providing 1500 byte end-to-end (at least with in the network I control) for IPv4 has proven to consume lots of troubleshooting time; fragmenting the inner packet doesn't work unless you ignore the DF bit that is typically set by TCP endpoints who want to do PMTU discovery.)
Ignoring the (explicit) DF bit for IPv4 and ignoring the (implicit) DF bit for IPv6 is what I am suggesting. Thanks - Fred fred.l.templin@boeing.com
I presume no one here would object to clauses 1) and 2). Clause 3) is obviously a bit more controversial - but, what harm would it cause from an operational standpoint?
-- Brett