tst_get_rthdr - Get Routing Header Option using getsockopt()
To check whether the Routing header specified by application can be get correctly by getsockopt().
./tst_get_rthdr [-tooloption ...] -tooloption : v6api tool option
1. Create an IPv6 socket 2. Get Routing header 3. Check A: Routing header has a length of zero 4. Set Routing header 5. Get Routing header 6. Check B: Routing header is the same as set 7. Get Routing header with NULL data pointer 8. Check C: Fail to get Routing header 9. Get Routing header with NULL length pointer 10.Check D: Fail to get Routing header 11.Get Routing header with short length 12.Check E: Routing header returned with short length
None
RFC 3542
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.