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

[Juliusz Chroboczek]

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

Yes, that's more or less what we're doing with hosts connected to
a AHCP/Babel mesh right now.  That's also what I suggested we do when
people were arguing in favour of TRILL (giggle) in order to have roaming.

That's certainly something I'm planning to experiment with when I have the
time and energy to replace AHCP with HNCP in our Babel mesh.  (Not before
February, I fear.)

> That might also solve the conundrum of how to handle roaming beween
> multiple routed wireless interfaces running on multiple Homenet routers,

Yes.

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

Almost -- any given IPv6 might go away when an ISP goes down.  So either
you include all of your ISPs in DNS (in which case you need probing) or
you renumber whenever you change addresses (in which case you need to wait
for DNS to propagate).

In short, it looks like something needs to give.  Unless I'm missing
something (in which case please do tell), multihoming requires one of the
following:

  - hosts perform e2e probing (shim6, MPTCP, or at the application layer); or
  - DNS becomes more dynamic and propagates faster than it does now; or
  - you use PI addresses, with the table bloat that this entails.

I'm not very keen on putting extra load on DNS, and PI seems out of the
question, so it looks like we're stuck with probing.  Or am I missing
something?

-- Juliusz