NetBSD Problem Report #22761

Received: (qmail 16252 invoked by uid 605); 12 Sep 2003 17:33:30 -0000
Message-Id: <200309121732.h8CHWWtL016506@server.duh.org>
Date: Fri, 12 Sep 2003 13:32:32 -0400 (EDT)
From: tv@duh.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: tv@duh.org
To: gnats-bugs@gnats.netbsd.org
Subject: There is no way to choose IPv4 preferably to IPv6
X-Send-Pr-Version: 3.95

>Number:         22761
>Category:       bin
>Synopsis:       There is no way to choose IPv4 preferably to IPv6
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pgoyette
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 12 17:34:00 +0000 2003
>Closed-Date:    Mon Jun 27 02:17:43 +0000 2016
>Last-Modified:  Mon Jun 27 02:20:00 +0000 2016
>Originator:     Todd Vierling
>Release:        NetBSD 1.6.1_STABLE
>Organization:
	DUH.ORG:  Pointing out the obvious since 1994.
>Environment:
System: NetBSD server.duh.org 1.6.1_STABLE NetBSD 1.6.1_STABLE (SERVER) #1: Fri Sep 12 11:28:14 EDT 2003 tv@server.duh.org:/export/SRC/duh/netbsd-kernels/SERVER i386
Architecture: i386
Machine: i386
>Description:

Many times I've been bitten by this, and I'm tired of typing "ftp -4"
all the time just because I'm trying to contribute to the deployment
of IPv6 but don't have the tunnel bandwidth to do major-throughput
operations over v6 on a daily basis.

My configuration is a 6to4 tunnel, which has pretty high RTT thanks to the
fact that very few providers advertise an exit point to 2002::/16 from the
6bone.  (Unfortunately, this situation is something I cannot fix.)

>How-To-Repeat:

Hook up a 6to4 tunnel, or any other relatively high latency IPv6-over-IPv4
tunnel.  Go to any site that has both IPv6 and IPv4 addresses.  See that
the IPv6 address family and address is always picked first, and that there
is no way to get around this without telling the network tool to use IPv4
explicitly.

>Fix:

NFC.  I'd presume that the first place this should be configurable is in
getaddrinfo(3).  It always returns IPv6 first, so perhaps it can be made
to return IPv4 first.  This might solve this whole issue altogether for
most tools that simply depend on what getaddrinfo(3) returns.

Other programs that do explicit IPv6 and IPv4 lookups separately would
need access to the same config option, likely via a function call, and
make use of it.
>Release-Note:
>Audit-Trail:

From: fredb@immanent.net (Frederick Bruckman)
To: tv@duh.org
Cc: fredb@netbsd.org, itojun@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: bin/22761: There is no way to choose IPv4 preferably to IPv6
Date: Sat, 13 Sep 2003 08:52:14 -0500 (CDT)

 In article <200309121732.h8CHWWtL016506@server.duh.org>,
 	tv@duh.org writes:
 > 
 >>Synopsis:       There is no way to choose IPv4 preferably to IPv6

 > NFC.  I'd presume that the first place this should be configurable is in
 > getaddrinfo(3).  It always returns IPv6 first, so perhaps it can be made
 > to return IPv4 first.  This might solve this whole issue altogether for
 > most tools that simply depend on what getaddrinfo(3) returns.

 RFC 3484 has something to say about this. To be compliant, we'll
 ultimately need some host-wide configuration file for this. When
 I last asked about it, itojun said that KAME has it, but there
 were problems merging the code into NetBSD:

     http://mail-index.netbsd.org/tech-net/2003/07/14/0000.html
     http://mail-index.netbsd.org/tech-net/2003/07/13/0002.html

 Frederick

From: itojun@itojun.org (Jun-ichiro itojun Hagino)
To: fredb@immanent.net
Cc: tv@duh.org, fredb@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: bin/22761: There is no way to choose IPv4 preferably to IPv6
Date: Sun, 14 Sep 2003 07:22:56 +0900 (JST)

 > In article <200309121732.h8CHWWtL016506@server.duh.org>,
 > 	tv@duh.org writes:
 > > 
 > >>Synopsis:       There is no way to choose IPv4 preferably to IPv6
 >  
 > > NFC.  I'd presume that the first place this should be configurable is in
 > > getaddrinfo(3).  It always returns IPv6 first, so perhaps it can be made
 > > to return IPv4 first.  This might solve this whole issue altogether for
 > > most tools that simply depend on what getaddrinfo(3) returns.
 > 
 > RFC 3484 has something to say about this. To be compliant, we'll
 > ultimately need some host-wide configuration file for this. When
 > I last asked about it, itojun said that KAME has it, but there
 > were problems merging the code into NetBSD:
 > 
 >     http://mail-index.netbsd.org/tech-net/2003/07/14/0000.html
 >     http://mail-index.netbsd.org/tech-net/2003/07/13/0002.html

 	basically it needs some cleanup.  i'll try to work on it sooner
 	(now my work-stack is full :-).

 itojun
From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: RE: bin/22761
Date: Mon, 27 Jun 2016 09:07:45 +0800 (PHT)

 With the introduction of network address selection policy (configured 
 using /etc/ip6addrctl.conf file), is this bug still an issue?  Or does 
 the address-selection-policy stuff effectively close the bug?


 +------------------+--------------------------+------------------------+
 | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
 | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
 | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
 +------------------+--------------------------+------------------------+

Responsible-Changed-From-To: bin-bug-people->pgoyette
Responsible-Changed-By: pgoyette@NetBSD.org
Responsible-Changed-When: Mon, 27 Jun 2016 01:37:37 +0000
Responsible-Changed-Why:
I can handle it, I think.


State-Changed-From-To: open->analyzed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Mon, 27 Jun 2016 01:37:37 +0000
State-Changed-Why:
With introduction of ipv6 address selection policy, this PR should be
effectively fixed.  Will confirm.


State-Changed-From-To: analyzed->feedback
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Mon, 27 Jun 2016 01:38:19 +0000
State-Changed-Why:
Feedback is more appropriate, since waiting for submitter (or someone)
to confirm that PR is fixed.


From: Todd Vierling <tv@duh.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/22761
Date: Sun, 26 Jun 2016 22:13:06 -0400

 >  With the introduction of network address selection policy (configured
 >  using /etc/ip6addrctl.conf file), is this bug still an issue?  Or does
 >  the address-selection-policy stuff effectively close the bug?

 I'm no longer capable of confirming this easily, but based solely on
 the ip6addrctl manpage and description, it sure appears to be fixed
 now. (Interestingly it appears ip6addrctl, originally addrselect, was
 part of the original KAME stack, but I'm guessing it was either not
 imported or not [well] documented at the time.)

State-Changed-From-To: feedback->closed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Mon, 27 Jun 2016 02:17:43 +0000
State-Changed-Why:
Problem solved.


From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@NetBSD.org
Cc: tv@duh.org
Subject: Re: bin/22761
Date: Mon, 27 Jun 2016 10:17:06 +0800 (PHT)

 On Mon, 27 Jun 2016, Todd Vierling wrote:

 > I'm no longer capable of confirming this easily, but based solely on
 > the ip6addrctl manpage and description, it sure appears to be fixed
 > now. (Interestingly it appears ip6addrctl, originally addrselect, was
 > part of the original KAME stack, but I'm guessing it was either not
 > imported or not [well] documented at the time.)

 Thanks, Todd!

 I'm using it successfully in production, and it does seem to work.

 So I will close the PR.


 +------------------+--------------------------+------------------------+
 | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
 | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
 | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
 +------------------+--------------------------+------------------------+

>Unformatted:

Home	PR Database Search