Re: implications of 6to4 for v6coex

[Nathan Ward <v6ops@daork.net>]

On 16/09/2008, at 7:35 AM, james woodyatt wrote:

> I had an extensive discussion off-list with Nathan Ward about this,  
> and he helped me refine my ideas considerably.  When I get the time  
> to work on my draft, it will include a better-composed justification  
> for allocating a new special-use block.
>
> Again, my purpose is to address the technical concerns I've heard  
> expressed from service providers who do not want the IPv4 interface  
> addresses of their 6to4 relay routers (and, yes Teredo relays too)  
> from being disclosed *at* *all* outside their networks, i.e. not  
> just kept out of BGP-- because they do not feel that ingress  
> filtering is practical, and that it wastes global IPv4 addresses,  
> and finally that they don't want to deal with realm conflicts  
> associated with using RFC 1918 for both subscriber networks and  
> relay router interfaces.
>
> In any case, we've heard technical objections from service providers  
> on the V6OPS list to deploying 6to4 and Teredo relay routers before,  
> and it seems like either A) those objections will need to be  
> addressed for IPv4-IPv6 coexistence to work, or B) we should  
> deprecate those transition mechanisms for which we cannot satisfy  
> the legitimate technical concerns of very large service providers  
> actively resisting the deployment of necessary relay routers.


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