NFS Client Daemons

On the client side of the NFS process, there are actually three daemon processes that are used. The first is biod, which stands for block input/output daemon. This daemon processes the input/output with the NFS server on behalf of the user process that is making requests of the remote file system. If you use NFS heavily on a client, you can improve performance by starting up more than one bind daemon. The syntax used to start the daemon is as follows:

/etc/biod [number of daemon processes]

This daemon is usually started in the / et cIrc. local startup file. Modify this file if you want to permanently change the number of daemons running on the client system. You can first test by executing the command online to determine how many daemons you need to start and then place the necessary commands in the startup file.

When deciding performance issues, remember that on a heavily loaded client, making a change in one place might result in poorer performance from another part of the system. So don't assume that you need a lot of extra daemons running unless you can first show that they are needed and do improve performance. Each daemon process is like any other process running on the system, and it uses up system resources, especially memory. Begin by using one or two daemons if you are using a workstation dedicated to one user. For a multiple-user computer, test your performance by increasing the number of daemons until NFS performance is satisfactory (all the time checking, of course, other performance indicators to be sure that the overall system impact is justified).

Although having multiple daemons means that NFS requests can be processed in parallel, remember that the network itself might be a bottleneck. Additional biod daemons will not increase throughput when the network itself is the limiting factor.

Also note that the biod daemon is a client process. You should not run it on an NFS server unless that server is also a client of another NFS server.

In addition to the biod daemon, the lock d and st at d daemons also run on the client

The mount Command

The mount command is used to mount a local file system, and you can also use the command to mount a remote NFS file system. The syntax for using mount to make available a file system being exported by an NFS server is as follows:

mount -F nfs -o options machine:filesystem mountpoint

In some versions of Unix, the syntax for mounting a remote NFS file system is a little different. For example, in SCO Unix you use a lowercase f and an uppercase NFS:

mount -f NFS -o options machine:filesystem mountpoint

In BSD Unix, there is a command called mount nf s, which uses the system call mount to perform most of its functions. This version of the mount command comes with a lot of additional parameters, including the capability to specify on the mount command line whether to use UPD or TCP as the underlying transport mechanism.

The value you supply for machine: filesystem should be the hostname of the remote server that is exporting the file system you want to mount for machine. Substitute the name of the file system for filesystem. The following example causes the remote file system on host zira, called /usr/ projectx/docs, to be made accessible in the local file system hierarchy at the /usr /docs directory:

mount -Fnfs -oro zira:usr/projectx/docs /usr/docs

This is the same way you mount other local file systems into the local hierarchy. Under the / us r/docs directory, you can access any other subdirectories that exist on host zira under the /usr/projectx/docs directory.

The -o parameter can be used to specify options for the mount command. In the preceding example, the letters ro for the option were used to make the remote file system read-only by users on the local computer.

Other options that can be used when mounting a remote file system include the following:

• rw—Mounts the file system for local read-write access, which is the default.
• ro—Mounts the file system for local read-only access.
• suid—Allows setuid execution.
• nosuid—Disallows setuid execution.
• timeo=x—Specifies a timeout value (in tenths of a second). The mount command will fail if it cannot mount the remote file system within this time limit.
• retry=x—The mount command will attempt to mount the remote file system x number of times, with each attempt lasting for the length of time specified by the timeo parameter.
• soft—Causes an error to be returned if the mount is unsuccessful. Opposite of the hard option.
• hard—Causes the mount attempt to continue until it succeeds. Opposite of the so^-ft option.

For more command-line parameters and options, see the man page for the mount command for your particular system.

The mountpoint is the path to the location in the local file system where the remote NFS file system will appear, and this path must exist before the mount command is issued. Any files existing in the mountpoint directory will no longer be accessible to users after a remote file system is attached to the directory with the mount command, so do not use just any directory. Note that the files are not lost. They reappear when the remote file system is unmounted.

Using the fstab File to Mount File Systems at Boot Time

When you have file systems that need to be remounted each time the system reboots, you can use the file /etc/fstab to do this. This file is also used to mount local file systems, so be careful when making edits. The format for a record is as follows:

filesystem directoryname type options frequency pass

The filesystem field for a record used to mount a remote file system includes the server hostname and the pathname of the remote file system separated by a colon (hostname: path ). The second field, directoryname, is the path for the mountpoint on the local system, which indicates where the remote system is mounted and made available for access. The next field, type, is used to specify the file- system type, which can be any of the following:

• uf s—A typical local Unix file system.
• mf s—The memory file system.
• nf s—An NFS remote file system.
• swap—A disk partition used for swapping by the virtual memory system.
• msdos—An MS-DOS–compatible file system.
• cd9660—A CD-ROM file system as defined by ISO 9660.
• pr ocf s—A filesystem structure used to access data about processes.
• kernfs—A filesystem structure used to access kernel parameters.

The options field is used for a comma-delimited list of mounting options (rw, ro, and so on). The frequency is used in determining when a file system will be "dumped" for backup purposes. This can usually be set to zero for NFS systems mounted on a client because it is usually the NFS server that is responsible for making backups of local data. The final field, pass, can also be set to zero most of the time for an NFS file system mounted on a client. This field is used by the f sck utility to determine on which pass it is to check this file system.

What is the Difference Between IPv4 and IPv6? continue...

IPv6 Extension Headers

In general, most protocols have header information followed by a payload that contains the actual data to be transmitted from one point to another. Some protocols include a trailer that usually is use to provide some type of integrity check, such as CRC, to ensure that the frame or datagram has arrived at the destination without corruption.

Still other protocols, and we're talking about IPv6 here, allow for additional headers to follow the ini tial IPv6 header, to describe certain aspects of the datagram. These headers are not required, but one or more can be placed into the datagram. These additional extension headers are placed directly after the IPv6 header, where the payload section is usually located. The payload that follows the lPv6 header, or the extension headers, will be a header for the encapsulated upper-layer protocol being transported by the IPv6 datagram. It is interesting to note that among the following headers, if the hop-by-hop header is used, it must follow the IPv6 header as the first additional header. Other extension headers don't have to be in any particular order, but the RFCs do suggest that certain headers be placed in a certain order.

The field Next Header is used to indicate whether another header follows the current header, after the initial IPv6 header. Yet if the next header is not one that the receiving node recognizes, the node should discard the datagram and send an ICMP message to the source indicating that there was a problem with the packet. In IPv6, the ICMP code for this is 1, which in text format means "unrecognized Next Header Field Header type encountered." This ICMP message is used in many of the IPv6 procedures.

It is important to note that an IPv6 datagram doesn't have to have any extension headers. They are used only when the feature is implemented in the IPv6 hardware (or software) routing mechanism.

The extension headers that can follow the IPv6 header include these:

• Hop-by-Hop—If present, this is the only header that must be examined by every node (read that as router, whether an actual router device or a computer acting as a router). This header, as described previously, must be placed directly after the IPv6 header. If you look back at the Next Header field of the IPv6 header shown in Figure 35.1, a value of zero indicates that the Hop-byHop header is the next header, and must be examined. The IPv6 header is the only header that can use a value of zero in the Next Header field. If any other extension header contains this value, an ICMP message value of 1 will be sent back to the source. This value indicates "unrecognized Next Header type encountered." This option type can be of variable length.
• Destination Options—This header can also be of variable length, and is used only by the destination of the packet. This extension header is used to carry additional information, which is to be defined by other RFCs.
• Routing—This field specifies specific network nodes that a packet should be passed through (a route) to reach its destination. Routers usually decide the route a packet will take depending on the routing protocol. Using this option, IPv6 routers can specify a route. The nodes listed in this option are not guaranteed, however, because there is always the possibility that a particular node might not be online. Or the Maximum Transmission Unit (MTU) of a router listed here might not accept the size of the packet, and thus the packet can't be sent through that router.
• Fragment—This option enables the source node to fragment a packet so that it will be able to reach its destination based on the MTU of the routers between the source and the destination. However, because this value is set by the source node, and it cannot be certain of the MTU value of intervening nodes, packets can still be dropped. A field called the M flag field can be set to one if more fragments of the original message are to be sent, or zero if the packet contains the last fragment of the original message. An Identification field is used to identify which fragmented packets should be considered as a group to be reassembled at the destination node. At the destination, fragments are identified by the source address + destination address + Identification field.
• Authentication
• Encapsulating Security Payloadis
• Upper-layer header—This header follows the other headers, as in an IPv4 packet, and describes the data contained in the remainder of the payload section of the packet.

The preceding list is described in the recommended order suggested by the RFC. This can change depending on a few circumstances. For example, if the Destination Options header should be read n just by the node specified by the destination address found in the initial IPv6 header, but also by th other destinations listed in the Routing header, then the Destination Options header should be p1 immediately after the Hop-by-Hop header, followed by the Routing header.

The Options Type Field for Hop-by-Hop and Destination Options

If the Destination Options header should be examined only by the final destination node, it should be placed just before the upper-layer header. The Options Type field for Hop-by-Hop and Destination Options is an 8-bit field. However, it should be interpreted by bit values, not by byte values.

The third-highest-ordered bit used is either zero or one. If the bit has a value of zero, the data contained in the option cannot be changed by a node it passes through on the way to its eventual destination. If the bit has a value of one, a node can change data in the extension header.

The Next Header field is used by all options. It simply specifies what the next option (following the current option) will be. These option type numbers are based on those described for IPv4. These numbers were originally defined in RFC 1700, and later RFCs. However, the RFC process was not sufficient to keep up with newer protocols and services that were being developed, so an online database now exists. You can use this database to determine what type of protocol or option the Next Header field indicates.

Other IPv6 Considerations

Although IPv6 contains a field that defines the maximum number of hops (the Hop-to-Hop field), it is not required that all nodes support this function, though they can if desired. Instead, upper-layer protocols (such as TCP) are generally delegated this responsibility.

In addition, upper-level protocols should be aware that the maximum payload space has been reduced if IPv6 headers are to be added to the packet. Again, this is a modification that will require that upper-layer protocols be modified, or that the source use fragmentation to deliver packets to their destination.

The Future of IPv6

IPv4 has been in use for more than 10 years now, and although most of the address-space issues have been resolved, there will come a time when the usefulness and flexibility of IPv6 becomes more and more important. There are many enhancements to IPv6 that might warrant its implementation in your network. If your network hasn't yet adopted IPv6, you can bet that eventually it will.

What is the Difference Between IPv4 and IPv6?

The IP protocol is a connectionless, unreliable protocol. TCP uses IP to establish sessions with remote computers and provides the reliability of the data transactions. IP, however, provides the hierarchical address space used by IPv4. Yet this address space is limited to fields in the IP datagram that are only 32 bits in length. When first created, it seemed like this address space would provide enough IP addresses to last for decades or more. After all, only government, educational facilities, and a few other institutions used what was then the ARPANET (the predecessor of the Internet). The address classes' original part of the IPv4 address space has pretty much been displaced by CIDR, to prevent wasting large ranges of addresses allocated to a single entity (such as class A networks).

IPv6 increases this 32-bit address space to 128 bits. At first glance, 32 bits versus 128 bits doesn't seem to be a big difference. When you consider the number of possible addresses that each of these bit ranges can provide, however, there is a tremendous difference. Fill a 32-bit field with all ones and you end up with a number just over 4 billion. A 128-bit field can provide a much larger number of possible addresses. The actual number of addresses, of course, depends on which bits are used to identify a network and which are used to identify a host on a network.

The address space that IPv4 enables can give us enough addresses to satisfy the demand today, especially when using NAT for LANs and using CIDR to reclaim wasted address space that was created by the original address classes. Yet the world of electronics today has changed the playing field. It's not just computers that need an IP address. Handheld devices, mobile phones, and other consumerdevices will likely require an IP address in the near future. NAT might work well in a LAN or a small enterprise network, but when you consider that many wireless devices will roam from one provider to another, an assigned IP address becomes more important. NAT is performed at a local level, not a national or global one.

Expanding the IP address space is not the only feature that IPv6 gives to the Internet and your LAN or WAN. Other important features include the following:

• A simpler header format for the IP datagram, which makes it possible to create faster routing techniques implemented in hardware designs.
• Support for new extensions to the IP header, as well as a means to include future expansion for additional headers that may be created later.
• The replacement of certain options left over from the IPv4 specification, as well as new options, and, again, room for expansion of additional options as required in the future.
• The capability to specify which datagrams require special handling when it comes to flow control. This capability can enable real-time handling of a stream of IP datagrams (needed, for example, for real-time voice or video communication over an IP network), a feature usually accomplished by other protocols tunneling IP.
• Authentication and encryption capabilities to provide for a secure connection.
• As you can see, there are many differences between the capabilities of IPv4 and those of IPv6.

The IPv6 Headers

Headers are used by protocols to provide information about source and destination addresses, protocols, or the payload encapsulated by the datagram. It is typical that one protocol's packet is sent as the payload of another protocol. For example, the IP datagram is usually sent across most LANs encapsulated in an Ethernet frame. At the destination, the Ethernet portion of the frame is stripped off and the IP packet information is

revealed. The IP information is then removed by the protocol stack, and the TCP (or other protocol) information is then removed before the actual data is reassembled and sent to an application.

A few of the IPv4 fields were never put to any practical use. And some of those fields no longer existin the IPv6 header.

The fields for IPv6 are as listed here:

• Version—This 4-bit field is the version of the Internet Protocol. The value for IPv4 was 4. The version for IPv6 in this field is 6. Routers and other devices use this value to determine what type of datagram is being processed.
• Traffic Class—Similar to the Flow Label field, this field enables nodes to specify a particular "traffic class," the definition of which is still being defined by many RFC documents. This field should be supported by any intervening device (such as a router) that understands this field (as it exists today), and ignored by those that do not.
• Flow Label—This 20-bit field is used to request that devices that stand between the source and the destination give special preference to this datagram. This can be compared to the Quality of Service field of IPv4 headers
• Payload Length—This 16-bit field is used to indicate the length of the payload section of the datagram. This does not include the original header of the IP datagram, but it does include any additional headers, as well as the actual payload of the datagram.
• Next Header—One of the most useful features that IPv6 provides is that additional headers can be included in a datagram, in addition to the main IPv6 header itself. There are many typ of headers, and they can be useful depending on the type of payload, or the treatment of the current datagram (such as routing techniques).
• Hop Limit—This 8-bit field is similar to a Time to Live (TTL) field used by many other pro cols. It is decremented by 1 at each router the datagram passes through. When the value reaches 0, the datagram can be discarded.
• Source Address—A 128-bit address used to describe the IP source of the datagram.
• Destination Address—A 128-bit address used to describe the IP destination address of the datagram.

This section describes just the initial IPv6 header format. In the next section you will learn about ho IPv6 can include additional headers that extend the traditional header to provide information about additional services for the IP protocol.