24.1. A walk through the kernel configuration

Before we dive into configuring various aspects of network
setup, we want to walk through the necessary bits that have to
or can be present in the kernel. See Chapter 32, Compiling the kernel for more details on compiling the
kernel, we will concentrate on the configuration of the kernel
here. We will take the i386/GENERIC config file as an example
here. Config files for other platforms should contain similar
information, the comments in the config files give additional
hints. Besides the information given here, each kernel option
is also documented in the options(4) manpage, and there is
usually a manpage for each driver too, e.g. tlp(4).

The first line of each config file shows the version.
It can be used to compare against other
versions via CVS, or when reporting bugs.

options NTP # NTP phase/frequency locked loop

If you want to run the Network Time Protocol
(NTP), this
option can be enabled for maximum precision. If the option is
not present, NTP will still work. See ntpd(8) for more
information.

If you want to setup a router that forwards packets between
networks or network interfaces, setting this option is
needed. It doesn't only switch on packet forwarding, but also
increases some buffers. See options(4) for details.

options INET # IP + ICMP + TCP + UDP

This enables the TCP/IP code in the kernel. Even if you don't
want/use networking, you will still need this for
machine-internal communication of subsystems like the X Window
System. See inet(4) for more details.

Includes support for the IPsec protocol, including key and
policy management, authentication and compression. This option
can be used without the previous option INET6, if you just
want to use IPsec with IPv4, which is possible. See ipsec(4)
for more information.

#options IPSEC_ESP # IP security (encryption part; define w/IPSEC)

This option is needed in addition to IPSEC if encryption is
wanted in IPsec.

#options MROUTING # IP multicast routing

If multicast services like the MBone services should be routed,
this option needs to be included. Note that the routing itself
is controlled by the mrouted(8) daemon.

options ISO,TPIP # OSI
#options EON # OSI tunneling over IP

These options include the OSI protocol
stack, which was said
for a long time to be the future of networking. It's mostly
history these days. :-) See the iso(4) manpage for more
information.

options NETATALK # AppleTalk networking protocols

Include support for the AppleTalk protocol stack. Userland
server programs are needed to make use of that. See
pkgsrc/net/netatalk and pkgsrc/net/netatalk-asun for such
packages. More information on the AppleTalk protocol and
protocol stack are available in the atalk(4) manpage.

This option is only needed if you have machines on the network
that still run 4.2BSD or a network stack derived from it. If
you've got one or more 4.2BSD-systems on your network, you've
to pay attention to set the right broadcast-address, as
4.2BSD has a bug in its networking code, concerning the
broadcast address. This bug forces you to set all host-bits
in the broadcast-address to “0”. The TCP_COMPAT_42
option helps you ensuring this.

options NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM

These options enable lookup of data via DHCP or the BOOTPARAM
protocol if the kernel is told to use a NFS root file
system. See the diskless(8) manpage for more information.

These lines tell where the kernel looks for its root file
system, and which filesystem type it is expected to have. If
you want to make a kernel that uses a NFS root filesystem via
the tlp0 interface, you can do this with “root on tlp0 type
nfs”. If a ? is used instead of a
device/type, the kernel
tries to figure one out on its own.

If you want to use PPP or SLIP, you will need some serial
(com) interfaces. Others with attachment on USB, PCMCIA or PUC
will do as well.

# Network Interfaces

This rather long list contains all sorts of network
drivers. Please pick the one that matches your hardware,
according to the comments. For most drivers, there's also a
manual page available, e.g. tlp(4), ne(4), etc.

# MII/PHY support

This section lists media independent interfaces for network
cards. Pick one that matches your hardware. If in doubt,
enable them all and see what the kernel picks. See the mii(4)
manpage for more information.

USB-ethernet adapters only have about 2MBit/s bandwidth, but
they are very convenient to use. Of course this needs other
USB related options which we won't cover here, as well as the
necessary hardware. See the corresponding
manpages for more information.

This is the “lo0” software loopback network device
which is used by some programs these days, as well as for routing
things. It should not be omitted. See lo(4) for more details.

pseudo-device ppp 2 # Point-to-Point Protocol

If you want to use PPP either over a serial interface or
ethernet (PPPoE), you will need this option. See ppp(4) for
details on this interface.

pseudo-device sl 2 # Serial Line IP

Serial Line IP is a simple encapsulation for IP over (well :)
serial lines. It does not include negotiation of IP addresses
and other options, which is the reason that it's not in
widespread use today any more. See sl(4).

pseudo-device strip 2 # Starmode Radio IP (Metricom)

If you happen to have one of the old Metricom Ricochet packet
radio wireless network devices, use this pseudo-device to use
it. See the strip(4) manpage for detailed information.

pseudo-device tun 2 # network tunneling over tty

This network device can be used to tunnel network packets to a
device file, /dev/tun*. Packets routed to
the tun0 interface can be read from
/dev/tun0, and data written to
/dev/tun0 will be sent out the tun0
network interface. This can be used to implement e.g. QoS
routing in userland. See tun(4) for details.

pseudo-device gre 2 # generic L3 over IP tunnel

The GRE encapsulation can be used to tunnel arbitrary layer 3
packets over IP, e.g. to implement
VPNs. See gre(4) for more.

pseudo-device gif 4 # IPv[46] over IPv[46] tunnel (RFC 1933)

Using the GIF interface allows to tunnel
e.g. IPv6 over IPv4, which can be used to get IPv6
connectivity if no IPv6-capable uplink (ISP) is
available. Other mixes of operations are possible, too. See
the gif(4) manpage for some examples.

#pseudo-device faith 1 # IPv[46] tcp relay translation i/f

The faith interface captures IPv6 TCP traffic, for
implementing userland IPv6-to-IPv4 TCP relays e.g. for
protocol transitions. See the faith(4) manpage for more
details on this device.

#pseudo-device stf 1 # 6to4 IPv6 over IPv4 encapsulation

This adds a network device that can be used to tunnel IPv6 over
IPv4 without setting up a configured tunnel before. The source
address of outgoing packets contains the IPv4 address, which
allows routing replies back via IPv4. See the stf(4) manpage
and Section 24.9, “IPv6 Connectivity & Transition via 6to4” for more details.

pseudo-device vlan # IEEE 802.1q encapsulation

This interface provides support for IEEE 802.1Q Virtual LANs,
which allows tagging Ethernet frames with a “vlan” ID.
Using properly configured switches (that also have to support VLAN,
of course), this can be used to build virtual LANs where one
set of machines doesn't see traffic from the other (broadcast
and other). The vlan(4) manpage tells more about this.

24.2. Overview of the network configuration files

The following is a list of the files used to configure the
network. The usage of these files, some of which have already
been met the first chapters, will be described in the
following sections.

/etc/hosts

Local hosts database file. Each line contains information
regarding a known host and contains the internet address,
the host's name and the aliases. Small networks can be
configured using only the hosts file, without a
name server.

/etc/resolv.conf

This file specifies how the routines which provide access
to the Internet Domain Name System should operate.
Generally it contains the addresses of the name servers.

/etc/ifconfig.xxx

This file is used for the automatic configuration of the
network card at boot.

/etc/mygate

Contains the IP address of the gateway.

/etc/nsswitch.conf

Name service switch configuration file. It controls how a
process looks up various databases containing information
regarding hosts, users, groups, etc. Specifically, this
file defines the order to look up the databases. For
example, the line:

hosts: files dns

specifies that the hosts database comes from two
sources, files (the local
/etc/hosts file) and
DNS, (the Internet Domain Name
System) and that the local files are searched before
the DNS.

It is usually not necessary to modify this file.

24.3. Connecting to the Internet with a modem

There are many types of Internet connections: this section
explains how to connect to a provider using a modem over a
telephone line using the PPP protocol, a
very common setup.
In order to have a working connection, the following steps must be
done:

Get the necessary information from the provider.

Edit the file /etc/resolv.conf and
check /etc/nsswitch.conf.

Create the directories /etc/ppp
and /etc/ppp/peers if they don't exist.

Create the connection script, the chat file and the
pppd options file.

Created the user-password authentication file.

Judging from the previous list it looks like a complicated
procedure that requires a lot of work.
Actually, the single steps are very easy: it's just a matter of
modifying, creating or simply checking some small text files.
In the following example it will be assumed that the modem is
connected to the second serial port
/dev/tty01 (COM2 in DOS).

A few words on the difference between com,
COM and tty. For
NetBSD, “com” is the name of the serial port driver
(the one that is displayed by dmesg) and
“tty” is the name of the port. Since numbering
starts at 0, com0 is the driver for the first serial port,
named tty00. In the DOS world, instead, COM1 refers to the
first serial port (usually located at 0x3f8), COM2 to the
second, and so on. Therefore COM1 (DOS) corresponds to
/dev/tty00 (NetBSD).

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

24.3.2. resolv.conf and
nsswitch.conf

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

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

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

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

24.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:

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.

Note

If you are experiencing connection problems, add the
following two lines to the connection script

debug
kdebug 4

You will get a log of the operations performed when the system
tries to connect.
See pppd(8), syslog.conf(5).

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:

Note

If you have problems with the chat file, you can try connecting
manually to the POP with the cu(1)
program and verify the exact strings that you are receiving.

24.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:

PAP/CHAP

login

Most providers use a PAP/CHAP authentication.

24.3.5.1. PAP/CHAP authentication

The authentication information (speak: password) is stored
in the /etc/ppp/pap-secrets for PAP
and in /etc/ppp/chap-secrets for
CHAP. The lines have the following format:

user * password

For example:

alan * pZY9o

For security reasons the pap-secrets and
chap-secrets files should be owned by
root and have permissions “600”.

24.3.5.2. Login authentication

This type of authentication is not widely used today; if the provider
uses login authentication, user name and password must be supplied
in the chat file instead of the PAP/CHAP files, because the
chat file simulates an interactive login.
In this case, set up appropriate permissions for the chat file.

24.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(1) program can be used, as in the
following example.

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

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(1), 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(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:

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

24.3.10. Running commands after dialin

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.

24.4. Creating a small home network

Networking is one of the main strengths of Unix and NetBSD is no
exception: networking is both powerful and easy to set up and
inexpensive too, because there is no need to buy additional software to
communicate or to build a server.
Section 24.5, “Setting up an Internet gateway with IPNAT” explains how
to configure a NetBSD machine
to act as a gateway for a network: with IPNAT all
the hosts of the network can reach the Internet with a single
connection to a provider made by the gateway machine.
The only thing to be checked before creating the network is to buy
network cards supported by NetBSD (check the
INSTALL.* files for a list of supported
devices).

If the card is not recognized by the kernel, check that it is
enabled in the kernel configuration file and then that the
card's IRQ matches the one that the kernel expects.
For example, this is the isa NE2000 line in the configuration
file; the kernel expects the card to be at IRQ 9.

...
ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards
...

If the card's configuration is different, it will probably not be
found at boot.
In this case, either change the line in the kernel configuration
file and compile a new kernel or change the card's setup (usually
through a setup disk or, for old cards, a jumper on the card).

The output of ifconfig has now changed: the
IP address is now printed and there are two new flags,
“UP” and “RUNNING”
If the interface isn't “UP”, it will not be used by the
system to send packets.

The host was given the IP address 192.168.1.1, which belongs to
the set of addresses reserved for internal networks which are not
reachable from the Internet.
The configuration is finished and must now be tested; if
there is another active host on the network, a
ping can be tried.
For example, if 192.168.1.2 is the address of the active host:

With the current setup, at the next boot it will be necessary to
repeat the configuration of the network card.
In order to avoid repeating the card's configuration at each
boot, add the following lines to
/etc/rc.conf:

auto_ifconfig=yes
ifconfig_ne0="inet 192.168.1.1 netmask 0xffffff00"

In this example the variable ifconfig_ne0
was set because the network card was recognized as
ne0 by the kernel; if you are using a
different adapter, substitute the appropriate name in place of
ne0.

At the next boot the network card will be configured
automatically.

If you have a router that is connected to the internet, you
can use it as default router, which will handle all your
packets. To do so, set defaultroute to the
router's IP address in /etc/rc.conf:

defaultroute=192.168.0.254

Be sure to use the default router's IP address instead of
name, in case your DNS server is beyond the default router. In
that case, the DNS server couldn't be reached to resolve the
default router's hostname and vice versa, creating a
chicken-and-egg problem.

To reach hosts on your local network, and assuming you really
have very few hosts, adjust /etc/hosts to
contain the addresses of all the hosts belonging to the
internal network. For example:

Example 24.9. /etc/hosts

#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# It is used only for "ifconfig" and other operations
# before the nameserver is started.
#
#
127.0.0.1 localhost
::1 localhost
#
# RFC 1918 specifies that these networks are "internal".
# 10.0.0.0 10.255.255.255
# 172.16.0.0 172.31.255.255
# 192.168.0.0 192.168.255.255
192.168.1.1 ape.insetti.net ape
192.168.1.2 vespa.insetti.net vespa
192.168.1.0 insetti.net

If you are dialed in via an Internet Service Provider, or if
you have a local Domain Name Server (DNS) running, you may
want to use it to resolve hostnames to IP addresses, possibly
in addition to /etc/hosts, which would
only know your own hosts. To configure a machine as DNS
client, you need to edit
/etc/resolv.conf, and enter the DNS
server's address, in addition to an optional domain name that
will be appended to hosts with no domain, in order to create a
FQDN for resolving. Assuming your DNS server's IP address is
192.168.1.2 and it is setup to serve for "home.net", put the
following into /etc/resolv.conf:

Summing up, to configure the network the following must be done:
the network adapters must be installed and physically connected.
Next they must be configured (with ifconfig)
and, finally, the file /etc/rc.conf must
be modified to configure the interface and possibly default
router, and /etc/resolv.conf and
/etc/nsswitch.conf should be adjusted if
DNS should be used.
This type of network management is sufficient for small
networks without sophisticated needs.

24.5. Setting up an Internet gateway with IPNAT

The mysterious acronym IPNAT hides the
Internet Protocol Network Address Translation, which enables the
routing of an internal network (e.g. your home network as
described in Section 24.4, “Creating a small home network ”) on
a real network (Internet). This means that with only one
“real” IP, static or dynamic, belonging to a
gateway running IPNAT, it is possible to create simultaneous
connections to the Internet for all the hosts of the internal
network.

Some usage examples of IPNAT can be found in the subdirectory
/usr/share/examples/ipf: look at the files
BASIC.NAT and
nat-setup.

The setup for the example described in this section is detailed
in Figure 24.1, “Network with gateway”:
host 1 can connect to the Internet calling
a provider with a modem and getting a dynamic IP address.
host 2 and host 3 can't
communicate with the Internet with a normal setup: IPNAT allows
them to do it: host 1 will act as a Internet gateway for hosts
2 and 3. Using host 1 as default router, hosts 2 and 3 will be
able to access the Internet.

Figure 24.1. Network with gateway

24.5.1. Configuring the gateway/firewall

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:

Compile a new kernel, with the GATEWAY option enabled.

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 to add

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.

For the setup, first, create the
/etc/ipnat.conf file containing the
following rules:

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.

24.5.2. Configuring the clients

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.

24.5.3. Some useful commands

The following commands can be useful for
diagnosing problems:

ping

netstat -r

Displays the routing tables (similar to
route show).

traceroute

On the client it shows the route followed by the packets to
their destination.

tcpdump

Use on the gateway to monitor TCP/IP traffic.

24.6. Setting up a network bridge device

A bridge can be used to combine different physical networks
into one logical network, i.e. connect them at layer 2 of the
ISO-OSI model, not at layer 3, which is what a router would
do. The NetBSD “bridge” driver
provides bridge functionality on NetBSD systems.

24.6.1. Bridge example

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.

24.7. A common LAN setup

The small home network discussed in the previous section
contained many items that were configured manually. In bigger
LANs that are centrally managed, one can expect Internet
connectivity being available via some router, a DNS server
being available, and most important, a DHCP server which hands
out IP addresses to clients on request. To make a NetBSD client
run in such an environment, it's usually enough to set

dhclient=yes

in /etc/rc.conf, and the IP address will
be set automatically, /etc/resolv.conf
will be created and routing setup to the default router.

24.8. Connecting two PCs through a serial line

If you need to transfer files between two PCs which are not networked
there is a simple solution which is particularly handy when
copying the files to a floppy is not practical: the two machines
can be networked with a serial cable (a null modem
cable).
The following sections describe some configurations.

24.8.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 -sspeed option to slattach
can be specified.

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

Linux

If one of the two PC's runs Linux, the commands are slightly
different (on the Linux machine only).
If the Linux machine gets the 192.168.1.2 address, the
following commands are needed:

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

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.

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.

24.8.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:

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.

24.9. IPv6 Connectivity & Transition via 6to4

This section will concentrate on how to get network
connectivity for IPv6 and - as that is rarely available directly
- talk at length about the alternatives to native
IPv6 connectivity as a transitional method until native IPv6 peers
are available.

Finding an ISP that offers IPv6 natively needs quite some
luck. What you need next is a router that will be able to
handle the traffic. To date, not all router manufacturers
offer IPv6 or hardware accelerated IPv6 features, and
gateway NAT boxes only rarely support IPv6 and also block IPv6 tunnels.
An alternative approach involves configuring
a standard PC running NetBSD to act as a router.
The base NetBSD system contains a complete IPv6 routing solution,
and for special routing needs software like
Zebra can provide additional routing protocols. This solution is
rather common for sites that want IPv6 connectivity
today. The drawbacks are that you need an ISP that supports
IPv6 and that you may need a dedicated uplink only for IPv6.

IPv6 to-the-door may be rare, but you can still get IPv6
connectivity by using tunnels. Instead of talking IPv6 on the
wire, the IPv6 packets are encapsulated in IPv4 packets, as shown
in Figure 24.2, “A frequently used method for transition is tunneling IPv6 in
IPv4 packets”. Using the existing IPv4
infrastructure, the encapsulated packets are sent to a
IPv6-capable uplink that will then remove the encapsulation, and
forward the IPv6 packets.

Figure 24.2. A frequently used method for transition is tunneling IPv6 in
IPv4 packets

When using tunnels, there are two possibilities. One is to use
a so-called “configured” tunnel, the other is called an
“automatic” tunnel. A “configured” tunnel
is one that required preparation from both ends of the tunnel,
usually connected with some kind of registration to exchange setup
information. An example for such a configured tunnel is the
IPv6-over-IPv4 encapsulation described in [RFC1933],
and that's implemented e.g. by the gif(4)
device found in NetBSD.

An “automatic” tunnel consists of a public server
that has some kind of IPv6 connectivity, e.g. via 6Bone. That server
has made its connectivity data public, and also runs a
tunneling protocol that does not require an explicit
registration of the sites using it as uplink. A well-used
example of such a protocol is the 6to4 mechanism described in
[RFC3056], and that is implemented in the
stf(4) device found in NetBSD's. Another mechanism that
does not require registration of IPv6-information is the 6over4
mechanism, which implements transporting of IPv6 over a
multicast-enabled IPv4 network, instead of e.g. ethernet or
FDDI. 6over4 is documented in [RFC2529].
It's main drawback is
that you do need existing multicast infrastructure. If you
don't have that, setting it up is about as much effort as
setting up a configured IPv6 tunnel directly, so it's usually
not worth bothering in that case.

24.9.1. Getting 6to4 IPv6 up & running

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

24.9.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
216 IPv6 subnets, which can take
up to 264 nodes each.
Figure 24.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 24.3. 6to4 derives an IPv6 from an IPv4 address

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

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

24.9.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:

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.

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

The 6to4 IPv6 relay anycast address.
which is 2002:c058:6301::, or
the IPv6 address of a specific 6to4 relay router you want
to use. The IPv6 address will do, as it also contains the
IPv4 address in the usual 6to4 translation.

24.9.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. 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:

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 32, Compiling the kernel for further information on
configuring, building and installing a new kernel!

24.9.7. 6to4 Setup

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

Configure interface

Set default route

Setup Router Advertisement, if wanted

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:

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

24.9.8. Quickstart using pkgsrc/net/hf6to4

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:

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

#cd /usr/pkgsrc/net/hf6to4#make install

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

Configure the 'hf6to4' package. First, copy
/usr/pkg/share/examples/hf6to4/hf6to4.conf to
/usr/pkg/etc/hf6to4.conf, then adjust
the variables. Note that the file is in /bin/sh syntax.

Please see the hf6to4(8) manpage for an explanation of all
the variables you can set in
hf6to4.conf. If you have dialup 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

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

#/usr/pkg/sbin/hf6to4 start

After that, you should be connected, use
ping6(8): to see if everything works:

24.9.9. Known 6to4 Relay Routers

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.

24.9.10. Tunneling 6to4 through an IPFilter firewall

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.

24.9.11. Conclusion & Further Reading

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:

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.