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

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

Mikael,

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.

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'.

Fred
fred.l.templin@boeing.com



> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
> Sent: Monday, July 13, 2009 4:23 AM
> To: v6ops@ops.ietf.org
> Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments
> 
> On Sun, 5 Apr 2009, Mag Pat wrote:
> 
> Hi,
> 
> I know I am a bit late, but I read thru the
> http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-00
> and I have a question:
> 
> In section:
> 
> 8.5. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV)/ISATAP
(MEDIUM)
> 
> Would it make sense to put in a recommendation about doing MSS-adjust
for
> packets traversing v6-in-v4 tunnels? I'm personally doing this today
to
> avoid MTU related problems, and I think it's a better way than doing
> tunnel packet fragmentation (which is problematic as for instance our
6to4
> gateway has 4470 MTU on its core facing interfaces so any 1500 byte
IPv6
> packet will be over 1500 when encapsulated in ipv6-in-ip, and then
there
> might be a v4 packet fragmentation problem on the way to the tunnel
> endpoint and the packet might be dropped).
> 
> Setting MSS to 1350 (or other value substantially lower than what is
> required to pass unfragmented thru ip-in-ip tunnels) avoids this
> fragmentation problem. It doesn't fix UDP of course, but it would
avoid
> performance and functionality problems in TCP (which in my experience
make
> up the majority of Internet traffic).
> 
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se