Hi spz, > -----Original Message----- > From: S.P.Zeidler [mailto:[email protected]] > 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 ([email protected]): > > > 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 [email protected] > regards, > spz > -- > [email protected] (S.P.Zeidler)
