Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't know if it is intentional, however if I use Google's public 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 (via /etc/gai.conf under Linux/glibc), it seems that the video content of all youtube videos is now being delivered over IPv6. Yes, YouTube videos are currently being served on dual-stack hostnames. The percentage of YouTube users that uses 6to4 is less than 0.02%. The percentage of YouTube users that uses native IPv6 is approximately 0.2% - over 10x more. That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? I'm having and have been having 100% success rate (or near enough to it that I can remember) using 6to4 for a number of years, including with an IPv6 MTU of as large as my PPPoE connection will support i.e. my 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos are coming over IPv6, I've paid a bit more attention to the quality of experience I've had, and have not found any reasons to change my preference back to native IPv4 instead of 6to4. Sure - you're one of the 80% for whom it works. But that wasn't my question - my question was what is the advantage? You said that you have near enough 100% success rate, but I bet that your IPv4 success rate is near enough 100% as well. So what are you gaining by using 6to4 to talk to YouTube? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.comwrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, and that case 2 is today solved more reliably, and in more cases (e.g., when no public IPv4 address is available at the border) by the various NAT traversal mechanisms that are implemented in applications. But I think we're just going around in circles here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews ma...@isc.org wrote: ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. No, because you often end up being dependent on the whims of BGP and third-party relays for your return path. Sure, if you have enough control over routing in a closed network, you can make sure the right relays are used. But in that case, why not use configured tunnels? 6to4 historic is throwing the baby out with the bath water. On this we know we disagree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, 15 Jun 2011 18:43:23 -0700 Lorenzo Colitti lore...@google.com wrote: On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews ma...@isc.org wrote: ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. No, because you often end up being dependent on the whims of BGP and third-party relays for your return path. If you generalise that statement a bit, No, because you often end up being dependent on the whims of BGP and third-party routers for your return path. you're describing the trust inherent in the operation of the Internet, both for IPv4 and IPv6. Yes there are some incompetent operators out there, but most of them aren't - they wouldn't keep their jobs otherwise, and the Internet would break more often than it does. I can only remember one instance of 6to4 relay breakage in the last 5 years, and IIRC that was fixed within 24 hours. People seem to be using a very coarse less than absolute 100% success means total technology failure to state that 6to4 as a whole is unreliable. Where is the data to back this up? Did Geoff Huston do any more detailed analysis of the 6to4 data, other than measuring success verses failure rates for 6to4 connections? Could I, for example, have warped his 6to4 failure rates during the test if I used all my 2^16 x 2^64 IPv6 6to4 addresses to purposely create excessive failed 6to4 connections apparently from many different hosts? I'm certainly not saying that exists in Geoff's data, rather asking how do we know that it doesn't? I have a vested interest in anycast 6to4 continuing to exist, because it has been as reliable as any other Internet technology I use. I also think it has some latency advantages over configured tunnels because my IPv6 traffic enters the IPv6 Internet where ever the closest 6to4 relay reachable via IPv4 is. That used to be in Europe (around 14000 Km from me) when I first started using 6to4, now it is only around 3000 Km, and as my ISP is going to deploy a 6to4 relay in the near future, will be around 8Km away. These changes have and will continue to be transparent on my end. I'd also get these latency benefits if I was changing my IPv4 Internet points of attachment, such as if I were travelling internationally. Anycast 6to4 also tends to distribute the IPv6 traffic load better across all the 6to4 globally gateways, instead of concentrating it at likely lower number of configured tunnel entry/exit points. Over time, increased IPv6 traffic will become a disincentive to running a configured tunnel entry/exit point because people will continue to use it even if there is a more local configured tunnel or 6to4 relay they could be using. If people use anycast 6to4, then they inherently get lower latency as a closer one becomes available, and 6to4 relay operators will see lower traffic load without intervention as more 6to4 relays are deployed. Sure, if you have enough control over routing in a closed network, you can make sure the right relays are used. But in that case, why not use configured tunnels? 6to4 historic is throwing the baby out with the bath water. On this we know we disagree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: I have a vested interest in anycast 6to4 continuing to exist, This actually brings up a good argument: are you going to pay for us to run our 6to4 relay? not that the cost of it is high, but there is cost to it - to make sure it keeps working, to monitor the system for overload, etc. Our customers don't really need it (because we have native IPv6), we're offering this for free to benefit users on the other side that do not have native IPv6, but insist on not using IPv4. And this also points out why anycasted 6to4 is necessarily(!) less reliable than those other Internet technologies that you have mentioned - because those that run the relays usually have no financial interest in doing so. So if it breaks, it will take longer to notice and even longer to fix than for something that directly affects paying customers. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi Gert, On Thu, 16 Jun 2011 08:51:26 +0200 Gert Doering g...@space.net wrote: Hi, On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: I have a vested interest in anycast 6to4 continuing to exist, This actually brings up a good argument: are you going to pay for us to run our 6to4 relay? not that the cost of it is high, but there is cost to it - to make sure it keeps working, to monitor the system for overload, etc. It was a conscious decision of yours to announce it globally, so you've made a conscious decision to provide it to people for free and to take on the operational responsibilities of doing so. If you become unhappy with accepting those costs without corresponding compensation, withdraw the 6to4 anycast IPv4 address from the global route table, and people like me would move onto another 6to4 relay automatically. I certainly don't take for granted people's generosity in providing them to global users, however I think that if you choose to do something charitable, you have then created an obligation on yourself to do it well and reliably. Most people both understand and deliver on that obligation. I've actually become more conscious of this lack of financial incentive since I've noticed that youtube videos are coming to me over IPv6. That's what prompted me to ask if my ISP was planning to deploy a 6to4 relay soon as an interim step towards their native service. Our customers don't really need it (because we have native IPv6), we're offering this for free to benefit users on the other side that do not have native IPv6, but insist on not using IPv4. And this also points out why anycasted 6to4 is necessarily(!) less reliable than those other Internet technologies that you have mentioned - because those that run the relays usually have no financial interest in doing so. So if it breaks, it will take longer to notice and even longer to fix than for something that directly affects paying customers. Actually, a broken local 6to4 relay is likely to be impacting your paying customers too as it is their local 6to4 relay. Your arguments are not specific to 6to4 though - I think they apply to anybody providing a free configured tunnel service too. In some cases they apply more so - the administrative effort to support automated provisioning of configured tunnels is greater than that involved in setting up an anycast 6to4 relay. Regards, Mark. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
The youtube folks made the decision to leave the video-serving hostnames available in blacklist-mode, meaning only very broken networks won't get s. This is being watched, and could easily change back. The exact policy for blacklisting has yet to be fully formalized. But re: 6to4 in this case, it still gains you nothing you didn't already have while risking randomly crappy performance. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, 14 Jun 2011 10:59:47 -0700 Lorenzo Colitti lore...@google.com wrote: On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. I don't know if it is intentional, however if I use Google's public 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 (via /etc/gai.conf under Linux/glibc), it seems that the video content of all youtube videos is now being delivered over IPv6. The same thing happens if I use my ISP's resolvers - I know they're doing IPv6 work behind the scenes, however I don't know but dont think their resolvers are Google whitelisted. That suggests that if there are hosts out there that blindly prefer tunnelled IPv6 over native IPv4, and have 6to4 available, there is a likelyhood that more people are using 6to4 now than there was before World IPv6 day. I'm having no performance problems at all with any videos I select, including 1080P ones. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? I'm having and have been having 100% success rate (or near enough to it that I can remember) using 6to4 for a number of years, including with an IPv6 MTU of as large as my PPPoE connection will support i.e. my 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos are coming over IPv6, I've paid a bit more attention to the quality of experience I've had, and have not found any reasons to change my preference back to native IPv4 instead of 6to4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, 14 Jun 2011 16:05:33 -0700 Erik Kline e...@google.com wrote: The youtube folks made the decision to leave the video-serving hostnames available in blacklist-mode, meaning only very broken networks won't get s. This is being watched, and could easily change back. The exact policy for blacklisting has yet to be fully formalized. But re: 6to4 in this case, it still gains you nothing you didn't already have while risking randomly crappy performance. A less used content cache could give me better performance. Not that it has happened recently, however in the past there have been IPv4 delivered performance issues with youtube here in .au. That's the reason I've paid a bit more attention to the quality of IPv6 delivery and tried 1080P videos when they've been available. Regards, Mark. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 14, 2011, at 1:59 PM, Lorenzo Colitti wrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network again, trying to judge how well 6to4 works by how well it works with web sites that also support IPv4 is entirely missing the point. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 15, 2011, at 7:10 PM, Lorenzo Colitti wrote: On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.com wrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. A single figure doesn't really describe the situation. The successes/failures aren't independent of one another. It's not that you get only an 80% probability of things working on every connection. It's more like, it either works fairly well for what you need it to do, or it doesn't. Again, don't assume that this is like the web and the connections are mostly client-to-server, or one source to large numbers of different destinations. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, There are lots of different tunneling methods each with strengths and weaknesses. What you probably do in practice is try one, and if that doesn't work for your purposes, try another. 6to4 is very easy to try, and it often works. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
In message BANLkTi=ggay2u0sx54hnv7bz7qdgrajz9h+8rwhmwkjk+9s...@mail.gmail.com , Lorenzo Colitti writes: On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.comwrot e: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, and that case 2 is today solved more reliably, and in more cases (e.g., when no public IPv4 address is available at the border) by the various NAT traversal mechanisms that are implemented in applications. But I think we're just going around in circles here. Which often times requires special software to be installed. Tunnels are a lot more hassle to setup and yes I've used both so I know. 6to4 historic is throwing the baby out with the bath water. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 14 Jun 2011, at 18:59, Lorenzo Colitti wrote: On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Running the relay inside your network lets you correlate the failure rate you observe to the direction of the path the failures occur in, though. That data may be valuable to you. And since it's HTTP we're talking about, it might be a consolation to know that it's your side of the network generating the most traffic. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. Your (Google's) problem is the relays. So, if we take this thought a step further, by deploying (no, I'm not suggesting you do this, obviously) a 6to4-reachable presence you may actually reduce the total traffic by volume reaching you over native IPv6, if it transpires that 6to4 is a good portion of the majority of tunnel traffic, the vast majority of IPv6 traffic reaching you. That's not to speak of address selection algorithms which would do the right thing (in theory) given the choice of native or 6to4, of course. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. That's a real shame, because the use of peer-to-peer applications is a solid reason to turn various tunnel techniques on. One popular Windows BitTorrent client makes it a single-button operation; others simply take the IPv6 connectivity for granted, when available. See: http://thepiratebay.org/blog/146 Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? I agree, this would be a good thing. That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? Others have beaten me to this one but I will say one thing in your favour: NAT traversal techniques are ubiquitous and, curse them, actually fairly transparent. This is probably a good thing and it does support your view that at least in the case of BitTorrent or other vanilla address-neutral protocols the end-user transparency really doesn't usually justify the added tunnels for v4-to-v4 communication, regardless of technical impropriety. However this does nothing to address other real concerns, most of them brought up by Keith already. Most importantly, new protocols or uses of the Internet shouldn't be sabotaged by the need for some sort of imaginary all-or-nothing transition to IPv6. One final thought: assuming we ever get to the stage of minority native IPv6 worth service providers' time to set up IPv6 reachability for, and not just the big ones either, what exactly do all the tunnel brokers of the world do about the sudden demand for their services? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. ... So the existence of 6to4 is in itself a significant barrier for IPv6 deployment Surely you meant to say the _incorrect configuration_ of 6to4 is in itself a significant barrier? You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. I get the impression that the problem comes in when 6to4 is configured on by default, and too high in the priority list (as opposed to native, other methods, etc). So fix the real issue, don't try and prematurely kill off something that's being used by lots of people. I fundamentally disagree. I really don't think that 6to4 is used by lots of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt j...@apple.com wrote: I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Yes, of course. I was trying to keep it short. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 10, 2011, at 09:38 , Lorenzo Colitti wrote: I fundamentally disagree. I really don't think that 6to4 is used by lots of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. The same is often said about IPv6 in general. That's not meant to be snarky quip. When you limit the population under observation to just current IPv6 users and leave out the vast teeming masses of people who are routed IPv4-only, I suspect the data will show that a significant fraction of people are still using 6to4 as a general network-layer NAT-avoidance mechanism because it continues to work for them, setting up a manual tunnel-broker account takes an order of magnitude more effort, and who has time? Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore mo...@network-heretics.comwrote: 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. No, it does not - in fact, it is the opposite. Geoff has presented data that shows that anycasted 6to4 as a connectivity mechanism has a failure rate of the order of 20-30%. We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. Search the list archives for details. So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. And if you believe the access networks, the lack of IPv6 content is one of the most significant barriers to IPv6 deployment in access networks. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore mo...@network-heretics.comwrote: Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. No, we're trying to make their lives easier, by suggesting they use something that actually *works*. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. So use a tunnel broker. You're missing something. I can connect directly from my mobile laptop to a machine in my home network using 6to4. Really? From where? On none of the networks my laptop connects to do I get a public IPv4 address. Some of them do give me have native IPv6 or manually-tunneled IPv6 though. We can disagree about the meaning of the word widespread, but the practical fact is that you can't expect people to give up something that works for them until you can provide them something that works better *for them. Available to 50% of Internet service customers is equivalent to a very small percent probability of native connectivity being able to replace 6to4 connectivity in a scenario where 6to4 is currently working. And the more hosts involved, the smaller that probability is. * You cannot claim that 6to4 is working when there is data that shows that it has a 20% failure rate. If we had that sort of connectivity in IPv4, we wouldn't have an Internet. Existing content providers are not going to drive adoption of IPv6. They're going to follow it. Nope. Look at World IPv6 day. If you look at the list of participaints, I'd say that probably more than 10% of Internet content, either by bits or by query volume, is ready for IPv6 now. Our data shows that access is at 0.3%. So you could say that in fact content *is* driving adoption of IPv6. We just need to get unreliable tunneled connectivity out of the way so we can turn it on for real. Web and email will be the last applications to migrate. Um, no. See above. WEG Well, it'd be more harmful if there weren't alternatives. There aren't any good ones. Teredo and configured tunnels are worse in many ways; though they each have their use cases. Actually, configured tunnels are much better. They have a much lower failure rate and lower latency. We published data that shows the latency impact in our PAM 2009 paper. Regards, Lorenzo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore mo...@network-heretics.comwrote: Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. Please point at the data behind that assertion. In many cases in the past, such assertions have comes from networks that do not have the hardware capabilities to monitor native IPv6 traffic. I remember one case at the RIPE meeting where someone from AMS-IX observed about one of these presentations, I have more native IPv6 traffic on my exchange point than you have observed in the entire Internet. How is that possible? Needless to say, that presentation did not go well. Look at http://www.google.com/intl/en/ipv6/statistics/ That obviously does not see peer-to-peer traffic, but it does see IPv6 web clients, and just under 90% of those are native. The evidence is that people are using it. You're trying to subject it to test cases that are largely meaningless - because in those cases IPv6 (of any kind) provides no marginal value in the near term. So far, you have provided solid evidence that *you* use it, but not solid evidence that people are using it. Can you point to that evidence? Almost all usage of IPv6 today is in spite of ISPs. For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 be deprecated. Nope. As before, 90% of IPv6 is native, and it comes from a small number of large deployments. Maybe your ISP doesn't support it, but other ISPs do. It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. No, it is a barrier to ubiquitous IPv6 adoption. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore mo...@network-heretics.comwrote: So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. non sequitur. Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses. No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually configured tunnels in the aggregate? In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained. It's been awhile since I used manually configured tunnels (from a well-known tunnel broker). But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate. Please try again. You will be pleasantly surprised. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore mo...@network-heretics.comwrote: I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then. Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of don't solve the problem, but rather, stamp out the solution. Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6. In a similar way as Geoff measured 6to4 - looking at SYNs. From where? Again, the tunnels aren't taking the variety of paths that 6to4 connections are. It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole. From the same place that he ran the 6to4 measurements from? A few months ago I was trying to set one up, but I ran out of time. I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4. Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. Er, I'm currently on 2001:388:f000:: Do you have an algorithm that will tell you whether that is native or a configured tunnel? Not perfectly. But you can look at things like MSS and MTU. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Lorenzo Colitti lore...@google.com Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. ... So the existence of 6to4 is in itself a significant barrier for IPv6 deployment Surely you meant to say the _incorrect configuration_ of 6to4 is in itself a significant barrier? I get the impression that the problem comes in when 6to4 is configured on by default, and too high in the priority list (as opposed to native, other methods, etc). So fix the real issue, don't try and prematurely kill off something that's being used by lots of people. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Lorenzo == Lorenzo Colitti lore...@google.com writes: Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. Lorenzo No, we're trying to make their lives easier, by suggesting Lorenzo they use something that actually *works*. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. Lorenzo So use a tunnel broker. My tunnel broker has a machine with broken IPv4 routing, which they can't fix. It's been down for a week+ now. We had to renumber that location in time for World IPv6 day. We only had 6 machines that were using their non-autoconfigured addresses, so the rest was just a s///g in the DNS zone file. 6to4 would have turned this into my problem (which I could have fixed), but since some places like google refuse to run their own 6to4 relay, I can't really use 6to4 to talk to. Thanks. This all reminds of how killing the mbone killed multicast. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 10, 2011, at 10:43 AM, Michael Richardson wrote: This all reminds of how killing the mbone killed multicast. Getting grumpy email from van because I sourced more than 128Kb/s killed the mbone, it was a toy. joel___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. ISATAP meets both of these conditions: http://tools.ietf.org/html/draft-templin-v6ops-isops Fred ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 9, 2011, at 9:25 PM, Randy Presuhn wrote: Your argument seems to be that the peculiar operational characteristics of 6to4 should give it additional immunity to being declared historic. I don't find that argument persuasive. That's not my argument. My argument is that declaring 6to4 Historic is inconsistent with the way we've used Historic in the past - namely to label something that either 'hardly anybody uses anymore' or something that should be abandoned because a better alternative is now generally available. The history of multiple protocols that have been declared historic shows that vendors seem to care about that designation only when it is convenient for them to do so. Installed base, customer demand, operational considerations and so on all trump whatever the IETF might say about a historic protocol. This works both ways: folks might decide to kill something before it becomes historic, or support it long after. We can't compel people to continue supporting it any more than we can make them stop. At most, we can give them (hopefully convincing) reasons to change. If the SNMP experience shows anything, it shows that even that isn't enough. For that reason, I find it amusing when others write of killing 6to4. We don't have that kind of power. Declaring 6to4 Historic certainly won't prevent people from implementing it. But the proposed action is clearly intended to discourage implementation of 6to4. It says so explicitly. Of course some vendors will ignore it, but some vendors will probably not ignore it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 10, 2011, at 1:15 PM, james woodyatt wrote: On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions. thanks for clearing that up. I was pretty sure it wasn't true, but you saved me the trouble of reinstalling 10.6.4 to prove it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 10, 2011, at 11:20 , Keith Moore wrote: Declaring 6to4 Historic certainly won't prevent people from implementing it. But the proposed action is clearly intended to discourage implementation of 6to4. It says so explicitly. Of course some vendors will ignore it, but some vendors will probably not ignore it. I would absolutely agree that the document would be improved if this pointless recommendation were removed. I expect some perfectly reasonable people will still oppose it with understandable concerns. Nevertheless, I do think this particular recommendation is inconsistent with the consensus in IETF that a phase-out plan for 6to4 is unwarranted. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 8, 2011, at 7:20 PM, james woodyatt wrote: On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... Let's be very clear. This proposed RFC would not take away the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. I have also seen those claims in v6ops email (haven't caught up with all of it, but have seen a few messages). I don't buy the argument. Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations. You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it. (That would be a bit like declaring IPv4 Historic and discouraging new implementations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it. Legacy hardware and software that's still in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are clearly people using 6to4 in the Real World, it strikes me as disingenuous for its proponents to claim that the document will do no harm. Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. The authors are already free to abandon the effort and pursue more useful ends. Not only would publishing this do harm to 6to4 and its users, it would set a bad precedent. We're supposed to be working toward consensus, not trying to cause harm to things that people use. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: Its 'rough' consensus... I don't wanna rat-hole here, but imho send the draft onwards for publication asap please. I'm not even sure it's rough consensus within the v6ops group. Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus. And just to be clear on procedure: - you need more than rough consensus in v6ops, you need rough community-wide consensus. - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness. The best way to not rat-hole is just to drop the proposed action. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 8:05 AM, Keith Moore wrote: On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: Its 'rough' consensus... I don't wanna rat-hole here, but imho send the draft onwards for publication asap please. I'm not even sure it's rough consensus within the v6ops group. Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus. If you disagree the wg chairs conclusions as far as the wg process outcome and the document shepherds report which can you can find here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/history/ Then you should consider talking to the responsible ad or an appeal to the IESG. As far as I am concerned the accusation that the process has gone off the rails is a seperate issue from the merits or lack thereof of the proposal. And just to be clear on procedure: - you need more than rough consensus in v6ops, you need rough community-wide consensus. This is an ietf last call... - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness. Informational status was at the behest of the iesg, we have been advised that an informational document may confer historical status on a standards track document. The best way to not rat-hole is just to drop the proposed action. Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Thu, Jun 9, 2011 at 5:05 PM, Keith Moore mo...@network-heretics.com wrote: On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: Its 'rough' consensus... I don't wanna rat-hole here, but imho send the draft onwards for publication asap please. I'm not even sure it's rough consensus within the v6ops group.  Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus. There were quite heavy discussion and in the end, there were a few that was totally against it, the rest supported the document. No point in repeating that entire discussion here really, go back and look at the archive. And just to be clear on procedure: - you need more than rough consensus in v6ops, you need rough community-wide consensus. - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness. The best way to not rat-hole is just to drop the proposed action. Let's take a few step back and think about what we are trying to achieve here, what is our goal. IPv6 for everyone for any price? A IPv6 only world? A world where both IPv4 and IPv6 work or? I will claim our goal is native IPv6 along IPv4, and in the long run, IPv6 only. We don't need more tunneling of IPv6 over IPv4, that was okay 10years ago, maybe even 5 or 3 years ago. Now it is time to actual do the right thing and say let's do it properly, let's do IPv6 native. ...and stop discussing yesterdays technology. -- Roger Jorgensen      | rog...@gmail.com     | - IPv6 is The Key! http://www.jorgensen.no  | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 11:18 AM, Philip Homburg wrote: In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote: I have also seen those claims in v6ops email (haven't caught up with all of it , but have seen a few messages). I don't buy the argument. Clearly the inten t of this draft and protocol action are to discourage use of 6to4, particularl y in new implementations. You can't discourage use of 6to4 in new implementat ions without harming people who are already using it and depending on it. (That would be a bit like declaring IPv4 Historic and discouraging new impleme ntations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it. Legacy hardware and software that's still in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are clearly p eople using 6to4 in the Real World, it strikes me as disingenuous for its prop onents to claim that the document will do no harm. I think this is likely to happen anyway. In all discussions it has been come clear that 6to4 has nothing to offer for ordinary users, and that the situation is going to get worse over time (more NAT, more broken 6to4 installation). I don't buy the notion that ordinary users only use some small number of killer apps. ordinary users are quite diverse. I certainly agree that increased deployment of LSN will do harm to 6to4 and its users. This wouldn't bother me if ISPs were going to roll out a native v6 solution concurrently with LSNs, but my impression is that v6 support is going to lag LSN imposition. So for any CPE manufacturer is makes perfect sense to start planning on dropping support for 6to4 in future CPEs, or not add it at all, if they have yet to release firmware with IPv6 support. I agree that v4 CPE manufacturers, at least those for consumer applications where the networks are likely to be saddled with LSN, certainly should not automatically enable 6to4 in their products. There's some justification for their not implementing it at all. However it's my experience that consumer CPEs are often used to provide connectivity for small business customers also. In general, LSN is not suitable for those customers, and they could benefit from 6to4 support in the CPE. But I'm more concerned about the potential for this action to result in 6to4 support being prematurely removed from hosts, than I am about its effects on CPEs. This is independent of whether the protocol is declared historic. On the other hand, there is no reason why open source distribution would have to drop 6to4 support. As long as there are people to maintain it, it can stay. Also on other operation systems, as long as there is some sort of tunnel interface, you can implement 6to4. It is just a few lines of code, everybody can do it. A few lines of code imposes a significant barrier. I've done a fair amount of kernel hacking in the past, written device drivers, and brought up Linux and FreeBSD and NetBSD (in that order) on laptops back in the days when laptop hardware was really flaky and poorly documented and there was no support in the kernels for their network interfaces. I'm not scared of writing kernel-level C code. But I don't do it all the time, and realistically it would take me several days to fetch the source code, update myself on the build process, and figure out exactly how to re-insert 6to4 into the kernel. And that's for Linux or NetBSD - I have less familiarity with MacOS and other kernels. And I'd have no idea about how to retro-fit 6to4 into Windows if support for it were removed. I generally don't write code for Windows, but I am occasionally forced to use it. And somehow I suspect that my skills in this area are considerably more than the typical 6to4 user. So I don't see the big fuzz. If you want to use it, just create a web page that lists software implementation of 6to4 for every possible platform. And let the authors of the software know have much their software is appreciated. Similarly, I don't see why there's such a desire to deprecate 6to4 and declare it Historic. It's the first time I can recall a proposal to move something to Historic that was widely deployed, widely used, and for which there was no suitable and widely available replacement. Nor do I understand why, in an organization that is supposedly about building consensus, there's such a demand for a divisive and obviously harmful action. Generally the way you build consensus is by focusing on things for which there is wide agreement, and crafting compromises on the other things. But the proponents of this draft have taken a 'no compromise' position. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 11:19 AM, Joel Jaeggli wrote: If you disagree the wg chairs conclusions as far as the wg process outcome and the document shepherds report which can you can find here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/history/ Then you should consider talking to the responsible ad or an appeal to the IESG. As far as I am concerned the accusation that the process has gone off the rails is a seperate issue from the merits or lack thereof of the proposal. I agree that it's a separate issue, and should be treated separately. Again, I haven't read all of the discussion, probably won't have time to do that for several more days, and will withhold a decision about any process appeal until I've done so. (And frankly, if IESG wants to sabotage 6to4 also, I doubt that a process appeal would do any good. I'll argue vigorously for something that I think is useful and/or important, but I have no interest in making hard-working people's lives harder for no good reason.) And just to be clear on procedure: - you need more than rough consensus in v6ops, you need rough community-wide consensus. This is an ietf last call... indeed. I just wanted to counter the possibly-implied assertion that v6ops rough consensus was sufficient. - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness. Informational status was at the behest of the iesg, we have been advised that an informational document may confer historical status on a standards track document. I don't have a problem with the idea that an Informational document can describe the consequences of moving something to Historic. I have a serious problem with the idea that a standards-track document can be moved off of the standards track by less than an IETF Consensus process, or by ignoring the criteria for standards-track actions. I haven't seen any evidence that IESG is trying to do that - they are doing a Last Call after all. But I don't think we want to set a precedent that removing something from the standards track is easier or requires less scrutiny of the technical criteria than putting something on the standards track. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 11:24 AM, Roger Jørgensen wrote: I will claim our goal is native IPv6 along IPv4, and in the long run, IPv6 only. We don't need more tunneling of IPv6 over IPv4, that was okay 10years ago, maybe even 5 or 3 years ago. Now it is time to actual do the right thing and say let's do it properly, let's do IPv6 native. The time to actually do the right thing was also 10-15 years ago. But native v6, for the most part, is still not here yet. At least the ISPs are saying Real Soon Now, which is something. But who knows what Real Soon means? Until native IPv6 is actually here, where here means everywhere, there is still a need to do tunneling of v6 over v4. ...and stop discussing yesterdays technology. We're always discussing yesterday's technology. IPv6 was approved in 1995, if I recall. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Arguably, transitions technologies like 6to4 and Teredo have already achieved their purpose. My goal at the time, more than 10 years ago, was to break the chicken and egg deadlock between application developers and network administrators. That's why I spent such energy on making 6to4 easy to deploy, or defining Teredo. Transitions technologies convinced developers that applications could be developed for IPv6 without waiting for every network to be ready, and applications were indeed developed by Microsoft and others. Network administrators in the meantime started deploying IPv6, and the presence of applications arguably helped somewhat -- although I am sure network administrators add many other motivations. We are now observing a strong pushback, because massive use of tunneling technologies makes networks harder to manage. Wide scale deployment of self-configuring technologies makes levels of services less predictable, and errors are hard to correct. Self-configuring technologies rely largely on the good will of others, which is easier to find during a pioneering phase. Arguably, we are beyond the pioneering phase for IPv6. I understand Keith's point of view, but it is probably time to start progressively rolling back the transition technologies. 6to4 is the weakest of these technologies. It does not traverse NAT, it does not include configuration verification tests, and it uses asymmetric paths. It makes sense to start the rollback with 6to4. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 8:50 AM, Keith Moore wrote: - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness. Informational status was at the behest of the iesg, we have been advised that an informational document may confer historical status on a standards track document. I don't have a problem with the idea that an Informational document can describe the consequences of moving something to Historic. I have a serious problem with the idea that a standards-track document can be moved off of the standards track by less than an IETF Consensus process, or by ignoring the criteria for standards-track actions. I haven't seen any evidence that IESG is trying to do that - they are doing a Last Call after all. But I don't think we want to set a precedent that removing something from the standards track is easier or requires less scrutiny of the technical criteria than putting something on the standards track. The record will show that that the intended status of the document until it reached the iegs was standards track. it has been understood from the outset that advancement of the document was to obsolete 3056 and 3068. revision 4 at the request of the iesg changed th e intented status to informational. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Keith Moore mo...@network-heretics.com Nor do I understand why, in an organization that is supposedly about building consensus, there's such a demand for a divisive ... action. Hey, that's been the IPv6 world since day 1. How many leading technical voices in the community objected vociferoursly to the choice of IPv6 back in the day, only to be blown off? (The large number of unhappy people have been, I reckon, a factor in the slow progress of IPv6 since 1995 - although not the larges, IMO.) The more things change... Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 6:48 PM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC KMI've been using 6to4 on a regular, often daily, basis since the late 1990s. 6to4 has allowed me to develop IPv6 applications and test them on real networks, and deploy them in limited circumstances. 6to4 has also allowed me to remotely access computers on my SOHO networks, using any application protocol that I chose to do so, with out-of-the-box hardware and software, without any application-specific proxies, and generally without any application-specific configuration. None of these scenarios required a relay router. All of them were, and continue to be, useful. KM Yes, I've experienced on many occasions that using 6to4 to access dual-stack web servers doesn't always work so well. Sometimes it picks a suboptimal path because the relay router isn't convenient. Sometimes the v6 path doesn't work at all and the application has to time out and retry using v4. But this never really bothered me much, because my purpose in using 6to4 wasn't to try to access services that I could get to via IPv4 anyway. And neither, I suggest, is that a reasonable metric for evaluating 6to4 or any other IPv6 transition mechanism. The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that are IPv6 only. WEG Again, are you or are you not using a relay router? You keep going back and forth. Bluntly, this isn't about whether you, or anyone else at IETF use 6to4. We are the longest of the long tail; the smallest percentage, the exception to the rule, not the exception that proves the rule. We're network geeks; we're willing to deal with dodgy connectivity or otherwise fiddly methods of doing things to test them and to prove a point. This discussion cannot be about whether the protocol should be preserved because some marginal percentage of folks in IETF use 6to4 successfully. I am not disagreeing that for some value of work 6to4 works to reach IPv6-only things. What I am saying is that the very things you illustrate here make it only acceptable for testing, and not for any sort of real substitute for IPv6 connectivity. What user is going to accept +100ms in latency due to suboptimal relay choice, or waiting multiple seconds for IPv6 to time out because 6to4 didn't work in that particular network setup? I think that the evidence says that 6to4 is actually *ineffective* by the evaluation you suggest - a good portion of the time it either utterly fails or provides such degraded service that it may as well not work. KM - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. WEG So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployment of IPv6, not in spite of it. KM What you're saying is that applications developers shouldn't bother with actually trying to use IPv6 until the ISPs get their act together and deploy it. Well guess what? The ISPs have let us down. We've been waiting for 15 years for the ISPs to roll out IPv6, and for most of those 15 years they were all telling us that there were no applications for it. Now the ISPs are scrambling to get IPv6 into their networks, and they want to sabotage the IPv6 mechanisms that we have in place even before they are actually offering product. WEG Yes, yes, shame on the big, bad ISPs and their lack of deployment. Trust me, I'm as annoyed with the ISPs I've worked for and been a customer of that it is taking so long to get IPv6 out there too. But...6to4 sabotaged itself. This draft is acknowledging reality that it really didn't work the way we'd hoped. There is no active malevolence here on the part of the ISPs. In fact many of them (us?) have deployed or will be deploying 6to4 relays to improve the customer experience until native service is available, and are supporting the recommendations to make 6to4 suck less in draft-carpenter. KMWidespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
I don't intend to re-spin the discussion that took place in the WG, but I'd like to say I do agree with the concerns raised in the LC threads by Keith and others. If there are 6to4 connectivity issues for some 6to4 clients, in my opinion, those issues would be sufficiently mitigated by RFC 3484/bis. Specifically, by changing priority of 6to4-to-6to4 below IPv4 (the 6to4-native IPv6 is already placed below IPv4 by most or all existing implementations of 3484). Once priority is changed, 6to4 basically would only be used when it is the only channel that could work to reach a particular destination. Which means that it could provide connectivity, when there would be no connectivity if 6to4 were removed. When native IPv6 is made widely available to users, they just would stop using 6to4. So, I don't understand concerns regarding evolutionary future of 6to4. And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working or why there is a need to take any action beyond the recommendations along the lines of RFC 3484/bis. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Wed, Jun 08, 2011 at 04:20:44PM -0700, james woodyatt wrote: Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. Well said. +1 Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
Its 'rough' consensus... I don't wanna rat-hole here, but imho send the draft onwards for publication asap please. G/ -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: 09 June 2011 16:38 To: james woodyatt Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC On Jun 8, 2011, at 7:20 PM, james woodyatt wrote: On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... Let's be very clear. This proposed RFC would not take away the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. I have also seen those claims in v6ops email (haven't caught up with all of it, but have seen a few messages). I don't buy the argument. Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations. You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it. (That would be a bit like declaring IPv4 Historic and discouraging new implementations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it. Legacy hardware and software that's still in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are clearly people using 6to4 in the Real World, it strikes me as disingenuous for its proponents to claim that the document will do no harm. Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. The authors are already free to abandon the effort and pursue more useful ends. Not only would publishing this do harm to 6to4 and its users, it would set a bad precedent. We're supposed to be working toward consensus, not trying to cause harm to things that people use. Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
Hi, On Thu, Jun 09, 2011 at 11:05:29AM -0400, Keith Moore wrote: The best way to not rat-hole is just to drop the proposed action. One voice doesn't make it consensus to drop. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote: I have also seen those claims in v6ops email (haven't caught up with all of it , but have seen a few messages). I don't buy the argument. Clearly the inten t of this draft and protocol action are to discourage use of 6to4, particularl y in new implementations. You can't discourage use of 6to4 in new implementat ions without harming people who are already using it and depending on it. (That would be a bit like declaring IPv4 Historic and discouraging new impleme ntations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it. Legacy hardware and software that's still in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are clearly p eople using 6to4 in the Real World, it strikes me as disingenuous for its prop onents to claim that the document will do no harm. I think this is likely to happen anyway. In all discussions it has been come clear that 6to4 has nothing to offer for ordinary users, and that the situation is going to get worse over time (more NAT, more broken 6to4 installation). So for any CPE manufacturer is makes perfect sense to start planning on dropping support for 6to4 in future CPEs, or not add it at all, if they have yet to release firmware with IPv6 support. This is independent of whether the protocol is declared historic. On the other hand, there is no reason why open source distribution would have to drop 6to4 support. As long as there are people to maintain it, it can stay. Also on other operation systems, as long as there is some sort of tunnel interface, you can implement 6to4. It is just a few lines of code, everybody can do it. So I don't see the big fuzz. If you want to use it, just create a web page that lists software implementation of 6to4 for every possible platform. And let the authors of the software know have much their software is appreciated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Philip, On 2011-06-10 03:18, Philip Homburg wrote: ... I think this is likely to happen anyway. In all discussions it has been come clear that 6to4 has nothing to offer for ordinary users, In all fairness, that depends on your definition of ordinary. Where I differ from Keith is that I don't think we harm the current ordinary (or extraordinary) 6to4 users by relabelling the RFCs. As long as all operators do what draft-ietf-v6ops-6to4-advisory suggests, of course. I wouldn't support the -historic draft if the -advisory draft wasn't coming along too. and that the situation is going to get worse over time (more NAT, more broken 6to4 installation). More NAT44, yes. But *less* broken 6to4 if operators implement -advisory. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Hi - From: Rémi Després remi.desp...@free.fr To: Randy Presuhn randy_pres...@mindspring.com Cc: ietf@ietf.org Sent: Thursday, June 09, 2011 1:11 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt ... I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. RFC 1227 specified an experimental protocol. The 6to4 specification is standard track. Declaring historic a standard track specification although it still serves legitimate needs would, AFAIK, be a precedent, a regrettable one IMHO. Consider, then, RFC 1157. It was, quite rightly, declared historic years ago, even though it was a full standard and in rather widespread use at the time. Despite that declaration, it remains in use. This despite all the good reasons that its replacement should be used instead. The point is that the historic declaration can be a statement about how the IETF wants things to be, rather than how they are. If one happens to be a user or vendor of a historic technology, the declaration might sting a little, but it's really not a big deal, IMO. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 12:17 PM, Joel Jaeggli wrote: I don't have a problem with the idea that an Informational document can describe the consequences of moving something to Historic. I have a serious problem with the idea that a standards-track document can be moved off of the standards track by less than an IETF Consensus process, or by ignoring the criteria for standards-track actions. I haven't seen any evidence that IESG is trying to do that - they are doing a Last Call after all. But I don't think we want to set a precedent that removing something from the standards track is easier or requires less scrutiny of the technical criteria than putting something on the standards track. The record will show that that the intended status of the document until it reached the iegs was standards track. it has been understood from the outset that advancement of the document was to obsolete 3056 and 3068. revision 4 at the request of the iesg changed th e intented status to informational. And Informational status *for the document*, if published, is entirely appropriate. But the *protocol action* is a standards-track protocol action. It used to not be considered necessary to publish an RFC every time the IESG approved a protocol action. Somewhere along the way, having a companion document started to be commonplace. I'm not sure why that got to be conventional - maybe it was because of increased use of tracking tools that were written with document processing in mind. And at least sometimes it's beneficial to the community to publish an RFC that explains why a particular document's status has changed, and how to interpret that change in document status. But RFC 2026 didn't anticipate the need for every protocol action to have an associated document, and sometimes - as in this case - it causes confusion when they are associated. Process-wise, I think that the protocol action and the document action should be separate items. Though of course it makes no sense for IESG to approve the document if it doesn't approve the protocol action. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Thu, Jun 9, 2011 at 13:30, Randy Presuhn randy_pres...@mindspring.comwrote: Hi - From: Rémi Després remi.desp...@free.fr To: Randy Presuhn randy_pres...@mindspring.com Cc: ietf@ietf.org Sent: Thursday, June 09, 2011 1:11 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt ... I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. RFC 1227 specified an experimental protocol. The 6to4 specification is standard track. Declaring historic a standard track specification although it still serves legitimate needs would, AFAIK, be a precedent, a regrettable one IMHO. Consider, then, RFC 1157. It was, quite rightly, declared historic years ago, even though it was a full standard and in rather widespread use at the time. Despite that declaration, it remains in use. This despite all the good reasons that its replacement should be used instead. The point is that the historic declaration can be a statement about how the IETF wants things to be, rather than how they are. If one happens to be a user or vendor of a historic technology, the declaration might sting a little, but it's really not a big deal, IMO. Although I have already stated my position in this issue (against, for now), I have a problem with the above logic. You are effectively arguing that this move won't really impact anything ... in which case I would ask, why are we doing it? I suspect that 6to4 is a fairly unique case in that it, as pointed out earlier, relies on the good nature of others to operate relays for the public good. Marking it as historic would, I imagine, demotivate ISPs to operate those relays and thus render the connectivity even worse than we are fearing. Please don't confuse my position - I wholeheartedly believe the right answer is, and am very vocal in promoting, native IPv6 (dual stack) everywhere, for everyone. But we aren't there yet. Even though my home ISP has done more IPv6 than many|most, they aren't ready to do native here, yet. I often rely on 6to4 is _many) scenarios and simply want something that exists to keep working until the alternatives are more available. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 12:01 PM, Christian Huitema wrote: Arguably, transitions technologies like 6to4 and Teredo have already achieved their purpose. My goal at the time, more than 10 years ago, was to break the chicken and egg deadlock between application developers and network administrators. That's why I spent such energy on making 6to4 easy to deploy, or defining Teredo. Transitions technologies convinced developers that applications could be developed for IPv6 without waiting for every network to be ready, and applications were indeed developed by Microsoft and others. Network administrators in the meantime started deploying IPv6, and the presence of applications arguably helped somewhat -- although I am sure network administrators add many other motivations. We are now observing a strong pushback, because massive use of tunneling technologies makes networks harder to manage. Wide scale deployment of self-configuring technologies makes levels of services less predictable, and errors are hard to correct. Self-configuring technologies rely largely on the good will of others, which is easier to find during a pioneering phase. Arguably, we are beyond the pioneering phase for IPv6. It's hard to argue that we're beyond the pioneering phase of IPv6 when native IPv6 is still not widely available. The pushback was predictable, for the very reasons you cite. But it's premature and counterproductive to cave in to it. If pain associated with 6to4 provides an additional incentive for ISPs to deploy native v6, and for users to use native v6 when it becomes available, that's a Good Thing. (Not that I want to cause them pain, but neither do I want the Internet to be stuck with 6to4 and Teredo forever.) I understand Keith's point of view, but it is probably time to start progressively rolling back the transition technologies. 6to4 is the weakest of these technologies. It does not traverse NAT, it does not include configuration verification tests, and it uses asymmetric paths. It makes sense to start the rollback with 6to4. The time to start rolling back the transition technologies is when v6 support is available off the shelf. Because there is some pain associated with them, there's a built in incentive to do so. And I disagree that 6to4 is the weakest of the technologies. They all have strengths and weaknesses. 6to4 is very widely implemented, is automatically configurable, needs no central server, and routing is near-optimal for 6to4-to-6to4 traffic. But there's a community learning curve associated with using anycast addresses for relay routers. Configured tunnels take a latency hit on every packet, no matter where it's going. Teredo works through NATs (good), but also requires routing packets through third party servers, with the corresponding implications for latency, privacy, etc. And in practice, it's pretty much a Microsoft-only solution - it doesn't ship with either Mac or Linux. (If we could have developed a universal best-of-breed transition technology, I think we would have done so. But the solution space really didn't permit that, so we ended up with a hodgepodge of different tools that are applicable in different situations.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Hi - From: TJ trej...@gmail.com To: Randy Presuhn randy_pres...@mindspring.com Cc: ietf@ietf.org Sent: Thursday, June 09, 2011 10:36 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt ... The point is that the historic declaration can be a statement about how the IETF wants things to be, rather than how they are. If one happens to be a user or vendor of a historic technology, the declaration might sting a little, but it's really not a big deal, IMO. Although I have already stated my position in this issue (against, for now), I have a problem with the above logic. You are effectively arguing that this move won't really impact anything ... in which case I would ask, why are we doing it? No, what I'm saying is that declaring a technology historic does not make it go away. If accompanied by strong advice and good alternatives, it might contribute to a reduced likelihood that one will encounter the offensive technology, but things rarely disappear completely, nor as quickly as one might like. Speaking in horribly general terms, rather than the specifics of 6to4: The folks who believe they have a legitimate need for a technology will continue to use it as long as they are able to. The folks who don't find it causing problems for them will tend to leave things alone - there's always the fear that turning something off, even if it appears to be little-used, might break some critical but low-frequency application somewhere in the enterprise. The folks for whom the historic technology has been causing a problem will rejoice and turn it off or remove it from their products, but will still need to defend against it, because you never know what's going to come in from the big bad internet. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 1:42 PM, Lorenzo Colitti wrote: On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore mo...@network-heretics.com wrote: 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. No, it does not - in fact, it is the opposite. Geoff has presented data that shows that anycasted 6to4 as a connectivity mechanism has a failure rate of the order of 20-30%. I don't dispute that data. I just disagree with the notion of discouraging 6to4 in its entirety because of the current problems with advertising 6to4 relay routers using anycast addresses. I suspect that the anycast issues will largely be sorted out before this document can have much of an effect. But nevertheless, I don't have a problem with discouraging this use of anycast. I think it was a noble experiment, and we learned something valuable: Don't use anycast to advertise a service that is provided by a wide range of players, at least not without having some fairly clear guidelines about how to monitor them and weed out the broken ones. We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. Search the list archives for details. Again, I have no problem with implementations disabling 6to4 by default. Especially given the looming threat of LSN, I became convinced that it was the right thing to do. So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. non sequitur. Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually configured tunnels in the aggregate? I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained. It's been awhile since I used manually configured tunnels (from a well-known tunnel broker). But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 7:37 AM, Keith Moore wrote: Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations. You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it. After it became clear to me that IETF will not be issuing a phase-out plan for 6to4, I recommended to all the relevant product managers at Apple that we should continue supporting 6to4 in new implementations for the foreseeable future (despite the non-RFC2119 'not recommended' line in section 1). I don't see why this draft should discourage anyone from continuing to support 6to4, which as you point out is a *uniquely* useful protocol that people depend on and find *irreplaceable*. Reclassifying it as Historic simply allows IETF working groups to operate on the fiction that 6to4 will eventually disappear someday in the indefinite and vaguely hopeful future. While I don't think that self-delusion will be a good thing for IETF in the long run, I have a hard time getting too bummed out about it. Pragmatism will find its way into deliberations. Yes, I think this draft is a pointless waste of time. The reason I support publishing it, however, is that I disagree with your assessment of the harm it could do. Also, it enjoys widespread support in the V6OPS working group and the opposition, while vocal, seems quite small. That looks like rough consensus to me, and if I can help get it off our agenda sooner by supporting it rather than opposing it, then I say let's print it. I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry. We're smart enough to recognize that we're not the target audience for the RFC. The draft that matters is the companion advisory draft. It would be nice if the 6to4-to-historic draft could be spiked so as not to distract from its companion, but I don't see that as a likely outcome. Alas and alack. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 2:20 PM, Lorenzo Colitti wrote: On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore mo...@network-heretics.com wrote: So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. non sequitur. Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses. No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail. I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then. Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of don't solve the problem, but rather, stamp out the solution. (And of course if the ISPs block protocol 41, that will also kill configured tunnels that happen to transit their networks. The overall failure rate will be the same, but the granularity of failure will be higher for the configured tunnels.) Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually configured tunnels in the aggregate? In a similar way as Geoff measured 6to4 - looking at SYNs. From where? Again, the tunnels aren't taking the variety of paths that 6to4 connections are. It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole. I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained. It's been awhile since I used manually configured tunnels (from a well-known tunnel broker). But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate. Please try again. You will be pleasantly surprised. A few months ago I was trying to set one up, but I ran out of time. I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote: On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore mo...@network-heretics.com wrote: I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then. Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of don't solve the problem, but rather, stamp out the solution. Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6. Well if an enterprise network wants to firewall certain kinds of traffic, that's its own business. The fact that some enterprises firewall ip-over-ip tunnels is not a justification for IETF trashing one particular kind of ip tunnel. In a similar way as Geoff measured 6to4 - looking at SYNs. From where? Again, the tunnels aren't taking the variety of paths that 6to4 connections are. It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole. From the same place that he ran the 6to4 measurements from? See above. It's not a valid measurement. Or the measurement is fine, but comparisons between configured tunnels and 6to4 on the basis of such measurements are not valid. A few months ago I was trying to set one up, but I ran out of time. I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4. Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-) That's who I was using before. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi Lorenzo, On 2011-06-10 06:20, Lorenzo Colitti wrote: On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore mo...@network-heretics.comwrote: So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. non sequitur. Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses. No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail. To be clear, that statistic applies to clients whose SYN packet reaches the server, but who never respond to SYN/ACK. It's a presumption that the problem is Protocol 41 filtering - probably correct, but there are other possible causes. Also, we have no possible way of knowing how many clients send SYN packets towards a 6to4 anycast relay, but those packets are blackholed and never reach the intended server. From the client's viewpoint, this also looks like a missing SYN/ACK, leading to retries and eventual fallback to IPv4. In other words, the real failure rate may be much worse than Geoff reports, but we have no way of measuring it. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually configured tunnels in the aggregate? In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. Er, I'm currently on 2001:388:f000:: Do you have an algorithm that will tell you whether that is native or a configured tunnel? Brian I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained. It's been awhile since I used manually configured tunnels (from a well-known tunnel broker). But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate. Please try again. You will be pleasantly surprised. ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
I agree the draft should be progressed, so add another +1 to the 'just ship it' people. On 9 Jun 2011, at 18:39, Keith Moore wrote: If pain associated with 6to4 provides an additional incentive for ISPs to deploy native v6, and for users to use native v6 when it becomes available, that's a Good Thing. The pain though is felt by the content providers, who still see too much brokenness. On 9 Jun 2011, at 19:01, james woodyatt wrote: I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry. We're smart enough to recognize that we're not the target audience for the RFC. The draft that matters is the companion advisory draft. It would be nice if the 6to4-to-historic draft could be spiked so as not to distract from its companion, but I don't see that as a likely outcome. Alas and alack. Well, the most important point in this is that 6to4 is disabled by default in every device. Apple did that already, which is good. What is unclear to me though is whether deprecating 2002::/16 means that prefix would no longer be routed, as per 3ffe::/16, or just 'reserved' so it's not reallocated later. On 9 Jun 2011, at 19:53, Keith Moore wrote: On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote: Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-) That's who I was using before. Our staff and students find the HE broker easy to use, though I believe some also use other brokers. One student did a final year project this year developing a Linux home router which included HE broker support. It was simple to use/integrate. On 9 Jun 2011, at 19:56, james woodyatt wrote: I need *native* IPv6 into my home in San Francisco for my day job Have you considered deploying/adding IPv6 VPN support at your day job? So your VPN from home to work gives you IPv4 and IPv6? This is quite a nice model, and is starting to appear in UK universities, and I use it myself for IPv6 training. At least one big vendor offers this today. Users are familiar with VPN use, so adding IPv6 with that comes naturally, and $dayjob provides the support, so you're in control. Meanwhile, 6to4 works fine on their network so long as remote IPv6 destinations have a working return path route to 2002::/16, i.e. they are complying with I-D.ietf-v6ops-6to4-advisory now. That 'so long as' is the crux though. Tim___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 9, 2011, at 1:30 PM, Randy Presuhn wrote: I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. RFC 1227 specified an experimental protocol. The 6to4 specification is standard track. Declaring historic a standard track specification although it still serves legitimate needs would, AFAIK, be a precedent, a regrettable one IMHO. Consider, then, RFC 1157. It was, quite rightly, declared historic years ago, even though it was a full standard and in rather widespread use at the time. Was there a replacement for RFC 1157 (presumably, a new version of SNMP) generally available at the time that document was moved to Historic? I mean, it would make perfect sense to want to declare 1157 historic if there were a new version available that clearly worked better. Right now, there's not a readily available replacement for 6to4 that is clearly better. So I think the comparison is not valid. SNMP (of whatever version) is a protocol that you can use on your own network if you want to, and that's where most of its utility is. You don't have to get your ISP to support it before it's significantly useful to you. By contrast, the very purpose of 6to4 is to communicate with peers over someone else's network(s). If you want to run IPv6 over your own IPv4 network, 6rd or maybe 6over4 are better suited to that. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Hi - From: Keith Moore mo...@network-heretics.com To: Randy Presuhn randy_pres...@mindspring.com Cc: ietf@ietf.org Sent: Thursday, June 09, 2011 5:49 PM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt ... Consider, then, RFC 1157. It was, quite rightly, declared historic years ago, even though it was a full standard and in rather widespread use at the time. Was there a replacement for RFC 1157 (presumably, a new version of SNMP) generally available at the time that document was moved to Historic? Yes, with some arguments about generally. I mean, it would make perfect sense to want to declare 1157 historic if there were a new version available that clearly worked better. Right now, there's not a readily available replacement for 6to4 that is clearly better. So I think the comparison is not valid. SNMP (of whatever version) is a protocol that you can use on your own network if you want to, and that's where most of its utility is. You don't have to get your ISP to support it before it's significantly useful to you. By contrast, the very purpose of 6to4 is to communicate with peers over someone else's network(s). If you want to run IPv6 over your own IPv4 network, 6rd or maybe 6over4 are better suited to that. There appears to be some dispute about whether the functionality of 6to4 is really needed. I take no sides in that part of the debate. My comment was in response to the claim (which you have not made, AFAIK) that it was inappropriate to declare a standards-track protocol historic while still in widespread use, for reasonable interpretations of widespread. I was making no claims about 6to4's (de)merits. Your argument seems to be that the peculiar operational characteristics of 6to4 should give it additional immunity to being declared historic. I don't find that argument persuasive. The history of multiple protocols that have been declared historic shows that vendors seem to care about that designation only when it is convenient for them to do so. Installed base, customer demand, operational considerations and so on all trump whatever the IETF might say about a historic protocol. This works both ways: folks might decide to kill something before it becomes historic, or support it long after. We can't compel people to continue supporting it any more than we can make them stop. At most, we can give them (hopefully convincing) reasons to change. If the SNMP experience shows anything, it shows that even that isn't enough. For that reason, I find it amusing when others write of killing 6to4. We don't have that kind of power. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
In message 000901cc270d$430ec000$6801a8c0@oemcomputer, Randy Presuhn writes : We can't compel people to continue supporting it any more than we can make them stop. At most, we can give them (hopefully convincing) reasons to change. If the SNMP experience shows anything, it shows that even that isn't enough. For that reason, I find it amusing when others write of killing 6to4. We don't have that kind of power. But you can give them a big excuse not to support it. Customer: Where did the 6to4 support go? Vendor: The IETF declared it historic so we removed it. Customer: I was using it, can you put it back? Vendor: I repeat the IETF declared it historic. 6to4 on by default is wrong. However if a user/site turns 6to4 on they do that with the full knowledge that it will add delays and it does use third party relays. As to those that say users won't accept 100ms delays many actually will accept the delay and it does not impact on what they do. The tunnel I use adds +300ms to some IPv6 sites compared to IPv4 but unless I explicitly measure it I don't notice it. Making 6to4 historic is a knee jerk reaction to a bad default setting. Fix the default. Don't make 6to4 historic. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Mark Andrews wrote: In message Randy Presuhn writes: We can't compel people to continue supporting it any more than we can make them stop. At most, we can give them (hopefully convincing) reasons to change. If the SNMP experience shows anything, it shows that even that isn't enough. For that reason, I find it amusing when others write of killing 6to4. We don't have that kind of power. But you can give them a big excuse not to support it. Customer: Where did the 6to4 support go? Vendor: The IETF declared it historic so we removed it. Vendor: I repeat the IETF declared it historic. 6to4 on by default is wrong. Making 6to4 historic is a knee jerk reaction to a bad default setting. Fix the default. Don't make 6to4 historic. I fully agree about your description of the purpose of historic for vendor and its usage by vendors. The only sensible use of historic is to promote active de-support on the part of vendors -- literally for ripping things out. I just did that myself 4 weeks ago, justifying the complete removal of support for MD2-based digital signatures from our PKI software with a pointer to http://tools.ietf.org/html/rfc6149 MD2 to Historic Status Moving 6to4 seems premature by several years. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
I'm sorry, I seem to have goofed up during mail editing... I meant to write that cassifying 6to4 as historic is INappropriate use of the IETF process in the last sentence. -Martin Martin Rex wrote: George, Wesley wrote: It's time to remove the stabilisers on the IPv6 bicycle. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. In my personal perception, the historic status used to be a technical characterization to indicate that (1) a protocol or technology has been fully replaced by some newer protocol and there is no reason to continue using the original technology anymore because the successor can be used in each of the original usage scenarios today (2) the protocol/technology has been largely put out of use, and its active use has dropped to marginal levels (like less than 1% of the original active use) Personally, I have never conciously used anything related to IPv6 so far, so for me it is difficult to comment, but what has been said looks to me that neither (1) nor (2) apply to 6to4. The user base seems to have always been small, and most of the users of 6to4 simply did _not_ have an alternative -- and its current users still do _not_ have an alternative today. Classification of 6to4 as historic is appropriate use of the IETF process, because it would be a political, but not an accurate technical statement. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? KMThe best current use cases for 6to4 that I'm aware of are: KM- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. WEG Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against. That doesn't require IPv6 connectivity to the outside world. If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that works and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution. Further, I don't buy the separate tunnel to every host... thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice of tunnel broker, and through the magic of the internet, they're all connected to one another. KM - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. WEG So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployment of IPv6, not in spite of it. KM - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks. This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT. WEG Until CGN becomes common, in which case 6to4 doesn't work again. Also, that same NAT + v6 router combination could just as easily manage a static tunnel. KMWidespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it. WEG So Widespread IPv6 has to have reliability and support equivalent to IPv4, yet you're saying that you can expect applications to rely on 6to4 in the meantime despite evidence that it's unreliable, and the virtual guarantee that it won't be supported by the upstream ISP? And you and I disagree about the definition of widespread. I do not think that widespread means every small ISP in every corner of the world supports it ubiquitously and at every price point. I think it means it's available for a majority (50%) of Internet service customers. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. KM With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4. Operators rarely have a good
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On 2011-06-09 04:17, james woodyatt wrote: On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. In any case, I don't see the politics, unless (for example) declaring RFC 1267 Historic was politics too. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Hi - From: james woodyatt j...@apple.com To: ietf@ietf.org Cc: v6...@ietf.org Sent: Wednesday, June 08, 2011 9:17 AM Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. On the other side of the argument, declaring RFC 1227 historic had little (I'm being generous) impact on its continued use. The folks that needed it kept using it, in some cases long after the IETF's replacement for it became widely available. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I'm much more worried about the important part that you didn't quote, that moving 6to4 to historic is a technically inaccurate statement. How about downgrading it (rfc3056+rfc3068, I assume) from Proposed to Experimental, acknowledging the fact that consumers will likely have to set it up themselves, it is rarely going to work out of the box and might not be available in all implementations. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 4:33 AM, TJ wrote: Less than 1% of the IPv6 traffic reaching us is 6to4. Unless you provide IPv6 only sites, you should see very little ... that is part of the point :). snip It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. That fails, 20% of time. Seems unlikely that it's going to go away anytime soon, draft or no, that said it seems unwise to keep telling the users and implementors to use it. by default. Just my $.02, /TJ ... ready for world IPv6 Day? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 8 Jun 2011, at 21:19, Keith Moore wrote: Nor, bluntly, is it about a few big content providers or whomever else you want to label as important. The internet is a hugely diverse place, and you don't get to dismiss the concerns of people whom you want to label as red herrings. Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. That's about as much as Teredo, it's a hell of a lot more than native v6. As long as 6to4 is one of the major ways that people get IPv6 connectivity (and it clearly is), it's premature to declare 6to4 historic. You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. Our observation point is as a university on an academic/research network that is native dual-stack. We probably have most of our IPv6 traffic come from other universities around the world, who are also most likely natively connected. Hence little if any need for transition methods. This may be different to your scenario, of course, but it is hopefully a future that will be more widespread in time. We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since. Perhaps it would be useful to see your use cases more clearly documented with examples. Almost all usage of IPv6 today is in spite of ISPs. For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 be deprecated. We see even less Teredo, i.e. the sum of the 6to4 and Teredo we see is under 1% of our total IPv6 traffic. I don't know where you see 90%; I assume it's an environment with home-to-home networks, with no broker or IPv6 VPN use? That's excellent news. But the current proposal on the table to deprecate 6to4 is premature, confusing, and harmful to real users. The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6to4 on by default, won't it? The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from product? It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... Let's be very clear. This proposed RFC would not take away the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. This draft does redundantly make some recommendations that are also made in I-D.ietf-v6ops-6to4-advisory, which is the companion document with technical content intended for audiences other than the IETF itself. These recommendations mainly say that 6to4 SHOULD NOT be enabled by DEFAULT. Beyond that, the principle point of this draft is to flip a categorization flag that nobody outside IETF cares about. The practical effect of that will be to free the authors of future working group drafts from a procedural requirement to consider whether 6to4 poses any special problems for the subjects of future standards efforts. I'm okay with that, actually, but I have a hard time imagining how it helps them avoid being pragmatic about what's actually deployed in the real world. Reality must take precedence over public relations, as Professor Feynman said. After much consideration on this draft, I have concluded that every moment IETF spends arguing over it is one that would be put to better use discussing almost anything else... even which cute word we should use for the colon-separated fields in the IPv6 address presentation format. Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 8, 2011, at 7:05 PM, Tim Chown wrote: On 8 Jun 2011, at 21:19, Keith Moore wrote: Nor, bluntly, is it about a few big content providers or whomever else you want to label as important. The internet is a hugely diverse place, and you don't get to dismiss the concerns of people whom you want to label as red herrings. Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. That's about as much as Teredo, it's a hell of a lot more than native v6. As long as 6to4 is one of the major ways that people get IPv6 connectivity (and it clearly is), it's premature to declare 6to4 historic. You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%. Our observation point is as a university on an academic/research network that is native dual-stack. We probably have most of our IPv6 traffic come from other universities around the world, who are also most likely natively connected. Hence little if any need for transition methods. This may be different to your scenario, of course, but it is hopefully a future that will be more widespread in time. I'd love it if we all saw a lot more native IPv6 traffic soon. Just to clarify, the 40% is not from my measurement. It's an approximation to figures I've seen quoted elsewhere. Like you, I'm sure this figure will vary from place to place. I haven't tried to do any measurement myself, because the amount of traffic is not a good indicator of overall usefulness. On the other hand, if any transit provider anywhere in the world is seeing 40% of v6 traffic as 6to4, that is a pretty good indication that somebody (besides myself) is using it. For that matter, the very fact that operators are observing problems with relay routers is another indication that people are using 6to4. Why would they be using it if they didn't want to? I realize that some platforms enable 6to4 by default, but not all of them do. And I've already said I support having hosts and routers ship with 6to4 disabled by default. We did use 6to4 in its router-to-router, site-to-site flavour many years ago while a project called 6NET ran, but have had no use case for it since. Perhaps it would be useful to see your use cases more clearly documented with examples. I've already given examples. People keep looking for more specific examples in an argument where any specific example can be dismissed as irrelevant. It's not any one specific example that matters, it's the fact that people are using 6to4 and there's not an obviously better replacement that's available to them. The problem is that 6to4 is unfortunately also harmful to real users, at least the ones that don't want to know about IPv6. It will continue to be until we can be confident no vendor anywhere has 6to4 on by default, won't it? NATs are harmful to real users too, and they do a lot more harm than 6to4 does. When will we deprecate them? When will we declare them Historic? It's misleading to talk about only the harm being done by 6to4 without acknowledging the benefits of 6to4 or the lack of a suitable alternative. And to say that 6to4 does harm is misleading. Is it 6to4 that's doing the harm, or people who advertise routes to relay routers that don't function properly? Why are people blaming the 6to4 protocol for configuration errors made by network operators? The question is whether Historic stops knowledgeable people like you using 6to4 safely in your own context/community, without affecting 'normal' users. Does it mean 6to4 off be default, or 6to4 removed from product? Historic doesn't stop someone who can write his own code. But if it results in implementations removing support for 6to4, declaring 6to4 as Historic will stop people who use those implementations. It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding brokenness. Geoff's stats illustrate that very well, though those are not based on vanilla 6to4. I disagree with that assessment, because it's only considering the case of using 6to4 when IPv4 would work just fine. That's not an appropriate metric. Nobody who has native IPv6 connectivity needs to use 6to4 to reach native IPv6 destination addresses. But a deeper problem is the notion that a single set of address selection rules will work well for all, or even most, applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 7 Jun 2011, at 07:33, Gert Doering wrote: Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Less than 1% of the IPv6 traffic reaching us is 6to4. Unless you provide IPv6 only sites, you should see very little ... that is part of the point :). snip It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. Just my $.02, /TJ ... ready for world IPv6 Day? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 7, 2011 at 08:56, George, Wesley wesley.geo...@twcable.comwrote: From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of TJ Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Wes George I agree with the end goal here, but for a mechanism that relies on the good will of others (relays) changing it to historic could have a more-abrupt impact on those who use the mechanism than in other cases of similar demotions. That is my concern. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 10:39 AM, George, Wesley wrote: At the risk of rehashing discussion from WGLC... Ole has addressed some of your points, I'll address a few others below inline. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, June 06, 2011 1:22 PM To: ietf@ietf.org Cc: v6...@ietf.org; IETF-Announce Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? The best current use cases for 6to4 that I'm aware of are: - Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks. This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT. Widespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it. 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. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4. Operators rarely have a good understanding of what individual application users or developers need. They tend to focus mostly on the applications that generate the most traffic, or cause them particular amounts of trouble, or the ones that their biggest customers need. Problem is, those aren't the only applications that are important. Every application is important to its users, no matter how much or little traffic (or revenue) it generates. 6to4 is as reliable as IPv4 is, if it isn't asked to cross a relay router. And there are valid reasons to use 6to4 even where IPv4 connectivity already exists. Even in cases where 6to4 traffic must cross a relay router, sometimes it's the best solution available. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Mon, Jun 06, 2011 at 07:41:49PM -0400, TJ wrote: On Mon, Jun 6, 2011 at 13:22, Keith Moore mo...@network-heretics.comwrote: I strongly object to the proposed reclassification of these documents as Historic. *snipped lots of great thoughts/comments, solely for brevity* Agreed that this is too harsh, too soon. Fixing the broken implementations is a better idea than trying to break the working ones. And I am not just saying this because I successfully use 6to4 on a fairly common basis ... Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of TJ Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011 12:16 AM, Tim Chown t...@ecs.soton.ac.uk wrote: On 7 Jun 2011, at 07:33, Gert Doering wrote: Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster Exactly. Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 6to4-to-native mode is proven to be highly unreliable. It seems highly preferable to have that 1% wait for native IPv6 to be available to them, rather than being used as a reason by the bigger content providers for holding back production deployment, which is what we all want to see. It's time to remove the stabilisers on the IPv6 bicycle. +1. Let's move on and not repeat this tired discussion. Cb Tim ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
At the risk of rehashing discussion from WGLC... Ole has addressed some of your points, I'll address a few others below inline. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, June 06, 2011 1:22 PM To: ietf@ietf.org Cc: v6...@ietf.org; IETF-Announce Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? 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. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. 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. WEG Again, please substantiate this with examples of implementations that are actively using non-relay 6to4. Also, the number of applications of 6to4 that can be guaranteed to avoid any unknown 3rd party relays is extremely limited due to the nature of anycast and 6to4's asymmetric routing. The protocol action requested in this draft in no way prevents one or more consenting networks from using 6to4 and continuing to run relays for their local traffic indefinitely - in fact, it even provides a reference to a document to show them how to make it work as well as possible. It is simply saying that it's not a good idea. 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. WEG this seems to be to be splitting hairs. Please explain the distinction you're making here. Disable by default means never use. Use as last resort means use when no better IP connectivity is available. I would think if you insist that 6to4 must stick around you'd prefer it to be enabled. I understand that there are different values of better but if 6to4 works, this means that the host is not behind a NAT, and therefore by most definitions, its IPv4 connectivity would be better than 6to4. If it's behind an IPv4 NAT, and therefore IPv6 connectivity would be better (especially if there are one or more applications that work via IPv6 but not via IPv4 + NAT) then 6to4 won't work in lieu of IPv6 connectivity anyway. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4 to Historic status) to Informational RFC
After a fair amount of thought, I have decided that I support this document without reservation. I support the recommendation that RFC 3056/3068 support should be off by default in CPEs; the reasons for this are clear enough in my companion draft. Specifically, I support the choice of SHOULD NOT enable (rather than MUST NOT) because it leaves open the option for a CPE or host vendor to enable RFC 3056/3068 by default if there is a sound reason to do so for a specific product. I support the recommendation to reclassify RFC 3056 as Historic, because its time is past. The reason for inventing 6to4 in the first place was for the benefit of customers whose ISPs could not deploy IPv6. There is now no reason or excuse for a consumer ISP to fail to deploy IPv6 for customers, so it is entirely reasonable to consider the technique as Historic. This has no impact on current successful use of 6to4 - the recommendation is to retain existing relays until traffic diminishes and to follow appropriate operational recommendations meanwhile. As my companion draft indicates, relays advertising the 2002::/16 prefix are needed as long as there is residual 6to4 traffic in the network. Regards Brian Carpenter (co-author of RFC 3056) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
George, Wesley wrote: It's time to remove the stabilisers on the IPv6 bicycle. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. In my personal perception, the historic status used to be a technical characterization to indicate that (1) a protocol or technology has been fully replaced by some newer protocol and there is no reason to continue using the original technology anymore because the successor can be used in each of the original usage scenarios today (2) the protocol/technology has been largely put out of use, and its active use has dropped to marginal levels (like less than 1% of the original active use) Personally, I have never conciously used anything related to IPv6 so far, so for me it is difficult to comment, but what has been said looks to me that neither (1) nor (2) apply to 6to4. The user base seems to have always been small, and most of the users of 6to4 simply did _not_ have an alternative -- and its current users still do _not_ have an alternative today. Classification of 6to4 as historic is appropriate use of the IETF process, because it would be a political, but not an accurate technical statement. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 7, 2011, at 5:27 PM, George, Wesley wrote: From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? KMThe best current use cases for 6to4 that I'm aware of are: KM- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. WEG Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against. Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. That doesn't require IPv6 connectivity to the outside world. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that works and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution. I've been using 6to4 on a regular, often daily, basis since the late 1990s. 6to4 has allowed me to develop IPv6 applications and test them on real networks, and deploy them in limited circumstances. 6to4 has also allowed me to remotely access computers on my SOHO networks, using any application protocol that I chose to do so, with out-of-the-box hardware and software, without any application-specific proxies, and generally without any application-specific configuration. None of these scenarios required a relay router. All of them were, and continue to be, useful. Yes, I've experienced on many occasions that using 6to4 to access dual-stack web servers doesn't always work so well. Sometimes it picks a suboptimal path because the relay router isn't convenient. Sometimes the v6 path doesn't work at all and the application has to time out and retry using v4. But this never really bothered me much, because my purpose in using 6to4 wasn't to try to access services that I could get to via IPv4 anyway. And neither, I suggest, is that a reasonable metric for evaluating 6to4 or any other IPv6 transition mechanism. The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that are IPv6 only. And sure, 6to4 is a sort of last resort for those services, except maybe for the other transition mechanisms that are worse: Teredo is often worse, configured tunnels are often worse, for all of the obvious reasons. If your ISP offers you native IPv6 access you should probably use that instead, even if internally they use 6rd or some other tunneling scheme. There's definitely benefit to having professional management and support (such as it is) for your IPv6 connectivity. Yet, time and time again the argument gets made that 6to4 gets in the way of trying to access such services. 6to4 by itself is not the problem. The problem is address selection rules that favor v6 over v4. If the service is supported under v4, if it works fine through any NATs in the signal path, the application should probably use v4 to talk to that service. And if the service is v6-only, and 6to4 is the best way of getting there that's available, you might as well try to use it. Further, I don't buy the separate tunnel to every host... thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice
