views:

704

answers:

4

There has been a lot of press about IPv6 and the impending switch over to IPv6 from IPv4. I have some understanding of IPv6, but I've often wondered how much impact IPv6 has on application development & design (specifically)?

Are there some tangible/well known benefits IPv6 provides which we don't already have today?

I know Windows Vista and Server 2008 support IPv6 out-of-the-box, is anyone using (or designing with IPv6 in mind) today, and if so, what are the benefits? Should we be considering IPv6 in current and future projects?

Are there any good examples of IPv6-aware applications?

+3  A: 

Initially not much. The switch from IPv4 to v6 should be transparent for most desktop and web applications.

But eventually applications that use network models that are made easier by IPv6 will become more common. For example most users are behind a NAT so mesh-networks are only feasible for a technical audience. Anyone who has had to open ports on his router for P2P software knows this is not something his mom could use.

Streaming and broadcasting are also things that are made easier by IPv6.

Mendelt
I do like the concept of keeping the same IP address whilst moving between regions (e.g. onboard an aircraft), but as you suggest, it's low level and probably won't be of much use/notice to an application developer.
RobS
+3  A: 

It will impact the UI design for any software where you input an IP address, as you will need to let them select between IPv4 and IPv6 input. Pretty obvious though.

My understanding is that not much else will change. Most programs are using networking facilities provided by the operating system, so by the time data gets back to the application all the addressing and transmission complexities are removed. Of course there are some applications that will be more impacted, but those are going to be the ones that work directly with the network...not your typical line-of-business app.

You need to look at where you application lies in the OSI model. I think IP addresses are part of layer 3, so if you are above that layer, you are abstracted from the changes by the OS.

One thing which may suck is old games where you put in the IP address of a player you want to connect to (Age of Empires, Starcraft, etc.). It seems that barring some sort of IPv4-IPv6 tunneling that that functionality of the game will be broken.

Aaron Axvig
your understanding is incorrect. Applications still have to be able to create sockets, address structures, etc, all of which have IPv6 specific variations.
Alnitak
No, I think that Aaron Axvig's summary is quite fair. Most applications should never manipulate IP addresses directly. The socket interface is a very low-level one: it's like the assembly language. Powerful but very unportable.
bortzmeyer
+1  A: 

All the modern web browsers (Chrome, IE, Safari, and Firefox come to mind) are all IPv6 aware. Also IPv6 aware is µTorrent.

Brian Knoblauch
+3  A: 

Aaron's reply is, I'm afraid, pretty much incorrect. Yes, UI changes will be necessary, but any code using the traditional socket APIs is also likely to need substantial changes to support IPv6.

Most older code uses a specific "address family" constant (AF_INET) and a particular data structure (struct sockaddr_in). Any code still using that is effectively stuck in IPv4 land.

Newer code should use modern API calls such as getaddrinfo() which is capable of returning the right values for protocol, address family (i.e. AF_INET6), address, etc, regardless of whether the remote host uses IPv4 or IPv6 (or both).

It's a bit lengthy, but here's a code sample from the Linux man page for getaddrinfo. Note how the call gets a whole list of potential remote addresses, and tries each in turn until it succeeds:

         memset(&hints, 0, sizeof(struct addrinfo));
         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(hostname, service, &hints, &result);
         if (s != 0) {
             fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s));
             exit(EXIT_FAILURE);
         }

         /* getaddrinfo() returns a list of address structures.
            Try each address until we successfully connect(2).
            If socket(2) (or connect(2)) fails, we (close the socket
            and) try the next address. */

         for (rp = result; rp != NULL; rp = rp->ai_next) {
             sfd = socket(rp->ai_family, rp->ai_socktype,
                          rp->ai_protocol);
             if (sfd == -1)
                 continue;

             if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1)
                 break;                  /* Success */

             close(sfd);
         }

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

         freeaddrinfo(result);           /* No longer needed */
Alnitak
I would not say he is incorrect but rather that he describes what should be the state of applications. Unfortunately, most applications use low-level stuff like the sockets API but they should not. And using AF_INET is certainly a big mistake: fire the programmer!
bortzmeyer