Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter <[e-mail]>]

On 19/12/2014 04:07, Michael Richardson wrote:
> 
> Dave,
> my take is that applications, and the entire gai.conf/getaddrinfo() library
> is broken.  Applications can neither be updated nor be trusted to know enough
> about the system to be able to make a proper decision.
> 
> Somewhere, someone was working on a new connect(2) call that took FQDNs
> rather than sockaddr's, such that the kernel could take ownership of this
> problem. 

I suppose you are thinking of Name Based Sockets:
http://tools.ietf.org/html/draft-ubillos-name-based-sockets

It's dead, as far as I know.

> (Of course, actually solving the problem in a kernel is probably the
> wrong answer).
> What is necessary is some new infrastructure inside the box which becomes
> standardized (like sockets API was), with some daemon that thinks about the
> best source addresses is, and possibly gets involved with routing protocols.
> (I'm told that OSX has a sophisticated state machine that combines DHCP and
> 1x, and wifi... it sounds like it could be the start of such a thing)
> 
> I think that shim6 and mptcp are answers in this equation.
> 
> shim6 has, I'm told, deployment issues which make me very very sad.

Like, it cannot get through most firewalls.

> mptcp, I'm told, is likely to show up in Apple and Google products and
> infrastructure, and my idea (and many others) is that you don't always have
> to pick the perfect address for the SYN, just one that works, but rather one
> can add better addresses as one discovers them.

But bad luck if you need UDP.

Some form of intelligent probing does seem to be the answer,
but certainly that needs to be generic because we cannot expect
all apps developers to reinvent it. That's one reason we wrote
http://tools.ietf.org/html/draft-naderi-ipv6-probing recently.

   Brian