Is the bug still present in vsftpd-2.0.1? This should also be IPv6
module bug. Try 2.6 kernel. 

The same behaviour continues.

Kernel  2.6.7-1.517smp 
vsftpd  2.0.1-2

This does relate to connection coming in as IPv6-mapped, e.g.
when system is listening on  :::21  the connection comes in
to local address ::ffff:2.3.4.5:21   and now the system will
consider the remote to be IPv6 speaker, even tough it is coming
in thru that IPv6-mapped address space, and it will produce v6-
sockets for outbound connections as well, BUT it will still
use V4 addresses to connect() to them (see strace below.)

This relates also to newish "you can't bind :::21  and *:21
at the same time" behaviour in IPv6.

The  vsftpd  appears to function as two processes for each
connection.  Child runs with logged-in user's privileges,
while parent runs as 'nobody'.

Child talks with remote user, and asks parent to create sockets
for it.

  --- child ---
recv(0, "PORT 62,78,96,80,201,165\r\n", 4096, MSG_PEEK) = 26
read(0, "PORT 62,78,96,80,201,165\r\n", 26) = 26
write(0, "200 PORT command successful. Con"..., 51) = 51
rt_sigaction(SIGALRM, {0x948930, ~[RTMIN], SA_RESTORER, 0x1f4778},
NULL, 8) = 0
alarm(300)                              = 288
recv(0, "LIST\r\n", 4096, MSG_PEEK)     = 6
read(0, "LIST\r\n", 6)                  = 6
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
write(5, "\3", 1)                       = 1
read(5, "\1", 1)                        = 1
recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
msg_controllen=16, msg_control=0xfee734d0, , msg_flags=0}, 0) = 1
fcntl64(6, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(6, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(6, {sa_family=AF_INET, sin_port=htons(51621),
sin_addr=inet_addr("62.78.96.80")}, 16) = -1 EINVAL (Invalid argument)
fcntl64(6, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(6, F_SETFL, O_RDWR)             = 0
write(0, "425 Failed to establish connecti"..., 37) = 37
close(6)                                = 0
close(4)                                = 0
rt_sigaction(SIGALRM, {0x948930, ~[RTMIN], SA_RESTORER, 0x1f4778},
NULL, 8) = 0
alarm(300)                              = 300


  ---- parent ---
read(4, "\3", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 6
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(6, {sa_family=AF_INET6, sin6_port=htons(20), inet_pton(AF_INET6,
"::ffff:62.78.96.67", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
28) = 0
write(4, "\1", 1)                       = 1
sendmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
msg_controllen=16, msg_control=0xfee737f0, , msg_flags=0}, 0) = 1
close(6)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0

I do recall, that the "you shall not bind *:21 and :::21 at the same
time" is IETF mandated behaviour, so Linux kernel does it correctly.
.. that comes (indirectly) from RFC 3493 section 5.3.


Oh, and there is no "IPv6-mapped" address format, there is
"IPv4-mapped" one.

Seems that this issue is fixed in the latest prerelease of vsftpd. The
test rpms can be found on personal page and are avaliable for tests.

http://people.redhat.com/rvokal/vsftpd/2.0.3-pre2/

Would be great to confirm if this issue gets fixed. 

vsftpd-2.0.3 released and is now avaliable in devel tree.