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. (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. 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. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
pgpbBqiEE5wOa.pgp
Description: PGP signature
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
