Chapter 28. Miscellaneous networking topics

Table of Contents

28.1. Bridge
28.1.1. Bridge example
28.2. Network File System (NFS)
28.2.1. NFS setup example
28.3. Setting up NFS automounting for /net with amd(8)
28.3.1. Introduction
28.3.2. Actual setup
28.4. IPv6 Connectivity & Transition via 6to4
28.4.1. Getting 6to4 IPv6 up & running
28.4.2. Obtaining IPv6 Address Space for 6to4
28.4.3. How to get connected
28.4.4. Security Considerations
28.4.5. Data Needed for 6to4 Setup
28.4.6. Kernel Preparation
28.4.7. 6to4 Setup
28.4.8. Quickstart using pkgsrc/net/hf6to4
28.4.9. Known 6to4 Relay Routers
28.4.10. Tunneling 6to4 through an IPFilter firewall
28.4.11. Conclusion & Further Reading

28.1. Bridge

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.

28.1.1. Bridge example

In this example two physical networks are going to be combined in one logical network,, 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:

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

28.2. Network File System (NFS)

Now that the network is working it is possible to share files and directories over the network using the Network File System (NFS). From the point of view of file sharing, the computer which gives access to its files and directories is called the server, and the computer using these files and directories is the client. A computer can be client and server at the same time.

  • A kernel must be compiled with the appropriate options for the client and the server (the options are easy to find in the kernel configuration file. See Section 23.1, “A walk through the kernel configuration” for more information on NFS related kernel options.

  • The server must enable the rpcbind, mountd lockd statd and nfs_server daemons in /etc/rc.conf:

  • The client must enable the rpcbind, lockd statd and nfs_client daemons in /etc/rc.conf:

  • The server must list the exported directories in /etc/exports and then run the command kill -HUP `cat /var/run/ (hup mountd may work too!).

A client host can access a remote directory through NFS if:

  • The server host exports the directory to the client. The list of filesystems a NFS server exports can be checked with the showmount -e command, see showmount(8):

    # showmount -e
    Exports list on
    /home                              host1 host2 host3
  • The client host mounts the remote directory with the command mount /home

The mount command has a rich set of options for remote directories which are not very intuitive (to say the least).

28.2.1. NFS setup example

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

The directories exported from the server are:


the five root directories for the five client machines. Each client has its own root directory.


Five swap directories for the five swap machines.


/usr directory; common for all client hosts.


Common /usr/src directory for all client machines.

The following file systems exist on the server

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

Each client needs the following file systems

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

The server configuration is the following:

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

On the client machines /etc/fstab contains:

buzz:/export/cliX/root  /        nfs rw
buzz:/export/common/usr /usr     nfs ro,nodev,nosuid
buzz:/usr/src           /usr/src nfs rw,nodev,nosuid

Each client machine has its number substituted to the “X” character in the first line of the previous example.

28.3. Setting up NFS automounting for /net with amd(8)

28.3.1. Introduction

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

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

$ showmount -e
Exports list on
/archive                           Everyone

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

$ cd /net/

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

28.3.2. Actual setup

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

  1. in /etc/rc.conf, set the following variable:

  2. mkdir /amd

  3. mkdir /net

  4. Taking /usr/share/examples/amd/amd.conf, put the following into /etc/amd.conf:

    [ /net ]
    map_name =              /etc/amd/net
    map_type =              file
  5. Taking /usr/share/examples/amd/net as example, put the following into /etc/amd/net:

    /defaults       type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root
    *             host==${key};type:=link;fs:=/                           \
  6. Reboot, or (re)start amd by hand:

    # sh /etc/rc.d/amd restart

28.4. 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 28.1, “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 28.1. A frequently used method for transition is tunneling IPv6 in IPv4 packets

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.

28.4.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 22.7, “Next generation Internet protocol - IPv6”. It can be used with static as well as dynamically assigned IPv4 addresses, e.g. as found in modem dialup scenarios today. When using dynamic IPv4 addresses, a change of IP addresses will be a problem for incoming traffic, i.e. you can't run persistent servers.

Example configurations given in this section is for NetBSD 1.5.2.

28.4.2. Obtaining IPv6 Address Space for 6to4

The 6to4 IPv6 setup on your side doesn't consist of a single IPv6 address; Instead, you get a whole /48 network! The IPv6 addresses are derived from your (single) IPv4 address. The address prefix “2002:” is reserved for 6to4 based addresses (i.e. IPv6 addresses derived from IPv4 addresses). The next 32 bits are your IPv4 address. This results in a /48 network that you can use for your very own purpose. It leaves 16 bits space for 216 IPv6 subnets, which can take up to 264 nodes each. Figure 28.2, “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 28.2. 6to4 derives an IPv6 from an IPv4 address

6to4 derives an IPv6 from an IPv4 address

28.4.3. How to get connected

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

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

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

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

28.4.4. Security Considerations

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

  • unspecified IPv4 source/destination address:

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

  • IPv4 multicast in source/destination:

  • limited broadcasts:

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

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

28.4.5. Data Needed for 6to4 Setup

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

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

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

  • Your local IPv6 address, as derived from the IPv4 address. See Figure 28.2, “6to4 derives an IPv6 from an IPv4 address” on how to do that.

    For our example, this is 2002:3ee0:3972:0001::1 ( == 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.

28.4.6. Kernel Preparation

To process 6to4 packets, the operating system kernel needs to know about them. For that a driver has to be compiled in that knows about 6to4, and how to handle it. In NetBSD 4.0 and newer, the driver is already present in GENERIC kernel configurations, so the procedure below is usually unnecessary.

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

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

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

28.4.7. 6to4 Setup

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

  1. Configure interface

  2. Set default route

  3. Setup Router Advertisement, if wanted

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

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

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

# route add -inet6 default 2002:c058:6301::

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

After these commands, you are connected to the IPv6-enabled world - Congratulations! Assuming name resolution is still done via IPv4, you can now ping an IPv6-site like or

# /sbin/ping6

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 28.4. Enabling packet forwarding is needed for a 6to4 router

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

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

  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 stf(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 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
  4. Now dial up, then start the 6to4 command manually:

    # /usr/pkg/sbin/hf6to4 start
  5. After that, you should be connected, use ping6(8): to see if everything works:

    # ping6
    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
    --- 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
    traceroute6 to (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  76.134 ms *  76.87 ms
     3  76.371 ms  80.709 ms  79.482 ms
     4  92.763 ms  90.863 ms  94.322 ms
     5  116.115 ms  93.463 ms  96.331 ms
     6  103.347 ms  99.334 ms  100.803 ms
     7  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  179.671 ms  185.141 ms  185.86 ms
    10  177.067 ms  179.086 ms  178.05 ms
    11  178.04 ms  179.727 ms  184.165 ms
    12  249.856 ms  247.476 ms  249.012 ms
    13  239.691 ms  241.404 ms  240.998 ms
    14  247.541 ms  246.661 ms  246.359 ms
    15  240.987 ms 239.056 ms  241.251 ms
    16  240.868 ms  241.29 ms  242.337 ms
    17  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 -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 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 -t ip-down Shutting down 6to4 IPv6
    /usr/pkg/sbin/hf6to4 rtadvd-stop
    /usr/pkg/sbin/hf6to4 stop

28.4.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 In tests, only and were found working. Cisco has one that requires registration, see

There's also an experimental 6to4 server located in Germany, 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

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

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