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: 6to4v2 (as in ripv2)?
Le 27 juil. 2011 à 17:29, Michel Py a écrit : ... Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. Oh, yes indeed, on can! (Depending, of course on what you mean with 6to4-bis, but no one can be sure what you mean). - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. - 6to4 has known operational problems, not 6rd. The difference is in who configures/manages it, not how it works; See above. the 6rd code base is a superset of the 6to4. Although it has been convenient to deploy 6rd starting with existing 6to4 code, one can write 6rd code that doesn't work for 6to4. The difference is more a matter of network design than core protocol. It is a matter of clean IPv6 service, transparent to users, vs service for experts who know what they are doing. RD Michel. ___ 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: 6to4v2 (as in ripv2)?
Rémi Després despres.r...@laposte.net wrote: Le 27 juil. 2011 à 17:29, Michel Py a écrit : ... Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. Oh, yes indeed, on can! (Depending, of course on what you mean with 6to4-bis, but no one can be sure what you mean). - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. - 6to4 has known operational problems, not 6rd. In a sense, 6rd has all of the problems that 6to4 does. The difference is that 6to4 is deployed independent of network operators and often without their involvement, and 6rd (when deployed) is deployed by network operators on their own networks. So 6to4 tries to work over networks that might or might not be unsuitable for it, or even hostile to it. By contrast, if an operator's network isn't a good fit for 6rd, they simply don't use it. And presumably an operator choosing to use 6rd won't try to DoS it... Again: there are valid use cases for 6to4. But almost any kind of provider managed service (except one that NATs traffic) is almost certainly better. Keith -- Sent from my Android tablet with K-9 Mail. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
Rémi Després wrote: - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. That is playing with words. In that case, any router that delivers native IPv6 to the hosts (by having the tunnel software on the router, not on the hosts) can be called a native solution. This is just flat out WRONG. ANY solution that needs IPv4 to transport IPv6 is NOT native IPv6, and regardless of who states it and their great contributions, it will remain the same. Some please stop calling things what they are not; a native IPv6 solution is one that works when IPv4 has been removed, anything else is called a transition mechanism. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
Le 29 juil. 2011 à 18:21, Michel Py a écrit : Rémi Després wrote: - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. That is playing with words. In that case, any router that delivers native IPv6 to the hosts (by having the tunnel software on the router, not on the hosts) can be called a native solution. This is just flat out WRONG. ANY solution that needs IPv4 to transport IPv6 is NOT native IPv6, and regardless of who states it and their great contributions, it will remain the same. Some please stop calling things what they are not; a native IPv6 solution is one that works when IPv4 has been removed, anything else is called a transition mechanism. We have, it seems, a different understanding of the situation. The distinction to be made, and which I make, is between - native addresses vs well-known-prefix addresses (the former start with an ISP allocated prefix, the latter, e.g. those of 6to4 and Teredo, have a routing problem in the Internet backbone) - native IPv6 routing (IPv6-only or dual stack) vs IPv4-only routing 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
6rd addresses a different problem than 6to4. 6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users. 6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd subnet. The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers. In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the global, uncoordinated 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Friday, July 29, 2011 11:38 AM To: Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ 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: 6to4v2 (as in ripv2)?
In your letter dated Fri, 29 Jul 2011 11:38:16 -0700 you wrote: R?mi Despr?s wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Could you please elaborate why expect the internal IPv4 network of an ISP to break while they are using it for 6rd? It there some sort of built-in self-destruct mechanism somewhere? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
Christian, -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Christian Huitema Sent: Friday, July 29, 2011 12:17 PM To: Michel Py; Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? 6rd addresses a different problem than 6to4. 6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users. 6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd subnet. The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers. I think this is well said. Another way of saying the same thing is that 6to4 is an inter-site solution while 6rd is an intra-site solution when considering the provider network as a site. With extensions, ISATAP can also satisfy this provider network intra-site requirement (see draft-templin-isupdate) while enabling the desired IPv6 services for end-user sites. Thanks - Fred fred.l.temp...@boeing.com In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the global, uncoordinated 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Friday, July 29, 2011 11:38 AM To: Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ 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 ___ 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: 6to4v2 (as in ripv2)?
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 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. only if you're confused about the use cases for each. 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 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: 6to4v2 (as in ripv2)?
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? free.fr, which is a third of the worldwide IPv6 traffic. Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. The difference is in who configures/manages it, not how it works; the 6rd code base is a superset of the 6to4. The difference is more a matter of network design than core protocol. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: 6to4v2 (as in ripv2)?
On Jul 27, 2011 8:30 AM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: 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? free.fr, which is a third of the worldwide IPv6 traffic. Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. The difference is in who configures/manages it, not how it works; the 6rd code base is a superset of the 6to4. The difference is more a matter of network design than core protocol. 6rd also evolves 6to4 with a real and traceable support model. Cb Michel. ___ 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
Re: 6to4v2 (as in ripv2)? (was: draft-ietf-v6ops-6to4-to-historic (yet again))
I jump in the midle of discussion and lazy to dissect emails: Is there a replacement for historic 6to4? What should I now install in the lab, without interaction to some admin or web page of some core server? Thanks, Alex Le 26/07/2011 15:47, Ronald Bonica a écrit : Brian, Does the following text work for you? Ron N. Meaning of HISTORIC For the purposes of this document, the term HISTORIC means: - 6-to-4 should not be configured by default on any implementation (host, cpe router, other) - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products. - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Monday, July 25, 2011 11:09 PM To: Ronald Bonica Cc: ietf@ietf.org Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) To be clear, I'd like to see exact proposed text before expressing support for the proposal. The trick is to get 6to4 disabled by default at the user end, without disabling it for users who are getting good service from it. Regards Brian On 2011-07-26 09:49, Brian E Carpenter wrote: Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. This is, of course, an undeniable statement of fact (as it is for any other feature of the Internet). However, it needs to be made clear that doing so *prematurely* would penalise existing successful users of those relays, and therefore it should only be done when there is no successful traffic through them. Which is when any operator would remove them anyway. Therefore, I don't see much value in this statement, and possible harm to users. The ways to avoid such harm as far as possible are already in the RFC Editor queue. Regards Brian Carpenter On 2011-07-26 02:30, Ronald Bonica wrote: Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
Alex, 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? 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? 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. Regards Brian Carpenter On 2011-07-27 03:37, Alexandru Petrescu wrote: I jump in the midle of discussion and lazy to dissect emails: Is there a replacement for historic 6to4? What should I now install in the lab, without interaction to some admin or web page of some core server? Thanks, Alex Le 26/07/2011 15:47, Ronald Bonica a écrit : Brian, Does the following text work for you? Ron N. Meaning of HISTORIC For the purposes of this document, the term HISTORIC means: - 6-to-4 should not be configured by default on any implementation (host, cpe router, other) - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products. - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Monday, July 25, 2011 11:09 PM To: Ronald Bonica Cc: ietf@ietf.org Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) To be clear, I'd like to see exact proposed text before expressing support for the proposal. The trick is to get 6to4 disabled by default at the user end, without disabling it for users who are getting good service from it. Regards Brian On 2011-07-26 09:49, Brian E Carpenter wrote: Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. This is, of course, an undeniable statement of fact (as it is for any other feature of the Internet). However, it needs to be made clear that doing so *prematurely* would penalise existing successful users of those relays, and therefore it should only be done when there is no successful traffic through them. Which is when any operator would remove them anyway. Therefore, I don't see much value in this statement, and possible harm to users. The ways to avoid such harm as far as possible are already in the RFC Editor queue. Regards Brian Carpenter On 2011-07-26 02:30, Ronald Bonica wrote: Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011. Ron Bonica speaking as OPS Area AD ___ 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 ___ 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: 6to4v2 (as in ripv2)?
Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. By observation, the transition is continuing for these 16 years since RFC1883. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
In message 4e2f4491.30...@gmail.com, Brian E Carpenter writes: Alex, 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? 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? 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. Regards Brian Carpenter -- 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
