fp.o content via IPv6

[Allen Kistler]

Daniel Drown wrote:
> 
> [snip]
> 
> I also have 6to4 setup on my home machine.  I'm no IPv6 expert (or networking
> expert, really), but I believe two things should be happening here:
> 
> 1. the packet too big ICMP message should be coming from your tunnel box

Hmm...  To keep the response relevant to Fedora infrastructure, maybe
the way for most readers to approach this message is as generally
informational in nature.

Pardon the ASCII art:
                                           Client           Client
 e.g., Fedora     Some ISP   asymmetric   Premises         Premises
 +-----------+  +------------+ tunnel +-------------+  +-------------+
 | IPv6 site +--+ 6to4 Relay +--------+ 6to4 Router +--+ IPv6 Client |
 +-----------+  +------------+  IPv4  +-------------+  +-------------+

"big" packet -->|(death)

Big packets die at the ISP, before they enter the tunnel, because
they're too big to enter the tunnel.  The client 6to4 router has no
opportunity to know the packet even existed in the first place.

> 2. the MSS and path MTU should already be set even before it gets to this
>     point, in the router advertisement messages.

Using Path MTU Discovery, both sides of the tunnel should be able to use
ICMP to find

  Path MTU = Min(Link MTU).

> I suspect that since you have a smaller MTU than default, changing the MTU on
> your tunnel interface should solve the #1 problem (ip -6 link set dev tun6to4 mtu
> 1472)

It's already done by ifup-ipv6 and network-functions-ipv6.
F9 and earlier used 1480 always (BZ #478441).
F10 and later use (IPv4 MTU - 20) correctly.

> Changing your radvd.conf (if you're using radvd) to have "AdvLinkMTU 1472;"
> should fix #2.

... at the cost of all IPv6 routes through the box, not just the 6to4
one.  It also wouldn't work for segments more than 0 hops away from the
6to4 router, and therefore unable to hear its advertisements.  Path MTU
Discovery *should* work (in an ideal world, even though it doesn't for
me for fp.o).  MTU Discovery works outbound, but apparently sometimes
not inbound for me.

radvd *is* another variable to tweak, though it still won't help
anything that's not TCP.  For things that aren't TCP, anything on the
other side of the tunnel has no clue what the tunnel MTU is unless it
tries to discover it.  Of common protocols, only TCP has anything like
the MSS option to give a hint to the other side.

> [snip]
> 
> (I should mention that curl over my 6to4 tunnel works fine with a mtu of 1480
> getting the fedoraproject front page)

Unfortunately the reliability of access through 6to4 is geographically
dependent.  Previous to fp.o, I had no MTU problems with access to sites
through IPv6.  You may simply be geographically luckier than I am.

The intent of the drafters was that, as dual-stacked ISPs multiplied,
they'd deploy 6to4 relays for their IPv4 customers to get access to
IPv6.  As nearly as I can tell, that doesn't seem to be happening very
much.  When it does happen, it's not a smooth operation.  That's not a
rant.  It's just an expectation that globally developing expertise in a
new protocol won't be painless.  Where does Fedora want to be in that?