option 212 for 6RD

[Jeroen Massar]

On 2013-01-15 00:01, Jean-Francois.TremblayING at videotron.com wrote:
>> Do you mean "lower the MTU to 1480" of the tunnel interface ("WAN") or
>> do you mean of the LAN?
> 
> LAN of course. The tunnel is already 1480 AFAIK. 
>  
>> As the tunnel should indeed be 1480 or lower, but the LAN can just stay
>> at 1500 and changing that would cause all kinds of other odd issues I
>> would think for hosts that don't take the info from the RA... 
> 
> What kind of odd issues do you have in mind? Operationnal experience
> shows no issue so far. 

I got jumbo at 9000 on the LAN and thus by advertising an MTU of 1480
you are restricting hosts talking directly to 1480 instead of 9000.

(Note that this only applies when they use the prefix in the RA, the
link-locals will still be 1500)

As the RA should apply to all hosts they should have the same MTU and
theoretically nothing there should go wrong except that you don't get
your full packet's worth of data.

And yes, the local network is important as people tend to have local
video caches and they like those to stream properly.

>> and the
>> CPE should really be doing PTBs thus lowering the MTU is not needed as
>> it will send a PTB because of the tunnel interface having the lower MTU
>> (eg 1480).
> 
> I had this same discussion last year with Mark T. in v6ops I believe. 
> 
> PMTUD is a nice concept, but it remains nice only in concept from our 
> experience. In the real world with 6RD, we see that: 
> 1) PTB is often sent from the relay to the content provider
>    (this doesn't preclude having it on the client side)

That is logical and nothing you can do about except removing the link.
Servers will deploy at 1500 and hopefully higher in the future.

Setting a local MTU will not solve this, the PTB will still be sent by
the 6rd gateway as the next link (the tunnel) has a lower MTU.

> 2) Content providers likely have a firewall or a load-balancer 
>    blocking PTB (quite a standard setup)

Then the person who deployed that should be shot and/or taken away his
internet license (really bad that these do not exist except as Cisco
certificates which are meaningless).

It is not the way to deploy servers (from the point of filtering ICMP
and from the point that deploying firewalls which likely have state
means that you are more suspectible to DDoS).

> 3) Clients experience a high level of brokeness, especially on 
>    streaming sites and with larger transfers, typical of MTU issues

Please realize that the MTU issue is created because of the tunnel you
are forcing upon your customer. If the point in 2) did not happen there
would not be any issues.

The only real solution to this is to contact the remote provider and
hammer on them to not be stupid. And yes, that is a big issue, but it is
the only way to REALLY resolve it.

See also 1)

> 4) Setting the MTU to 1480 in RAs on the LAN removes all issues as far 
>    as we can tell (TCP MSS is lower and everyone is happy everafter)

It only "solves" it for TCP indeed due to the MSS, it does not solve it
for anything else that is UDP, SCTP etc.

To make it clearer: when a streaming site switches to UDP it will all
break again.... as TCP's MSS is only for TCP.

> This is why both Linksys and D-Link both lower the MTU to 1480 on the 
> LAN when 6RD is enabled.

That is great, but it does not really solve the problem.

Instead of setting the MTU though, you could rewrite the MSS on the
gateway, that is a much better solution in that case...

> If there's a better way to do this that 
> works in the real world, I'd be happy to try it. So far, in my 
> opinion, IPv6 PMTUD seems to be a fail. There's no way to fix all 
> the content out there to make sure PTB gets through. 

I unfortunately have to fully agree with that statement.... :(

The real world is a nasty place with stupid people. Fixing stupid people
filtering ICMP will never happen, but really, it is the only way to go
in the long term.


But I would propose that instead of changing the MTU on the LAN, to then
force the MSS, this is what people have been doing for IPv4.

Note that you could deploy such a fix for all your customers on your 6rd
gateway. Of course, it is not entirely nice to rewrite your customer's
packets, but if you are set to fix that for them like that, then it
might be the way to go.

Alternatively of rewriting all packets, identify the broken destinations
and route those through a rewrite rule/box.

Greets,
 Jeroen