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

Wed Dec 17 14:16:16 UTC 2014

I have been wrestling with prefix coloring, where choosing a "best"
prefix would be of use in (for example) reducing the problems induced
by happy eyeballs when more than one ipv6 prefix is present and
several other scenarios.

There are many parts to this - one is in addressing, the other in DNS,
and this is not dnsmasq specific but kind of general.

* gai.conf

Does anyone have a "better" gai.conf file or getaddrinfo implemention
"out there?

This is the closest I've found to what I sort of think I want.

http://biplane.com.au/blog/?p=122

* hints for addressing?

I will start with the complex scenario - I have three primary
connections to the internet (one is hardline, one is 5 hops away on a
source specific gateway to elsewhere, the last LTE), with slaac, dhcp,
and privacy addresses assigned for each, a ula for internal addressing
(with possibly slaac, dhcp, and privacy addresses), and a vpn (also on
a ula). What the heck, let's throw in a hip address, also. And... why
not? A legacy ipv6 tunnel from hurricane, a 2002:address for 6to4....

The ideal scenario is where the host app picks the "best" address for
each connection type, and I am a little vague on what actually
happens. What my backbrain (but not RFC 3484 - is there a later rfc
for what gai.conf should do?) says should happen is that the host
should pick the shortest prefix match between source and destination.
Well, it turns out this breaks down - my tunnel is a 2001::address,
and my native ipv6 connection is a 2600::address, and my destination
(being on the "legacy" internet), is a 2001::address, so things tend
to pick the tunnel rather than the native address. A differentiation
between these is that I have a different MTU for each. Another is how
these addresses are acquired - the main address comes from dhcpv6,
tunnel from a he speciifc script, the source specific gateway comes
from hnet, the lte address is pppoe....

And worse, the "best" address is dynamic and changes every week, and
on reboots, (this just happened to me and I went nuts flushing old
ipv6 addrs everywhere, since I lack hnetd) and caching it or using it
internally is a bad idea when a static ULA or more static tunnel addr
is available,

The LTE connection costs money to use, and is definately "secondary"
in intent, and I can see supplying that via ra as secondary. I can
also see treating almost all the others as "secondary" also, but it
probably would be nice to have the nearly equal cost hnetd supplied
prefix have a chance at being used occasionally.

and, sigh, the ip route command has no ability currently to set
secondary on an address.

* In terms of DNS

spitting all these into a single DNS record strikes me as insane.
However, having more than one visible address per dns entry strikes me
as desirable. Certainly a dhcp supplied address should end up in dns,
and dnsmasq also has a mechanism to put slaac assigned address into
dns.

putting the ULA in the local dns is actually desirable when you have split dns.

Perhaps having a subdomain per address type? dave.lte.home.lan
dave.slaac.home.lan dave.dhcp.home.lan?

I am not offering any solutions here, just sharing a headache. There
are some other basic problems like setting a default src address on a
default route in this scenario that are giving me headaches in the
source specific universe...

* In terms of being a host and selecting the

for example, I think linux presently choses the last assigned static
address as it's default source, and that can be overridden with stuff
like:

ip -6 route add default via 2001:db8::1 dev ethic src 2001:db8::abcd

but it is not done today, and is not always the correct thing. I add a
vpn address last in my case.

What I see happening now is distributing source specific routes to
hosts doesn't work, if you merely have

default from 2001:558:6045:bd:8dcc:5e18:dd54:b31c via
fe80::6eb0:ceff:fe0b:e2ab dev eth0  proto babel  metric 1024
default from 2601:9:3640::/60 via fe80::6eb0:ceff:fe0b:e2ab dev eth0
proto babel  metric 1024

and no broader default, the right thing doesn't happen for source
address selection on the host. You end up with no ipv6 connectivity at
all until you add something like this

default via fe80::6eb0:ceff:fe0b:e2ab dev eth0  metric 1024

or this

default from :: via fe80::4a1:51ff:fea3:1304 dev eth0.2  proto babel
metric 1024 (different machine)

to get something that works.

On Mon, Dec 1, 2014 at 2:17 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> On 01/12/14 18:49, Michael Gorbach wrote:
>> On Nov 30, 2014, at 11:17 AM, Simon Kelley <simon at thekelleys.org.uk>
>> wrote:
>>>
>>> On 29/11/14 19:18, Michael Gorbach wrote:
>>>> Hi All,
>>>>
>>>> I've got a question and potential enhancement request. It looks
>>>> like right now, the (very useful) interface-name feature pulls
>>>> all (global) addresses from the interface. One of my machines
>>>> uses IPv6 privacy extensions (known in Linux as use_tempaddr),
>>>> which means that in addition to link-local and permanent global
>>>> addresses, it has a rotating cast of ~ 5 temporary addresses. I
>>>> suggest that dnsmasq should detect those temporary addresses and
>>>> not return them for queries that would otherwise hit
>>>> interface-name. Returning them as it does now means > 5 AAAA
>>>> records for a single name, which causes repeated confusion due to
>>>> things like SSH warning about an unknown host because it has
>>>> suddenly picked a previously-unknown temporary address to connect
>>>> to. Thoughts?
>>>>
>>>
>>> Sounds like a sensible suggestion. This facility was added before I
>>> was really familiar with IPv6 and all its extra complications. Most
>>> of those 5 temporary addresses will be "deprecated" ie hanging
>>> around for the use of existing connections, but not used for new
>>> ones. They definitely shouldn't appear, but I'm pretty convinced,
>>> unless anyone can come up with a good reason why not, that all
>>> privacy addresses should be elided, without exception.
>>>
>>> I wonder, though, if that's only true for forward (ie AAAA)
>>> lookups. Should a reverse lookup on an old privacy address still
>>> yield the name of the host it belongs to?
>>
>> Thanks, Simon. I’d agree that all the temporary addresses should be
>> skipped in forward resolution. In terms of reverse, I’d say there’s a
>> high amount of value in having at least the current temporary address
>> resolve to the correct host name. Temporary addresses are often
>> preferred for outbound connections, so if we don’t have reverse
>> resolution here then for example SSH is going to complain that it
>> can’t check reverse DNS. There’s probably some value in reverse
>> resolution for deprecated temporary addresses, for example if you
>> wanted to track down some client in your system logs from several
>> days ago, but it’s significantly lower. If that’s a large amount of
>> work, to me it’s something that wouldn’t be top-priority.
>
> Since all the addresses - permanent, current privacy, and deprecated
> privacy - are there now, it's just a question of filtering them, with a
> bit of extra complication to do it differently for forward and reverse
> queries. I think I've convinced myself that this won't bite anyone if we
> make it a simple change-of-behaviour, rather than some new configuration
> option to request this behaviour. I'd feel more confident if others had
> a think about it and convinced themselves too.
>
>
> Cheers,
>
> Simon.
>
>>
>> Yours, ~ M.
>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>>
>>> _______________________________________________ Dnsmasq-discuss
>>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
>>> <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>> <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks