option 212 for 6RD

[Jeroen Massar]

On 2013-01-14 21:38, Jean-Francois.TremblayING at videotron.com wrote:
> Jeroen Massar <jeroen at massar.ch> a écrit sur 14/01/2013 02:43:47 PM :
> 
>> Wouldn't the CPE (that terminates the 6rd tunnel and routes a /64 out of
>> the delegated prefix to the LAN side) send PTB's already?
>>
>> At least, that is how I have been doing IPv6 for years now.... (some
>> device makes a tunnel with MTU of <1500, LAN has 1500)
> 
> In our experience, there are number of cases where the first large 
> packet is sourced from the content provider rather the client. In that
> scenario, it's the 6RD relay that sends back the PTB and the content 
> provider 
> who has to adjust. My 6RD relays ICMP stats seem to tell that story at 
> least. 

As typically requests are <1500 and content are >1500 that is quite
likely in most cases indeed.

But what you described is that you put an MTU of 1480 in the RA on the
LAN; this while that LAN is really 1500 and while the CPE can easily
tell the clients on the LAN with a PTB that the next part is <1500.
(and thus clients can talk between eachother with 1500 while talking
with 1480 max towards the internet)

The only thing that having 1480 in the RA might do is that some OSs
might advertise 1480 in the TCP MSS which does get to servers who are
stupid (really no other way to say that ;) and filter ICMP PTB and then
the problem is partially circumvented.

>> Google handles PMTUD properly afaik... but yes, there will be others who
>> will send packets with size == 1500 even though the tunnel endpoint
>> sends a PTB to them that that packet size really won't fit.
> 
> I still have to debug this in details. It's an on-going project to 
> characterize the PTB destinations and their exact content. For now, 
> all I can tell is that we had a number of support calls related to 
> this, all with YouTube. 

Interesting. I've not seen or heard of any such issues yet. Do keep this
list informed about this, I guess others should be noticing it too.

Greets,
 Jeroen