RE: [v6ops] 6to4v2 (as in ripv2)?
Hmmm...it's been well documented that 6to4 causes bad experiences, not decreases the chance of having them. Since much of the IPv6-accssible content is dual-stacked, unless you're using an application that implements HE, the odds are in your favor to use IPv4 rather than IPv4+6to4. Frank -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, July 27, 2011 1:25 PM To: Philip Homburg Cc: IPv6 Operations; Keith Moore; ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: In message 4e2f4491.30...@gmail.com, Brian E Carpenter writes: Of course, if implementors choose to drop the code you might not be able to upgrade software versions - but hopefully by that time you will have native IPv6 service anyway. Which is exactly why HISTORIC is NOT appropriate. With rfc3484-revise and the documented brokenness of 6to4, it doesn't make any sense for implementors to offer 6to4 anyhow. False. It makes even more sense to offer 6to4 because it significantly decreases the chance that it will cause a bad experience for users of services that provide both v4 and v6 addresses, while increasing the chance letting local hosts/users talk to v6-only services/hosts. snip 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] 6to4v2 (as in ripv2)?
To clarify, what I meant here is that with 3484-revise address selection rules in place, 6to4 is an overall benefit. 6to4 provides a means of accessing v6-only hosts and services when no other means is available. And though one might argue that there are too few v6-only hosts and services to matter, that's a temporary situation. Keith On Aug 8, 2011, at 12:22 AM, Frank Bulk wrote: Hmmm...it's been well documented that 6to4 causes bad experiences, not decreases the chance of having them. Since much of the IPv6-accssible content is dual-stacked, unless you're using an application that implements HE, the odds are in your favor to use IPv4 rather than IPv4+6to4. Frank -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, July 27, 2011 1:25 PM To: Philip Homburg Cc: IPv6 Operations; Keith Moore; ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: In message 4e2f4491.30...@gmail.com, Brian E Carpenter writes: Of course, if implementors choose to drop the code you might not be able to upgrade software versions - but hopefully by that time you will have native IPv6 service anyway. Which is exactly why HISTORIC is NOT appropriate. With rfc3484-revise and the documented brokenness of 6to4, it doesn't make any sense for implementors to offer 6to4 anyhow. False. It makes even more sense to offer 6to4 because it significantly decreases the chance that it will cause a bad experience for users of services that provide both v4 and v6 addresses, while increasing the chance letting local hosts/users talk to v6-only services/hosts. snip 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-30 03:06 , Mark Andrews wrote: In message 4e3127f1.2030...@unfix.org, Jeroen Massar writes: On 2011-07-28 01:36 , Mark Andrews wrote: [..] Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP = dynamic NATted addresses - proto-41 + heartbeat + TIC = dynamic public addresses - AYIYA + TIC = dynamic NATted addresses I was more thinking about commonality with tunnel brokers. These all are implemented by tunnelbrokers, be they tunnel brokers where you can just fill in the details yourself (6to4) or the others where the parameters are provided by the entity you want to connect to. 6rd is not a replacement for 6to4 as it requires ISP involment or someone to create a registry of 3rd party 6rd providers along with associated parameters sets similar non anycast 6to4. 6rd is then also intended for a per ISP deployment. static proto-41 tunnel is also not a viable replacement as it doesn't handle address reassignment at the CPE end. See the proto-41 + heartbeat option, that is standard proto-41 but with a side-channel which beats where the endpoint currently is. But why are you trying to replace 6to4? What are the requirements that you have that are not satisfied by any of the above methods? Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
In message 4e3127f1.2030...@unfix.org, Jeroen Massar writes: On 2011-07-28 01:36 , Mark Andrews wrote: [..] Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP = dynamic NATted addresses - proto-41 + heartbeat + TIC = dynamic public addresses - AYIYA + TIC = dynamic NATted addresses I was more thinking about commonality with tunnel brokers. 6rd is not a replacement for 6to4 as it requires ISP involment or someone to create a registry of 3rd party 6rd providers along with associated parameters sets similar non anycast 6to4. static proto-41 tunnel is also not a viable replacement as it doesn't handle address reassignment at the CPE end. TSP conveys configurartion information inline with the UDP packets. TIC is solely for configuration information and does not do tunneling but can be used for all proto-41/heartbeat/AYIYA protocols (and for instance AVM chose to only do proto-41 + heartbeat as their devices always have public IPv4 IPs). Teredo is only for a single host thus is not useful for CPEs and thus not included in them. One of the advantages of 6to4 anycast is that it is just needs a check box to turn on and off. Everybody speaks the same thing. Except that it does not work behind a NAT and most people do sit behind a NAT. Next to that those anycasts are even rarer around the world and on top of that it is hard to figure out issues when they are there (although some people have tricks to apparently debug them, the anycast on both IPv4 and IPv6 requires one to contact a lot of folks). The big advantage over a known tunnel endpoint is the known behavior of that endpoint and the simple way of complaining when something is broken. And people fortunately do complain when stuff is broken, unfortunately not always with the proper details though, but I am to blame for not finishing that program up... Another advantage of 6to4 is it doesn't require manual intervention on renumber events. Manual tunnel don't pass muster. I guess you are one of the lucky people to get a public static IPv4 address prefix at home that never renumbers? Guess what, most of the world does not have that luxury, they get 1 dynamic address and for instance in Germany they get a disconnect/force-renumber every 24 hours (according to the ISPs because of 'accounting' reasons...) Do realize that when you have that public IPv4 address, when it changes you are renumbering your 2002:ipv4::/48 prefix everywhere. Fun... (I hope you also like asking 6to4.nro.net everytime to change your reverse) The tunnels above all have ISP-supplied prefixes and tend to be static (I think TSP anonymous tunnels rotate addresses, but the majority just keeps on returning the same static allocation, in the case of SixXS you really get a fixed address, much easier on the PoP side and we can do whois and store it in the relevant RIR registry) Another advantage of 6to4 is you don't have to register. For most of the tunnel brokers you have to register. I guess you also where able to anonymously sign up to your IPv4 ISP!? :) Especially that static IPv4 address must be wonderful to get that way. Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away. Something with the amounts of abuse made us (SixXS) require that we require valid address data. Next to that it is a RIPE requirement to register /48 prefixes. Other Tunnelbrokers just started blocking things like IRC and NNTP because there was too much abuse or traffic We kill off accounts of people when they abuse, google my name and you will find various people who where caught in the act and are quite mad that they can't have funny vhosts on IRC anymore and attract 500mbit DoSses and other such nonsense which are not the goal of providing IPv6. Also, the registration means that people can just type in their username/password (and optionally which tunnel they want to use out of the multiple tunnels they might have) in their CPE and the CPE then uses TIC or TSP to fetch this configuration and set it all up, and it will just work(tm). As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg and http://www.sixxs.net/wiki/Fritz!Box_7270 Next to that knowing where the user is and more importantly their endpoint allows one to select a proper PoP for that user close to their endpoint causing low latency and generally high throughput. With anycast you are just hoping that that all will work. Greets, Jeroen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 28, 2011 1:08 AM, Philip Homburg pch-v6...@u-1.phicoh.com wrote: In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote: In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that. Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them. I would hope that big companies like Apple would actually do an impact analysis before removing a feature. Like how Apple does not support Flash in iOS? Just one example where a visionary drops an inferior solution to force a better one. This is also known as cracking some eggs to make an omelet. Cb Big content providers can measure how much 6to4 is enabled, so they can probably say something about trends. But that doesn't say much about how many users actually care about 6to4. Vendors seem to be best equiped to analyse the users' need for 6to4. I don't think relay operators have expressed a desire for a specific cut off date. So I guess they just figure out for themselves when to switch off the relays. ___ 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] 6to4v2 (as in ripv2)?
From: Cameron Byrne cb.li...@gmail.com Like how Apple does not support Flash in iOS? Just one example where a visionary drops an inferior solution to force a better one. Apple has enough market share to get away with that. IPv6 doesn't. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-27 18:03 , Mark Andrews wrote: [..] b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses For which there is only experimental / ad-hoc code. You call my code Experimental/ad-hoc? :) Like a good whiskey it matured over the years and hopefully soon I will be releasing the next edition of AICCU which solves, at least in that implementation, a couple of quirks that we have encountered in the recent years. Please name CPE vendors that support tsp? Please name CPE vendors that support tunnel re-configuration on re-number. I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA in some cases there are a variety of vendors, amongst which AVM Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget ;) I unfortunately do not have an exact list of devices/models as I had nothing to do with them, we just get users saying that they have a device which supports it ;) The fun part though with CPEs is that they tend to sit on the public IP address, which is also the reason why the Fritz!Box only does TIC/heartbeat. And of course every self respecting distribtion has support for it too by just adding AICCU, that includes the various WRTs, pfSense, m0nowall, Astaro and many many others. As you said, everybody can decide themselves what options they add ;) Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-27 20:21 , Keith Moore wrote: On Jul 27, 2011, at 11:35 AM, Tim Chown wrote: I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? tunnel brokers suck if the tunnel endpoint isn't near your current network location. Let me rewrite that sentence for you: transition mechanisms suck if the tunnel endpoint isn't near your current network location It does not matter much if that mechanism is static proto-41 (6in4), 6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a bit more latency if they are not directly next to you. Not much you can do about except deploy more of them or And this will always be the case unless you deploy enough of them in all places possible. For SixXS we are at 48 boxes around the world, Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and then there are 4 others at other organizations and there are a couple of other services out there which provide tunnels see: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions. For your set of requirements maybe but especially Tunnel Brokers are working very well for a lot of people and if one sees the traffic stats on Teredo and 6to4 nodes due to this little thing called NNTP I would state that those are doing quite fine too for giving access to what people need to get to. Your major requirement seems to involve latency though, thus as such, there is only one thing to do, get one of those boxes deployed locally to your endpoint. Do note to yourself that the next issue you will run into that the service you are actually contacting will be far away, and you suddenly understand that you need that Akamai content box and a Google one and various other closeby too ;) If you want to solve your problem though, I guess for HE you'll have to give them connectivity to their network and space in a rack for a box, gogo6 will sell you a box and for SixXS you provide the box+connectivity and we'll set up the software for free for you and handle the tunneling completely. Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote: In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that. Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them. I would hope that big companies like Apple would actually do an impact analysis before removing a feature. Big content providers can measure how much 6to4 is enabled, so they can probably say something about trends. But that doesn't say much about how many users actually care about 6to4. Vendors seem to be best equiped to analyse the users' need for 6to4. I don't think relay operators have expressed a desire for a specific cut off date. So I guess they just figure out for themselves when to switch off the relays. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 2011-07-28 01:36 , Mark Andrews wrote: [..] Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP = dynamic NATted addresses - proto-41 + heartbeat + TIC = dynamic public addresses - AYIYA + TIC = dynamic NATted addresses TSP conveys configurartion information inline with the UDP packets. TIC is solely for configuration information and does not do tunneling but can be used for all proto-41/heartbeat/AYIYA protocols (and for instance AVM chose to only do proto-41 + heartbeat as their devices always have public IPv4 IPs). Teredo is only for a single host thus is not useful for CPEs and thus not included in them. One of the advantages of 6to4 anycast is that it is just needs a check box to turn on and off. Everybody speaks the same thing. Except that it does not work behind a NAT and most people do sit behind a NAT. Next to that those anycasts are even rarer around the world and on top of that it is hard to figure out issues when they are there (although some people have tricks to apparently debug them, the anycast on both IPv4 and IPv6 requires one to contact a lot of folks). The big advantage over a known tunnel endpoint is the known behavior of that endpoint and the simple way of complaining when something is broken. And people fortunately do complain when stuff is broken, unfortunately not always with the proper details though, but I am to blame for not finishing that program up... Another advantage of 6to4 is it doesn't require manual intervention on renumber events. Manual tunnel don't pass muster. I guess you are one of the lucky people to get a public static IPv4 address prefix at home that never renumbers? Guess what, most of the world does not have that luxury, they get 1 dynamic address and for instance in Germany they get a disconnect/force-renumber every 24 hours (according to the ISPs because of 'accounting' reasons...) Do realize that when you have that public IPv4 address, when it changes you are renumbering your 2002:ipv4::/48 prefix everywhere. Fun... (I hope you also like asking 6to4.nro.net everytime to change your reverse) The tunnels above all have ISP-supplied prefixes and tend to be static (I think TSP anonymous tunnels rotate addresses, but the majority just keeps on returning the same static allocation, in the case of SixXS you really get a fixed address, much easier on the PoP side and we can do whois and store it in the relevant RIR registry) Another advantage of 6to4 is you don't have to register. For most of the tunnel brokers you have to register. I guess you also where able to anonymously sign up to your IPv4 ISP!? :) Especially that static IPv4 address must be wonderful to get that way. Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away. Something with the amounts of abuse made us (SixXS) require that we require valid address data. Next to that it is a RIPE requirement to register /48 prefixes. Other Tunnelbrokers just started blocking things like IRC and NNTP because there was too much abuse or traffic We kill off accounts of people when they abuse, google my name and you will find various people who where caught in the act and are quite mad that they can't have funny vhosts on IRC anymore and attract 500mbit DoSses and other such nonsense which are not the goal of providing IPv6. Also, the registration means that people can just type in their username/password (and optionally which tunnel they want to use out of the multiple tunnels they might have) in their CPE and the CPE then uses TIC or TSP to fetch this configuration and set it all up, and it will just work(tm). As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg and http://www.sixxs.net/wiki/Fritz!Box_7270 Next to that knowing where the user is and more importantly their endpoint allows one to select a proper PoP for that user close to their endpoint causing low latency and generally high throughput. With anycast you are just hoping that that all will work. Greets, Jeroen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
Hi, On Thu, Jul 28, 2011 at 11:20:18AM -0400, Noel Chiappa wrote: Apple has enough market share to get away with that. IPv6 doesn't. Just how much market share has 6to4, if we exclude those two users? It's amazing how many human life cycles got wasted on this (and that I can't refuse to be sucked into this again). gert -- have you enabled 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] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 9:07 AM, John Mann (ITS) wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. only if you're confused about the use cases for each. In my opinion: 6to4 use case - D.I.Y setup - no ISP involvement - depend upon kindness of strangers to run the anycast relays - some users have hard-to-solve reliability problems - experimental / historic / not-recommended - should be off by default - for users who would prefer unreliable IPv6 to no IPv6 close, but no cigar. the use case for 6to4 is when - you have a public IPv4 address - your ISP doesn't support any kind of IPv6 access - there's no good native v6 tunnel endpoint near your host, or your host is mobile - you have applications for IPv6 other than to access content that is also available via IPv4, OR your hosts are set up to prefer native IPv4 over 6to4 addresses 6rd use case - configuration parameters set by ISP - ISP runs the relays - apparently production quality (see free.fr) - for users who would prefer no IPv6 to unreliable Internet I agree that 6rd is not a replacement protocol for the 6to4 use case. I will argue that the 6rd use case is a replacement for the 6to4 use case. If you have 6rd or any kind of native IPv6 available to you, you'll almost certainly prefer it to 6to4, except perhaps when needing to communicate with other hosts using 6to4. The problem is that native IPv6 is not widely available, and will not be universally available for maybe 10 years. (Or maybe, never, because the deployment model in many people's minds assumes that the only reason to use IPv6 is to access content that will continue to be available via IPv4 indefinitely.) We want normal users to move past experimental IPv6 towards production IPv6. I want that too. What I object to is a denial-of-service attack on people who find 6to4 useful, just because it doesn't work as well as IPv4 for services that support both IPv4 and IPv6. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011 4:32 AM, Mark Townsley m...@townsley.net wrote: On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 +1 as well as 6in4 or native v6. The full requirements of 6to4 are based on currently unrealistic requirements for no-nat (apnic is post exhaust ) and service providers to stand up relays without a reasonable business case - Mark ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ 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] 6to4v2 (as in ripv2)?
On Jul 27, 2011 7:20 AM, Ted Lemon ted.le...@nominum.com wrote: If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? This seems like an easy question to answer. You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol. It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight. Cb ___ 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] 6to4v2 (as in ripv2)?
In message CAD6AjGTPjhD=yiv5pe6g4trgknpyzn0_nmk9v8bevmgtqu2...@mail.gmail.com , Cameron Byrne writes: On Jul 27, 2011 4:32 AM, Mark Townsley m...@townsley.net wrote: On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 +1 as well as 6in4 or native v6. The full requirements of 6to4 are based on currently unrealistic requirements for no-nat (apnic is post exhaust ) and service providers to stand up relays without a reasonable business case There are lots of things that require no-nat. 6to4 is just one of them. ISP will end up providing no-nat for those that need it the same way as they provide unfiltered port 25 for those that need it and it also shouldn't cost more. Yet there are relays out there and there are business cases to run them. 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] 6to4v2 (as in ripv2)?
In message 968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com, Ted Lemon writes : If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? Because it will come down to run 6to4 and be exposed to some bug or not run 6to4 but be safe from the bug. We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. This seems like an easy question to answer. You'd implement and use 6to4v= 2 because it works better than the historic 6to4 protocol. -- 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] 6to4v2 (as in ripv2)?
On Jul 27, 2011 8:16 AM, Mark Andrews ma...@isc.org wrote: In message 968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com, Ted Lemon writes : If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? Because it will come down to run 6to4 and be exposed to some bug or not run 6to4 but be safe from the bug. We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. You also have content owners that say no while 6to4 is tanking reliability stats. Pick your battles. Cb This seems like an easy question to answer. You'd implement and use 6to4v= 2 because it works better than the historic 6to4 protocol. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 10:37 AM, Cameron Byrne wrote: On Jul 27, 2011 7:20 AM, Ted Lemon ted.le...@nominum.com wrote: If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? This seems like an easy question to answer. You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol. It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight. And natpt implementations still exist and are used by consenting adults. At a previous employer we were considering the business case for an implementation well after it's historic status. better solutions came along. Cb ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 27 Jul 2011, at 16:15, Mark Andrews wrote: Because it will come down to run 6to4 and be exposed to some bug or not run 6to4 but be safe from the bug. We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. I would note that RIPE-501 does not mention 6to4: http://www.ripe.net/ripe/docs/ripe-501 As far as I can see, it only mentions RFC4213. I would ask what is the alternative if as Mark suggests the vendors begin removing 6to4 support? a) use 6to4 anyway on an open platform like OpenWRT b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses c) use your $work VPN if it supports IPv6, which it could/should if your company values IPv6 d) get IPv6 from your ISP, or move to one that has it if yours does not I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: In message 4e2f4491.30...@gmail.com, Brian E Carpenter writes: Of course, if implementors choose to drop the code you might not be able to upgrade software versions - but hopefully by that time you will have native IPv6 service anyway. Which is exactly why HISTORIC is NOT appropriate. With rfc3484-revise and the documented brokenness of 6to4, it doesn't make any sense for implementors to offer 6to4 anyhow. So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 - Mark ___ 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] 6to4v2 (as in ripv2)?
Hi, On 27 July 2011 22:15, Keith Moore mo...@network-heretics.com wrote: On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. only if you're confused about the use cases for each. In my opinion: 6to4 use case - D.I.Y setup - no ISP involvement - depend upon kindness of strangers to run the anycast relays - some users have hard-to-solve reliability problems - experimental / historic / not-recommended - should be off by default - for users who would prefer unreliable IPv6 to no IPv6 6rd use case - configuration parameters set by ISP - ISP runs the relays - apparently production quality (see free.fr) - for users who would prefer no IPv6 to unreliable Internet I agree that 6rd is not a replacement protocol for the 6to4 use case. I will argue that the 6rd use case is a replacement for the 6to4 use case. [ And that native dual-stack is a replacement for both. ] We want normal users to move past experimental IPv6 towards production IPv6. Thanks, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? This seems like an easy question to answer. You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
Moving 6to4 to historic does not in any way impact your ability to use it as you wish. 6to4 support is not part of the IPv6 node requirements, as I understand it. Therefore I believe that any vendor (OS, router, otherwise) could deleted 6to4 support in any release and be in violation of anything, regardless of historic status. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
In message EMEW3|fcf145b5033ff99790b7c34003f47686n6QGZC03tjc|ecs.soton.ac.uk|D 0d20eb6-78c9-415d-9493-3aa08faac...@ecs.soton.ac.uk, Tim Chown writes: On 27 Jul 2011, at 16:15, Mark Andrews wrote: Because it will come down to run 6to4 and be exposed to some bug or not run 6to4 but be safe from the bug. We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. I would note that RIPE-501 does not mention 6to4: http://www.ripe.net/ripe/docs/ripe-501 As far as I can see, it only mentions RFC4213. I would ask what is the alternative if as Mark suggests the vendors begin rem oving 6to4 support? a) use 6to4 anyway on an open platform like OpenWRT Which may or may not still have the code. OpenWRT could remove support just the same as another source could. OpenWRT is also not widely supported by CPE vendors. i.e. you are own your own if something goes wrong in most (not all) cases. b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses For which there is only experimental / ad-hoc code. Please name CPE vendors that support tsp? Please name CPE vendors that support tunnel re-configuration on re-number. c) use your $work VPN if it supports IPv6, which it could/should if your comp any values IPv6 d) get IPv6 from your ISP, or move to one that has it if yours does not Which is not always a viable option. I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? Tim ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- 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] 6to4v2 (as in ripv2)?
From: Philip Homburg pch-v6...@u-1.phicoh.com I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. There have been suggestions that it might be more appropriate to reclassify it as Experimental, and I think that makes a lot of sense - as you correctly (IMO) point out, due to its issues 6to4 is not really appropriate for standards track (at least, in its current form). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 7/27/11 4:31 AM, Mark Townsley wrote: On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 +1 -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
In message CAD6AjGThTpvH5HgGc8RbedOcJKZ=_JLR=2t7yaajwkss1ck...@mail.gmail.com , Cameron Byrne writes: On Jul 27, 2011 8:16 AM, Mark Andrews ma...@isc.org wrote: In message 968f0b1c-d082-4a59-8213-fd58c74af...@nominum.com, Ted Lemon writes : If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? Because it will come down to run 6to4 and be exposed to some bug or not run 6to4 but be safe from the bug. We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. You also have content owners that say no while 6to4 is tanking reliability stats. You have Google Chrome and Firefox already implementing HE. You have new address selection rules out there. You have a dramatic decrease in 6to4 traffic already as a result. You have improved throughput for the 80% of machines for which 6to4 does work. We are yet to see the effects of Mac OS Lion both the 6to4 side and the HE side. Pick your battles. Cb This seems like an easy question to answer. You'd implement and use 6to4v= 2 because it works better than the historic 6to4 protocol. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- 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] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 7:31 AM, Mark Townsley m...@townsley.net wrote: On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 - Mark +2 ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On 27 Jul 2011, at 17:03, Mark Andrews wrote: 0d20eb6-78c9-415d-9493-3aa08faac...@ecs.soton.ac.uk, Tim Chown writes: a) use 6to4 anyway on an open platform like OpenWRT Which may or may not still have the code. OpenWRT could remove support just the same as another source could. OpenWRT is also not widely supported by CPE vendors. i.e. you are own your own if something goes wrong in most (not all) cases. In the event OpenWRT should remove 6to4 support, just get like-minded people together (if there are lots of people that consciously want to use 6to4 for application development and testing) and roll your own. b) use a tunnel broker - this works much better through NATs and with dynamic IPv4 addresses For which there is only experimental / ad-hoc code. Please name CPE vendors that support tsp? Please name CPE vendors that support tunnel re-configuration on re-number. Jeroen has answered this, but I would point out, as an example of what can be done in short time, that I had a student last year who developed a mini-ITX Linux build with tunnel broker support, and IPv6 firewall and QoS support, using a web interface driving existing tools like iptables and tc. He chose to use the HE broker, and it's a one-time registration after which it just works without further user intervention with HE. It would be very interesting to see brokenness figures for well-known broker prefixes as against 6to4, if anyone is gathering such data. c) use your $work VPN if it supports IPv6, which it could/should if your comp any values IPv6 d) get IPv6 from your ISP, or move to one that has it if yours does not Which is not always a viable option. It is in the UK, at least. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 11:35 AM, Tim Chown wrote: I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? tunnel brokers suck if the tunnel endpoint isn't near your current network location. there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: In message 4e2f4491.30...@gmail.com, Brian E Carpenter writes: Of course, if implementors choose to drop the code you might not be able to upgrade software versions - but hopefully by that time you will have native IPv6 service anyway. Which is exactly why HISTORIC is NOT appropriate. With rfc3484-revise and the documented brokenness of 6to4, it doesn't make any sense for implementors to offer 6to4 anyhow. False. It makes even more sense to offer 6to4 because it significantly decreases the chance that it will cause a bad experience for users of services that provide both v4 and v6 addresses, while increasing the chance letting local hosts/users talk to v6-only services/hosts. So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. Vendors can drop 6to4 support, or for that matter any other feature, anytime they wish. They don't need permission from IETF to do that. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 11:12 AM, Erik Kline wrote: Moving 6to4 to historic does not in any way impact your ability to use it as you wish. False. Moving 6to4 to Historic is inviting people to mount denial of service attacks on things that actually work for people today. Moving 6to4 to Historic will also invite vendors to remove 6to4 support from future versions or updates of their products, forcing users to make difficult choices between using 6to4 on one hand and changing equipment or vendors on another. There's no reason to cause that kind of collateral damage. Denial of service attacks are completely inappropriate. 6to4 support is not part of the IPv6 node requirements, as I understand it. Therefore I believe that any vendor (OS, router, otherwise) could deleted 6to4 support in any release and be in violation of anything, regardless of historic status. Nothing that IETF specifies requires 6to4. Vendors can indeed delete it if they want to. But IETF should not recommend that they do so, or imply that they should do so. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) john.m...@monash.edu wrote: snip [ And that native dual-stack is a replacement for both. ] We want normal users to move past experimental IPv6 towards production IPv6. Exactly, we should focus on doing production IPv6, not wasting our time on something that run on top of something else, whatever it's called (are way too many to choice from already and I will recommend anyone that ask me to never walk down that road, never). So, can we please stop this never ending SPAMMING with regards to 6to4? It is a total waste of time, really Keith, please stop. pretty please stop. -- 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] 6to4v2 (as in ripv2)?
Le 27/07/2011 21:25, Roger Jørgensen a écrit : On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS)john.m...@monash.edu wrote: snip [ And that native dual-stack is a replacement for both. ] We want normal users to move past experimental IPv6 towards production IPv6. Exactly, we should focus on doing production IPv6, not wasting our time on something that run on top of something else, whatever it's called (are way too many to choice from already and I will recommend anyone that ask me to never walk down that road, never). So, can we please stop this never ending SPAMMING with regards to 6to4? It is a total waste of time, really Keith, please stop. pretty please stop. I believe 6to4 is useful dont make it historic without a clear replacement strategy which is backwards compatible with installed base. open source and no need to fill in forms on web pages. Alex ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
Roger == Roger Jørgensen rog...@gmail.com writes: We want normal users to move past experimental IPv6 towards production IPv6. Roger Exactly, we should focus on doing production IPv6, not wasting our Roger time on something that run on top of something else, whatever Roger it's So, in your opinion, a production host will never have more than one address? This is the fundamental problem. 6to4 is just the thing shining the light on the problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. As one of those implementers-- as in, it will probably be *my* commit to the repository that does rm $XNU/bsd/net/if_stf.c—- I now feel compelled to reiterate that I would prefer a more controlled phase-out plan than, equipment vendors and operators are free to commence the destruction of 6to4 at their individual convenience and without further warning to the user community. In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that. Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them. -- 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
