[Dnsmasq-discuss] [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

Dave Taht dave.taht at gmail.com
Tue Dec 23 00:22:20 GMT 2014

On Thu, Dec 18, 2014 at 2:06 PM, Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:
> On 19/12/2014 04:07, Michael Richardson wrote:

I am way behind on my mail (this thread) and will be away for the holidays.

Merry Christmas, everyone, and to all a happy new year!

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

I concur. Also other apis dating from the 70s, like sendmsg,getmsg,
and the new sendmmsg,getmmsg are a real pita to use, but increasingly
of interest to the webrtc, quic, and brave new post-tcp udp-only

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

It's not dead, it's resting!

The kernel work is not that out of date (3 years). Why did progress stop?


I for one would really like names to get more closely tied to numbers...

>> (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)

Openwrt had to go to very tightly integrated internal messaging API in
order to get all of the newly mandated dynamicsm in ipv6 sort of taken
care of, and that still isn't quite working right.

Yes, looking over OSX would be a good idea.

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

I would like to test it against modern 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.

Meh. The world is seemingly moving to userspace networking anyway.

> 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

Dave Täht


More information about the Dnsmasq-discuss mailing list