[c-nsp] ACE v6->v4 translation & path MTU problems

Phil Mayers p.mayers at imperial.ac.uk
Mon May 14 07:32:11 EDT 2012


All,

We are testing protocol translation on ACE30 with an IPv6 VIP, and IPv4 
serverfarm. We are seeing problems with path MTU discovery. The ACE does 
not seem to be obeying section 5.2 of RFC 6145, which states with regard 
ICMPv6 packet-too-big errors:

"""The MTU field MUST be adjusted for the difference between the IPv4 
and IPv6 header sizes"""

...when translating into ICMPv4, and goes on to specify the nature of 
the adjustment.

So, for hosts with tunnelled IPv6 connectivity, we see the following - 
note the client believes it has a 1500 byte MTU, the low MTU is in the 
"middle".

   v6client SYN MSS=1440
   xlated v4client SYN MSS=1440

   v4server SYN,ACK MSS=1460
   xlated v6server SYN,ACK MSS=1460


Note that, although no MSS clamping has taken place, the lower of the 
two MSS, 1440, will be picked (and indeed, is) which would work fine in 
a 1500-byte MTU setting.

   v6client ack, GET / HTTP/1.0
   etc.

Then we get to the 1st full-size payload packet:

   v4server payload=1440 therefore packet=1480
   xlated v6server payload=1440 therefore packet=1500

   v6router ICMPv6 packet-too-big MTU=1480
   xlated ICMPv4 packet-too-big MTU=1480

...which is course is wrong; the xlated ICMPv4 packet should have 20 
subtracted from the MTU. Path MTU discovery fails, and the v6client 
doesn't see any traffic.

We have IP and IPv6 normalization DISABLED, for various reasons (they're 
problematic if you do direct server return, for example).

Has anyone else tested this scenario? Did you have MTU problems, and if 
so, how did you resolve them?

ACE is on version A5(1.2)


More information about the cisco-nsp mailing list