thr3ads.net - freebsd stable - [FreeBSD 7.0-BETA1] strange behavior in hostname resolving order [Nov 2007]

If this information is useful, please help other people find it:
Share via:

Hajimu UMEMOTO

2007-Nov-02 12:13 UTC

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

Hi,
>>>>> On Sat, 03 Nov 2007 00:05:07 +0900
>>>>> Byung-Hee HWANG <bh@izb.knu.ac.kr> said:
bh> To Whom It May Concern: (Cc'ed bind-users@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@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@viola.izb.knu.ac.kr:/usr/obj/usr/src/sys/GENERIC  i386

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

bh> bh@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@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@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@setaria:~> uname -srm
bh>         FreeBSD 6.2-RELEASE-p8 i386
bh>         bh@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@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@viola:~> uname -srm
bh>         FreeBSD 7.0-BETA1 i386
bh>         bh@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@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@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

Byung-Hee HWANG

2007-Nov-04 13:04 UTC

head link

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

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

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.

Here is my shot using 6to4:

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

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

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

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

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

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:

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

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

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

Byung-Hee

-- 
"After super, can you drive me and the kids to New York in your car?"
"That's what I came for."
		-- Kay Adams and Tom Hagen, "Chapter 32", page 443

JINMEI Tatuya / 神明達哉

2007-Nov-04 23:31 UTC

head link

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

At Sat, 03 Nov 2007 00:05:07 +0900,
Byung-Hee HWANG <bh@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@isl.rdc.toshiba.co.jp

freebsd stable - Nov 2007 - [FreeBSD 7.0-BETA1] strange behavior in hostname resolving order

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

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

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