RFC2553 - Basic Socket Interface Extensions for IPv6(2)

时间:2005-02-16 来源: 作者: 点击:
that was passed as an argument to this function. All four steps listed are performed, in order. Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- compatible addresses,
  
that was passed as an argument to this function.

All four steps listed are performed, in order. Also note that the
IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
be returned and a query of the address not performed.

Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
false for "::" and "::1".

6.3 Freeing memory for getipnodebyname and getipnodebyaddr

The hostent structure does not change from its existing definition.
This structure, and the information pointed to by this structure, are
dynamically allocated by getipnodebyname and getipnodebyaddr. The
following function frees this memory:

#include <netdb.h>

void freehostent(struct hostent *ptr);

6.4 Protocol-Independent Nodename and Service Name Translation

Nodename-to-address translation is done in a protocol-independent
fashion using the getaddrinfo() function that is taken from the
Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
(Protocol Independent Interfaces) draft specification [3].

The official specification for this function will be the final POSIX
standard, with the following additional requirements:

- getaddrinfo() (along with the getnameinfo() function described
in the next section) must be thread safe.

- The AI_NUMERICHOST is new with this document.

- All fields in socket address structures returned by
getaddrinfo() that are not filled in through an explicit
argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
(This makes it easier to compare socket address structures.)

- getaddrinfo() must fill in the length field of a socket address
structure (e.g., sin6_len) on systems that support this field.

We are providing this independent description of the function because
POSIX standards are not freely available (as are IETF documents).

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

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

The addrinfo structure is defined as a result of including the
<netdb.h> header.

struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
int ai_family; /* PF_xxx */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_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 return value from the function is 0 upon success or a nonzero
error code. The following names are the nonzero error codes from
getaddrinfo(), and are defined in <netdb.h>:

EAI_ADDRFAMILY address family for nodename not supported
EAI_AGAIN temporary failure in name resolution
EAI_BADFLAGS invalid value for ai_flags
EAI_FAIL non-recoverable failure in name resolution
EAI_FAMILY ai_family not supported
EAI_MEMORY memory allocation failure
EAI_NODATA no address associated with nodename
EAI_NONAME nodename nor servname provided, or not known
EAI_SERVICE servname not supported for ai_socktype
EAI_SOCKTYPE ai_socktype not supported
EAI_SYSTEM system error returned in errno

The nodename and servname arguments are pointers to null-terminated
strings or NULL. One or both of these two arguments must be a non-
NULL pointer. In the normal client scenario, both the nodename and
servname are specified. In the normal server scenario, only the
servname is specified. A non-NULL nodename string can be either a
node name or a numeric host address string (i.e., a dotted-decimal
IPv4 address or an IPv6 hex address). A non-NULL servname string can
be either a service name or a decimal port number.

The caller can optionally pass an addrinfo structure, pointed to by
the third argument, to provide hints concerning the type of socket
that the caller supports. In this hints structure all members other
than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
or a NULL pointer. A value of PF_UNSPEC for ai_family means the

caller will accept any protocol family. A value of 0 for ai_socktype
means the caller will accept any socket type. A value of 0 for
ai_protocol means the caller will accept any protocol. For example,
if the caller handles only TCP and not UDP, then the ai_socktype
member of the hints structure should be set to SOCK_STREAM when
getaddrinfo() is called. If the caller handles only IPv4 and not
IPv6, then the ai_family member of the hints structure should be set
to PF_INET when getaddrinfo() is called. If the third argument to
getaddrinfo() is a NULL pointer, this is the same as if the caller
had filled in an addrinfo structure initialized to zero with
ai_family set to PF_UNSPEC.

Upon successful return a pointer to a linked list of one or more
addrinfo structures is returned through the final argument. The
caller can process each addrinfo structure in this list by following
the ai_next pointer, until a NULL pointer is encountered. In each
returned addrinfo structure the three members ai_family, ai_socktype,
and ai_protocol are the corresponding arguments for a call to the
socket() function. In each addrinfo structure the ai_addr member
points to a filled-in socket address structure whose length is
specified by the ai_addrlen member.

If the AI_PASSIVE bit is set in the ai_flags member of the hints
structure, then the caller plans to use the returned socket address
structure in a call to bind(). In this case, if the nodename
argument is a NULL pointer, then the IP address portion of the socket
address structure will be set to INADDR_ANY for an IPv4 address or
IN6ADDR_ANY_INIT for an IPv6 address.

If the AI_PASSIVE bit is not set in the ai_flags member of the hints
structure, then the returned socket address structure will be ready
for a call to connect() (for a connection-oriented protocol) or
either connect(), sendto(), or sendmsg() (for a connectionless
protocol). In this case, if the nodename argument is a NULL pointer,
then the IP address portion of the socket address structure will be
set to the loopback address.

If the AI_CANONNAME bit is set in the ai_flags member of the hints
structure, then upon successful return the ai_canonname member of the
first addrinfo structure in the linked list will point to a null-
terminated string containing the canonical name of the specified
nodename.

If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
structure, then a non-NULL nodename string must be a numeric host
address string. Otherwise an error of EAI_NONAME is returned. This
flag prevents any type of name resolution service (e.g., the DNS)
from being called.

All of the information returned by getaddrinfo() is dynamically
allocated: the addrinfo structures, and the socket address structures
and canonical node name strings pointed to by the addrinfo
structures. To return this information to the system the function
freeaddrinfo() is called:

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

void freeaddrinfo(struct addrinfo *ai);

The addrinfo structure pointed to by the ai argument is freed, along
with any dynamic storage pointed to by the structure. This operation
is repeated until a NULL ai_next pointer is encountered.

To aid applications in printing error messages based on the EAI_xxx
codes returned by getaddrinfo(), the following function is defined.

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

char *gai_strerror(int ecode);

The argument is one of the EAI_xxx values defined earlier and the
return value points to a string describing the error. If the
argument is not one of the EAI_xxx values, the function still returns
a pointer to a string whose contents indicate an unknown error.

6.5 Socket Address Structure to Nodename and Service Name

The POSIX 1003.1g specification includes no function to perform the
reverse conversion from getaddrinfo(): to look up a nodename and
service name, given the binary address and port. Therefore, we
define the following function:

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

int getnameinfo(const struct sockaddr *sa, socklen_t salen,
char *host, size_t hostlen,
char *serv, size_t servlen,
int flags);

This function looks up an IP address and port number provided by the
caller in the DNS and system-specific database, and returns text
strings for both in buffers provided by the caller. The function
indicates successful completion by a zero return value; a non-zero
return value indicates failure.

The first argument, sa, points to either a sockaddr_in structure (for
IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
address and port number. The salen argument gives the length of the
sockaddr_in or sockaddr_in6 structure.

The function returns the nodename associated with the IP address in
the buffer pointed to by the host argument. The caller provides the
size of this buffer via the hostlen argument. The service name
associated with the port number is returned in the buffer pointed to
by serv, and the servlen argument gives the length of this buffer.
The caller specifies not to return either string by providing a zero
value for the hostlen or servlen arguments. Otherwise, the caller
must provide buffers large enough to hold the nodename and the
service name, including the terminating null characters.

Unfortunately most systems do not provide constants that specify the
maximum size of either a fully-qualified domain name or a service
name. Therefore to aid the application in allocating buffers for
these two returned strings the following constants are defined in
<netdb.h>:

#define NI_MAXHOST 1025
#define NI_MAXSERV 32

The first value is actually defined as the constant MAXDNAME in recent
versions of BIND's <arpa/nameser.h> header (older versions of BIND
define this constant to be 256) and the second is a guess based on the
services listed in the current Assigned Numbers RFC.

The final argument is a flag that changes the default actions of this
function. By default the fully-qualified domain name (FQDN) for the
host is looked up in the DNS and returned. If the flag bit NI_NOFQDN
is set, only the nodename portion of the FQDN is returned for local
hosts.

If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
located in the DNS, the numeric form of the host's address is returned
instead of its name (e.g., by calling inet_ntop() instead of
getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is
returned if the host's name cannot be located in the DNS.

If the flag bit NI_NUMERICSERV is set, the numeric form of the service
address is returned (e.g., its port number) instead of its name. The
two NI_NUMERICxxx flags are required to support the "-n" flag that
many commands provide.

A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
service, and causes getservbyport() to be called with a second
argument of "udp" instead of its default of "tcp". This is required
for the few ports (e.g. 512-514) that have different services for UDP
and TCP.

These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
flags already defined for getaddrinfo().

6.6 Address Conversion Functions

The two functions inet_addr() and inet_ntoa() convert an IPv4 address
between binary and text form. IPv6 applications need similar
functions. The following two functions convert both IPv6 and IPv4
addresses:

#include <sys/socket.h>
#include <arpa/inet.h>

int inet_pton(int af, const char *src, void *dst);

const char *inet_ntop(int af, const void *src,
char *dst, size_t size);

The inet_pton() function converts an address in its standard text
presentation form into its numeric binary form. The af argument
specifies the family of the address. Currently the AF_INET and
AF_INET6 address families are supported. The src argument points to
the string being passed in. The dst argument points to a buffer into
which the function stores the numeric address. The address is
returned in network byte order. Inet_pton() returns 1 if the
conversion succeeds, 0 if the input is not a valid IPv4 dotted-
decimal string or a valid IPv6 address string, or -1 with errno set
to EAFNOSUPPORT if the af argument is unknown. The calling
application must ensure that the buffer referred to by dst is large
enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
bytes for AF_INET6).

If the af argument is AF_INET, the function accepts a string in the
standard IPv4 dotted-decimal form:

ddd.ddd.ddd.ddd

where ddd is a one to three digit decimal number between 0 and 255.
Note that many implementations of the existing inet_addr() and
inet_aton() functions accept nonstandard input: octal numbers,
hexadecimal numbers, and fewer than four numbers. inet_pton() does
not accept these formats.

If the af argument is AF_INET6, then the function accepts a string in
one of the standard IPv6 text forms defined in Section 2.2 of the
addressing architecture specification [2].

The inet_ntop() function converts a numeric address into a text
string suitable for presentation. The af argument specifies the
family of the address. This can be AF_INET or AF_INET6. The src
argument points to a buffer holding an IPv4 address if the af
argument is AF_INET, or an IPv6 address if the af argument is
AF_INET6, the address must be in network byte order. The dst
argument points to a buffer where the function will store the
resulting text string. The size argument specifies the size of this
buffer. The application must specify a non-NULL dst argument. For
IPv6 addresses, the buffer must be at least 46-octets. For IPv4
addresses, the buffer must be at least 16-octets. In order to allow
applications to easily declare buffers of the proper size to store
IPv4 and IPv6 addresses in string form, the following two constants
are defined in <netinet/in.h>:

#define INET_ADDRSTRLEN 16
#define INET6_ADDRSTRLEN 46

The inet_ntop() function returns a pointer to the buffer containing
the text string if the conversion succeeds, and NULL otherwise. Upon
failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
ENOSPC if the size of the result buffer is inadequate.

6.7 Address Testing Macros

The following macros can be used to test for special IPv6 addresses.

#include <netinet/in.h>

int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);

int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);

The first seven macros return true if the address is of the specified
type, or false otherwise. The last five test the scope of a
multicast address and return true if the address is a multicast
address of the specified scope or false if the address is either not
a multicast address or not of the specified scope. Note that
IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
the two local-use IPv6 unicast addresses. These two macros do not
return true for IPv6 multicast addresses of either link-local scope
or site-local scope.

7. Summary of New Definitions

The following list summarizes the constants, structure, and extern
definitions discussed in this memo, sorted by header.

<net/if.h> IF_NAMESIZE
<net/if.h> struct if_nameindex{};

<netdb.h> AI_ADDRCONFIG
<netdb.h> AI_DEFAULT
<netdb.h> AI_ALL
<netdb.h> AI_CANONNAME
<netdb.h> AI_NUMERICHOST
<netdb.h> AI_PASSIVE
<netdb.h> AI_V4MAPPED
<netdb.h> EAI_ADDRFAMILY
<netdb.h> EAI_AGAIN
<netdb.h> EAI_BADFLAGS
<netdb.h> EAI_FAIL
<netdb.h> EAI_FAMILY
<netdb.h> EAI_MEMORY
<netdb.h> EAI_NODATA
<netdb.h> EAI_NONAME
<netdb.h> EAI_SERVICE
<netdb.h> EAI_SOCKTYPE
<netdb.h> EAI_SYSTEM
<netdb.h> NI_DGRAM
<netdb.h> NI_MAXHOST
<netdb.h> NI_MAXSERV
<netdb.h> NI_NAMEREQD
<netdb.h> NI_NOFQDN
<netdb.h> NI_NUMERICHOST
<netdb.h> NI_NUMERICSERV
<netdb.h> struct addrinfo{};

<netinet/in.h> IN6ADDR_ANY_INIT
<netinet/in.h> IN6ADDR_LOOPBACK_INIT
<netinet/in.h> INET6_ADDRSTRLEN

<netinet/in.h> INET_ADDRSTRLEN
<netinet/in.h> IPPROTO_IPV6
<netinet/in.h> IPV6_JOIN_GROUP
<netinet/in.h> IPV6_LEAVE_GROUP
<netinet/in.h> IPV6_MULTICAST_HOPS
<netinet/in.h> IPV6_MULTICAST_IF
<netinet/in.h> IPV6_MULTICAST_LOOP
<netinet/in.h> IPV6_UNICAST_HOPS
<netinet/in.h> SIN6_LEN
<netinet/in.h> extern const struct in6_addr in6addr_any;
<netinet/in.h> extern const struct in6_addr in6addr_loopback;
<netinet/in.h> struct in6_addr{};
<netinet/in.h> struct ipv6_mreq{};
<netinet/in.h> struct sockaddr_in6{};

<sys/socket.h> AF_INET6
<sys/socket.h> PF_INET6
<sys/socket.h> struct sockaddr_storage;

The following list summarizes the function and macro prototypes
discussed in this memo, sorted by header.

<arpa/inet.h> int inet_pton(int, const char *, void *);
<arpa/inet.h> const char *inet_ntop(int, const void *,
char *, size_t);

<net/if.h> char *if_indextoname(unsigned int, char *);
<net/if.h> unsigned int if_nametoindex(const char *);
<net/if.h> void if_freenameindex(struct if_nameindex *);
<net/if.h> struct if_nameindex *if_nameindex(void);

<netdb.h> int getaddrinfo(const char *, const char *,
const struct addrinfo *,
struct addrinfo **);
<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
char *, size_t, char *, size_t, int);
<netdb.h> void freeaddrinfo(struct addrinfo *);
<netdb.h> char *gai_strerror(int);
<netdb.h> struct hostent *getipnodebyname(const char *, int, int,
int *);
<netdb.h> struct hostent *getipnodebyaddr(const void *, size_t,
int, int *);
<netdb.h> void freehostent(struct hostent *);

<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);

<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);

8. Security Considerations

IPv6 provides a number of new security mechanisms, many of which need
to be accessible to applications. Companion memos detailing the
extensions to the socket interfaces to support IPv6 security are
being written.

9. Year 2000 Considerations

There are no issues for this memo concerning the Year 2000 issue
regarding the use of dates.

Changes From RFC2133

Changes made in the March 1998 Edition (-01 draft):

Changed all "hostname" to "nodename" for consistency with other
IPv6 documents.

Section 3.3: changed comment for sin6_flowinfo to be "traffic
class & flow info" and updated corresponding text description to
current definition of these two fields.

Section 3.10 ("Portability Additions") is new.

Section 6: a new paragraph was added reiterating that the existing
gethostbyname() and gethostbyaddr() are not changed.

Section 6.1: change gethostbyname3() to getnodebyname(). Add
AI_DEFAULT to handle majority of applications. Renamed
AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
IPv4 addresses too. Defined exactly what getnodebyname() must
return if the name argument is a numeric address string.

Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword
items 2 and 3 in the description of how to handle IPv4-mapped and
IPv4- compatible addresses to "lookup a name" for a given address,
instead of specifying what type of DNS query to issue.

Section 6.3: added two more requirements to getaddrinfo().

Section 7: added the following constants to the list for
<netdb.h>: AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union
sockaddr_union and SA_LEN to the lists for <sys/socket.h>.

Updated references.

Changes made in the November 1997 Edition (-00 draft):

The data types have been changed to conform with Draft 6.6 of the
Posix 1003.1g standard.

Section 3.2: data type of s6_addr changed to "uint8_t".

Section 3.3: data type of sin6_family changed to "sa_family_t".
data type of sin6_port changed to "in_port_t", data type of
sin6_flowinfo changed to "uint32_t".

Section 3.4: same as Section 3.3, plus data type of sin6_len
changed to "uint8_t".

Section 6.2: first argument of gethostbyaddr() changed from "const
char *" to "const void *" and second argument changed from "int"
to "size_t".

Section 6.4: second argument of getnameinfo() changed from
"size_t" to "socklen_t".

The wording was changed when new structures were defined, to be
more explicit as to which header must be included to define the
structure:

Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
(ipv6_mreq{}), and Section 6.3 (addrinfo{}).

Section 4: NET_RT_LIST changed to NET_RT_IFLIST.

Section 5.1: The IPV6_ADDRFORM socket option was removed.

Section 5.3: Added a note that an option value other than 0 or 1
for IPV6_MULTICAST_LOOP returns an error. Added a note that
IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().

Section 6.1: Removed the description of gethostbyname2() and its
associated RES_USE_INET6 option, replacing it with
gethostbyname3().

Section 6.2: Added requirement that gethostbyaddr() be thread
safe. Reworded step 4 to avoid using the RES_USE_INET6 option.

Section 6.3: Added the requirement that getaddrinfo() and
getnameinfo() be thread safe. Added the AI_NUMERICHOST flag.

Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
IN6_IS_ADDR_SITELOCAL macros.

Changes made to the draft -01 specification Sept 98

Changed priority to traffic class in the spec.

Added the need for scope identification in section 2.1.

Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
3.4.

Changed 3.10 to use generic storage structure to support holding
IPv6 addresses and removed the SA_LEN macro.

Distinguished between invalid input parameters and system failures
for Interface Identification in Section 4.1 and 4.2.

Added defaults for multicast operations in section 5.2 and changed
the names from ADD to JOIN and DROP to LEAVE to be consistent with
IPv6 multicast terminology.

Changed getnodebyname to getipnodebyname, getnodebyaddr to
getipnodebyaddr, and added MT safe error code to function
parameters in section 6.

Moved freehostent to its own sub-section after getipnodebyaddr now
6.3 (so this bumps all remaining sections in section 6.

Clarified the use of AI_ALL and AI_V4MAPPED that these are
dependent on the AF parameter and must be used as a conjunction in
section 6.1.

Removed the restriction that literal addresses cannot be used with
a flags argument in section 6.1.

Added Year 2000 Section to the draft

Deleted Reference to the following because the attached is deleted
from the ID directory and has expired. But the logic from the
aforementioned draft still applies, so that was kept in Section
6.2 bullets after 3rd paragraph.

[7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
ipv4ptr-00.txt>, May 1996.

Deleted the following reference as it is no longer referenced.
And the draft has expired.

[3] D. McDonald, "A Simple IP Security API Extension to BSD
Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
01.txt>, March 1997.

Deleted the following reference as it is no longer referenced.

[4] C. Metz, "Network Security API for Sockets",
Internet-Draft, <draft-metz-net-security-api-01.txt>, January
1998.

Update current references to current status.

Added alignment notes for in6_addr and sin6_addr.

Clarified further that AI_V4MAPPED must be used with a dotted IPv4
literal address for getipnodebyname(), when address family is
AF_INET6.

Added text to clarify "::" and "::1" when used by
getipnodebyaddr().

Acknowledgments

Thanks to the many people who made suggestions and provided feedback
to this document, including: Werner Almesberger, Ran Atkinson, Fred
Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
Waitzman, Carl Williams, and Kazu Yamamoto,

The getaddrinfo() and getnameinfo() functions are taken from an
earlier Internet Draft by Keith Sklower. As noted in that draft,
William Durst, Steven Wise, Michael Karels, and Eric Allman provided
many useful discussions on the subject of protocol-independent name-
to-address translation, and reviewed early versions of Keith
Sklower's original proposal. Eric Allman implemented the first
prototype of getaddrinfo(). The observation that specifying the pair
of name and service would suffice for connecting to a service
independent of protocol details was made by Marshall Rose in a
proposal to X/Open for a "Uniform Network Interface".

Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
Kacker made many contributions to this document. Ramesh Govindan
made a number of contributions and co-authored an earlier version of
this memo.

References

[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.

[2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.

[3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
6.6, March 1997.

[4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
2292, February 1998.

Authors' Addresses

Robert E. Gilligan
FreeGate Corporation
1208 E. Arques Ave.
Sunnyvale, CA 94086

Phone: +1 408 617 1004
EMail: gilligan@freegate.com

Susan Thomson
Bell Communications Research
MRE 2P-343, 445 South Street
Morristown, NJ 07960

Phone: +1 201 829 4514
EMail: set@thumper.bellcore.com

Jim Bound
Compaq Computer Corporation
110 Spitbrook Road ZK3-3/U14
Nashua, NH 03062-2698

Phone: +1 603 884 0400
EMail: bound@zk3.dec.com

W. Richard Stevens
1202 E. Paseo del Zorro
Tucson, AZ 85718-2826

Phone: +1 520 297 9416
EMail: rstevens@kohala.com

Full Copyright Statement

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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容