INtime SDK Help
IP6 (Internet Protocol version 6)


#include <sys/socket.h>
#include <netinet/in.h>

socket(AF_INET6, SOCK_RAW, proto);

The IPv6 (Internet Protocol version 6) network layer is used by the IPv6 protocol family for transporting data. IPv6 packets contain an IPv6 header that is not provided as part of the payload contents when passed to an application. IPv6 header options affect the behavior of this protocol and may be used by high-level protocols (such as the tcp and udp protocols) as well as directly by 'raw sockets', which process IPv6 messages at a lower-level and may be useful for developing new protocols and special-purpose applications.


All IPv6 packets begin with an IPv6 header. When data received by the kernel are passed to the application, this header is not included in buffer, even when raw sockets are being used. Likewise, when data are sent to the kernel for transmit from the application, the buffer is not examined for an IPv6 header: the kernel always constructs the header. To directly access IPv6 headers from received packets and specify them as part of the buffer passed to the kernel, link-level access (bpf, for example) must instead be utilized.

The header has the following definition:

struct ip6_hdr {
    union {
        struct ip6_hdrctl {
                  u_int32_t ip6_un1_flow;  /* 20 bits of flow ID */
                  u_int16_t ip6_un1_plen;  /* payload length */
                  u_int8_t  ip6_un1_nxt;   /* next header */
                  u_int8_t  ip6_un1_hlim;  /* hop limit */
             } ip6_un1;
             u_int8_t ip6_un2_vfc;   /* version and class */
        } ip6_ctlun;
        struct in6_addr ip6_src;     /* source address */
        struct in6_addr ip6_dst;     /* destination address */

#define ip6_vfc    ip6_ctlun.ip6_un2_vfc
#define ip6_flow   ip6_ctlun.ip6_un1.ip6_un1_flow
#define ip6_plen   ip6_ctlun.ip6_un1.ip6_un1_plen
#define ip6_nxt    ip6_ctlun.ip6_un1.ip6_un1_nxt
#define ip6_hlim   ip6_ctlun.ip6_un1.ip6_un1_hlim
#define ip6_hops   ip6_ctlun.ip6_un1.ip6_un1_hlim

All fields are in network-byte order. Any options specified (see Options below) must also be specified in network-byte order.

ip6_flow specifies the flow ID. ip6_plen specifies the payload length. ip6_nxt specifies the type of the next header. ip6_hlim specifies the hop limit.

The top 4 bits of ip6_vfc specify the class and the bottom 4 bits specify the version.

ip6_src and ip6_dst specify the source and destination addresses.

The IPv6 header may be followed by any number of extension headers that start with the following generic definition:

struct ip6_ext {
  u_int8_t ip6e_nxt;
     u_int8_t ip6e_len;
} ;


IPv6 allows header options on packets to manipulate the behavior of the protocol. These options and other control requests are accessed with the getsockopt and setsockopt system calls at level IPPROTO_IPV6 and by using ancillary data in recvmsg and sendmsg. They can be used to access most of the fields in the IPv6 header and extension headers.

The following socket options are supported:

The IPV6_PKTINFO, IPV6_HOPLIMIT, IPV6_HOPOPTS, IPV6_DSTOPTS, and IPV6_RTHDR options will return ancillary data along with payload contents in subsequent recvmsg calls with cmsg_level set to IPPROTO_IPV6 and cmsg_type set to respective option name value (e.g., IPV6_HOPTLIMIT). These options may also be used directly as ancillary cmsg_type values in sendmsg to set options on the packet being transmitted by the call. The cmsg_level value must be IPPROTO_IPV6. For these options, the ancillary data object value format is the same as the value returned as explained for each when received with recvmsg.

Note that using sendmsg to specify options on particular packets works only on UDP and raw sockets. To manipulate header options for packets on TCP sockets, only the socket options may be used.

In some cases, there are multiple APIs defined for manipulating an IPv6 header field. A good example is the outgoing interface for multicast datagrams, which can be set by the IPV6_MULTICAST_IF socket option, through the IPV6_PKTINFO option, and through the sin6_scope_id field of the socket address passed to the sendmsg system call.

Resolving these conflicts is implementation dependent. This implementation determines the value in the following way: options specified by using ancillary data (i.e., sendmsg) are considered first, options specified by using IPV6_PKTOPTIONS to set 'sticky' options are considered second, options specified by using the individual, basic, and direct socket options (e.g., IPV6_UNICAST_HOPS) are considered third, and options specified in the socket address supplied to sendmsg are the last choice.


IPv6 multicasting is supported only on AF_INET6 sockets of type SOCK_DGRAM and SOCK_RAW, and only on networks where the interface driver supports multicasting. Socket options (see above) that manipulate membership of multicast groups and other multicast options include IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, IPV6_MULTICAST_LOOP, IPV6_LEAVE_GROUP, and IPV6_JOIN_GROUP.

Raw Sockets

Raw IPv6 sockets are connectionless and are normally used with the sendto and recvfrom calls, although the connect call may be used to fix the destination address for future outgoing packets so that send may instead be used and the bind call may be used to fix the source address for future outgoing packets instead of having the kernel choose a source address.

By using connect or bind, raw socket input is constrained to only packets with their source address matching the socket destination address if connect was used and to packets with their destination address matching the socket source address if bind was used.

If the proto argument to socket is zero, the default protocol (IPPROTO_RAW) is used for outgoing packets. For incoming packets, rotocols recognized by kernel are not passed to the application socket (e.g., tcp and udp) except for some ICMPv6 messages. The ICMPv6 messages not passed to raw sockets include echo, timestamp, and address mask requests. If proto is non-zero, only packets with this protocol will be passed to the socket.

IPv6 fragments are also not passed to application sockets until they have been reassembled. If reception of all packets is desired, link-level access (such as bpf) must be used instead.

Outgoing packets automatically have an IPv6 header prepended to them (based on the destination address and the protocol number the socket was created with). Incoming packets are received by an application without the IPv6 header or any extension headers.

Outgoing packets will be fragmented automatically by the kernel if they are too large. Incoming packets will be reassembled before being sent to the raw socket, so packet fragments or fragment headers will never be seen on a raw socket.


The following determines the hop limit on the next packet received:

struct iovec iov[2];
     u_char buf[BUFSIZ];
     struct cmsghdr *cm;
     struct msghdr m;
     int found, optval;
     u_char data[2048];

     /* Create socket. */

     (void)memset(&m, 0, sizeof(m));
     (void)memset(&iov, 0, sizeof(iov));

     iov[0].iov_base = data;         /* buffer for packet payload */
     iov[0].iov_len = sizeof(data);  /* expected packet length */

     m.msg_name = &from;             /* sockaddr_in6 of peer */
     m.msg_namelen = sizeof(from);
     m.msg_iov = iov;
     m.msg_iovlen = 1;
     m.msg_control = (caddr_t)buf;   /* buffer for control messages */
     m.msg_controllen = sizeof(buf);

      * Enable the hop limit value from received packets to be
      * returned along with the payload.
     optval = 1;
     if (setsockopt(s, IPPROTO_IPV6, IPV6_HOPLIMIT, &optval,
         sizeof(optval)) == -1)
             err(1, "setsockopt");

     found = 0;
     while (!found) {
             if (recvmsg(s, &m, 0) == -1)
                     err(1, "recvmsg");
             for (cm = CMSG_FIRSTHDR(&m); cm != NULL;
                  cm = CMSG_NXTHDR(&m, cm)) {
                     if (cm->cmsg_level == IPPROTO_IPV6 &&
                         cm->cmsg_type == IPV6_HOPLIMIT &&
                         cm->cmsg_len == CMSG_LEN(sizeof(int))) {
                             found = 1;
                             (void)printf("hop limit: %d\n",
                                 *(int *)CMSG_DATA(cm));


A socket operation may fail with one of the following errors returned:

EISCON when trying to establish a connection on a socket which already has one or when trying to send a datagram with the destination address specified and the socket is already connected.
ENOTCONN when trying to send a datagram, but no destination address is specified, and the socket has not been connected.
ENOBUFS when the system runs out of memory for an internal data structure.
EADDRNOTAVAIL when an attempt is made to create a socket with a network address for which no network interface exists.
EACCES when an attempt is made to create a raw IPv6 socket by a non-privileged process.

The following errors specific to IPv6 may occur when setting or getting header options:

EINVAL An unknown socket option name was given.
EINVAL An ancillary data object was improperly formed.


Most of the socket options are defined in RFC 2292 or RFC 2553. The IPV6_V6ONLY socket option is defined in RFC 3542. The IPV6_PORTRANGE socket option and the conflict resolution rule are not defined in the RFCs and should be considered implementation dependent.


Versions Link to
INtime 4.0 netlib.lib

See Also

W. Stevens and M. Thomas, Advanced Sockets API for IPv6, RFC 2292, February 1998.

S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998.

R. Gilligan, S. Thomson, J. Bound, and W. Stevens, Basic Socket Interface Extensions for IPv6, RFC 2553, March 1999.

W. Stevens, B. Fenner, and A. Rudoff, UNIX Network Programming, third edition.

See Also