Authors of the new API realised it was not sufficient to treat IPv6 as just another protocol family supported by the socket API. First, since most application and services are common to IPv4 and IPv6,the new API must not break their smooth operation. And second, because of the infamous chickenand-egg problem (and general laziness of programmers), the amount of work needed for including IPv6 support in applications must be minimal. Therefore, the following goals have been explicitly set for the new API design:

1. All changes must retain binary and source compatibility with existing programs. In other words, on systems with upgraded libraries that include support for the new API, old binary programs work as before. And also, programs written for the old API can be compiled and run unmodified on systems with the new API.

2. The changes in the API must be as small as possible and in line with the traditional socket programming methods.

3. Where possible and appropriate, applications written for the new API should be able to communicate using both IPv6 and IPv4.

Does it mean that with the new API migration of applications to IPv6 becomes a trivial exercise?Unfortunately, not necessarily. Quite a number of applications, including popular ones, employ certain programming techniques and assumptions that make their conversion to IPv6 difficult. For example, they

• work internally with IPv4 addresses (for host identification etc.), or
• expect every network interface to have just a single IP address, or
• assume IP addresses to be 32 bits long.

On the other hand, IPv4 applications that are free of these flaws can usually be converted with minimum effort. In fact, there are even tools doing this automatically.