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

JINMEI Tatuya / 神明達哉 jinmei at isl.rdc.toshiba.co.jp
Sun Nov 4 23:31:44 PST 2007


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

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

(snip)

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

This is most likely because 7.0 now installs the address selection
policy table at boot time by default:

http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf.diff?r1=1.304&r2=1.305

Now if you have (which I guess is your network configuration)
A. a global IPv4 address and
B. a 6to4 IPv6 address,

and have a candidate destination addresses

C. a global IPv4 address (like 210.226.20.15)
D. a native global IPv6 address (like 2001:218:422:1::15)

then getaddrinfo() will prefer the combination of {A and C} because
these addresses have a matching scope while B and D don't.  If you
make sure the 6to4 source address always wins, you should modify the
policy table to:

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     1
      ::/96                 20     3
      ::ffff:0:0/96        100     4
(i.e., change the label of 2002::/16).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp


More information about the freebsd-stable mailing list