MTU handling in 6RD deployments

[Templin, Fred L]

Hi spz,

> -----Original Message-----
> From: S.P.Zeidler [mailto:spz at serpens.de]
> Sent: Thursday, January 09, 2014 8:22 AM
> To: Templin, Fred L
> Cc: IPv6 Ops list
> Subject: Re: MTU handling in 6RD deployments
> 
> Thus wrote Templin, Fred L (Fred.L.Templin at boeing.com):
> 
> > What is the MTU as seen by the IPv6 hosts - 1480? Something less?
> > Would it not be better if they could see 1500+?
> 
> Is this about the "let's improve a case of flu (router generates too many
> Packet Too Big ICMP) with bubonic plague (let the router do both packet
> fragmentation (wasn't that explicitly forbidden in IPv6?) and packet
> reassembly)" idea?

Fragmentation and reassembly would not happen at the IPv6 level; they
would happen at a sub-layer below IPv6 and above IPv4. So, there is no
violation of the IPv6 standard since the tunnel endpoint is acting as
a "host" when it encapsulates IPv6 packets.

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.

This is not a "one size fits all" solution for all 6rd domains; some
might be better able to manage their IPv4 link MTUs and/or accept
steady-state fragmentation than others.

Thanks - Fred
fred.l.templin at boeing.com
 
> regards,
> 	spz
> --
> spz at serpens.de (S.P.Zeidler)