Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

[Philip Homburg <[e-mail]>]

In your letter dated Mon, 02 Jun 2014 09:11:40 +1000 you wrote:
>Every piece of client software should already support multi-homing.
>This is about supporting it *better* so there isn't the big delay
>when switching to the second address because the link at the other
>end is down.  The stack should be choosing source addresses which
>have working outbound paths.  Selecting destination addresses is
>up to the application.
>
>This is about making the error cases work better which quite frankly
>should have been done years ago for IPv4.  The only ones that don't
>benefit from this is GLB developers.

I'd like to see IPv6 deployed sooner rather than later. And in my experience,
everywhere where IPv6 is different from IPv4 it causes problems and extra
delays.

So if you say 'every piece of client software should already support
multi-homing' then that is simply not true in the IPv4 world. At least while
giving reasonable performance.

If all IPv4 software supported multi-homing properly, then there was no need 
for happy eyeballs. And many of the features that discussed in the context
of happy eyeballs were not implemented in a large scale before.

As a result, there also no standard API for doing HE. The Berkeley socket
interface is still the same because in practice, eveybody is not doing
multi-homed. 

Doing HE with minimal overhead is very tricky. It is very easy for most
client systems to take a full matrix of source and destination addresses and
connect to all of them. I'm quite sure that most operators of server systems
would completely hate that approach.

Simply put, the more things we come up with that have to be done before someone
can deplay IPv6, the longer it will take.