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

The /etc/resolv.conf file must be configured using the information supplied by the provider, especially 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

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
shells:        files

The defaults of doing hostname lookups via /etc/hosts followed by the DNS works fine and there's usually no need to modify this.

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).

# mkdir /etc/ppp
# mkdir /etc/ppp/peers 

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.

debug
kdebug 4

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 ''

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:

Most providers use a PAP/CHAP authentication.

user * password

alan * pZY9o

# chown root /etc/ppp/pap-secrets
# chown root /etc/ppp/chap-secrets
# chmod 600 /etc/ppp/pap-secrets
# chmod 600 /etc/ppp/chap-secrets

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

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.

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(1) program can be used, as in the following 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(1). Cables are a frequent cause of trouble, too.

When you start cu(1) and a message saying “Permission denied” appears, check who is the owner of the /dev/tty## device, it must be "uucp". For example:

$ ls -l /dev/tty00
crw-------  1 uucp  wheel  8, 0 Mar 22 20:39 /dev/tty00

If the owner is root, the following happens:

$ ls -l /dev/tty00
crw-------  1 root  wheel  8, 0 Mar 22 20:39 /dev/tty00
$ cu -p modem
cu: open (/dev/tty00): Permission denied
cu: All matching ports in use

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.

 # pkill -HUP pppd 

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-start and ppp-stop.

ppp-start 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-stop 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 process ID (pid) of the pppd process.

The two scripts must be executable:

# chmod u+x ppp-start ppp-stop

If you find yourself to always run the same set of commands each time you dial in, you can put them in a script /etc/ppp/ip-up which will be called by pppd(8) after successful dial-in. Likewise, before the connection is closed down, /etc/ppp/ip-down is executed. Both scripts are expected to be executable. See pppd(8) for more details.

To use IPNAT, the “pseudo-device ipfilter” must be compiled into the kernel, and IP packet forwarding must be enabled in the kernel. To check, run:

# 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:

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.

For the setup, 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.

Next, 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.

Create a /etc/resolv.conf file like the one on the gateway machine, to make the clients access the same DNS server as the gateway.

Next, make all clients use the gateway as their default router. Use 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: the default route will be set automatically during system initialization, using 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.

The following commands can be useful for diagnosing problems:

In this example two physical networks are going to be combined in one logical network, 192.168.1.0, using a NetBSD bridge. The NetBSD machine which is going to act as bridge has two interfaces, ne0 and ne1, which are each connected to one physical network.

The first step is to make sure support for the “bridge” is compiled in the running kernel. Support is included in the GENERIC kernel.

When the system is ready the bridge can be created, this can be done using the brconfig(8) command. First of a bridge interface has to be created. With the following ifconfig command the “bridge0” interface will be created:

$ ifconfig bridge0 create

Please make sure that at this point both the ne0 and ne1 interfaces are up. The next step is to add the ne0 and ne1 interfaces to the bridge.

$ brconfig bridge0 add ne0 add ne1 up

This configuration can be automatically set up by creating an /etc/ifconfig.interface file, in this case /etc/ifconfig.bridge0, with the following contents:

create
        !brconfig $int add ne0 add ne1 up

After setting up the bridge the bridge configuration can be displayed using the brconfig -a command. Remember that if you want to give the bridge machine an IP address you can only allocate an IP address to one of the interfaces which are part of the bridge.

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.

# slattach -p slip -s 115200 /dev/ttyS0 &
# ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up
# route add 192.168.1.1 dev sl0

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 nameservers 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.

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:

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.

6to4 is an easy way to get IPv6 connectivity for hosts that only have an IPv4 uplink, especially if you have the background given in Section 22.7, “Next generation Internet protocol - IPv6”. 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.

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 23.3, “6to4 derives an IPv6 from an IPv4 address” 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.

Figure 23.3. 6to4 derives an IPv6 from an IPv4 address

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

To transmit IPv6 packets, the 6to4 router will encapsulate them inside IPv4 packets; a system performing these functions is called a 6to4 border router. These packets have a default route to the 6to4 relay anycast prefix. This anycast prefix will route the tunnel to a 6to4 relay router. Figure 23.4, “Request and reply can be routed via different gateways in 6to4” illustrates this.

Figure 23.4. Request and reply can be routed via different gateways in 6to4

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:

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.

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

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. In NetBSD 4.0 and newer, the driver is already present in GENERIC kernel configurations, so the procedure below is usually unnecessary.

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 on NetBSD releases older than 4.0. Rebuild your kernel, then reboot your system to use the new kernel. Please consult Chapter 31, Compiling the kernel for further information on configuring, building and installing a new kernel!

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

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

# ifconfig stf0 create
# ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias
      

After configuring the 6to4 device with these commands, routing needs to be setup, to forward all tunneled IPv6 traffic to the 6to4 relay router. 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:c058:6301::

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 an 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 an 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 an 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

Figure 23.5. Enabling packet forwarding is needed for a 6to4 router

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

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 'hf6to4' 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/hf6to4 package are:

It is normally not necessary to pick a specific 6to4 relay router, but if necessary, you may find a list of known working routers at http://www.kfu.com/~nsayer/6to4/. In tests, only 6to4.kfu.com and 6to4.ipv6.microsoft.com were found working. Cisco has one that requires registration, 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.6 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.

The 6to4 protocol encapsulates IPv6 packets in IPv4, and gives them their own IP type, which most firewalls block as unknown, as their payload type is directly "TCP", "UDP" or "ICMP". Usually, you want to setup your 6to4 gateway on the same machine that is directly connected to the (IPv4) internet, and which usually runs the firewall. For the case that you want to run your 6to4 gateway behind a firewall, you need to drill a hole into the firewall, to let 6to4 packets through. Here is how to do this!

The example assumes that you use the "ppp0" interface on your firewall to connect to the Internet.

Put the following lines into /etc/ipf.conf to allow your IPfilter firewall let all 6to4 packets pass (lines broken with \ due to space restrictions; please put them lines continued that way all in one line):

# Handle traffic by different rulesets
block in  quick on ppp0 all head 1
block out quick on ppp0 all head 2

### Incoming packets:
# allow some IPv4:
pass  in  log quick on ppp0 proto tcp from any to any \
port = www flags S keep state keep frags  group 1
pass  in      quick on ppp0 proto tcp from any to any \
port = ssh keep state         group 1
pass  in      quick on ppp0 proto tcp from any to any \
port = mail keep state        group 1
pass  in  log quick on ppp0 proto tcp from any to any \
port = ftp keep state       group 1
pass  in  log quick on ppp0 proto tcp from any to any \
port = ftp-data keep state      group 1
pass  in  log quick on ppp0 proto icmp from any to any        group 1
# allow all IPv6:
pass in       quick on ppp0 proto ipv6       from any to any  group 1
pass in  log  quick on ppp0 proto ipv6-route from any to any  group 1
pass in  log  quick on ppp0 proto ipv6-frag  from any to any  group 1
pass in  log  quick on ppp0 proto ipv6-icmp  from any to any  group 1
pass in  log  quick on ppp0 proto ipv6-nonxt from any to any  group 1
pass in  log  quick on ppp0 proto ipv6-opts  from any to any  group 1
# block rest:
blockin  log  quick on ppp0 all                               group 1

### Outgoing packets:
# allow usual stuff:
pass  out     quick on ppp0 proto  tcp from any to any flags S \
keep state keep frags group 2
pass  out     quick on ppp0 proto  udp from any to any         \
keep state keep frags group 2
pass  out     quick on ppp0 proto icmp from any to any         \
keep state            group 2
# allow all IPv6:
pass out      quick on ppp0 proto ipv6       from any to any  group 2
pass out log  quick on ppp0 proto ipv6-route from any to any  group 2
pass out log  quick on ppp0 proto ipv6-frag  from any to any  group 2
pass out log  quick on ppp0 proto ipv6-icmp  from any to any  group 2
pass out log  quick on ppp0 proto ipv6-nonxt from any to any  group 2
pass out log  quick on ppp0 proto ipv6-opts  from any to any  group 2
# block rest:
block out log quick on ppp0 all             group 2

Now any host on your network can send (the "out" rules) and receive (the "in" rules) v4-encapsulated IPv6 packets, allowing setup of any of them as a 6to4 gateway. Of course you only want to do this on one host and use native IPv6 between your hosts, and you may also want to enforce this with more restrictive rulesets, please see ipf.conf(5) for more information on IPFilter rules.

After your firewall lets pass encapsulated IPv6 packets, you may want to set up your 6to4 gateway to monitor the IPv6 traffic, or even restrict it. To do so, you need to setup IPfilter on your 6to4 gateway as well. For basic monitoring, enable "ipfilter=yes" in /etc/rc.conf and put the following into /etc/ipf6.conf:

pass in  log quick on stf0 from any to any
pass out log quick on stf0 from any to any

This logs all (IPv6) traffic going in and out of your "stf0" tunneling interface. You can add filter rules as well if needed.

If you are more interested in traffic stats than a general overview of your network traffic, using MRTG in conjunction with the "net-snmp" package is recommended instead of analyzing IPfilter log files.

Compared to where IPv4 is today, IPv6 is still in its 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: