rfc2133.txt

bind-3.2.

Network Working Group                                        R. Gilligan
Request for Comments: 2133                                      Freegate
Category: Informational                                       S. Thomson
                                                                Bellcore
                                                                J. Bound
                                                                 Digital
                                                              W. Stevens
                                                              Consultant
                                                              April 1997

               Basic Socket Interface Extensions for IPv6

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   The de facto standard application program interface (API) for TCP/IP
   applications is the "sockets" interface.  Although this API was
   developed for Unix in the early 1980s it has also been implemented on
   a wide variety of non-Unix systems.  TCP/IP applications written
   using the sockets API have in the past enjoyed a high degree of
   portability and we would like the same portability with IPv6
   applications.  But changes are required to the sockets API to support
   IPv6 and this memo describes these changes.  These include a new
   socket address structure to carry IPv6 addresses, new address
   conversion functions, and some new socket options.  These extensions
   are designed to provide access to the basic IPv6 features required by
   TCP and UDP applications, including multicasting, while introducing a
   minimum of change into the system and providing complete
   compatibility for existing IPv4 applications.  Additional extensions
   for advanced IPv6 features (raw sockets and access to the IPv6
   extension headers) are defined in another document [5].

Table of Contents

   1.  Introduction ................................................  2
   2.  Design Considerations .......................................  3
   2.1.  What Needs to be Changed ..................................  3
   2.2.  Data Types ................................................  5
   2.3.  Headers ...................................................  5
   2.4.  Structures ................................................  5
   3.  Socket Interface ............................................  5
   3.1.  IPv6 Address Family and Protocol Family ...................  5
   3.2.  IPv6 Address Structure ....................................  6



Gilligan, et. al.            Informational                      [Page 1]

RFC 2133            IPv6 Socket Interface Extensions          April 1997


   3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
   3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
   3.5.  The Socket Functions ......................................  8
   3.6.  Compatibility with IPv4 Applications ......................  9
   3.7.  Compatibility with IPv4 Nodes .............................  9
   3.8.  IPv6 Wildcard Address ..................................... 10
   3.9.  IPv6 Loopback Address ..................................... 11
   4.  Interface Identification .................................... 12
   4.1.  Name-to-Index ............................................. 13
   4.2.  Index-to-Name ............................................. 13
   4.3.  Return All Interface Names and Indexes .................... 14
   4.4.  Free Memory ............................................... 14
   5.  Socket Options .............................................. 14
   5.1.  Changing Socket Type ...................................... 15
   5.2.  Unicast Hop Limit ......................................... 16
   5.3.  Sending and Receiving Multicast Packets ................... 17
   6.  Library Functions ........................................... 19
   6.1.  Hostname-to-Address Translation ........................... 19
   6.2.  Address To Hostname Translation ........................... 22
   6.3.  Protocol-Independent Hostname and Service Name Translation  22
   6.4.  Socket Address Structure to Hostname and Service Name ..... 25
   6.5.  Address Conversion Functions .............................. 27
   6.6.  Address Testing Macros .................................... 28
   7.  Summary of New Definitions .................................. 29
   8.  Security Considerations ..................................... 31
   9.  Acknowledgments ............................................. 31
   10.  References ................................................. 31
   11.  Authors' Addresses ......................................... 32

1.  Introduction

   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
   by 128-bit addresses.  The socket interface make the size of an IP
   address quite visible to an application; virtually all TCP/IP
   applications for BSD-based systems have knowledge of the size of an
   IP address.  Those parts of the API that expose the addresses must be
   changed to accommodate the larger IPv6 address size.  IPv6 also
   introduces new features (e.g., flow label and priority), some of
   which must be made visible to applications via the API.  This memo
   defines a set of extensions to the socket interface to support the
   larger address size and new features of IPv6.










Gilligan, et. al.            Informational                      [Page 2]

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                      [Page 3]

RFC 2133            IPv6 Socket Interface Extensions          April 1997


    address data structure is defined for each protocol that the socket
    functions support.  Applications must cast pointers to these
    protocol-specific address structures into pointers to the generic
    "sockaddr" address structure when using the socket functions.  These
    functions need not change for IPv6, but a new IPv6-specific address
    data structure is needed.

    The "sockaddr_in" structure is the protocol-specific data structure
    for IPv4.  This data structure actually includes 8-octets of unused
    space, and it is tempting to try to use this space to adapt the
    sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
    structure is not large enough to hold the 16-octet IPv6 address as
    well as the other information (address family and port number) that
    is needed.  So a new address data structure must be defined for IPv6.

    The name-to-address translation functions in the socket interface are
    gethostbyname() and gethostbyaddr().  These must be modified to
    support IPv6 and the semantics defined must provide 100% backward
    compatibility for all existing IPv4 applications, along with IPv6
    support for new applications.  Additionally, the POSIX 1003.g work in
    progress [4] specifies a new hostname-to-address translation function
    which is protocol independent.  This function can also be used with
    IPv6.

    The address conversion functions -- inet_ntoa() and inet_addr() --
    convert IPv4 addresses between binary and printable form.  These
    functions are quite specific to 32-bit IPv4 addresses.  We have
    designed two analogous functions that convert both IPv4 and IPv6
    addresses, and carry an address type parameter so that they can be
    extended to other protocol families as well.

    Finally, a few miscellaneous features are needed to support IPv6.
    New interfaces are needed to support the IPv6 flow label, priority,
    and hop limit header fields.  New socket options are needed to
    control the sending and receiving of IPv6 multicast packets.

    The socket interface will be enhanced in the future to provide access
    to other IPv6 features.  These extensions are described in [5].













Gilligan, et. al.            Informational                      [Page 4]

RFC 2133            IPv6 Socket Interface Extensions          April 1997


2.2.  Data Types

   The data types of the structure elements given in this memo are
   intended to be examples, not absolute requirements.  Whenever
   possible, POSIX 1003.1g data types are used:  u_intN_t means an
   unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
   means an unsigned integer of at least N bits (e.g., u_int32m_t).  We
   also assume the argument data types from 1003.1g when possible (e.g.,
    the final argument to setsockopt() is a size_t value).  Whenever
   buffer sizes are specified, the POSIX 1003.1 size_t data type is used
   (e.g., the two length arguments to getnameinfo()).

2.3.  Headers

   When function prototypes and structures are shown we show the headers
   that must be #included to cause that item to be defined.

2.4.  Structures

   When structures are described the members shown are the ones that
   must appear in an implementation.  Additional, nonstandard members
   may also be defined by an implementation.

   The ordering shown for the members of a structure is the recommended
   ordering, given alignment considerations of multibyte members, but an
   implementation may order the members differently.

3.  Socket Interface

   This section specifies the socket interface changes for IPv6.

3.1.  IPv6 Address Family and Protocol Family

   A new address family name, AF_INET6, is defined in <sys/socket.h>.
   The AF_INET6 definition distinguishes between the original
   sockaddr_in address data structure, and the new sockaddr_in6 data
   structure.

   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
   Like most of the other protocol family names, this will usually be
   defined to have the same value as the corresponding address family
   name:

       #define PF_INET6        AF_INET6

   The PF_INET6 is used in the first argument to the socket() function
   to indicate that an IPv6 socket is being created.




Gilligan, et. al.            Informational                      [Page 5]

RFC 2133            IPv6 Socket Interface Extensions          April 1997


3.2.  IPv6 Address Structure

   A new data structure to hold a single IPv6 address is defined as
    follows:

       #include <netinet/in.h>

       struct in6_addr {
           u_int8_t  s6_addr[16];      /* IPv6 address */
       }

   This data structure contains an array of sixteen 8-bit elements,
   which make up one 128-bit IPv6 address.  The IPv6 address is stored
   in network byte order.

3.3.  Socket Address Structure for 4.3BSD-Based Systems

   In the socket interface, a different protocol-specific data structure
   is defined to carry the addresses for each protocol suite.  Each
   protocol-specific data structure is designed so it can be cast into a
   protocol-independent data structure -- the "sockaddr" structure.
   Each has a "family" field that overlays the "sa_family" of the
   sockaddr data structure.  This field identifies the type of the data
   structure.

   The sockaddr_in structure is the protocol-specific address data
   structure for IPv4.  It is used to pass addresses between
   applications and the system in the socket functions.  The following
   structure is defined to carry IPv6 addresses:

       #include <netinet/in.h>

       struct sockaddr_in6 {
           u_int16m_t      sin6_family;    /* AF_INET6 */
           u_int16m_t      sin6_port;      /* transport layer port # */
           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
           struct in6_addr sin6_addr;      /* IPv6 address */
       };

   This structure is designed to be compatible with the sockaddr data
   structure used in the 4.3BSD release.

   The sin6_family field identifies this as a sockaddr_in6 structure.
   This field overlays the sa_family field when the buffer is cast to a
   sockaddr data structure.  The value of this field must be AF_INET6.