IPv6 Support for the networking lib

[StormWingDelta]

Just wondering since I didn't see anything to do with IPv6 in there.  Might be useful for later but not really needed.  I know full well we'd need to either add onto the existing IP Address class or make another for IPv6.  It'd likely be easier to just add the ipv6 format to the existing list of formats that can be used but who knows.


I know right now it isn't needed but it might a nice addition for those types that like to get cut by the edge they are at.

[Sandburg]

I’d like to propose an implementation of IPv6 for SFML. As yet, nobody makes any pull request, therefore I wish to.

I hope to have returns on this forum. Only after, I’ll make the pull request, as suggested by Laurent Gomila.

State of the art
Actually, SFML (v. 2.3 rev.746bb9c et previous) doesn’t support IPv6. It means the type sf::IpAddress and dependencies are implemented around IPv4 only.

Right now on GitHub there is only 1 report on this subject, classed as rejected:
https://github.com/SFML/SFML/issues/307

Affected components:

• SFML/Network/IpAddress.hpp
• SFML/Network/Socket.hpp
• SFML/Network/TcpSocket.hpp
• SFML/Network/SocketImpl.hpp
     static sockaddr_in createAddress(Uint32 address, unsigned short port);
• SFML/Network/Unix/SocketImpl .hpp
     sockaddr_in SocketImpl::createAddress(Uint32 address, unsigned short port)
• SFML/Network/Win32/SocketImpl .hpp
     sockaddr_in SocketImpl::createAddress(Uint32 address, unsigned short port)

Several implementation possibilities:
split v4 and v6 → YES

• multiple inheritance
  sf::IpAddress ―> sf::IpAddressV4
  sf::IpAddress ―> sf::IpAddressV6
• a composition
  sf::IpAddress ◄►― sf::IpAddressV4
  sf::IpAddress ◄►― sf::IpAddressV6
• dynamic type (but it is still a composition, careful of RAII)
• a union
  A union type which can store either v4 or v6. Not sure the memory space gain is relevant (almost insignificant) compared to the errors it could cause. But maybe.

Tip: We don’t know which kind of storage structure we need before parsing the given address. So it will always be a treatment in 2 times.

To help judging this different approaches, I have listed the implementations in several notorious libraries:

• Boost
  boost::asio::ip::address
     v4 & v6 exist as independent types and are merged in the ip::address type by a composition.
• C++ Standard Library
  std::ip::address (the proposal of Christopher Kohlhoff for C++17 TR2, rejected yet)
     same as in Boost, composition, so 2in1.
• WxWidget
  wxIPaddress ―> wxSockAddress
     2in1 through an union but then, this class wxIPaddress is specialized to make specific v6 or v4 daughters. Well, it looks like a nasty mess.
• Qt (v5)
  QHostAddress
     2in1 like Boost. But with their own implementation approach (many test to make it backward compatible).

As first shot, I choose a composition with member values like in boost::asio (or the next std::ip).

Use case. How the developer has to use sf::IpAddress?
One unique component sf::IpAddress for the user. Two specific classes for v4 and v6 (priv or not?). sf::IpAddress is a generalisation of v4 plus v6.
When using sf::IpAddress, the dev must interest in the type of address he manages… in some cases like sockets.

Fix
In the current version, testing if an address in localhost (to make loopback redirections) is on user’s responsibility. Something like:
if ( my_address == sf::IpAddress::LocalHost )
But it doesn’t respect the IANA normalisation. IPv4 localhost has the form 127.0.0.1/8, which means addresses from 127.0.0.1 to 127.255.255.255 (/8 means 8 significant bits).
So, if we fix that, the test can’t be user side any more. We need a method isLocalHost().
On another side IPv6 has only one localhost address ::0.

Naming this method localhost or loopback?
« localhost » is a set of addresses. « loopback » is the consequence on path taken. This 2 words are some times interchangeable. However if we only check addresses and not network reality, it’s better to name it localhost, technically.

Extension
Other domain addresses exist like the Unix type AF_UNIX (which is not ip like AF_INET and AF_INET6). There is also AF_IPX and AF_AX25 (Novell and radio) but very rare.
Unix type is somehow popular. Do we restrict to ip like now?

Also watch
Christopher Kohlhoff IPv6 ready: https://youtu.be/bsoR5m-036U?t=10m10s (I put it at the time he speaks of implementation).
Previous discussion in French on
http://fr.sfml-dev.org/forums/index.php?topic=8782.msg151009#msg151009

PS: the mentioned libs are under their own license

[binary1248]

I (and I'm assuming others) prefer keeping things simple whenever they can. If you look at sf::IpAddress in its current state, it can't do much really. However, what is important is that it can do enough to guide packets to their intended destination on the other end of the internet.

You mentioned a lot of things that one has to consider when implementing a feature complete IP address implementation, they are all correct, however many of them are of no practical use to your typical SFML application. You mention that technically, one would have to check against 127.0.0.0/8 (not 127.0.0.1/8 this doesn't make much sense) to determine whether an address is a loopback address. Yes, this is true, however, how many times have you actually seen e.g. 127.0.0.2 being used? I can think of a few legitimate cases where one might need such addresses, such as having 2 instances of a webserver run local only and for whatever reason not being able to change the port number. These are really rare edge cases, and SFML was and will never be designed to solve all of them. The effort involved in implementing real CIDR support is not worth it considering the effect it would have on the day to day usage of SFML as a library. If you are writing a high performance web server or firewall or whatever, you should probably use another library anyway.

How IPv6 address support is implemented internally is a detail that can be discussed at a later point. While also important, it is not as important as the public interface changes that have to be made to the class. I personally prefer this change to be isolated to the sf::IpAddress class, meaning it would have to simultaneously support both v4 and v6 addresses through its public facing API. This way, other networking classes don't have to care too much about the address type in their own implementations and we can preserve the loose coupling that is currently the case.

If I were to add IPv6 support to SFML, I would simply extend the current sf::IpAddress interface with the v6 versions of each method (where applicable of course). getLocalAddress and getPublicAddress would have to be extended with the ability to pick the address type and the static const values should more or less retain their "meaning" while differentiating into a specific address type when the time comes.

The only way to efficiently go along with implementing this is to simply start somewhere and keep going until you cover 99% of the use cases. There are things SFML supports, because not supporting them would be too crippling and annoying, and there are things SFML will not support, because at the end of the day it is a general purpose amalgamation of a library that aims to keep things simple when possible while providing the most flexibility when it is needed.