11.1.3.1 Serial Line

There are a couple of reasons for using TCP/IP over a serial line.

• If your remote host is only reachable via telephone, you can use a modem to access it.

• Almost every computer has a serial port today, and the cable needed is rather cheap.

The disadvantage of a serial connection is that it's slower than other methods. NetBSD can use at most 115200 bit/s, making it a lot slower than e.g Ethernet's minimum 10 Mbit/s and Arcnet's 4 Mbit/s.

There are two possible protocols to connect a host running NetBSD to another host using a serial line (possibly over a phone-line):

• Serial Line IP (SLIP)

• Point to Point Protocol (PPP)

The choice here depends on whether you use a dial-up connection through a modem or if you use a static connection (null-modem or leased line). If you dial up for your IP connection, it's wise to use PPP as it offers some possibilities to auto-negotiate ip-addresses and routes, which can be quite painful to do by hand. If you want to connect to another machine which is directly connected, use SLIP, as this is supported by about every operating system and more easy to set up with fixed addresses and routes.

PPP on a direct connection is a bit difficult to setup, as it's easy to timeout the initial handshake; with SLIP, there's no such initial handshake, i.e. you start up one side, and when the othersite has its first packet, it will send it over the line.

[RFC1331] and [RFC1332] describe PPP and TCP/IP over PPP. SLIP is defined in [RFC1055].

11.1.3.2 Ethernet

Ethernet is the medium commonly used to build local area networks (LANs) of interconnected machines within a limited area such as an office, company or university campus. Ethernet is based on a bus that many machines can connect to, and communication always happens between two nodes at a time. When two or more nodes want to talk at the same time, both will restart communication after some timeout. The technical term for this is CSMA/CD (Carrier Sense w/ Multiple Access and Collision Detection).

Initially, Ethernet hardware consisted of a thick (yellow) cable that machines tapped into using special connectors that poked through the cable's outer shielding. The successor of this was called 10base5, which used BNC-type connectors for tapping in special T-connectors and terminators on both ends of the bus. Today, ethernet is mostly used with twisted pair lines which are used in a collapsed bus system that are contained in switches or hubs. The twisted pair lines give this type of media it's name - 10baseT for 10 Mbit/s networks, and 100baseT for 100 MBit/s ones. In switched environments there's also the distinction if communication between the node and the switch can happen in half- or in full duplex mode.

11.1.6.1 /etc/hosts

The first and most simplest way to translate hostnames into IP-addresses is by using a table telling which IP address belongs to which hostname(s). This table is stored in the file /etc/hosts and has the following format:

IP-address        hostname [nickname [...]]

Lines starting with a hash mark ("#") are treated as comments. The other lines contain one IP-address and the corresponding hostname(s).

It's not possible for a hostname to belong to several IP addresses, even if I made you think so when talking about routing. rzi for example has really two distinct names for each of its two addresses: rzi and rzia (but please don't ask me which name belongs to which address!).

Giving a host several nicknames can be convenient if you want to specify your favourite host providing a special service with that name, as is commonly done with FTP-servers. The first (leftmost) name is usually the real (canonical) name of the host.

Besides giving nicknames, it's also convenient to give a host's full name (including domain) as its canonical name, and using only its hostname (without domain) as a nickname.

Important: There must be an entry mapping localhost to 127.0.0.1!

11.1.6.2 Domain Name Service (DNS)

/etc/hosts bears an inherent problem, especially in big networks: when one host is added or one hosts's address changes, all the /etc/hosts' on all machines have to be changed! This is not only time-consuming, it's also very likely that there will be some errors and inconsistencies, leading to problems.

Another appoach is to hold only one hostnames-table (-database) for a network, and make all the clients query that "nameserver". Updates will be made only on the nameserver.

This is the basic idea behind the Domain Name Service (DNS).

Usually, there's one nameserver for each domain (hence DNS), and every host (client) in that domain knows which domain it is in and which nameserver to query for its domain.

When the DNS gets a query about an host which is not in its domain, it will forward the query to a DNS which is either the DNS of the domain in question or knows which DNS to ask for the specified domain. If the DNS forwarded the query doesn't know how to handle it, it will forward that query again to a DNS one step higher. This is not ad infinitum, there are several "root"-servers, which know about any domain.

See Chapter 12 for details on DNS.

11.1.6.3 Network Information Service (NIS/YP)

Yellow Pages (YP) was invited by Sun Microsystems. The name has been changed into Network Information Service (NIS) because YP was already a trademark of the british telecom. So, when I'll talk about NIS you'll know what I mean. ;-)

There are quite some configuration files on a unix-system, and often it's desired to maintain only one set of those files for a couple of hosts. Those hosts are grouped together in a NIS-domain (which has nothing to do with the domains built by using DNS!) und are usually contained in one workstation cluster.

Examples for the config-files shared among those hosts are /etc/passwd, /etc/group and - last but not least - /etc/hosts.

So, you can "abuse" NIS for getting a unique name-to-address-translation on all hosts throughout one (NIS-)domain.

There's only one drawback, which prevents NIS from actually being used for that translation: In contrast to the DNS, NIS provides no way to resolve hostnames which are not in the hosts-table. There's no hosts "one level up" which the NIS-server can query, and so the translation will fail! Suns NIS+ takes measures against that problem, but as NIS+ is only available on Solaris-systems, this is of little use for us now.

Don't get me wrong: NIS is a fine thing for managing e.g. user-information (/etc/passwd, ...) in workstation-clusters, it's simply not too useful for resolving hostnames.

11.1.6.4 Other

The name resolving methods described above are what's used commonly today to resolve hostsnames into IP addresses, but they aren't the only ones. Basically, every database mechanism would do, but none is implemented in NetBSD. Let's have a quick look what you may encounter.

With NIS lacking hierarchy in data structures, NIS+ is intended to help out in that field. Tables can be setup in a way so that if a query cannot be answered by a domain's server, there can be another domain "above" that might be able to do so. E.g. you could choose to have a domain that lists all the hosts (users, groups, ...) that are valid in the whole company, one that defines the same for each division, etc. NIS+ is not used a lot today, even Sun went back to ship back NIS by default.

Last century, the X.500 standard was designed to accomodate both simple databases like /etc/hosts as well as comples, hierarchical systems as can be found e.g. in DNS today. X.500 wasn't really a success, mostly due to the fact that it tried to do too much at the same time. A cut-down version is available today as the Lightweight Directory Access Protocol (LDAP), which is becoming popular in the last years to manage data like users but also hosts and others in small to medium sized organisations.

11.1.7.1 The Future of the Internet

According to experts, the Internet as we know it will face a serious problem in a few years. Due to it's rapid growth and the limitations in it's design, there will be a point at which no more free addresses are available for connecting new hosts. At that point, no more new web servers can be set up, no more users can sign up for accounts at ISPs, no more new machines can be setup to access the web or participate in online games - some people may call this a serious problem.

Several approaches have been made to solve the problem. A very popular one is to not assign a worldwide unique address to every users' machine, but rather to assign them "private" addresses, and hide several machines behind one official, globally unique address. This approach is called "Network Address Translation" (NAT, also known as IP Masquerading). It has problems, as the machines hidden behind the global address can't be addressed, and as a result of this, opening connections to them - which is used in online gaming, peer to peer networking, etc. - is not possible. For a more in-depth discussion of the drawbacks of NAT, see [RFC3027].

A different approach to the problem of internet addresses getting scarce is to abandon the old Internet protocol with it's limited addressing capabilities, and use a new protocol that does not have these limitations. The protocol - or actually, a set of protocols - used by machines connected to form today's Internet is know as the TCP/IP (Transmission Control Protocol, Internet Protocol) suite, and version 4 currently in use has all the problems described above. Switching to a different protocol version that does not have these problems of course requires for a 'better' version to be available, which actually is. Version 6 of the Internet Protocol (IPv6) does fulfill any possible future demands on address space, and also addresses further features such as privacy, encryption, and better support of mobile computing.

Assuming a basic understanding of how today's IPv4 works, this text is intended as an introduction to the IPv6 protocol. The changes in address formats and name resolution are covered. With the background given here, Section 11.3.4 will show how to use IPv6 even if your ISP doesn't offer it by using a simple yet efficient transition mechanism called 6to4. The goal is to to get online with IPv6, giving example configuration for NetBSD.

11.1.7.2 What good is IPv6?

When telling people to migrate from IPv4 to IPv6, the question you usually hear is "why?". There are actually a few good reasons to move to the new version:

• Bigger address space

• Support for mobile devices

• Built-in security

11.1.7.3 Changes to IPv4

After giving a brief overview of all the important features of IPv6, we'll go into the details of the basics of IPv6 here. A brief understanding of how IPv4 works is assumed, and the changes in IPv6 will be hilighted. Starting with IPv6 addresses and how they're split up we'll go into the various types of addresses there are, what became of broadcasts, then after discussing the IP layer go into changes for name resolving and what's new in DNS for IPv6.

127.0.0.1               localhost
::1                     localhost

noon            IN      AAAA    3ffe:400:430:2:240:95ff:fe40:4385

zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {
        type master;
        file "db.reverse";
};

5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0 IN   PTR   noon.ipv6.example.com.

11.2.3.1 Getting the connection information

The first thing to do is ask the provider the necessary information for the connection, which means:

• The phone number of the nearest POP.

• The authentication method to be used.

• The username and password for the connection.

• The IP addresses of the name servers.

11.2.3.2 resolv.conf and nsswitch.conf

The /etc/resolv.conf file must be configured using the information supplied by the provider, expecially the addresses of the DNS. In this example the two DNS will be "194.109.123.2" and "191.200.4.52".

nameserver 194.109.123.2
nameserver 191.200.4.52
#lookup file bind

And now an example of the /etc/nsswitch.conf file.

# /etc/nsswitch.conf
group:         compat
group_compat:  nis
hosts:         files dns 
netgroup:      files [notfound=return] nis
networks:      files
passwd:        compat
passwd_compat: nis

11.2.3.3 Creating the directories for pppd

The directories /etc/ppp and /etc/ppp/peers will contain the configuration files for the PPP connection. After a fresh install of NetBSD they don't exist and must be created (chmod 700.)

11.2.3.4 Connection script and chat file

The connection script will be used as a parameter on the pppd command line; it is located in /etc/ppp/peers and has usually the name of the provider. For example, if the provider's name is BigNet and your user name for the connection to the provider is alan, an example connection script could be:

# /etc/ppp/peers/bignet
connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat'
noauth
user alan
remotename bignet.it

In the previous example, the script specifies a chat file to be used for the connection. The options in the script are detailed in the pppd(8) man page.

The connection script calls the chat application to deal with the physical connection (modem initialization, dialing, ...) The parameters to chat can be specified inline in the connection script, but it is better to put them in a separate file. If, for example, the telephone number of the POP to call is 02 99999999, an example chat script could be:

# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''

11.2.3.5 Authentication

During authentication each of the two systems verifies the identity of the other system, although in practice you are not supposed to authenticate the provider, but only to be verified by him, using one of the following methods.

• login

• PAP/CHAP

Most providers use a PAP/CHAP authentication.

user * password

alan * pZY9o

# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''
TIMEOUT 50
ogin: alan
ssword: pZY9o

11.2.3.6 pppd options

The only thing left to do is the creation of the pppd options file, which is /etc/ppp/options (chmod 644).

/dev/tty01
lock
crtscts
57600
modem
defaultroute
noipdefault

Check the pppd(8) man page for the meaning of the options.

11.2.3.7 Testing the modem

Before activating the link it is a good idea to make a quick modem test, in order to verify that the physical connection and the communication with the modem works. For the test the cu program can be used, as in the following example.

1. Create the file /etc/uucp/port with the following lines:

   type modem
   port modem
   device /dev/tty01
   speed 115200
   

   (substitute the correct device in place of /dev/tty01.)

2. Write the command cu -p modem to start sending commands to the modem. For example:

   # cu -p modem
     Connected.
     ATZ
     OK
     ~.
     Disconnected.
     #
   

   In the previous example the reset command (ATZ) was sent to the modem, which replied with OK: the communication works. To exit cu, write ~ (tilde) followed by . (dot), as in the example.

If the modem doesn't work, check that it is connected to the correct port (i.e. you are using the right port with cu. Cables are a frequent cause of trouble, too.

11.2.3.8 Activating the link

At last everything is ready to connect to the provider with the following command:

# pppd call bignet

where bignet is the name of the already described connection script. To see the connection messages of pppd, give the following command:

# tail -f /var/log/messages

To disconnect, do a kill -HUP of pppd.

11.2.3.9 Using a script for connection and disconnection

When the connection works correctly, it's time to write a couple of scripts to avoid repeating the commands every time. These two scripts can be named, for example, ppp-up and ppp-down.

ppp-up is used to connect to the provider:

#!/bin/sh
MODEM=tty01
POP=bignet
if [ -f /var/spool/lock/LCK..$MODEM ]; then
  echo ppp is already running...
else
  pppd call $POP
  tail -f /var/log/messages
fi

ppp-down is used to close the connection:

#!/bin/sh
MODEM=tty01
if [ -f /var/spool/lock/LCK..$MODEM ]; then
  echo -f killing pppd...
  kill -HUP `cat /var/spool/lock/LCK..$MODEM`
  echo done
else
  echo ppp is not active
fi

The two scripts take advantage of the fact that when pppd is active, it creates the file LCK..tty01 in the /var/spool/lock directory. This file contains the pid of the pppd process.

The two scripts must be executable:

# chmod u+x ppp-up ppp-down

11.2.5.1 Connecting NetBSD with BSD or Linux

The easiest case is when both machines run NetBSD: making a connection with the SLIP protocol is very easy. On the first machine write the following commands:

# slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.1 192.168.1.2

On the second machine write the following commands:

# slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.2 192.168.1.1

Now you can test the connection with ping; for example, on the second PC write:

# ping 192.168.1.1

If everything worked there is now an active network connection between the two machines and ftp, telnet and other similar commands can be executed. The textual aliases of the machines can be written in the /etc/hosts file.

• In the previous example both PC's used the first serial port (/dev/tty0). Substitute the appropriate device if you are using another port.

• IP addresses like 192.168.x.x are reserved for "internal" networks. The first PC has address 192.168.1.1 and the second 192.168.1.2.

• To achieve a faster connection the -s speed option to slattach can be specified.

• ftp can be used to transfer files only if inetd is active and the ftpd server is enabled.

11.2.5.2 Connecting NetBSD and Windows NT

NetBSD and Windows NT can be (almost) easily networked with a serial null modem cable. Basically what needs to be done is to create a "Remote Access" connection under Windows NT and to start pppd on NetBSD.

Start pppd as root after having created a .ppprc in /root. Use the following example as a template.

connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
local
tty00  
115200
crtscts
lock   
noauth
nodefaultroute
:192.168.1.2

The meaning of the first line will be explained later in this section; 192.168.1.2 is the IP address that will be assigned by NetBSD to the Windows NT host; tty00 is the serial port used for the connection (first serial port.)

On the NT side a null modem device must be installed from the Control Panel (Modem icon) and a Remote Access connection using this modem must be created. The null modem driver is standard under Windows NT 4 but it's not a 100% null modem: when the link is activated, NT sends the string CLIENT and expects to receive the answer CLIENTSERVER. This is the meaning of the first line of the .ppprc file: chat must answer to NT when the connection is activated or the connection will fail.

In the configuration of the Remote Access connection the following must be specified: use the null modem, telephone number "1" (it's not used, anyway), PPP server, enable only TCP/IP protocol, use IP address and namservers from the server (NetBSD in this case.) Select the hardware control flow and set the port to 115200 8N1.

Now everything is ready to activate the connection.

• Connect the serial ports of the two machines with the null modem cable.

• Launch pppd on NetBSD. To see the messages of pppd: tail -f /var/log/messages).

• Activate the Remote Access connection on Windows NT.

11.2.5.3 Connecting NetBSD and Windows 95

The setup for Windows 95 is similar to the one for Windows NT: Remote Access on Windows 95 and the PPP server on NetBSD will be used. Most (if not all) Windows 95 releases don't have the null modem driver, which makes things a little more complicated. The easiest solution is to find one of the available null modem drivers on the Internet (it's a small .INF file) and repeat the same steps as for Windows NT. The only difference is that the first line of the .ppprc file (the one that calls chat) can be removed.

If you can't find a real null modem driver for Windows 95 it's still possible to use a little trick:

• Create a Remote Access connection like the one described in Section 11.2.5.2 but using the "Standard Modem".

• In .ppprc substitute the line that calls chat with the following line

  connect '/usr/sbin/chat -v ATH OK AT OK ATE0V1 OK AT OK ATDT CONNECT'
  

• Activate the connection as described in Section 11.2.5.2.

In this way the chat program, called when the connection is activated, emulates what Windows 95 thinks is a standard modem, returning to Windows 95 the same answers that a standard modem would return. Whenever Windows 95 sends a modem command string, chat returns OK.

11.3.1.1 Configuring the gateway/firewall

To use IPNAT, in the kernel configuration file the "pseudo-device ipfilter" must be enabled in the kernel. To check if it is enabled in the current kernel:

# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding = 1

If the result is "1" as in the previous example, the option is enabled, otherwise, if the result is "0" the option is disabled. You can do two things:

1. Compile a new kernel, with the GATEWAY option enabled by default.

2. Enable the option in the current kernel with the following command:

   # sysctl -w net.inet.ip.forwarding=1
   

   You can add sysctl settings to /etc/sysctl.conf to have them set automatically at boot. In this case you would want

   net.inet.ip.forwarding=1
   

The rest of this section explains how to create an IPNAT configuration that is automatically started every time that a connection to the provider is activated with the PPP link. With this configuration all the host of a home network (for example) will be able to connect to the Internet through the gateway machine, even if they don't use NetBSD.

First, create the /etc/ipnat.conf file containing the following rules:

map ppp0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp
map ppp0 192.168.1.0/24 -> 0/32 portmap tcp/udp 40000:60000
map ppp0 192.168.1.0/24 -> 0/32

192.168.1.0/24 are the network addresses that should be mapped The first line of the configuration file is optional: it enables active FTP to work through the gateway. The second line is used to handle correctly tcp and udp packets; the portmapping is necessary because of the many to one relationship.) The third line is used to enable ICMP, ping, etc.

Create the /etc/ppp/ip-up file; it will be called automatically every time that the PPP link is activated.

#!/bin/sh
# /etc/ppp/ip-up
/etc/rc.d/ipnat forcestart

Create the file /etc/ppp/ip-down; it will be called automatically when the PPP link is closed.

#!/bin/sh
# /etc/ppp/ip-down
/etc/rc.d/ipnat forcestop

Both ip-up and ip-down must be executable:

# chmod u+x ip-up ip-down

The gateway machine is now ready.

11.3.1.2 Configuring the clients

Create a /etc/resolv.conf file like the one on the gateway machine.

Write the following command:

# route add default 192.168.1.1

192.168.1.1 is the address of the gateway machine configured in the previous section.

Of course you don't want to give this command every time, so it's better to define the "defaultroute" entry in the /etc/rc.conf file or, which is the same, write the address of the gateway in the /etc/mygate file: the default route will be set automatically during system initialization, using the contents of /etc/mygate (or the defaultroute option) as an argument to the route add default command.

If the client machine is not using NetBSD, the configuration will be different. On Windows PC's you need to set the gateway property of the TCP/IP protocol to the IP address of the NetBSD gateway.

That's all that needs to be done on the client machines.

11.3.1.3 Some useful commands

The following commands can be useful for diagnosing problems:

11.3.2.1 NFS setup example

Warning: I have taken this rather complicated example from a NetBSD mailing list and I haven't tested it; it should give an idea of how NFS works.

The scenario is the following: five client machines (cli1, ..., cli5) share some directories on a server (buzz.toys.org.) Some of the directories exported by the server are reserved for a specific client, the other directories are common for all client machines. All the clients boot from the server and must mount the directories.

The directories exported from the server are:

The following file systems exist on the server

/dev/ra0a on /
/dev/ra0f on /usr
/dev/ra1a on /usr/src
/dev/ra2a on /export

Each client needs the following file systems

buzz:/export/cli?/root on /
buzz:/export/common/usr on /usr
buzz:/usr/src on /usr/src

The server configuration is the following:

# /etc/exports
/usr/src -network 123.45.67.0 -mask 255.255.255.0
/export  -alldirs -maproot=root -network 123.45.67.0 -mask 255.255.255.0

On the client machines /etc/fstab contains

buzz:/export/cli?/root / nfs rw
buzz:/export/common/usr /usr nfs rw,nodev,nosuid
buzz:/usr/src /usr/src rw,nodev,nosuid

Each client machine has its number substituted to the "?" character in the first line of the previous example.

11.3.3.1 Introduction

The problem with NFS (and other) mounts is, that you usually have to be root to make them, which can be rather inconvenient for users. Using amd you can set up a certain directory (I'll take /net), under which one can make any NFS-mount as a normal user, as long as the filesystem about to be accessed is actually exported by the NFS server.

To check if a certain server exports a filesystem, and which ones, use the showmount-command with the -e (export) switch:

$ showmount -e wuarchive.wustl.edu
Exports list on wuarchive.wustl.edu:
/export/home                       onc.wustl.edu 
/export/local                      onc.wustl.edu 
/export/adm/log                    onc.wustl.edu 
/usr                               onc.wustl.edu 
/                                  onc.wustl.edu 
/archive                           Everyone

If you then want to mount a directory to access anything below it (for example /archive/systems/unix/NetBSD), just change into that directory:

$ cd /net/wuarchive.wustl.edu/archive/systems/unix/NetBSD

The filesystem will be mounted (by amd), and you can a access any files just as if the directory was mounted by the superuser of your system.

11.3.3.2 Actual setup

You can set up such a /net directory with the following steps (including basic amd configuration):

11.3.4.1 Getting 6to4 IPv6 up & running

6to4 is an easy way to get IPv6 connectivity for hosts that only have an IPv4 uplink, esp. if you have the background given in Section 11.1.7. It can be used with static as well as dynamically assigned IPv4 addresses, e.g. as found in modem dialup scenarios today. When using dynamic IPv4 addresses, a change of IP addresses will be a problem for incoming traffic, i.e. you can't run persistent servers.

Example configurations given in this section is for NetBSD 1.5.2.

11.3.4.2 Obtaining IPv6 Address Space for 6to4

The 6to4 IPv6 setup on your side doesn't consist of a single IPv6 address; Instead, you get a whole /48 network! The IPv6 addresses are derived from your (single) IPv4 address. The address prefix "2002:" is reserved for 6to4 based addresses (i.e. IPv6 addresses derived from IPv4 addresses). The next 32 bits are your IPv4 address. This results in a /48 network that you can use for your very own purpose. It leaves 16 bits space for 2¹⁶ IPv6 subnets, which can take up to 2⁶⁴ nodes each. Figure 11-8 illustrates the building of your IPv6 address (range) from your IPv4 address.

Thanks to the 6to4 prefix and your worldwide unique IPv4 address, this address block is unique, and it's mapped to your machine carrying the IPv4 address in question.

11.3.4.3 How to get connected

In contrast to the configured "IPv6-over-IPv4 tunnel" setup, you do not have to register at a 6bone-gateway, which will then forward you any IPv6 traffic (encapsulated in IPv4). Instead, as your IPv6 address is derived from your IPv4 address, any answers can be sent through your nearest 6to4 gateway to you. De-encapsulation of the packet is done via a 6to4-capable network interface, which then forwards the resulting IPv6 package according to your routing setup (in case you have more than one machine connected on your 6to4 assigned network).

For sending out IPv6 packets, the 6to4-capable network interface will take the IPv6 packet, and encapsulate it into a IPv4 packet. You still need a 6bone-connected 6to4-gateway as uplink that will de-encapsulate your packets, and forward them on over the 6Bone. Figure 11-9 illustrates this.

11.3.4.4 Security Considerations

In contrast to the "configured tunnel" setup, you usually can't setup packet filters to block 6to4-packets from unauthorized sources, as this is exactly how (and why) 6to4 works at all. As such, malicious users can send packets with invalid/hazardous IPv6 payload. If you don't already filter on your border gateways anyways, packets with the following characteristics should not be allowed as valid 6to4 packets, and some firewalling seems to be justified for them:

• unspecified IPv4 source/destination address: 0.0.0.0/8

• loopback address in outer (v4) source/destination: 127.0.0.0/8

• IPv4 multicast in source/destination: 224.0.0.0/4

• limited broadcasts: 255.0.0.0/8

• subnet broadcast address as source/destination: depends on your IPv4 setup

The NetBSD stf(4) manual page documents some common configuration mistakes intercepted by default by the KAME stack as well as some further advice on filtering, but keep in mind that because of the requirement of these filters, 6to4 is not perfectly secure. Still, if forged 6to4 packets become a problem, you can use IPsec authentication to ensure the IPv6 packets are not modified.

11.3.4.5 Data Needed for 6to4 Setup

In order to setup and configure IPv6 over 6to4, a few bits of configuration data must be known in advance. These are:

• Your local IPv4 address. It can be determined using either the 'ifconfig -a' or 'netstat -i' commands on most Unix systems. If you use a NATing gateway or something, be sure to use the official, outside-visible address, not your private (10/8 or 192.168/16) one.

  We will use 62.224.57.114 as the local IPv4 address in our example.

• Your local IPv6 address, as derived from the IPv4 address. See Figure 11-8 on how to do that.

  For our example, this is 2002:3ee0:3972:0001::1 (62.224.57.114 == 0x3ee03972, 0001::1 arbitrarily chosen).

• The IPv6-address of the 6to4 uplink gateway you want to use. The IPv6 address will do, as it also contains the IPv4 address in the usual 6to4 translation.

  We will use 2002:c25f:6cbf::1 (== 194.95.108.191 == 6to4.ipv6.fh-regensburg.de).

11.3.4.6 Kernel Preparation

To process 6to4 packets, the operating system kernel needs to know about them. For that a driver has to be compiled in that knows about 6to4, and how to handle it.

For a NetBSD kernel, put the following into your kernel config file to prepare it for using IPv6 and 6to4, e.g. on NetBSD use:

options INET6                 # IPv6
pseudo-device stf             # 6to4 IPv6 over IPv4 encapsulation

Note that the stf(4) device is not enabled by default. Rebuild your kernel, then reboot your system to use the new kernel. Please consult Chapter 9 for further information on configuring, building and installing a new kernel!

11.3.4.7 6to4 Setup

This section describes the commands to setup 6to4. In short, the steps performed here are:

1. Configure interface

2. Set default route

3. Setup Router Advertisement, if wanted

The first step in setting up 6to4 is assigning an IPv6 address to the 6to4 interface. This is achieved with the ifconfig(8) command. Assuming the example configuration above, the command for NetBSD is:

# ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias  (local)

After configuring the 6to4 device with these commands, routing needs to be setup, to forward all IPv6 traffic to the 6to4 (uplink) gateway. The best way to do this is by setting a default route, the command to do so is, for NetBSD:

# route add -inet6 default 2002:cdb2:5ac2::1 (remote)

Note that NetBSD's stf(4) device determines the IPv4 address of the 6to4 uplink from the routing table. Using this feature, it is easy to setup your own 6to4 (uplink) gateway if you have a IPv6 uplink, e.g. via 6Bone.

After these commands, you are connected to the IPv6-enabled world - Congratulations! Assuming name resolution is still done via IPv4, you can now ping a IPv6-site like www.kame.net or www6.NetBSD.org:

# /sbin/ping6 www.kame.net

As a final step in setting up IPv6 via 6to4, you will want to setup Router Advertisement if you have several hosts on your network. While it is possible to setup 6to4 on each node, doing so will result in very expensive routing from one node to the other - packets will be sent to the remote 6to4 gateway, which will then route the packets back to the neighbor node. Instead, setting up 6to4 on one machine and talking native IPv6 on-wire is the preferred method of handling things.

The first step to do so is to assign a IPv6-address to your ethernet. In the following example we will assume subnet "2" of the IPv6-net is used for the local ethernet and the MAC address of the ethernet interface is 12:34:56:78:9a:bc, i.e. your local gateway's ethernet interface's IP address will be 2002:3ee0:3972:2:1234:56ff:fe78:9abc. Assign this address to your ethernet interface, e.g.

# ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc

Here, "ne0" is an example for your ethernet card interface. This will most likely be different for your setup, depending on what kind of card is used.

Next thing that needs to be ensured for setting up the router is that it will actually forward packets from the local 6to4 device to the ethernet device and back. To enable IPv6 packet forwarding, set "ip6mode=router" in NetBSD's /etc/rc.conf, which will result in the "net.inet6.ip6.forwarding" sysctl being set to "1":

# sysctl -w net.inet6.ip6.forwarding=1

To setup router advertisement on BSD, the file /etc/rtadvd.conf needs to be checked. It allows configuration of many things, but usually the default config of not containing any data is ok. With that default, IPv6 addresses found on all of the router's network interfaces will be advertised.

After checking the router advertisement configuration is correct and IPv6 forwarding is turned on, the daemon handling it can be started. Under NetBSD, it is called 'rtadvd'. Start it up either manually (for testing it the first time) or via the system's startup scripts, and see all your local nodes automagically configure the advertised subnet address in addition to their already-existing link local address.

# rtadvd

11.3.4.8 Quickstart using pkgsrc/net/6to4

So far, we have described how 6to4 works and how to set it up manually. For an automated way to make everything happen e.g. when going online, the '6to4' package is convenient. It will determine your IPv6 address from the IPv4 address you got assigned by your provider, then set things up that you are connected.

Steps to setup the pkgsrc/net/6to4 package are:

1. Install the package either by compiling it from pkgsrc, or by pkg_add'ing the 6to4-1.1nb1 package.

   # cd /usr/pkgsrc/net/6to4
   # make install
   

2. Make sure you have the stf(4) pseudo-device in your kernel, see above.

3. Configure the '6to4' package. Frist, copy /usr/pkg/etc/6to4.conf-example to /usr/pkg/etc/6to4.conf, then adjust the variables. Note that the file is in perl syntax.

   # cd /usr/pkg/etc
   # cp 6to4.conf-example 6to4.conf
   # vi 6to4.conf
   

   Please see the 6to4(8) manpage for an explanation of all the variables you can set in 6to4.conf. If you have diapup IP via PPP, and don't want to run Router Advertizing for other IPv6 machines on your home or office network, you don't need to configure anything. If you want to setup Router Advertising, you need to set the in_if to the internal (ethernet) interface, e.g.

   $in_if="rtk0";            # Inside (ethernet) interface
   

4. Now dial up, then start the 6to4 command manually:

   # /usr/pkg/sbin/6to4.pl start
   

   After that, you should be connected, use ping6(8) etc. to see if everything works. If it does, you can put the following lines into your /etc/ppp/ip-up script to run the command each time you go online:

   logger -p user.info -t ip-up Configuring 6to4 IPv6
   /usr/pkg/sbin/6to4.pl stop
   /usr/pkg/sbin/6to4.pl start
   

5. If you want to route IPv6 for your LAN, you can instruct 6to4.pl to setup Router Advertising for you too:

   # /usr/pkg/sbin/6to4 rtadvd-start
   

   You can put that command into /etc/ppp/ip-up as well to make it permanent.

6. If you have changed /etc/ppp/ip-up to setup 6to4 automatically, you will most likely want to change /etc/ppp/ip-down too, to shut it down when you go offline. Here's what to put into /etc/ppp/ip-down:

   logger -p user.info -t ip-down Shutting down 6to4 IPv6
   /usr/pkg/sbin/6to4.pl rtadvd-stop   
   /usr/pkg/sbin/6to4.pl stop
   

11.3.4.9 Known 6to4 Gateway

There are not many public 6to4 gateways available today, and from the few available, you will want to chose the one closest to you, netwise. A list of known working 6to4 gateways is available at http://www.kfu.com/~nsayer/6to4/. In tests, only 6to4.kfu.com and 6to4.ipv6.microsoft.com were found working. Cisco has another one that you have to register to before using it, see http://www.cisco.com/ipv6/.

There's also an experimental 6to4 server located in Germany, 6to4.ipv6.fh-regensburg.de. This server runs under NetBSD 1.5 and was setup using the configuration steps described above. The whole configuration of the machine can be seen at http://www.feyrer.de/IPv6/netstart.local.

11.3.4.10 Conclusion & Further Reading

Compared to where IPv4 is today, IPv6 is still in it's early steps. It is working, there are all sort of services and clients available, only the userbase is missing. It is hoped the information provided here helps people better understand what IPv6 is, and to start playing with it.

A few links should be mentioned here for interested parties:

• An example script to setup 6to4 on BSD based machines is available at http://www.NetBSD.org/packages/net/hf6to4/. The script determines your IPv6 address and sets up 6to4 and (if wanted) router advertising. It was designed to work in dialup setups with changing IPv4 addresses.

• Given that there isn't a standard for IPv6 in Linux land today, there are different setup instructions for most distributions. The setup of IPv6 on Debian Linux can be found at http://people.debian.org/~csmall/ipv6/setup.html and http://www.mailgate.org/linux/linux.debian.ipv6/msg00137.html.

• The BSD Unix implementations have their own IPv6 documentation each, interresting URLs are http://www.NetBSD.org/Documentation/network/ipv6/ for NetBSD, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html for FreeBSD and pages 61 and 62 of the BSD/OS Administrator's Guide at http://www.bsdi.com/products/internet/release-notes/rn42.pdf.

• Projects working on implementing IPv6 protocol stacks for free Unix like operating systems are KAME for BSD and USAGI for Linux. Their web sites can be found at http://www.kame.net/ and http://www.linux-ipv6.org/. A list of host and router implementations can be found at http://playground.sun.com/pub/ipng/html/ipng-implementations.html.

• Besides the official RFC archive at ftp://ftp.isi.edu/in-notes, information on IPv6 can be found at several web sites. First and foremost, the 6Bone's web page at http://www.6bone.net/ must be mentioned. 6Bone was started as the testbed for IPv6, and is now an important part of the IPv6-connected world. Other web pages that contain IPv6-related contents include http://www.ipv6.org/, http://playground.sun.com/pub/ipng/html/ and http://www.ipv6forum.com/. Most of these sites carry further links - be sure to have a look!