|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
If an off-link node is not reachable, the following messages may appear in an application log file:
no route to host network is unreachable connection timed out |
Verify that an off-link node is reachable by issuing the ping command.
If there is 100% packet loss, perform the following steps:
Frequently dropped packets indicate either network congestion or an intermittent routing problem.
To determine the cause, do the following:
IPv6 hosts generate their global and site-local unicast addresses automatically by using address prefixes provided by a router on the link. If an on-link node cannot autoconfigure its addresses, perform the following steps:
If another network user reports that message transmission appears to be failing at your router, perform the following steps:
$ SHOW SYSTEM /PROCESS=TCPIP$IP6RTRD |
If someone reports a problem reaching your node from another node, perform the following steps:
If a remote node is not configured to accept a connection from your application, the following message might appear in an application log file:
connection refused |
Verify that TCP/IP Services has been correctly configured on the remote node to accept connections.
Contact the administrator for the remote node and ask whether the
correct socket-based service definitions are defined in the
TCPIP$SERVICES.DAT file. Check whether the service has IPv6 enabled.
6.5.9 Connection Terminates
If the connection terminates abnormally or if a network application appears to hang, perform the following steps:
The TCP/IP Services for OpenVMS programming interface supports the Berkeley Software Distribution (BSD) socket programming interface. It also supports the basic sockets interface extensions for Internet Protocol Version 6 (IPv6) as defined in RFC 3493 and the advanced sockets application programming interfaces as defined in draft RFC 3542. The basic syntax of socket functions remains the same. Existing IPv4 applications will continue to operate as before, and IPv6 applications can interoperate with IPv4 applications.
To support IPv6, TCP/IP Services for OpenVMS provides the following:
This chapter describes the following aspects of the IPv6 API:
The following structures support IPv6. The header file containing each
structure is listed. Consult the appropriate header file for details on
the definitions of each structure.
7.1.1 in6_addr Structure
The in6_addr , defined in the IN6.H header file, supports IPv6.
The address is stored in network byte order as an array of sixteen 8-bit elements.
A wildcard address, defined in network byte order, has the following forms:
A loopback address, defined in network byte order, has the following forms:
The
sockaddr_in6
structure, defined in IN6.H header file, is the protocol-specific
address data structure for IPv6.
7.1.3 msghdr Structure
This data structure enables applications to send and receive ancillary data using the sendmsg and recvmsg functions. This data structure, which is defined in the SOCKET.H header file, also allows AF_INET sockets and raw AF_INET6 sockets to receive certain data.
For IPv4, see the Compaq TCP/IP Services for OpenVMS Sockets API and System Services Programming manual for the descriptions of the IP_RECVDSTADDR and IP_RECVOPTS socket options.
For IPv6, Section 7.3 describes the
IPV6_RECVHOPOPTS
,
IPV6_RECVDSTOPTS
, and
IPV6_RECVRTHDR
options.
7.1.4 cmsghdr Structure
The cmsghdr structure describes ancillary data objects transferred by the sendmsg and recvmsg functions.
The msg_control member of the msghdr data structure points to the ancillary data that are contained in a cmsghdr structure. Typically, only one data object is passed in a cmsghdr structure. However, the IPv6 advanced sockets API enables the sendmsg and recvmsg functions to pass multiple objects. See Section 7.5.1 for information about using raw IPv6 sockets.
The data structure is defined in the SOCKET.H header file.
7.2 Header Files
Header files are provided by the C Run-Time Library (DECC$RTLDEF.TLB).
Updated header files may also appear in the TCPIP$EXAMPLES: directory.
If you use the /INCLUDE=TCPIP$EXAMPLES: qualifier in your compile
command, the header files in TCPIP$EXAMPLES: supersede those in
DECC$RTLDEF.TLB.
7.3 Socket Options
The following socket options supporting IPv6 supplement those listed in the Compaq TCP/IP Services for OpenVMS Sockets API and System Services Programming manual. The IPv6 socket options do not have system service symbols.
| Sockets API Symbol | Description |
|---|---|
| IPV6_RECVPKTINFO | Source and destination IPv6 address, and sending and receiving interface. |
| IPV6_RECVHOPLIMIT | Hop limit. |
| IPV6_RECVRTHDR | Routing header. |
| IPV6_RECVHOPOPTS | Hop-by-hop options. |
| IPV6_RECVDSTOPTS | Destination options. |
| IPV6_CHECKSUM | For raw IPv6 sockets other than ICMPv6 raw sockets, causes the kernel to compute and store checksum for output and to verify the received checksum on input. Discards the packet if the checksum is in error. |
| IPV6_ICMP6_FILTER | Fetches and stores the filter associated with the ICMPv6 raw socket using getsockopt function and setsockopt function. |
| IPV6_UNICAST_HOPS | Sets the hop limit for all subsequent unicast packets sent on a socket. You can also use this option with the getsockopt function to determine the current hop limit for a socket. |
| IPV6_MULTICAST_IF | Sets the interface to use for outgoing multicast packets. |
| IPV6_MULTICAST_HOPS | Sets the hop limit for outgoing multicast packets. |
| IPV6_MULTICAST_LOOP | Controls whether to deliver outgoing multicast packets back to the local application. |
| IPV6_JOIN_GROUP | Joins a multicast group on the specified interface. |
| IPV6_LEAVE_GROUP | Leaves a multicast group on the specified interface. |
The basic IPv6 API focuses on interoperability between IPv4 and IPv6
applications. The API provides functions to identify interfaces, socket
options to support IPv6 multicast datagrams, and functions to translate
and convert addresses.
7.4.1 Interface Identification
To identify the interface on which a datagram is received, on which a datagram is to be sent, and on which a multicast group is joined, the API uses a small, positive integer called an interface index. The kernel assigns this integer to an interface when the interface is initialized.
The API defines the following new functions:
| Function | Description |
|---|---|
| if_nametoindex() | Maps an interface name to its corresponding index. |
| if_indextoname() | Maps an interface index to its corresponding name. |
| if_nameindex() | Returns an array of all interface names and indexes. |
| if_freenameindex() | Frees dynamic memory allocated by if_nameindex() to the array of interface names and indexes. |
To send IPv6 multicast datagrams, an application indicates the multicast group to send to by specifying an IPv6 multicast address in a sendto function. The system maps the specified IPv6 destination address to the appropriate Ethernet or FDDI multicast address prior to transmitting the datagram.
An application can explicitly control multicast options with arguments to the setsockopt function. The following options can be set by an application using the setsockopt function:
The examples here illustrate how to use the setsockopt function options that apply to IPv6 multicast datagrams only. |
The IPV6_MULTICAST_HOPS option to the setsockopt function allows an application to specify a value between 0 and 255 for the hop limit field.
Multicast datagrams with a hop limit value of 0 restrict distribution of the multicast datagram to applications running on the local host. Multicast datagrams with a hop limit value of 1 are forwarded only to hosts on the local link. If a multicast datagram has a hop limit value greater than 1 and a multicast router is attached to the sending host's network, multicast datagrams can be forwarded beyond the local link. Multicast routers forward the datagram to known networks that have hosts belonging to the specified multicast group. The hop limit value is decremented by each multicast router in the path. When the hop limit value is decremented to 0, the datagram is not forwarded further.
The following example shows how to use the IPV6_MULTICAST_HOPS option to the setsockopt function:
u_char hops;
hops=2;
if (setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &hops,
sizeof(hops)) < 0)
perror("setsockopt: IPV6_MULTICAST_HOPS error");
|
A datagram addressed to an IPv6 multicast address is transmitted from the default network interface unless the application specifies that an alternate network interface is associated with the socket. The default interface is determined by the interface associated with the default route in the kernel routing table or by the interface associated with an explicit route, if one exists. Using the IPV6_MULTICAST_IF option to the setsockopt function, an application can specify a network interface other than that specified by the route in the kernel routing table.
The following example shows how to use the IPV6_MULTICAST_IF option to the setsockopt function to specify an interface other than the default:
u_int if_index = 1;
.
.
.
if (setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_IF, &if_index,
sizeof(if_index)) < 0)
perror ("setsockopt: IPV6_MULTICAST_IF error");
else
printf ("new interface set for sending multicast datagrams\n");
|
The if_index parameter specifies the interface index of the desired interface, or specifies 0 to select a default interface. You can use the if_nametoindex() function to find the interface index.
If a multicast datagram is sent to a group that has the sending node as a member, a copy of the datagram is, by default, looped back by the IP layer for local delivery. The IPV6_MULTICAST_LOOP option to the setsockopt() function allows an application to disable this loopback delivery.
The following example shows how to use the IPV6_MULTICAST_LOOP option to the setsockopt() function:
u_char loop=0;
if (setsockopt( sock, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &loop,
sizeof(loop)) < 0)
perror("setsockopt: IPV6_MULTICAST_LOOP error");
|
If the value of loop is 0, loopback is disabled; if
the value of loop is 1, loopback is enabled. For
performance reasons, you should disable the default by setting loop to
0, unless applications on the same host must receive copies of the
datagrams.
7.4.2.2 Receiving IPv6 Multicast Datagrams
Before a node can receive IPv6 multicast datagrams destined for a particular multicast group other than the All Nodes group, an application must direct the node to become a member of that multicast group.
This section describes how an application can direct a node to add itself to and remove itself from a multicast group.
An application can direct the node it is running on to join a multicast group by using the IPV6_JOIN_GROUP option to the setsockopt() function:
struct ipv6_mreq imr6;
.
.
.
imr6.ipv6mr_interface = if_index;
if (setsockopt( sock, IPPROTO_IPV6, IPV6_JOIN_GROUP,
(char *)&imr6, sizeof(imr6)) < 0)
perror("setsockopt: IPV6_JOIN_GROUP error");
|
The imr6 parameter has the following structure:
structipv6_mreq {
struct in6_addr ipv6mr_multiaddr; /* IP multicast address of
group */
unsigned int ipv6mr_interface; /* local interface index*/
};
|
Each multicast group membership is associated with a particular interface. It is possible to join the same group on multiple interfaces. The ipv6mr_interface variable can be specified with a value of 0, which allows an application to choose the default multicast interface. Alternatively, specifying one of the host's local interfaces allows an application to select a particular multicast-capable interface. The maximum number of memberships that can be added on a single socket is subject to the IPV6_MAX_MEMBERSHIPS value, which is defined in the <in.h> header file.
To drop membership from a particular multicast group, use the IPV6_LEAVE_GROUP option to the setsockopt function:
struct ipv6_mreq imr6;
if (setsockopt( sock, IPPROTO_IPV6, IPV6_LEAVE_GROUP, &imr6,
sizeof(imr6)) < 0)
perror("setsockopt: IPV6_LEAVE_GROUP error");
|
The imr6 parameter contains the same structure values used for adding membership.
If multiple sockets request that a node join a particular multicast group, the node remains a member of that multicast group until the last of those sockets is closed.
To receive multicast datagrams sent to a specific UDP port, the receiving socket must have bound to that port using the bind system call. More than one process can receive UDP datagrams destined for the same port if the bind function is preceded by a setsockopt function that specifies the SO_REUSEPORT option.
Delivery of IP multicast datagrams to SOCK_RAW sockets is determined by the protocol type of the destination.
| Previous | Next | Contents | Index |