>Number:         22761
>Category:       bin
>Synopsis:       There is no way to choose IPv4 preferably to IPv6
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 12 17:34:00 UTC 2003
>Closed-Date:
>Last-Modified:
>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:
>Unformatted: