On Jul 3, 2011, at 10:58 AM, Arturo Servin wrote:
On 3 Jul 2011, at 11:40, Keith Moore wrote:
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.
And b.
And probably it is too much effort for something that will go away
(probably sooner that we expect) with the exhaustion of IPv4 addresses for
each ISP's customer (6to4 does not work with NATs, and they are here).
It's clearly inappropriate for operators to be filtering protocol 41. Not
only does this break 6to4, it also breaks other tunneling mechanisms. More
generally, it's inappropriate for operators to be favoring one kind of traffic
over another.
The ISPs I've talked to tell me that they see no reason why static, public IPv4
addresses cannot continue to be given to those that request them, indefinitely,
as long as they're paying for business service.
If the overriding concern is that imposition of LSN will break 6to4 even more
and thus generate even more support calls, that's understandable. However:
- LSN will break a lot more than 6to4, and generate support calls for many
other reasons, and this shouldn't surprise anyone.
- declaring 6to4 Historic will not reduce the number of support calls, while
the above measures will.
The most effective single measure that I can see to reduce the number of 6to4
support calls is to get OS vendors to patch their customers' systems to
implement (e), and perhaps (d), ASAP. That shouldn't break 6to4 for anyone
who is using it as a means of supporting IPv6 apps, and it should reduce the
largest source of complaints both from users and content providers.
(The reason I say "perhaps" (d) is that (d) would break those who are currently
depending on 6to4. "Off by default" is perfectly appropriate for new
installations, but not necessarily so for automatic updates.)
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf