[BEHAVE] PMTU Discovery and ICMPv6 filtering

[Ed Jankiewicz <[e-mail]>]

One of my colleagues received a long comment on Path MTU Discovery recommendations his organization published and is seeking advice.  I recall this has been discussed several times at IETF meetings, not sure which WG, so this may be redundant.  I've tried to summarize the salient points below, and have two broad questions on this:  Are these points already covered in RFCs (other than 4459, 4890) or current Internet-Drafts? If so, I would appreciate pointers.  If not already covered by current publications, is there interest in documenting the problem and comparing the solutions/drawbacks?

The commenter basically wrote:

IPv4 and IPv6 treat packets exceeding MTU differently - IPv4 will fragment packets that are "too big" but IPv6 will drop the packet and respond with ICMPv6 "too-big" error message. [The subject publication] recommends using the Path MTU Discovery Protocol to discover the end-to-end PMTU, which relies on ICMPv6 error messages. These may be blocked by various "filters" and IPsec gateways, which is the case in many operational networks.

However, even when ICMPv6 is not blocked, IPsec gateways (in tunnel mode) add extra headers, and there can be more than one tunnel header involved (routers also create tunnels). When a "too-big" message is sent the router will return put in its ICMPv6 message the value of the MTU on the next link at layer 2. The host receiving this MTU value in an ICMP message at part of the Path MTU Discovery Protocol has no way of knowing how many extra tunnel headers are added along the path, and so if it just takes the reported MTU value without allowing for these extra headers the process will keep on failing and will not recover. We have seen this behavior in our experiments. 

This can be prevented by ensuring that the maximum packet size sent by the host is smaller than the layer 2 limit: smaller by an amount estimated to be sufficient to allow room for extra headers to be added along the path. Several ways of achieving this are possible: 

(1) Set this reduced MTU value on the on the IPSec gateway LAN interface; the host then discovers this MTU through the PMTUD. 

(2) Statically configure this reduced MTU value into the host and switch off PMTUD. 

(3) Set a reduced MTU at the IPSec gateway WAN interface; The IPSec gateway acts as a host on this interface and so can do packet fragmentation.

(4) Provide the capability in the IPSec gateway to discover the MTU on its WAN interface, subtract the maximum header size that this gateway will add to packets presented on its LAN interface, which the host can then discover through the PMTUD.

Method (4) would be the best solution, but is not currently available in the IPSec gateway products. 
The next best solution is (1), which has been used [in commenter experiments]. This is not as good as (4) because it requires manual intervention, and an understanding of how to calculate the appropriate (reduced) MTU value.  
The next best solution is (2), the only disadvantage of this approach is that only one value can be set for all paths and so the worst case (lowest) value has to be used. In a complex network it may not always be obvious what the worst case path is, and so a conservative estimate may be necessary. Even so this could be preferable in some deployment scenarios since the path-MTU discovery protocol relies on the passage of ICMP messages which are sometimes blocked by firewalls and other security devices.  
Approach (3) is the worst solution since it will cause many IP packets to be fragmented which is inefficient (both because, unlike IPv4, the IPv6 header has to be extended to include the fragmentation offset field, and because it will result the second fragment being very small, i.e. the ratio of user-data to IP header size will be poor). 

It is likely that for immediate use option (1) should be used although (4) would be better if it were supported in the relevant products. 

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [e-mail]