draft-ietf-ipngwg-rfc2553bis-02.txt   draft-ietf-ipngwg-rfc2553bis-03.txt 
IPNG Working Group R.E. Gilligan IPNG Working Group R.E. Gilligan
INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-02.txt Cache Flow INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-03.txt Cache Flow
Obsoletes RFC 2553 S. Thomson Obsoletes RFC 2553 S. Thomson
Cisco Cisco
J. Bound J. Bound
Nokia Networks Nokia Networks
W. R. Stevens W. R. Stevens
January 2001 February 2001
Basic Socket Interface Extensions for IPv6 Basic Socket Interface Extensions for IPv6
<draft-ietf-ipngwg-rfc2553bis-02.txt> <draft-ietf-ipngwg-rfc2553bis-03.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 32 skipping to change at page 3, line 32
3.9 IPv6 Loopback Address......................................11 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_V6ONLY 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.....................................28 8. Security Considerations.....................................28
9. Year 2000 Considerations....................................28 9. Year 2000 Considerations....................................28
Changes made to rfc2553bis-02 to rfc2553bis-03.................29
Changes made to rfc2553bis-01 to rfc2553bis-02.................29 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................................................29 Acknowledgments................................................30
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 29 skipping to change at page 4, line 29
There are a number of important considerations in designing changes to There are a number of important considerations in designing changes to
this well-worn API: this well-worn API:
- 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 additional
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-200x. (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
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.1-200x draft [3] and specifies a new nodename-to-address the IEEE Std 1003.1-200x draft [3] and specifies a new nodename-to-
translation function which is protocol independent. This function can address translation function which is protocol independent. This
also be used with IPv4 and IPv6. function can 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.
Finally, a few miscellaneous features are needed to support IPv6. New Finally, a few miscellaneous features are needed to support IPv6. New
interfaces are needed to support the IPv6 traffic class, flow label, and interfaces are needed to support the IPv6 traffic class, flow label, and
skipping to change at page 12, line 43 skipping to change at page 12, line 43
Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to
a previously declared IPv6 address variable. a previously declared IPv6 address variable.
3.10 Portability Additions 3.10 Portability Additions
One simple addition to the sockets API that can help application writers One simple addition to the sockets API that can help application writers
is the "struct sockaddr_storage". This data structure can simplify is the "struct sockaddr_storage". This data structure can simplify
writing portable code across multiple address families and platforms. writing portable code across multiple address families and platforms.
This data structure is designed with the following goals. This data structure is designed with the following goals.
- Large enough to accomodate all supported protocol-specific address - Large enough to accommodate all supported protocol-specific address
structures. structures.
- Aligned at an appropriate boundary so that pointers to it can be cast - Aligned at an appropriate boundary so that pointers to it can be cast
as pointers to protocol specific address structures and used to as pointers to protocol specific address structures and used to
access the fields of those structures without alignment problems. access the fields of those structures without alignment problems.
The sockaddr_storage structure contains field ss_family which is of type 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 sa_family_t. When a sockaddr_storage structure is cast to a sockaddr
structure, the ss_family field of the sockaddr_storage structure maps structure, the ss_family field of the sockaddr_storage structure maps
onto the sa_family field of the sockaddr structure. When a onto the sa_family field of the sockaddr structure. When a
sockaddr_storage structure is cast as a protocol specific address sockaddr_storage structure is cast as a protocol specific address
skipping to change at page 18, line 32 skipping to change at page 18, line 32
struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
unsigned int ipv6mr_interface; /* interface index */ unsigned int ipv6mr_interface; /* interface index */
}; };
Note that to receive multicast datagrams a process must join the Note that to receive multicast datagrams a process must join the
multicast group and bind the UDP port to which datagrams will be sent. multicast group and bind the UDP port to which datagrams will be sent.
Some processes also bind the multicast group address to the socket, in Some processes also bind the multicast group address to the socket, in
addition to the port, to prevent other datagrams destined to that same addition to the port, to prevent other datagrams destined to that same
port from being delivered to the socket. port from being delivered to the socket.
5.3 IPV6_ONLY option for AF_INET6 Sockets 5.3 IPV6_V6ONLY option for AF_INET6 Sockets
This socket option restricts AF_INET6 sockets to IPv6 communications This socket option restricts AF_INET6 sockets to IPv6 communications
only. As stated in section <3.7 Compatibility with IPv4 Nodes>, only. As stated in section <3.7 Compatibility with IPv4 Nodes>,
AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some 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 applications may want to restrict their use of an AF_INET6 socket to
IPv6 communications only. For these applications the IPV6_V6ONLY socket IPv6 communications only. For these applications the IPV6_V6ONLY socket
option is defined. When this option is turned on, the socket can be 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 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 level option. This option takes an int value. This is a boolean
option. By default this option is turned off. option. By default this option is turned off.
skipping to change at page 19, line 36 skipping to change at page 19, line 36
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 1003.1-200x Institute of Electrical and Electronic Engineers IEEE 1003.1-200x
(POSIX) 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 IEEE
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 Austin (IEEE/ISO/TOG) 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);
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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
families. If a specific family is not given and the name could be families. If a specific family is not given and the name could be
interpreted as valid within multiple supported families, the interpreted as valid within multiple supported families, the
implementation will attempt to resolve the name in all supported implementation will attempt to resolve the name in all supported
families and, all successful results will be returned. families and, all successful results will be returned.
If the nodename argument is not null, it can be a descriptive name or 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, can be an address string. If the specified address family is AF_INET,
or AF_UNSPEC, the permisssable nodename argument is specified as or AF_UNSPEC, the permissable nodename argument is specified as
defined in inet_pton(). If the specified address family is AF_INET6 defined in inet_pton(). If the specified address family is AF_INET6
or AF_UNSPEC, the permisssable nodename argument is specified as or AF_UNSPEC, the permissable nodename argument is specified as
defined in [5]. defined in [5].
If nodename is not null, the requested service location is named by If nodename is not null, the requested service location is named by
nodename; otherwise, the requested service location is local to the nodename; otherwise, the requested service location is local to the
caller. caller.
If servname is null, the call returns network-level addresses for the If servname is null, the call returns network-level addresses for the
specified nodename. If servname is not null, it is a null-terminated specified nodename. If servname is not null, it is a null-terminated
character string identifying the requested service. This can be character string identifying the requested service. This can be
either a descriptive name or a numeric representation suitable for either a descriptive name or a numeric representation suitable for
skipping to change at page 29, line 5 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-02 to rfc2553bis-03
1. Edits only.
Changes made to rfc2553bis-01 to rfc2553bis-02 Changes made to rfc2553bis-01 to rfc2553bis-02
1. Updated all references to comply with latest IEEEE work on 1. Updated all references to comply with latest IEEEE work on
socket APIs and changed all remaining size_t to socklen_t. socket APIs and changed all remaining size_t to socklen_t.
2. Edits caught. 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_V6ONLY 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 parameter associations for
these functions will be done by Austin. 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.
skipping to change at page 29, line 47 skipping to change at page 30, line 7
5. Added qualification to getipnodebyname/addr() functions that 5. Added qualification to getipnodebyname/addr() functions that
they will not work as is with scope identifiers with IPv6, and they will not work as is with scope identifiers with IPv6, and
getaddrinfo/getnameinfo should be used. getaddrinfo/getnameinfo should be used.
6. Added DNS A6 record notation to AAAA and added ip6.arpa as new 6. Added DNS A6 record notation to AAAA and added ip6.arpa as new
PTR record domain. PTR record domain.
Acknowledgments Acknowledgments
This specification's evolution and completeness were siginficantly This specification's evolution and completeness were significantly
influenced by the efforts of Richard Stevens, who has passed on. Rich's influenced by the efforts of Richard Stevens, who has passed on. Rich's
wisdom and talent made the specification what it is today. The co- wisdom and talent made the specification what it is today. The co-
authors will long think of Richard with great respect. authors will long think of Richard with great respect.
Thanks to the many people who made suggestions and provided feedback to Thanks to the many people who made suggestions and provided feedback to
this document, including: Werner Almesberger, Ran Atkinson, Fred Baker, this document, including: Werner Almesberger, Ran Atkinson, Fred Baker,
Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering,
Richard Draves, Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro Richard Draves, Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro
itojun Hagino, Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, itojun Hagino, Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu,
Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles
Lynn, Dan McDonald, Dave Mitton, Thomas Narten, Josh Osborne, Craig Lynn, Dan McDonald, Dave Mitton, Thomas Narten, Josh Osborne, Craig
Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith
Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean
D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl
Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill
skipping to change at page 31, line 9 skipping to change at page 31, line 12
[7] B. Haberman " Routing of Scoped Addresses in the Internet Protocol [7] B. Haberman " Routing of Scoped Addresses in the Internet Protocol
Version 6 (IPv6)", Work-in-Progress. Version 6 (IPv6)", Work-in-Progress.
[8] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)" [8] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)"
RFC 2765, February 2000. RFC 2765, February 2000.
Authors' Addresses Authors' Addresses
Bob Gilligan Bob Gilligan
Cacheflow, Inc. Cacheflow, Inc.
650 Almanor Ave. 650 Almanor Ave..
Sunnyvale, CA 94086 Sunnyvale, CA 94086
Telephone: 408-220-2084 (voice) Telephone: 408-220-2084 (voice)
408-220-2250 (fax) 408-220-2250 (fax)
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
 End of changes. 19 change blocks. 
19 lines changed or deleted 23 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/