draft-ietf-ipngwg-rfc2553bis-01.txt   draft-ietf-ipngwg-rfc2553bis-02.txt 
IPNG Working Group R.E. Gilligan IPNG Working Group R.E. Gilligan
INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-01.txt Cache Flow INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-02.txt Cache Flow
Obsoletes RFC 2553 S. Thomson Obsoletes RFC 2553 S. Thomson
Cisco Cisco
J. Bound J. Bound
Compaq Nokia Networks
W. R. Stevens W. R. Stevens
October 2000 January 2001
Basic Socket Interface Extensions for IPv6 Basic Socket Interface Extensions for IPv6
<draft-ietf-ipngwg-rfc2553bis-01.txt> <draft-ietf-ipngwg-rfc2553bis-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is a submission by the Internet Protocol IPv6 Working This document is a submission by the Internet Protocol IPv6 Working
Group of the Internet Engineering Task Force (IETF). Comments should Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ipng@sunroof.eng.sun.com mailing list. be submitted to the ipng@sunroof.eng.sun.com mailing list.
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents: Table of Contents:
1. Introduction.................................................4 1. Introduction.................................................4
2. Design Considerations........................................4 2. Design Considerations........................................4
2.1 What Needs to be Changed....................................4 2.1 What Needs to be Changed....................................4
2.2 Data Types..................................................6 2.2 Data Types..................................................6
2.3 Headers.....................................................6 2.3 Headers.....................................................6
2.4 Structures..................................................6 2.4 Structures..................................................6
3. Socket Interface.............................................6 3. Socket Interface.............................................6
3.1 IPv6 Address Family and Protocol Family.....................6 3.1 IPv6 Address Family and Protocol Family.....................6
3.2 IPv6 Address Structure......................................7 3.2 IPv6 Address Structure......................................6
3.3 Socket Address Structure for 4.3BSD-Based Systems...........7 3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
3.4 Socket Address Structure for 4.4BSD-Based Systems...........8 3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
3.5 The Socket Functions........................................9 3.5 The Socket Functions........................................9
3.6 Compatibility with IPv4 Applications.......................10 3.6 Compatibility with IPv4 Applications.......................10
3.7 Compatibility with IPv4 Nodes..............................10 3.7 Compatibility with IPv4 Nodes..............................10
3.8 IPv6 Wildcard Address......................................11 3.8 IPv6 Wildcard Address......................................10
3.9 IPv6 Loopback Address......................................12 3.9 IPv6 Loopback Address......................................11
3.10 Portability Additions.....................................12 3.10 Portability Additions.....................................12
4. Interface Identification....................................14 4. Interface Identification....................................14
4.1 Name-to-Index..............................................14 4.1 Name-to-Index..............................................14
4.2 Index-to-Name..............................................15 4.2 Index-to-Name..............................................15
4.3 Return All Interface Names and Indexes.....................15 4.3 Return All Interface Names and Indexes.....................15
4.4 Free Memory................................................15 4.4 Free Memory................................................15
5. Socket Options..............................................16 5. Socket Options..............................................16
5.1 Unicast Hop Limit..........................................16 5.1 Unicast Hop Limit..........................................16
5.2 Sending and Receiving Multicast Packets....................17 5.2 Sending and Receiving Multicast Packets....................17
5.3 IPV6_ONLY option for AF_INET6 Sockets......................18 5.3 IPV6_ONLY option for AF_INET6 Sockets.......................18
6. Library Functions...........................................19 6. Library Functions...........................................19
6.1 Protocol-Independent Nodename and Service Name Translation.19 6.1 Protocol-Independent Nodename and Service Name Translation.19
6.2 Socket Address Structure to Nodename and Service Name......23 6.2 Socket Address Structure to Nodename and Service Name......23
6.3 Address Conversion Functions...............................25 6.3 Address Conversion Functions...............................25
6.4 Address Testing Macros.....................................26 6.4 Address Testing Macros.....................................26
7. Summary of New Definitions..................................27 7. Summary of New Definitions..................................27
8. Security Considerations.....................................29 8. Security Considerations.....................................28
9. Year 2000 Considerations....................................29 9. Year 2000 Considerations....................................28
Changes made to rfc2553bis-01 to rfc2553bis-02.................29
Changes made to rfc2553bis-00 to rfc2553bis-01.................29 Changes made to rfc2553bis-00 to rfc2553bis-01.................29
Changes made rfc2553 to rfc2553bis-00:.........................29 Changes made rfc2553 to rfc2553bis-00:.........................29
Acknowledgments................................................30 Acknowledgments................................................29
References.....................................................30 References.....................................................30
Authors' Addresses.............................................31 Authors' Addresses.............................................31
1. Introduction 1. Introduction
While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by 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 128-bit addresses. The socket interface makes the size of an IP address
quite visible to an application; virtually all TCP/IP applications for quite visible to an application; virtually all TCP/IP applications for
BSD-based systems have knowledge of the size of an IP address. Those 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 parts of the API that expose the addresses must be changed to
skipping to change at page 4, line 32 skipping to change at page 4, line 32
- The API changes should provide both source and binary - The API changes should provide both source and binary
compatibility for programs written to the original API. That compatibility for programs written to the original API. That
is, existing program binaries should continue to operate when is, existing program binaries should continue to operate when
run on a system supporting the new API. In addition, existing run on a system supporting the new API. In addition, existing
applications that are re-compiled and run on a system supporting applications that are re-compiled and run on a system supporting
the new API should continue to operate. Simply put, the API the new API should continue to operate. Simply put, the API
changes for IPv6 should not break existing programs. An additonal changes for IPv6 should not break existing programs. An additonal
mechanism for implementations to verify this is to verify the new mechanism for implementations to verify this is to verify the new
symbols are protected by Feature Test Macros as described in IEEE Std symbols are protected by Feature Test Macros as described in IEEE Std
1003.1. (Such Feature Test Macros are not defined by this RFC.) 1003.1-200x. (Such Feature Test Macros are not defined by this RFC.)
- The changes to the API should be as small as possible in order - The changes to the API should be as small as possible in order
to simplify the task of converting existing IPv4 applications to to simplify the task of converting existing IPv4 applications to
IPv6. IPv6.
- Where possible, applications should be able to use this - Where possible, applications should be able to use this
API to interoperate with both IPv6 and IPv4 hosts. Applications API to interoperate with both IPv6 and IPv4 hosts. Applications
should not need to know which type of host they are should not need to know which type of host they are
communicating with. communicating with.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
IPv6 addresses are scoped [2] so they could be link-local, site, IPv6 addresses are scoped [2] so they could be link-local, site,
organization, global, or other scopes at this time undefined. To organization, global, or other scopes at this time undefined. To
support applications that want to be able to identify a set of support applications that want to be able to identify a set of
interfaces for a specific scope, the IPv6 sockaddr_in structure must 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 support a field that can be used by an implementation to identify a set
of interfaces identifying the scope for an IPv6 address. of interfaces identifying the scope for an IPv6 address.
The name-to-address translation functions in the socket interface are The name-to-address translation functions in the socket interface are
gethostbyname() and gethostbyaddr(). These are left as is and new gethostbyname() and gethostbyaddr(). These are left as is and new
functions are defined to support IPv4 and IPv6. The new API is based on functions are defined to support IPv4 and IPv6. The new API is based on
the POSIX 1003.g draft [3] and specifies a new nodename-to-address the POSIX 1003.1-200x draft [3] and specifies a new nodename-to-address
translation function which is protocol independent. This function can translation function which is protocol independent. This function can
also be used with IPv4 and IPv6. also be used with IPv4 and IPv6.
The address conversion functions -- inet_ntoa() and inet_addr() -- The address conversion functions -- inet_ntoa() and inet_addr() --
convert IPv4 addresses between binary and printable form. These convert IPv4 addresses between binary and printable form. These
functions are quite specific to 32-bit IPv4 addresses. We have designed functions are quite specific to 32-bit IPv4 addresses. We have designed
two analogous functions that convert both IPv4 and IPv6 addresses, and two analogous functions that convert both IPv4 and IPv6 addresses, and
carry an address type parameter so that they can be extended to other carry an address type parameter so that they can be extended to other
protocol families as well. protocol families as well.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
interfaces are needed to support the IPv6 traffic class, flow label, and interfaces are needed to support the IPv6 traffic class, flow label, and
hop limit header fields. New socket options are needed to control the hop limit header fields. New socket options are needed to control the
sending and receiving of IPv6 multicast packets. sending and receiving of IPv6 multicast packets.
The socket interface will be enhanced in the future to provide access to The socket interface will be enhanced in the future to provide access to
other IPv6 features. These extensions are described in [4]. other IPv6 features. These extensions are described in [4].
2.2 Data Types 2.2 Data Types
The data types of the structure elements given in this memo are intended The data types of the structure elements given in this memo are intended
to be examples, not absolute requirements. Whenever possible, data to track the relevant standards. uintN_t means an unsigned integer of
types from Draft 6.6 (March 1997) of POSIX 1003.1g are used: uintN_t exactly N bits (e.g., uint16_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 2.3 Headers
When function prototypes and structures are shown we show the headers When function prototypes and structures are shown we show the headers
that must be #included to cause that item to be defined. that must be #included to cause that item to be defined.
2.4 Structures 2.4 Structures
When structures are described the members shown are the ones that must When structures are described the members shown are the ones that must
appear in an implementation. Additional, nonstandard members may also appear in an implementation. Additional, nonstandard members may also
be defined by an implementation. As an additional precaution be defined by an implementation. As an additional precaution
nonstandard members could be verified by Feature Test Macros as nonstandard members could be verified by Feature Test Macros as
described in IEEE Std 1003.1. (Such Feature Test Macros are not defined described in IEEE Std 1003.1-200x. (Such Feature Test Macros are not
by this RFC.) defined by this RFC.)
The ordering shown for the members of a structure is the recommended The ordering shown for the members of a structure is the recommended
ordering, given alignment considerations of multibyte members, but an ordering, given alignment considerations of multibyte members, but an
implementation may order the members differently. implementation may order the members differently.
3. Socket Interface 3. Socket Interface
This section specifies the socket interface changes for IPv6. This section specifies the socket interface changes for IPv6.
3.1 IPv6 Address Family and Protocol Family 3.1 IPv6 Address Family and Protocol Family
skipping to change at page 16, line 4 skipping to change at page 15, line 52
The memory used for this array of structures along with the interface The memory used for this array of structures along with the interface
names pointed to by the if_name members is obtained dynamically. This names pointed to by the if_name members is obtained dynamically. This
memory is freed by the next function. memory is freed by the next function.
4.4 Free Memory 4.4 Free Memory
The following function frees the dynamic memory that was allocated by The following function frees the dynamic memory that was allocated by
if_nameindex(). if_nameindex().
#include <net/if.h> #include <net/if.h>
void if_freenameindex(struct if_nameindex *ptr); void if_freenameindex(struct if_nameindex *ptr);
The argument to this function must be a pointer that was returned by The argument to this function must be a pointer that was returned by
if_nameindex(). if_nameindex().
Currently net/if.h doesn't have prototype definitions for functions and Currently net/if.h doesn't have prototype definitions for functions and
it is recommended that these definitions be defined in net/if.h as well it is recommended that these definitions be defined in net/if.h as well
and the struct if_nameindex{}. as the struct if_nameindex{}.
5. Socket Options 5. Socket Options
A number of new socket options are defined for IPv6. All of these new 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 options are at the IPPROTO_IPV6 level. That is, the "level" parameter
in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using 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 these options. The constant name prefix IPV6_ is used in all of the new
socket options. This serves to clearly identify these options as socket options. This serves to clearly identify these options as
applying to IPv6. applying to IPv6.
skipping to change at page 16, line 55 skipping to change at page 16, line 50
x < -1: return an error of EINVAL x < -1: return an error of EINVAL
x == -1: use kernel default x == -1: use kernel default
0 <= x <= 255: use x 0 <= x <= 255: use x
x >= 256: return an error of EINVAL x >= 256: return an error of EINVAL
The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine
the hop limit value that the system will use for subsequent unicast the hop limit value that the system will use for subsequent unicast
packets sent via that socket. For example: packets sent via that socket. For example:
int hoplimit; int hoplimit;
size_t len = sizeof(hoplimit); socklen_t len = sizeof(hoplimit);
if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
(char *) &hoplimit, &len) == -1) (char *) &hoplimit, &len) == -1)
perror("getsockopt IPV6_UNICAST_HOPS"); perror("getsockopt IPV6_UNICAST_HOPS");
else else
printf("Using %d for hop limit.\n", hoplimit); printf("Using %d for hop limit.\n", hoplimit);
5.2 Sending and Receiving Multicast Packets 5.2 Sending and Receiving Multicast Packets
IPv6 applications may send UDP multicast packets by simply specifying an IPv6 applications may send UDP multicast packets by simply specifying an
skipping to change at page 19, line 37 skipping to change at page 19, line 33
gethostbyname2() but this function was also inadequate, first because gethostbyname2() but this function was also inadequate, first because
its use required setting a global option (RES_USE_INET6) when IPv6 its use required setting a global option (RES_USE_INET6) when IPv6
addresses were required, and second because a flag argument is needed to addresses were required, and second because a flag argument is needed to
provide the caller with additional control over the types of addresses provide the caller with additional control over the types of addresses
required. required.
6.1 Protocol-Independent Nodename and Service Name Translation 6.1 Protocol-Independent Nodename and Service Name Translation
Nodename-to-address translation is done in a protocol-independent Nodename-to-address translation is done in a protocol-independent
fashion using the getaddrinfo() function that is taken from the fashion using the getaddrinfo() function that is taken from the
Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g Institute of Electrical and Electronic Engineers IEEE 1003.1-200x
(Protocol Independent Interfaces) draft specification [3]. (POSIX) draft specification [3].
The official specification for this function will be the final POSIX The official specification for this function will be the final POSIX
standard. In addition this specification is not specifying all standard. In addition this specification is not specifying all
parameter possibilities for this function, but only the parameters that parameter possibilities for this function, but only the parameters that
can be provided to support IPv4 and IPv6 communications to support this can be provided to support IPv4 and IPv6 communications to support this
specification. This is beyond the scope of this document and additional specification. This is beyond the scope of this document and additional
work on this function will be done by the IEEE POSIX group. work on this function will be done by the Austin (IEEE/ISO/TOG) Group.
#include <sys/socket.h> #include <sys/socket.h>
#include <netdb.h> #include <netdb.h>
int getaddrinfo(const char *nodename, const char *servname, int getaddrinfo(const char *nodename, const char *servname,
const struct addrinfo *hints, struct addrinfo **res); const struct addrinfo *hints, struct addrinfo **res);
void freeaddrinfo(struct addrinfo *ai); void freeaddrinfo(struct addrinfo *ai);
struct addrinfo { struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */ int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */
int ai_family; /* PF_xxx */ int ai_family; /* PF_xxx */
int ai_socktype; /* SOCK_xxx */ int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_t ai_addrlen; /* length of ai_addr */ socklen_t ai_addrlen; /* length of ai_addr */
char *ai_canonname; /* canonical name for nodename */ char *ai_canonname; /* canonical name for nodename */
struct sockaddr *ai_addr; /* binary address */ struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */ struct addrinfo *ai_next; /* next structure in linked list */
}; };
The getaddrinfo ( ) function translates the name of a service The getaddrinfo ( ) function translates the name of a service
location (for example, a host name) and/or a service name and returns 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 a set of socket addresses and associated information to be used in
creating a socket with which to address the specified service. creating a socket with which to address the specified service.
The nodename and servname arguments are either null pointers or The nodename and servname arguments are either null pointers or
pointers to null-terminated strings. One or both of these two pointers to null-terminated strings. One or both of these two
arguments must be a non-null pointer. arguments must be a non-null pointer.
The format of a valid name depends on the protocol family or The format of a valid name depends on the protocol family or
skipping to change at page 23, line 51 skipping to change at page 23, line 43
char *gai_strerror(int ecode); char *gai_strerror(int ecode);
The argument is one of the EAI_xxx values defined earlier and the return 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 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 one of the EAI_xxx values, the function still returns a pointer to a
string whose contents indicate an unknown error. string whose contents indicate an unknown error.
6.2 Socket Address Structure to Nodename and Service Name 6.2 Socket Address Structure to Nodename and Service Name
The official specification for this function will be the final POSIX The official specification for this function will be the final Austin
standard update to getaddrinfo(), and will incorporate this function. Group standard update to getaddrinfo(), and will incorporate this
In addition this specification is not specifying all parameter function. In addition this specification is not specifying all
possibilities for this function, but only the parameters that can be parameter possibilities for this function, but only the parameters that
provided to support IPv4 and IPv6 communications to support this can be provided to support IPv4 and IPv6 communications to support this
specification. This is beyond the scope of this document and additional specification. This is beyond the scope of this document and additional
work on this function will be done by the IEEE POSIX group. work on this function will be done by the Austin group.
#include <sys/socket.h> #include <sys/socket.h>
#include <netdb.h> #include <netdb.h>
int getnameinfo(const struct sockaddr *sa, socklen_t salen, int getnameinfo(const struct sockaddr *sa, socklen_t salen,
char *host, size_t hostlen, char *host, socklen_t hostlen,
char *serv, size_t servlen, char *serv, socklen_t servlen,
int flags); int flags);
The getnameinfo( ) translates a socket address to a node name and The getnameinfo( ) translates a socket address to a node name and
service location, all of which are defined as with getaddrinfo (). service location, all of which are defined as with getaddrinfo ().
The argument sa points to a socket address structure to be translated. The argument sa points to a socket address structure to be translated.
If the argument node is non-NULL and the argument nodelen is nonzero, If the argument node is non-NULL and the argument nodelen is nonzero,
then the argument node points to a buffer able to contain up to nodelen then the argument node points to a buffer able to contain up to nodelen
characters that will receive the node name as a null-terminated string. characters that will receive the node name as a null-terminated string.
skipping to change at page 25, line 53 skipping to change at page 25, line 45
The two functions inet_addr() and inet_ntoa() convert an IPv4 address The two functions inet_addr() and inet_ntoa() convert an IPv4 address
between binary and text form. IPv6 applications need similar functions. between binary and text form. IPv6 applications need similar functions.
The following two functions convert both IPv6 and IPv4 addresses: The following two functions convert both IPv6 and IPv4 addresses:
#include <sys/socket.h> #include <sys/socket.h>
#include <arpa/inet.h> #include <arpa/inet.h>
int inet_pton(int af, const char *src, void *dst); int inet_pton(int af, const char *src, void *dst);
const char *inet_ntop(int af, const void *src, const char *inet_ntop(int af, const void *src,
char *dst, size_t size); char *dst, socklen_t size);
The inet_pton() function converts an address in its standard text The inet_pton() function converts an address in its standard text
presentation form into its numeric binary form. The af argument presentation form into its numeric binary form. The af argument
specifies the family of the address. Currently the AF_INET and AF_INET6 specifies the family of the address. Currently the AF_INET and AF_INET6
address families are supported. The src argument points to the string address families are supported. The src argument points to the string
being passed in. The dst argument points to a buffer into which the being passed in. The dst argument points to a buffer into which the
function stores the numeric address. The address is returned in network function stores the numeric address. The address is returned in network
byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the 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 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 string, or -1 with errno set to EAFNOSUPPORT if the af argument is
unknown. The calling application must ensure that the buffer referred 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 to by dst is large enough to hold the numeric address (e.g., 4 bytes for
AF_INET or 16 bytes for AF_INET6). AF_INET or 16 bytes for AF_INET6).
If the af argument is AF_INET, the function accepts a string in the If the af argument is AF_INET, the function accepts a string in the
standard IPv4 dotted-decimal form: standard IPv4 dotted-decimal form:
skipping to change at page 27, line 37 skipping to change at page 27, line 29
<net/if.h> IF_NAMESIZE <net/if.h> IF_NAMESIZE
<net/if.h> struct if_nameindex{}; <net/if.h> struct if_nameindex{};
<netdb.h> AI_ADDRCONFIG <netdb.h> AI_ADDRCONFIG
<netdb.h> AI_DEFAULT <netdb.h> AI_DEFAULT
<netdb.h> AI_ALL <netdb.h> AI_ALL
<netdb.h> AI_CANONNAME <netdb.h> AI_CANONNAME
<netdb.h> AI_NUMERICHOST <netdb.h> AI_NUMERICHOST
<netdb.h> AI_PASSIVE <netdb.h> AI_PASSIVE
<netdb.h> AI_V4MAPPED <netdb.h> AI_V4MAPPED
<netdb.h> EAI_ADDRFAMILY
<netdb.h> EAI_AGAIN <netdb.h> EAI_AGAIN
<netdb.h> EAI_BADFLAGS <netdb.h> EAI_BADFLAGS
<netdb.h> EAI_FAIL <netdb.h> EAI_FAIL
<netdb.h> EAI_FAMILY <netdb.h> EAI_FAMILY
<netdb.h> EAI_MEMORY <netdb.h> EAI_MEMORY
<netdb.h> EAI_NODATA
<netdb.h> EAI_NONAME <netdb.h> EAI_NONAME
<netdb.h> EAI_SERVICE <netdb.h> EAI_SERVICE
<netdb.h> EAI_SOCKTYPE <netdb.h> EAI_SOCKTYPE
<netdb.h> EAI_SYSTEM <netdb.h> EAI_SYSTEM
<netdb.h> NI_DGRAM <netdb.h> NI_DGRAM
<netdb.h> NI_MAXHOST <netdb.h> NI_MAXHOST
<netdb.h> NI_MAXSERV <netdb.h> NI_MAXSERV
<netdb.h> NI_NAMEREQD <netdb.h> NI_NAMEREQD
<netdb.h> NI_NOFQDN <netdb.h> NI_NOFQDN
<netdb.h> NI_NUMERICHOST <netdb.h> NI_NUMERICHOST
skipping to change at page 28, line 28 skipping to change at page 28, line 17
<sys/socket.h> AF_INET6 <sys/socket.h> AF_INET6
<sys/socket.h> PF_INET6 <sys/socket.h> PF_INET6
<sys/socket.h> struct sockaddr_storage; <sys/socket.h> struct sockaddr_storage;
The following list summarizes the function and macro prototypes The following list summarizes the function and macro prototypes
discussed in this memo, sorted by header. discussed in this memo, sorted by header.
<arpa/inet.h> int inet_pton(int, const char *, void *); <arpa/inet.h> int inet_pton(int, const char *, void *);
<arpa/inet.h> const char *inet_ntop(int, const void *, <arpa/inet.h> const char *inet_ntop(int, const void *,
char *, size_t); char *, socklen_t);
<net/if.h> char *if_indextoname(unsigned int, char *); <net/if.h> char *if_indextoname(unsigned int, char *);
<net/if.h> unsigned int if_nametoindex(const char *); <net/if.h> unsigned int if_nametoindex(const char *);
<net/if.h> void if_freenameindex(struct if_nameindex *); <net/if.h> void if_freenameindex(struct if_nameindex *);
<net/if.h> struct if_nameindex *if_nameindex(void); <net/if.h> struct if_nameindex *if_nameindex(void);
<netdb.h> int getaddrinfo(const char *, const char *, <netdb.h> int getaddrinfo(const char *, const char *,
const struct addrinfo *, const struct addrinfo *,
struct addrinfo **); struct addrinfo **);
<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t, <netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
char *, size_t, char *, size_t, int); char *, socklen_t, char *, socklen_t, int);
<netdb.h> void freeaddrinfo(struct addrinfo *); <netdb.h> void freeaddrinfo(struct addrinfo *);
<netdb.h> char *gai_strerror(int); <netdb.h> char *gai_strerror(int);
<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); <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_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_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_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_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_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_MC_SITELOCAL(const struct in6_addr *);
skipping to change at page 29, line 16 skipping to change at page 29, line 5
IPv6 provides a number of new security mechanisms, many of which need to IPv6 provides a number of new security mechanisms, many of which need to
be accessible to applications. Companion memos detailing the extensions be accessible to applications. Companion memos detailing the extensions
to the socket interfaces to support IPv6 security are being written. to the socket interfaces to support IPv6 security are being written.
9. Year 2000 Considerations 9. Year 2000 Considerations
There are no issues for this draft concerning the Year 2000 issue There are no issues for this draft concerning the Year 2000 issue
regarding the use of dates. regarding the use of dates.
Changes made to rfc2553bis-01 to rfc2553bis-02
1. Updated all references to comply with latest IEEEE work on
socket APIs and changed all remaining size_t to socklen_t.
2. Edits caught.
Changes made to rfc2553bis-00 to rfc2553bis-01 Changes made to rfc2553bis-00 to rfc2553bis-01
1. Removed all references to getipnodebyname() and 1. Removed all references to getipnodebyname() and
getipnodebyaddr(). getipnodebyaddr().
2. Added IPV6_ONLY Socket IP level option to permit nodes 2. Added IPV6_ONLY Socket IP level option to permit nodes
to not process IPv4 packets as IPv4 Mapped addresses to not process IPv4 packets as IPv4 Mapped addresses
in implementations. in implementations.
3. Added note to getaddrinfo() and getnameinfo() 3. Added note to getaddrinfo() and getnameinfo()
that final specification of paramter associations for that final specification of paramter associations for
these functions will be done by POSIX. these functions will be done by Austin.
4. Added SIIT to references and added new contributors. 4. Added SIIT to references and added new contributors.
Changes made rfc2553 to rfc2553bis-00: Changes made rfc2553 to rfc2553bis-00:
1. Updated Portability Section 3.10 to conform to XNS 5.2. 1. Updated Portability Section 3.10 to conform to XNS 5.2.
2. Updated getaddrinfo(), getnameinfo(), to conform to XNS 5.2. 2. Updated getaddrinfo(), getnameinfo(), to conform to XNS 5.2.
3. Added references to Scope Architecture, Scope Routing, and 3. Added references to Scope Architecture, Scope Routing, and
skipping to change at page 30, line 47 skipping to change at page 30, line 39
of contributions and co-authored an earlier version of this memo. of contributions and co-authored an earlier version of this memo.
References References
[1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460 Draft Standard. Specification", RFC 2460 Draft Standard.
[2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998 Draft Standard. RFC 2373, July 1998 Draft Standard.
[3] IEEE, "Protocol Independent Interfaces", [3] IEEE Std. 1003.1-200x (Portable Operating System Interface (POSIX))
IEEE Std 1003.1g, DRAFT 6.6, DRAFT 6, July 2000.
March 1997.
[4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6",
RFC 2292, February 1998. RFC 2292, February 1998.
[5] T. Jinmei, A. Onoe, "An Extension of Format for IPv6 Scoped [5] T. Jinmei, A. Onoe, "An Extension of Format for IPv6 Scoped
Addresses", Work-in-Progress. Addresses", Work-in-Progress.
[6] S. Deering, B. Haberman, B. Zill "IP Version 6 Scoped Address [6] S. Deering, B. Haberman, B. Zill "IP Version 6 Scoped Address
Architecture", Work-in-Progress. Architecture", Work-in-Progress.
skipping to change at page 31, line 27 skipping to change at page 31, line 23
Email: gilligan@cacheflow.com Email: gilligan@cacheflow.com
Susan Thomson Susan Thomson
Cisco Systems Cisco Systems
499 Thornall Street, 8th floor 499 Thornall Street, 8th floor
Edison, NJ 08837 Edison, NJ 08837
Telephone: 732-635-3086 Telephone: 732-635-3086
Email: sethomso@cisco.com Email: sethomso@cisco.com
Jim Bound Jim Bound
Compaq Computer Corporation Nokia Networks
110 Spitbrook Road ZK3-3/U14 5 Wayside Road
Nashua, NH 03062-2698 Burlington, MA 01803
Phone: +1 603 884 0400 Phone: +1 781 492 6013
Email: bound@zk3.dec.com Email: Jim.Bound@nokia.com
 End of changes. 35 change blocks. 
48 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/