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

[V6ops]

Sent from my iThing

> On 23 Dec 2014, at 00:22, Dave Taht <dave.taht at gmail.com> wrote:
> 
> 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
> world.
> 
>>> 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?
> 
> https://github.com/namebasedsockets
> 
> 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
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> 
Another potential solution would be to follow current practice in router management. I know Homenet does not wish to change hosts, but it may result in the best solution.

We could:
- create one of more additional software loopback interfaces that are always up and used as source and destination for binding for all (legacy) apps.
- a software interface would have one single /64 prefix from each delegated Homenet prefix, reducing the number of potential sources and sinks.
- allow the end nodes to take part in HNCP as multi-homed stub devices that do not forward packets between hardware interfaces.
- use stub mode of Babel to learn outbound routes, and to originate a return route to the software loopback interface.

That might also solve the conundrum of how to handle roaming beween multiple routed wireless interfaces running on multiple Homenet routers, and should also greatly simplify the namespace, as the AAAA record of the device could be invariant and independent of the attachment point to the Homenet.