9.1.1. 对象

在这本指导手册中，有关网路的这一章，解释了有关网路方面的各种 基本知识，是为了帮助初学者而设计的。它分成了三部份。 一开始，我们让你大概了解网路是如何运作的，并介绍基本的概念。 接著，我们会进一步地说明各种不同类型网路的设定。在第三部份中， 会涵盖各种在前两部份中，未提到的"进阶"课题。

我们假设读者已经知道一些基本的系统管理工作：如何成为 root， 编辑档案，更改权限，终止程序，等。在 [AeleenFrisch] 中可以得到这方面的资讯。此外， 你应该了解如何使用一些基本的工具，例如，你应该知道如何使用 telnet, FTP, ...。我将不会解释这些工具的基本用法，请参考相关的 man-pages，或是这本手册的其他章节。

这一章的目的是为了让初学者具备基本的 TCP/IP 网路的知识。 如果你想要一窥全貌，可以参阅 [CraigHunt]。 这本书不只包含了基础的部份，更解释了所有的概念，服务程式并详细 说明如何设定它们。它很棒，我喜欢这本书! :-)

9.1.2. 支援的网路协定

NetBSD 支援好几种协定，大部份是来自 NetBSD 的前身，4.4BSD， 并经过而后的增强和改进。 第一个，也是最重要的一个是 DARPA 的 Transmission Control Protocoll/Internet Protocoll (TCP/IP)。 其他在 NetBSD 中有效的协定包括 Xerox Network System (XNS)，只被在 UCB 中 用来连接单独的机器到网路上，Apple 的 AppleTalk 协定和 ISO 协定，CCITT X.25 和 ARGO TP。 在今日，它们只用在一些特别的应用上。

在今日，TCP/IP 是在上述的协定中，最被广泛应用的一个。它在大部 份的硬体和作业系统上被执行，也是在各种不同环境中，最常使用的 协定。所以，如果你只是要连接执行 NetBSD 的电脑到家里其他的机器， 或是你想要将它整合到你公司或学校的网路，TCP/IP 是正确的选择。

IPv6 (TCP/IP 协定的版本 6，目前的版本是 IPv4) 仍在发展当中， 而 KAME 专案的 IPv6 程式码已经被整合到 NetBSD 中，并且开始发行在 NetBSD 1.5 release 中。

有关其他的协定，像是 DECNET，Novell 的 IPX/SPX 或是 Microsoft 的 NetBIOS，目前还未被 NetBSD 所支援。这两种协定不同于上述 的是，它们是专有的，不像其他的协定是被完整地定义在数种 RFC 和其他开放的标准中。

9.1.3. 支援的媒体

TCP/IP 可以被广泛地应用在各种不同的媒体上。其中被 NetBSD 所 支援的有 Ethernet (10/100/1000MBd), Arcnet, serial line, ATM, FDDI, Fiber Channel, USB, HIPPI, FireWire (IEEE 1394), Token Ring 等。

9.1.4. TCP/IP 位址格式

TCP/IP 在目前实行的版本(IPv4)上使用 4-byte (32-bit) 位址， 也叫做 IP-numbers (Internet-Protocol numbers)，来为各个 主机定址。

TCP/IP 允许任意两台机器进行直接地沟通。为了执行这项功能， 在既定网路上的所有主机都必须有一个独特的 IP 位址。为了确保其 独特性，IP 位址都由一个主要的组织 InterNIC 来集中管理。他们 将一定范围的位址(网路位址)，直接给那些想要参与网际网路的站台， 或是网际网路的提供者，进而将这些位址分别交给他们的顾客。

如果你的学校或公司有连接到网际网路，则它已经(至少)有一个网路位址 供它自己使用，通常不是直接由 InterNIC 分配的，大多是经由网际网路 服务提供者(ISP)所取得的。

如果你只是想要在家里执行你私有的网路，请看底下有关如何"建立" 自有 IP 位址的那一段落。但是，如果你要直接将你的机器连上 (真实的 :-)网际网路，你需要从区域网路管理者或提供者那里取得 你的 IP 位址。

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, 132.199.15.99 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 132.199.0.0 (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. 132.199.0.0/16 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 2²⁴ 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 132.199.15.99 (or 0x84c70f63, which is more appropriate here!) is on a class B network, as 0x84... = 1000... (base 2).

  Therefore, the address 132.199.15.99 can be split into an network-address of 132.199.0.0 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 2²¹ 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, 255.255.0.0 is a possible netmask for 132.199.15.99. When applying this mask, the network-address 132.199.0.0 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: 255.0.0.0, first byte of address: 1-127

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

• Class C (/24): default-netmask: 255.255.255.0, 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 132.199.15.99 with its netmask 255.255.0.0 again, the broadcast-address would result in 132.199.255.255.

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 2¹⁶-2 hosts, a class C (/24) network can hold no more than 2⁸-2 = 254 hosts.

Besides all those categories of addresses, there's the special IP-address 127.0.0.1 which always refers to the "local" host, i. e. if you talk to 127.0.0.1 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 127.0.0.1.

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 2¹⁶ ~= 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 255.255.0.0 as supposed by a class B network, but it will be set to 255.255.255.0.

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 132.199.15.99 (I'll call him dusk from now; we'll talk about assigning hostnames later) has a netmask of 255.255.255.0 and thus is on the subnet 132.199.15.0/24. Let's furthermore introduce some more hosts so we have something to play around with, see Figure 9-1.

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 132.199.15.0/24-subnet 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 (132.199.15.1), which knows where to forward the packets to.

Dusk knows the address of it's defaultrouter in its network (rzi, 132.199.15.1), 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 132.199.1.0/24-network, 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 132.199.15.0/24 are attached to the backbone in a similar manner.

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

When we now want to reach a host which is located in the 132.199.16.0/24-subnet from dusk, it won't work routing it to rzi, but you'll have to send it directly to route2 (132.199.15.2). 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 132.199.16.0/24-subnet to route2, and all others to rzi. Instead of specifying this default as 132.199.1.0/24, 132.199.2.0/24, etc., 0.0.0.0 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 132.199.15.0-network, 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 132.199.1.0/24 and 132.199.15.0/24 (and others) are part of the subdomain "rz.uni-regensburg.de". The domain the University of Regensburg got from it's IP-provider is "uni-regensburg.de" (".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 fox_in.socs.uts.edu.au.

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

Further above I told you that the IP-address 127.0.0.1 always belongs to the local host, regardless what's the "real" IP-address of the host. Therefore, 127.0.0.1 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).

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

9.1.7. Next generation Internet protocol - IPv6

  127.0.0.1 

fe80::2a0:d2ff:fea5:e9f5 

10.0.0.0/24 

2001:638:a01:2::/64 

01:23:45:67:89:ab 

03:23:45:ff:fe:67:89:ab	

::0323:45ff:fe67:89ab 

127.0.0.1		localhost
::1			localhost
	  

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

zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {
	type master;
	file "db.reverse";
}; 

5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0	IN   PTR   noon.ipv6.example.com.
	  

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: chap-net.sgml,v 1.2 2002/02/06	14:19:28 jrf 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 9.3.1.1 for a configuration example.

# Compatibility	with 4.2BSD implementation of TCP/IP.  Not recommended.
#options	TCP_COMPAT_42
      

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

options		NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM
      

These options enable lookup of data via DHCP or the BOOTPARAM protocol if the kernel is told to use a NFS root file system. See the 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 9.3.1.1 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.

9.2.3. 连接到 Internet

Internet 连线有许多类型：这一段解释如何使用 modem 经由电话线 并利用 PPP 协定连接到 ISP，提供一个一般 的设定。为了要进行网路连线，必须执行以下步骤：

从以上的列表来看，好像需要很多复杂的程序要做。实际上，这些 步骤是非常容易的：这只是修改，建立或简单地检查一些小的 文字档而已。以下的范例中，我们将假设 modem 连接到第二个 序列埠上 /dev/tty01 (COM2 in DOS.)。

  nameserver 194.109.123.2
  nameserver 191.200.4.52
  #lookup file bind
	  

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

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

  # /etc/ppp/peers/bignet.chat
  ABORT	BUSY
  ABORT	"NO CARRIER"
  ABORT	"NO DIALTONE"
  '' ATDT0299999999
  CONNECT ''
	

  user * password
	  

  alan * pZY9o
	  

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

  /dev/tty01
  lock
  crtscts
  57600
  modem
  defaultroute
  noipdefault
	  

  # pppd call bignet
	

  # tail -f /var/log/messages
	

  #!/bin/sh
  MODEM=tty01
  POP=bignet
  if [ -f /var/spool/lock/LCK..$MODEM ]; then
    echo ppp is	already	running...
  else
    pppd call $POP
    tail -f /var/log/messages
  fi
	  

  #!/bin/sh
  MODEM=tty01
  if [ -f /var/spool/lock/LCK..$MODEM ]; then
    echo -f killing pppd...
    kill -HUP `cat /var/spool/lock/LCK..$MODEM`
    echo done
  else
    echo ppp is	not active
  fi
	  

  # chmod u+x ppp-up	ppp-down
	

9.2.4. 建立小型的家庭网路

网路功能是 Unix 和 NetBSD 的主要优势之一：网路具有强大的 功能又容易设定，而且也不贵，因为不需要购买额外的软体来进行通讯 的运作或是建立伺服器。Section 9.3.1 解释了如何设定 一台 NetBSD 机器来扮演网路中闸道器的角色：所有的连线使用 IPNAT 连接到闸道器。在建立网路之前，唯一要做的事 就是购买 NetBSD 支援的网路卡 (参考 INSTALL 可以 得到支援硬体的清单)。

首先，网路卡必须安装并连接到集线器，交换器或是另一张网路卡。 （请看 Figure 9-6）

下一步，检查网路卡是否被核心支援，可查看 dmesg 指令的输出。在以下的例子中，被核心支援的网路卡是 NE2000 相容卡：

  ...
  ne0 at isa0 port 0x280-0x29f irq 9
  ne0: NE2000 Ethernet
  ne0: Ethernet	address	00:c2:dd:c1:d1:21
  ...
      

如果卡没有被核心承认，检查它是否在核心设定档内并且卡的 IRQ 是否和核心期望的值相符合。例如，在核心设定档中，有一行 isa NE2000 的设定；核心预设卡的 IRQ 为 9。

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

如果卡的设定并不相同，它在开机时，将不能被侦测到。在此例中， 你以更改核心设定档并重新编译一个核心，或是改变卡的设定（通常 可经由设定磁片来设定，如果是老旧的卡，则使用 jumper）。

以下的指令显示网路卡目前的设定：

# ifconfig ne0
ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet 10base2
      

网路卡的软体设定是非常容易的。IP 位址 "192.168.1.1" （为内部的网路所保留的）被指派到这张卡上。

# ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00
      

重复前项指令并得到不同的结果：

# ifconfig ne0
ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	  media: Ethernet 10base2
	  inet 192.168.1.1 netmask 0xffffff00 broadcast	192.168.1.255
      

ifconfig 的输出现在被改变了：IP 位址被 印出来了而且有两个新的 flags，"UP" 和 "RUNNING"。如果介面不是 "UP"，它将不能被 系统用来传送封包。

主机被指派了 IP 位址 192.168.1.1，这是被内部网路所保留的而不能 经由 Internet 到达的位址。设定已经完成了而必须被测试；如果有 另一台主机在网路上，可利用 ping 来测试。 例如，如果主机的位址是 192.168.1.2 ：

  # ping 192.168.1.2
  PING ape	(192.168.1.2): 56 data bytes
  64 bytes from	192.168.1.2: icmp_seq=0	ttl=255	time=1.286 ms
  64 bytes from	192.168.1.2: icmp_seq=1	ttl=255	time=0.649 ms
  64 bytes from	192.168.1.2: icmp_seq=2	ttl=255	time=0.681 ms
  64 bytes from	192.168.1.2: icmp_seq=3	ttl=255	time=0.656 ms
  ^C
  ----ape PING Statistics----
  4 packets transmitted, 4 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev	= 0.649/0.818/1.286/0.312 ms
      

但是现在的设定在下一次开机时会消失，必须重复进行一次网路卡 的设定。为了避免每次开机时重复设定网路卡，需要完成两件事： 第一，建立 /etc/ifconfig.ne0 档并包含 以下这行：

  inet 192.168.1.1 netmask 0xffffff00
      

接著，在 /etc/rc.conf 中，设定以下选项

  auto_ifconfig=YES
      

在下一次开机时，网路卡将会被自动地设定了。

/etc/hosts 是 IP 位址和别名的资料库： 它应该包含属于这个内部网路中的主机位址。例如：

#     $NetBSD: chap-net.sgml,v 1.2 2002/02/06 14:19:28 jrf 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.
#
#
127.0.0.1	      localhost
#
# RFC 1918 specifies that these	networks are "internal".
# 10.0.0.0    10.255.255.255
# 172.16.0.0  172.31.255.255
# 192.168.0.0 192.168.255.255

192.168.1.1   ape.insetti.net ape
192.168.1.2   vespa.insetti.net vespa
192.168.1.0   insetti.net
	

/etc/nsswitch.conf 应该被修改像 Example 9-2 所解释的一样。

摘要，设定网路卡必须执行以下的步骤：网路卡必须被安装并与其他 主机相连接。接著必须设定网路卡(使用 ifconfig) 并且，最后，/etc/hosts 和 /etc/nsswitch.conf 档必须被修改。 这种网路类型的管理非常简单，而且适合不太复杂的小型网路。

9.2.5. 使用序列线连接两台 PC

如果你需要在两台没有网路设备的 PC 之间传输资料，而将资料复制到 磁片上又是不太方便的时候，最简单的解决方案是：两台机器利用序列 缆线做网路连接 (a null modem cable.) 以下的段落描述一些设定。

  # slattach	/dev/tty00
  # ifconfig	sl0 inet 192.168.1.1 192.168.1.2
	

  # slattach	/dev/tty00
  # ifconfig	sl0 inet 192.168.1.2 192.168.1.1
	

  # ping 192.168.1.1
	

  connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
  local
  tty00
  115200
  crtscts
  lock
  noauth
  nodefaultroute
  :192.168.1.2
	

9.3.1. IPNAT

这个字 IPNAT 是由以下字母的开头组成的 Internet Protocol Network Address Translation，可以进行内部网路 和真实网路 (Internet) 的连线工作。这是指只有一个 "真实的" IP，静态的或动态的属于一台跑著 IPNAT 的闸道器， 它也可以让内部网路上的主机，同时连线到 Internet。

一些 IPNAT 范例的使用可以在 /usr/share/examples/ipf 目录中找到：参考 BASIC.NAT 和 nat-setup。

以下设定的例子的详细描述在 Figure 9-6： host 1 可以利用 modem 拨接连接到 Internet 并且获得动态 IP 位址。host 2 和 host 3 不能直接与 Internet 沟通：IPNAT 将 会允许他们如此做：host 1 将扮演 hosts 2 and 3 的闸道器。

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

map ppp0 192.168.1.0/24	-> 0/32	proxy port ftp ftp/tcp
map ppp0 192.168.1.0/24	-> 0/32	portmap	tcp/udp	40000:60000
map ppp0 192.168.1.0/24	-> 0/32
	

#!/bin/sh
# /etc/ppp/ip-up
/etc/rc.d/ipnat	forcestart
	

#!/bin/sh
# /etc/ppp/ip-down
/etc/rc.d/ipnat	forcestop
	

  # chmod u+x ip-up ip-down
	

  # route add default 192.168.1.1
	

9.3.2. NFS

我们在网路上可以使用 NFS 来共享档案和目录。 从档案共享的观点来看，提供档案和目录存取的电脑称之为 server，而使用这些档案和目录的电脑称之为 client。一台电脑可同时成为 client 和 server。

• 要使用 client 和 server，在编译核心时必须加入适当的选项 (在核心设定档中通常很容易发现这些选项。请看 Section 9.2.1 可以获得与 NFS 相关的核心选项 的资讯）。

• server 必需在 /etc/inetd.conf 中 打开它的 RPC 服务。

• 在 /etc/rc.conf 中，server 必须打开 inetd 和 portmap 常驻程式和 nfs_server 选项。

• 在 /etc/rc.conf 中，client 必须打开 inetd 和 nfs_client。

• server 必须列出开放的目录在 /etc/exports 中并且执行 kill -HUP `cat /var/run/mountd.pid。

client 主机可以经由 NFS 存取远端的目录，如果：

• server 主机开放了目录。

• client 主机使用这个指令挂上远端的目录 mount server:/xx/yy /mnt

对远端的目录而言，mount 指令提供了丰富的 选项以供设定。

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

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

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

  buzz:/export/cli?/root / nfs rw
  buzz:/export/common/usr /usr nfs rw,nodev,nosuid
  buzz:/usr/src	/usr/src rw,nodev,nosuid
	

9.3.3. Setting up /net with amd

  % showmount -e wuarchive.wustl.edu
  Exports list on wuarchive.wustl.edu:
  /export/home			     onc.wustl.edu
  /export/local			     onc.wustl.edu
  /export/adm/log		     onc.wustl.edu
  /usr				     onc.wustl.edu
  /				     onc.wustl.edu
  /archive			     Everyone
	

  % cd /net/wuarchive.wustl.edu/archive/systems/unix/NetBSD
	

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.

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.

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

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

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

  # /sbin/ping6 www.kame.net

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

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

  # rtadvd