Re: What is Native IPv6
In your letter dated Fri, 29 Jul 2011 19:31:13 -0700 you wrote: - If one is in the business of writing an draft about what is native IPv6, and if one of the draft's goals is to reach -cough- consensus -cough-, one may consider forgetting the 6PE classification altogether. The one part that is not open for grabs with me is classifying 6RD as native. Why do you care so much about 'native'? At the moment, I have 5 IPv6 connections: 1) native 2) tunnel to my ISP 3) tunnel to HE 4) tunnel to SixXS 5) 6to4 Obviously, the first one is native and the others aren't, But as user of those links, it seems a completely arbitrary and useless distinction. Number 5, 6to4 is obviously a problem. So that's in the 'avoid' category. Number 3 and 4, require good access to the IPv4 Internet. At the moment they work perfectly, but they are not future proof. Numbers 1 and 2. In first case, ppp frames go over atm/ethernet to my ISP. In the second case, IPv4 packets go over ppp frames over atm/ethernet to my ISP. Yes, compared to native, the tunnel has an extra IPv4 header, but otherwise, there is no difference. (At my ISP, native and tunneled are terminated differently, but so far that difference is almost impossible to notice) So my classification would be 1) IPv6 provided by the user's ISP. (native, 6rd, tunnel by ISP) 2) IPv6 provided by a third party (tunnels by other parties) 3) IPv6 provided by unknown third parties (6to4, teredo) 1) can be made to work very well, 2) has problems, 3) is to be avoided. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What is Native IPv6
In your letter dated Sat, 30 Jul 2011 11:39:53 -0700 you wrote: 6RD is not a last mile solution. With the existing levels of IPv6 traffic, an ISP would deploy a couple of 6RD relays at their main IX. In a country such as France, it means that a 6RD customer in Nice would see their IPv6 traffic bei ng encapsulated all the way to Paris over IPv4 crossing the entire ISP's netwo rk for some 400 miles. In Spain, the really native part of the traffic would p ossibly start in Madrid. Imagine 2 customers in Barcelona, who are with two different ISPs using 6RD. T he 6RD relays are in Madrid for both, likely not much more than a few miles aw ay or even possibly in the same IX (I don't know the details of IXes in Madrid ). The 6RD traffic from one goes over IPv4 all the way to Madrid, then goes na tive for a few miles to the other ISP's 6RD relay, then back over IPv4 to Barc elona. This is not native. So, 6rd is bad because it allows an ISP to deploy it in a sub-optimal way. Wow, if that how we are going to judge protocols then we can just as well go home. If the existing levels of IPv6 traffic were a reason to install just one 6rd box for an entire country then expecting that ISP to deploy native IPv6 would be extremely unrealistic. And even if an ISP would do that. The round trip latency between Barcelona and Madrid is likely to be in the order of 5ms. There are DSL error correcting settings that have much impact than that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt
In your letter dated Fri, 29 Jul 2011 04:38:12 +0200 (MEST) you wrote: Mark Andrews wrote: Martin Rex writes: Mark Andrews wrote: More correctly it is try the first address and if that doesn't connect in a short period (150...250ms) start a second connection to the next address while continuing with the first. If you have more that 2 address you do something similar for the next one Happy eyeballs means that a clients reaction to congestion is to perform an DoS attack, flood the network with additional connection requests and hammer the server with many additional half-open connections that will never actually get used. It is not a DoS attack. The client is almost certainly going to make those connection attempts anyway if the path is congested enough to cause the first connection attempt to fail. The only difference is the application gives up in 30 seconds rather than 60 or 90 seconds by doing the attempts serially. 150...250ms ?! For a satellite link you already have started 3 parallel connects in non-congested(!) situations. just some random IPv4 pings from my office (in germany) _without_congestion_: ping www.asus.com.tw300-380ms ping south-america.pool.ntp.org 280-370ms ping oceania.pool.ntp.org 340-420ms ping www.eff.org160-170ms ping www.ietf79.cn 330-450ms ping www.ietf76.jp 270-370ms So your approach is already hurting the network without congestion! There are two ways to do Happy Eyeballs. A simple immediate solution that works in most cases to use a fixed timeout value. In your case, you would have to increase that value to a bit higher than 400ms. If HE was invented a long time ago, then by now there could have been a parameter in DHCP to let the network control this parameter. The other way of doing HE is make it react to observed connect time. In that case if you are regularly connecting to sites that are more than 400ms away then the parameter will automatically increase to that value. The proposal is currently discussed in v6ops and everybody seems to be happy with it. So a critical voice may help shape the proposal a bit. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
In your letter dated Thu, 28 Jul 2011 18:55:04 -0700 you wrote: On Jul 28, 2011 5:28 PM, Martin Rex m...@sap.com wrote: It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). In particular, if the remote address is encoded this way. If the host has to chose between an IPv6 or IPv4 destination address then the protocol is fixed. I think that would have been a much better use of thse bits then simply storing the ethernet address there. But anyhow, it should be possible to do that with a destination option with is then inspected by some middle box that makes a routing decision. But that would require a lot of changes to retrofit it in todays operating systems. This is largely (not entirely) achieved with nat64 / dns64. That would require the dns64 box to do destination selection. Possible, but maybe also tricky to keep a dns resolver informed about the current state of the network. ___ 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: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote: PS - And in those cases, proper address selection is a much better solution (IMHO) than hitting this screw with a hammer. I think the problem is that we don't know how to do 'proper' address selection. It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. Today, we are just in the stage of doing more experiments. There is one thing that works well. And that is, you only assign global IPv6 addresses to a host if global IPv6 connectivity is at least as good as IPv4 connectivity. We want large scale deployment of IPv6 today not some time in the future when we finally figured out address selection. And that means that today we have to make sure that users don't end up with unreliable IPv6 connections. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
In your letter dated Thu, 28 Jul 2011 07:50:38 -0400 you wrote: In general, all of a host's addresses (at least, those in the same preference class in the address selection algorithm) need to work equally well from everywhere. But even that might not be sufficient. Fred Baker has recently been citing a different example of the same problem: Imagine a future where hosts on a network have both v6 and legacy v4 through stateful NAT. Because the v6 connection works well most of the time, hosts tend to choose v6 destinations, and sites reduce the capacity of their NATs over time. Then the v6 connection fails, and suddenly everything falls back to v4, and the connections through NAT also fail for lack of sufficient capacity to handle the load. I'm sure some manager will just require this to work. But I would say that this is just supposed to fail. If you had in the past just an IPv4 connection and it went down, there would be no Internet access. Same thing in the future. If your IPv6 connection goes down you don't have an Internet conenction. It would be different if the NAT was there just to connect to a very specific collection of legacy IPv4 sites. But that can be solved easily but just routing those IPv4 prefixes to the NAT. If you want the NAT to provide full redundancy, then it has to be scaled to accept full load. Otherwise, no IPv6 just means no Internet. Very simple. We want large scale deployment of IPv6 today not some time in the future when we finally figured out address selection. And that means that today we have to make sure that users don't end up with unreliable IPv6 connections. If you make the constraint that nobody can use IPv6 at all until the IPv6 connections work as well in all cases as the IPv4 connections, that creates a huge barrier to the universal deployment of IPv6 - which already has enough barriers as it is. To some extent that is exactly the way it is. Suppose that a significant fraction of popular websites would have IPv6 addresses that don't actually work. Then essentially no ISP would enable IPv6 for their customers because their customers would suffer. At the moment, most servers that do have IPv6 addresses seem to actually support IPv6 so this doesn't seem to be a big problem. But we don't know what the future might bring. If there would be a sudden rush of servers that have PMTU problems, then we could have a very serious problem. A less onerous constraint is that less reliable IPv6 connections don't get used in preference to more reliable IPv4 connections. We're lucky in the case of 6to4 in that it has a well-known prefix that allows the traffic to be distinguished from other v6 traffic. But it's still necessary to manage expectations about IPv4 as a fallback path. Happy Eyeballs can solve a lot of problems where a connection will fail completely or have a high latency. But HE support is far from universal and so far experience is limited to TCP. But it doesn't do anything for PMTU problems. It also doesn't do anything for real-time streaming applications. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
In your letter dated Thu, 28 Jul 2011 17:08:01 +0900 you wrote: Philip Homburg wrote: I think the problem is that we don't know how to do 'proper' address selection. I know and it's trivially easy. 11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote: End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. which means an end system should have a full routing table, IGP metrics in which tell the end system what is the best address of its multihomed peer. Full routing table should and can, of course, be small. Even in the unlikely case that it would be feasible to give every host a complete copy of the DFZ routing table... That still would leave a lot of issues open... 1) End-to-end latency. Maybe some future generation BGP provides that, but that doesn't help now. 2) For 6to4, the use of anycase. You probably need a link-state routing protocol to allow a host to figure out which relays are going to be used on a give path. 3) Filters in firewalls. I'd love to see a routing protocol that reports the settings of all firewalls in the world :-) 4) Other performance metrics, like jitter, packets loss, etc. Maybe you can do some experiments and report on how well your draft works for deciding when to prefer a 6to4 address over IPv4. ___ 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)?
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: draft-ietf-v6ops-6to4-to-historic (yet again)
In your letter dated Mon, 25 Jul 2011 20:25:53 -0700 you wrote: Maybe I'm reading the list wrong, but I think the sticky point here is the historic thing, and nothing short of removing that part will significantly change the mindset of people who oppose it. Have you considered a newer revision of the 6-to-4 RFCs that would obsolete the current ones and add that 6-to-4 should be disabled by default? That could reach consensus. Hmm, I never bothered to really study RFC-2026. But now I found this: [Section 6.2:] When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, at the same time the IESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. This decision shall be communicated to the IETF by electronic mail to the IETF Announce mailing list to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort. I think it is safe to say that 6to4 is a standard track protocol that is going nowhere. So why can't the IESG just decide to move 6to4 to historic? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)
In your letter dated Tue, 19 Jul 2011 08:26:26 +0900 you wrote: Given that each of us reads something different into the definition of HISTO RIC, is there any hope that this thread will ever converge? I don't see any progress. We may just have to blacklist any resolvers that have 6to4 clients behind them and leave it at that. I don't think there is any need to be overly dramatic about it. I firmly belive that 6to4 should be moved to historic. But at the same time, I was looking for a poorly performing IPv6 connection to test happy eyeballs and didn't find it. 6to4 can just work. So a less aggressive approach might be in order. (If you look at the numbers, there are fewer and fewer 6to4 connections to dual-stack sites because modern operating system releases will prefer IPv4 over 6to4. Of the users who didn't upgrade, there is about 20% with a completely broken 6to4 setup. What remains is slightly higher latency due to non-optimal placement of relays) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In your letter dated Sat, 2 Jul 2011 16:02:47 -0400 you wrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. Is there any summary of the IETF community consensus? I sort of can't imagine that ISPs want to continue operating 6to4 relays longer than strictly necessary. So I'm curious what the IETF community at large considers the future of 6to4 in it's default-disabled mode. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding records. In other words, it was ticking time bomb. This time bomb has been defused mostly because most operating system now prefer any kind of IPv4 over a 6to4 address. So once again people can have a broken 6to4 setup without noticing it. What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. So we may end up with a sizable group people who have an IPv6 setup that completely doesn't work. And they don't know it. Which will create all kinds of headaches for IPv6-only content because you have to explain to users that yes, they have an IPv6 address and no, it is not going to work. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
In your letter dated Thu, 9 Jun 2011 10:37:56 -0400 you wrote: I have also seen those claims in v6ops email (haven't caught up with all of it , but have seen a few messages). I don't buy the argument. Clearly the inten t of this draft and protocol action are to discourage use of 6to4, particularl y in new implementations. You can't discourage use of 6to4 in new implementat ions without harming people who are already using it and depending on it. (That would be a bit like declaring IPv4 Historic and discouraging new impleme ntations from supporting it - when we all know that there will be people using IPv4 in corner cases for many years even after the public Internet no longer routes it. Legacy hardware and software that's still in use, etc.) When the draft is clearly intended to do harm to 6to4, and there are clearly p eople using 6to4 in the Real World, it strikes me as disingenuous for its prop onents to claim that the document will do no harm. I think this is likely to happen anyway. In all discussions it has been come clear that 6to4 has nothing to offer for ordinary users, and that the situation is going to get worse over time (more NAT, more broken 6to4 installation). So for any CPE manufacturer is makes perfect sense to start planning on dropping support for 6to4 in future CPEs, or not add it at all, if they have yet to release firmware with IPv6 support. This is independent of whether the protocol is declared historic. On the other hand, there is no reason why open source distribution would have to drop 6to4 support. As long as there are people to maintain it, it can stay. Also on other operation systems, as long as there is some sort of tunnel interface, you can implement 6to4. It is just a few lines of code, everybody can do it. So I don't see the big fuzz. If you want to use it, just create a web page that lists software implementation of 6to4 for every possible platform. And let the authors of the software know have much their software is appreciated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
