[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-wbeebee-ipv6-cpe-router-04 comments
What do you think of making MSS clamping a "MAY" in the CPE Router
document, while leaving it up to the vendor whether to make it default
or not? Along with a note that this is one way to deal with PMTUD
problems with tunnels.
- Wes
-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Mikael Abrahamsson
Sent: Monday, July 13, 2009 9:02 AM
To: v6ops@ops.ietf.org
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments
On Mon, 13 Jul 2009, Templin, Fred L wrote:
> As you say, MSS clamping can be applied to TCP the same as for any
> link and in fact is a common operational practice. However, TCP
> headers are not always available in-the-clear, and as you say not all
> traffic is TCP. IMHO, operators can already do MSS clamping w/o the
> need for additional text in these documents.
In the case of 6to4, a common platform to do this on is Cisco 7600 (it
does it pretty much wirespeed), in that platform you cannot do MSS
adjust.
Therefore it would make more sense to do this in the CPE.
> The idea with setting the tunnel MTU is to set a size that is highly
> unlikely to fragment, as sustained fragmentation is dangerous in any
> case. An additional alternative under development you may not be aware
> of is SEAL, which fixes fragmentation to the point that larger MTUs
> can be realized - even up to jumbogram size if that is desired. See:
> 'draft-templin-intarea-seal'.
Yes, I was a bit unclear, myself (since I control both ends of the
tunnel (I don't use 6to4 but a statically configured ipv6-in-ip) I have
actually set the MTU of this tunnel to 1350 which means this is the
lowest common denominator for PMTUD (is my guess anyway) so this solves
my "problem".
I still think it would make most sense to do the MSS clamping in the
6to4 tunnel CPE because it knows for sure whether traffic is going to a
tunnel or not.
--
Mikael Abrahamsson email: swmike@swm.pp.se