Sure people can do this, but what is the point? Let us imagine that as a matter of national policy we are all to live in smaller houses to save energy. In what respect would such a policy be realized if everyone bought a second, smaller house and started occupying both simultaneously?
The critical objective here is to create a situation where people can use the Internet successfully without requiring a full IPv4 address. It is not going to be the case that anyone can use pure IPv6 100% of the time for several decades. Getting people to use IPv6 is not an end in itself. If you have a full IPv4 address there is no point in using IPv6 in parallel. Its like buying a Prius to show how ecological you are and towing it behind your Hummer. The case where this dual stack is going to make sense is where the user has a shared IPv4 and clean IPv6 and there is a performance advantage to going through the clean connection. This is not something that I would want to have to code for as an application programmer. I would want to have a call of the form 'get best connection for (protocol, domain_name) and have the platform figure it out using information that I would not want the application programmer to have access to. <eom> On Mon, Jan 24, 2011 at 7:02 AM, Mark Andrews <[email protected]> wrote: > > In message <[email protected]>, Martin Rex > writes > : > > Brian E Carpenter wrote: > > > > > > However, see draft-wing-v6ops-happy-eyeballs-ipv6 > > > > Yuk. That approach appears to be from a completely different universe > > that solutions to the IPv4->IPv6 migration issue. > > > > Instead of solving the problem where it originates, at the network level, > > it dumps the entire problem onto the application in the worst conceivable > > fashion. It makes IPv6 and IPv4 worlds appear like two completely > > seperate and independent Internets, i.e. this proposal incurs on apps > > the exact same effort as migrating a completely different network > protocol > > or completely different network. > > The solution space is equally applicable to two IPv4 addresses or > two IPv6 addresses. You start one, wait a short while to see if > it succeeds then start another, etc. If the network is doing its > job you get a error back from it before you start the second and > you start it sooner. If it isn't then you don't waste 30 seconds > for the connect to timeout. > > If you have a abnormally long path then you get some embryonic > connections. 500ms is more than enough time to wait for a terrestrial > path to complete. Sydney, Australia to Europe is high 3 hundreds > to low 4 hundreds of milliseconds. > > % ~/a.out www.ripe.net > connect_to_host(www.ripe.net) -> 3 in 376 ms > % > > > If anyone had suggested that for a migration from PSTN to VoiP, then > > everyone would have to use two phones these days, dial in parallel > > and hang up on whichever call establishes second. > > I've seen plenty of people pick up one phone dial then put the call > on speaker then pick up a second phone and dial a different number > and put it on speaker when trying to reach someone with two numbers > urgently. They hang up which ever doesn't answer. > > > The problem that this draft tries to solve at the app-level really > > ought to be solved at the network level. Use IPv6 addresses that > > embed the alternative IPv4 address and have the network figure out > > whether the route is IPv6 clean and the connection can be established > > as IPv6 or only IPv4. (IPv4-NATing the IPv4 part of such an > > address along the way is probably "fun"...) ... for exactly those > > network interfaces that _have_ dual IPv4+IPv6 addresses. > > Having good error recovery at the application layer hasn't been a > issue until now because 99.99% of sites were single homed. This > is changing with almost a 100% of sites becoming multi-homed. It's > time the applications learned how to work well in such a environment. > > It might also mean that one might be able to stop having to deploy > DNS servers that track reachability just to get some robustness > that should have been there if clients wern't using naive connection > strategies. > > B.T.W. the a.out above implements this sort of connection strategy > with a 500 ms wait before attempting the second connection. The > wait for the 3rd connection is 250 ms, the 4th is 125 ms, the 5th > is 62 ms. You get the pattern. There are poll, select and thread > based versions. > > Mark > > > -Martin > > _______________________________________________ > > Ietf mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ietf > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
