ipv6 support

Adding this to dcpp team since we should have support for this since its in the protocol aslo changed to wishlist since we are aware that its not in the client yet.. think poy mubled something about him not having the testing capabilites or something cant recall ^^

Hi everybody,

Your information is stale.

ADC-hub uhub has this feature about year:
  http://www.uhub.org/
Testing PtokaX DC hub and even CzDC client:
  http://i15.fastpic.ru/big/2011/0219/e3/003ff25f41a3a62bdaa092ff2994c8e3.png

Original link: http://www.czdc.org/PtokaX/PX-CzDC-IPv6.png

I'm working on support ipv6(i think only in ADC) in linuxdcpp...
 Anyone else need it? Now I have working file transfers between ipv6 clients, but it seems broken support ipv4. I'm working on it ;) Patch will upload later.

Sorry for the mistake - I thought it linudcpp page.

Don't worry. This is feature for DC++ core. So this is the correct place...

When both I4 and I6 are available in INF where the client should connect to? To address specified in I4 or in I6?

It can be special option. And I think that IPv6 as default connection is better because this is the future.

Also you can take into account the experience of torrent clients. Programs which I saw prefer IPv6 connection when it available but use both of them.

And if you can to combine IPv6 with your realisation of DHT it will be really great feature.

and is there any ADC hub able to run on IPv6? I tried that uhub but I was able to run it on IPv4 only.

1) Did you launch it in MS Windows or in another system?
2) What type of IPv6 connection have you got? (direct connection/tunnel broker/teredo)
3) What value of server_bind_addr variable (in uhub.conf) did you try? It should be something like that:
server_bind_addr=fe80::203:47ff:fe31:fde0
or
server_bind_addr=::1
(for localhost)
Note: if server_bind_addr=any is uses only IPv4 interfaces...

Hmm, official documentation says that program automatically detects if IPv6 is supported and prefer that:
"Specify the IP address the local hub should bind to. This can be an IPv4 or IPv6 address, or one of the special addresses "any" or "loopback". When "any" or "loopback" is used, the hub will automatically detect if IPv6 is supported and prefer that."

http://www.uhub.org/config.php

I'm on Win7 Pro x64. If I run uhub, it says that it's listening on 0.0.0.0 (which is IPv4 address), If I change config from "any" to ::1, the uhub closes immediately after startup. If I try to connect to hub (listening on 0.0.0.0) via ::1 or that long IPv6 address (which I found in Windows Network Center), it says something like "Can't connect because remote server actively refused the connection" (don't know the exact English translation).

Sorry, I wrote wrong example:
::1 is analog of 127.0.0.1 (loopback)
0.0.0.0 analog in IPv6 is ::

So you can try server_bind_addr=::

We already tried last version of uHub from it's master branch in Debian and Arch Linux ant it works fine with default settings:
2011-07-28 21:39:30 INFO: Starting uhub/0.4.0, listening on :::1511...
In full accordance with official documentation.

Unfortunately I have no any Windows distribution at my disposal. But I have asked this question to our community. And when anybody launch uHub successfully I will write here about his experience.

Did you check IPv6 interface settings in your system?
It should be something like ipconfig /all in cmd.exe

server_port=1511
server_bind_addr=::

Successfull launch with patched linuxdcpp. Tested with pathed linuxdcpp.

in Debian unstable. uhub from git.

First results are not optimistic...

1) Unfortunately last development version of uHub has compilation error in MS Windows yet.

2) Last stable release 0.3.2 was compiled normally but it don't work with IPv6 interface:
C:\uhub>uhub.exe -v
2011-07-29 03:23:08 WARN: Windows system, limited to 4096 connections.
2011-07-29 03:23:08 DEBUG: Initialized select network backend.
2011-07-29 03:23:08 DEBUG: IPv6 not supported.
2011-07-29 03:23:08 FATAL: Unable to start hub service

This is the case when server_bind_addr=:: in config.

In my Debian system this version of uHub also work fine:
2011-07-28 22:50:32 INFO: Starting uhub/0.3.2, listening on :::1511...

$ netstat -a | grep 1511 | grep tcp6
tcp6 0 0 [::]:1511 [::]:* LISTEN

3) Precompiled files from http://www.extatic.org/downloads/uhub/

C:\uhub-0.2.8>uhub.exe -v
2011-07-29 03:42:10 DEBUG: IPv6 not supported.

C:\uhub-0.2.7>uhub.exe -v
2011-07-29 04:13:49 ERROR: Unknown ACL command on line 52: '.'

C:\uhub-0.2.6>uhub.exe -v
Thu, 28 Jul 2011 20:12:15 +0000 ERROR: Unknown ACL command on line 52: '.'

...

C:\uhub-0.2.2-3393>uhub.exe -v
Thu, 28 Jul 2011 20:20:50 +0000 DEBUG: IPv6 supported and enabled.
Thu, 28 Jul 2011 20:20:50 +0000 INFO: Starting server, listening on :::1511

C:\uhub-0.2.0-3293>uhub.exe -v
Thu, 28 Jul 2011 20:05:35 +0000 DEBUG: IPv6 supported and enabled.
Thu, 28 Jul 2011 20:05:35 +0000 INFO: Starting server, listening on :::1511

netstat says:
 TCP [::]:1511 [::]:0 LISTENING [uhub.exe]

Also I tried to launch ubub binaries from wine.

TEMP/uhub-0.2.8$ wine uhub.exe -v
fixme:advapi:RegisterEventSourceA ((null),"mpich_mpd"): stub
fixme:advapi:RegisterEventSourceW (L"",L"mpich_mpd"): stub
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000000,(nil),0x0001,0x00000000,0x85e5cc,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000000,(nil),0x0001,0x00000000,0x143da8,(nil)): stub
fixme:advapi:DeregisterEventSource (0xcafe4242) stub
2011-07-28 23:26:18 DEBUG: ACL: Added user 'Dj_Offset' (admin)
2011-07-28 23:26:18 DEBUG: ACL: Added user 'janvidar' (operator)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'Hub-Security' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'Administrator' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'root' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'admin' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'username' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'user' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'guest' (deny_nick)
2011-07-28 23:26:18 DEBUG: ACL: Deny access for: 'operator' (deny_nick)
2011-07-28 23:26:18 DEBUG: IPv6 not supported.
2011-07-28 23:26:18 INFO: Starting uHub/0.2.8, listening on 0.0.0.0:1511...

TEMP/uhub-0.2.2-3393$ wine uhub.exe -v
err:menubuilder:init_xdg error looking up the desktop directory
fixme:advapi:RegisterEventSourceA ((null),"mpich_mpd"): stub
fixme:advapi:RegisterEventSourceW (L"",L"mpich_mpd"): stub
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000000,(nil),0x0001,0x00000000,0x85e5cc,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000...

I tried uhub version 0.2.0-3293 and IPv6 works there correctly. Now my client is able to connect to IPv4 hubs and IPv6 hubs according to given IP address format.

This is a rather amusing situation. I know about three different implementations of IPv6 in the ADC-clients, but I have not seen any of them in the sources. Perhaps it's time to write own bike... =)

IPv6 support in StrongDC++ is now almost ready - IPv4/IPv6 connections to hubs work, connections between users work correctly too. But there are two possible implementations and each one has its advantages and disadvantages. Now I have to choose one of them:

a) hybrid dual-stack
+ just one IPv6 socket is created and it supports both IPv4 and IPv6 connections
+ very easy to implement and code is almost clean
- it's not supported on older OS's (e.g. WinXP doesn't support it)
- IPv4 addresses are in IPv4-mapped IPv6 format, so conversion must be done

b) independent dual-stack
+ works on all OS's with IPv6 support (including WinXP)
+ IPv4 addresses are in IPv4 format
- two sockets need to be created - one for IPv4 and one for IPv6 connections (increases resource usage)
- almost everything needs to be doubled (you need to listen on both sockets, do blocking wait on two sockets etc.)
- a more complicated for implementation than first method (you need to check for IP address version etc.)

StrongDC++ will use the first method. But what to do when hybrid dual-stack is not supported (e.g. WinXP)? Should I fallback to second method or completely disable IPv6 support in this case?

a) with IPv6 completly disabled in XP is the obivious choice. But what about *nix? Would this method be usable there?

From my point of view (developer's opinion) we should use method a). And in the case when OS doesn't support hybrid dual-stack, program should work with IPv4 only. But it should work fine. So users with old operation systems will not have one feature, but they will be able to take part in file sharing as before.

Also conversion addresses from IPv4 to IPv6 is very simple. And it can be made in sources very easily. So users even will not see the changes.

The core will be opting for b) probably - but I'm doing for educative reasons to see how complicated it turns out...

In any case, it has a few advantages such as making it easier to connect through ipv4&6 in parallell and see which one connects faster instead of trying ipv6 first and then v4 (it stands to reason to try both if both are available)...

eMTee: I think that *nix systems shouldn't be any problem. But I will try it under Ubuntu to be 100% sure.

Tehnick: yes, conversions are simple. There is also IN6ADDR_SETV4MAPPED function to simplify that. But I think that adding and removing "::ffff:" prefix from IP addresses should be fine.

arne: you can connect to ipv4&6 in parallel but what would it be for in real usage? Hybrid dual sockets allow connecting to both IP versions without redudant code for separate sockets. But I must admit that b) would be more consistent with ADC protocol which provides U6 (and therefor listening on port different from U4) should be possible.

And when I mentioned ADC protocol. There is CTM command but it doesn't specify whether <port> is for IPv4 or IPv6. It seems to be little inconsistency - UDP ports can be different for each protocol, but TCP port is only one (and nobody knows which protocol to use when I4 and I6 are both specified).

so my implementation is here: http://strongdc.svn.sf.net/viewvc/strongdc?view=revision&revision=573

I see it also works in DHT. This is great! People connected via NAT will be happy. Thanks a lot for a fast realisation.

Yeah, since I touched Socket layer only, it should work everywhere - ADC, NMDC, DHT, HTTP etc. I just need to test behaviour under *nix systems. Also, I'm not sure about Util::getLocalIp() - but I know exactly that this function doesn't work under *nix correctly. Here, under Ubuntu, it returns always 127.0.1.1 and not my real IP.

Well, for one when resolving with getaddrinfo, you might get more than one ip (in truth there might be more than 2 but I cheat a little), and you're supposed to connect to all, either in parallel or in the returned addrinfo order - so for example if a domain advertises both an ipv4 and an ipv6 address but the hub/server only runs on one, you're in for a long wait if you connect sequentially (and no connection at all if you keep using just the first resolved address). The second problem is that while you might have an ipv6 address, seeing that everything is quite fresh it might not work for config reasons so it stands to reason to try ipv4 as well if available.

As to the protocol, I agree that is an issue - there are more issues such as references to a long deprecated rfc for the ipv6 address format (I haven't checked but I hope it is in line with the latest representations (rfc 5952 and 4291). In any case, until the issue is resolved, one might as well try both and see which one works (from what I can tell, most servers listen to the same port on both v4 and v6, specially the hybrid dual-stack ones - so the question is whether it makes sense to have separate u4 and u6 ports...

Just to clarify about uhub and IPv6 support.
uhub works by using Big Muscle's option A, but all binaries released in the past have been compiled on WinXP which does not support IPV6_V6ONLY define, and thus IPv6 is disabled.

It should work on all other OSes, and if compiled on newer windowses.

JVK, how do you handle I4/I6 auto-detection?

Basically, if uhub receives a connection from an IPv4 address it removes the I6 and vice versa. It means IPv4 clients cannot talk to IPv6 clients (at least not in active mode).

I just saw the commit: http://bazaar.launchpad.net/~dcplusplus-team/dcplusplus/trunk/revision/2605

So it looks like original DC++ already has IPv6 support. Does anybody tested it?

Also I didn't understand yet is this the same realisation as in BM project or another one?

afaik it's a bit different from the one implemented in StrongDC, the IPv6 in DC++ well if you have anyone with IPv6 IP's it would be nice to test in pure IPv6 mode so by all means if you can help us with that you can inquire in DCDev Public hub

Implementations are different. (See above)

How is ADCH (or any other hubsoft) going to verify the second IP (the one he is not using for the hubconnection) if a hub is going to support both IP4 and IP6 for H-H, the IP6 client can have SU TCP4 while connected with IP6 and that IP is not verified so can be used for CTM flood ?

uhub strips off all IP addresses IPv4 or IPv6 and adds the one the client connected from.
So, if connected from an IPv6 address then the IPv6 address is the only address other clients can see (and vice versa for IPv4).

So then the question - how hubs which are running on both version will handle this situation? Hub with 2000 users (1500 via IPv4, 500 via IPv6) - I guess 1500 users can connect only together and 500 the same? So that 500 users can't connect to the 1500 users and vice versa?

Maybe a possible way to deal with the IP verification process, have putted the rough idea it in attachement :)

(1) I share Big Muscle's concern. This proposed HBRI extension addresses the client-hub aspect, but the client-client issues remain. This does, as Pirre has elsewhere pointed out, form a necessary condition for client-client connections.

In some circumstances, this is an insurmountable problem - if a pair of users cannot share an IP protocol, but such should be rare given the coming near-ubiquity not of pure IPv6 users, but of of dual-stacking. Therefore I suspect BM's worst-case will not become common.

(2) It's a little odd the client sends its own email address at all, but that's not a quirk new to HBRI and does render it consistent with DC++'s current behavior. The default address a client would send to a hub is 0.0.0.0 (or, one would suppose, :: for IPv6) regardless. I'm just unsure under what circumstances allowing meaningfully different client-sent IPs makes sense.

(3) Otherwise, HBRI seems to function reasonably and with about as few round-trips as one can get away with. I like that it doesn't place additional constraints on which of the four combinations of (IPv4 yes/no) and (IPv6 yes/no) that a given client might be able to listen on due to ISP routing, firewalling, or NAT considerations.

Having a dual-stack hub (or effective hub, if one splits roles across machines or software, but that doesn't affect the protocol suggested) seems a minimal requirement for any solution to this, such that the hub can verify both IPv4 and IPv6 addresses. HBRI seems a near-minimal yet usable extension of ADC to allow that and as such it seems worthwhile.

an alternative to HBRI that doesn't require a separate extension:

1) hubs send I6 and I4 fields in their hub INF to indicates the IP addresses they are listening on.
this step may not even be required if the "alternate" IP of the hub is available by other means (DNS record, hub list...).

2) upon receiving the initial hub INF, clients that wish to be available on both IPv6 & IPv4 networks can then connect to either the hub's I6 or the hub's I4 (obviously they would pick the one they are not already connected to).
the client then goes through the regular login process in order for the hub to associate the client's IPv6 address to its IPv4 address. the additional connection is then cut.

3) after a successful verification of a client's "alternate" IP, the hub adds that information to the client's INF and updates it so other users are notified of it.

4) when a user wants to connect to another user, it can:
- connect only to its IPv6 address if an I6 is present in that user's INF.
- connect only to its IPv4 address if an I4 is present in that user's INF.
- connect to both if both are present, then discard the one that didn't connect first.

poy : your proposal misses the possibility to link the 2 connections to 1 unique client i think.

There can be more then 1 same ip4 or ip6 in the hub already.

Nore the CID gives a uniquenes @ the moment of connecting to the second address there can be already same CID (other client) in the hub who then get a support he should not have ...

Thats exactly why the HBRI is there , there it gives the hub the original's client connection's SID and tolken so it is sure its that client that gets the support for the second ip version.

linking the 2 connections to a user is the point of steps 2 & 3.

when a user B connects, if that user has the same CID but a different IP type (v6 / v4) than another user (user A) already connected, then user B's IP is added to user A's INF and user B is then discarded. user A then has 2 IP fields in its INF (I6 and I4).

:) then user B will receive all c-c communication of user A for that protocol and not even be in the hub ... not having a file etc

sure, but by that time it would have been determined (with the PID / CID check) that user B is in fact the same as user A.

user B never actually appears in the user list; it is just a connection from user A in which a SUP and an INF are sent. the INF can be trimmed to only containing the PID, CID (and if a custom IP is configured, an IP). once the PID&CID have been verified, that "user B" connection is disconnected and the IP is transferred over to user A's INF.

nor the CID or the PID/CID combination is unique (instalations containing a xml) , if it would be we shouldent have so much "same cid" disconnects but CID does'nt match PID instead. maybe i am wrong but imho there is only a real implentation if a client can be sure that the INF the hub sends is correct and not a guess ...