rfc3493.txt

bind 9.3结合mysql数据库

5. Socket Options

   A number of new socket options are defined for IPv6.  All of these
   new options are at the IPPROTO_IPV6 level.  That is, the "level"
   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
   when using these options.  The constant name prefix IPV6_ is used in
   all of the new socket options.  This serves to clearly identify these
   options as applying to IPv6.




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


   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
   related constants defined in this section are obtained by including
   the header <netinet/in.h>.

5.1 Unicast Hop Limit

   A new setsockopt() option controls the hop limit used in outgoing
   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
   and it is used at the IPPROTO_IPV6 layer.  The following example
   illustrates how it is used:

   int  hoplimit = 10;

   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
       perror("setsockopt IPV6_UNICAST_HOPS");

   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
   option value given is used as the hop limit for all subsequent
   unicast packets sent via that socket.  If the option is not set, the
   system selects a default value.  The integer hop limit value (called
   x) is interpreted as follows:

      x < -1:        return an error of EINVAL
      x == -1:       use kernel default
      0 <= x <= 255: use x
      x >= 256:      return an error of EINVAL

   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
   determine the hop limit value that the system will use for subsequent
   unicast packets sent via that socket.  For example:

      int  hoplimit;
      socklen_t  len = sizeof(hoplimit);

      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
                     (char *) &hoplimit, &len) == -1)
          perror("getsockopt IPV6_UNICAST_HOPS");
      else
          printf("Using %d for hop limit.\n", hoplimit);

5.2 Sending and Receiving Multicast Packets

   IPv6 applications may send multicast packets by simply specifying an
   IPv6 multicast address as the destination address, for example in the
   destination address argument of the sendto() function.





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


   Three socket options at the IPPROTO_IPV6 layer control some of the
   parameters for sending multicast packets.  Setting these options is
   not required: applications may send multicast packets without using
   these options.  The setsockopt() options for controlling the sending
   of multicast packets are summarized below.  These three options can
   also be used with getsockopt().

      IPV6_MULTICAST_IF

         Set the interface to use for outgoing multicast packets.  The
         argument is the index of the interface to use.  If the
         interface index is specified as zero, the system selects the
         interface (for example, by looking up the address in a routing
         table and using the resulting interface).

         Argument type: unsigned int

      IPV6_MULTICAST_HOPS

         Set the hop limit to use for outgoing multicast packets.  (Note
         a separate option - IPV6_UNICAST_HOPS - is provided to set the
         hop limit to use for outgoing unicast packets.)

         The interpretation of the argument is the same as for the
         IPV6_UNICAST_HOPS option:

            x < -1:        return an error of EINVAL
            x == -1:       use kernel default
            0 <= x <= 255: use x
            x >= 256:      return an error of EINVAL

            If IPV6_MULTICAST_HOPS is not set, the default is 1
            (same as IPv4 today)

         Argument type: int

      IPV6_MULTICAST_LOOP

         If a multicast datagram is sent to a group to which the sending
         host itself belongs (on the outgoing interface), a copy of the
         datagram is looped back by the IP layer for local delivery if
         this option is set to 1.  If this option is set to 0 a copy is
         not looped back.  Other option values return an error of
         EINVAL.







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


         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
         same as IPv4 today).

         Argument type: unsigned int

   The reception of multicast packets is controlled by the two
   setsockopt() options summarized below.  An error of EOPNOTSUPP is
   returned if these two options are used with getsockopt().

      IPV6_JOIN_GROUP

         Join a multicast group on a specified local interface.
         If the interface index is specified as 0,
         the kernel chooses the local interface.
         For example, some kernels look up the multicast group
         in the normal IPv6 routing table and use the resulting
         interface.

         Argument type: struct ipv6_mreq

      IPV6_LEAVE_GROUP

         Leave a multicast group on a specified interface.
         If the interface index is specified as 0, the system
         may choose a multicast group membership to drop by
         matching the multicast address only.

         Argument type: struct ipv6_mreq

   The argument type of both of these options is the ipv6_mreq
   structure, defined as a result of including the <netinet/in.h>
   header;

   struct ipv6_mreq {
       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
       unsigned int    ipv6mr_interface; /* interface index */
   };

   Note that to receive multicast datagrams a process must join the
   multicast group to which datagrams will be sent.  UDP applications
   must also bind the UDP port to which datagrams will be sent.  Some
   processes also bind the multicast group address to the socket, in
   addition to the port, to prevent other datagrams destined to that
   same port from being delivered to the socket.







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


5.3 IPV6_V6ONLY option for AF_INET6 Sockets

   This socket option restricts AF_INET6 sockets to IPv6 communications
   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
   Some applications may want to restrict their use of an AF_INET6
   socket to IPv6 communications only.  For these applications the
   IPV6_V6ONLY socket option is defined.  When this option is turned on,
   the socket can be used to send and receive IPv6 packets only.  This
   is an IPPROTO_IPV6 level option.  This option takes an int value.
   This is a boolean option.  By default this option is turned off.

   Here is an example of setting this option:

      int on = 1;

      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
                     (char *)&on, sizeof(on)) == -1)
          perror("setsockopt IPV6_V6ONLY");
      else
          printf("IPV6_V6ONLY set\n");

   Note - This option has no effect on the use of IPv4 Mapped addresses
   which enter a node as a valid IPv6 addresses for IPv6 communications
   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].

   An example use of this option is to allow two versions of the same
   server process to run on the same port, one providing service over
   IPv6, the other providing the same service over IPv4.

6. Library Functions

   New library functions are needed to perform a variety of operations
   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
   address translation) and reverse lookup (address-to-nodename
   translation) need to be supported.  Functions are also needed to
   convert IPv6 addresses between their binary and textual form.

   We note that the two existing functions, gethostbyname() and
   gethostbyaddr(), are left as-is.  New functions are defined to handle
   both IPv4 and IPv6 addresses.

   The commonly used function gethostbyname() is inadequate for many
   applications, first because it provides no way for the caller to
   specify anything about the types of addresses desired (IPv4 only,
   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
   implementations of this function are not thread safe.  RFC 2133



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


   defined a function named gethostbyname2() but this function was also
   inadequate, first because its use required setting a global option
   (RES_USE_INET6) when IPv6 addresses were required, and second because
   a flag argument is needed to provide the caller with additional
   control over the types of addresses required.  The gethostbyname2()
   function was deprecated in RFC 2553 and is no longer part of the
   basic API.

6.1 Protocol-Independent Nodename and Service Name Translation

   Nodename-to-address translation is done in a protocol-independent
   fashion using the getaddrinfo() function.

#include <sys/socket.h>
#include <netdb.h>


int getaddrinfo(const char *nodename, const char *servname,
                const struct addrinfo *hints, struct addrinfo **res);

void freeaddrinfo(struct addrinfo *ai);

struct addrinfo {
  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
                           AI_NUMERICHOST, .. */
  int     ai_family;    /* AF_xxx */
  int     ai_socktype;  /* SOCK_xxx */
  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
  socklen_t  ai_addrlen;   /* length of ai_addr */
  char   *ai_canonname; /* canonical name for nodename */
  struct sockaddr  *ai_addr; /* binary address */
  struct addrinfo  *ai_next; /* next structure in linked list */
};

   The getaddrinfo() function translates the name of a service location
   (for example, a host name) and/or a service name and returns a set of
   socket addresses and associated information to be used in creating a
   socket with which to address the specified service.

   The nodename and servname arguments are either null pointers or
   pointers to null-terminated strings.  One or both of these two
   arguments must be a non-null pointer.

   The format of a valid name depends on the address family or families.
   If a specific family is not given and the name could be interpreted
   as valid within multiple supported families, the implementation will
   attempt to resolve the name in all supported families and, in absence
   of errors, one or more results shall be returned.



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


   If the nodename argument is not null, it can be a descriptive name or
   can be an address string.  If the specified address family is
   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
   names. If the specified address family is AF_INET or AF_UNSPEC,
   address strings using Internet standard dot notation as specified in
   inet_addr() are valid.  If the specified address family is AF_INET6
   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
   valid.

   If nodename is not null, the requested service location is named by
   nodename; otherwise, the requested service location is local to the
   caller.

   If servname is null, the call shall return network-level addresses
   for the specified nodename.  If servname is not null, it is a null-
   terminated character string identifying the requested service.  This
   can be either a descriptive name or a numeric representation suitable
   for use with the address family or families.  If the specified
   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
   specified as a string specifying a decimal port number.

   If the argument hints is not null, it refers to a structure
   containing input values that may direct the operation by providing
   options and by limiting the returned information to a specific socket
   type, address family and/or protocol.  In this hints structure every
   member other than ai_flags, ai_family, ai_socktype and ai_protocol
   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
   ai_family means that the caller shall accept any address family.  A
   value of zero for ai_socktype means that the caller shall accept any
   socket type.  A value of zero for ai_protocol means that the caller
   shall accept any protocol.  If hints is a null pointer, the behavior
   shall be as if it referred to a structure containing the value zero
   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
   for the ai_family field.