On 6to4 gateway and recommended MTU setting

[Martin Millnert]

On Thu, 2010-03-11 at 12:39 +0000, Martin List-Petersen wrote:
> 1280 has sort of been adapted for 6in4 tunneling and thus most 6to4
> implementations follow that same setup.

If ->all implementations configure 1280 (which they seem to do, except
Linux), where will the hurt be in a relay having >1280?

Not in 6to4-node -> relay -> v6 internet, at least.
In the reverse path (v6 internet -> relay -> 6to4-node) there can
obviously be problems on the IPv6 internet, but that's the general IPv6
internet case today and the MTU of my relay will not change this one way
or another.
  On the v4 side of the reverse path however, there can be a difference
and this is what I was originally wondering about. This sort of
operational feedback is what I believe is missing from the relevant
RFCs. Perhaps its obvious to most, it wasn't to me.

While speaking about RFC:s, 3056 clearly states that anyone running a
relay at 192.88.99.1 that is announced MUST also operate the gateway
with a unicast address, for trouble shoot purposes. ~nobody does that.
It helpfully leaves out *how* a end-user is supposed to find his
equivalent unicast address though. :)
[ http://tools.ietf.org/html/rfc3068#section-4.5 ] So RFC's only go so
far. Operational feedback is strictly necessary and this is ipv6-ops
after all. :)

Me toying with 6to4 isn't that big of a problem, nor is any time that
could be better used on other v6 things wasted, to the best of my
knowledge; we already provide native v6 to our users since long ago, we
dual-stack web servers, we operate v6 DNS and announce v6 resolvers to
customers. We do everything short of knocking doors and talking with
them about why they should spend 50€(?) on a WiFi router that handles
native IPv6 while NAT:ing IPv4.
  Other suggestions for what we should do for IPv6 at this point are
welcome.


Thanks all who responded. I've configured our relay to 1280 now. 

Cheers,
-- 
Martin Millnert <martin at millnert.se>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100311/4e9af4b1/attachment.sig>