From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: arisawa <arisawa@ar.aichi-u.ac.jp>
In-Reply-To: <03a4bcd9e6053108cc41cff5a379fc0f@felloff.net>
Date: Wed, 15 Jul 2015 13:41:38 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F3FE931-6DF5-4D66-9D4E-E6F0537F1A8B@ar.aichi-u.ac.jp>
References: <03a4bcd9e6053108cc41cff5a379fc0f@felloff.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] ipv6 and ndb/csquery
Topicbox-Message-UUID: 6037480c-ead9-11e9-9d60-3106f5b1d025

Thanks cinap,

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

Kenji Arisawa


> 2015/07/12 0:37=E3=80=81cinap_lenrek@felloff.net =E3=81=AE=E3=83=A1=E3=83=
=BC=E3=83=AB=EF=BC=9A
>=20
> 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=3D or ipv6=3D 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.
>=20
> 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).
>=20
> when ndb/cs looks for an address in the network database, it only =
looks
> for the ip=3D attribute and ignores ipv6=3D attributes (these are for =
dns only).
>=20
> 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=3D attribute in ndb as network database lookups will
> ignore the ipv6=3D stuff.
>=20
> when you have both ipv4 and ipv6 connectivity, you can just use
> ip=3D attribute for both v4 and v6 addresses, then network database
> lookup will yield both.=20
>=20
> 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).
>=20
> the results from network database are not randomized (but can be
> reordered) by ndb/cs:
>=20
> sys=3Dtesta ip=3D89.186.156.12=20
> 	ip=3D2001:470:1f0a:a61::2
>=20
> sys=3Dtestb ip=3D2001:470:1f0a:a61::2
> 	ip=3D89.186.156.12=20
>=20
>> 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!*
>=20
> 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.
>=20
> 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?
>=20
> --
> cinap
>=20