ietf
[Top] [All Lists]

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

2011-07-03 09:34:24
On Jul 3, 2011 7:14 AM, "Keith Moore" <moore(_at_)network-heretics(_dot_)com> 
wrote:

On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote:

In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote:
Unfortunately, in the 20% of the time that it's not working, Google has
no
idea that the user has a 2002::/16 address. Google only knows, after
the
fact, that the user suffered a 20 or 75-second timeout and was not
happy. So
it would serve no purpose to avoid serving users that successfully
connect
from 2002::/16 addresses; once the AAAA record is handed out, the
damage is
done. What Google could do, however, is stop handing out AAAA records
to
networks that have significant number of 6to4 users in the future.
We're
considering this.

I think this clearly illustrates why the IETF should issue a strong
statement
that no new 6to4 installation should be deplayed and the existing 6to4
users
should migrate to other tunneling techniques (if native is not
available).

I think this clearly illustrates why IETF should issue a strong statement
that

a) operators of 6to4 relays should not advertise those relays via BGP
unless they're routing traffic for all of 2002://16 or native v6,
respectively
b) operators should not filter protocol 41traffic
c) (maybe) operators using LSN should use RFC 1918 addresses behind those
NATs unless/until there's another address range that 6to4 host
implementations know about
d) 6to4 should be disabled by default in both hosts and routers
e) host implementations should prefer native v4 destinations over 6to4
destinations when both are available and the application can use either IPv4
or IPv6


You will not get "consensus" on these statements in the IETF or by the
various companies that implement gear and networks in the REAL world.

Can we let this thread die now? If the ietf will not kill 6to4, there are
several other methods to deal with it in the REAL world (dns whitelisting,
null routes, rfp's, blocking aaaa on ipv4 ....). Just like the NAT debacle
of years past , the IETF has once again proven its irrelevance.

Thanks for your time and have a great weekend.

Cb

Saying that no new 6to4 installation should be deployed and that existing
6to4 users should migrate to other tunneling techniques assumes that all
installations and users have the same needs, namely, to access content over
IPv6 that is also available over IPv4.

The problem with 6to4 is it was rolled out on a relatively large scale
when
there was essentially no IPv6 content. As a result, the people who had a
broken 6to4 setup would only find out when content providers would start
adding AAAA records.

In other words, it was ticking time bomb.

The label "broken 6to4 setup" is misleading.   Most of the time, the thing
that breaks 6to4 is not the user's "setup"; it's an ISP somewhere that is
either (a) advertising a bad relay or (b) filtering protocol 41.   (If the
problem were the users' setups, the providers could just say "not our
problem; fix your 6to4 setup")

What worries me is that people will start using 6to4 for bittorrent.
Bittorrent
will of course completely hide broken setups and worse, it will also
hide
broken 6to4 relays.

From my understanding of bittorrent, it will just find other routes.

And all of this, because a few hobbyists are afraid that declaring 6to4
as
historic will require them to search a bit harder in the furture for a
router that supports 6to4.

You completely misunderstand both the situation, and the size and
diversity of 6to4 users.

Keith

_______________________________________________
v6ops mailing list
v6ops(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf