RE: draft-wbeebee-ipv6-cpe-router-04 comments

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

> -----Original Message-----
> From: Wes Beebee (wbeebee) [mailto:wbeebee@cisco.com]
> Sent: Monday, July 13, 2009 7:56 AM
> To: Mikael Abrahamsson; v6ops@ops.ietf.org
> Subject: 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.

MSS clamping has been known for a long time, and in
fact is already implemented in some systems. However,
it is generally regarded as a band-aid fix. Indeed,
the IPv6/IPv4 tunneling mechanisms (e.g., RFC3056,
RFC4213, RFC5214, etc.) do not make a recommendation
for MSS clamping even after many years of deliberations
on ngtrans, v6ops and other discussion forums.

In addition to not working for non-TCP sessions and when
TCP headers are not available in the clear (e.g., IPsec),
MSS clamping also doesn't work when the initial packets
of a TCP session go through a different path and then
the session gets re-routed over the tunnel. For these
and other reasons, it therefore cannot be considered
as a generalized method for dealing with tunnel PMTUD
problems.

In short, I don't think this document should make a
recommendation for a solution that may or may not mask
one set of operational issues in the short term but will
almost certainly lead to a different set of operational
issues down the road. 

Fred
fred.l.templin@boeing.com
  
> 
> - 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
>