Add support for IPv6

[tduboys]

Hi, I'm trying to use Jamulus with my own dedicated server in both ipv4+ipv6 stack.

When I try to connect to the DNS with A and AAAA record, nothing happens. I dont see any packets sent from my client, and on my server (with wireshark). When I use the IPv4 directly, all is working. When I use the IPv6 directly, I see my client sending a lot of packets to 127.0.0.1:22124

Is there something wrong on my setup or on the client part regarding IPv6 ?

I'm using Jamulus 3.4.4 on Archlinux Thanks

[corrados]

IPv6 is not supported by the Jamulus software. Just IPv4.

[corrados]

This issue has been migrated from Sourceforge. Created: 2015-12-13 Creator: Volker Fischer

Right now Jamulus only supports IP v4 in the protocol messages. As a results, a Jamulus server cannot be operated if the internet connection is IP v6 only.

Volker Fischer - 2020-03-11

Interestingly, I just tried out to register a Jamulus server on a internet connection which has IPv6 only and the registration succeeded. I have not yet an explaination for this behavior but it is good news that it works.

[gutobenn]

Hi, @corrados! Could you provide more details about why IPv6 isn't supported? I'm living in an area where almost everybody's IPv4 are behind CGNAT and isn't easy or cheap to find virtual private servers nearby. We are interested in understading how much effort is needed to add IPv6 support. Maybe we could try to help on this implementation.

[corrados]

The Jamulus network protocol is completely IPv4 based. New protocol messages would have to be defined. Of course, somehow compatibility to old versions have to be preserved. I am not sure if you start a Jamulus server on a pure IPv6 network, can a client which is connected via a IPv4 network access that server? A lot of open questions... And I guess a lot of changes are needed to the Jamulus software to support IPv6 in a clean and compatible way.

[gutobenn]

Good news!

@lfzawacki and I got it working on IPv6 hosts using socat! :smiley:

I'm going to document it very soon. We've tested it only on Linux, but it seems socat can be installed on Mac and Windows too.

[biermanncarl]

@gutobenn Have you already done any documentation on how you did it? I'm having the same issues with IPv4 being not available. IPv6 support would be really big for Jamulus.

[gutobenn]

1. Install socat on server and clients.
2. On the server, execute sudo socat UDP6-LISTEN:31476,fork UDP4:localhost:31478. It makes socat forward IPv6 packets from port 31476 to port 31478 (jamulus default) as IPv4 packets. I've choosed 31476, but you can use any other available port. Just don't forget to allow connections to this port on any firewall in your network (routers or computers) and to configure port forwarding in your router, if needed.
3. On the client, run sudo socat UDP4-LISTEN:31478,fork UDP6:[server_ipv6_here]:31476, replacing server_ipv6_here with the server IPv6 address. Then connect your Jamulus client to 127.0.0.1.

For debugging, you can execute socat with parameters '-d -d -d -d' and '-v'. Wireshark or similar might be very useful too.

If you want to connect a client to the server in the same LAN network, just use the server's local IPv4 address, like 192.168.0.13.

[streaps]

The Jamulus network protocol is completely IPv4 based. New protocol messages would have to be defined. Of course, somehow compatibility to old versions have to be preserved.

I'm not sure what part of an UDP protocol would be different on IPv6 or IPv4. As the socat experiment shows, this is not really true.

I think the additional IPv6 overhead is 20 byte per packet (with 2.5 ms packets -> 64kbps per stream).

[KnobbyCLARKE]

I have just been through the exercise of getting a Static IPv4 address from my ISP because otherwise mu private Server would not work because ISP uses CGNAT. It is only a matter of time before ISP "encourages" move to IPv6. I have a dual protocol Router but I do not want to have to stop using Jamulus because it does not support IPv6 and as a MacOS user I do not want to have to get involved with the underlying Unix. Please can we at least see some work being done on this issue.

[berndbb]

I just setup an IPV6-only Server just to discover, that I cannot use it for its main purpose: Jamulus. Bad Luck. Of course, I would like to see IPv6 working. I wouldn't mind setting up something like socat on the server (although I have to admit I would never have found this solution ...).

But my mates from our choir will surely ran away if things are getting even more complicated than installing asio-driver, a new unknown software Jamulus and typing strange letters into the server field.

[berndbb]

I just want to confirm that the "socat-method" from gutobenn (May 26th) worked on my ubuntu-server 20.04. I was able to connect from my home pc to a Jamulus Server running on the ubuntu instance which is only reachable via ipv6.

Maybe I have to supply a script for the users to let them connect with one click (by using the "Jamulus -c" option). Have to check for socat for windows first.

Does somebody know how to write such a start script for Mac-Devices?

[cbix]

I would like to request for a potential implementation to be able to choose between different A/AAAA records based on the ping (or manually). Some servers I tested with have a route/ping difference of as much as 10ms between IPv4 and IPv6 and it might be desirable to regard that :)

[corrados]

have a route/ping difference of as much as 10ms between IPv4 and IPv6

Do you mean the IPv4 has higher or smaller delay compared to IPv6?

Is it consistent that one protocol version has always higher delay or is it dependend on the server so that sometimes IPv4 is faster and sometimes IPv6 is faster?

[cbix]

Do you mean the IPv4 has higher or smaller delay compared to IPv6?

It depends on the server. Actually on the datacenter + your ISP but in simple terms, host A can have 10 ms shorter ping over v4 while host B has 6 ms shorter ping over v6.

[drummer1154]

Only because today I discovered that servers on DS-Lite based internet connections (e.g. German m-net fiber) cannot be reached via IPv4 because they do not have a public IPv4 address assigned (so a Private Jamulus Server set up behind a router fed by DS-Lite (https://tools.ietf.org/html/rfc6333) cannot be reached from outside) I would like to ask the network protocol experts (@gene96817 ?) whether a quick solution to provide IPv6 support in Jamulus would be to use packet encapsulation (see https://tools.ietf.org/html/rfc2473 because I think that Lightweight 4over6 (https://tools.ietf.org/html/rfc7596) would be needed to be provided by the ISP). I am not a protocol guy but more a coder, so this is just guessing.

[gene96817]

IPv6 is very old. Finally, the Internet world is reaching the limits of delaying IPv6 with IPv4 tricks. If we want a quick solution, the best way is to ask DS-Lite what is their minimum IPv6 configuration. Then we would know the minimum amount of work to be compatible with DS-Lite.

[corrados]

I discovered that servers on DS-Lite based internet connections (e.g. German m-net fiber) cannot be reached via IPv4

That's interesting. My parents also have a fiber internet connection with DS-Lite and I can register a Jamulus server and also can connect to it from the outside. Maybe "DS-Lite" is not "DS-Lite", meaning that the providers maybe have some choices how to set it up.

[gene96817]

Most Internet providers try to support IPv4 for consumers and officially IPv4 addresses ran out a few years ago. More and more effort has gone into reclaiming and recycling IPv4 addresses. Eventually, it will really not be possible to have new (recycled) IPv4 addresses. It is more likely some parts of DS-Lite's network is now only IPv6. I would expect more and more parts of the Internet is only IPv6.

[cbix]

Not an expert with DS Lite but reaching a UDP port behind a NAT/firewall sound like a typical problem that can be solved with an external STUN server. Supporting this in Jamulus would make a different feature request though.

Took a quick look at the code and I believe the networking stack in Jamulus would need some refactoring anyway, but also for IPv6 support. There is a mix of Qt networking functions abstracting C sockets and vice-versa, address lookup using QHostInfo, then storing a QHostAddress but eventually creating a C socket (from only a port attribute) which needs a sockaddr_in for sendto ...

I don't know if the idea was to make it more efficient but it could at least be much simpler by either using only C sockets or Qt sockets, both of which can by themselves be completely transparent to the IP protocol. A client would do something like:

hints.ai_family = AF_UNSPEC;    /* Allow IPv4 or IPv6 */
hints.ai_socktype = SOCK_DGRAM; /* Datagram socket */
hints.ai_flags = 0;
hints.ai_protocol = 0;          /* Any protocol */
s = getaddrinfo("my.jamulus.server", "22124", &hints, &result);
// ...
for (rp = result; rp != NULL; rp = rp->ai_next) {
  sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
  if (sfd == -1)
    continue;
    // here we could also have a concurrent ping check like the one in the server list
  if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1)
    break;                  /* Success */

  close(sfd);
}
freeaddrinfo(result);
if (rp == NULL) {               /* No address succeeded */
  fprintf(stderr, "Could not bind\n");
  exit(EXIT_FAILURE);
}

// ... then after connecting simply use sendto/recvfrom with rp->ai_addr/ai_addrlen

Of course the server will also have to bind to IPv4 and IPv6 address ...

I don't have any experience with Qt but from the QUdpSocket docs it looks like a good alternative to raw C sockets!

[drummer1154]

@corrados

My parents also have a fiber internet connection with DS-Lite and I can register a Jamulus server and also can connect to it from the outside.

Is it possible to get the provider name? I would like to look up their AGBs and compare them to m-net's. And yes, I have read elsewhere that for DS-Lite the port mapping is not tightly specified so ISPs have room for different implementations.

On Monday afternoon prior to the rehearsal evening we got a private Jamulus server running on the iMac of our key/tp player, see https://github.com/corrados/jamulus/issues/756#issuecomment-737903152. The local Jamulus client on the same iMac could connect to the server (at 127.0.0.1) so it was possible to test audio. But it was not possible to get the server registered with the Jamulus central server. Also not possible was the attempt to set up a DynDns address. To me it appears that the fiber end point has a local DSLAM set up which provides private IPv4 addresses (192.168. 0.0/16) to the connected DSL routers (a FB 7430 provided by m-net in our case). So if we set up DynDns, the FB sends its private IPv4 to the DynDns server which is of course rejected. I believe the same happens with Jamulus central server.

Has anyone out there successfully set up a private Jamulus server on an m-net fiber based internet connection (<600 Mbit/s download)? If you have 600+ Mbit, you will also get a public IPv4 address assigned...

[gene96817]

@drummer1154 Not everything you describe makes sense to me. There are some gaps. I am now going into debugging mode. I apologize if some things are trivial to you.

1- The server is at a private IPv4 address. Did it get a full set of address configuration through DHCP? (gateway router and DNS address)? Were these addresses supposed to be manually configured? Failure to reach the central Jamulus server and DynDNS suggests a problem with these addresses. The ability to communicate with a client on the local network demonstrates the server and client software were installed correctly.

2- When the computers on the local network communicate to the Internet, the router AND the NAT function maps packets carrying the local address to the gateway router's external interface external IP address and a port. This internal/external address pairing (or mapping) is used to rewrite the packet addresses for inbound packets.

3- The host table at DynDNS will have the gateway router's (external port) address. You can manually set this entry to test inbound traffic. However, it does take time for the information to propagate from DynDNS to the global network of DNS servers. The rule of thumb is that it takes as much as two days.

4- One complication, if you are on an old DSL service, there could be an authentication step between your CPE and the DSLAM. This authentication protocol also carries the equivalent of DNS data for startup configuration. So there are two points of failure. (1) The authentication failed. (2) the router was not properly configured with the DNS server addresses (from authentication, or DNS protocol, or manually).

This is how it should work. As far as I can tell the only reason this description does not make sense is if another set of jargon is being used.

Let me know if my description does not help. It is always possible I forgot some detail not common in the USA.

[drummer1154]

@gene96817 Thanks for commenting, I have described a scenario which indeed might not be understandable outside Germany. The CPE (DSL modem + router) in use is a Fritz!Box 7430 (https://en.avm.de/service/fritzbox/fritzbox-7430/overview/) behind a fiber/DSL converter which uses DS-Lite (https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite)). You can find an English blog entry describing a working IPv6 port forwarding in this scenario at https://klaus.hohenpoelz.de/mnet-ipv6-port-forwarding-fritzbox-7430.html - not so relevant for our problem but you can see what the CPE's GUI looks like.

I need to say again that I am not a network protocol expert. The information I have put above is a compilation of statements found in other forums - mostly in German, and a short research in Wikipedia and IETF RFC 6333. The result of the said discussions is that it is not possible to perform IPv4 port forwarding if you are connected via DS-Lite.

You already said that ISPs tend to provide both public IPv4 and IPv6 addresses to their clients, so-called Dual Stack. The problem with ISP m-net is that they only provide a public IPv6 address for download rates below 600 Mbit/s and handle IPv4 traffic via DS-Lite. They set up a DSL network local to a building, transforming the fiber traffic into DSL traffic. The local DSL modems (CPEs) get private IPv4 addresses via DHCP on the WAN interface (external port) and perform NAT to translate into the private IPv4 address LAN range set up by the router. (I do not currently know if they also get an IPv6 address - will research this - my current impression is that the fiber/DSL converter performs the encapsulation of the IPv4 packets into IPv6 packets.)

Maybe I was not clear enough: The CPE performs IPv4 NAT between two private IPv4 address ranges.

The problematic part is the so-called Carrier Grade NAT (CGN) which transforms the IPv6 encapsulated IPv4 traffic back into IPv4 traffic (a second NAT in the chain). I was not yet able to dig deeper into this, so for the time being I do not know how this CGN is supposed to work in more detail than given in Wikipedia as linked above.

Regarding DynDNS, as far as I understood, the CPE sends the WAN address to the DynDNS server (initially at service setup in the CPE and subsequently as soon as the WAN address changes). As we needed to use IPv4 with Jamulus, we created only an A record in the DynDNS server, so the server queries the CPE's IPv4 WAN address which is the private IPv4 address in the DSL network. This is rejected and the CPE displays an error message.

A few remarks in addition to your points:

1 - The iMac is set up correctly with DHCP and can communicate with the internet. It only cannot provide IPv4 port forwarding, so we cannot set up a private Jamulus server. Why registering the server with the Central Jamulus server did not work needs further investigation. Edit: If Volker's parents have the same ISP and connection setup then we clearly know that something is wrong in our configuration. /Edit

2 - Yes

3 - Yes; but the propagation appears to be much quicker here.

4 - I do not believe that we have this problem as internet access works fine except the described Jamulus server issue.

Cheers from Munich Helmuth

[gene96817]

@drummer1154 What a mess. And you know a lot about these IPv4/IPv6 issues. Even if we both understand the issue, it will be difficult to explain to other Jamulus users. Take a step away from the details. Why not jus support IPv6 in Jamulus instead of trying to make IPv4 work through all these IPv4/IPv6 mappings. Doesn't Linux, MacOS, and Win10 already have enough IPv6 support for our needs? Are we trying too hard to keep using IPv4?

[cbix]

Are we trying too hard to keep using IPv4?

@gene96817 No, the current implementation is just a bit messy and intransparent to IP, but it requires some work to be fixed, so just be patient :) Or try to help refactoring the code ;)

[drummer1154]

I need to say that currently my 1st priority is to create a setup in which our band can rehearse with all 3 musicians being at home. We must live with the given ISPs (see https://github.com/corrados/jamulus/issues/756#issuecomment-737903152), and I do not see a better platform than Jamulus - also because there are a lot of discussions ongoing. I expicitly want to express my thanks to all contributing persons.

As a matter of fact Jamulus currently only works with IPv4, and DS-Lite does not support IPv4 port forwarding (simply because a single public IPv4 address is shared with multiple users/CPEs and therefore the external access to a specific CPE via (uniquely assigned) public IPv4 address and port number combination cannot work). The currently measured delays/latencies suggest to establish a server in the m-net environment, register with the central server, let the 2 other members connect and then de-register the server again so as to not be disturbed by anyone else (we need to rehearse our partially "sophisticated" arrangements and are not aimed at jamming).

I hope we can find a working setup and use the workaround above. I do not yet know how the registration with the central server works. When I enable "Make My Server Public", I think the local server initially contacts the central server (via IPv4), the "IPv4-in-IPv6 tunnel" should be established and then also the communication in the reverse direction is supposed to work.

Of course it would be great if Jamulus could be made "IPv6-ready" but I fear this will take time which we in our band do not really have ...

[gene96817]

@cbix Thank you and the rest of the team for working on Jamulus. I have discovered long ago that I am better at other task than coding.

@drummer1154 Sorry to hear you are stuck with this IPv4 mapping problem. It is a real mess. Would it be possible for you to create a IPv6 VPN tunnel for your Jamulus connections? Yes, this is another kludge. However, if you do this, your four Jamulus nodes (3 musicians plus server) will see IPv4. You will have four IPv4 devices (?) providing IPv6 VPN tunnels and your ISP will only see IPv6. Essentially you are creating a mini-CGN function totally under your control. (Alternative perspective, you are overlaying your own IPv6 network. Your NAT issues are simplified by supporting a small 4 node IPv4 network.)

[cbix]

@cbix Thank you and the rest of the team for working on Jamulus. I have discovered long ago that I am better at other task than coding.

I wish I had more free time for contributing to amazing projects like this, but so far I wasn't involved (yet) in any work on Jamulus – your thanks should go to @corrados ;)

[drummer1154]

@gene96817

Would it be possible for you to create a IPv6 VPN tunnel for your Jamulus connections?

Could you please help me setting up such a tunnel. What I tried is setting up a VPN connection between my CPE (https://avm.de/service/fritzbox/fritzbox-7580/uebersicht/ - page only available in German) and the keyboardist's (https://en.avm.de/service/fritzbox/fritzbox-7430/overview/) by configuring the VPN in both CPEs. We use the the manufacturer (AVM) service (https://sso.myfritz.net/) to resolve the symbolic addresses which are required to be entered in the CPE's VPN configuration panel.

But while my LAN can be accessed by the keyboardist, I cannot access his LAN. I always get a timeout error in the eventlog of my CPE. I think the reason is that AVM says: "The FRITZ!Box does not support IPv6 VPN connections since they cannot transmit IPv4 data." (https://en.avm.de/service/fritzbox/fritzbox-7430/knowledge-base/publication/show/1306_Can-a-FRITZ-Box-on-a-DS-Lite-internet-connection-be-used-for-VPN-connections/).

I think when we establish the VPN from the 7430, it uses my public IPv4 => access is possible. In the reverse direction (from my 7580) it does not work. However, what I do not understand is: Why can I not access the 7430 LAN, even while the 7430 has established the VPN connection to my 7580? If I deactivate the VPN configuration in my 7580 and ping the 7430 LAN I receive "Destination net unreachable." - obviously my CPE does not create a route back to the incoming VPN tunnel, and the connection is also lost from the 7430 (clear because the authentication is lost).

So I do not know how to go on...

[gene96817]

@drummer1154 Ok, now I regret my suggestion. LOL I will look at the details but it will be spread out over some days. I hope Google translate will be good enough for the technical information. you can send me email at gene96817@gmail.com.

[jms27000]

Hi, Jamulus people

i'm facing to the ipv6 migration of my ISP (SFR, France). my new configuration, for mid of December,2020 is a "IPV6 & IPV4 CGNAT" connectivity, loosing NAT & DynDNS for IPV4. so, despite calls to ISP support, my Jamulus private room is KO. It seems that the solution is the native ipv6 support within Jamulus.

Question: have you a plan for this topic ? is there any alternative ?

Thanks a lot.

Jean-Marie

[jardous]

I would also love to have the IPv6 support. Reason is simple.

My server is running on an AWS instance, that IPv4 ping takes >40ms, IPv6 ping taks just 15ms!

That is quite a difference

[gene96817]

Plus pockets of the Internet are only IPv6. Similar to AWS, there will be paths to IPv4 part of the world but it will add latency. Even though IPv4 address exhaustion was reached a few years ago, all the tricks used to keep using IPv4 adds latency.

[jardous]

Hello guys, I have first version of the IPv6 support. Please take a look: https://github.com/jardous/jamulus/commit/68933a42f5bc5b171cd5f11feec2a904556d5ee2

[jardous]

Testers welcome :) https://github.com/jamulussoftware/jamulus/pull/1017

[bjacke]

On 18.02.21 20:36, Jiri Popek wrote:

Testers welcome :) #1017 https://github.com/jamulussoftware/jamulus/pull/1017

thank you! I tested it right away :-)

1) The first test using a DNS name that has a v6 enabled mumble server didn't work for me on Ubuntu 20.04 here, The UDP6 Packages are being sent to random (and sick looking) IPv6 addresses only.

2) Connecting to a raw IPv6 address server worked! Cool!

3) When using a plain IPv6 address it's not yet working to enter a custom port number instead of the defailt 22124 port. With IPv6 I would expect most likely the bracket syntax [2020:f00:faa::1]:22125 to be working when using a custom port number.

[bjacke]

Connecting to plain a IPv4 address is not working any more with that patch applied. It also doesn't load the list of public servers.

[mstolle629]

Hello, I just wrote a patch for Jamulus 3.7.0 in conjunction with linux, which enables dual-stack support. As i am normally not a developer (i did that long ago), but have network background, i am not so experienced in github.

It is essential for the choir i am singing in and for friends to have ipv6 support working, because in our regions (near Frankfurt and Cologne) many people use internet providers which don't have native ipv4 support, but have "Dual stack lite" with ipv6 native and ipv4 only over a central NAT instance, which leads to problems with ipv4.

I have to keep backward compatiblity for jamulus and not disturb the registration on central server, therefore i decided to introduce a new option "ipmode", which defaults to ipv4 first and ipv6, if there is no ipv4 address for the server. I introduced two command line option flags "-4" and "-6". "-4 -6" = default "-6 -4" = -v6 first, -4 (if there is no ipv6 support for the Hostname) "-4" = ipv4 only "-6" = ipv6 only

For backward compatiblity, the connection to the central registration server is done by ipv4 only.

I think, we should discuss, whether a registration for ipv6 on central server should be supported. My idea would be, to register the server twice, one time for ipv4 (as usual) and a second time with a Server name Postfix of "_v6" for ipv6.

I patched ParseNetworkAddress(), so that it supports the additional parameter of "ipmode" with default to "0", so that old sources with ipv4 only are supported.

I replaced sendto() and recvfrom() with sendmsg() and recvmsg(), added some setsockopts() at the start of a socket(), so that i can read the local ip address, which the client connected to, on the server, to choose the right ip address for the answer - i think, this is useful for ipv4 only, too. Therefore I added a field "LocalAddress" to Hostaddr.

I used "ipv4 mapped ipv4". Shall i send you my patch - I never did a fork and pull request before, because i am not accustomed to github...

In addition, i do not have development platforms for Windows and Mac, therefore i don't know, how much work it is to get it run under Windows and Mac.

[mstolle629]

I just created a fork and replaced the files i edited. If you want to, someone could review it. On the other hand, i can see in the sources, that there are differences caused by "delay panning", which i would love to have.

How can i merge both?

[cbix]

@mstolle629 just open a Pull Request on this repo, that's the best way for others to review, discuss and to see the diff, update your branch etc. If you are not familiar with Git/GitHub basics, maybe this introduction helps :)

[gene96817]

@mstolle629 Are you distributing the server IPv6 address manually (i.e. out-of-band by email)? With the work you have done, it appears the biggest missing piece is supporting IPv6 in the central directory. Instead of having a server register twice, it would be good to extend the registration message to include (an optional) IPv6 address.

[mstolle629]

Yes i do distribute my server address manually.

I didn't want to change the registration message, because of downward compatiblity. I don't know, how old clients would react to new entries, which they don't understand. That's the reason, why i didn't change the registration.

My idea would be register the server twice, the second time with either a prefix of v6 or a postfix of v6, so that everybody can see, that this a v6 server.

But that's only an idea.

-----Original-Nachricht----- Betreff: Re: [jamulussoftware/jamulus] Add support for IPv6 (#46) Datum: 2021-03-31T19:18:34+0200 Von: "gene96817" @.> An: "jamulussoftware/jamulus" @.>

@mstolle629 https://github.com/mstolle629 Are you distributing the server IPv6 address manually (i.e. out-of-band by email)? With the work you have done, it appears the biggest missing piece is supporting IPv6 in the central directory. Instead of having a server register twice, it would be good to extend the registration message to include (an optional) IPv6 address. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811265876 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKQY5HV2V6LW5TQ3TBANFTTGNKOJANCNFSM4MD55VXQ . [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811265876", "url": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811265876", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ] 

[mstolle629]

My code just now doesn't work with windows (and possibly mac). I sent my code to a friend in another choir in cologne for code review and adaptation to win/mac. He has a Windows Development environment and mac. He wanted to review the code over the easter holidays, so i'll wait with my pull request till next week. In that time, you can see my changes in my jamulus fork.

[gene96817]

I offer these opinions to forward the thinking.

Whether we register a server twice or once (with two addresses) has the same result, there is a table entry with two addresses.

It should be relatively simple to extend the registration process to be backward compatible. Old clients continue to register IPv4 addresses. New clients would have a new protocol (extension) that registers two addresses.

To maintain backward compatibility, when a client request the server list, the directory assumes it is an old client and delivers the old IPv4 only list, When a new client request the server list, it indicates it is IPv6 capable and the directory delivers the server list with both IPv4 and IPv6 addresses.

The first benefit of IPv6 support will be some users will magically see lower overall delay when they automatically use IPv6 instead of the network-scale (IPv4) NAT.

[mstolle629]

Hello gene96817,

thanks for your help and your inspiration.

When a new client request the server list, it indicates it is IPv6 capable and the directory delivers the server list with both IPv4 and IPv6 addresses.

That's the right direction, but we need a solution, that a server or a client with ipv6 only can communicate.

If a server, that has ipv6 only behind a "dual stack light" solution would register ipv6 and ipv4, it would register the wrong ipv4 address.

I think, a client in "dual stack light" condition should signal, that it prefers ipv6 (with the new protocol), but it can read ipv4 (for reaching "old" servers). In that case, it should get a list with servers supporting v6 on the one hand - and the other servers with ipv4 on the other hand.

A server with the new protocol has to signal that it supports v4, v6 and v4

• or v6 only, because the central server couldn't know that. Depending on that signal it is included in one or both of these lists.

The problem would be, that you would get different lists, depending on the protocol. If one server registers ipv4 only - and another ipv6 only with the same name, what should happen?

Greetings,

mstolle629

-----Original-Nachricht----- Betreff: Re: [jamulussoftware/jamulus] Add support for IPv6 (#46) Datum: 2021-03-31T20:07:51+0200 Von: "gene96817" @.> An: "jamulussoftware/jamulus" @.>

I offer these opinions to forward the thinking. Whether we register a server twice or once (with two addresses) has the same result, there is a table entry with two addresses. It should be relatively simple to extend the registration process to be backward compatible. Old clients continue to register IPv4 addresses. New clients would have a new protocol (extension) that registers two addresses. To maintain backward compatibility, when a client request the server list, the directory assumes it is an old client and delivers the old IPv4 only list, When a new client request the server list, it indicates it is IPv6 capable and the directory delivers the server list with both IPv4 and IPv6 addresses. The first benefit of IPv6 support will be some users will magically see lower overall delay when they automatically use IPv6 instead of the network-scale (IPv4) NAT. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811298115 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKQY5HSGQEF42LIH34CQHLTGNQHBANCNFSM4MD55VXQ . [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811298115", "url": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811298115", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ] 

[gene96817]

but we need a solution, that a server or a client with ipv6 only can communicate.

This doesn't sound right. A server will have many clients that have only IPv4 addresses and a client will need to be able to access a server with only an IPv4 address. That is why there are carrier-scale NATs. For the most part, we already have clients and servers with only IPv6 assigned by their ISP but they are able to connect to the IPv4 Jamulus world through the carrier-scale NAT. (with occasional reports of problems).

it should get a list with servers supporting v6 on the one hand - and the other servers with ipv4 on the other hand.

I feel we are making things sound confusing. A server will be either IPv4-only or IPv4 & IPv6 (meaning they can be reached by either IPv4 or IPv6). Even a native IPv6 server will be reachable by IPv4 (because of the carrier-scale NAT). If there is an IPv6-only server listed that means all the IPv4 uses cannot reach the IPv6-only server. There would be a huge outcry.

A server with the new protocol has to signal that it supports v4, v6 & v4 - or v6 only, because the central server couldn't know that. Depending on that signal it is included in one or both of these lists.

I think this approach does not provide a smooth transition to IPv6. As mentioned in the previous point, for the near term, all IPv6 clients and servers also have the ability to communicate to IPv4 destinations. A server registering with the directory should (will always) know it's IPv4 address.

If one server registers ipv4 only - and another ipv6 only with the same name, what should happen?

The simple view is that:

1. All the servers in the directory has an IPv4 address
2. Some servers have both IPv4 and IPv6 addresses
3. IPv4 clients would receive the full list of servers with only IPv4 addresses
4. IPv6 clients would receive the full list of servers with both IPv4 and IPv6 addresses. (Its the coder's choice if the full list of servers is delivered with only one address, IPv6 if possible, IPv4 otherwise. I can't get excited about the difference in total bytes of the server table.)

[mstolle629]

Helo gene96817

Another "unfiltered" ideas in brainstorming:

1.) Registering twice has the advantage, that the central server sees both ip adresses of the registering server. Sometimes there is also NAT for ipv6

• or the jamulus server has more than one ipv6 internet connection. In that case it is important to register the correct ipv6 adress. On the other hand, it should be overridable by the server, which trying to register. It is important not to register temporary privacy extension ip addresses (with the exception of dhcp-reserved ones), because they change very often.

2.) The owner of the central server should decide, how the central server should communicate. We can only provide ideas for that.

3.) I am not wise enough to decide, how the protocol should work.

Let's discuss a bit longer, more ideas are welcome.

mstolle629

-----Original-Nachricht----- Betreff: Re: [jamulussoftware/jamulus] Add support for IPv6 (#46) Datum: 2021-04-01T04:13:13+0200 Von: "gene96817" @.> An: "jamulussoftware/jamulus" @.>

but we need a solution, that a server or a client with ipv6 only can
communicate.

This doesn't sound right. A server will have many clients that have only IPv4 addresses and a client will need to be able to access a server with only an IPv4 address. That is why there are carrier-scale NATs. For the most part, we already have clients and servers with only IPv6 assigned by their ISP but they are able to connect to the IPv4 Jamulus world through the carrier-scale NAT. (with occasional reports of problems).

it should get a list with servers supporting v6 on the one hand - and
the other servers with ipv4 on the other hand.

I feel we are making things sound confusing. A server will be either IPv4-only or IPv4 & IPv6 (meaning they can be reached by either IPv4 or IPv6). Even a native IPv6 server will be reachable by IPv4 (because of the carrier-scale NAT). If there is an IPv6-only server listed that means all the IPv4 uses cannot reach the IPv6-only server. There would be a huge outcry.

A server with the new protocol has to signal that it supports v4, v6 &
v4 - or v6 only, because the central server couldn't know that.
Depending on that signal it is included in one or both of these lists.

I think this approach does not provide a smooth transition to IPv6. As mentioned in the previous point, for the near term, all IPv6 clients and servers also have the ability to communicate to IPv4 destinations. A server registering with the directory should (will always) know it's IPv4 address.

If one server registers ipv4 only - and another ipv6 only with the same
name, what should happen?

The simple view is that:

1. All the servers in the directory has an IPv4 address
2. Some servers have both IPv4 and IPv6 addresses
3. IPv4 clients would receive the full list of servers with only IPv4 addresses
4. IPv6 clients would receive the full list of servers with both IPv4 and IPv6 addresses. (Its the coder's choice if the full list of servers is delivered with only one address, IPv6 if possible, IPv4 otherwise. I can't get excited about the difference in total bytes of the server table.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811586753 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKQY5FKLTHWEPRR3HGNW4LTGPJC3ANCNFSM4MD55VXQ . [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811586753", "url": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811586753", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ] 

[mstolle629]

Hello,

another idea:

Registering twice is necessary in my eyes for security reasons.

The central server needs to see the real ip address of the server, which wants to register itself.

Otherwise it would be easily possible, that a bad server could register with wrong ip addresses - and disturb or attack the jamulus system.

Therefore it is necessary IMHO, that a server for ipv4 and ipv6 will register itself separately in ipv6 and ipv4 with one connection in ipv6 and another ipv4.

Greetings,

mstolle629

-----Original-Nachricht----- Betreff: Re: [jamulussoftware/jamulus] Add support for IPv6 (#46) Datum: 2021-04-01T04:13:13+0200 Von: "gene96817" @.> An: "jamulussoftware/jamulus" @.>

but we need a solution, that a server or a client with ipv6 only can
communicate.

This doesn't sound right. A server will have many clients that have only IPv4 addresses and a client will need to be able to access a server with only an IPv4 address. That is why there are carrier-scale NATs. For the most part, we already have clients and servers with only IPv6 assigned by their ISP but they are able to connect to the IPv4 Jamulus world through the carrier-scale NAT. (with occasional reports of problems).

it should get a list with servers supporting v6 on the one hand - and
the other servers with ipv4 on the other hand.

I feel we are making things sound confusing. A server will be either IPv4-only or IPv4 & IPv6 (meaning they can be reached by either IPv4 or IPv6). Even a native IPv6 server will be reachable by IPv4 (because of the carrier-scale NAT). If there is an IPv6-only server listed that means all the IPv4 uses cannot reach the IPv6-only server. There would be a huge outcry.

A server with the new protocol has to signal that it supports v4, v6 &
v4 - or v6 only, because the central server couldn't know that.
Depending on that signal it is included in one or both of these lists.

I think this approach does not provide a smooth transition to IPv6. As mentioned in the previous point, for the near term, all IPv6 clients and servers also have the ability to communicate to IPv4 destinations. A server registering with the directory should (will always) know it's IPv4 address.

If one server registers ipv4 only - and another ipv6 only with the same
name, what should happen?

The simple view is that:

1. All the servers in the directory has an IPv4 address
2. Some servers have both IPv4 and IPv6 addresses
3. IPv4 clients would receive the full list of servers with only IPv4 addresses
4. IPv6 clients would receive the full list of servers with both IPv4 and IPv6 addresses. (Its the coder's choice if the full list of servers is delivered with only one address, IPv6 if possible, IPv4 otherwise. I can't get excited about the difference in total bytes of the server table.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811586753 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKQY5FKLTHWEPRR3HGNW4LTGPJC3ANCNFSM4MD55VXQ . [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811586753", "url": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-811586753", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ] 

[gene96817]

Separate registration events to allow the directory server to verify the address is a very good reason!

[hoffie]

Registering twice is necessary in my eyes for security reasons. The central server needs to see the real ip address of the server, which wants to register itself. Otherwise it would be easily possible, that a bad server could register with wrong ip addresses - and disturb or attack the jamulus system.

Sadly, this is already possible, either by directly using the protocol, playing with strange local ip addresses or using command line flags.

So I'd say that this should not be the deciding criterion.

[mstolle629]

This is not a deciding criterion, of cause - but, if you change the protocol or implement a new filtering on the central server, then it would make it more difficult - but not impossible - to register false ip addresses.

Btw., I ported the ipv6 support for Windows now - and get connection via ipv6 from Windows clients.

The port is still a mess and not optimized, some things have to be optimized. Name resolution still doesn't work correctly - it seems, there is still a bug in it - but this should be solveable. I got problems with memset(), which works someway different under Windows - WSARecvMsg and WSASendMsg need an IOCtl to make it visible - quite strange. The options are similar, but not equal.

I think, i will upload the code on Easter-Monday .

Greetings

mstolle629

-----Original-Nachricht----- Betreff: Re: [jamulussoftware/jamulus] Add support for IPv6 (#46) Datum: 2021-04-01T19:31:22+0200 Von: "Christian Hoffmann" @.> An: "jamulussoftware/jamulus" @.>

Registering twice is necessary in my eyes for security reasons. The
central server needs to see the real ip address of the server, which
wants to register itself. Otherwise it would be easily possible, that a
bad server could register with wrong ip addresses - and disturb or
attack the jamulus system.

Sadly, this is already possible, either by directly using the protocol, playing with strange local ip addresses or using command line flags. So I'd say that this should not be the deciding criterion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-812059798 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATKQY5C2KN56UBNXF7A5L33TGSUWNANCNFSM4MD55VXQ . [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-812059798", "url": "https://github.com/jamulussoftware/jamulus/issues/46#issuecomment-812059798", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]