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