Subject: Just Thinking (About the Nightmare Transition Ahead)

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 22 Jan 2011 15:34:33 +0000

My thought right now is perhaps of an OS update that includes a background client which tries very hard to reduce the effect of breakage or delay caused by IPv6 routes that are dead, DNS queries that don't go anywhere, and delays caused by slow transition techniques.  It couldn't be comprehensive, but I think it'd go a long way at this point.  The software vendors could, for instance, provide the test sites that receive IPv6 probes and/or traffic, and respond to them.  Not scalable? ...

Cheers,
Sabahattin

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Jan 2011 07:48:40 +1300

What nightmare? I find IPv6 dual stack works just fine.

However, see draft-wing-v6ops-happy-eyeballs-ipv6

Regards
   Brian Carpenter

On 2011-01-23 04:34, Sabahattin Gucukoglu wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 22 Jan 2011 20:46:04 +0000

> What nightmare? I find IPv6 dual stack works just fine.

It does, when your connectivity is working.  Unfortunately, the 0.1% (or whatever it is) of users whose connectivity isn't working seem to be sufficient in number to prevent large sites from deploying, and a number of others to just turn IPv6 off.  Not news, except I'd hate for this to be justification in keeping dual-stack from happening (the effects of which must be considerably worse than just losing 0.1% of users), especially since the publicity about "World IPv6 Day" has brought the whole issue to light.

Of course, I'd also like Google to run IPv6 (on its main web servers) for longer than 24 hours at a time. :-)

> However, see draft-wing-v6ops-happy-eyeballs-ipv6

Yes.  I'd love there to be some sort of consensus on it, or something like it.  I'd focus more on testing connectivity, though, rather than optimal calculation of IPv6 reachability using one protocol/application to any given place at the time (i.e. rough and ready determination at OS boot whether we're on a broken network, EG).  It would not be foolproof, but it would not need to be in order to be useful in the short-term.  Perhaps Happy Eyeballs is the answer.

Cheers,
Sabahattin

---

From: [email-masked]
Date: Sun, 23 Jan 2011 08:06:47 +0200

Hi,

I agree with Brian. What nightmare? It only seems as a nightmare until you don't have it in place.

It is not about the transition itself, rather about the conceptual fact. First off all, the common belief is for 0.05% of brokenness (most of it coming from old version of Mac OS X, some from old versions of Opera etc.). Now, that was half a year ago. Is it the same today? Have you noticed that no one has ever said that the service WILL be broken, but rather MIGHT be broken. This is a very important distinction. Also, do you know of any standardized method of measuring it? Have you ever measured the brokenness in IPv4 due to MTU issues or DNS problems? For instance I have quite often encountered issues with my home service provider, that had an overloaded DNS during the peak hours that used to time out on various occasions, and the page would not display until you hit refresh. Is it brokenness?

So, really - I believe that to some extent the World IPv6 Day is a first step that proves QA departments are starting being comfortable with the new realities.

What is a little hard, is the operations, where you need to watch now for two protocols in the same time, while the feature parity is still an issue. But I would hardly call this a nightmare.

Best,
Roman

[email-masked] wrote: -----

To: Brian E Carpenter <[email-masked]>
From: Sabahattin Gucukoglu
Sent by: [email-masked]
Date: 01/22/2011 10:47PM
Cc: [email-masked]
Subject: Re: Just Thinking (About the Nightmare Transition Ahead)

Cheers,
Sabahattin

---

From: Martin Rex <[email-masked]>
Date: Mon, 24 Jan 2011 12:15:25 +0100 (MET)

> 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.

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.

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.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Jan 2011 23:02:48 +1100

In message <[email-masked]>, Martin Rex writes
> 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
% 

> 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.

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Jan 2011 07:59:18 -0500

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>

-- 
Website: http://hallambaker.com/

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Jan 2011 00:35:24 +1100

In message <[email-masked]>, Phil
> time for several decades.

Who is talking pure IPv6 yet?  I'm talking multi-homed.  Multiple
A's, A's and AAAA's or multiple AAAA's.  I don't care which.  The
path to one of those addresses is broken and the network is not
reporting it.  The question is how to make the application behave
well in such a enviorment and also not be a bad network citizen
when all the addresses are reachable.

> address there is no point in using IPv6 in parallel.

I will agree that when everything is working as expected it doesn't
matter if you use IPv4 or IPv6.  However we are not discussing this
senario.  We are discussing the senario where one of the paths is
broken and not returning error messages and you don't know it is
broken without trying it.

> through the clean connection.

That's one case but not the only one.

> using information that I would not want the application programmer to have

Does it really matter if it in the application or a library.  The
problem is still the same.

Mark

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 24 Jan 2011 13:02:40 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sabahattin Gucukoglu [[email-masked]]

An interesting concept.  It resembles ideas we've discussed but not implemented in our SIP stack:  For any given SIP destination, there may be many SRV records that give various redundant servers for that SIP domain.  Instead of obeying the SRV records as they are given, falling back from the one with highest priority to the next highest priority, etc., keep track of which addresses have recently been responding and which have not.  Those that have not been responding have their SRV priority artificially lowered for the purposes of the address-selection algorithm.  For addresses that need prompt response but are not accessed on a short cycle, a background process can send probes to keep the responsiveness information up to date.

An interesting aspect of this that might allow it to be generalized (at least in regard to applications that search for SRV records before A records) is that this could be implemented in a shim between the DNS lookup interface that the SIP stack uses and the real DNS:  The SRV records that the application sees can be modified to give the desired effect.  And for SIP domain lookups that do not have SRV records, SRV records can be synthesized to give the desired effect.

In particular, if a domain name has an A record and an AAAA record, instead of letting the application see (and choose between) these records directly:

domain.example.com    A    xx.yy.zz.ww
domain.example.com    AAAA    pppp::qqqq

the shim could construct:

_sip._tcp.domain.example.com    SRV    prio=1 weight=1 name=AAAA.domain.example.com port=5060
_sip._tcp.domain.example.com    SRV    prio=100 weight=1 name=A.domain.example.com port=5060

_sip._udp.domain.example.com    SRV    prio=1 weight=1 name=AAAA.domain.example.com port=5060
_sip._udp.domain.example.com    SRV    prio=100 weight=1 name=A.domain.example.com port=5060

A.domain.example.com    A    xx.yy.zz.ww
AAAA.domain.example.com    AAAA    pppp::qqqq

Thus, the shim has directed the SIP stack to try the IPv6 address first -- without any application change!

Dale

---

From: Danny Cohen <[email-masked]>
Date: Mon, 24 Jan 2011 18:04:00 -0800