MTU handling in 6RD deployments

[Templin, Fred L]

Hi Ragnar,

> -----Original Message-----
> From: Anfinsen, Ragnar [mailto:Ragnar.Anfinsen at altibox.no]
> Sent: Thursday, January 09, 2014 11:36 AM
> To: Templin, Fred L; S.P.Zeidler
> Cc: IPv6 Ops list
> Subject: Re: MTU handling in 6RD deployments
> 
> On 09.01.14 17:36, "Templin, Fred L" <Fred.L.Templin at boeing.com> wrote:
> 
> 
> >But, in some environments we might not want the 6rd BRs to suffer from
> >sustained fragmentation and reassembly so a responsible network operator
> >would fix their IPv4 link MTUs to 1520+. If they can't do that and the
> >load on the 6rd BR appears too great, then MSS clamping and a degenerate
> >IPv6 MTU reported to the IPv6 hosts is the only option.
> 
> The problem with your statement

Where do you see a problem with my statement - it agrees with what
you said below:

> is that many L3 access networks do not
> support MTU greater than 1500 on the access port. And if the RA MTU is set
> to 1480, you would not see any problems at all. However, there are some
> retail routers which do not set the MTU to 1480 when using a 6rd tunnel.
> In these cases adjusting the MSS if a good and efficient way of correcting
> that problem. Our experience so far is that MSS-clamping does not have any
> additional CPU load compared to not do it.

I don't doubt that your experience is valid for the environment you
are working in. What I am saying is that there may be many environments
where setting IPv4 link MTUs to 1520+ is a viable alternative and then
the hosts can see a full 1500+ MTU w/o ICMPs. SEAL detects when such
favorable conditions exist and uses limited fragmentation/reassembly
only when they don't. Or, if fragmentation/reassembly is deemed
unacceptable for the environment, then clamp the MSS.

Thanks - Fred
fred.l.templin at boeing.com
 
> /Ragnar
>