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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
