option 212 for 6RD
ek at google.com
Sat Jan 19 11:35:51 CET 2013
> That said, if you read between the lines of the original question, it
> suggests: «I have no control over my subscribers' CPEs». Which makes the
> LAN MTU solution extremely impractical to deploy. In that situation, the
> solution that is the most likely to yield the best effect, would be to
> enable TCP MSS clamping for 6RD traffic on the BR (or somewhere else in
> the ISP's core network). IMHO.
I guess I'm still unclear why there is a PMTUD problem. If the tunnel
thinks its MTU is <1500 then there will be a mismatch with the
(average) LAN and ensuing "good times".
But if the tunnel pretends the MTU is 1500 and fragments such a packet
into two packets of 1480 + 20 (the outer protocol is IPv4, after all),
what is the problem? Are people worried about the Segmentation and
Reassembly workload on the BR or something?
More information about the ipv6-ops