draft-ietf-ipngwg-bsd-api-00.txt   draft-ietf-ipngwg-bsd-api-01.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)
March 13, 1995 June 21, 1995
IPv6 Program Interfaces for BSD Systems IPv6 Program Interfaces for BSD Systems
<draft-ietf-ipngwg-bsd-api-00.txt> <draft-ietf-ipngwg-bsd-api-01.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 September 13, 1995. Internet Drafts may This Internet Draft expires on December 20, 1995. 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 2, line 36 skipping to change at page 2, line 36
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. changes for IPv6 should not break existing programs.
- 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 the extended - Where possible, applications should be able to use the extended
API to interoperate with both IPv6 and IPv4 hosts. Applications API to interoperate with both IPv6 and IPv4 hosts. Applications
should not need know which type of host they are communicating should not need to know which type of host they are
with. communicating with.
- IPv6 addresses carried in data structures should be 64-bit - IPv6 addresses carried in data structures should be 64-bit
aligned. This is necessary in order to obtain optimum aligned. This is necessary in order to obtain optimum
performance on 64-bit machine architectures. performance on 64-bit machine architectures.
Because of the importance of providing IPv4 compatibility in the API, Because of the importance of providing IPv4 compatibility in the API,
our extensions are explicitly designed to operate on machines that our extensions are explicitly designed to operate on machines that
provide complete support for both IPv4 and IPv6. A subset of this API provide complete support for both IPv4 and IPv6. A subset of this API
could probably be designed for operation on systems that support only could probably be designed for operation on systems that support only
IPv6. However, this is not addressed in this document. IPv6. However, this is not addressed in this document.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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 which convert both IPv4 and IPv6 addresses, and two analogous functions which 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. A new Finally, a few miscellaneous features are needed to support IPv6. A new
interface is needed in order to support the IPv6 flow label. New interface is needed in order to support the IPv6 flow label and priority
interfaces are needed in order to receive IPv6 multicast packets and header fields. New interfaces are needed in order to receive IPv6
control the sending of multicast packets. And an interface is necessary multicast packets and control the sending of multicast packets. And an
in order to pass IPv6 source route information between the application interface is necessary in order to pass IPv6 source route information
and the system. between the application and the system.
3. Implementation Experience 3. Implementation Experience
A few issues exposed in experimenting with prototype implementations A few issues exposed in experimenting with prototype implementations of
of IPv6 helped to guide the design of this API. IPv6 helped to guide the design of this API:
First, we discovered that, by providing a way to represent the First, we discovered that, by providing a way to represent the addresses
addresses of IPv4 nodes as IPv6 addresses, we could greatly simplify of IPv4 nodes as IPv6 addresses, we could greatly simplify the
the applications' task of providing IPv4 compatibility. New applications' task of providing IPv4 compatibility. New applications
applications could interoperate with IPv4 nodes by using the new API could interoperate with IPv4 nodes by using the new API and expressing
and expressing the addresses of IPv4 nodes they interoperate with as the addresses of IPv4 nodes they interoperate with as IPv6 addresses.
IPv6 addresses. For example, a client application could open a TCP For example, a client application could open a TCP connection to an IPv4
connection to an IPv4 server by giving the IPv6 representation of the server by giving the IPv6 representation of the server's IPv4 address in
server's IPv4 address in the connect() call. Most applications do not the connect() call. Most applications do not even need to know whether
even need to know whether the peer is an IPv4 or IPv6 node. Such the peer is an IPv4 or IPv6 node. Such applications can simply treat
applications can simply treat IPv6 addresses as opaque values; They IPv6 addresses as opaque values; They need not understand the
need not understand the "structure" by which IPv4 addresses are "structure" by which IPv4 addresses are encoded within IPv6 addresses.
encoded within IPv6 addresses. Yet the structure can be decoded by Yet the structure can be decoded by those applications that do need to
those applications that do need to know whether the peer is IPv6 or know whether the peer is IPv6 or IPv4. This should prove to be a
IPv4. This should prove to be a significant simplification since most significant simplification since most applications will need to
applications will need to interoperate with both IPv4 and IPv6 nodes interoperate with both IPv4 and IPv6 nodes for some time to come.
for some time to come.
Second, we learned that existing applications written to the IPv4 API Second, we learned that existing applications written to the IPv4 API
could be made to interoperate with IPv6 nodes to a limited degree. This could be made to interoperate with IPv6 nodes to a limited degree. This
technique does not work for all applications, but does for certain technique does not work for all applications, but does for certain
applications, such as those that do not "look at" the peer address that applications, such as those that do not "look at" the peer address that
is provided by the API. (e.g. the source address provided by the is provided by the API. (e.g. the source address provided by the
recvfrom() function when a UDP packet is received, or the client address recvfrom() function when a UDP packet is received, or the client address
returned by the accept() function.) returned by the accept() function.)
Third, we learned that the common application practice of passing open Third, we learned that the common application practice of passing open
socket descriptors between processes across an exec() call can cause socket descriptors between processes across an exec() call can cause
problems. It is possible, for example, for an application using the problems. It is possible, for example, for an application using the
extended API to pass an open socket to an older application using the extended API to pass an open socket to an older application using the
original API. The old application could be confused if the socket original API. The old application could be confused if the socket
functions return IPv6 address structures to it. The solution designed functions return IPv6 address structures to it. The solution designed
was to provide a mechanism by which applications could have explicit was to provide a mechanism by which applications could have explicit
control over what form of addresses are returned. control over what form of addresses are returned.
4. Interface Specification 4. Interface Specification
This section specifies the interface changes for IPv6.
The data types of the structure elements given in the following section
are intended to be examples, not absolute requirements. System
implementations may use other types if they are appropriate. In some
cases, such as when a field of a data structure holds a protocol value,
the structure field must be of some minimum size. These size
requirements are noted in the text. For example, since the UDP and TCP
port values are 16-bit quantities, the sin6_port field must be at least
a 16-bit data types. We specify the sin6_port field as a u_short type,
but an implementation may use any data type that is at least 16-bits
long.
4.1. New Address Family 4.1. New Address Family
A new address family macro, named AF_INET6, is defined in A new address family macro, named AF_INET6, is defined in
<sys/socket.h>. The AF_INET6 definition is used to distinguish between <sys/socket.h>. The AF_INET6 definition is used to distinguish between
the original sockaddr_in address data structure, and the new the original sockaddr_in address data structure, and the new
sockaddr_in6 data structure. sockaddr_in6 data structure.
A new protocol family macro, named PF_INET6, is defined in A new protocol family macro, named PF_INET6, is defined in
<sys/socket.h>. Like most of the other protocol family macros, this <sys/socket.h>. Like most of the other protocol family macros, this
will usually be defined to have the same value as the corresponding will usually be defined to have the same value as the corresponding
skipping to change at page 5, line 30 skipping to change at page 5, line 43
The PF_INET6 is used in the first argument to the socket() function to The PF_INET6 is used in the first argument to the socket() function to
indicate that an IPv6 socket is being created. indicate that an IPv6 socket is being created.
4.2. IPv6 Address Data Structure 4.2. IPv6 Address Data Structure
A new data structure to hold a single IPv6 address is defined in A new data structure to hold a single IPv6 address is defined in
<netinet/in.h>: <netinet/in.h>:
struct in_addr6 { struct in_addr6 {
u_long s6_addr[4]; /* IPv6 address */ u_char s6_addr[16]; /* IPv6 address */
} }
This data structure contains an array of four 32-bit elements, which This data structure contains an array of sixteen 8-bit elements, which
make up one 128-bit IPv6 address. make up one 128-bit IPv6 address.
The IPv6 address is stored in in network byte order. The IPv6 address is stored in network byte order.
4.3. Socket Address Structure for 4.3 BSD-Based Systems 4.3. Socket Address Structure for 4.3 BSD-Based Systems
In the socket interface, a different protocol-specific data structure In the socket interface, a different protocol-specific data structure
is defined to carry the addresses for each of the protocol suite. is defined to carry the addresses for each of the protocol suite.
Each protocol-specific data structure is designed so it can be cast Each protocol-specific data structure is designed so it can be cast
into a protocol-independent data structure -- the "sockaddr" into a protocol-independent data structure -- the "sockaddr"
structure. Each has a "family" field which overlays the "sa_family" structure. Each has a "family" field which overlays the "sa_family"
of the sockaddr data structure. This field can be used to identify of the sockaddr data structure. This field can be used to identify
the type of the data structure. the type of the data structure.
The sockaddr_in structure is the protocol-specific address data The sockaddr_in structure is the protocol-specific address data
structure for IPv4. It is used to pass addresses between applications structure for IPv4. It is used to pass addresses between applications
and the system in the socket functions. We have defined the following and the system in the socket functions. We have defined the following
structure in <netinet/in.h> to carry IPv6 addresses: structure in <netinet/in.h> to carry IPv6 addresses:
struct sockaddr_in6 { struct sockaddr_in6 {
u_short sin6_family; /* AF_INET6 */ u_short sin6_family; /* AF_INET6 */
u_short sin6_port; /* Transport layer port # */ u_short sin6_port; /* Transport layer port # */
u_long sin6_flowlabel; /* IPv6 flow label */ u_long sin6_flowinfo; /* IPv6 flow information */
struct in_addr6 sin6_addr; /* IPv6 address */ struct in_addr6 sin6_addr; /* IPv6 address */
}; };
This structure is designed to be compatible with the sockaddr data This structure is designed to be compatible with the sockaddr data
structure used in the 4.3 BSD release. structure used in the 4.3 BSD release.
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_flowlabel 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 the
28-bit IPv6 flow label. The IPv6 flow label is represented as the 24-bit IPv6 flow label, and the 4-bit priority field. The IPv6 flow
low-order 28-bits of a 32-bit value, which is stored in network byte label is represented as the low-order 24-bits of the 32-bit field, and
order in the sin6_flowlabel field. The use of this field is explained the priority is represented in the next 4-bits above this. The
in sec 4.8. high-order 4 bits of this field are reserved. The sin6_flowinfo field
is stored in network byte order. The use of this field is explained in
sec 4.8.
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 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 done for optimum performance on 64-bit architectures. is done for optimum performance on 64-bit architectures.
The data types of the structure elements given here and in the
previous section are intended as examples only. System
implementations may use other types if they are appropriate for the
system they are used on.
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 was changed from a 16-bit value to an 8-bit value, and the structure was changed from a 16-bit value to an 8-bit value, and the
space saved used to hold a length field, named "sa_len". The space saved used to hold a length field, named "sa_len". The
sockaddr_in6 data structure given in the previous section can not be sockaddr_in6 data structure given in the previous section can not be
correctly cast into the newer sockaddr data structure. For this correctly cast into the newer sockaddr data structure. For this
reason, we have defined the following alternative IPv6 address data reason, we have defined the following alternative IPv6 address data
structure to be used on systems based on 4.4 BSD: structure to be used on systems 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_flowlabel; /* IPv6 flow label */ 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 inclusion of the length field, and the change of the family field the inclusion of the length field, and the change of the family field
to a 8-bit data type. The definitions of all the other fields are to a 8-bit data type. The definitions of all the other fields are
identical to the 4.3 BSD variant defined in the previous section. identical 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
skipping to change at page 7, line 42 skipping to change at page 7, line 50
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 = 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
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 8, line 26 skipping to change at page 8, line 40
s = socket (PF_INET6, SOCK_DGRAM, 0); s = socket (PF_INET6, SOCK_DGRAM, 0);
Once the application has created a PF_INET6 socket, it must use the Once the application has created a PF_INET6 socket, it must use the
sockaddr_in6 address structure when passing addresses in to the system. sockaddr_in6 address structure when passing addresses in to the system.
The functions which the application uses to pass addresses into the The functions which the application uses to pass addresses into the
system are: system are:
bind() bind()
connect() connect()
sendmsg()
sendto() sendto()
The system will use the sockaddr_in6 address structure to return The system will use the sockaddr_in6 address structure to return
addresses to applications that are using PF_INET6 sockets. The addresses to applications that are using PF_INET6 sockets. The
functions that return an address from the system to an application functions that return an address from the system to an application
are: are:
accept() accept()
recvfrom() recvfrom()
recvmsg()
getpeername() getpeername()
getsockname() getsockname()
No changes to the syntax of the socket functions are needed to support No changes to the syntax of the socket functions are needed to support
IPv6, since the all of the "address carrying" functions use an opaque IPv6, since the all of the "address carrying" functions use an opaque
address pointer, and carry an address length as a function argument. address pointer, and carry an address length as a function argument.
4.6. Compatibility with IPv4 Applications 4.6. Compatibility with IPv4 Applications
In order to support the large base of applications using the original In order to support the large base of applications using the original
skipping to change at page 11, line 10 skipping to change at page 11, line 24
if (getsockopt(s, IPPROTO_IP, IP_ADDRFORM, (char *) &addrform, if (getsockopt(s, IPPROTO_IP, IP_ADDRFORM, (char *) &addrform,
&len) == -1) &len) == -1)
perror("getsockopt IP_ADDRFORM"); perror("getsockopt IP_ADDRFORM");
if (addrform == PF_INET) if (addrform == PF_INET)
printf("This is an IPv4 socket.\n"); printf("This is an IPv4 socket.\n");
else if (addrform == PF_INET6) else if (addrform == PF_INET6)
printf("This is an IPv6 socket.\n"); printf("This is an IPv6 socket.\n");
else else
printf("This system is broken.\n"); printf("This system is broken.\n");
4.9. Flow Label 4.9. Flow Information
The IPv6 header has a 28-bit field to hold a "flow label". Applications The IPv6 header has a 24-bit field to hold a "flow label", and a 4-bit
have control over what flow label value is used in packets that they field to hold a "priority". Applications have control over what values
originate, and have access to the flow label value of packets that they for these fields are used in packets that they originate, and have
send. access to the field values of packets that they receive.
The sin6_flowlabel field of the sockaddr_in6 structure is used to The sin6_flowinfo field of the sockaddr_in6 structure is used to carry
carry the flow label between the application and the system. An the flow information between the application and the system. An
application may specify a flow label to use in the transmitted packets application may specify a flow label and priority to use in the
of an actively opened TCP connection by setting the sin6_flowlabel transmitted packets of an actively opened TCP connection by setting the
field of the destination address sockaddr_in6 structure passed in the sin6_flowinfo field of the destination address sockaddr_in6 structure
connect() function. An application may specify the flow label to use passed in the connect() function. An application may specify the flow
in transmitted UDP packets by setting the sin6_flowlabel field of the label and priority to use in transmitted UDP packets by setting the
destination address sockaddr_in6 structure passed in the sendto() sin6_flowinfo field of the destination address sockaddr_in6 structure
function. If an application does not care what flow label is used, it passed in the sendto() function. If an application does not care what
should set the flowlabel value to zero. values are used, it should set the flowinfo value to zero.
An application may specify the flow label to use in transmitted packets An application may specify the flow label and priority to use in
of a passively accepted TCP connection, by setting the sin6_flowlabel transmitted packets of a passively accepted TCP connection, by setting
field of the address passed in the bind() function. the sin6_flowinfo field of the address passed in the bind() function.
The flow label and priority that appeared in received UDP packets are
passed up to the application in the sin6_flowinfo field of the source
address sockaddr_in6 structure that is returned in the recvfrom() call.
The flow information that appeared in the received SYN segment of a
passively accepted TCP connection is returned to the application in the
source address sin6_flowinfo field of the sockaddr_in6 structure that is
The flow label that appeared in received UDP packets is passed up to
the application in the sin6_flowlabel field of the source address
sockaddr_in6 structure that is returned in the recvfrom() call. The
flow label that appeared in the received SYN segment of a passively
accepted TCP connection is returned to the application in the source
address sin6_flowlabel field of the sockaddr_in6 structure that is
passed in the accept() call. passed in the accept() call.
4.10. Handling IPv6 Source Routes 4.10. Handling IPv6 Source Routes
IPv6 makes more use of the source routing mechanism than IPv4. In order IPv6 makes more use of the source routing mechanism than IPv4. In order
for source routing to operate properly, the node receiving a request for source routing to operate properly, the node receiving a request
packet that bears a source route must reverse that source route when packet that bears a source route must reverse that source route when
sending the reply. In the case of TCP, the reversal can be done in the sending the reply. In the case of TCP, the reversal can be done in the
transport protocol implementation transparently to the application. But transport protocol implementation transparently to the application. But
in the case of UDP, the application must perform the reversal itself. in the case of UDP, the application must perform the reversal itself.
skipping to change at page 12, line 30 skipping to change at page 12, line 45
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 identifying address, and the last element of
the array represents the source identifying address. If the application the array represents the source identifying address. If the application
provides a source route, the source identifying address can not be provides a source route, the source identifying address can not be
omitted. The sin6_addr field of the source identifying address may be omitted. The sin6_addr field of the source identifying address may be
set to zero, however, in which case the system will select an set to zero, however, in which case the system will select an
appropriate source address. The sin6_port field of the destination appropriate source address. The sin6_port field of the destination
identifying address must be assigned. The sin_port field of the source identifying address must be assigned. The sin_port field of the source
identifying address may be set to zero, in which case the system will identifying address may be set to zero, in which case the system will
select an appropriate source port number. The sin6_port and select an appropriate source port number. The sin6_port and
sin6_flowlabel fields of the intermediate addresses must be set to zero. sin6_flowinfo fields of the intermediate addresses must be set to zero.
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 Identifying Address
| | | |
+--------------------+ +--------------------+
| | | |
skipping to change at page 19, line 51 skipping to change at page 19, line 51
fails. fails.
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. Changes from October 1994 Edition 6. Change History
Changes from the March 1995 Edition
- Changed the definition of the ipv6_addr structure to be an array
of sixteen chars instead of four longs. This change is
necessary to support machines which implement the socket
interface, but do not have a 32-bit addressable word. Virtually
all machines which provide the socket interface do support an
8-bit addressable data type.
- Added a more detailed explanation that the data types defined in
this documented are not intended to be hard and fast
requirements. Systems may use other data types if they wish.
- Added a note flagging the fact that the sockaddr_in6 structure
is not the same size as the sockaddr structure.
- Changed the sin6_flowlabel field to sin6_flowinfo to accommodate
the addition of the priority field to the IPv6 header.
Changes from the October 1994 Edition
- Added variant of sockaddr_in6 for 4.4 BSD-based systems (sa_len - Added variant of sockaddr_in6 for 4.4 BSD-based systems (sa_len
compatibility). compatibility).
- Removed references to SIT transition specification, and added - Removed references to SIT transition specification, and added
reference to addressing architecture document, for definition of reference to addressing architecture document, for definition of
IPv4-mapped addresses. IPv4-mapped addresses.
- Added a solution to the problem of the application not providing - Added a solution to the problem of the application not providing
enough buffer space to hold a received source route. enough buffer space to hold a received source route.
skipping to change at page 21, line 41 skipping to change at page 22, line 13
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
earlier revisions of this document. Comments were provided by: Richard to the numerous revisions of this document, including: Dave Borman, Mark
Stevens, Dan McDonald, Christian Huitema, Steve Deering, Andrew Hasson, Alan Cox, Wan-Yen Hsu, Alex Conta, Richard Stevens, Dan
Cherenson, Charles Lynn, Ran Atkinson, Erik Nordmark, Glenn Trewitt, McDonald, Alan Lloyd, Christian Huitema, Steve Deering, Andrew
Fred Baker, Robert Elz, Dean D. Throop, and Francis Dupont. Craig Cherenson, Charles Lynn, Ran Atkinson, Erik Nordmark, Josh Osborne,
Partridge suggested the addr2ascii() and ascii2addr() functions. Glenn Trewitt, Fred Baker, Robert Elz, Dean D. Throop, and Francis
Dupont. Craig Partridge suggested the addr2ascii() and ascii2addr()
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. October 1994. Internet Draft. June 1995.
[2] K. Sklower. Private communication. [2] K. Sklower. Private communication.
[3] R. Hinden. "IP Next Generation Addressing Architecture". [3] R. Hinden., S. Deering. "IP Version 6 Addressing Architecture".
Internet Draft. October 1994. 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. 30 January 1995. Draft. January 1995.
Authors' Address Authors' Address
Jim Bound Jim Bound
Digital Equipment Corporation Digital Equipment Corporation
110 Spitbrook Road ZK3-3/U14 110 Spitbrook Road ZK3-3/U14
Nashua, NH 03062-2698 Nashua, NH 03062-2698
Phone: +1 603 881 0400 Phone: +1 603 881 0400
Email: bound@zk3.dec.com Email: bound@zk3.dec.com
 End of changes. 32 change blocks. 
80 lines changed or deleted 123 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/