Chapter 9. Networking

Table of Contents
9.1. Introduction to TCP/IP Networking
9.2. Practice
9.3. Advanced Topics

9.1. Introduction to TCP/IP Networking

This chapter (Introduction to TCP/IP Networking) has been contributed by Hubert Feyrer .

9.1.1. Audience

This networking section of this guide explains various aspects of networking and is intended to help people with little knowledge about networks to get started. It is devided into three sections. We start by giving a general overview of how networking works and introduce the basic concepts. Then we go into details for setting up various types of networking in the second section, and the third section covers any "advanced" topics that go beyond the scope of basic operation as introduced in the first two sections.

The reader is assumed to know about basic system administration tasks: how to become root, edit files, change permissions, stop processes, etc. See [AeleenFrisch] for further information on this topic. Besides that, you should know how to handle the utilities we're going to set up here, i. e. you should know how to use telnet, FTP, ... I will not explain the basic features of those utilities, please refer to the appropriate man-pages, the references listed or of course the other parts of this document instead.

This Introduction to TCP/IP Networking was written with the intention in mind to give starters a basic knowledge. If you really want to know what's it all about, read [CraigHunt]. This book does not only cover the basics, but goes on and explains all the concepts, services and how to set them up in detail. It's great, I love it! :-)

9.1.2. Supported Networking Protocols

There are several protocol suites supported by NetBSD, most of which were inherited from NetBSD's predecessor, 4.4BSD, and subsequently enhanced and improved. The first and most important one today is DARPA's Transmission Control Protocoll/Internet Protocoll (TCP/IP). Other protocol suites available in NetBSD include the Xerox Network System (XNS) which was only implemented at UCB to connect isolated machines to the net, Apple's AppleTalk protocol suite and the ISO protocol suite, CCITT X.25 and ARGO TP. They are only used in some special applications these days.

Today, TCP/IP is the most widespread protocol of the ones mentioned above. It is implemented on almost every hardware and operating system, and it is also the most-used protocol in heterogenous environments. So, if you just want to connect your computer running NetBSD to some other machine at home, or you want to integrate it into your company's or university's network, TCP/IP is the right choice.

IPv6 (TCP/IP protocol issue 6, current version IPv4) is still under development, and the KAME project's IPv6 code was merged into NetBSD and shipped starting with the NetBSD 1.5 release.

There are other protocol suites such as DECNET, Novell's IPX/SPX or Microsoft's NetBIOS, but these are not currently supported by NetBSD. These two protocols differ from the protocols mentioned above in that they are proprietary, in contrast to the others, which are well-defined in several RFCs and other open standards.

9.1.3. Supported Media

TCP/IP can be used on a wide range of media. Among the ones supported by NetBSD are Ethernet (10/100/1000MBd), Arcnet, serial line, ATM, FDDI, Fiber Channel, USB, HIPPI, FireWire (IEEE 1394), Token Ring, serial lines and others. Serial Line

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

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

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

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

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

  • Serial Line IP (SLIP)

  • Point to Point Protocol (PPP)

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

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

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

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

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

9.1.4. TCP/IP Address Format

TCP/IP uses 4-byte (32-bit) addresses in the current implementations (IPv4), also called IP-numbers (Internet-Protocol numbers), to address hosts.

TCP/IP allows any two machines to communicate directly. To permit this all hosts on a given network must have a unique IP address. To assure this, IP addresses are administrated by one central organisation, the InterNIC. They give certain ranges of addresses (network-addresses) directly to sites which want to participate in the internet or to internet-providers, which give the addresses to their customers.

If your university or company is connected to the Internet, it has (at least) one such network-address for it's own use, usually not assigned by the InterNIC directly, but rather through an Internet Service Provider (ISP).

If you just want to run your private network at home, see below on how to "build" your own IP addresses. However, if you want to connect your machine to the (real :-) Internet, you should get an IP addresses from your local network-administrator or -provider.

IP addresses are usually written in "dotted quad"-notation - the four bytes are written down in decimal (most significant byte first), separated by dots. For example, would be a valid address. Another way to write down IP-addresses would be as one 32-bit hex-word, e.g. 0x84c70f63. This is not as convenient as the dotted-quad, but quite useful at times, too. (See below!)

Being assigned a network means nothing else but setting some of the above-mentioned 32 address-bits to certain values. These bits that are used for identifying the network are called network-bits. The remaining bits can be used to address hosts on that network, therefore they are called host-bits.

In the above example, the network-address is (host-bits are set to 0 in network-addresses), the host's address is 15.99 on that network.

How do you know that the host's address is 16 bit wide? Well, this is assigned by the provider from which you get your network-addresses. In the classless inter-domain routing (CIDR) used today, host fields are usually between as little as 2 to 16 bits wide, and the number of network-bits is written after the network address, seperated by a "/", e.g. tells that the network in question has 16 network-bits. When talking about the "size" of a network, it's usual to only talk about it as "/16", "/24", etc.

Before CIDR was used, there used to be four classes of networks. Each one starts with a certain bit-pattern identifying it. Here are the four classes:

  • Class A starts with "0" as most significant bit. The next seven bits of a class A address identify the network, the remaining 24 bit can be used to address hosts. So, within one class A network there can be 224 hosts. It's not very likely that you (or your university, or company, or whatever) will get a whole class A address.

    The CIDR notation for a class A network with it's eight network bits is an "/8".

  • Class B starts with "10" as most significant bits. The next 14 bits are used for the networks address, the remaining 16 bits can be used to address more than 65000 hosts. Class B addresses are very rarely given out today, they used to be common for companies and universities before IPv4 address space went scarce.

    The CIDR notation for an class B network with it's 16 network bits is an "/16".

    Returning to our above example, you can see that (or 0x84c70f63, which is more appropriate here!) is on a class B network, as 0x84... = 1000... (base 2).

    Therefore, the address can be split into an network-address of and an host-address of 15.99.

  • Class C is identified by the MSBs being "110", allowing only 256 (actually: only 254, see below) hosts on each of the 221 possible class C networks. Class C addresses are usually found at (small) companies.

    The CIDR notation for an class C network with it's 24 network bits is an "/24".

  • There are also other addresses, starting with "111". Those are used for special purposes (e. g. multicast-addresses) and are not of interrest here.

Please note that the bits which are used for identifying the network-class are part of the network-address.

When seperating host-addresses from network-addresses, the "netmask" comes in handy. In this mask, all the network-bits are set to "1", the host-bits are "0". Thus, putting together IP-address and netmask with a locical AND-function, the network-address remains.

To continue our example, is a possible netmask for When applying this mask, the network-address remains.

For addresses in CIDR notation, the number of network-bits given also says how many of the most significant bits of the address must be set to "1" to get the netmask for the corresponding network. For classfull addressing, every network-class has a fixed default netmask assigned:

  • Class A (/8): default-netmask:, first byte of address: 1-127

  • Class B (/16): default-netmask:, first byte of address: 128-191

  • Class C (/24): default-netmask:, first byte of address: 192-223

Another thing to mention here is the "broadcast-address". When sending to this address, all hosts on the corresponding network will receive the message sent. The broadcast address is characterized by having all host-bits set to "1".

Taking with its netmask again, the broadcast-address would result in

You'll ask now: But what if I want a hosts address to be all bits "0" or "1"? Well, this doesn't work, as network- and broadcast-address must be present! Because of this, a class B (/16) network can contain at most 216-2 hosts, a class C (/24) network can hold no more than 28-2 = 254 hosts.

Besides all those categories of addresses, there's the special IP-address which always refers to the "local" host, i. e. if you talk to you'll talk to yourself without starting any network-activity. This is sometimes useful to use services installed on your own machine or to play around if you don't have other hosts to put on your network.

Let's put together the things we've introduced in this section:

  • IP-address: 32 bit-address, with network- and host-bits.

  • Network-address: IP-address with all host bits set to "0".

  • Netmask: 32-bit mask with "1" for network- and "0" for host-bits.

  • Broadcast: IP-address with all host bits set "1".

  • The local host's IP address is always

9.1.5. Subnetting and Routing

After talking so much about netmasks, network-, host- and other addresses, I have to admit that this is not the whole truth.

Imagine the situation at your university, which usually has a class B (/16) address, allowing it to have up to 216 ~= 65534 hosts on that net. Maybe it would be a nice thing to have all those hosts on one single network, but it's simply not possible due to limitations in the transport media commonly used today.

For example, when using thinwire ethernet, the maximum length of the cable is 185 meters. Even with repeaters in between, which refresh the signals, this is not enough to cover all the locations where machines are located. Besides that, there is a maximum number of 1024 hosts on one ethernet wire, and you'll loose quite a bit of performance if you go to this limit.

So, are you hosed now? Having an address which allows more than 60000 hosts, but being bound to media which allows far less than that limit?

Well, of course not! :-)

The idea is to divide the "big" class B net into several smaller networks, commonly called sub-networks or simply subnets. Those subnets are only allowed to have, say, 254 hosts on them (i.e. you divide one big class B network into several class C networks!).

To do this, you adjust your netmask to have more network- and less host-bits on it. This is usually done on a byte-boundary, but you're not forced to do it there. So, commonly your netmask will not be as supposed by a class B network, but it will be set to

In CIDR notation, you now write a "/24" instead of the "/16" to show that 24 bits of the address are used for identifying the network and subnet, instead of the 16 that were used before.

This gives you one additional network-byte to assign to each (physical!) network. All the 254 hosts on that subnet can now talk directly to each other, and you can build 256 such class C nets. This should fit your needs.

To explain this better, let's continue our above example. Say our host (I'll call him dusk from now; we'll talk about assigning hostnames later) has a netmask of and thus is on the subnet Let's furthermore introduce some more hosts so we have something to play around with, see Figure 9-1.

Figure 9-1. Our demo-network

In the above network, dusk can talk directly to dawn, as they are both on the same subnet. (There are other hosts attached to the but they are not of importance for us now)

But what, if dusk wants to talk to a host on another subnet?

Well, the traffic will then go through one or more gateways (routers), which are attached to two subnets. Because of this, a router always has two different addresses, one for each of the subnets it is on. The router is functionally transparent, i. e. you don't have to address it to reach hosts on the "other" side. Instead, you address that host directly and the packets will be routed to it correctly.

Example. Let's say dusk wants to get some files from the local ftp-server. As dusk can't reach ftp directly (because it's on a different subnet), all its packets will be forwarded to it's "defaultrouter" rzi (, which knows where to forward the packets to.

Dusk knows the address of it's defaultrouter in its network (rzi,, and it will forward any packets to it which are not on the same subnet, i.e. it will forward all IP-packets in which the third address-byte isn't 15.

The (default)router then gives the packets to the appropriate host, as it's also on the FTP-server's network.

In this example, all packets are forwarded to the, simply because it's the network's backbone, the most important part of the network, which carries all the traffic that passes between several subnets. Almost all other networks besides are attached to the backbone in a similar manner.

But what, if we had hooked up another subnet to instead of Maybe something the situation displayed in Figure 9-2.

Figure 9-2. Attaching one subnet to another one

When we now want to reach a host which is located in the from dusk, it won't work routing it to rzi, but you'll have to send it directly to route2 ( Dusk will have to know to forward those packets to route2 and send all the others to rzi.

When configuring dusk, you tell it to forward all packets for the to route2, and all others to rzi. Instead of specifying this default as,, etc., can be used to set the default-route.

Returning to Figure 9-1, there's a similar problem when dawn wants to send to noon, which is connected to dusk via a serial line running. When looking at the IP-addresses, noon seems to be attached to the, but it isn't really. Instead, dusk is used as gateway, and dawn will have to send its packets to dusk, which will forward them to noon then. The way dusk is forced into accepting packets that aren't destined at it but for a different host (noon) instead is called "proxy arp".

The same goes when hosts from other subnets want to send to noon. They have to send their packets to dusk (possibly routed via rzi),

9.1.6. Name Service Concepts

In the previous sections, when we talked about hosts, we referred to them by their IP-addresses. This was necessary to introduce the different kinds of addresses. When talking about hosts in general, it's more convenient to give them "names", as we did when talking about routing.

Most applications don't care whether you give them an IP address or an hostname. However, they'll use IP addresses internally, and there are several methods for them to map hostnames to IP addresses, each one with its own way of configuration. In this section we'll introduce the idea behind each method, in the next chapter, we'll talk about the configuration-part.

The mapping from hostnames (and domainnames) to IP-addresses is done by a piece of software called the "resolver". This is not an extra service, but some library routines which are linked to every application using networking-calls. The resolver will then try to resolve (hence the name ;-) the hostnames you give into IP addresses. See [RFC1034] and [RFC1035] for details on the resolver.

Hostnames are usually up to 10 characters long, and contain letters, numbers, dashes ("-") and underscores ("_"); case is ignorred.

Just as with networks and subnets, it's possible (and desirable) to group hosts into domains and subdomains. When getting your network-address, you usually also obtain a domainname by your provider. As with subnets, it's up to you to introduce subdomains. Other as with IP-addresses, (sub)domains are not directly related to (sub)nets; for example, one domain can contain hosts from several subnets.

Figure 9-1 shows this: Both subnets and (and others) are part of the subdomain "". The domain the University of Regensburg got from it's IP-provider is "" (".de" is for Deutschland, Germany), the subdomain "rz" is for Rechenzentrum, computing center.

Hostnames, subdomain- and domainnames are separated by dots ("."). It's also possible to use more than one stage of subdomains, although this is not very common. An example would be

A hostname which includes the (sub)domain is also called a fully qualified domain name (FQDN). For example, the IP-address belongs to the host with the FQDN

Further above I told you that the IP-address always belongs to the local host, regardless what's the "real" IP-address of the host. Therefore, is always mapped to the name "localhost".

The three different ways to translate hostnames into IP addresses are: /etc/hosts, the Domain Name Service (DNS) and the Network Information Service (NIS). /etc/hosts

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

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

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

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

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

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

Important: There must be an entry mapping localhost to! Domain Name Service (DNS)

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

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

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

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

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

See Chapter 10 for details on DNS. Network Information Service (NIS/YP)

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

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

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

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

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

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

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

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

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

9.1.7. Next generation Internet protocol - IPv6 The Future of the Internet

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

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

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

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

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

  • Bigger address space

  • Support for mobile devices

  • Built-in security Bigger Address Space

The bigger address space that IPv6 offers is the most obvious enhancement it has over IPv4. While today's internet architecture is based on 32-bit wide addresses, the new version has 128 bit available for addressing. Thanks to the enlarged address space, work-arounds like NAT don't have to be used any more. This allows full, unconstrained IP connectivity for today's IP based machines as well as upcoming mobile devices like PDAs and cell phones will benefit from full IP access through GPRS and UMTS. Mobility

When mentioning mobile devices and IP, another important point to note is that some special protocol is needed to support mobility, and implementing this protocol - called "Mobile IP" - is one of the requirements for every IPv6 stack. Thus, if you have IPv6 going, you have support for roaming between different networks, with everyone being updated when you leave one network and enter the other one. Support for roaming is possible with IPv4 too, but there are a number of hoops that need to be jumped in order to get things working. With IPv6, there's no need for this, as support for mobility was one of the design requirements for IPv6. See [RFC3024] for some more information on the issues that need to be addressed with Mobile IP on IPv4. Security

Besides support for mobility, security was another requirement for the successor to today's Internet Protocol version. As a result, IPv6 protocol stacks are required to include IPsec. IPsec allows authentication, encryption and compression of any IP traffic. Unlike application level protocols like SSL or SSH, all IP traffic between two nodes can be handled, without adjusting any applications. The benefit of this is that all applications on a machine can benefit from encryption and authentication, and that policies can be set on a per-host (or even per-network) base, not per application/service. An introduction to IPsec with a roadmap to the documentation can be found in [RFC2411], the core protocol is described in [RFC2401]. Changes to IPv4

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

An IPv4 address is a 32 bit value, that's usually written in "dotted quad" representation, where each "quad" represents a byte value between 0 and 255, for example: 

This allows a theoretical number of 232 or ~4 billion hosts to be connected on the internet today. Due to grouping, not all addresses are available today.

IPv6 addresses use 128 bit, which results in 2128 theoretically addressable hosts. This allows for a Really Big number of machines to addressed, and it sure fits all of today's requirements plus all those nifty PDAs and cell phones with IP phones in the near future without any sweat. When writing IPv6 addresses, they are usually divided into groups of 16 bits written as four hex digits, and the groups are separated by colons. An example is:


This shows a special thing - a number of consecutive zeros can be abbreviated by a single "::" once in the IPv6 address. The above address is thus equivalent to fe80:0:00:000:2a0:d2ff:fea5:e9f5 - leading zeros within groups can be omitted.

To make addresses manageable, they are split in two parts, which are the bits identifying the network a machine is on, and the bits that identify a machine on a (sub)network. The bits are known as netbits and hostbits, and in both IPv4 and IPv6, the netbits are the "left", most significant bits of an IP address, and the host bits are the "right", least significant bits, as shown in Figure 9-3.

Figure 9-3. Adresses are divided into more significant network- and less significant hostbits

In IPv4, the border is drawn with the aid of the netmask, which can be used to mask all net/host bits. Typical examples are that uses 16 bit for addressing the network, and 16 bit for the machine, or which takes another 8 bit to allow addressing 256 subnets on e.g. a class B net.

When addressing switched from classful addressing to CIDR routing, the borders between net and host bits stopped being on 8 bit boundaries, and as a result the netmasks started looking ugly and not really manageable. As a replacement, the number of network bits is used for a given address, to denote the border, e.g. 

is the same as a netmask of (24 1-bits). The same scheme is used in IPv6:


tells us that the address used here has the first (leftmost) 64 bits used as the network address, and the last (rightmost) 64 bits are used to identify the machine on the network. The network bits are commonly referred to as (network) "prefix", and the "prefixlen" here would be 64 bits.

Common addressing schemes found in IPv4 are the (old) class B and class C nets. With a class C network (/24), you get 24 bits assigned by your provider, and it leaves 8 bits to be assigned by you. If you want to add any subnetting to that, you end up with "uneven" netmasks that are a bit nifty to deal with. Easier for such cases are class B networks (/16), which only have 16 bits assigned by the provider, and that allow subnetting, i.e. splitting of the rightmost bits into two parts. One to address the on-site subnet, and one to address the hosts on that subnet. Usually, this is done on byte (8 bit) boundaries. Using a netmask of (or a /24 prefix) allows flexible management even of bigger networks here. Of course there is the upper limit of 254 machines per subnet, and 256 subnets.

With 128 bits available for addressing in IPv6, the scheme commonly used is the same, only the fields are wider. Providers usually assign /48 networks, which leaves 16 bits for a subnetting and 64 hostbits.

Figure 9-4. IPv6-addresses have a similar structure to class B addresses

Now while the space for network and subnets here is pretty much ok, using 64 bits for addressing hosts seems like a waste. It's unlikely that you will want to have several billion hosts on a single subnet, so what is the idea behind this?

The idea behind fixed width 64 bit wide host identifiers is that they aren't assigned manually as it's usually done for IPv4 nowadays. Instead, IPv6 host addresses are recommended (not mandatory!) to be built from so-called EUI64 addresses. EUI64 addresses are - as the name says - 64 bit wide, and derived from MAC addresses of the underlying network interface. E.g. for ethernet, the 6 byte (48 bit) MAC address is usually filled with the hex bits "fffe" in the middle and a bit is set to mark the address as unique (which is true for Ethernet), e.g. the MAC address


results in the EUI64 address


which again gives the host bits for the IPv6 address as


These host bits can now be used to automatically assign IPv6 addresses to hosts, which supports autoconfiguration of IPv6 hosts - all that's needed to get a complete IPv6 address is the first (net/subnet) bits, and IPv6 also offers a solution to assign them automatically.

When on a network of machines speaking IP, there's usually one router which acts as the gateway to outside networks. In IPv6 land, this router will send "router advertisement" information, which clients are expected to either receive during operation or to solicit upon system startup. The router advertisement information includes data on the router's address, and which address prefix it routes. With this information and the host-generated EUI64 address, a IPv6-host can calculate it's IP address, and there is no need for manual address assignment. Of course routers still need some configuration.

The router advertisement information they create are part of the Neighbor Discovery Protocol (NDP, see [RFC2461]), which is the successor to IPv4's ARP protocol. In contrast to ARP, NDP does not only do lookup of IPv6 addresses for MAC addresses (the neighbor solicitation/advertisement part), but also does a similar service for routers and the prefixes they serve, which is used for autoconfiguration of IPv6 hosts as described in the previous paragraph. Multiple Addresses

In IPv4, a host usually has one IP address per network interface or even per machine if the IP stack supports it. Only very rare applications like web servers result in machines having more than one IP address. In IPv6, this is different. For each interface, there is not only a globally unique IP address, but there are two other addresses that are of interest: The link local address, and the site local address. The link local address has a prefix of fe80::/64, and the host bits are built from the interface's EUI64 address. The link local address is used for contacting hosts and routers on the same network only, the addresses are not visible or reachable from different subnets. If wanted, there's the choice of either using global addresses (as assigned by a provider), or using site local addresses. Site local addresses are assigned the network address fec0::/10, and subnets and hosts can be addressed just as for provider-assigned networks. The only difference is, that the addresses will not be visible to outside machines, as these are on a different network, and their "site local" addresses are in a different physical net (if assigned at all). As with the 10/8 network in IPv4, site local addresses can be used, but don't have to. For IPv6 it's most common to have hosts assigned a link-local and a global IP address. Site local addresses are rather uncommon today, and are no substitute for globally unique adresses if global connectivity is required. Multicasting

In IP land, there are three ways to talk to a host: unicast, broadcast and multicast. The most common one is by talking to it directly, using it's unicast address. In IPv4, the unicast address is the "normal" IP address assigned to a single host, with all address bits assigned. The broadcast address used to address all hosts in the same IP subnet has the network bits set to the network address, and all host bits set to "1" (which can be easily done using the netmask and some bit operations). Multicast addresses are used to reach a number of hosts in the same multicast group, which can be machines spread over the whole internet. Machines must join multicast groups explicitly to participate, and there are special IPv4 addresses used for multicast addresses, allocated from the 224/8 subnet. Multicast isn't used very much in IPv4, and only few applications like the MBone audio and video broadcast utilities use it.

In IPv6, unicast addresses are used the same as in IPv4, no surprise there - all the network and host bits are assigned to identify the target network and machine. Broadcasts are no longer available in IPv6 in the way they were in IPv4, this is where multicasting comes into play. Addresses in the ff::/8 network are reserved for multicast applications, and there are two special multicast addresses that supersede the broadcast addresses from IPv4. One is the "all routers" multicast address, the others is for "all hosts". The addresses are specific to the subnet, i.e. a router connected to two different subnets can address all hosts/routers on any of the subnets it's connected to. Addresses here are:

  • ff0X::1 for all hosts and

  • ff0X::2 for all routers,

where "X" is the scope ID of the link here, identifying the network. Usually this starts from "1" for the "node local" scope, "2" for the first link, etc. Note that it's perfectly ok for two network interfaces to be attached to one link, thus resulting in double bandwidth:

Figure 9-5. Several interfaces attached to a link result in only one scope ID for the link

One use of the "all hosts" multicast is in the neighbor solicitation code of NDP, where any machine that wants to communicate with another machine sends out a request to the "all hosts" group, and the machine in question is expected to respond. Name Resolving in IPv6

After talking a lot about addressing in IPv6, anyone still here will hope that there's a proper way to abstract all these long & ugly IPv6 addresses with some nice hostnames as one can do in IPv4, and of course there is.

Hostname to IP address resolving in IPv4 is usually done in one of three ways: using a simple table in /etc/hosts, by using the Network Information Service (NIS, formerly YP) or via the Domain Name System (DNS).

As of this writing, NIS/NIS+ over IPv6 is currently only available on Solaris 8, for both database contents and transport, using a RPCextension.

Having a simple address<->name map like /etc/hosts is supported in all IPv6 stacks. With the KAME implementation used in NetBSD, /etc/hosts contains IPv6 addresses as well as IPv4 addresses. A simple example is the "localhost" entry in the default NetBSD installation:               localhost
::1                     localhost

For DNS, there are no fundamentally new concepts. IPv6 name resolving is done with AAAA records that - as the name implies - point to an entity that's four times the size of an A record. The AAAA record takes a hostname on the left side, just as A does, and on the right side there's an IPv6 address, e.g.

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

For reverse resolving, IPv4 uses the zone, and below that it writes the bytes (in decimal) in reversed order, i.e. more significant bytes are more right. For IPv6 this is similar, only that hex digits representing 4 bits are used instead of decimal numbers, and the resource records are also under a different domain,

So to have the reverse resolving for the above host, you would put into your /etc/named.conf something like:

zone "" {
        type master;
        file "db.reverse";

and in the zone file db.reverse you put (besides the usual records like SOA and NS): IN   PTR

The address is reversed here, and written down one hex digit after the other, starting with the least significant (rightmost) one, separating the hex digits with dots, as usual in zone files.

One thing to note when setting up DNS for IPv6 is to take care of the DNS software version in use. BIND 8.x does understand AAAA records, but it does not offer name resolving via IPv6. You need BIND 9.x for that. Beyond that, BIND 9.x supports a number of resource records that are currently being discussed but not officially introduced yet. The most noticeable one here is the A6 record which allows easier provider/prefix changing.

To sum up, this section talked about the technical differences between IPv4 and IPv6 for addressing and name resolving. Some details like IP header options, QoS and flows were deliberately left out to not make the this document more complex than necessary.

9.2. Practice

9.2.1. A walk throught the kernel configuration

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

#       $NetBSD: GENERIC,v 1.354.2.15 2001/05/06 15:18:54 he Exp $

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

options         NTP             # NTP phase/frequency locked loop

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

file-system     NFS             # Network File System client

If you want to use another machine's harddisk via the Network File System (NFS), this option is needed. Section 9.3.2 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 harddisk. Section 9.3.2 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. If doesn't only switch on packet forwarding, but also increases some buffers. See options(4) for details.

options         INET            # IP + ICMP + TCP + UDP

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

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 inet6(4) manpage and Section 9.1.7 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 ipsec(4) for more information.

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

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

#options        MROUTING        # IP multicast routing

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

options         NS              # XNS
#options        NSIP            # XNS tunneling over IP

These options enables the Xerox Network Systems(tm) protocol family. It's not related to the TCP/IP protocol stack, and in rare use today. The ns(4) manpage has some details.

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

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

options         CCITT,LLC,HDLC  # X.25

These options enable the X.25 protocol set for transmission of data over serial lines. It is/was used mostly in conjunction with the OSI protocols and in WAN networking.

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 stackk are available in the atalk(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 ipf(4) and ipf(8) manpages for more information on operation of IPfilter, and Section 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.


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

# 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 it's 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 it's 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 sort of network drivers. Please pick the one that matches your hardware, according to the comments. For most drivers, there's also a manual page available, e.g. tlp(4), ne(4), etc.

# MII/PHY support

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

# USB Ethernet adapters
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 bpf(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 ipf(4) and Section 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. Should not be omited. See lo(4) for more details.

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

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

pseudo-device   sl              2       # Serial Line IP

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

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

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

pseudo-device   tun             2       # network tunneling over tty

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

pseudo-device   gre             2       # generic L3 over IP tunnel

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

pseudo-device   ipip            2       # IP Encapsulation within IP (RFC 2003)

Another IP-in-IP encapsulation device, with a different encapsulation format. See the ipip(4) manpage for details.

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

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

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

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

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

This add a network device that can be used to tunnel IPv6 over IPv4 without setting up a configured tunnel before. The source address of outgoing packets contains the IPv4 address, which allows routing replies back via IPv4. See the stf(4) manpage and Section 9.3.4 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 switchens (that also have to support VLAN, of course), this can be used to build virtual LANs where one set of machines doesn't see traffic from the other (broadcast and other). The vlan(4) manpage tells more about this.

9.2.2. Overview of the network configuration files

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


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.


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.


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


Contains the IP address of the gateway.


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.

9.2.3. Connecting to the Internet

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.) 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, expecially the addresses of the DNS. In this example the two DNS will be "" and "".

Example 9-1. resolv.conf

  #lookup file bind

Note: the last line (lookup file bind) indicates that the name servers will be used only for the names which are not present in the /etc/hosts file. The line is commented, because starting with NetBSD 1.4 it is not needed any more; this type of information is now defined in the /etc/nsswitch.conf file. The new Name Service Switch changes the access to the databases used by programs to find the base system information.

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

Example 9-2. nsswitch.conf

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

Note: only one line has been modified, the one beginning with the word "hosts:"; when resolving host names, the local hosts file will be searched before resorting to DNS. 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.) 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:

Example 9-3. Connection script

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

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

Note: if you are experiencing connection problems, add the following two lines to the connection script

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

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

Example 9-4. Chat file

  # /etc/ppp/peers/
  '' ATDT0299999999

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

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

  • login


Most providers use a PAP/CHAP authentication. PAP/CHAP authentication

The authentication information 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

Note: for security reasons the pap-secrets and chap-secrets files should be owned by root and have permissions "600". 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:

Example 9-5. Chat file with login

  # /etc/ppp/peers/
  '' ATDT0299999999
  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).

Example 9-6. /etc/ppp/options


Check the pppd(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 cu program can be used, as in the following example.

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

      type modem
      port modem
      device /dev/tty01
      speed 115200
    (substitute the correct device in place of /dev/tty01.)

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

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

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

Note: when you start cu, if 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. Using a script for connection and disconnection

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

ppp-up is used to connect to the provider:

Example 9-7. ppp-up

  if [ -f /var/spool/lock/LCK..$MODEM ]; then
    echo ppp is already running...
    pppd call $POP
    tail -f /var/log/messages

ppp-down is used to close the connection:

Example 9-8. ppp-down

  if [ -f /var/spool/lock/LCK..$MODEM ]; then
    echo -f killing pppd...
    kill -HUP `cat /var/spool/lock/LCK..$MODEM`
    echo done
    echo ppp is not active

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

The two scripts must be executable:

  # chmod u+x ppp-up ppp-down

9.2.4. Creating a small home network

Networking is one of the main strengths of Unix and NetBSD is no exception: networking is both powerful and easy to set up and inexpensive too, because there is no need to buy additional software to communicate or to build a server. Section 9.3.1 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 file for a list of supported devices.)

First, the network cards must be installed and connected to a hub, switch or directly (see Figure 9-6.)

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 media: Ethernet 10base2

The software configuration of the network card is very easy. The IP address "" (which is reserved for internal networks) is assigned to the card.

# ifconfig ne0 inet netmask 0xffffff00

Repeating the previous command now gives a different result:

# ifconfig ne0
          media: Ethernet 10base2
          inet netmask 0xffffff00 broadcast

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, 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 is the address of the active host:

  # ping
  PING ape ( 56 data bytes
  64 bytes from icmp_seq=0 ttl=255 time=1.286 ms
  64 bytes from icmp_seq=1 ttl=255 time=0.649 ms
  64 bytes from icmp_seq=2 ttl=255 time=0.681 ms
  64 bytes from icmp_seq=3 ttl=255 time=0.656 ms
  ----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, two things need to be done: first, create the file /etc/ifconfig.ne0 containing the following line:

  inet netmask 0xffffff00

Next, in the /etc/rc.conf file, set the following option


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

The /etc/hosts file is a database of IP addresses and textual aliases: it should contain the addresses of all the hosts belonging to the internal network. For example:

Example 9-9. /etc/hosts

#     $NetBSD: hosts,v 1.4 1997/01/09 05:33:14 mikel Exp $
# 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.
#             localhost
# RFC 1918 specifies that these networks are "internal".
# ape vespa

The /etc/nsswitch.conf should be modified as explained in Example 9-2.

Note: in this example the file /etc/ifconfig.ne0 was created 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.

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 /etc/hosts and /etc/nsswitch.conf files must be modified. This type of network management in very simplified and is suited only for small networks without sophisticated needs.

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

On the second machine write the following commands:

  # slattach /dev/tty00
  # ifconfig sl0 inet

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

  # ping

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

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

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

  • 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 PC's runs Linux, the commands are slightly different (on the Linux machine only.) If the Linux machine gets the address, the following commands are needed:

  # slattach -p slip -s 115200 /dev/ttyS0 &
  # ifconfig sl0 pointopoint up
  # route add 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'

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

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

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

Now everything is ready to activate the connection.

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

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

  • Activate the Remote Access connection on Windows NT. Connecting NetBSD and Windows 95

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

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

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

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

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

  • Activate the connection as described in Section

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.

9.3. Advanced Topics

This chapter (Introduction to TCP/IP Networking) has been contributed by Hubert Feyrer .

9.3.1. IPNAT

The mysterious acronym IPNAT hides the Internet Protocol Network Address Translation, which enables the routing of an internal network on a real network (Internet.) This means that with only one "real" IP, static or dynamic, belonging to a gateway running IPNAT, it is possible to create simultaneous connections to the Internet for all the hosts of the internal network.

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

The setup for the example described in this section is detailed in Figure 9-6: 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 gateway for hosts 2 and 3.

Figure 9-6. Network with gateway Configuring the gateway/firewall

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

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

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

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

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

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

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


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

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

map ppp0 -> 0/32 proxy port ftp ftp/tcp
map ppp0 -> 0/32 portmap tcp/udp 40000:60000
map ppp0 -> 0/32
 are the network addresses that should be mapped The first line of the configuration file is optional: it enables active FTP to work through the gateway. The second line is used to handle correctly tcp and udp packets; the portmapping is necessary because of the many to one relationship.) The third line is used to enable ICMP, ping, etc.

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

# /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.

# /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.

Write the following command:

  # route add default
 is the address of the gateway machine configured in the previous section.

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

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

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

The following commands can be useful for diagnosing problems:


netstat -r

Displays the routing tables (similar to route show).


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


Use on the gateway to monitor TCP/IP traffic.

9.3.2. NFS

Now that the network is working it is possible to share files and directories over the network using 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 9.2.1 for more information on NFS related kernel options.

  • The server must enable its RPC services in /etc/inetd.conf.

  • In /etc/rc.conf the server must enable the inetd and portmap daemons and the nfs_server option.

  • In /etc/rc.conf the client must enable inetd and nfs_client.

  • The server must list the exported directories in /etc/exports and then run the command kill -HUP `cat /var/run/

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

  • The server host exports the directory.

  • The client host mounts the remote directory with the command mount server:/xx/yy /mnt

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

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

The scenario is the following: five client machines (cli1, ..., cli5) share some directories on a server ( 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/cli?/root / nfs rw
  buzz:/export/common/usr /usr nfs rw,nodev,nosuid
  buzz:/usr/src /usr/src rw,nodev,nosuid

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

9.3.3. Setting up /net with amd Introduction

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

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

  % showmount -e
  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. 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/master, put the following into /etc/amd/master:

      /net            /etc/amd/net
  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

9.3.4. IPv6 Connectivity & Transition via 6to4

This section will concentrate on how to get network connectivity for IPv6 and - as that's still not easy to get native today - talk in 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 support for their machines, and even if they do, it's unlikely that they offer hardware accelerated IPv6 routing or switching. A rather cheap alternative to the router hardware commonly in use today is using a standard PC and configure it as a router, e.g. by using some Linux or BSD derived operating system like NetBSD, and use software like Zebra for handling the routing protocols. This solution is rather common today for sites that want IPv6 connectivity today. The drawbacks are that you need an ISP that supports IPv6, and that you need dedicated uplink only for IPv6.

If this is not an option for you, 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 9-7. Using existing IPv4 infrastructure, the encapsulated packets are sent to a IPv6-capable uplink that will then remove the encapsulation, and forward the IPv6 packets via native IPv6.

Figure 9-7. 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 it's 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. Getting 6to4 IPv6 up & running

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

Example configurations given in this section is for NetBSD 1.5.2. 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 9-8 illustrates the building of your IPv6 address (range) from your IPv4 address.

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

Figure 9-8. 6to4 derives a 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 will then forward you any IPv6 traffic (encapsulated in IPv4). Instead, as your IPv6 address is derived from your IPv4 address, any answers can be sent through your nearest 6to4 gateway to you. De-encapsulation of the packet is done via a 6to4-capable network interface, which then forwards the resulting IPv6 package according to your routing setup (in case you have more than one machine connected on your 6to4 assigned network).

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

Figure 9-9. 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:

  • 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. 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 9-8 on how to do that.

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

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

    We will use 2002:c25f:6cbf::1 (== == Kernel Preparation

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

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

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

Note that the stf(4) device is not enabled by default. Rebuild your kernel, then reboot your system to use the new kernel. Please consult Chapter 7 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 assigning an IPv6 address to the 6to4 interface. This is achieved with the ifconfig(8) command. Assuming the example configuration above, the command for NetBSD is:

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

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

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

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

After these commands, you are connected to the IPv6-enabled world - Congratulations! Assuming name resolution is still done via IPv4, you can now ping a IPv6-site like 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 a IPv6-address to your ethernet. In the following example we will assume subnet "2" of the IPv6-net is used for the local ethernet and the MAC address of the ethernet interface is 12:34:56:78:9a:bc, i.e. your local gateway's ethernet interface's IP address will be 2002:3ee0:3972:2:1234:56ff:fe78:9abc. Assign this address to your ethernet interface, e.g.

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

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

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

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

Figure 9-10. 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/6to4

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

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

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

      # cd /usr/pkgsrc/net/6to4
      # make install
  2. Make sure you have the stf(4) pseudo-device in your kernel, see above.

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

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

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

      $in_if="rtk0";            # Inside (ethernet) interface 
  4. Now dial up, then start the 6to4 command manually:

      # /usr/pkg/sbin/ start

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

      logger -p -t ip-up Configuring 6to4 IPv6
      /usr/pkg/sbin/ stop
      /usr/pkg/sbin/ start
  5. If you want to route IPv6 for your LAN, you can instruct to setup Router Advertising for you too:

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

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

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

      logger -p -t ip-down Shutting down 6to4 IPv6
      /usr/pkg/sbin/ rtadvd-stop   
      /usr/pkg/sbin/ stop Known 6to4 Gateway

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

There's also an experimental 6to4 server located in Germany, This server runs under NetBSD 1.5 and was setup using the configuration steps described above. The whole configuration of the machine can be seen at Conclusion & Further Reading

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

A few links should be mentioned here for interested parties:


[AeleenFrisch] Aeleen Frisch, 1991, O'Reilly & Associates, Essential System Administration.

[CraigHunt] Craig Hunt, 1993, O'Reilly & Associates, TCP/IP Network Administration.

[RFC1034] P. V. Mockapetris, 1987, RFC 1034: Domain names - concepts and facilities.

[RFC1035] P. V. Mockapetris, 1987, RFC 1035: Domain names - implementation and specification.

[RFC1055] J. L. Romkey, 1988, RFC 1055: Nonstandard for transmission of IP datagrams over serial lines: SLIP.

[RFC1331] W. Simpson, 1992, RFC 1331: The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links.

[RFC1332] G. McGregor, 1992, RFC 1332: The PPP Internet Protocol Control Protocol (IPCP).

[RFC1933] R. Gilligan and E. Nordmark, 1996, RFC 1933: Transition Mechanisms for IPv6 Hosts and Routers.

[RFC2004] C. Perkins, 1996, RFC 2003: IP Encapsulation within IP.

[RFC2401] S. Kent and R. Atkinson, 1998, RFC 2401: Security Architecture for the Internet Protocol.

[RFC2411] R. Thayer, N. Doraswamy, and R. Glenn, 1998, RFC 2411: IP Security Document Roadmap.

[RFC2461] T. Narten, E. Nordmark, and W. Simpson, 1998, RFC 2461: Neighbor Discovery for IP Version 6 (IPv6).

[RFC2529] B. Carpenter and C. Jung, 1999, RFC 2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels.

[RFC3024] G. Montenegro, 2001, RFC 3024: Reverse Tunneling for Mobile IP.

[RFC3027] M. Holdrege and P. Srisuresh, 2001, RFC 3027: Protocol Complications with the IP Network Address Translator.

[RFC3056] B. Carpenter and K. Moore, 2001, RFC 3056: Connection of IPv6 Domains via IPv4 Clouds.