p.mayers at imperial
May 14, 2012, 4:32 AM
Post #1 of 1
(231 views)
Permalink
|
|
ACE v6->v4 translation & path MTU problems
|
|
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)
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
|
