ietf
[Top] [All Lists]

Re: Just Thinking (About the Nightmare Transition Ahead)

2011-01-24 06:59:40
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 <marka(_at_)isc(_dot_)org> wrote:


In message 
<201101241115(_dot_)p0OBFPmU016916(_at_)fs4113(_dot_)wdf(_dot_)sap(_dot_)corp>,
 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf




-- 
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf