HP OpenVMS Systems Documentation

Compaq TCP/IP Services for OpenVMS
Release Notes

The following sections describe some problems commonly encountered with BIND and how to solve them.

C.11.3.1 Server Not Responding

A missing client name in the BIND server's database files results in lack of service to that client. If records that point to the name servers (NS records) in a domain are missing from your server's database files, you might see the following messages:

%TCPIP-W-BIND_NOSERVNAM, Server with address 199.85.8.8 is not responding 
%TCPIP-E-BIND_NOSERVERS, Default servers are not available 
%TCPIP-W-NORECORD, Information not found 
-TCPIP-E-BIND_NOSERVERS, Default servers are not available 

When the CONVERT/ULTRIX BIND /DOMAIN command creates the .DB files from the hosts database, it cannot detect the existence or the names of name servers in a domain. Therefore, it does not add NS records for the name servers to the .DB files.

To solve the problem, follow these steps:

1. Stop the BIND server.
2. Manually add NS records for the missing names.
3. Update the start-of-authority (SOA) records by incrementing the serial number.
4. Restart the BIND server.

This appendix describes:

• The data structures for sending and receiving ancillary data ( Section D.1)
• How to use IPv6 raw socket ( Section D.2)
• The socket calls used to build and examine IPv6 options headers ( Section D.3)
• The socket calls used to build and examine IPv6 routing headers ( Section D.4)

The following data structures enable applications to send and receive ancillary data using the sendmsg and recvmsg system calls:

• struct msghdr
  This data structure, which is defined in the sys/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 options.
  For IPv6, this section describes the IPV6_RECVHOPOPTS , IPV6_RECVDSTOPTS , and IPV6_RECVRTHDR options.
  The msghdr data structure consists of the following components:

  struct msghdr { void *msg_name; /* optional address */ size_t msg_namelen; /* size of address */ struct iovec *msg_iov; /* scatter/gather array */ int msg_iovlen; /* # elements in msg_iov */ void *msg_control; /* ancillary data, see below */ size_t msg_controllen; /* ancillary data buffer len */ int msg_flags; /* flags on received message */ };

• struct cmsghdr
  Describes ancillary data objects transferred by the sendmsg and recvmsg system calls.
  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 system calls to pass multiple objects. See Section D.2 for information about using raw IPv6 sockets.
  The data structure is defined in the sys/socket.h header file.
  The cmsghdr data structure consists of the following components:

  struct cmsghdr { socklen_t cmsg_len; /* #bytes, including this header */ int cmsg_level; /* originating protocol */ int cmsg_type; /* protocol-specific type */ /* followed by unsigned char cmsg_data[]; */ };

Raw sockets are used in both IPv4 and IPv6 to bypass the TCP and UDP transport layers.

Table D-1 describes the principal differences between IPv4 and IPv6 raw sockets.

For output, applications can modify all fields, except for the flow label field, by using ancillary data or socket options, or both.

For input, applications can access all fields, except for the flow label, version number, and Next Header fields, and all extension headers by using ancillary data.

For IPv6 raw sockets other than ICMPv6 raw sockets, the application must set the IPV6_CHECKSUM socket option. For example:

int offset = 2; 
setsockopt (fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); 

This enables the kernel to compute and store a checksum for output and to verify the checksum on input. This relieves the application from having to perform source address selection on all outgoing packets. This socket option is disabled by default. You can disable this option by setting the offset variable to -1.

Using IPv6 raw sockets, an application can access the following information:

• ICMPv6 messages
• IPv6 header
• Routing header
• IPv6 options headers: hop-by-hop options header and destination options header

The following sections describe how to access this information.

D.2.1 Accessing ICMPv6 Messages

An ICMPv6 raw socket is a socket that is created by calling the socket function with the PF_INET6 , SOCK_RAW , and IPPROTO_ICMPV6 arguments.

The kernel calculates and inserts the ICMPv6 checksum for all outbound ICMPv6 packets and verifies the checksum for all received packets. If the received checksum is incorrect, the packet is discarded.

Because ICMPv6 is a superset of ICMPv4,an ICMPv6 raw socket can receive many more messages than an ICMPv4 raw socket. By default, when you create an ICMPv6 raw socket, it passes all ICMPv6 message types to an application. An application, however, does not need access to all messages. An application can specify the ICMPv6 message types it wants passed by creating an ICMPv6 filter.

The ICMPv6 filter has a datatype of struct icmp6_filter . Use getsockopt to retrieve the current filter and setsockopt to store the filter. For example, to enable filtering of ICMPv6 messages, use the ICMP6_FILTER option, as follows:

struct icmp6_filter myfilter; 
 
setsockopt (fd, IPPROTO_ICMPV6, IPV6_FILTER, &(myfilter), (sizeof)(myfilter)); 

The value of myfilter is an ICMPv6 message type between 0 and 255.

Table D-2 describes the ICMPv6 filter macros.

To clear an installed filter, call setsockopt for the ICMP_FILTER option with a zero-length filter.

The kernel does not perform any validity checks on message type, message content, or packet structure. The application is responsible for checking them.

D.2.2 Accessing the IPv6 Header

When using IPv6 raw sockets, applications must be able to receive the IPv6 header content. To receive this optional information, use the setsockopt system call with the appropriate socket option.

Table D-3 describes the socket options for receiving optional information.

The recvmsg system call returns the received data as one or more ancillary data objects in a cmsghdr data structure.

To determine the value of a socket option, use the getsockopt system call with the corresponding option. If the IPV6_RECVPKTINFO option is not set, the function returns an in6_pktinfo data structure with ipi6_addr set to in6addr_any and ipi6_addr set to zero. For other options, the function returns an option_len value of zero if there is no option value.

An application can receive the following IPv6 header information as ancillary data from incoming packets:

• Destination IPv6 address
• Interface index
• Hop limit

The IPv6 address and interface index are contained in a in6_pktinfo data structure that is received as ancillary data with the recvmsg system call. the in6_pktinfo data structure is defined in netinet/in.h . The tasks associated with the IPv6 header are:

• Receiving an IPv6 address
  If the IPV6_RECVPKTINFO option is enabled, the recvmsg system call returns a in6_pktinfo data structure as ancillary data. The ipi6_addr member contains the destination IPv6 address from the received packet. For TCP sockets, the destination address is the local address of the connection.
• Receiving an interface
  If the <