IPv6 and 1.2.1.1

[Rudi De Vos]

Looks like DirectAccess is a good way to test ipv6.
What need to be done to make it working ?

[jeffwmiles]

With 1211 IPv6 version, UltraVNC works over DirectAccess. In my environment, it only works as a reverse connection, initiated from the server side with "winvnc.exe -connect". This isn't a problem.

The difficulty is that UltraVNC only listens on one protocol at a time, but the nature of DirectAccess means users are roaming inside and outside the corporate network. Our internal network is IPv4, but outside on DirectAccess all client communication is IPv6.

For this to be viable without messy workarounds, we need UltraVNC to respond to both protocols at startup.

In my testing, the viewer has not needed to be the IPv6 version, as far as I recall; I think this is because of the 6to4 conversion that DirectAccess is doing once the traffic gets internal to the corporate network.

I haven't done extensive testing of the IPv6 version from a DirectAccess client, but I know so far that it works great when statically set to that protocol.

[Rudi De Vos]

Perhaps i explain first how it's current implemented so you can tell better what require a change.

ipv6 special versions implementation

Viewer
connect:
If you enter an ipv6 ip, ipv6 mode is used
If you inter an ipv4 ip, ipv4 mode is used
if you enter a name, dns search the name and request if it is ipv4 or ipv6
If dns answer ipv4 and ipv6 , we first try ipv6 and then switch to ipv4 if ipv6 fail.
reverse:
The viewer create 2 listening sockets ( one for ipv4 and one for ipv6) and answer to both.

Server
listen
you need to set the server to listen to ipv4 or ipv6
He only can listen to one mode
Reverse connection
If you enter an ipv6 ip, ipv6 mode is used
If you inter an ipv4 ip, ipv4 mode is used
if you enter a name, dns search the name and request if it is ipv4 or ipv6
If dns answer ipv4 and ipv6 , we first try ipv6 and then switch to ipv4 if ipv6 fail.

[jeffwmiles]

Thanks for the clarification Rudi.

Your note about the Reverse Connection using DNS to determine the protocol type gave me hope, but it didn't work as I expected.

Based on testing with a DirectAccess client (I'm testing Reverse VNC exclusively):

If the winvnc service is started at boot and UseIPv6=1, Reverse VNC works over DirectAccess
If the winvnc service is started at boot and UseIPv6=0, Reverse VNC fails over DirectAccess
If I change the value of UseIPv6=1 and restart service, Reverse VNC works

If the service is NOT started, and I try "winvnc.exe -connect", no window appears at all, no winvnc process starts.

What would be ideal is if the WinVNC.exe service could listen on both IPv6 and IPv4 at the same time. Or, if running "winvnc.exe -connect" would spawn a WinVNC process and dynamically use IPv6 or IPv4 for a user with no admin rights.

[Rudi De Vos]

winvnc commandline always require -run at the end.
http://www.uvnc.com/docs/uvnc-server/51 ... eters.html

Code: Select all

If the winvnc service is started at boot and UseIPv6=1, Reverse VNC works over DirectAccess
If the winvnc service is started at boot and UseIPv6=0, Reverse VNC fails over DirectAccess
If I change the value of UseIPv6=1 and restart service, Reverse VNC works

This indicate that ipv6 is required for DirectAccess

There was some reason why is switch was implemented and not a dual listener.
I know it's posible, i guess i run in trouble implementing it because.
When time i gonna try the dual listener again.

[AmigoJack]

If you enter an ipv6 ip

No, IPv6 addresses are only recognized when being in the full format with padding zeroes:

1. affe:dead:cafe:fade:beef:0000:0000:0001 = the only one that works
2. affe:dead:cafe:fade:beef:0:0:1 = valid format without padding zeroes, uVNC doesn't recognize
3. affe:dead:cafe:fade:beef::1 = valid short format, uVNC doesn't recognize
4. [affe:dead:cafe:fade:beef:0:0:1] = used in URLs to distinguish IPv4 from IPv6 without colliding giving a port, i.e. http://[affe:dead:cafe:fade:beef:0:0:1]:8080/root, but also not supported by uVNC

Format A is quite unusable in reality - most of the times you always get an IPv6 address in format B and don't always have the time manually add the zeroes. You should also support format D, as then one can still either add :display or ::port without confusing how far the address part goes. More examples of how it should be implemented:

1. 127.0.0.1:0 = easy: using dots means an IPv4 address.
2. ::1:0 = ambiguous: either IPv6 address ::1 is meant along with display 0, or IPv6 address ::1:0 is meant. In such a case give an error message.
3. [::1]:0 = easy: using square brackets means an IPv6 address and you know where it starts and where it ends.
4. 2101:4:deaf:0:0:0:0:5:0 = easy: IPv6 has at max 8 words, so :0 at the end must be the display.
5. 2101:4:deaf:0:0:0:0:5::5009 = easy: IPv6 has at max 8 words, so ::5009 at the end must be the port.
6. 2101:4:deaf::5:0 = ambiguous, just like case 2.) - give an error message.
7. 2101:4:deaf::5::5009 = easy: IPv6 can have at max 1 shortcut, so ::5009 at the end can't be an address word, but must be the port instead.

You see, it's not that difficult. However, it took me a couple of attempts until I realized that uVNC only accepts format A.) and then tries to use IPv4 instead (this could have internal reasons, but made no sense, as my remote partner did not have any IPv4 address). I wonder nobody else complained.

[AmigoJack]

Furthermore I'm not even sure how uVNC will work if Bob has only one IPv4 address and Alice has only one IPv6 address - from plain knowledge I'd say this is impossible, unless I'm missing a protocol specification. However, with i.e. British ISPs only serving IPv6 addresses and i.e. German ISPs only serving IPv4 addresses any communication attempt between those seems to be doomed. Not to speak from users lacking technical skills that don't really grasp they have to use a different EXE and which IP version they have. Can't those two EXEs not at least be merged into one, so the viewer/server is intelligent enough to recognize the IP version on its own? Distinguishing IPv4 addresses from IPv6 is unambiguous.

I successfully used uVNC in the past, but only because the communications were always IPv4 versus IPv4.

This time I wasn't able to figure out a working scenario. First I had to find out my partner's Windows platform version (32bit versus 64bit). When taking control of another person's computer this almost always implies it happens because he can't figure out himself. But he has to know which platform he's using AND which IP version - hello? For me it's no problem. For my partner(s) it definitly is. My suggestions: add a launcher - another EXE that recognizes the platform (32bit or 64bit) and the IP version being used (v4 or v6 or even both) and then disables all those viewers/servers that wouldn't make sense to start. That would help a lot!

In my particular scenario my partner was using Windows 10 x86 (32bit), having an IPv6 address, while I have Windows 7 x64 (64bit), having an IPv4 address. After (with my help) he found out he used the IPv6 Server, and I tried both IPv4 and IPv6 viewer - with no success. Learnt that entering an IPv6 address gives the first problems, and after that I never managed to see in the "establishing connection" window to see the address I entered (it was mostly only the first word of the IPv6 address, or worse a display with a very big number, obviously from misinterpreting my input). Frustrated enough I had no choice but to use TeamViewer, which worked instantly. But I always kept my fingers off because traffic runs thru their servers, which is why I want either this very project or another (TigerVNC was no help either) to succeed in advanced scenarios like these. And not have issues with the startup already.

[Prisma]

You see, it's not that difficult.

No, it's only easy for a human. But I'd say any format that could lead to ambiguous interpretation in connection with a port can't be used.
In your specific case only A B D could be used, because they are unambiguous. But B+C are both shortened formats where C is ambiguous. So, to break it down to a simple and transparent way I'd say:

Either use the completely unshortened format or use the square bracket format with any shortening you want.

Code: Select all

2101:0004:deaf:0000:0000:0000:0000:0005::5009
[2101:4:deaf::5]::5009

Everything else would be to complex to implement EDIT: and to understand for the end user.

[AmigoJack]

to complex implement

Counting char occurances within a string, counting string occurances within a string... I don't see the complexity here and could easily write that myself within 1 minute using PHP, or 5 minutes using Pascal, or 10 seconds using regular expressions. Just focus on square brackets accepting all valid IPv6 formats (which includes 2101:2:3:4:5:6:7:127.0.0.1 as well, but that should really be a rare encounter).

[Prisma]

The complexity lies not in handling the chars and strings but in handling the ambiguous cases in formats where ambiguous interpretations are possible.Therefore we should only allow un-ambiguous formats.

Just focus on square brackets accepting all valid IPv6 formats

Yes, this is exactly what I suggested.

And to make it easier for the end user to understand where which format is allowed I suggested to allow shortened formats always and only in square brackets.