Re: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement)

[Geoff Huston <[e-mail]>]

> On 5 Dec 2014, at 8:00 am, Metzler, Dan J <[e-mail]> wrote:
> 
>> 
>> In IPv6 the problem is at its worst in a situation where the large packet sender
>> is using a 1500 octet MTU and close to the sender is a packet filter that
>> discards IPv6 packet too big massages. If there is some form of encapsulating
>> tunnel on the path to the receiver and the tunnel operates with an effective
>> MTU of less than 1500 then its possible to encounter a wedged TCP session:
>> 
>>   the sender sends a 1500 octet packet
>>   the tunnel ingress cannot accept the packet and passes back IPv6 ICMP PTB
>> message toward the sender
>>   the packet filter discards the IPv6 ICMP PTB message
>>   the sender times out and retransmits the 1500 octet
>> 
>>   rinse and repeat forever
> 
> Wouldn't this be working as designed?
> As it stands now we can even probe for this by sending a purposely large packet, and monitor for the response or PTB reply.  If it doesn't come back, that network is broken.
> 
> Is it really worth masking the problem?


The problem is here that there is potentially no single "network" that is broken. At one point on the path from the sender to the receiver there is a constrained MTU. At one point on the path from the constrained MTU to the sender (which is not necessarily the same path as the forward path) there is an ICMP filter.

So who is "broken"? The tunnel ingress that is performing IP-over-IP and needs to down-adjust the MTU to factor in the additional header? Or the filter rule set that is saying that it is unprepared to admit ICMP packets from arbitrary sources? Its not necessarily a single point of "failure" here, but the interaction of two different items of middleware, and they may not be located within a single locus of admin/operational control.


Geoff