rfc3493.txt

bind 9.3结合mysql数据库

   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
   in6addr_xxx externals are defined in network byte order.







Gilligan, et al.             Informational                     [Page 12]

RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003


3.9 IPv6 Loopback Address

   Applications may need to send UDP packets to, or originate TCP
   connections to, services residing on the local node.  In IPv4, they
   can do this by using the constant IPv4 address INADDR_LOOPBACK in
   their connect(), sendto(), or sendmsg() call.

   IPv6 also provides a loopback address to contact local TCP and UDP
   services.  Like the unspecified address, the IPv6 loopback address is
   provided in two forms -- a global variable and a symbolic constant.

   The global variable is an in6_addr structure named
   "in6addr_loopback."  The extern declaration for this variable is
   defined in <netinet/in.h>:

      extern const struct in6_addr in6addr_loopback;

   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
   in IPv4 applications (but beware of the byte ordering difference
   mentioned at the end of the previous section).  For example, to open
   a TCP connection to the local telnet server, an application could use
   the following code:

   struct sockaddr_in6 sin6;
    . . .
   sin6.sin6_family = AF_INET6;
   sin6.sin6_flowinfo = 0;
   sin6.sin6_port = htons(23);
   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
    . . .
   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
           . . .

   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
   in <netinet/in.h>.  It can be used at declaration time ONLY; for
   example:

      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;

   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
   to a previously declared IPv6 address variable.










Gilligan, et al.             Informational                     [Page 13]

RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003


3.10 Portability Additions

   One simple addition to the sockets API that can help application
   writers is the "struct sockaddr_storage".  This data structure can
   simplify writing code that is portable across multiple address
   families and platforms.  This data structure is designed with the
   following goals.

   - Large enough to accommodate all supported protocol-specific address
      structures.

   - Aligned at an appropriate boundary so that pointers to it can be
      cast as pointers to protocol specific address structures and used
      to access the fields of those structures without alignment
      problems.

   The sockaddr_storage structure contains field ss_family which is of
   type sa_family_t.  When a sockaddr_storage structure is cast to a
   sockaddr structure, the ss_family field of the sockaddr_storage
   structure maps onto the sa_family field of the sockaddr structure.
   When a sockaddr_storage structure is cast as a protocol specific
   address structure, the ss_family field maps onto a field of that
   structure that is of type sa_family_t and that identifies the
   protocol's address family.



























Gilligan, et al.             Informational                     [Page 14]

RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003


   An example implementation design of such a data structure would be as
   follows.

/*
 * Desired design of maximum size and alignment
 */
#define _SS_MAXSIZE    128  /* Implementation specific max size */
#define _SS_ALIGNSIZE  (sizeof (int64_t))
                         /* Implementation specific desired alignment */
/*
 * Definitions used for sockaddr_storage structure paddings design.
 */
#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
    sa_family_t  ss_family;     /* address family */
    /* Following fields are implementation specific */
    char      __ss_pad1[_SS_PAD1SIZE];
              /* 6 byte pad, this is to make implementation
              /* specific pad up to alignment field that */
              /* follows explicit in the data structure */
    int64_t   __ss_align;     /* field to force desired structure */
               /* storage alignment */
    char      __ss_pad2[_SS_PAD2SIZE];
              /* 112 byte pad to achieve desired size, */
              /* _SS_MAXSIZE value minus size of ss_family */
              /* __ss_pad1, __ss_align fields is 112 */
};

   The above example implementation illustrates a data structure which
   will align on a 64-bit boundary.  An implementation-specific field
   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
   alignment which covers proper alignment good enough for the needs of
   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
   size of padding field __ss_pad1 depends on the chosen alignment
   boundary.  The size of padding field __ss_pad2 depends on the value
   of overall size chosen for the total size of the structure.  This
   size and alignment are represented in the above example by
   implementation specific (not required) constants _SS_MAXSIZE (chosen
   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
   are also for illustration and not required.  The derived values
   assume sa_family_t is 2 bytes.  The implementation specific
   definitions and structure field names above start with an underscore
   to denote implementation private namespace.  Portable code is not
   expected to access or reference those fields or constants.




Gilligan, et al.             Informational                     [Page 15]

RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003


   On implementations where the sockaddr data structure includes a
   "sa_len" field this data structure would look like this:

/*
 * Definitions used for sockaddr_storage structure paddings design.
 */
#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
                            (sizeof (uint8_t) + sizeof (sa_family_t))
#define _SS_PAD2SIZE (_SS_MAXSIZE -
                            (sizeof (uint8_t) + sizeof (sa_family_t) +
                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
struct sockaddr_storage {
    uint8_t      ss_len;        /* address length */
    sa_family_t  ss_family;     /* address family */
    /* Following fields are implementation specific */
    char         __ss_pad1[_SS_PAD1SIZE];
                  /* 6 byte pad, this is to make implementation
                  /* specific pad up to alignment field that */
                  /* follows explicit in the data structure */
    int64_t      __ss_align;  /* field to force desired structure */
                  /* storage alignment */
    char         __ss_pad2[_SS_PAD2SIZE];
                  /* 112 byte pad to achieve desired size, */
                  /* _SS_MAXSIZE value minus size of ss_len, */
                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
};

4. Interface Identification

   This API uses an interface index (a small positive integer) to
   identify the local interface on which a multicast group is joined
   (Section 5.2).  Additionally, the advanced API [4] uses these same
   interface indexes to identify the interface on which a datagram is
   received, or to specify the interface on which a datagram is to be
   sent.

   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
   and the like.  On Berkeley-derived implementations, when an interface
   is made known to the system, the kernel assigns a unique positive
   integer value (called the interface index) to that interface.  These
   are small positive integers that start at 1.  (Note that 0 is never
   used for an interface index.)  There may be gaps so that there is no
   current interface for a particular positive interface index.

   This API defines two functions that map between an interface name and
   index, a third function that returns all the interface names and
   indexes, and a fourth function to return the dynamic memory allocated
   by the previous function.  How these functions are implemented is



Gilligan, et al.             Informational                     [Page 16]

RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003


   left up to the implementation.  4.4BSD implementations can implement
   these functions using the existing sysctl() function with the
   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
   for this purpose.

4.1 Name-to-Index

   The first function maps an interface name into its corresponding
   index.

      #include <net/if.h>

      unsigned int  if_nametoindex(const char *ifname);

   If ifname is the name of an interface, the if_nametoindex() function
   shall return the interface index corresponding to name ifname;
   otherwise, it shall return zero.  No errors are defined.

4.2 Index-to-Name

   The second function maps an interface index into its corresponding
   name.

      #include <net/if.h>

      char  *if_indextoname(unsigned int ifindex, char *ifname);

   When this function is called, the ifname argument shall point to a
   buffer of at least IF_NAMESIZE bytes.  The function shall place in
   this buffer the name of the interface with index ifindex.
   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
   terminating null byte at the end of the interface name.)  If ifindex
   is an interface index, then the function shall return the value
   supplied in ifname, which points to a buffer now containing the
   interface name.  Otherwise, the function shall return a NULL pointer
   and set errno to indicate the error.  If there is no interface
   corresponding to the specified index, errno is set to ENXIO.  If
   there was a system error (such as running out of memory), errno would
   be set to the proper value (e.g., ENOMEM).












Gilligan, et al.             Informational                     [Page 17]

RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003


4.3 Return All Interface Names and Indexes

   The if_nameindex structure holds the information about a single
   interface and is defined as a result of including the <net/if.h>
   header.

   struct if_nameindex {
     unsigned int   if_index;  /* 1, 2, ... */
     char          *if_name;   /* null terminated name: "le0", ... */
   };

   The final function returns an array of if_nameindex structures, one
   structure per interface.

      #include <net/if.h>

      struct if_nameindex  *if_nameindex(void);

   The end of the array of structures is indicated by a structure with
   an if_index of 0 and an if_name of NULL.  The function returns a NULL
   pointer upon an error, and would set errno to the appropriate value.

   The memory used for this array of structures along with the interface
   names pointed to by the if_name members is obtained dynamically.
   This memory is freed by the next function.

4.4 Free Memory

   The following function frees the dynamic memory that was allocated by
   if_nameindex().

      #include <net/if.h>

      void  if_freenameindex(struct if_nameindex *ptr);

   The ptr argument shall be a pointer that was returned by
   if_nameindex().  After if_freenameindex() has been called, the
   application shall not use the array of which ptr is the address.