Diff for /wikisrc/guide/net-practice.mdwn between versions 1.5 and 1.8

version 1.5, 2015/06/19 19:18:31 version 1.8, 2021/04/12 13:15:03
Line 1 Line 1
 **Contents**  This page was moved to:
   [The NetBSD Guide - Setting up TCP/IP on NetBSD in practice](//www.NetBSD.org/docs/guide/en/chap-net-practice.html)
 [[!toc levels=3]]  
   
 # Setting up TCP/IP on NetBSD in practice  
   
 ## 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 [[Compiling the kernel|guide/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   
 [[!template id=man name="options" section="4"]]   
 manpage, and there is usually a manpage for each driver too, e.g.   
 [[!template id=man name="tlp" section="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   
 [[!template id=man name="ntpd" section="8"]] for   
 more information.  
   
     file-system     NFS             # Network File System client  
   
 If you want to use another machine's hard disk via the Network File System   
 (NFS), this option is needed. The guide article about the  
 [[Network File System|guide/net-services#nfs]] gives more information on NFS.  
   
     options         NFSSERVER       # Network File System server  
   
 This option includes the server side of the NFS remote file sharing protocol.   
 Enable if you want to allow other machines to use your hard disk. The mentioned   
 article in the guide about [[NFS|guide/net-services#nfs]] contains more   
 information on NFS.  
   
     #options        GATEWAY         # packet forwarding  
   
 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   
 [[!template id=man name="options" section="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   
 [[!template id=man name="inet" section="4"]] for   
 more details.  
   
     options         INET6           # IPV6  
   
 If you want to use IPv6, this is your option. If you don't want IPv6, which is   
 part of NetBSD since the 1.5 release, you can remove/comment out that option.   
 See the   
 [[!template id=man name="inet6" section="4"]]   
 manpage and [[Next generation Internet protocol -   
 IPv6|guide/net-intro#ipv6-intro]] for more information on the next generation   
 Internet protocol.  
   
     #options        IPSEC           # IP security  
   
 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   
 [[!template id=man name="ipsec" section="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   
 [[!template id=man name="mrouted" section="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   
 [[!template id=man name="iso" section="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   
 [[!template id=man name="atalk" section="4"]]   
 manpage.  
   
     options         PPP_BSDCOMP     # BSD-Compress compression support for PPP  
     options         PPP_DEFLATE     # Deflate compression support for PPP  
     options         PPP_FILTER      # Active filter support for PPP (requires bpf)  
   
 These options tune various aspects of the Point-to-Point protocol. The first two   
 determine the compression algorithms used and available, while the third one   
 enables code to filter some packets.  
   
     options         PFIL_HOOKS      # pfil(9) packet filter hooks  
     options         IPFILTER_LOG    # ipmon(8) log support  
   
 These options enable firewalling in NetBSD, using IPFilter. See the   
 [[!template id=man name="ipf" section="4"]] and   
 [[!template id=man name="ipf" section="8"]] manpages   
 for more information on operation of IPFilter, and [[Configuring the   
         gateway/firewall|guide/net-practice#ipnat-configuring-gateway]] for a   
         configuration example.  
   
     # Compatibility with 4.2BSD implementation of TCP/IP.  Not recommended.  
     #options        TCP_COMPAT_42  
   
 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   
 [[!template id=man name="diskless" section="8"]]   
 manpage for more information.  
   
     # Kernel root file system and dump configuration.  
     config          netbsd  root on ? type ?  
     #config         netbsd  root on sd0a type ffs  
     #config         netbsd  root on ? type nfs  
   
 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.  
   
     # ISA serial interfaces  
     com0    at isa? port 0x3f8 irq 4        # Standard PC serial ports  
     com1    at isa? port 0x2f8 irq 3  
     com2    at isa? port 0x3e8 irq 5  
   
 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.   
 [[!template id=man name="tlp" section="4"]],   
 [[!template id=man name="ne" section="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   
 [[!template id=man name="mii" section="4"]] manpage   
 for more information.  
   
     # USB Ethernet adapters  
     aue*    at uhub? port ?         # ADMtek AN986 Pegasus based adapters  
     cue*    at uhub? port ?         # CATC USB-EL1201A based adapters  
     kue*    at uhub? port ?         # Kawasaki LSI KL5KUSB101B based adapters  
   
 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.  
   
     # network pseudo-devices  
     pseudo-device   bpfilter        8       # Berkeley packet filter  
   
 This pseudo-device allows sniffing packets of all sorts. It's needed for   
 tcpdump, but also rarpd and some other applications that need to know about   
 network traffic. See   
 [[!template id=man name="bpf" section="4"]] for more   
 information.  
   
     pseudo-device   ipfilter                # IP filter (firewall) and NAT  
   
 This one enables the IPFilter's packet filtering kernel interface used for   
 firewalling, NAT (IP Masquerading) etc. See   
 [[!template id=man name="ipf" section="4"]] and   
 [Configuring the gateway/firewall|guide/net-practice#ipnat-configuring-gateway]]   
 for more information.  
   
     pseudo-device   loop                    # network loopback  
   
 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 [[!template id=man name="lo" section="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   
 [[!template id=man name="ppp" section="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   
 [[!template id=man name="sl" section="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   
 [[!template id=man name="strip" section="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   
 [[!template id=man name="tun" section="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   
 [[!template id=man name="gre" section="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   
 [[!template id=man name="gif" section="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   
 [[!template id=man name="faith" section="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   
 [[!template id=man name="stf" section="4"]] manpage   
 and [IPv6 Connectivity & Transition via 6to4|guide/net-practice#ipv6-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   
 [[!template id=man name="vlan" section="4"]] manpage   
 tells more about this.  
   
 ## 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.  
   
 ## 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:  
   
  1. Get the necessary information from the provider.  
  2. Edit the file `/etc/resolv.conf` and check `/etc/nsswitch.conf`.  
  3. Create the directories `/etc/ppp` and `/etc/ppp/peers` if they don't exist.  
  4. Create the connection script, the chat file and the pppd options file.  
  5. 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).  
   
 Besides external modems connected to COM ports (using `/dev/tty0[012]` on i386,   
 `/dev/tty[ab]` on sparc, ...) modems on USB (`/dev/ttyU*`) and pcmcia/cardbus   
 (`/dev/tty0[012]`) can be used.  
   
 ### 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.  
   
 ### 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`:  
   
     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.  
   
 ### 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   
   
 ### 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   
 [[!template id=man name="pppd" section="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 [[!template id=man name="pppd" section="8"]],   
 [[!template id=man name="syslog.conf" section="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:  
   
     # /etc/ppp/peers/bignet.chat  
     ABORT BUSY  
     ABORT "NO CARRIER"  
     ABORT "NO DIALTONE"  
     '' ATDT0299999999  
     CONNECT ''  
   
 *Note*: If you have problems with the chat file, you can try connecting manually   
 to the POP with the   
 [[!template id=man name="cu" section="1"]] program and   
 verify the exact strings that you are receiving.  
   
 ### 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.  
   
 #### 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.  
   
     # chown root /etc/ppp/pap-secrets  
     # chown root /etc/ppp/chap-secrets  
     # chmod 600 /etc/ppp/pap-secrets  
     # chmod 600 /etc/ppp/chap-secrets  
   
 #### 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.  
   
 The following is an example chat file with login authentication:  
   
     # /etc/ppp/peers/bignet.chat  
     ABORT BUSY  
     ABORT "NO CARRIER"  
     ABORT "NO DIALTONE"  
     '' ATDT0299999999  
     CONNECT ''  
     TIMEOUT 50  
     ogin: alan  
     ssword: pZY9o  
   
 ### 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   
 [[!template id=man name="pppd" section="8"]] man   
 page for the meaning of the options.  
   
 ### 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   
 [[!template id=man name="cu" section="1"]] 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   
         [[!template id=man name="cu" section="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   
 [[!template id=man name="cu" section="1"]]. Cables are   
 a frequent cause of trouble, too.  
   
 When you start   
 [[!template id=man name="cu" section="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  
   
 ### 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`.  
   
      # pkill -HUP pppd   
   
 ### 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-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  
   
 ### 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   
 [[!template id=man name="pppd" section="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   
 [[!template id=man name="pppd" section="8"]] for   
 more details.  
   
 ## 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.   
 [[Setting up an Internet gateway with IPNAT|guide/net-practice#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).  
   
 First, the network cards must be installed and connected to a hub, switch or   
 directly (see the next image for an example configuration).  
   
 Next, check that the network cards are recognized by the kernel, studying the   
 output of the `dmesg` command. In the following example the kernel recognized   
 correctly an NE2000 clone:  
   
     ...  
     ne0 at isa0 port 0x280-0x29f irq 9  
     ne0: NE2000 Ethernet  
     ne0: Ethernet address 00:c2:dd:c1:d1:21  
     ...  
   
 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 following command shows the network card's current configuration:  
   
     # ifconfig ne0  
     ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500  
     address: 00:50:ba:aa:a7:7f  
     media: Ethernet autoselect (10baseT)  
     inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1   
   
 The software configuration of the network card is very easy. The IP address   
 192.168.1.1 is assigned to the card.  
   
     # ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00  
   
 Note that the networks 10.0.0.0/8 and 192.168.0.0/16 are reserved for private   
 networks, which is what we're setting up here.  
   
 Repeating the previous command now gives a different result:  
   
     # ifconfig ne0  
     ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500  
     address: 00:50:ba:aa:a7:7f  
     media: Ethernet autoselect (10baseT)  
     inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255  
     inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1   
   
 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:  
   
     # ping 192.168.1.2  
     PING ape (192.168.1.2): 56 data bytes  
     64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms  
     64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms  
     64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms  
     64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms  
     ^C  
     ----ape PING Statistics----  
     4 packets transmitted, 4 packets received, 0.0% packet loss  
     round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms  
   
 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:  
   
     #  
     # 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`:  
   
     # /etc/resolv.conf  
     domain home.net  
     nameserver 192.168.1.2  
   
 The `/etc/nsswitch.conf` file should be checked as explained in the previous   
 [[nsswitch.conf example|guide/net-practice#rc.conf_and_nsswitch.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.  
   
 ## 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 the previous section) 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 the following   
 figure: *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.  
   
 ![Network with gateway](/guide/images/net1.gif)    
 **Network with gateway**  
   
 ### 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:  
   
  1. Compile a new kernel, with the GATEWAY option enabled.  
   
  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 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:  
   
     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.  
   
 ### 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 PCs 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.  
   
 ### Some useful commands  
   
 The following commands can be useful for diagnosing problems:  
   
  * `ping` -- tries to connect to other computers via ICMP (usually used for   
    testing if a connection exists).  
  * `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.  
   
 ## 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.  
   
 ### 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   
 [[!template id=man name="brconfig" section="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.  
   
 ## 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.  
   
 ## 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.  
   
 ### 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 PCs 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.  
   
 ### Linux  
   
 If one of the two PCs 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:  
   
     # 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  
   
 Don't forget the `&` in the first command.  
   
 ### 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 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.  
   
 ### 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 before for Windows   
    NT, 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 the section before for Windows NT.  
   
   
 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.  
   
 ## 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 the next image. 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.  
   
 ![A frequently used method for transition is tunneling IPv6 in IPv4 packets](/guide/images/ipv6-en-2tunnel.gif)    
 **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](http://tools.ietf.org/html/rfc1933) ("RFC 1933: Transition Mechanisms   
 for IPv6 Hosts and Routers"), and that's implemented e.g. by the   
 [[!template id=man name="gif" section="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](http://tools.ietf.org/html/rfc3056) ("RFC 3056: Connection of IPv6   
 Domains via IPv4 Clouds"), and that is implemented in the   
 [[!template id=man name="stf" section="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](http://tools.ietf.org/html/rfc2529) ("RFC 2529:   
 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"). 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.  
   
 ### 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  
 [[the chapter about IPv6|guide/net-intro#ipv6-intro]]. 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 are for NetBSD 1.5.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^16^ IPv6 subnets, which can take   
 up to 2^64^ nodes each. The next figure 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.  
   
 ![6to4 derives an IPv6 from an IPv4 address](/guide/images/ipv6-en-3adr.gif)    
 **6to4 derives an IPv6 from an IPv4 address**  
   
 ### 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).  
   
 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*.  
   
 ![Request and reply can be routed via different gateways in 6to4](/guide/images/ipv6-en-1scene.gif)    
 **Request and reply can be routed via different gateways in 6to4**  
   
 ### 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   
 [[!template id=man name="stf" section="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.  
   
 ### 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 the previous   
    figure ("6to4 derives an IPv6 from an IPv4 address") about how to do so.  
   
    For our example, this is 2002:3ee0:3972:0001::1 (62.224.57.114 == 0x3ee03972,   
    0001::1 arbitrarily chosen).  
   
  * 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.  
   
 ### 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:  
   
     options INET6                 # IPv6  
     pseudo-device stf             # 6to4 IPv6 over IPv4 encapsulation  
   
 Note that the   
 [[!template id=man name="stf" section="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  
 [[Compiling the kernel|guide/kernel]] for further information on configuring,   
 building and installing a new kernel!  
   
 ### 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 creating the 6to4 interface and assigning   
 an IPv6 address to it. This is achieved with the   
 [[!template id=man name="ifconfig" section="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   
 [[!template id=man name="stf" section="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  
   
 ![Enabling packet forwarding is needed for a 6to4 router](/guide/images/ipv6-en-5forward.gif)    
 **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  
   
 ### 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:  
   
  1. 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  
   
  2. Make sure you have the   
     [[!template id=man name="stf" section="4"]]   
     pseudo-device in your kernel, see above.  
   
  3. 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.  
   
         # cd /usr/pkg/etc  
         # cp ../share/examples/hf6to4/hf6to4.conf hf6to4.conf  
         # vi hf6to4.conf  
   
         Please see the   
         [[!template id=man name="hf6to4" section="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  
   
  4. Now dial up, then start the 6to4 command manually:  
   
         # /usr/pkg/sbin/hf6to4 start  
   
  5. After that, you should be connected, use   
     [[!template id=man name="ping6" section="8"]]: to   
     see if everything works:  
   
         # ping6 www.NetBSD.org  
         PING6(56=40+8+8 bytes) 2002:d954:110b:1::1 --> 2001:4f8:4:7:2e0:81ff:fe52:9a6b  
         16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=0 hlim=60 time=250.234 ms  
         16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=1 hlim=60 time=255.652 ms  
         16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=2 hlim=60 time=251.237 ms  
         ^C  
         --- www.NetBSD.org ping6 statistics ---  
         3 packets transmitted, 3 packets received, 0.0% packet loss  
         round-trip min/avg/max/std-dev = 250.234/252.374/255.652/2.354 ms  
           
         # traceroute6 www.NetBSD.org  
         traceroute6 to www.NetBSD.org (2001:4f8:4:7:2e0:81ff:fe52:9a6b)  
         from 2002:d954:110b:1::1, 64 hops max, 12 byte packets  
         1  2002:c25f:6cbf:1::1  66.31 ms  66.382 ms  69.062 ms  
         2  nr-erl1.6win.dfn.de  76.134 ms *  76.87 ms  
         3  nr-fra1.6win.dfn.de  76.371 ms  80.709 ms  79.482 ms  
         4  dfn.de6.de.6net.org  92.763 ms  90.863 ms  94.322 ms  
         5  de.nl6.nl.6net.org  116.115 ms  93.463 ms  96.331 ms  
         6  nl.uk6.uk.6net.org  103.347 ms  99.334 ms  100.803 ms  
         7  uk1.uk61.uk.6net.org  99.481 ms  100.421 ms  100.119 ms  
         8  2001:798:28:300::2  89.711 ms  90.435 ms  90.035 ms  
         9  ge-1-0-0-2.r20.londen03.uk.bb.verio.net  179.671 ms  185.141 ms  185.86 ms  
         10  p16-0-0-0.r81.nycmny01.us.bb.verio.net  177.067 ms  179.086 ms  178.05 ms  
         11  p16-1-1-3.r20.nycmny01.us.bb.verio.net  178.04 ms  179.727 ms  184.165 ms  
         12  p16-0-1-1.r20.mlpsca01.us.bb.verio.net  249.856 ms  247.476 ms  249.012 ms  
         13  p64-0-0-0.r21.snjsca04.us.bb.verio.net  239.691 ms  241.404 ms  240.998 ms  
         14  p64-0-0-0.r21.plalca01.us.bb.verio.net  247.541 ms  246.661 ms  246.359 ms  
         15  xe-0-2-0.r20.plalca01.us.bb.verio.net  240.987 ms 239.056 ms  241.251 ms  
         16  ge-6-1.a01.snfcca05.us.ra.verio.net  240.868 ms  241.29 ms  242.337 ms  
         17  fa-5-2.a01.snfcca05.us.ce.verio.net  249.477 ms  250.4 ms  256.035 ms  
         18  2001:4f8:4:7:2e0:81ff:fe52:9a6b  268.164 ms  252.97 ms  252.366 ms   
   
         Please note that `traceroute6` shows the v6 hops only, any underlying   
         tunnels are invisible and thus not displayed.  
   
  6. If this works, 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/hf6to4 stop  
         /usr/pkg/sbin/hf6to4 start  
   
  7. If you want to route IPv6 for your LAN, you can instruct `6to4.pl` to setup   
     Router Advertising for you too:  
   
         # /usr/pkg/sbin/hf6to4 rtadvd-start  
   
     You can put that command into `/etc/ppp/ip-up` as well to make it permanent.  
   
  8. 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/hf6to4 rtadvd-stop  
         /usr/pkg/sbin/hf6to4 stop  
   
 ### 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/](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/](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](http://www.feyrer.de/IPv6/netstart.local).  
   
 ### 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   
 [[!template id=man name="ipf.conf" section="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.  
   
 ### 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.  
   
  * 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 GNU/Linux can be found at   
    [http://people.debian.org/\~csmall/ipv6/setup.html](http://people.debian.org/~csmall/ipv6/setup.html).  
   
  * The BSD Unix implementations have their own IPv6 documentation each,   
    interesting URLs are <http://www.NetBSD.org/docs/network/ipv6/> for NetBSD,   
    <http://www.freebsd.org/doc/en\_US.ISO8859-1/books/handbook/network-ipv6.html  
    for FreeBSD.  
   
  * 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!  
   

Removed from v.1.5  
changed lines
  Added in v.1.8


CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb