[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implications of 6to4 for v6coex
On Sep 16, 2008, at 16:05, Antonio Querubin wrote:
On Tue, 16 Sep 2008, james woodyatt wrote:
The complaint I have heard is that simply not advertising the
routes to third parties is not enough to prevent them from using
static routes to steal relay service.
If they're afraid of that, why can't they just block access to the
relay address via ACLs at their borders? Most ISPs probably do some
kind of filtering at their border anyway. Adding one more deny rule
isn't gonna make a big impact on performance.
Yes, the existing RFCs recommend filtering at the border gateway and
limited routing advertisements to trusted peers. So, why do service
providers think they can't secure their 6to4 relay service that way?
They must have a legitimate reason, don't you think? Surely, they
aren't trying to sabotage the IPv4-IPv6 transition by splitting the
public IPv6 internet into three parts (one for native, one for 6to4
and one for Teredo), right?
Again, it would be better if an authoritative voice recommending
*against* the deployment of 6to4 and Teredo relays in service provider
networks, because of concerns about limiting access to relay services
to their subscribers only, would step in here and speak to the issue
directly. I've only gathered from talking with people that the
problem with ACLs at the border routers is that a real deployment plan
would require too many ACL entries, i.e. one for each relay, because
relays would have to be in lots of different places around the
interiors of their networks, and addressed accordingly.
Won't somebody from a service provider *please* step up and explain
why they cannot and/or will not deploy 6to4 relay routers for the use
of their subscribers as the standards track documents currently
describe them? The continuing silence from the operations community
on this topic is very troubling, but I suppose it's possible everyone
is still enjoying their copious allotment of holiday time.
It *is* September, though, isn't it?
--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering