On Jun 7, 2011, at 4:48 AM, Ole Troan wrote:
I'm loathe to go through this discussion again. let me just respond to some
of the points you make, and then agree that we disagree.
I'm also loathe to go through the discussion again. It shouldn't be necessary.
6to4 has long been useful, and continues to be useful, for some cases. It's
appropriate to document problems with 6to4, perhaps revise its applicability
based on experience, and also to publish recommendations for how to manage 6to4
relays, and to urge removal of broken relays and/or filtering of their routing
advertisements. But deprecating it is entirely premature. (When I recently
asked local ISPs when they'll be offering IPv6 support, their answer was
"what?". )
(It could be argued that reclassification of RFC 3068 (by itself) to
Historic is appropriate, but that would require a separate document and last
call.)
In addition, this document is misleading and perhaps even vituperative.
For instance:
"There would appear to be no evidence of any substantial deployment of the
variant of 6to4 described in [RFC3056]."
This statement is blatantly false. 6to4 is supported by every major desktop
and server platfrom that is shipping today, and has been supported for
several years.
incorrect. there is no evidence that the _managed_ model of 6to4 described
in rfc3056 has any deployment.
that's the model where relay operators advertise what parts of the 6to4 space
they are routing. with BGP neighborships between managed and participating
relays.
_deployment_ not _support_.
The recommendations of the proposal are overkill anyway. But assuming there's
some merit in writing an applicability statement for 6to4 (and I think there
might be), this text should be clearer and more balanced.
And I'm not sure where you get the idea that RFC 3056 recommends that relay
operators advertise what parts of the 6to4 space they are routing. 3056
doesn't say anything about BGP advertisements for IPv4, as 3056 assumes there
will be a manually configured relay router. As for advertisement of IPv6
prefixes, the idea has always been that we didn't want to incorporate the v4
routing table into v6, so 3056 specifically says that the only prefix
advertised in BGP should be 2002::/16. (Obviously no such prefix should be
advertised if the router isn't willing and able to route to the entire
2002::/16 space, i.e. arbitrary addresses on the public IPv4 network.)
"The IETF sees no evolutionary future for the mechanism and it is not
recommended to include this mechanism in new implementations."
6to4 never was intended to have an "evolutionary future". It was always
intended as a near-term solution to allow consenting hosts and networks to
interchange IPv6 traffic without prior support from the IPv4 networks that
carry the traffic. It is premature to recommend that 6to4 be removed from
implementations. We do not know how long it will take ISPs to universally
deploy IPv6. Until they do, there will be a need for individuals and
enterprises using IPv6-based applications to be able to exchange IPv6
traffic with hosts that only have IPv4 connectivity.
All of the criticisms in section 3 have to do with the use of relays to
exchange traffic between 6to4 and native IPv6. In many cases the
criticisms are overbroad. Not all uses of 6to4 involve relays. For some
of those that do need to use relays, it is not necessarily the case that the
relay is operated by an unknown third-party.
The fact that some firewalls block protocol 41 traffic causes problems for
many tunneling solutions, not just 6to4; yet this document appears to
recommend some tunneling solutions while trashing 6to4.
it is the unmanaged aspect of 6to4 deployment that exhibits the most
problems. a manually configured managed point to point tunnel may also be
blocked in a firewall, but then the operator will have to sort that out. 6to4
has no operator.
Indeed, that is one of its main virtues. 6to4 decouples application deployment
of v6 from network deployment of v6, and helps reduce the "chicken or egg"
problem.
(At least, that's the intent. Reality is that 6to4 does have some impact on
the network, at least where relay routers that publicly advertise prefixes
through BGP are concerned. But 6to4 is useful - admittedly in corner cases -
even without relay routers.)
Teredo is similar in many aspects to 6to4, but there is little evidence that
it causes the same problems. largely because it is the choice of last resort
in implementations and it hasn't/can't be enabled by default in CPEs.
Bogus argument. Teredo has a different set of problems than 6to4 - higher
overhead, not as scalable, dependent on a single provider for relays, not as
widely deployed in hosts, etc. If you're seeing fewer problems with Teredo,
it's because it's not used as much as 6to4 is (in part because it has more
problems) - not because there are fewer problems with it overall. In other
words, you're blaming 6to4 for its relative success.
I think it's fair to say that 6to4 didn't anticipate the degree to which relay
routers and their BGP advertisements need to be monitored, and it failed to
make recommendations for this. But the same is true for IP. When you get a
BGP advertisement for a prefix that goes to a router that drops the packets,
you have to deal with it. When you get a BGP advertisement for a 6to4 router
that isn't working properly, you have to deal with that too. The 6to4 relay
problem may appear worse than the normal bogus route advertisement case because
all of the 6to4 related bogus BGP advertisements are for the same two address
prefixes (one IPv4 and one IPv6). But from where I sit, I can't tell that it's
a worse problem overall.
The recommendations to treat 6to4 as a service of last resort will do harm
to users and applications using it. A better recommendation is for hosts
to disable 6to4 by default.
This document appears to make the mistake of assuming that the purpose of
applications using IPv6 is to interoperate with the existing Internet. I
have maintained for many years that it is new applications, or existing
applications that can't tolerate widespread deployment of IPv4 NAT, that
will drive use of IPv6. I therefore believe that it is inappropriate to
judge 6to4 merely by how well it works in scenarios where it is being used
to talk to applications that work well over IPv4 NAT such as HTTP. The
Internet is much more diverse than that, and will become even more diverse
as IPv6 enjoys wider deployment.
6to4 does not work through IPv4 NATs.
6to4 can work through IPv4 NATs. Some NATs support 6to4 (and act as NATs for
v4, routers for v6). Other NATs can be manually configured to pass protocol
41, and to have that traffic handled internally to the interior network.
Admittedly, 6to4 does not work though LSN. I see that as a bug in LSN, if it
doesn't provide a well-defined way for customers to get equivalent
functionality to 6to4.
It is also premature to remove references to 6to4 from RFC 5156bis, for IANA
to mark the prefix and DNS zones as deprecated. This will only cause
confusion and difficulty for legitimate continued uses of 6to4.
the purpose of the text in the document is to ensure that the deprecated
prefixes are not reused before 6to4 has been phased out.
Just leave the allocation as-is until it really is time to deprecate 6to4.
Frankly I don't expect that to happen for another 5-10 years, but I'd love to
be surprised at the rapid acceleration in native IPv6 deployment.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf