[9fans] ipv6 and ndb/csquery

[9fans] ipv6 and ndb/csquery

[arisawa]

Hello,

I am currently trying ipv6 of Plan9.

with a line
	ip=192.168.0.3 ipv6=fe80::6a05:caff:fe00:fc34 ether=6805ca00fc34	sys=maia
in /lib/ndb/local, and executing
	ipv6on
I tried dnsquery and csquery.

ii seems dnsquery is OK

term% ndb/dnsquery
> maia
maia.local ip	192.168.0.3
> maia ipv6
maia.local ipv6	fe80::6a05:caff:fe00:fc34
> www.google.com
www.google.com ip	173.194.117.212
www.google.com ip	173.194.117.211
www.google.com ip	173.194.117.210
www.google.com ip	173.194.117.208
www.google.com ip	173.194.117.209
> www.google.com ipv6
www.google.com ipv6	2404:6800:4004:80c::1014
>

however I don’t understand the behavior of csquery

term% ndb/csquery
> tcp!maia!*
/net/tcp/clone 192.168.0.3!*
> tcp!www.google.com!*
/net/tcp/clone 173.194.117.210!*
/net/tcp/clone 173.194.117.208!*
/net/tcp/clone 173.194.117.209!*
/net/tcp/clone 173.194.117.211!*
/net/tcp/clone 173.194.117.212!*
/net/tcp/clone 2404:6800:4004:80c::1014!*
>

why csquery does not show ipv6 address of maia?

Kenji Arisawa

Re: [9fans] ipv6 and ndb/csquery

[cinap_lenrek]

i dont know for sure but could it be that cs resolves
these local domains thru ndb? and then ignores your
ipv6= attibures in ndb?

i use ip= attribute in my ndb for both v4 and v6 addresses
and that works fine.

--
cinap

Re: [9fans] ipv6 and ndb/csquery

[arisawa]

Thanks.
It seems you are right.

I have been playing with ipv6 and yet i don’t understand something.
What is the rule to select an IP if we allow multiple IPs for a dom?
Maybe case by case. But how to select ipv6 in case of telnet?

> 2015/07/07 2:01、cinap_lenrek@felloff.net のメール：
> 
> i dont know for sure but could it be that cs resolves
> these local domains thru ndb? and then ignores your
> ipv6= attibures in ndb?
> 
> i use ip= attribute in my ndb for both v4 and v6 addresses
> and that works fine.
> 
> --
> cinap
> 

Re: [9fans] ipv6 and ndb/csquery

[cinap_lenrek]

when you query /net/dns, it differentiates between ip (A) and ipv6
(AAAA) records. so querying for "ip" only yields ipv4 addresses and
querying for "ipv6" yields ipv6 addresses only. it shouldnt matter if
you use ip= or ipv6= attribute in ndb for this, as ndb/dns is smart
enogth to check the value of the attribute and figure out if its for
and A or AAAA record.

now ndb/cs is concerned about finding an addresses that is reachable
from your system. i think that is why it reorders the results
based on local ip interfaces. in any case, ndb/cs will query dns
for both ipv4 and ipv6 addresses unless you give it (v4 only flag -4).

when ndb/cs looks for an address in the network database, it only looks
for the ip= attribute and ignores ipv6= attributes (these are for dns only).

so if you have no ipv6 connectivity on the lan, but you want to put
ipv6 AAAA records in your dns server (to serve to the outside world?),
use the ipv6= attribute in ndb as network database lookups will
ignore the ipv6= stuff.

when you have both ipv4 and ipv6 connectivity, you can just use
ip= attribute for both v4 and v6 addresses, then network database
lookup will yield both.

when a domain has multiple ip addresses, dns will randomize the
list of results (for a specific record type). ndb/cs queries dns
for v4 addresses first and v6 addresses last, the (randomized)
v4 addresses appear before the (randomized) v6 addresses
(unless cs did reorder the list as it found the v6 address to be
reachable directly the by a local network interface).

the results from network database are not randomized (but can be
reordered) by ndb/cs:

sys=testa ip=89.186.156.12
	ip=2001:470:1f0a:a61::2

sys=testb ip=2001:470:1f0a:a61::2
	ip=89.186.156.12

> net!testa!*
/net.alt/il/clone 89.186.156.12!*!fasttimeout
/net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout
/net.alt/tcp/clone 89.186.156.12!*
/net.alt/tcp/clone 2001:470:1f0a:a61::2!*
/net.alt/il/clone 89.186.156.12!*
/net.alt/il/clone 2001:470:1f0a:a61::2!*
> net!testb!*
/net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout
/net.alt/il/clone 89.186.156.12!*!fasttimeout
/net.alt/tcp/clone 2001:470:1f0a:a61::2!*
/net.alt/tcp/clone 89.186.156.12!*
/net.alt/il/clone 2001:470:1f0a:a61::2!*
/net.alt/il/clone 89.186.156.12!*

dial() processes the list from cs in sequential order, unless
you use geoffs parallel dial implementation which connects to
some bounded number of addresses in parallel.

still the ordering of what cs returns is in most prefered first,
and it is up to cs to define that order. like it *could* decide to
always put ipv6 addresses first, but i think this was not done because
in the labs the v6 network was less reliable than the v4 network?

--
cinap

Re: [9fans] ipv6 and ndb/csquery

[arisawa]

Thanks cinap,

your detailed explanation will be helpful to me and all others.

Kenji Arisawa


> 2015/07/12 0:37、cinap_lenrek@felloff.net のメール：
> 
> when you query /net/dns, it differentiates between ip (A) and ipv6
> (AAAA) records. so querying for "ip" only yields ipv4 addresses and
> querying for "ipv6" yields ipv6 addresses only. it shouldnt matter if
> you use ip= or ipv6= attribute in ndb for this, as ndb/dns is smart
> enogth to check the value of the attribute and figure out if its for
> and A or AAAA record.
> 
> now ndb/cs is concerned about finding an addresses that is reachable
> from your system. i think that is why it reorders the results
> based on local ip interfaces. in any case, ndb/cs will query dns
> for both ipv4 and ipv6 addresses unless you give it (v4 only flag -4).
> 
> when ndb/cs looks for an address in the network database, it only looks
> for the ip= attribute and ignores ipv6= attributes (these are for dns only).
> 
> so if you have no ipv6 connectivity on the lan, but you want to put
> ipv6 AAAA records in your dns server (to serve to the outside world?),
> use the ipv6= attribute in ndb as network database lookups will
> ignore the ipv6= stuff.
> 
> when you have both ipv4 and ipv6 connectivity, you can just use
> ip= attribute for both v4 and v6 addresses, then network database
> lookup will yield both. 
> 
> when a domain has multiple ip addresses, dns will randomize the
> list of results (for a specific record type). ndb/cs queries dns
> for v4 addresses first and v6 addresses last, the (randomized)
> v4 addresses appear before the (randomized) v6 addresses
> (unless cs did reorder the list as it found the v6 address to be
> reachable directly the by a local network interface).
> 
> the results from network database are not randomized (but can be
> reordered) by ndb/cs:
> 
> sys=testa ip=89.186.156.12 
> 	ip=2001:470:1f0a:a61::2
> 
> sys=testb ip=2001:470:1f0a:a61::2
> 	ip=89.186.156.12 
> 
>> net!testa!*
> /net.alt/il/clone 89.186.156.12!*!fasttimeout
> /net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout
> /net.alt/tcp/clone 89.186.156.12!*
> /net.alt/tcp/clone 2001:470:1f0a:a61::2!*
> /net.alt/il/clone 89.186.156.12!*
> /net.alt/il/clone 2001:470:1f0a:a61::2!*
>> net!testb!*
> /net.alt/il/clone 2001:470:1f0a:a61::2!*!fasttimeout
> /net.alt/il/clone 89.186.156.12!*!fasttimeout
> /net.alt/tcp/clone 2001:470:1f0a:a61::2!*
> /net.alt/tcp/clone 89.186.156.12!*
> /net.alt/il/clone 2001:470:1f0a:a61::2!*
> /net.alt/il/clone 89.186.156.12!*
> 
> dial() processes the list from cs in sequential order, unless
> you use geoffs parallel dial implementation which connects to
> some bounded number of addresses in parallel.
> 
> still the ordering of what cs returns is in most prefered first,
> and it is up to cs to define that order. like it *could* decide to
> always put ipv6 addresses first, but i think this was not done because
> in the labs the v6 network was less reliable than the v4 network?
> 
> --
> cinap
>