rfc2553.txt

Basic Socket Interface Extensions for IPv6

Network Working Group                                        R. Gilligan
Request for Comments: 2553                                      FreeGate
Obsoletes: 2133                                               S. Thomson
Category: Informational                                         Bellcore
                                                                J. Bound
                                                                  Compaq
                                                              W. Stevens
                                                              Consultant
                                                              March 1999


               Basic Socket Interface Extensions for IPv6

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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 [4].










Gilligan, et. al.            Informational                      [Page 1]

RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999


Table of Contents

   1. Introduction.................................................3
   2. Design Considerations........................................3
   2.1 What Needs to be Changed....................................4
   2.2 Data Types..................................................5
   2.3 Headers.....................................................5
   2.4 Structures..................................................5
   3. Socket Interface.............................................6
   3.1 IPv6 Address Family and Protocol Family.....................6
   3.2 IPv6 Address Structure......................................6
   3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
   3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
   3.5 The Socket Functions........................................9
   3.6 Compatibility with IPv4 Applications.......................10
   3.7 Compatibility with IPv4 Nodes..............................10
   3.8 IPv6 Wildcard Address......................................11
   3.9 IPv6 Loopback Address......................................12
   3.10 Portability Additions.....................................13
   4. Interface Identification....................................16
   4.1 Name-to-Index..............................................16
   4.2 Index-to-Name..............................................17
   4.3 Return All Interface Names and Indexes.....................17
   4.4 Free Memory................................................18
   5. Socket Options..............................................18
   5.1 Unicast Hop Limit..........................................18
   5.2 Sending and Receiving Multicast Packets....................19
   6. Library Functions...........................................21
   6.1 Nodename-to-Address Translation............................21
   6.2 Address-To-Nodename Translation............................24
   6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
   6.4 Protocol-Independent Nodename and Service Name Translation.26
   6.5 Socket Address Structure to Nodename and Service Name......29
   6.6 Address Conversion Functions...............................31
   6.7 Address Testing Macros.....................................32
   7. Summary of New Definitions..................................33
   8. Security Considerations.....................................35
   9. Year 2000 Considerations....................................35
   Changes From RFC 2133..........................................35
   Acknowledgments................................................38
   References.....................................................39
   Authors' Addresses.............................................40
   Full Copyright Statement.......................................41








Gilligan, et. al.            Informational                      [Page 2]

RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999


1. Introduction

   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
   by 128-bit addresses.  The socket interface makes 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., traffic class and flowlabel), 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.

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.  An
        additonal mechanism for implementations to verify this is to
        verify the new symbols are protected by Feature Test Macros as
        described in IEEE Std 1003.1.  (Such Feature Test Macros are not
        defined by this RFC.)

      - 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.




Gilligan, et. al.            Informational                      [Page 3]

RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999


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
   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.

   IPv6 addresses are scoped [2] so they could be link-local, site,
   organization, global, or other scopes at this time undefined.  To
   support applications that want to be able to identify a set of
   interfaces for a specific scope, the IPv6 sockaddr_in structure must
   support a field that can be used by an implementation to identify a
   set of interfaces identifying the scope for an IPv6 address.

   The name-to-address translation functions in the socket interface are
   gethostbyname() and gethostbyaddr().  These are left as is and new
   functions are defined to support IPv4 and IPv6.  Additionally, the
   POSIX 1003.g draft [3] specifies a new nodename-to-address
   translation function which is protocol independent.  This function
   can also be used with IPv4 and IPv6.






Gilligan, et. al.            Informational                      [Page 4]

RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999


   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 traffic class, flow
   label, 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 [4].

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, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
   used: uintN_t means an unsigned integer of exactly N bits (e.g.,
   uint16_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.  As an additional
   precaution nonstandard members could be verified by Feature Test
   Macros as described in IEEE Std 1003.1.  (Such Feature Test Macros
   are not defined by this RFC.)

   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.








Gilligan, et. al.            Informational                      [Page 5]

RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999


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.

3.2 IPv6 Address Structure

   A new in6_addr structure holds a single IPv6 address and is defined
   as a result of including <netinet/in.h>:

      struct in6_addr {
          uint8_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.

   The structure in6_addr above is usually implemented with an embedded
   union with extra fields that force the desired alignment level in a
   manner similar to BSD implementations of "struct in_addr". Those
   additional implementation details are omitted here for simplicity.

   An example is as follows: