[ENet-discuss] IPv6 Support

[Lee Salzman]

What I was thinking a long time ago was to use a specific ipv4 host address as the ipv6 marker, since the port is still necessary in any case. And then underneath the port, reserve space for an actual ipv6 host address.

So you end up with something like:

struct ENetAddress
{
     enet_uint32 host;
     enet_uint16 port, reserved;
     enet_uint32 flowInfo;
     enet_uint8 address[16];
     enet_uint32 scopeId;
};

Then have:

ENET_HOST_IPV6 = 0xAC1111AC

... where the above is some hex palindrome (reads same in both big and little endian) is otherwise not a public ipv4 host.

So you set the host to ENET_HOST_IPV6 and just fill in the rest of the fields. Most use cases of ENetAddress blah = { host, port }; would work as they always did. Certain stuff could possibly even be mirrored between both ipv4 and ipv6 data when being passed back to the app.

Only real danger is that ENET_HOST_IPV6's value needs to be chosen well enough that it is "unlikely" for it to ever occur in practice by accident or cause dangerous behavior if it does.

On 07/07/2013 09:23 PM, James Bellinger wrote:
> On 7/7/2013 12:10 PM, John Cotton Ericson wrote:
>> I recently submitted a patch "sketching" IPv6 support for ENet: https://github.com/lsalzman/enet/pull/21 . I say "sketching" as I haven't tested it at all: once the issues below are resolved, I will refine and test it, and then resubmit an actual patch.
>>
>> The biggest issue with this patch is it breaks the current interface by redesigning the EnetAddress structure. One can read the comments between Lee Salzman and I on the github page, but I will summarize below:
>>
>> I think we both agreed the interface change with IPv6 support is inevitable. I thought simply incrementing the version number, and supporting two versions for a time would be sufficient. He supported changing the namespace (function prefix and header names I assume) in order to avoid clashes.
>>
> It doesn't have to break anything. Here's one possible route...
>
> The ENetAddress in most ENet structures is effectively read-only. Add an ENetAddress2 to ENetHost etc. and leave the others in as IPv4-only mirrors of the real data.
> Have it initialized with accessor functions, and give it a structure like
>
> struct ENetAddress2
> {
> uint8_t magicIPv6Marker[6];
> real data like port, address, type, etc;
> };
>
> There are reserved IPv4 addresses that can't exist on the net, and you could use one of those for the magic. If the ENet address functions got one of these, and enet_initialize_with_callbacks was passed a sufficiently high version (so that the caller's structures have room for the extra data), the structure could be assumed ENetAddress2. Otherwise, it's an IPv4 address.
>
> If one wanted to transparently add IPv6, the old struct ENetAddress could become ENetCompatibleAddress, ENetHost's address could become addressIPv4, a new ENetAddress 'address' could be added at the end. For new projects compiling with new headers wanting compatibility with old ENet versions, an "IPv4-only" define could be added.
>
> Something like that. Your thoughts?
>
>> I also questioned storing the port number in host byte order, when as far as I know Windows and Unix consistently store it in network byte order. I brought this up because in my implementation, I defined EnetAddress as a union of the existing sockaddr_in and sockaddr_in6 structures, with the sole exception of keeping the portnumber in host byte order as ENet currently does. Salzman responded that the ease of working with port numbers in host byte order outweighed the extra marshaling in the socket_* functions such a design decision entailed.
> Network byte order is an implementation detail of sockets. ENet's socket code is an abstraction layer above that so folks don't have to be exposed to it.
>
> sockaddr_in and sockaddr_in6 are going to be inconsistent between platforms. If you went this way, you would *have* to add accessor functions even for port, or nobody can support cross-platform wrappers that rely on the binary format (something that *mostly* has been possible with ENet to date). I can't see a compelling reason to use the platform-specific socket structs. Please do not do this.
>
> James
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>