NetBSD Problem Report #44943

From www@NetBSD.org  Sat May  7 13:48:51 2011
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 3BC6D63BBF6
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  7 May 2011 13:48:51 +0000 (UTC)
Message-Id: <20110507134850.62FF463BBC7@www.NetBSD.org>
Date: Sat,  7 May 2011 13:48:50 +0000 (UTC)
From: pettai@nordu.net
Reply-To: pettai@nordu.net
To: gnats-bugs@NetBSD.org
Subject: 2002::/16 (6to4) addresses are preferred over native IPv6 transport
X-Send-Pr-Version: www-1.0

>Number:         44943
>Category:       misc
>Synopsis:       2002::/16 (6to4) addresses are preferred over native IPv6 transport
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat May 07 13:50:00 +0000 2011
>Last-Modified:  Sat May 14 17:30:02 +0000 2011
>Originator:     Fredrik Pettai
>Release:        NetBSD 5.99.51
>Organization:
NORDUnet A/S
>Environment:
NetBSD wilma 5.99.51 NetBSD 5.99.51 (GENERIC) #0: Wed May  4 15:19:35 CEST 2011  root@wilma:/usr/obj/sys/arch/i386/compile/GENERIC i386
>Description:
NetBSD seems to pref 2002::/16 6to4 addresses (which is a tunnel mechanism) over native IPv6 transport if both are given for a remote host. This is broken behavior now days, then native IPv6 is deployed on a much wider scale than before. (The 6to4 2002::/16 RFC is under discussion to become a historic document in the IETF)


>How-To-Repeat:
Fetch a package from a server that has a public DNS name containing a 6to4 address, a IPv6 native address and a IPv4 address. NetBSD will try to download the source file in the order just described.  
>Fix:

>Release-Note:

>Audit-Trail:
From: Fredrik Pettai <pettai@nordu.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native IPv6 transport
Date: Sat, 7 May 2011 22:11:47 +0200

 >> Category:       kern
 >> Responsible:    kern-bug-people
 >> Synopsis:       2002::/16 (6to4) addresses are preferred over native =
 IPv6 transport
 >> Arrival-Date:   Sat May 07 13:50:00 +0000 2011

 A NetBSD 5.99.51 example with ftp:

 -bash-4.2$ ftp 6to4test.hactrn.net
 Trying 2002:931c:13::1:21 ...
 ftp: Can't connect to `2002:931c:13::1:21': Connection refused
 Trying 2001:418:1::19:21 ...
 ftp: Can't connect to `2001:418:1::19:21': Connection refused
 Trying 147.28.0.19:21 ...
 ftp: Can't connect to `147.28.0.19:21': Connection refused
 ftp: Can't connect to `6to4test.hactrn.net:ftp'
 ftp>=20

 A better default would be to avoid trying to connect to 2002:: addresses =
 if native IPv6 (and IPv4) is available, and only use 2002:: addresses as =
 last resort...=

Responsible-Changed-From-To: kern-bug-people->misc-bug-people
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Sun, 08 May 2011 08:12:51 +0000
Responsible-Changed-Why:
Clearly not a kernel bug


From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native IPv6 transport
Date: Sun, 8 May 2011 10:11:36 +0200

 On Sat, May 07, 2011 at 01:50:00PM +0000, pettai@nordu.net wrote:

 > NetBSD seems to pref 2002::/16 6to4 addresses (which is a tunnel
 > mechanism) over native IPv6 transport if both are given for a remote
 > host. This is broken behavior now days, then native IPv6 is deployed on
 > a much wider scale than before. (The 6to4 2002::/16 RFC is under
 > discussion to become a historic document in the IETF)

 This sounds like a misunderstanding. NetBSD itself does not prefer any
 address over any other. Applications typically just try all results
 returned by the resolver in the (more or less) random order they arrive.

 So this depends mostly on the nameserver answering your question.

 You could check the "sortlist" option in /etc/resolv.conf - but I don't know
 if/how that works for v6 addresses.

 Besides, why do you realy care?

 Martin

From: Fredrik Pettai <pettai@nordu.net>
To: gnats-bugs@NetBSD.org
Cc: misc-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native IPv6 transport
Date: Sun, 8 May 2011 13:37:51 +0200

 On May 8, 2011, at 10:15 , Martin Husemann wrote:
 > This sounds like a misunderstanding.

 Sorry for the confusion. So, Mac OS X (before 10.6.6 AFAIK) had this =
 broken behavior, and my random test results gave me what looked like the =
 same behavior on the NetBSD machines I tested on.

 > NetBSD itself does not prefer any
 > address over any other. Applications typically just try all results
 > returned by the resolver in the (more or less) random order they =
 arrive.

 But IPv6 is AFAIK always preferred over IPv4 on NetBSD, no?

 > So this depends mostly on the nameserver answering your question.
 >=20
 > You could check the "sortlist" option in /etc/resolv.conf - but I =
 don't know
 > if/how that works for v6 addresses.
 >=20
 > Besides, why do you realy care?

 Then World IPv6 Day (http://isoc.org/wp/worldipv6day/) comes , content =
 providers will measure the brokenness of IPv6 clients. Even if NetBSD is =
 a small player then it comes to clients, it's better if it would do the =
 correct thing and ignore/de-pref the 6to4 addresses and always prefer =
 native IPv6 over anything else (possibly with the only exception of =
 non-RFC1918 IPv4 addresses.)

 So maybe we should close this case?
 I could open a new "feature request" instead...=

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native
 IPv6 transport]
Date: Sat, 14 May 2011 17:25:43 +0000

 (not sent to gnats)

    ------

 From: George Michaelson <ggm@pobox.com>
 To: netbsd-bugs@netbsd.org
 Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native
 	IPv6 transport
 Date: Mon, 9 May 2011 00:31:07 +0000 (UTC)

 Ahem.

 I believe there is an RFC, or draft RFC expectation that tunnelled IP is 
 de-preferenced to native when both exist.

 So, NetBSD may not have that logic in kernel, but the RFCs specify that 
 if a longest-match rule is used, with weightings, you should be able to 
 avoid using 2002::/16 source IPs except when you have a working binding, 
 and are sending packets to a 2002::/16 destination address.

 I don't have the docs to hand, but skimming discussion on IETF v6 working 
 groups leads me to believe there is a pretty clear understanding you 
 shouldn't preference a 6to4 route if you have native V6.

 Is that kind of route preference ordering not something we would want in 
 NetBSD? Is there any way to weight preference in routes other than 
 longest match? If its longest match, then the order you apply route 
 statements might influence route preference, but there is this niggle in 
 my mind about INADDR_ANY and what source IP selection you wind up with..

 (reading http://www.ietf.org/rfc/rfc5014.txt makes me think Erik Nordmark 
 coded some of this in the socket() preferences section)

 -G

>Unformatted:

Home	PR Database Search