RFC 2133 (rfc2133) - Page 3 of 32

Basic Socket Interface Extensions for IPv6

RFC 2133            IPv6 Socket Interface Extensions          April 1997


2.  Design Considerations

   There are a number of important considerations in designing changes
   to this well-worn API:

   -  The API changes should provide both source and binary
       compatibility for programs written to the original API.  That is,
       existing program binaries should continue to operate when run on
       a system supporting the new API.  In addition, existing
       applications that are re-compiled and run on a system supporting
       the new API should continue to operate.  Simply put, the API
       changes for IPv6 should not break existing programs.

   -  The changes to the API should be as small as possible in order to
       simplify the task of converting existing IPv4 applications to
       IPv6.

   -  Where possible, applications should be able to use this API to
       interoperate with both IPv6 and IPv4 hosts.  Applications should
       not need to know which type of host they are communicating with.

   -  IPv6 addresses carried in data structures should be 64-bit
       aligned.  This is necessary in order to obtain optimum
       performance on 64-bit machine architectures.

   Because of the importance of providing IPv4 compatibility in the API,
   these extensions are explicitly designed to operate on machines that
   provide complete support for both IPv4 and IPv6.  A subset of this
   API could probably be designed for operation on systems that support
   only IPv6.  However, this is not addressed in this memo.

2.1.  What Needs to be Changed

   The socket interface API consists of a few distinct components:

    -  Core socket functions.

    -  Address data structures.

    -  Name-to-address translation functions.

    -  Address conversion functions.

    The core socket functions -- those functions that deal with such
    things as setting up and tearing down TCP connections, and sending
    and receiving UDP packets -- were designed to be transport
    independent.  Where protocol addresses are passed as function
    arguments, they are carried via opaque pointers.  A protocol-specific



Gilligan, et. al.            Informational