[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: broken IPv6 code




On 31 Dec 2000, Brian May wrote:

> Debian potato, 2.2.18, and no, port 8024 is not already in use.
> 
> As far as I am aware, this is the standard way of binding both to IPv6
> and IPv4, however, it obvious does not work. It this a kernel bug?  a
> glibc bug? or a bug in the above code?
Nopes... you see this wrong :)

Though it depends on the OS.
The Win2k implementation of the IPv6 stack is completely seperated from
the IPv4 side, and then what you did above would be correct.
Though on most UNIX'es (using KAME at least) listening on IPv6 will
also listen on IPv4, On FreeBSD:
8<----
tcp46      0      0  *.domain               *.*                    LISTEN
------>8
On debian you can verify this by giving the -A inet[6] option to netstat.

Also to give you insight how to detect IPv4 clients (snipped from Cyclone IPv6 patches :)

/*
 * inetntop: return the : notation of a given IPv6 internet number.
 *           make sure the compressed representation (rfc 1884) isn't used.
 *
 * This version also checks for addresses that are actually IPv4.
 * eg. ::ffff:10:100:13:66 or 0:0:0:0:0:ffff:10.100.13.66 is actualy the
 *     the IPv6 notation for 10.100.13.66 in IPv4.
 *     This happens when an IPv4 client connects to an IPv6 server :)
 */

So.... when one connects from IPv4 to an IPv6 listening program you can
'see' that it's from IPv4 due to the leading 0:0:0:0:0:ffff.

This info is also needed when one needs to due reverse lookups because
IPv4 reverse's are in the "in-addr.arpa" domain and the IPv6 reverses are
in the "ip6.int" domain, noting that the ::ffff range isn't reverse mapped
into the in-addr.arpa part...

Greets & Happy New Millenium,
 Jeroen




Reply to: