option by specifying a corresponding ancillary data item that could
disable the sticky option when being used as an argument for a socket
option. For example, if the application has set IPV6_HOPOPTS as a
sticky option and later passes IPV6_HOPOPTS with a zero length as an
ancillary data item, the packet will not have a Hop-by-Hop options
header.
5. Extensions to Socket Ancillary Data
This specification uses ancillary data as defined in Posix with some
compatible extensions, which are described in the following
subsections. Section 20 will provide a detailed overview of
ancillary data and related structures and macros, including the
extensions.
5.1. CMSG_NXTHDR
struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr,
const struct cmsghdr *cmsg);
CMSG_NXTHDR() returns a pointer to the cmsghdr structure describing
the next ancillary data object. Mhdr is a pointer to a msghdr
structure and cmsg is a pointer to a cmsghdr structure. If there is
not another ancillary data object, the return value is NULL.
The following behavior of this macro is new to this API: if the value
of the cmsg pointer is NULL, a pointer to the cmsghdr structure
describing the first ancillary data object is returned. That is,
CMSG_NXTHDR(mhdr, NULL) is equivalent to CMSG_FIRSTHDR(mhdr). If
there are no ancillary data objects, the return value is NULL.
5.2. CMSG_SPACE
socklen_t CMSG_SPACE(socklen_t length);
This macro is new with this API. Given the length of an ancillary
data object, CMSG_SPACE() returns an upper bound on the space
required by the object and its cmsghdr structure, including any
padding needed to satisfy alignment requirements. This macro can be
used, for example, when allocating space dynamically for the
ancillary data. This macro should not be used to initialize the
cmsg_len member of a cmsghdr structure; instead use the CMSG_LEN()
macro.
5.3. CMSG_LEN
socklen_t CMSG_LEN(socklen_t length);
This macro is new with this API. Given the length of an ancillary
data object, CMSG_LEN() returns the value to store in the cmsg_len
member of the cmsghdr structure, taking into account any padding
needed to satisfy alignment requirements.
Note the difference between CMSG_SPACE() and CMSG_LEN(), shown also
in the figure in Section 20.2: the former accounts for any required
padding at the end of the ancillary data object and the latter is the
actual length to store in the cmsg_len member of the ancillary data
object.
6. Packet Information
There are five pieces of information that an application can specify
for an outgoing packet using ancillary data:
1. the source IPv6 address,
2. the outgoing interface index,
3. the outgoing hop limit,
4. the next hop address, and
5. the outgoing traffic class value.
Four similar pieces of information can be returned for a received
packet as ancillary data:
1. the destination IPv6 address,
2. the arriving interface index,
3. the arriving hop limit, and
4. the arriving traffic class value.
The first two pieces of information are contained in an in6_pktinfo
structure that is set with setsockopt() or sent as ancillary data
with sendmsg() and received as ancillary data with recvmsg(). This
structure is defined as a result of including <netinet/in.h>.
struct in6_pktinfo {
struct in6_addr ipi6_addr; /* src/dst IPv6 address */
unsigned int ipi6_ifindex; /* send/recv interface index */
};
In the socket option and cmsghdr level will be IPPROTO_IPV6, the type
will be IPV6_PKTINFO, and the first byte of the option value and
cmsg_data[] will be the first byte of the in6_pktinfo structure. An
application can clear any sticky IPV6_PKTINFO option by doing a
"regular" setsockopt with ipi6_addr being in6addr_any and
ipi6_ifindex being zero.
This information is returned as ancillary data by recvmsg() only if
the application has enabled the IPV6_RECVPKTINFO socket option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
(Note: The hop limit is not contained in the in6_pktinfo structure
for the following reason. Some UDP servers want to respond to client
requests by sending their reply out the same interface on which the
request was received and with the source IPv6 address of the reply
equal to the destination IPv6 address of the request. To do this the
application can enable just the IPV6_RECVPKTINFO socket option and
then use the received control information from recvmsg() as the
outgoing control information for sendmsg(). The application need not
examine or modify the in6_pktinfo structure at all. But if the hop
limit were contained in this structure, the application would have to
parse the received control information and change the hop limit
member, since the received hop limit is not the desired value for an
outgoing packet.)
6.1. Specifying/Receiving the Interface
Interfaces on an IPv6 node are identified by a small positive
integer, as described in Section 4 of [RFC-3493]. That document also
describes a function to map an interface name to its interface index,
a function to map an interface index to its interface name, and a
function to return all the interface names and indexes. Notice from
this document that no interface is ever assigned an index of 0.
When specifying the outgoing interface, if the ipi6_ifindex value is
0, the kernel will choose the outgoing interface.
The ordering among various options that can specify the outgoing
interface, including IPV6_PKTINFO, is defined in Section 6.7.
When the IPV6_RECVPKTINFO socket option is enabled, the received
interface index is always returned as the ipi6_ifindex member of the
in6_pktinfo structure.
6.2. Specifying/Receiving Source/Destination Address
The source IPv6 address can be specified by calling bind() before
each output operation, but supplying the source address together with
the data requires less overhead (i.e., fewer system calls) and
requires less state to be stored and protected in a multithreaded
application.
When specifying the source IPv6 address as ancillary data, if the
ipi6_addr member of the in6_pktinfo structure is the unspecified
address (IN6ADDR_ANY_INIT or in6addr_any), then (a) if an address is
currently bound to the socket, it is used as the source address, or
(b) if no address is currently bound to the socket, the kernel will
choose the source address. If the ipi6_addr member is not the
unspecified address, but the socket has already bound a source
address, then the ipi6_addr value overrides the already-bound source
address for this output operation only.
The kernel must verify that the requested source address is indeed a
unicast address assigned to the node. When the address is a scoped
one, there may be ambiguity about its scope zone. This is
particularly the case for link-local addresses. In such a case, the
kernel must first determine the appropriate scope zone based on the
zone of the destination address or the outgoing interface (if known),
then qualify the address. This also means that it is not feasible to
specify the source address for a non-binding socket by the
IPV6_PKTINFO sticky option, unless the outgoing interface is also
specified. The application should simply use bind() for such
purposes.
IPV6_PKTINFO can also be used as a sticky option for specifying the
socket's default source address. However, the ipi6_addr member must
be the unspecified address for TCP sockets, because it is not
possible to dynamically change the source address of a TCP
connection. When the IPV6_PKTINFO option is specified for a TCP
socket with a non-unspecified address, the call will fail. This
restriction should be applied even before the socket binds a specific
address.
When the in6_pktinfo structure is returned as ancillary data by
recvmsg(), the ipi6_addr member contains the destination IPv6 address
from the received packet.
6.3. Specifying/Receiving the Hop Limit
The outgoing hop limit is normally specified with either the
IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket
option, both of which are described in [RFC-3493]. Specifying the
hop limit as ancillary data lets the application override either the
kernel's default or a previously specified value, for either a
unicast destination or a multicast destination, for a single output
operation. Returning the received hop limit is useful for IPv6
applications that need to verify that the received hop limit is 255
(e.g., that the packet has not been forwarded).
The received hop limit is returned as ancillary data by recvmsg()
only if the application has enabled the IPV6_RECVHOPLIMIT socket
option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
In the cmsghdr structure containing this ancillary data, the
cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
IPV6_HOPLIMIT, and the first byte of cmsg_data[] will be the first
byte of the integer hop limit.
Nothing special need be done to specify the outgoing hop limit: just
specify the control information as ancillary data for sendmsg(). As
specified in [RFC-3493], the interpretation of the integer hop limit
value is
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
This API defines IPV6_HOPLIMIT as an ancillary-only option, that is,
the option name cannot be used as a socket option. This is because
[RFC-3493] has more fine-grained socket options; IPV6_UNICAST_HOPS
and IPV6_MULTICAST_HOPS.
6.4. Specifying the Next Hop Address
The IPV6_NEXTHOP ancillary data object specifies the next hop for the
datagram as a socket address structure. In the cmsghdr structure
containing this ancillary data, the cmsg_level member will be
IPPROTO_IPV6, the cmsg_type member will be IPV6_NEXTHOP, and the
first byte of cmsg_data[] will be the first byte of the socket
address structure.
This is a privileged option. (Note: It is implementation defined and
beyond the scope of this document to define what "privileged" means.
Unix systems use this term to mean the process must have an effective
user ID of 0.)
This API only defines the case where the socket address contains an
IPv6 address (i.e., the sa_family member is AF_INET6). And, in this
case, the node identified by that address must be a neighbor of the
sending host. If that address equals the destination IPv6 address of
the datagram, then this is equivalent to the existing SO_DONTROUTE
socket option.
This option does not have any meaning for multicast destinations. In
such a case, the specified next hop will be ignored.
When the outgoing interface is specified by IPV6_PKTINFO as well, the
next hop specified by this option must be reachable via the specified
interface.
In order to clear a sticky IPV6_NEXTHOP option the application must
issue a setsockopt for IPV6_NEXTHOP with a zero length.
6.5. Specifying/Receiving the Traffic Class value
The outgoing traffic class is normally set to 0. Specifying the
traffic class as ancillary data lets the application override either
the kernel's default or a previously specified value, for either a
unicast destination or a multicast destination, for a single output
operation. Returning the received traffic class is useful for
programs such as a diffserv debugging tool and for user level ECN
(explicit congestion notification) implementation.
The received traffic class is returned as ancillary data by recvmsg()
only if the application has enabled the IPV6_RECVTCLASS socket
option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVTCLASS, &on, sizeof(on));
In the cmsghdr structure containing this ancillary data, the
cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte
of the integer traffic class.
To specify the outgoing traffic class value, just specify the control
information as ancillary data for sendmsg() or using setsockopt().
Just like the hop limit value, the interpretation of the integer
traffic class value is
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
In order to clear a sticky IPV6_TCLASS option the application can
specify -1 as the value.
There are cases where the kernel needs to control the traffic class
value and conflicts with the user-specified value on the outgoing
traffic. An example is an implementation of ECN in the kernel,
setting 2 bits of the traffic class value. In such cases, the kernel
should override the user-specified value. On the incoming traffic,
the kernel may mask some of the bits in the traffic class field.
6.6. Additional Errors with sendmsg() and setsockopt()
With the IPV6_PKTINFO socket option there are no additional errors
possible with the call to recvmsg(). But when specifying the
outgoing interface or the source address, additional errors are
possible from sendmsg() or setsockopt(). Note that some
implementations might only be able to return this type of errors for
setsockopt(). The following are examples, but some of these may not
be provided by some implementations, and some implementations may
define additional errors:
ENXIO The interface specified by ipi6_ifindex does not exist.
ENETDOWN The interface specified by ipi6_ifindex is not enabled
for IPv6 use.
EADDRNOTAVAIL ipi6_ifindex specifies an interface but the address
ipi6_addr is not available for use on that interface.
EHOSTUNREACH No route to the destination exists over the interface
specified by ipi6_ifindex.
6.7. Summary of Outgoing Interface Selection
This document and [RFC-3493] specify various methods that affect the
selection of the packet's outgoing interface. This subsection
summarizes the ordering among those in order to ensure deterministic
behavior.
For a given outgoing packet on a given socket, the outgoing interface
is determined in the following order:
1. if an interface is specified in an IPV6_PKTINFO ancillary data
item, the interface is used.
2. otherwise, if an interface is specified in an IPV6_PKTINFO sticky
option, the interface is used.
3. otherwise, if the destination address is a multicast address and
the IPV6_MULTICAST_IF socket option is specified for the socket,
the interface is used.
4. otherwise, if an IPV6_NEXTHOP ancillary data item is specified,
the interface to the next hop is used.
5. otherwise, if an IPV6_NEXTHOP sticky option is specified, the
interface to the next hop is used.
6. otherwise, the outgoing interface should be determined in an
implementation dependent manner.
The ordering above particularly means if the application specifies an
interface by the IPV6_MULTICAST_IF socket option (described in [RFC-
3493]) as well as specifying a different interface by the
IPV6_PKTINFO sticky option, the latter will override the former for
every multicast packet on the corresponding socket. The reason for
the ordering comes from expectation that the source address is
specified as well and that the pair of the address and the outgoing
interface should be preferred.
In any case, the kernel must also verify that the source and
destination addresses do not break their scope zones with regard to
the outgoing interface.
7. Routing Header Option
Source routing in IPv6 is accomplished by specifying a Routing header
as an extension header. There can be different types of Routing
headers, but IPv6 currently defines only the Type 0 Routing header
[RFC-2460]. This type supports up to 127 intermediate nodes (limited
by the length field in the extension header). With this maximum
number of intermediate nodes, a source, and a destination, there are
128 hops.
Source routing with the IPv4 sockets API (the IP_OPTIONS socket
option) requires the application to build the source route in the
format that appears as the IPv4 header option, requiring intimate
knowledge of the IPv4 options format. This IPv6 API, however,
defines six functions that the application calls to build and examine
a Routing header, and the ability to use sticky options or ancillary
data to communicate this information between the application and the
kernel using the IPV6_RTHDR option.
Three functions build a Routing header:
inet6_rth_space() - return #bytes required for Routing header
inet6_rth_init() - initialize buffer data for Routing header
inet6_rth_add() - add one IPv6 address to the Routing header
Three functions deal with a returned Routing header:
inet6_rth_reverse() - reverse a Routing header
inet6_rth_segments() - return #segments in a Routing header
inet6_rth_getaddr() - fetch one address from a Routing header
The function prototypes for these functions are defined as a result
of including <netinet/in.h>.
To receive a Routing header the application must enable the
IPV6_RECVRTHDR socket option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
Each received Routing header is returned as one ancillary data object
described by a cmsghdr structure with cmsg_type set to IPV6_RTHDR.
When multiple Routing headers are received, multiple ancillary data
objects (with cmsg_type set to IPV6_RTHDR) will be returned to the
application.
To send a Routing header the application specifies it either as
ancillary data in a call to sendmsg() or using setsockopt(). For the
sending side, this API assumes the number of occurrences of the
Routing header as described in [RFC-2460]. That is, applications can
only specify at most one outgoing Routing header.
The application can remove any sticky Routing header by calling
setsockopt() for IPV6_RTHDR with a zero option length.
When using ancillary data a Routing header is passed between the
application and the kernel as follows: The cmsg_level member has a
value of IPPROTO_IPV6 and the cmsg_type member has a value of
IPV6_RTHDR. The contents of the cmsg_data[] member is implementation
dependent and should not be accessed directly by the application, but
should be accessed using the six functions that we are about to
describe.
The following constant is defined as a result of including the
<netinet/in.h>:
#define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */
When a Routing header is specified, the destination address specified
for connect(), sendto(), or sendmsg() is the final destination
address of the datagram. The Routing header then contains the
addresses of all the intermediate nodes.
7.1. inet6_rth_space
socklen_t inet6_rth_space(int type, int segments);
This function returns the number of bytes required to hold a Routing
header of the specified type containing the specified number of
segments (addresses). For an IPv6 Type 0 Routing header, the number
of segments must be between 0 and 127, inclusive. The return value
is just the space for the Routing header. When the application uses
ancillary data it must pass the returned length to CMSG_SPACE() to
determine how much memory is needed for the ancillary data object
(including the cmsghdr structure).
If the return value is 0, then either the type of the Routing header
is not supported by this implementation or the number of segments is
invalid for this type of Routing header.
(Note: This function returns the size but does not allocate the space
required for the ancillary data. This allows an application to
allocate a larger buffer, if other ancillary data objects are
desired, since all the ancillary data objects must be specified to
sendmsg() as a single msg_control buffer.)
7.2. inet6_rth_init
void *inet6_rth_init(void *bp, socklen_t bp_len, int type,
int segments);
This function initializes the buffer pointed to by bp to contain a
Routing header of the specified type and sets ip6r_len based on the
segments parameter. bp_len is only used to verify that the buffer is
large enough. The ip6r_segleft field is set to zero; inet6_rth_add()
will increment it.
When the application uses ancillary data the application must
initialize any cmsghdr fields.
The caller must allocate the buffer and its size can be determined by
calling inet6_rth_space().
Upon success the return value is the pointer to the buffer (bp), and
this is then used as the first argument to the inet6_rth_add()
function. Upon an error the return value is NULL.
7.3. inet6_rth_add
int inet6_rth_add(void *bp, const struct in6_addr *addr);
This function adds the IPv6 address pointed to by addr to the end of
the Routing header being constructed.
If successful, the segleft member of the Routing Header is updated to
account for the new address in the Routing header and the return
value of the function is 0. Upon an error the return value of the
function is -1.
7.4. inet6_rth_reverse
int inet6_rth_reverse(const void *in, void *out);
This function takes a Routing header extension header (pointed to by
the first argument) and writes a new Routing header that sends
datagrams along the reverse of that route. The function reverses the
order of the addresses and sets the segleft member in the new Routing
header to the number of segments. Both arguments are allowed to
point to the same buffer (that is, the reversal can occur in place).
The return value of the function is 0 on success, or -1 upon an
error.
7.5. inet6_rth_segments
int inet6_rth_segments(const void *bp);
This function returns the number of segments (addresses) contained in
the Routing header described by bp. On success the return value is
zero or greater. The return value of the function is -1 upon an
error.
7.6. inet6_rth_getaddr
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
This function returns a pointer to the IPv6 address specified by
index (which must have a value between 0 and one less than the value
returned by inet6_rth_segments()) in the Routing header described by
bp. An application should first call inet6_rth_segments() to obtain
the number of segments in the Routing header.
Upon an error the return value of the function is NULL.
8. Hop-By-Hop Options
A variable number of Hop-by-Hop options can appear in a single Hop-
by-Hop options header. Each option in the header is TLV-encoded with
a type, length, and value. This IPv6 API defines seven functions
that the application calls to build and examine a Hop-by_Hop options
header, and the ability to use sticky options or ancillary data to
communicate this information between the application and the kernel.
This uses the IPV6_HOPOPTS for a Hop-by-Hop options header.
Today several Hop-by-Hop options are defined for IPv6. Two pad
options, Pad1 and PadN, are for alignment purposes and are
automatically inserted by the inet6_opt_XXX() routines and ignored by
the inet6_opt_XXX() routines on the receive side. This section of
the API is therefore defined for other (and future) Hop-by-Hop
options that an application may need to specify and receive.
Four functions build an options header:
inet6_opt_init() - initialize buffer data for options header
inet6_opt_append() - add one TLV option to the options header
inet6_opt_finish() - finish adding TLV options to the options
header
inet6_opt_set_val() - add one component of the option content to
the option
Three functions deal with a returned options header:
inet6_opt_next() - extract the next option from the options
header
inet6_opt_find() - extract an option of a specified type from
the header
inet6_opt_get_val() - retrieve one component of the option
content
Individual Hop-by-Hop options (and Destination options, which are
described in Section 9 and are very similar to the Hop-by-Hop
options) may have specific alignment requirements. For example, the
4-byte Jumbo Payload length should appear on a 4-byte boundary, and
IPv6 addresses are normally aligned on an 8-byte boundary. These
requirements and the terminology used with these options are
discussed in Section 4.2 and Appendix B of [RFC-2460]. The alignment
of first byte of each option is specified by two values, called x and
y, written as "xn + y". This states that the option must appear at
an integer multiple of x bytes from the beginning of the options
header (x can have the values 1, 2, 4, or 8), plus y bytes (y can
have a value between 0 and 7, inclusive). The Pad1 and PadN options
are inserted as needed to maintain the required alignment. The
functions below need to know the alignment of the end of the option
(which is always in the form "xn," where x can have the values 1, 2,
4, or 8) and the total size of the data portion of the option. These
are passed as the "align" and "len" arguments to inet6_opt_append().
Multiple Hop-by-Hop options must be specified by the application by
placing them in a single extension header.
Finally, we note that use of some Hop-by-Hop options or some
Destination options, might require special privilege. That is,
normal applications (without special privilege) might be forbidden
from setting certain options in outgoing packets, and might never see
certain options in received packets.
8.1. Receiving Hop-by-Hop Options
To receive a Hop-by-Hop options header the application must enable
the IPV6_RECVHOPOPTS socket option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
When using ancillary data a Hop-by-hop options header is passed
between the application and the kernel as follows: The cmsg_level
member will be IPPROTO_IPV6 and the cmsg_type member will be
IPV6_HOPOPTS. These options are then processed by calling the
inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_val()
functions, described in Section 10.
8.2. Sending Hop-by-Hop Options
To send a Hop-by-Hop options header, the application specifies the
header either as ancillary data in a call to sendmsg() or using
setsockopt().
The application can remove any sticky Hop-by-Hop options header by
calling setsockopt() for IPV6_HOPOPTS with a zero option length.
All the Hop-by-Hop options must be specified by a single ancillary
data object. The cmsg_level member is set to IPPROTO_IPV6 and the
cmsg_type member is set to IPV6_HOPOPTS. The option is normally
constructed using the inet6_opt_init(), inet6_opt_append(),
inet6_opt_finish(), and inet6_opt_set_val() functions, described in
Section 10.
Additional errors may be possible from sendmsg() and setsockopt() if
the specified option is in error.
9. Destination Options
A variable number of Destination options can appear in one or more
Destination options headers. As defined in [RFC-2460], a Destination
options header appearing before a Routing header is processed by the
first destination plus any subsequent destinations specified in the
Routing header, while a Destination options header that is not
followed by a Routing header is processed only by the final
destination. As with the Hop-by-Hop options, each option in a
Destination options header is TLV-encoded with a type, length, and
value.
9.1. Receiving Destination Options
To receive Destination options header the application must enable the
IPV6_RECVDSTOPTS socket option:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
Each Destination options header is returned as one ancillary data
object described by a cmsghdr structure with cmsg_level set to
IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS.
These options are then processed by calling the inet6_opt_next(),
inet6_opt_find(), and inet6_opt_get_value() functions.
9.2. Sending Destination Options
To send a Destination options header, the application specifies it
either as ancillary data in a call to sendmsg() or using
setsockopt().
The application can remove any sticky Destination options header by
calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero
option length.
This API assumes the ordering about extension headers as described in
[RFC-2460]. Thus, one set of Destination options can only appear
before a Routing header, and one set can only appear after a Routing
header (or in a packet with no Routing header). Each set can consist
of one or more options but each set is a single extension header.
Today all destination options that an application may want to specify
can be put after (or without) a Routing header. Thus, applications
should usually need IPV6_DSTOPTS only and should avoid using
IPV6_RTHDRDSTOPTS whenever possible.
When using ancillary data a Destination options header is passed
between the application and the kernel as follows: The set preceding
a Routing header are specified with the cmsg_level member set to
IPPROTO_IPV6 and the cmsg_type member set to IPV6_RTHDRDSTOPTS. Any
setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently
ignored when sending packets unless a Routing header is also
specified. Note that the "Routing header" here means the one
specified by this API. Even when the kernel inserts a routing header
in its internal routine (e.g., in a mobile IPv6 stack), the
Destination options header specified by IPV6_RTHDRDSTOPTS will still
be ignored unless the application explicitly specifies its own
Routing header.
The set of Destination options after a Routing header, which are also
used when no Routing header is present, are specified with the
cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is
set to IPV6_DSTOPTS.
The Destination options are normally constructed using the
inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and
inet6_opt_set_val() functions, described in Section 10.
Additional errors may be possible from sendmsg() and setsockopt() if
the specified option is in error.
10. Hop-by-Hop and Destination Options Processing
Building and parsing the Hop-by-Hop and Destination options is
complicated for the reasons given earlier. We therefore define a set
of functions to help the application. These functions assume the
formatting rules specified in Appendix B in [RFC-2460] i.e., that the
largest field is placed last in the option.
The function prototypes for these functions are defined as a result
of including <netinet/in.h>.
The first 3 functions (init, append, and finish) are used both to
calculate the needed buffer size for the options, and to actually
encode the options once the application has allocated a buffer for
the header. In order to only calculate the size the application must
pass a NULL extbuf and a zero extlen to those functions.
10.1. inet6_opt_init
int inet6_opt_init(void *extbuf, socklen_t extlen);
This function returns the number of bytes needed for the empty
extension header i.e., without any options. If extbuf is not NULL it
also initializes the extension header to have the correct length
field. In that case if the extlen value is not a positive (i.e.,
non-zero) multiple of 8 the function fails and returns -1.
(Note: since the return value on success is based on a "constant"
parameter, i.e., the empty extension header, an implementation may
return a constant value. However, this specification does not
require the value be constant, and leaves it as implementation
dependent. The application should not assume a particular constant
value as a successful return value of this function.)
10.2. inet6_opt_append
int inet6_opt_append(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t len, uint_t align,
void **databufp);
Offset should be the length returned by inet6_opt_init() or a
previous inet6_opt_append(). This function returns the updated total
length taking into account adding an option with length 'len' and
alignment 'align'. If extbuf is not NULL then, in addition to
returning the length, the function inserts any needed pad option,
initializes the option (setting the type and length fields) and
returns a pointer to the location for the option content in databufp.
If the option does not fit in the extension header buffer the
function returns -1.
Type is the 8-bit option type. Len is the length of the option data
(i.e., excluding the option type and option length fields).
Once inet6_opt_append() has been called the application can use the
databuf directly, or use inet6_opt_set_val() to specify the content
of the option.
The option type must have a value from 2 to 255, inclusive. (0 and 1
are reserved for the Pad1 and PadN options, respectively.)
The option data length must have a value between 0 and 255,
inclusive, and is the length of the option data that follows.
The align parameter must have a value of 1, 2, 4, or 8. The align
value can not exceed the value of len.
10.3. inet6_opt_finish
int inet6_opt_finish(void *extbuf, socklen_t extlen, int offset);
Offset should be the length returned by inet6_opt_init() or
inet6_opt_append(). This function returns the updated total length
taking into account the final padding of the extension header to make
it a multiple of 8 bytes. If extbuf is not NULL the function also
initializes the option by inserting a Pad1 or PadN option of the
proper length.
If the necessary pad does not fit in the extension header buffer the
function returns -1.
10.4. inet6_opt_set_val
int inet6_opt_set_val(void *databuf, int offset, void *val,
socklen_t vallen);
Databuf should be a pointer returned by inet6_opt_append(). This
function inserts data items of various sizes in the data portion of
the option. Val should point to the data to be inserted. Offset
specifies where in the data portion of the option the value should be
inserted; the first byte after the option type and length is accessed
by specifying an offset of zero.
The caller should ensure that each field is aligned on its natural
boundaries as described in Appendix B of [RFC-2460], but the function
must not rely on the caller's behavior. Even when the alignment
requirement is not satisfied, inet6_opt_set_val should just copy the
data as required.
The function returns the offset for the next field (i.e., offset +
vallen) which can be used when composing option content with multiple
fields.
10.5. inet6_opt_next
int inet6_opt_next(void *extbuf, socklen_t extlen, int offset,
uint8_t *typep, socklen_t *lenp,
void **databufp);
This function parses received option extension headers returning the
next option. Extbuf and extlen specifies the extension header.
Offset should either be zero (for the first option) or the length
returned by a previous call to inet6_opt_next() or inet6_opt_find().
It specifies the position where to continue scanning the extension
buffer. The next option is returned by updating typep, lenp, and
databufp. Typep stores the option type, lenp stores the length of
the option data (i.e., excluding the option type and option length
fields), and databufp points the data field of the option. This
function returns the updated "previous" length computed by advancing
past the option that was returned. This returned "previous" length
can then be passed to subsequent calls to inet6_opt_next(). This
function does not return any PAD1 or PADN options. When there are no
more options or if the option extension header is malformed the
return value is -1.
10.6. inet6_opt_find
int inet6_opt_find(void *extbuf, socklen_t extlen, int offset,
uint8_t type, socklen_t *lenp,
void **databufp);
This function is similar to the previously described inet6_opt_next()
function, except this function lets the caller specify the option
type to be searched for, instead of always returning the next option
in the extension header.
If an option of the specified type is located, the function returns
the updated "previous" total length computed by advancing past the
option that was returned and past any options that didn't match the
type. This returned "previous" length can then be passed to
subsequent calls to inet6_opt_find() for finding the next occurrence
of the same option type.
If an option of the specified type is not located, the return value
is -1. If the option extension header is malformed, the return value
is -1.
10.7. inet6_opt_get_val
int inet6_opt_get_val(void *databuf, int offset, void *val,
socklen_t vallen);
Databuf should be a pointer returned by inet6_opt_next() or
inet6_opt_find(). This function extracts data items of various sizes
in the data portion of the option. Val should point to the
destination for the extracted data. Offset specifies from where in
the data portion of the option the value should be extracted; the
first byte after the option type and length is accessed by specifying
an offset of zero.
It is expected that each field is aligned on its natural boundaries
as described in Appendix B of [RFC-2460], but the function must not
rely on the alignment.
The function returns the offset for the next field (i.e., offset +
vallen) which can be used when extracting option content with
multiple fields.
11. Additional Advanced API Functions
11.1. Sending with the Minimum MTU
Unicast applications should usually let the kernel perform path MTU
discovery [RFC-1981], as long as the kernel supports it, and should
not care about the path MTU. Some applications, however, might not
want to incur the overhead of path MTU discovery, especially if the
applications only send a single datagram to a destination. A
potential example is a DNS server.
[RFC-1981] describes how path MTU discovery works for multicast
destinations. From practice in using IPv4 multicast, however, many
careless applications that send large multicast packets on the wire
have caused implosion of ICMPv4 error messages. The situation can be
worse when there is a filtering node that blocks the ICMPv4 messages.
Though the filtering issue applies to unicast as well, the impact is
much larger in the multicast cases.
Thus, applications sending multicast traffic should explicitly enable
path MTU discovery only when they understand that the benefit of
possibly larger MTU usage outweighs the possible impact of MTU
discovery for active sources across the delivery tree(s). This
default behavior is based on the today's practice with IPv4 multicast
and path MTU discovery. The behavior may change in the future once
it is found that path MTU discovery effectively works with actual
multicast applications and network configurations.
This specification defines a mechanism to avoid path MTU discovery by
sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger
than the minimum MTU and this feature has been enabled the IP layer
will fragment to the minimum MTU. To control the policy about path
MTU discovery, applications can use the IPV6_USE_MIN_MTU socket
option.
As described above, the default policy should depend on whether the
destination is unicast or multicast. For unicast destinations path
MTU discovery should be performed by default. For multicast
destinations path MTU discovery should be disabled by default. This
option thus takes the following three types of integer arguments:
-1: perform path MTU discovery for unicast destinations but do not
perform it for multicast destinations. Packets to multicast
destinations are therefore sent with the minimum MTU.
0: always perform path MTU discovery.
1: always disable path MTU discovery and send packets at the minimum
MTU.
The default value of this option is -1. Values other than -1, 0, and
1 are invalid, and an error EINVAL will be returned for those values.
As an example, if a unicast application intentionally wants to
disable path MTU discovery, it will add the following lines:
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));
Note that this API intentionally excludes the case where the
application wants to perform path MTU discovery for multicast but to
disable it for unicast. This is because such usage is not feasible
considering a scale of performance issues around whether to do path
MTU discovery or not. When path MTU discovery makes sense to a
destination but not to a different destination, regardless of whether
the destination is unicast or multicast, applications either need to
toggle the option between sending such packets on the same socket, or
use different sockets for the two classes of destinations.
This option can also be sent as ancillary data. In the cmsghdr
structure containing this ancillary data, the cmsg_level member will
be IPPROTO_IPV6, the cmsg_type member will be IPV6_USE_MIN_MTU, and
the first byte of cmsg_data[] will be the first byte of the integer.
11.2. Sending without Fragmentation
In order to provide for easy porting of existing UDP and raw socket
applications IPv6 implementations will, when originating packets,
automatically insert a fragment header in the packet if the packet is
too big for the path MTU.
Some applications might not want this behavior. An example is
traceroute which might want to discover the actual path MTU.
This specification defines a mechanism to turn off the automatic
inserting of a fragment header for UDP and raw sockets. This can be
enabled using the IPV6_DONTFRAG socket option.
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(on));
By default, this socket option is disabled. Setting the value to 0
also disables the option i.e., reverts to the default behavior of
automatic inserting. This option can also be sent as ancillary data.
In the cmsghdr structure containing this ancillary data, the
cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
IPV6_DONTFRAG, and the first byte of cmsg_data[] will be the first
byte of the integer. This API only specifies the use of this option
for UDP and raw sockets, and does not define the usage for TCP
sockets.
When the data size is larger than the MTU of the outgoing interface,
the packet will be discarded. Applications can know the result by
enabling the IPV6_RECVPATHMTU option described below and receiving
the corresponding ancillary data items. An additional error EMSGSIZE
may also be returned in some implementations. Note, however, that
some other implementations might not be able to return this
additional error when sending a message.
11.3. Path MTU Discovery and UDP
UDP and raw socket applications need to be able to determine the
"maximum send transport-message size" (Section 5.1 of [RFC-1981]) to
a given destination so that those applications can participate in
path MTU discovery. This lets those applications send smaller
datagrams to the destination, avoiding fragmentation.
This is accomplished using a new ancillary data item (IPV6_PATHMTU)
which is delivered to recvmsg() without any actual data. The
application can enable the receipt of IPV6_PATHMTU ancillary data
items by setting the IPV6_RECVPATHMTU socket option.
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on));
By default, this socket option is disabled. Setting the value to 0
also disables the option. This API only specifies the use of this
option for UDP and raw sockets, and does not define the usage for TCP
sockets.
When the application is sending packets too big for the path MTU
recvmsg() will return zero (indicating no data) but there will be a
cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long.
This can happen when the sending node receives a corresponding ICMPv6
packet too big error, or when the packet is sent from a socket with
the IPV6_DONTFRAG option being on and the packet size is larger than
the MTU of the outgoing interface. This indication is considered as
an ancillary data item for a separate (empty) message. Thus, when
there are buffered messages (i.e., messages that the application has
not received yet) on the socket the application will first receive
the buffered messages and then receive the indication.
The first byte of cmsg_data[] will point to a struct ip6_mtuinfo
carrying the path MTU to use together with the IPv6 destination
address.
struct ip6_mtuinfo {
struct sockaddr_in6 ip6m_addr; /* dst address including
zone ID */
uint32_t ip6m_mtu; /* path MTU in host byte order */
};
This cmsghdr will be passed to every socket that sets the
IPV6_RECVPATHMTU socket option, even if the socket is non-connected.
Note that this also means an application that sets the option may
receive an IPV6_MTU ancillary data item for each ICMP too big error
the node receives, including such ICMP errors caused by other
applications on the node. Thus, an application that wants to perform
the path MTU discovery by itself needs to keep history of
destinations that it has actually sent to and to compare the address
returned in the ip6_mtuinfo structure to the history. An
implementation may choose not to delivery data to a connected socket
that has a foreign address that is different than the address
specified in the ip6m_addr structure.
When an application sends a packet with a routing header, the final
destination stored in the ip6m_addr member does not necessarily
contain complete information of the entire path.
11.4. Determining the Current Path MTU
Some applications might need to determine the current path MTU e.g.,
applications using IPV6_RECVPATHMTU might want to pick a good
starting value.
This specification defines a get-only socket option to retrieve the
current path MTU value for the destination of a given connected
socket. If the IP layer does not have a cached path MTU value it
will return the interface MTU for the interface that will be used
when sending to the destination address.
This information is retrieved using the IPV6_PATHMTU socket option.
This option takes a pointer to the ip6_mtuinfo structure as the
fourth argument, and the size of the structure should be passed as a
value-result parameter in the fifth argument.
struct ip6_mtuinfo mtuinfo;
socklen_t infolen = sizeof(mtuinfo);
getsockopt(fd, IPPROTO_IPV6, IPV6_PATHMTU, &mtuinfo, &infolen);
When the call succeeds, the path MTU value is stored in the ip6m_mtu
member of the ip6_mtuinfo structure. Since the socket is connected,
the ip6m_addr member is meaningless and should not be referred to by
the application.
This option can only be used for a connected socket, because a non-
connected socket does not have the information of the destination and