[FreeBSD 7.0-BETA1] strange behavior in hostname resolving order

[Hajimu UMEMOTO]

Hi,

>>>>> On Sat, 03 Nov 2007 00:05:07 +0900
>>>>> Byung-Hee HWANG <bh at izb.knu.ac.kr> said:

bh> To Whom It May Concern: (Cc'ed bind-users at isc.org)

bh> Usually i prefer 6to4(stf(4)) to 6over4(gif(4)) because some 
bh> tunnel providers like to limit bandwidth too musch. So until my 
bh> upstream ISP give me native ipv6 addresses (it's take long time maybe), 
bh> i'm going to use 6to4 instead of 6over4 continuous.

bh> Here is my shot using 6to4:

bh> bh at viola:~> uname -a
bh> FreeBSD viola.izb.knu.ac.kr 7.0-BETA1 FreeBSD 7.0-BETA1 #0: 
bh> Fri Nov  2 12:13:10 KST 2007     
bh> root at viola.izb.knu.ac.kr:/usr/obj/usr/src/sys/GENERIC  i386

bh> bh at viola:~> ifconfig rl0 | grep 2002
bh> inet6 2002:9be6:9d5d:2:20b:6aff:fe56:969f prefixlen 64 autoconf 

bh> bh at viola:~> ping6 -c 5 mx.jp.freebsd.org.
bh> PING6(56=40+8+8 bytes) 
bh> 2002:9be6:9d5d:2:20b:6aff:fe56:969f --> 2001:218:422:1::15
bh> 16 bytes from 2001:218:422:1::15, icmp_seq=0 hlim=49 time=225.297 ms
bh> 16 bytes from 2001:218:422:1::15, icmp_seq=1 hlim=49 time=224.591 ms
bh> 16 bytes from 2001:218:422:1::15, icmp_seq=2 hlim=49 time=237.175 ms
bh> 16 bytes from 2001:218:422:1::15, icmp_seq=3 hlim=49 time=230.540 ms
bh> 16 bytes from 2001:218:422:1::15, icmp_seq=4 hlim=49 time=224.681 ms

bh> --- mx.jp.freebsd.org ping6 statistics ---
bh> 5 packets transmitted, 5 packets received, 0.0% packet loss
bh> round-trip min/avg/max/std-dev = 224.591/228.457/237.175/4.889 ms

bh> bh at viola:~> traceroute6 mx.jp.freebsd.org.
bh> traceroute6 to mx.jp.freebsd.org (2001:218:422:1::15) from 
bh> 2002:9be6:9d5d:2:20b:6aff:fe56:969f, 64 hops max, 12 byte packets
bh> 1  2002:9be6:9d5d:2:250:4dff:fe00:5df3  1.541 ms  0.949 ms  1.154 ms
bh> [......]
bh> 23  v6.imgsrc.co.jp  264.635 ms  226.812 ms  232.207 ms
bh> 24  castle.jp.FreeBSD.org  427.683 ms  219.659 ms  222.862 ms
bh> bh at viola:~> 

bh> And from now on, i would give you one question. Why is 7.0-BETA1 
bh> different from another -RELEASE in hostname resolving order? AFAIK, at 
bh> least on 6.2-RELEASE, the order is first IPv6 and then IPv4. However, 
bh> 7.0-BETA1 try to lookup in first IPv4 than IPv6. Here is the evidence:

bh>         bh at setaria:~> uname -srm
bh>         FreeBSD 6.2-RELEASE-p8 i386
bh>         bh at setaria:~> telnet mx.jp.freebsd.org 25
bh>         Trying 2001:218:422:1::15...
bh>         Connected to mx.jp.freebsd.org.
bh>         Escape character is '^]'.
bh>         [......]
bh>         bh at setaria:~> ssh -v mx.jp.freebsd.org.
bh>         debug1: Connecting to mx.jp.freebsd.org. [2001:218:422:1::15]
bh>         ^C
bh>         
bh> And

bh>         bh at viola:~> uname -srm
bh>         FreeBSD 7.0-BETA1 i386
bh>         bh at viola:~> telnet mx.jp.freebsd.org 25
bh>         Trying 210.226.20.15...
bh>         Connected to mx.jp.freebsd.org.
bh>         Escape character is '^]'.
bh>         [......]
bh>         bh at viola:~> ssh -v mx.jp.freebsd.org.
bh>         debug1: Connecting to mx.jp.freebsd.org. [210.226.20.15]
bh>         ^C

bh> What happended? Is there anyone to dislike IPv6 in src committers?
bh> Please let me know the correct answer to this puzzle ;;

The Default Address Selection is turned on by default after
6.2-RELEASE was out.  According to RFC 3484, the default policy is as
follows:

Prefix                          Prec Label
::1/128                           50     0
::/0                              40     1
2002::/16                         30     2
::/96                             20     3
::ffff:0.0.0.0/96                 10     4

It means that communicating with native IP address is preferred over
6to4 address when source address and destination adddress are not 6to4
address.

If you want not to treat 6to4 address as special, you can omit the
line of 2002::/16 by putting the following lines into your
/etc/ip6addrctl.conf:

::1/128				  50	 0
::/0				  40	 1
::/96				  20	 3
::ffff:0.0.0.0/96		  10	 4

Then, run `/etc/rc.d/ip6addrctl restart'.

Please refer the ip6addrctl(8) manpage and RFC 3484 for detail.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/