ChorusOS 5.0 System Administrator's Guide

Chapter 12 IP and the ChorusOS System

This chapter explains both IPv4 and IPv6 operations in the context of the ChorusOS operating system. It explains how to set up a ChorusOS system as an IPv4 gateway, also called a router. This allows a ChorusOS system to connect to two or more separate subnetworks. It also explains IPv6 in the ChorusOS operating system.

In order to behave as a gateway, a ChorusOS system needs to be installed on a multi-homed host; namely, a host with at least two network interfaces.

The ChorusOS system can act as a gateway in two different ways: either visibly using IP forwarding only (see "IP Forwarding") or transparently by acting as an ARP proxy, (Address Resolution Protocol), (see "The ChorusOS operating system as an ARP proxy").

IP Forwarding

This section explains IPv4 datagrams, and includes procedural instructions for configuring the gateway, and for configuring the hosts on subnetworks.

One of the ways in which the ChorusOS operating system can act as a gateway between separate subnetworks is through simply forwarding IP datagrams. A ChorusOS host with two or more ethernet adapters can be configured to make a link between different network interfaces, as shown in Figure 12-1 below.

Figure 12-1 ChorusOS as an IP Gateway

In Figure 12-1 above, the ChorusOS system is a gateway bridging Subnetwork 1 to Subnetwork 2. In order to make this gateway:

Assign an IP address to each ethernet interface corresponding to each of the different IP subnetworks.
Configure the ChorusOS operating system to forward the IP traffic accordingly between the ethernet interfaces.
Configure the hosts to send datagrams between the subnetworks via the gateway.

For example, in order to send an IP datagram from Subnetwork 1 to Subnetwork 2, the ethernet interface IP addresses must to be created for ifeth0 and ifeth1 on the ChorusOS host. Then, in order to reach Subnetwork 2, datagrams received on the ifeth0 interface must be redirected through the ifeth1 interface. The default behavior would be for a ChorusOS system to drop silently the datagram after it is received at ifeth0, so a specific configuration is required to forward it between the two ethernet interfaces.

Configuring the Gateway

In order to configure the two ethernet interfaces from Figure 12-1 and to create the routing table to redirect the datagrams between the interfaces, add the following lines to the sysadm.ini file (see sysadm.ini(4CC)) of the ChorusOS gateway.

Create the network interfaces:
```
mkdev ifeth 0 
mkdev ifeth 1
```

Configure the ifeth0 interface:

ifconfig ifeth0 129.158.111.111 netmask 0xffff0000 broadcast 129.158.255.255
ifwait ifeth0

Configure the ifeth1 interface:

ifconfig ifeth1 129.159.222.222 netmask 0xffff0000 broadcast 129.159.255.255
ifwait ifeth1

Set up the routes between ifeth0 and ifeth1:

route add -net 129.158 -iface ifeth0
route add -net 129.159 -iface ifeth1

Configure the ChorusOS operating system to forward the incoming IP datagrams to the corresponding ethernet interface. You do this by activating the net.inet.ip.forwarding state in the microkernel, by adding the following line to the sysadm.ini file:
```
sysctl -w net.inet.ip.forwarding=1
```

Configuring the Hosts on the Subnetworks

You must now configure the hosts on the different subnetworks so that they will use the gateway to send datagrams to each other. For example, assuming that Host A on Subnetwork 1 in Figure 12-1 is running under a ChorusOS system, define a route for it to send datagrams to Subnetwork 2 via the gateway. To do this, add the following lines to the sysadm.ini file for Host A.

Create the network interface:
```
mkdev ifeth 0
```

Configure this interface:

ifconfig ifeth0 129.158.333.333 netmask 0xffff0000 broadcast 129.158.255.255
ifwait ifeth0

Set up the routes. You can set up a simple route, which uses the network interface directly:
```
route add -net 129.158 -iface ifeth0
```
Or, you can specify a gateway explicitly, for example ifeth0 on the ChorusOS gateway from Figure 12-1, as the route to take:
```
route add -net 129.159 129.158.111.111
```

As you can see, the gateway configuration using simple IP forwarding will only work if the hosts on the different subnetworks are correctly configured to send datagrams via the gateway. Since configuring all the hosts to use a specific machine as a gateway is not always possible, it is sometimes necessary to create a gateway between the subnetworks by configuring the ChorusOS operating system to act as an ARP proxy.

The ChorusOS operating system as an ARP proxy

The Address Resolution Protocol (ARP -- see ARP(7P)) maps IP addresses to specific machine addresses in a network. Where a ChorusOS system is acting as a gateway between two or more subnetworks, configuring it as an ARP proxy allows you to handle all the different physical subnetworks as if they are the same network. In other words, creating an ARP proxy makes a single virtual network composed of several physical subnetworks. Consequently, the different hosts located on these networks can communicate without being aware of the presence of the gateway.

This type of configuration is desirable in the following circumstances:

To extend an ethernet segment beyond the physical limit of the ethernet transport used. The ARP proxy gateway can be used to join two or more subnetworks together to form a single ethernet segment with a single network configuration.
To boot a diskless machine via the network if the server providing the system image is located on the other side of a gateway. This situation requires the gateway to be transparent since the firmware code used to load the system image through the network is unaware of the gateway's existence.

A ChorusOS host with two or more ethernet adapters can be configured as an ARP proxy linking different network interfaces to create a single, virtual network, as shown in Figure 12-2.

Figure 12-2 The ChorusOS system as an ARP Proxy

Configuring the Gateway as an ARP Proxy

To configure the ChorusOS gateway to act as an ARP proxy, create the two network interfaces, set them up and create the routing table. To create the example shown in Figure 12-2, you add the following to the sysadm.ini file of the ChorusOS gateway:

Create the two network interfaces:
```
mkdev ifeth 0
mkdev ifeth 1
```

Configure interface ifeth0:

ifconfig ifeth0 129.158.110.111 netmask 0xffffff00 broadcast 129.158.110.255
ifwait ifeth0

Configure interface ifeth1

ifconfig ifeth1 129.158.112.222 netmask 0xffffff00 broadcast 129.159.112.255
ifwait ifeth1

Set up the routes:

route add -net 129.158.110 -iface ifeth0
route add -net 129.158.112 -iface ifeth1

Configure the ChorusOS system to forward IP packets:
```
sysctl -w net.inet.ip.forwarding=1
```

Configure the ChorusOS system to forward ARP requests by activating the net.ether.inet.proxyall microkernel state:
```
sysctl -w net.ether.inet.proxyall=1
```

Configuring the Hosts on the Subnetworks

You must now configure the individual hosts on the virtual network so that they use the ARP proxy gateway. To configure Host A in Figure 12-2 you add the following lines to its sysadm.ini file:

Configure the ifeth0 interface:

ifconfig ifeth0 129.158.110.333 netmask 0xffff0000 broadcast 129.158.255.255
ifwait ifeth0

Set a default route, since the router simulates a single network:
```
route add default -iface ifeth0
```

As you can see, when configuring the hosts on the network you are required only to specify the IP address of that particular host and the IP address of the virtual network. There is no requirement to specify the exact IP address of the gateway, thus rendering the gateway transparent to all the individual hosts on the network.

IPv6 and the ChorusOS System

Internet Protocol version 6 IPv6 adds increased address space and improves Internet functionality using a simplified header format, support for authentication and privacy, autoconfiguration of address assignments, and enables new quality-of-service capabilities. This section focuses on Internet Protocol Version 6, the new standard for the Internet and wireless devices. It explains the transition from IPv4 to IPv6, and the effect of IPv6, for a System Administrator.

To ensure that IPv6 works effectively on this version of the ChorusOS operating system, you must configure it as follows:

host% rsh target sysctl -w net.inet6.ip6.accept_rtadv=1

host% rsh target /sbin/rtsolifeth-0

This is necessary to ensure that IPv6 accepts global addresses in addition to link-local addresses. For more information, see "rtsol and rtsold".

These are the advantages of IPv6:

Expanded routing and addressing capabilities.

IPv6 increases the IP address size from 32 bits to 128 bits to support more levels of addressing hierarchy, provide a much greater number of addressable nodes, and employ simpler auto-configuration of addresses.

The addition of a scope field improves the scalability of multicast routing to multicast addresses

A new type of address, called an anycast address, is defined. It identifies sets of nodes, where a packet sent to an anycast address is delivered to one of the nodes. The use of anycast addresses in the IPv6 source route allows nodes to control the path over which their traffic flows.
Header format simplification.

Some IPv4 header fields have been dropped or made optional. This reduces the common-case processing cost of packet handling and keeps the bandwidth cost of the IPv6 header as low as possible, despite the increased size of the addresses. Even though the IPv6 addresses are four times longer than the IPv4 addresses, the IPv6 header is only twice the size of the IPv4 header.
Improved support for options.

Changes in the way IP header options are encoded allow for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future.
Quality-of-service capabilities.

A new capability is added to enable the labeling of packets belonging to particular traffic flows for which the sender requests special handling, such as non-default quality of service or real-time service.
Authentication and privacy capabilities.

IPv6 includes the definition of extensions that provide support for authentication, data integrity, and confidentiality.

Note -

The IPSEC feature and IPv6 routing facilities are not supported in this version of the ChorusOS operating system. Some include files or utilities related to routing and security may however be present in binary and source product.

This version of the ChorusOS operating system can be used as an end IPv6 host only. You must have an IPv6 router on your network to answer router solicitations and to send router messages.

IPv4 to IPv6 Transition Process

When transitioning from IPv4 to IPv6, it is important to ensure that all existing hosts and routers that still operate on the network at any one time, can support IPv4-only operations. This is to reduce the risk of problems in the event of dual stack nodes, hosts and routers (those that can support both IPv4 and IPv6 operations) sending tasks through IPv4-only nodes. More information is contained in "Transitioning From IPv4 to IPv6" in System Administration Guide, Volume 3

Standardized Transition Tools

The Internet Engineering Task Force, (IETF) specification for advising companies making the transition from IPv4 to IPv6 is the RTF 1933 specification. For transitioning, this document sets out these transition mechanisms:

When you upgrade your hosts and routers to IPv6, they retain their IPv4 functionality to provide compatibility for all IPv4 protocols and applications. These hosts and routers are known as dual stack.
They use the name service (for example, DNS) to carry information about which nodes are IPv6 capable.
IPv6 address formats can contain IPv4 addresses.
You can tunnel IPv6 packets in IPv4 packets as a means of crossing routers that have not been upgraded to IPv6.

Configuring Name Services

A dual node must determine if the peer can support IPv6 or IPv4 to know which IP version to use when transmitting. Controlling what information goes in the name service accomplishes this. You define an IPv4 node's IP address and the IPv6 node's IP address in the name service. Thus, a dual node has both addresses in the name service.

However, the presence of an IPv6 address in the name service also signifies that the node is reachable, using IPv6 from all nodes that get information from that name service. This is no different than in IPv4 where some operations depend on there being only IPv4 addresses for nodes that can be reached using IPv4. When no reachability exists in IPv4 the name service must be partitioned so that IPv4 addresses are visible only where they are reachable.

The protocol used to access the name service is independent of the type of address that can be retrieved from the name service. This name service support, coupled with dual stacks, allows a dual node to use IPv4 when communicating with IPv4-only nodes and use IPv6 when communicating with IPv6 nodes, provided that there is an IPv6 route to the destination.

IPv6 Related Processes

Processes and procedures for ChorusOS networking are enhanced by the introduction of Plug'n'Play Free BSD 4.1 IPv6 and related features. See ip6(7P) and icmp6(7P) man pages for further information.

IP stacks: IPv4 and IPv6

The ChorusOS operating system provides TCP/IP and UDP/IP stacks (POSIX_SOCKETS), both over IPv4 and IPv6.

IPv4 and IPv6 can be used simultaneously.

Consult "Networking" in ChorusOS 5.0 Features and Architecture Overview to see the RFC list of the IPv4 and IPv6 protocols that are supported

See ip6(7P) man page for further information.