So, James' point here about the IPv4 interface being visible outside
the provider seems strange at first - as we all assume that that
address will be 192.88.99.1, so anyone trying to steal bandwidth
using 6to4 would be sent to the nearest 192.88.99.0/24 instance, and
if the provider in question does not advertise it outside their AS
it will be no problem.
However, RFC3068 says:
<snip>
Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
also provide an equivalent IPv4 unicast address. Packets sent to
that unicast address will follow the same processing path as packets
sent to the anycast address, i.e., be relayed to the IPv6 Internet.
</snip>
Cisco's 6to4 implementation does not allow this. Neither does
FreeBSD's.
(Though, myself and colleagues have been able to do things to make
it work on both platforms, but none of that is in the config
examples you can find around the web)
I can't recall what Linux's implementation does.
I don't see a need for that paragraph in the RFC, and unless there's
a reason for it, I think we should remove it, which in my
understanding removes this whole problem.
For more fine grained control of who uses your relay, there is no
reason you couldn't create a '6to4' MPLS VPN, and leak the
192.88.99.0/24 prefix to their customers who you wanted to receive
service from their relay.
Result is, transit customers get to some public relay, but end users
on your network (say dsl or cable or whatever) get your 6to4 relay.
Also, as per Christian's followup comments, Teredo is far different
to 6to4 - the IPv4 address must be exposed for it to work.
If you don't want people to 'trombone' through your Teredo relay,
put an ACL on there that permits traffic coming from the relay to be
only from 2001::/32, and to only your IPv6 networks. That's much
easier than attempting to keep state and things, and it's something
that you can do right now.
--
Nathan Ward