On Jul 3, 2011, at 10:32 AM, Cameron Byrne wrote:
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.
why not? all of those recommendations are clearly appropriate and desirable,
with the possible exception of (c) because ISP use of RFC 1918 addresses is
likely to conflict with customer user of the same address ranges.
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.
and the attitude from v6ops reminds me of nothing so much as a lynch mob. it
has gotten way out of hand.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf