draft-ietf-ipngwg-bsd-api-01.txt   draft-ietf-ipngwg-bsd-api-02.txt 
Internet Engineering Task Force R. E. Gilligan (Sun) Internet Engineering Task Force R. E. Gilligan (Sun)
INTERNET-DRAFT S. Thomson (Bellcore) INTERNET-DRAFT S. Thomson (Bellcore)
J. Bound (Digital) J. Bound (Digital)
June 21, 1995 July 7, 1995
IPv6 Program Interfaces for BSD Systems IPv6 Program Interfaces for BSD Systems
<draft-ietf-ipngwg-bsd-api-01.txt> <draft-ietf-ipngwg-bsd-api-02.txt>
Abstract Abstract
In order to implement the version 6 Internet Protocol (IPv6) [1] in an In order to implement the version 6 Internet Protocol (IPv6) [1] in an
operating system based on Berkeley Unix (4.x BSD), changes must be made operating system based on Berkeley Unix (4.x BSD), changes must be made
to the application program interface (API). TCP/IP applications written to the application program interface (API). TCP/IP applications written
for BSD-based operating systems have in the past enjoyed a high degree for BSD-based operating systems have in the past enjoyed a high degree
of portability because most of the systems derived from BSD provide the of portability because most of the systems derived from BSD provide the
same API, known informally as "the socket interface". We would like the same API, known informally as "the socket interface". We would like the
same portability with IPv6. This memo presents a set of extensions to same portability with IPv6. This memo presents a set of extensions to
skipping to change at page 1, line 36 skipping to change at page 1, line 36
providing complete compatibility for existing IPv4 applications. providing complete compatibility for existing IPv4 applications.
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
This Internet Draft expires on December 20, 1995. Internet Drafts may This Internet Draft expires on January 6, 1996. Internet Drafts may
be updated, replaced, or obsoleted by other documents at any time. It be updated, replaced, or obsoleted by other documents at any time. It
is not appropriate to use Internet Drafts as reference material or to is not appropriate to use Internet Drafts as reference material or to
cite them other than as a "working draft" or "work in progress." cite them other than as a "working draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
The sin6_family field is used to identify this as a sockaddr_in6 The sin6_family field is used to identify this as a sockaddr_in6
structure. This field is designed to overlay the sa_family field when structure. This field is designed to overlay the sa_family field when
the buffer is cast to a sockaddr data structure. The value of this the buffer is cast to a sockaddr data structure. The value of this
field must be AF_INET6. field must be AF_INET6.
The sin6_port field is used to store the 16-bit UDP or TCP port The sin6_port field is used to store the 16-bit UDP or TCP port
number. This field is used in the same way as the sin_port field of number. This field is used in the same way as the sin_port field of
the sockaddr_in structure. The port number is stored in network byte the sockaddr_in structure. The port number is stored in network byte
order. order.
The sin6_flowinfo field is a 32-bit field that is used to store the The sin6_flowinfo field is a 32-bit field that is used to store three
24-bit IPv6 flow label, and the 4-bit priority field. The IPv6 flow pieces of information: the 24-bit IPv6 flow label, the 4-bit priority
label is represented as the low-order 24-bits of the 32-bit field, and field, and a 1-bit loose/strict source routing flag. The IPv6 flow
the priority is represented in the next 4-bits above this. The label is represented as the low-order 24-bits of the 32-bit field. The
high-order 4 bits of this field are reserved. The sin6_flowinfo field priority is represented in the next 4-bits above this, and the
is stored in network byte order. The use of this field is explained in loose/strict flag is the 1 bit above this. The high-order 3 bits of
sec 4.8. this field are reserved. The sin6_flowinfo field is stored in network
byte order. The use of the flow label and priority fields are explained
in sec 4.9. The use of the loose/strict flag is discussed in section
4.10.
The sin6_addr field is a single in_addr6 structure (defined in the The sin6_addr field is a single in_addr6 structure (defined in the
previous section). This field holds one 128-bit IPv6 address. The previous section). This field holds one 128-bit IPv6 address. The
address is stored in network byte order. address is stored in network byte order.
The ordering of elements in this structure is specifically designed so The ordering of elements in this structure is specifically designed so
that the sin6_addr field will be aligned on a 64-bit boundary. This that the sin6_addr field will be aligned on a 64-bit boundary. This is
is done for optimum performance on 64-bit architectures. done for optimum performance on 64-bit architectures.
4.4. Socket Address Structure for 4.4 BSD-Based Systems 4.4. Socket Address Structure for 4.4 BSD-Based Systems
The 4.4 BSD release includes a small, but incompatible change to the The 4.4 BSD release includes a small, but incompatible change to the
socket interface. The "sa_family" field of the sockaddr data socket interface. The "sa_family" field of the sockaddr data structure
structure was changed from a 16-bit value to an 8-bit value, and the was changed from a 16-bit value to an 8-bit value, and the space saved
space saved used to hold a length field, named "sa_len". The used to hold a length field, named "sa_len". The sockaddr_in6 data
sockaddr_in6 data structure given in the previous section can not be structure given in the previous section can not be correctly cast into
correctly cast into the newer sockaddr data structure. For this the newer sockaddr data structure. For this reason, we have defined the
reason, we have defined the following alternative IPv6 address data following alternative IPv6 address data structure to be used on systems
structure to be used on systems based on 4.4 BSD: based on 4.4 BSD:
#define SIN6_LEN #define SIN6_LEN
struct sockaddr_in6 { struct sockaddr_in6 {
u_char sin6_len; /* length of this struct */ u_char sin6_len; /* length of this struct */
u_char sin6_family; /* AF_INET6 */ u_char sin6_family; /* AF_INET6 */
u_short sin6_port; /* Transport layer port # */ u_short sin6_port; /* Transport layer port # */
u_long sin6_flowinfo; /* IPv6 flow information */ u_long sin6_flowinfo; /* IPv6 flow information */
struct in_addr6 sin6_addr; /* IPv6 address */ struct in_addr6 sin6_addr; /* IPv6 address */
}; };
This structure is defined in the <netinet/in.h> header file. The only This structure is defined in the <netinet/in.h> header file. The only
differences between this data structure and the 4.3 BSD variant are differences between this data structure and the 4.3 BSD variant are the
the inclusion of the length field, and the change of the family field inclusion of the length field, and the change of the family field to a
to a 8-bit data type. The definitions of all the other fields are 8-bit data type. The definitions of all the other fields are identical
identical to the 4.3 BSD variant defined in the previous section. to the 4.3 BSD variant defined in the previous section.
Systems that provide this version of the sockaddr_in6 data structure Systems that provide this version of the sockaddr_in6 data structure
must include the SIN6_LEN macro definition in <netinet/in.h>. This must include the SIN6_LEN macro definition in <netinet/in.h>. This
macro allows applications to determine whether they are being built on macro allows applications to determine whether they are being built on a
a system that supports the 4.3 BSD or 4.4 BSD variants of the data system that supports the 4.3 BSD or 4.4 BSD variants of the data
structure. Applications can be written to run on both systems by structure. Applications can be written to run on both systems by simply
simply making their assignments and use of the sin6_len field making their assignments and use of the sin6_len field conditional on
conditional on the SIN6_LEN field. For example, to fill in an IPv6 the SIN6_LEN field. For example, to fill in an IPv6 address structure
address structure in an application, one might write: in an application, one might write:
struct sockaddr_in6 sin6; struct sockaddr_in6 sin6;
bzero((char *) &sin6, sizeof(struct sockaddr_in6)); bzero((char *) &sin6, sizeof(struct sockaddr_in6));
#ifdef SIN6_LEN #ifdef SIN6_LEN
sin6.sin6_len = sizeof(struct sockaddr_in6); sin6.sin6_len = sizeof(struct sockaddr_in6);
#endif #endif
sin6.sin6_family = AF_INET6; sin6.sin6_family = AF_INET6;
sin6.sin6_port = 23; sin6.sin6_port = htons(23);
Note that the size of the sockaddr_in6 structure is larger than the
size of the sockaddr structure. Applications that use the
sockaddr_in6 structure need to be aware that they can not use Note that the size of the sockaddr_in6 structure is larger than the size
sizeof(sockaddr) to allocate a buffer to hold a sockaddr_in6 of the sockaddr structure. Applications that use the sockaddr_in6
structure. They should use sizeof(sockaddr_in6) instead. structure need to be aware that they can not use sizeof(sockaddr) to
allocate a buffer to hold a sockaddr_in6 structure. They should use
sizeof(sockaddr_in6) instead.
4.5. The Socket Functions 4.5. The Socket Functions
Applications use the socket() function to create a socket descriptor Applications use the socket() function to create a socket descriptor
that represents a communication endpoint. The arguments to the socket() that represents a communication endpoint. The arguments to the socket()
function tell the system which protocol to use, and what format address function tell the system which protocol to use, and what format address
structure will be used in subsequent functions. For example, to create structure will be used in subsequent functions. For example, to create
an IPv4/TCP socket, applications make the call: an IPv4/TCP socket, applications make the call:
s = socket (PF_INET, SOCK_STREAM, 0); s = socket (PF_INET, SOCK_STREAM, 0);
skipping to change at page 12, line 34 skipping to change at page 12, line 38
packets. An application may always provide a source route with TCP packets. An application may always provide a source route with TCP
connections being originated and UDP packets being sent. But to receive connections being originated and UDP packets being sent. But to receive
source routes, the application must enable an option. source routes, the application must enable an option.
To provide a source route, an application simply provides an array of To provide a source route, an application simply provides an array of
sockaddr_in6 data structures in the address argument of the sendto() sockaddr_in6 data structures in the address argument of the sendto()
function (when sending a UDP packet), or the connect() function (when function (when sending a UDP packet), or the connect() function (when
actively opening a TCP connection). The length argument of the function actively opening a TCP connection). The length argument of the function
is the total length, in octets, of the array. The elements of the array is the total length, in octets, of the array. The elements of the array
represent the full source route, including both source and destination represent the full source route, including both source and destination
identifying address. The elements of the array are ordered from endpoint address. The elements of the array are ordered from
destination to source. That is, the first element of the array destination to source. That is, the first element of the array
represents the destination identifying address, and the last element of represents the destination endpoint address, and the last element of the
the array represents the source identifying address. If the application array represents the source endpoint address. If the application
provides a source route, the source identifying address can not be provides a source route, the source endpoint address can not be omitted.
omitted. The sin6_addr field of the source identifying address may be The sin6_addr field of the source endpoint address may be set to zero,
set to zero, however, in which case the system will select an however, in which case the system will select an appropriate source
appropriate source address. The sin6_port field of the destination address. The sin6_port field of the destination endpoint address must
identifying address must be assigned. The sin_port field of the source be assigned. The sin_port field of the source endpoint address may be
identifying address may be set to zero, in which case the system will set to zero, in which case the system will select an appropriate source
select an appropriate source port number. The sin6_port and port number. The sin6_port fields of the intermediate
sin6_flowinfo fields of the intermediate addresses must be set to zero. addresses must be set to zero.
The flow label and priority sub-fields of the sin6_flowinfo field of the
destination endpoint address may be set, but the these fields must be
set to zero in the intermediate and source endpoint address. The
loose/strict flag of the sin6_flowid field of the destination endpoint
address and the intermediate addresses may be set to 0 or 1. If the
flag is set to one, the leg of the end-to-end path TO that address
should be treated as a strict source route. If the flag is 0, that leg
should be treated as a loose source route. The loose/strict flag of the
source endpoint address must be set to 0.
The arrangement of the address structures in the address buffer passed The arrangement of the address structures in the address buffer passed
to connect() or sendto() is shown in the figure below: to connect() or sendto() is shown in the figure below:
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[0] | Destination Identifying Address | sockaddr_in6[0] | Destination Endpoint Address
| | | |
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[1] | Last Source-Route Hop Address | sockaddr_in6[1] | Last Source-Route Hop Address
| | | |
+--------------------+ +--------------------+
. . . .
. . . .
. . . .
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[N-1] | First Source-Route Hop Address | sockaddr_in6[N-1] | First Source-Route Hop Address
| | | |
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[N] | Source Identifying Address | sockaddr_in6[N] | Source Endpoint Address
| | | |
+--------------------+ +--------------------+
Address buffer when sending a source route Address buffer when sending a source route
The IP_RCVSRCRT setsockopt() option controls the reception of source The IP_RCVSRCRT setsockopt() option controls the reception of source
routes. The option is disabled by default. Applications must routes. The option is disabled by default. Applications must
explicitly enable the option using the setsockopt() function in order to explicitly enable the option using the setsockopt() function in order to
receive source routes. receive source routes.
skipping to change at page 13, line 48 skipping to change at page 14, line 10
int on = 1; /* value == 1 means enable the option */ int on = 1; /* value == 1 means enable the option */
if (setsockopt(s, IPPROTO_IP, IP_RCVSRCRT, (char *) &on, if (setsockopt(s, IPPROTO_IP, IP_RCVSRCRT, (char *) &on,
sizeof(on)) == -1) sizeof(on)) == -1)
perror("setsockopt IP_RCVSRCRT"); perror("setsockopt IP_RCVSRCRT");
When the IP_RCVSRCRT option is disabled, only a single sockaddr_in6 When the IP_RCVSRCRT option is disabled, only a single sockaddr_in6
address structure is returned to applications in the address argument address structure is returned to applications in the address argument
of the recvfrom() and accept() functions. This address represents the of the recvfrom() and accept() functions. This address represents the
source identifying address of the UDP packet received or the TCP source endpoint address of the UDP packet received or the TCP
connection accepted. connection accepted.
When the IP_RCVSRCRT option is enabled, the address argument of the When the IP_RCVSRCRT option is enabled, the address argument of the
recvfrom() function (when receiving UDP packets) and the accept() recvfrom() function (when receiving UDP packets) and the accept()
functions (when passively accepting TCP connections) points to an array functions (when passively accepting TCP connections) points to an array
of sockaddr_in6 structures. When the function returns, the array will of sockaddr_in6 structures. When the function returns, the array will
hold two elements -- source and destination address -- when the received hold two elements -- source and destination address -- when the received
UDP packet or TCP SYN packet does not carry a source route. The array UDP packet or TCP SYN packet does not carry a source route. The array
will hold more than two elements when the received packet carries a will hold more than two elements when the received packet carries a
source route. source route.
The addresses in the array are ordered from source to destination. That The addresses in the array are ordered from source to destination. That
is, the first element of the array holds source identifying address of is, the first element of the array holds source endpoint address of the
the received packet. Following this in the array are the intermediary received packet. Following this in the array are the intermediate hops
hops. And the last element of the array holds the destination in the order in which they were visited. The last element of the array
identifying address. Note that this is the opposite of the order holds the destination endpoint address. Note that this is the opposite
specified for sending. This ordering was chosen so that the address of the order specified for sending. This ordering was chosen so that
array received in a recvfrom() call can be used in a subsequent sendto() the address array received in a recvfrom() call can be used in a
call without requiring the application to re-order the addresses in the subsequent sendto() call without requiring the application to re-order
array. Similarly, the address array received in an accept() call can be the addresses in the array. Similarly, the address array received in an
used unchanged in a subsequent connect() call. accept() call can be used unchanged in a subsequent connect() call.
The address length argument of the recvfrom() and accept() functions The address length argument of the recvfrom() and accept() functions
indicate the length, in octets, of the full address array. This indicate the length, in octets, of the full address array. This
argument is a value-result parameter. The application sets the maximum argument is a value-result parameter. The application sets the maximum
size of the address buffer when it makes the call, and the system size of the address buffer when it makes the call, and the system
modifies the value to return the actual size of the buffer to the modifies the value to return the actual size of the buffer to the
application. application.
The sin6_port field of the first and last array elements (source and The sin6_port field of the first and last array elements (source and
destination identifying address) will hold the source and destination destination endpoint address) will hold the source and destination UDP
UDP or TCP port number of the received packet. The sin6_port field of or TCP port number of the received packet. The sin6_port field of the
the intermediate elements of the array will be zero. intermediate elements of the array will be zero.
The flow label and priority sub-fields of the sin6_flowinfo field of the
source endpoint address will hold the flow label and priority values of
the received packet. The flow label and priority sub-fields of the
intermediate addresses and the destination endpoint address will be
zero. The loose/strict flag of the sin6_flowinfo field of the source
endpoint address and the intermediate addresses will be 1 if the leg of
the end-to-end path originating FROM that address was strict. The
loose/strict flag of the destination endpoint address will be 0.
The address buffer returned to the application in the recvfrom() or The address buffer returned to the application in the recvfrom() or
accept() functions when the IP_RCVSRCRT option is enabled is shown accept() functions when the IP_RCVSRCRT option is enabled is shown
below: below:
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[0] | Source Identifying Address | sockaddr_in6[0] | Source Endpoint Address
| | | |
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[1] | First Source-Route Hop Address | sockaddr_in6[1] | First Source-Route Hop Address
| | | |
+--------------------+ +--------------------+
. . . .
. . . .
. . . .
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[N-1] | Last Source-Route Hop Address | sockaddr_in6[N-1] | Last Source-Route Hop Address
| | | |
+--------------------+ +--------------------+
| | | |
| sockaddr_in6[N] | Destination Identifying Address | sockaddr_in6[N] | Destination Endpoint Address
| | | |
+--------------------+ +--------------------+
Address buffer when receiving a source route Address buffer when receiving a source route
Since IPv6 allows the number of elements in a source route to be very Since IPv6 allows the number of elements in a source route to be very
large, it is impractical for all applications that have enabled the large, it is impractical for all applications that have enabled the
reception of source routes to provide buffer space to hold the maximum reception of source routes to provide buffer space to hold the maximum
number of elements. Some applications may choose a buffer size that is number of elements. Some applications may choose a buffer size that is
appropriate for their own use. This means that it is possible that a appropriate for their own use. This means that it is possible that a
received source route may be too large to fit into the buffer provided received source route may be too large to fit into the buffer provided
by the application. In this circumstance, the system should return only by the application. In this circumstance, the system should return only
a single address element -- the source identifying address -- to the a single address element -- the source endpoint address -- to the
application. This case is clearly distinguishable to the application application. This case is clearly distinguishable to the application
because in all other cases, the system returns at least two address because in all other cases, the system returns at least two address
elements -- the source and destination identifying addresses. elements -- the source and destination endpoint addresses.
4.11. Unicast Hop Limit 4.11. Unicast Hop Limit
A new setsockopt() option is used to control the hop limit used in A new setsockopt() option is used to control the hop limit used in
outgoing unicast IPv6 packets. The name of this option is outgoing unicast IPv6 packets. The name of this option is
IP_UNICAST_HOPS, and it is used at the IPPROTO_IP layer. The macro IP_UNICAST_HOPS, and it is used at the IPPROTO_IP layer. The macro
definition for IP_UNICAST_HOPS resides in the <netinet/in.h> header definition for IP_UNICAST_HOPS resides in the <netinet/in.h> header
file. The following example illustrates how it is used: file. The following example illustrates how it is used:
int hoplimit = 10; int hoplimit = 10;
if (setsockopt(s, IPPROTO_IP, IP_UNICAST_HOPS, (char *) &hoplimit, if (setsockopt(s, IPPROTO_IP, IP_UNICAST_HOPS, (char *) &hoplimit,
sizeof(hoplimit)) == -1) sizeof(hoplimit)) == -1)
perror("setsockopt IP_UNICAST_HOPS); perror("setsockopt IP_UNICAST_HOPS);
When the IP_UNICAST_HOPS option is set with setsockopt(), the option When the IP_UNICAST_HOPS option is set with setsockopt(), the option
value given is used as the hop limit for all subsequent unicast packets value given is used as the hop limit for all subsequent unicast packets
skipping to change at page 18, line 18 skipping to change at page 18, line 35
specified, returning a completed hostent structure if the lookup specified, returning a completed hostent structure if the lookup
succeeds, or NULL, if the lookup fails. This function supports both the succeeds, or NULL, if the lookup fails. This function supports both the
AF_INET and AF_INET6 address families. If the af argument is AF_INET, AF_INET and AF_INET6 address families. If the af argument is AF_INET,
then len must be specified to be 4-octets and addr must refer to an IPv4 then len must be specified to be 4-octets and addr must refer to an IPv4
address. If af is AF_INET6, then len must be specified as 16-octets and address. If af is AF_INET6, then len must be specified as 16-octets and
addr must refer to an IPv6 address. If the addr argument is an addr must refer to an IPv6 address. If the addr argument is an
IPv4-mapped IPv6 address, an IPv4 address-to-name lookup is performed on IPv4-mapped IPv6 address, an IPv4 address-to-name lookup is performed on
the embedded IPv4 address. the embedded IPv4 address.
A new name-to-address translation library function is now under A new name-to-address translation library function is now under
development at Berkeley [2]. This new function, named getconninfo(), development at Berkeley. This new function, named getconninfo(), will
will subsume the functionality of gethostbyname(), hostname2addr(), as subsume the functionality of gethostbyname(), hostname2addr(), as well
well as the getservbyname() and getservbyport() functions. The new as the getservbyname() and getservbyport() functions. The new
function is specifically designed to be "transport independent", so it function is specifically designed to be "transport independent", so it
should be directly usable by IPv6 applications. should be directly usable by IPv6 applications.
System implementations should provide the addr2hostname() and System implementations should provide the addr2hostname() and
hostname2addr() functions in order to simplify the porting of existing hostname2addr() functions in order to simplify the porting of existing
IPv4 applications to IPv6. System implementations may also provide the IPv4 applications to IPv6. System implementations may also provide
getconninfo() function, once it is defined, so that newly written the getconninfo() function, once it is defined, so that newly written
applications can be transport independent. applications can be transport independent.
The getconninfo() function is expected to be published as a separate Specification of the getconninfo() function is published as a separate
specification document, not included in this spec. specification document [2], not included in this spec.
Implementations must retain the BSD gethostbyname() and gethostbyaddr() Implementations must retain the BSD gethostbyname() and gethostbyaddr()
functions in order to provide source and binary compatibility for functions in order to provide source and binary compatibility for
existing applications. existing applications.
4.14. Address Conversion Functions 4.14. Address Conversion Functions
BSD Unix provides two functions, inet_addr() and inet_ntoa(), to convert BSD Unix provides two functions, inet_addr() and inet_ntoa(), to convert
an IPv4 address between binary and printable form. IPv6 applications an IPv4 address between binary and printable form. IPv6 applications
need similar functions. We have defined the following two functions to need similar functions. We have defined the following two functions to
skipping to change at page 20, line 5 skipping to change at page 20, line 20
5. Security Considerations 5. Security Considerations
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. A companion document detailing the be accessible to applications. A companion document detailing the
extensions to the socket interfaces to support IPv6 security is being extensions to the socket interfaces to support IPv6 security is being
written [4]. At some point in the future, that document and this one written [4]. At some point in the future, that document and this one
may be merged into a single API specification. may be merged into a single API specification.
6. Change History 6. Change History
Changes from the June 1995 Edition
- Added capability for application to select loose or strict
source routing.
Changes from the March 1995 Edition Changes from the March 1995 Edition
- Changed the definition of the ipv6_addr structure to be an array - Changed the definition of the ipv6_addr structure to be an array
of sixteen chars instead of four longs. This change is of sixteen chars instead of four longs. This change is
necessary to support machines which implement the socket necessary to support machines which implement the socket
interface, but do not have a 32-bit addressable word. Virtually interface, but do not have a 32-bit addressable word. Virtually
all machines which provide the socket interface do support an all machines which provide the socket interface do support an
8-bit addressable data type. 8-bit addressable data type.
- Added a more detailed explanation that the data types defined in - Added a more detailed explanation that the data types defined in
skipping to change at page 22, line 12 skipping to change at page 22, line 33
have to make sure that these cookie values did not escape into have to make sure that these cookie values did not escape into
the Internet as the source or destination addresses of IPv4 the Internet as the source or destination addresses of IPv4
packets. packets.
Both of these techniques have drawbacks. This is an area for further Both of these techniques have drawbacks. This is an area for further
study. System implementors may use one of these techniques or implement study. System implementors may use one of these techniques or implement
another solution. another solution.
Acknowledgments Acknowledgments
Thanks to the many people who made suggestions and provided feedback to Thanks to the many people who made suggestions and provided feedback
to the numerous revisions of this document, including: Dave Borman, Mark to to the numerous revisions of this document, including: Marc Hasson,
Hasson, Alan Cox, Wan-Yen Hsu, Alex Conta, Richard Stevens, Dan Dave Borman, Alan Cox, Wan-Yen Hsu, Alex Conta, Richard Stevens, Dan
McDonald, Alan Lloyd, Christian Huitema, Steve Deering, Andrew McDonald, Alan Lloyd, Christian Huitema, Steve Deering, Andrew
Cherenson, Charles Lynn, Ran Atkinson, Erik Nordmark, Josh Osborne, Cherenson, Charles Lynn, Ran Atkinson, Erik Nordmark, Josh Osborne,
Glenn Trewitt, Fred Baker, Robert Elz, Dean D. Throop, and Francis Glenn Trewitt, Fred Baker, Robert Elz, Dean D. Throop, and Francis
Dupont. Craig Partridge suggested the addr2ascii() and ascii2addr() Dupont. Craig Partridge suggested the addr2ascii() and ascii2addr()
functions. functions.
Ramesh Govindan made a number of contributions and co-authored an Ramesh Govindan made a number of contributions and co-authored an
earlier version of this paper. earlier version of this paper.
References References
[1] R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification". [1] R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification".
Internet Draft. June 1995. Internet Draft. June 1995.
[2] K. Sklower. Private communication. [2] Keith Sklower. "Getconninfo(): An alternative to Gethostbyname()"
Internet Draft. June 1995.
[3] R. Hinden., S. Deering. "IP Version 6 Addressing Architecture". [3] R. Hinden., S. Deering. "IP Version 6 Addressing Architecture".
Internet Draft. June 1995. Internet Draft. June 1995.
[4] D. McDonald. "IPv6 Security API for BSD Sockets". Internet [4] D. McDonald. "IPv6 Security API for BSD Sockets". Internet
Draft. January 1995. Draft. January 1995.
Authors' Address Authors' Address
Jim Bound Jim Bound
 End of changes. 29 change blocks. 
78 lines changed or deleted 107 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/