Replies: 9 comments 40 replies
-
There may well be other issues in using IPv6 with Jamulus, specifically to do with large UDP datagrams and fragmentation. Apparently, IPv6 does not allow intermediate routers to fragment at the IP layer, and places the onus on the sending host to determine the path MTU size and perform its own fragmentation. Whether this requires knowledge at the application layer, or if the UDP layer can handle it, I don't yet know. But Jamulus currently relies on large UDP datagrams for server lists from Directory Servers, and for client lists from servers. The following articles provide some background: |
Beta Was this translation helpful? Give feedback.
-
What happens with directories on an IPv6 only connection? You say that an IPv4 connection is needed because of the registration process.
Why can’t we change that? |
Beta Was this translation helpful? Give feedback.
-
Could already be implemented now for usability reasons.
Yes. Preferably the client chooses the best connection automatically. |
Beta Was this translation helpful? Give feedback.
-
How should things work if a client or server has only IPv6 service and the IPv4-IPv6 gateway is operated by the ISP? |
Beta Was this translation helpful? Give feedback.
-
OK, bumping because I think it's about time we revivified this. In terms of project time lines, this would be "Jamulus v4.0.0". There shouldn't be breaking changes but it does twist the protocol a little... I've a fairly simple plan for this: The existing "server internal address" is transfered as a UTF-8 string... At first, that might seem odd. But I had plans when I did it.
Previously, it was: So I made it: So long as the total length of the field fits in the "2 bytes number n" for the length and the field encoding supports appropriate parsing, there's the possibility of putting more into it than just the server internal address. The problem is that the Directory currently has no way of knowing the Client version - it's not sent when requesting the server list. Well, not in the current version. So what I'm thinking is
If we assume the Client will always use its chosen protocol "server public address", then the server list processing needed to ensure, based on the same magic it uses for IPv4, that the switching of local and public addresses happens for both protocols. The Directory would need some backward compatibility around the server list persistence file.
Not necessarily. The Directory would be able to see from the Client version (or lack of) that it could support the new format entries. If the Server didn't have an IPv4 address and the Client didn't have the right version, then that Server could be dropped from the list (or set to an invalid IPv4 address so it would still show in
I don't think this is needed. We can have
Yeah, there are probably bits this doesn't quite cover. But I'm hoping it's getting us going again. |
Beta Was this translation helpful? Give feedback.
-
I've just picked this up again and have been giving it some more thought. I plan to produce a more complete proposal in the next week or two, but I wanted to comment on one specific part of @pljones suggestion above.
It's not necessary to have all four of those fields above, for a few reasons:
Also, I don't like the idea of Base64, and don't think it's needed here. My suggestion is for the server to put into this field its local IPv4 address (or provided server public address) exactly as at present, and for an IPv6-enabled server to append to that a single space followed by its detected public IPv6 address. For example The IPv6-enabled server will initially use that format whatever Directory it tries to register to. Once the public Directories are updated to understand this format, this registration will always succeed, so this will be the "normal" case. The Directory will just split this field on the space and use the two parts as If trying to register with an older Directory that doesn't understand this format, the request will fail validation, so the Directory will ignore the request and not respond (I've just tried it). This is because the Local IP string will be longer than 15 characters, which is the current value of If in the future we make it possible for a server instance to have only an IPv6 address and no IPv4 address, it can just send its registration request from its IPv6 address, with an empty string in the Local Address field. An IPv6-enabled Directory can then add the server entry with an IPv6 address but no IPv4 address. |
Beta Was this translation helpful? Give feedback.
-
Seems like the strategy here has been thoroughly hashed out! @softins what's the status on this? I'd be happy to guinea-pig any code/branch you need testing ... |
Beta Was this translation helpful? Give feedback.
-
Is this for backward compatibility? It just seems there's a lot of work involved to do things in a "legacy" way which are much more easily done with purpose-built things such as JSON endpoints.
I admit I haven't played with it much, but if it's well suited to certain admin-related tasks (such as directory server metadata distribution), then what's the problem with bringing it more into play?
Aren't we just talking about client requests to the JSON endpoints in question? Which is a cinch compared to your very involved proposals that I definitely haven't finished digesting :) PS Wondering also about the requirement on IPv4 re server registrations - I don't think I understood those assumptions. IPv4 addresses are becoming more expensive to use with cloud providers. And you already implemented IPv6 direct connections (kudos btw) which I still have to test ... |
Beta Was this translation helpful? Give feedback.
-
Fair enough! These are more operational concerns, as I see it, rather than pure design choices (web endpoint interactions are well understood and probably easier to maintain long-term security-wise than custom TCP implementations), but I get your point. |
Beta Was this translation helpful? Give feedback.
-
Now that #1938 has been merged to provide support for direct connections over IPv6, I wanted to start a discussion around the issues involved with adding IPv6 support for Directory Servers. This is a potentially complex thing to get right, so it is worth talking through the technicalities before starting to write code!
Server registration
All servers must still support IPv4 connections.
If a server also supports IPv6, this should be available from the same server entry. i.e. there should not be two entries in the Directory for the one server.
Servers must register with a Directory Server using IPv4, never IPv6. This is because the Directory registers the server using the IPv4 address and port number from which the registration request originates.
The existing server registration message contains the local IPv4 address of the registering server's public interface. If the server is behind NAT, this will be the LAN address, not the WAN address (the WAN address is the address from which the registration packet arrives, as mentioned in the above point). The Directory stores both the WAN and LAN addresses for the registering server.
Servers will initially register for IPv4 using the existing protocol, for compatibility with Directory Servers that do not support IPv6.
A Server that supports IPv6 will follow up with an enhanced registration message that additionally contains the IPv6 address of its public interface, as well as all the information currently in the existing registration message. This message will be ignored by a Directory Server that does not support IPv6. If the Directory Server does support IPv6, it will respond with a registration successful message. This might also need to be a new message for unambiguity.
The Directory Server receiving the enhanced registration message (over IPv4) will create or update the existing Server entry to include the supplied IPv6 address too.
A server that receives the enhanced registration successful message can note that the Directory Server support IPv6, and could elect to send only the enhanced registration message for registration renewals.
A Directory Server that supports IPv6 and receives a legacy registration message for a Server it knows about and has an IPv6 address for must not clear the IPv6 address it holds.
Client operation
It might be worthwhile to put a "Use IPv6" checkbox in the Advanced Settings and store it in the ini file.
A client that does not support IPv6 will request the server list from the Directory as currently. It will receive the existing format list that does not contain IPv6 addresses.
A client that supports IPv6 must still send the request for the server list over IPv4. This is because most listed servers will still need to send an empty message to the client's IPv4 address.
A client that supports IPv6 may send an enhanced server list request. A Directory Server that does not understand the message, or does not support IPv6, will ignore this request.
A server that understands the enhanced request and supports IPv6 will respond with a server list that includes both IPv4 and (if available) IPv6 addresses for the servers.
A client that receives the enhanced server list can continue just to send the enhanced list request to that Directory Server. Each time the client user changes list, the client will start by sending both the legacy and enhanced list request.
!!! Currently, when the Directory sends the list to a client, it also tells all the servers in that list to send an empty message to the client's IPv4 address and port. This IPv4 address and port are taken from the source address/port of the list request. What should we do about servers that are registered with both IPv4 and IPv6 addresses, when sending a client the enhanced server list? Possibilities:
The client sends the legacy list request from IPv4 and the enhanced request from IPv6?
The client sends both from IPv4, but includes its IPv6 address in the enhanced request? (probably this option)
Should we support a Directory Server that can only communicate on IPv4, but that does support the storing of servers' supplied IPv6 addresses? We probably should. If so, then the client needs to send its IPv6 address in the enhanced request.
If the directory server is serving an enhanced list, it should tell all listed servers to send the normal empty message to the client's IPv4 address, and those servers registered with an IPv6 address also to send an empty message to the client's IPv6 address.
!!! What about the pings performed by the Connect dialog? If a client supports IPv6, and a server has both IPv4 and IPv6 addresses, we should probably list it twice in the list, and send a ping to both addresses, so the user can observe any difference and choose which to connect to.
Beta Was this translation helpful? Give feedback.
All reactions