1: **Contents**
2:
3: [[!toc levels=3]]
4:
5: # Setting up TCP/IP on NetBSD in practice
6:
7: ## A walk through the kernel configuration
8:
9: Before we dive into configuring various aspects of network setup, we want to
10: walk through the necessary bits that have to or can be present in the kernel.
11: See [[Compiling the kernel|guide/kernel]] for more details on compiling the
12: kernel, we will concentrate on the configuration of the kernel here. We will
13: take the i386/GENERIC config file as an example here. Config files for other
14: platforms should contain similar information, the comments in the config files
15: give additional hints. Besides the information given here, each kernel option is
16: also documented in the
17: [[!template id=man name="options" section="4"]]
18: manpage, and there is usually a manpage for each driver too, e.g.
19: [[!template id=man name="tlp" section="4"]].
20:
21: The first line of each config file shows the version. It can be used to compare
22: against other versions via CVS, or when reporting bugs.
23:
24: options NTP # NTP phase/frequency locked loop
25:
26: If you want to run the Network Time Protocol (NTP), this option can be enabled
27: for maximum precision. If the option is not present, NTP will still work. See
28: [[!template id=man name="ntpd" section="8"]] for
29: more information.
30:
31: file-system NFS # Network File System client
32:
33: If you want to use another machine's hard disk via the Network File System
34: (NFS), this option is needed. The guide article about the
35: [[Network File System|guide/net-services#nfs]] gives more information on NFS.
36:
37: options NFSSERVER # Network File System server
38:
39: This option includes the server side of the NFS remote file sharing protocol.
40: Enable if you want to allow other machines to use your hard disk. The mentioned
41: article in the guide about [[NFS|guide/net-services#nfs]] contains more
42: information on NFS.
43:
44: #options GATEWAY # packet forwarding
45:
46: If you want to setup a router that forwards packets between networks or network
47: interfaces, setting this option is needed. It doesn't only switch on packet
48: forwarding, but also increases some buffers. See
49: [[!template id=man name="options" section="4"]]
50: for details.
51:
52: options INET # IP + ICMP + TCP + UDP
53:
54: This enables the TCP/IP code in the kernel. Even if you don't want/use
55: networking, you will still need this for machine-internal communication of
56: subsystems like the X Window System. See
57: [[!template id=man name="inet" section="4"]] for
58: more details.
59:
60: options INET6 # IPV6
61:
62: If you want to use IPv6, this is your option. If you don't want IPv6, which is
63: part of NetBSD since the 1.5 release, you can remove/comment out that option.
64: See the
65: [[!template id=man name="inet6" section="4"]]
66: manpage and [[Next generation Internet protocol -
67: IPv6|guide/net-intro#ipv6-intro]] for more information on the next generation
68: Internet protocol.
69:
70: #options IPSEC # IP security
71:
72: Includes support for the IPsec protocol, including key and policy management,
73: authentication and compression. This option can be used without the previous
74: option INET6, if you just want to use IPsec with IPv4, which is possible. See
75: [[!template id=man name="ipsec" section="4"]] for
76: more information.
77:
78: #options IPSEC_ESP # IP security (encryption part; define w/IPSEC)
79:
80: This option is needed in addition to IPSEC if encryption is wanted in IPsec.
81:
82: #options MROUTING # IP multicast routing
83:
84: If multicast services like the MBone services should be routed, this option
85: needs to be included. Note that the routing itself is controlled by the
86: [[!template id=man name="mrouted" section="8"]]
87: daemon.
88:
89: options ISO,TPIP # OSI
90: #options EON # OSI tunneling over IP
91:
92: These options include the OSI protocol stack, which was said for a long time to
93: be the future of networking. It's mostly history these days. :-) See the
94: [[!template id=man name="iso" section="4"]] manpage
95: for more information.
96:
97: options NETATALK # AppleTalk networking protocols
98:
99: Include support for the AppleTalk protocol stack. Userland server programs are
100: needed to make use of that. See pkgsrc/net/netatalk and pkgsrc/net/netatalk-asun
101: for such packages. More information on the AppleTalk protocol and protocol stack
102: are available in the
103: [[!template id=man name="atalk" section="4"]]
104: manpage.
105:
106: options PPP_BSDCOMP # BSD-Compress compression support for PPP
107: options PPP_DEFLATE # Deflate compression support for PPP
108: options PPP_FILTER # Active filter support for PPP (requires bpf)
109:
110: These options tune various aspects of the Point-to-Point protocol. The first two
111: determine the compression algorithms used and available, while the third one
112: enables code to filter some packets.
113:
114: options PFIL_HOOKS # pfil(9) packet filter hooks
115: options IPFILTER_LOG # ipmon(8) log support
116:
117: These options enable firewalling in NetBSD, using IPFilter. See the
118: [[!template id=man name="ipf" section="4"]] and
119: [[!template id=man name="ipf" section="8"]] manpages
120: for more information on operation of IPFilter, and [[Configuring the
121: gateway/firewall|guide/net-practice#ipnat-configuring-gateway]] for a
122: configuration example.
123:
124: # Compatibility with 4.2BSD implementation of TCP/IP. Not recommended.
125: #options TCP_COMPAT_42
126:
127: This option is only needed if you have machines on the network that still run
128: 4.2BSD or a network stack derived from it. If you've got one or more
129: 4.2BSD-systems on your network, you've to pay attention to set the right
130: broadcast-address, as 4.2BSD has a bug in its networking code, concerning the
131: broadcast address. This bug forces you to set all host-bits in the
132: broadcast-address to `0`. The `TCP_COMPAT_42` option helps you ensuring this.
133:
134: options NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM
135:
136: These options enable lookup of data via DHCP or the BOOTPARAM protocol if the
137: kernel is told to use a NFS root file system. See the
138: [[!template id=man name="diskless" section="8"]]
139: manpage for more information.
140:
141: # Kernel root file system and dump configuration.
142: config netbsd root on ? type ?
143: #config netbsd root on sd0a type ffs
144: #config netbsd root on ? type nfs
145:
146: These lines tell where the kernel looks for its root file system, and which
147: filesystem type it is expected to have. If you want to make a kernel that uses a
148: NFS root filesystem via the tlp0 interface, you can do this with
149:
150: root on tlp0 type nfs
151:
152: If a `?` is used instead of a device/type, the kernel tries to
153: figure one out on its own.
154:
155: # ISA serial interfaces
156: com0 at isa? port 0x3f8 irq 4 # Standard PC serial ports
157: com1 at isa? port 0x2f8 irq 3
158: com2 at isa? port 0x3e8 irq 5
159:
160: If you want to use PPP or SLIP, you will need some serial (com) interfaces.
161: Others with attachment on USB, PCMCIA or PUC will do as well.
162:
163: # Network Interfaces
164:
165: This rather long list contains all sorts of network drivers. Please pick the one
166: that matches your hardware, according to the comments. For most drivers, there's
167: also a manual page available, e.g.
168: [[!template id=man name="tlp" section="4"]],
169: [[!template id=man name="ne" section="4"]], etc.
170:
171: # MII/PHY support
172:
173: This section lists media independent interfaces for network cards. Pick one that
174: matches your hardware. If in doubt, enable them all and see what the kernel
175: picks. See the
176: [[!template id=man name="mii" section="4"]] manpage
177: for more information.
178:
179: # USB Ethernet adapters
180: aue* at uhub? port ? # ADMtek AN986 Pegasus based adapters
181: cue* at uhub? port ? # CATC USB-EL1201A based adapters
182: kue* at uhub? port ? # Kawasaki LSI KL5KUSB101B based adapters
183:
184: USB-ethernet adapters only have about 2MBit/s bandwidth, but they are very
185: convenient to use. Of course this needs other USB related options which we won't
186: cover here, as well as the necessary hardware. See the corresponding manpages
187: for more information.
188:
189: # network pseudo-devices
190: pseudo-device bpfilter 8 # Berkeley packet filter
191:
192: This pseudo-device allows sniffing packets of all sorts. It's needed for
193: tcpdump, but also rarpd and some other applications that need to know about
194: network traffic. See
195: [[!template id=man name="bpf" section="4"]] for more
196: information.
197:
198: pseudo-device ipfilter # IP filter (firewall) and NAT
199:
200: This one enables the IPFilter's packet filtering kernel interface used for
201: firewalling, NAT (IP Masquerading) etc. See
202: [[!template id=man name="ipf" section="4"]] and
203: [Configuring the gateway/firewall|guide/net-practice#ipnat-configuring-gateway]]
204: for more information.
205:
206: pseudo-device loop # network loopback
207:
208: This is the `lo0` software loopback network device which is used by some
209: programs these days, as well as for routing things. It should not be omitted.
210: See [[!template id=man name="lo" section="4"]] for
211: more details.
212:
213: pseudo-device ppp 2 # Point-to-Point Protocol
214:
215: If you want to use PPP either over a serial interface or ethernet (PPPoE), you
216: will need this option. See
217: [[!template id=man name="ppp" section="4"]] for
218: details on this interface.
219:
220: pseudo-device sl 2 # Serial Line IP
221:
222: Serial Line IP is a simple encapsulation for IP over (well :) serial lines. It
223: does not include negotiation of IP addresses and other options, which is the
224: reason that it's not in widespread use today any more. See
225: [[!template id=man name="sl" section="4"]].
226:
227: pseudo-device strip 2 # Starmode Radio IP (Metricom)
228:
229: If you happen to have one of the old Metricom Ricochet packet radio wireless
230: network devices, use this pseudo-device to use it. See the
231: [[!template id=man name="strip" section="4"]]
232: manpage for detailed information.
233:
234: pseudo-device tun 2 # network tunneling over tty
235:
236: This network device can be used to tunnel network packets to a device file,
237: `/dev/tun*`. Packets routed to the tun0 interface can be read from `/dev/tun0`,
238: and data written to `/dev/tun0` will be sent out the tun0 network interface.
239: This can be used to implement e.g. QoS routing in userland. See
240: [[!template id=man name="tun" section="4"]] for
241: details.
242:
243: pseudo-device gre 2 # generic L3 over IP tunnel
244:
245: The GRE encapsulation can be used to tunnel arbitrary layer 3 packets over IP,
246: e.g. to implement VPNs. See
247: [[!template id=man name="gre" section="4"]] for more.
248:
249: pseudo-device gif 4 # IPv[46] over IPv[46] tunnel (RFC 1933)
250:
251: Using the GIF interface allows to tunnel e.g. IPv6 over IPv4, which can be used
252: to get IPv6 connectivity if no IPv6-capable uplink (ISP) is available. Other
253: mixes of operations are possible, too. See the
254: [[!template id=man name="gif" section="4"]] manpage
255: for some examples.
256:
257: #pseudo-device faith 1 # IPv[46] tcp relay translation i/f
258:
259: The faith interface captures IPv6 TCP traffic, for implementing userland
260: IPv6-to-IPv4 TCP relays e.g. for protocol transitions. See the
261: [[!template id=man name="faith" section="4"]]
262: manpage for more details on this device.
263:
264: #pseudo-device stf 1 # 6to4 IPv6 over IPv4 encapsulation
265:
266: This adds a network device that can be used to tunnel IPv6 over IPv4 without
267: setting up a configured tunnel before. The source address of outgoing packets
268: contains the IPv4 address, which allows routing replies back via IPv4. See the
269: [[!template id=man name="stf" section="4"]] manpage
270: and [IPv6 Connectivity & Transition via 6to4|guide/net-practice#ipv6-6to4]] for
271: more details.
272:
273: pseudo-device vlan # IEEE 802.1q encapsulation
274:
275: This interface provides support for IEEE 802.1Q Virtual LANs, which allows
276: tagging Ethernet frames with a `vlan` ID. Using properly configured switches
277: (that also have to support VLAN, of course), this can be used to build virtual
278: LANs where one set of machines doesn't see traffic from the other (broadcast and
279: other). The
280: [[!template id=man name="vlan" section="4"]] manpage
281: tells more about this.
282:
283: ## Overview of the network configuration files
284:
285: The following is a list of the files used to configure the network. The usage of
286: these files, some of which have already been met the first chapters, will be
287: described in the following sections.
288:
289: * `/etc/hosts` -- Local hosts database file. Each line contains information
290: regarding a known host and contains the internet address, the host's name and
291: the aliases. Small networks can be configured using only the hosts file,
292: without a *name server*.
293:
294: * `/etc/resolv.conf` -- This file specifies how the routines which provide
295: access to the Internet Domain Name System should operate. Generally it
296: contains the addresses of the name servers.
297:
298: * `/etc/ifconfig.xxx` -- This file is used for the automatic configuration of
299: the network card at boot.
300:
301: * `/etc/mygate` -- Contains the IP address of the gateway.
302:
303: * `/etc/nsswitch.conf` -- Name service switch configuration file. It controls
304: how a process looks up various databases containing information regarding
305: hosts, users, groups, etc. Specifically, this file defines the order to look
306: up the databases. For example, the line:
307:
308: hosts: files dns
309:
310: specifies that the hosts database comes from two sources, *files* (the local
311: `/etc/hosts` file) and *DNS*, (the Internet Domain Name System) and that the
312: local files are searched before the DNS.
313:
314: It is usually not necessary to modify this file.
315:
316: ## Connecting to the Internet with a modem
317:
318: There are many types of Internet connections: this section explains how to
319: connect to a provider using a modem over a telephone line using the PPP
320: protocol, a very common setup. In order to have a working connection, the
321: following steps must be done:
322:
323: 1. Get the necessary information from the provider.
324: 2. Edit the file `/etc/resolv.conf` and check `/etc/nsswitch.conf`.
325: 3. Create the directories `/etc/ppp` and `/etc/ppp/peers` if they don't exist.
326: 4. Create the connection script, the chat file and the pppd options file.
327: 5. Created the user-password authentication file.
328:
329: Judging from the previous list it looks like a complicated procedure that
330: requires a lot of work. Actually, the single steps are very easy: it's just a
331: matter of modifying, creating or simply checking some small text files. In the
332: following example it will be assumed that the modem is connected to the second
333: serial port `/dev/tty01` (COM2 in DOS).
334:
335: A few words on the difference between `com`, `COM` and `tty`. For NetBSD, `com`
336: is the name of the serial port driver (the one that is displayed by `dmesg`) and
337: `tty` is the name of the port. Since numbering starts at 0, `com0` is the driver
338: for the first serial port, named `tty00`. In the DOS world, instead, `COM1`
339: refers to the first serial port (usually located at 0x3f8), `COM2` to the
340: second, and so on. Therefore `COM1` (DOS) corresponds to `/dev/tty00` (NetBSD).
341:
342: Besides external modems connected to COM ports (using `/dev/tty0[012]` on i386,
343: `/dev/tty[ab]` on sparc, ...) modems on USB (`/dev/ttyU*`) and pcmcia/cardbus
344: (`/dev/tty0[012]`) can be used.
345:
346: ### Getting the connection information
347:
348: The first thing to do is ask the provider the necessary information for the
349: connection, which means:
350:
351: * The phone number of the nearest POP.
352: * The authentication method to be used.
353: * The username and password for the connection.
354: * The IP addresses of the name servers.
355:
356: ### resolv.conf and nsswitch.conf
357:
358: The `/etc/resolv.conf` file must be configured using the information supplied by
359: the provider, especially the addresses of the DNS. In this example the two DNS
360: will be `194.109.123.2` and `191.200.4.52`:
361:
362: nameserver 194.109.123.2
363: nameserver 191.200.4.52
364:
365: And now an example of the `/etc/nsswitch.conf` file:
366:
367: # /etc/nsswitch.conf
368: group: compat
369: group_compat: nis
370: hosts: files dns
371: netgroup: files [notfound=return] nis
372: networks: files
373: passwd: compat
374: passwd_compat: nis
375: shells: files
376:
377: The defaults of doing hostname lookups via `/etc/hosts` followed by the DNS
378: works fine and there's usually no need to modify this.
379:
380: ### Creating the directories for pppd
381:
382: The directories `/etc/ppp` and `/etc/ppp/peers` will contain the configuration
383: files for the PPP connection. After a fresh install of NetBSD they don't exist
384: and must be created (chmod 700).
385:
386: # mkdir /etc/ppp
387: # mkdir /etc/ppp/peers
388:
389: ### Connection script and chat file
390:
391: The connection script will be used as a parameter on the pppd command line; it
392: is located in `/etc/ppp/peers` and has usually the name of the provider. For
393: example, if the provider's name is BigNet and your user name for the connection
394: to the provider is alan, an example connection script could be:
395:
396: # /etc/ppp/peers/bignet
397: connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat'
398: noauth
399: user alan
400: remotename bignet.it
401:
402: In the previous example, the script specifies a *chat file* to be used for the
403: connection. The options in the script are detailed in the
404: [[!template id=man name="pppd" section="8"]] man
405: page.
406:
407: ### Note
408:
409: If you are experiencing connection problems, add the following two lines to the
410: connection script
411:
412: debug
413: kdebug 4
414:
415: You will get a log of the operations performed when the system tries to connect.
416: See [[!template id=man name="pppd" section="8"]],
417: [[!template id=man name="syslog.conf" section="5"]].
418:
419: The connection script calls the chat application to deal with the physical
420: connection (modem initialization, dialing, ...) The parameters to chat can be
421: specified inline in the connection script, but it is better to put them in a
422: separate file. If, for example, the telephone number of the POP to call is
423: `02 99999999`, an example chat script could be:
424:
425: # /etc/ppp/peers/bignet.chat
426: ABORT BUSY
427: ABORT "NO CARRIER"
428: ABORT "NO DIALTONE"
429: '' ATDT0299999999
430: CONNECT ''
431:
432: *Note*: If you have problems with the chat file, you can try connecting manually
433: to the POP with the
434: [[!template id=man name="cu" section="1"]] program and
435: verify the exact strings that you are receiving.
436:
437: ### Authentication
438:
439: During authentication each of the two systems verifies the identity of the other
440: system, although in practice you are not supposed to authenticate the provider,
441: but only to be verified by him, using one of the following methods:
442:
443: * PAP/CHAP
444: * login
445:
446: Most providers use a PAP/CHAP authentication.
447:
448: #### PAP/CHAP authentication
449:
450: The authentication information (speak: password) is stored in the
451: `/etc/ppp/pap-secrets` for PAP and in `/etc/ppp/chap-secrets` for CHAP. The
452: lines have the following format:
453:
454: user * password
455:
456: For example:
457:
458: alan * pZY9o
459:
460: For security reasons the `pap-secrets` and `chap-secrets` files should be owned
461: by root and have permissions 600.
462:
463: # chown root /etc/ppp/pap-secrets
464: # chown root /etc/ppp/chap-secrets
465: # chmod 600 /etc/ppp/pap-secrets
466: # chmod 600 /etc/ppp/chap-secrets
467:
468: #### Login authentication
469:
470: This type of authentication is not widely used today; if the provider uses login
471: authentication, user name and password must be supplied in the chat file instead
472: of the PAP/CHAP files, because the chat file simulates an interactive login. In
473: this case, set up appropriate permissions for the chat file.
474:
475: The following is an example chat file with login authentication:
476:
477: # /etc/ppp/peers/bignet.chat
478: ABORT BUSY
479: ABORT "NO CARRIER"
480: ABORT "NO DIALTONE"
481: '' ATDT0299999999
482: CONNECT ''
483: TIMEOUT 50
484: ogin: alan
485: ssword: pZY9o
486:
487: ### pppd options
488:
489: The only thing left to do is the creation of the pppd options file, which is
490: `/etc/ppp/options` (chmod 644):
491:
492: /dev/tty01
493: lock
494: crtscts
495: 57600
496: modem
497: defaultroute
498: noipdefault
499:
500: Check the
501: [[!template id=man name="pppd" section="8"]] man
502: page for the meaning of the options.
503:
504: ### Testing the modem
505:
506: Before activating the link it is a good idea to make a quick modem test, in
507: order to verify that the physical connection and the communication with the
508: modem works. For the test the
509: [[!template id=man name="cu" section="1"]] program can
510: be used, as in the following example.
511:
512: 1. Create the file `/etc/uucp/port` with the following lines:
513:
514: type modem
515: port modem
516: device /dev/tty01
517: speed 115200
518:
519: (substitute the correct device in place of `/dev/tty01`).
520:
521: 2. Write the command `cu -p modem` to start sending commands to the modem. For
522: example:
523:
524: # cu -p modem
525: Connected.
526: ATZ
527: OK
528: ~.
529:
530: Disconnected.
531: #
532:
533: In the previous example the reset command (ATZ) was sent to the modem, which
534: replied with OK: the communication works. To exit
535: [[!template id=man name="cu" section="1"]], write
536: `~` (tilde) followed by `.` (dot), as in the example.
537:
538: If the modem doesn't work, check that it is connected to the correct port (i.e.
539: you are using the right port with
540: [[!template id=man name="cu" section="1"]]. Cables are
541: a frequent cause of trouble, too.
542:
543: When you start
544: [[!template id=man name="cu" section="1"]] and a
545: message saying `Permission denied` appears, check who is the owner of the
546: `/dev/tty##` device, it must be "uucp". For example:
547:
548: $ ls -l /dev/tty00
549: crw------- 1 uucp wheel 8, 0 Mar 22 20:39 /dev/tty00
550:
551: If the owner is root, the following happens:
552:
553: $ ls -l /dev/tty00
554: crw------- 1 root wheel 8, 0 Mar 22 20:39 /dev/tty00
555: $ cu -p modem
556: cu: open (/dev/tty00): Permission denied
557: cu: All matching ports in use
558:
559: ### Activating the link
560:
561: At last everything is ready to connect to the provider with the following
562: command:
563:
564: # pppd call bignet
565:
566: where `bignet` is the name of the already described connection script. To see
567: the connection messages of pppd, give the following command:
568:
569: # tail -f /var/log/messages
570:
571: To disconnect, do a `kill -HUP` of `pppd`.
572:
573: # pkill -HUP pppd
574:
575: ### Using a script for connection and disconnection
576:
577: When the connection works correctly, it's time to write a couple of scripts to
578: avoid repeating the commands every time. These two scripts can be named, for
579: example, `ppp-start` and `ppp-stop`.
580:
581: `ppp-start` is used to connect to the provider:
582:
583: #!/bin/sh
584: MODEM=tty01
585: POP=bignet
586: if [ -f /var/spool/lock/LCK..$MODEM ]; then
587: echo ppp is already running...
588: else
589: pppd call $POP
590: tail -f /var/log/messages
591: fi
592:
593: `ppp-stop` is used to close the connection:
594:
595: #!/bin/sh
596: MODEM=tty01
597: if [ -f /var/spool/lock/LCK..$MODEM ]; then
598: echo -f killing pppd...
599: kill -HUP `cat /var/spool/lock/LCK..$MODEM`
600: echo done
601: else
602: echo ppp is not active
603: fi
604:
605: The two scripts take advantage of the fact that when pppd is active, it creates
606: the file `LCK..tty01` in the `/var/spool/lock` directory. This file contains the
607: process ID (*pid*) of the pppd process.
608:
609: The two scripts must be executable:
610:
611: # chmod u+x ppp-start ppp-stop
612:
613: ### Running commands after dialin
614:
615: If you find yourself to always run the same set of commands each time you dial
616: in, you can put them in a script `/etc/ppp/ip-up` which will be called by
617: [[!template id=man name="pppd" section="8"]] after
618: successful dial-in. Likewise, before the connection is closed down,
619: `/etc/ppp/ip-down` is executed. Both scripts are expected to be executable. See
620: [[!template id=man name="pppd" section="8"]] for
621: more details.
622:
623: ## Creating a small home network
624:
625: Networking is one of the main strengths of Unix and NetBSD is no exception:
626: networking is both powerful and easy to set up and inexpensive too, because
627: there is no need to buy additional software to communicate or to build a server.
628: [[Setting up an Internet gateway with IPNAT|guide/net-practice#ipnat]] explains
629: how to configure a NetBSD machine to act as a gateway for a network: with IPNAT
630: all the hosts of the network can reach the Internet with a single connection to
631: a provider made by the gateway machine. The only thing to be checked before
632: creating the network is to buy network cards supported by NetBSD (check the
633: `INSTALL.*` files for a list of supported devices).
634:
635: First, the network cards must be installed and connected to a hub, switch or
636: directly (see the next image for an example configuration).
637:
638: Next, check that the network cards are recognized by the kernel, studying the
639: output of the `dmesg` command. In the following example the kernel recognized
640: correctly an NE2000 clone:
641:
642: ...
643: ne0 at isa0 port 0x280-0x29f irq 9
644: ne0: NE2000 Ethernet
645: ne0: Ethernet address 00:c2:dd:c1:d1:21
646: ...
647:
648: If the card is not recognized by the kernel, check that it is enabled in the
649: kernel configuration file and then that the card's IRQ matches the one that the
650: kernel expects. For example, this is the isa NE2000 line in the configuration
651: file; the kernel expects the card to be at IRQ 9.
652:
653: ...
654: ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards
655: ...
656:
657: If the card's configuration is different, it will probably not be found at boot.
658: In this case, either change the line in the kernel configuration file and
659: compile a new kernel or change the card's setup (usually through a setup disk
660: or, for old cards, a jumper on the card).
661:
662: The following command shows the network card's current configuration:
663:
664: # ifconfig ne0
665: ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500
666: address: 00:50:ba:aa:a7:7f
667: media: Ethernet autoselect (10baseT)
668: inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1
669:
670: The software configuration of the network card is very easy. The IP address
671: 192.168.1.1 is assigned to the card.
672:
673: # ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00
674:
675: Note that the networks 10.0.0.0/8 and 192.168.0.0/16 are reserved for private
676: networks, which is what we're setting up here.
677:
678: Repeating the previous command now gives a different result:
679:
680: # ifconfig ne0
681: ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
682: address: 00:50:ba:aa:a7:7f
683: media: Ethernet autoselect (10baseT)
684: inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
685: inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1
686:
687: The output of `ifconfig` has now changed: the IP address is now printed and
688: there are two new flags, `UP` and `RUNNING` If the interface isn't `UP`, it will
689: not be used by the system to send packets.
690:
691: The host was given the IP address 192.168.1.1, which belongs to the set of
692: addresses reserved for internal networks which are not reachable from the
693: Internet. The configuration is finished and must now be tested; if there is
694: another active host on the network, a `ping` can be tried. For example, if
695: 192.168.1.2 is the address of the active host:
696:
697: # ping 192.168.1.2
698: PING ape (192.168.1.2): 56 data bytes
699: 64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms
700: 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms
701: 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms
702: 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms
703: ^C
704: ----ape PING Statistics----
705: 4 packets transmitted, 4 packets received, 0.0% packet loss
706: round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms
707:
708: With the current setup, at the next boot it will be necessary to repeat the
709: configuration of the network card. In order to avoid repeating the card's
710: configuration at each boot, add the following lines to `/etc/rc.conf`:
711:
712: auto_ifconfig=yes
713: ifconfig_ne0="inet 192.168.1.1 netmask 0xffffff00"
714:
715: In this example the variable `ifconfig_ne0` was set because the network card was
716: recognized as *ne0* by the kernel; if you are using a different adapter,
717: substitute the appropriate name in place of ne0.
718:
719: At the next boot the network card will be configured automatically.
720:
721: If you have a router that is connected to the internet, you can use it as
722: default router, which will handle all your packets. To do so, set `defaultroute`
723: to the router's IP address in `/etc/rc.conf`:
724:
725: defaultroute=192.168.0.254
726:
727: Be sure to use the default router's IP address instead of name, in case your DNS
728: server is beyond the default router. In that case, the DNS server couldn't be
729: reached to resolve the default router's hostname and vice versa, creating a
730: chicken-and-egg problem.
731:
732: To reach hosts on your local network, and assuming you really have very few
733: hosts, adjust `/etc/hosts` to contain the addresses of all the hosts belonging
734: to the internal network. For example:
735:
736: #
737: # Host Database
738: # This file should contain the addresses and aliases
739: # for local hosts that share this file.
740: # It is used only for "ifconfig" and other operations
741: # before the nameserver is started.
742: #
743: #
744: 127.0.0.1 localhost
745: ::1 localhost
746: #
747: # RFC 1918 specifies that these networks are "internal".
748: # 10.0.0.0 10.255.255.255
749: # 172.16.0.0 172.31.255.255
750: # 192.168.0.0 192.168.255.255
751:
752: 192.168.1.1 ape.insetti.net ape
753: 192.168.1.2 vespa.insetti.net vespa
754: 192.168.1.0 insetti.net
755:
756: If you are dialed in via an Internet Service Provider, or if you have a local
757: Domain Name Server (DNS) running, you may want to use it to resolve hostnames to
758: IP addresses, possibly in addition to `/etc/hosts`, which would only know your
759: own hosts. To configure a machine as DNS client, you need to edit
760: `/etc/resolv.conf`, and enter the DNS server's address, in addition to an
761: optional domain name that will be appended to hosts with no domain, in order to
762: create a FQDN for resolving. Assuming your DNS server's IP address is
763: 192.168.1.2 and it is setup to serve for "home.net", put the following into
764: `/etc/resolv.conf`:
765:
766: # /etc/resolv.conf
767: domain home.net
768: nameserver 192.168.1.2
769:
770: The `/etc/nsswitch.conf` file should be checked as explained in the previous
771: [[nsswitch.conf example|guide/net-practice#rc.conf_and_nsswitch.conf]].
772:
773: Summing up, to configure the network the following must be done: the network
774: adapters must be installed and physically connected. Next they must be
775: configured (with `ifconfig`) and, finally, the file `/etc/rc.conf` must be
776: modified to configure the interface and possibly default router, and
777: `/etc/resolv.conf` and `/etc/nsswitch.conf` should be adjusted if DNS should be
778: used. This type of network management is sufficient for small networks without
779: sophisticated needs.
780:
781: ## Setting up an Internet gateway with IPNAT
782:
783: The mysterious acronym IPNAT hides the Internet Protocol Network Address
784: Translation, which enables the routing of an internal network (e.g. your home
785: network as described in the previous section) on a real network (Internet). This
786: means that with only one *real* IP, static or dynamic, belonging to a gateway
787: running IPNAT, it is possible to create simultaneous connections to the Internet
788: for all the hosts of the internal network.
789:
790: Some usage examples of IPNAT can be found in the subdirectory
791: `/usr/share/examples/ipf`: look at the files `BASIC.NAT` and `nat-setup`.
792:
793: The setup for the example described in this section is detailed in the following
794: figure: *host 1* can connect to the Internet calling a provider with a modem and
795: getting a dynamic IP address. *host 2* and *host 3* can't communicate with the
796: Internet with a normal setup: IPNAT allows them to do it: host 1 will act as a
797: Internet gateway for hosts 2 and 3. Using host 1 as default router, hosts 2 and
798: 3 will be able to access the Internet.
799:
800: 
801: **Network with gateway**
802:
803: ### Configuring the gateway/firewall
804:
805: To use IPNAT, the *pseudo-device ipfilter* must be compiled into the kernel, and
806: IP packet forwarding must be enabled in the kernel. To check, run:
807:
808: # sysctl net.inet.ip.forwarding
809: net.inet.ip.forwarding = 1
810:
811: If the result is `1` as in the previous example, the option is enabled,
812: otherwise, if the result is `0` the option is disabled. You can do two things:
813:
814: 1. Compile a new kernel, with the GATEWAY option enabled.
815:
816: 2. Enable the option in the current kernel with the following command:
817:
818: # sysctl -w net.inet.ip.forwarding=1
819:
820: You can add sysctl settings to `/etc/sysctl.conf` to have them set
821: automatically at boot. In this case you would want to add
822:
823: net.inet.ip.forwarding=1
824:
825:
826: The rest of this section explains how to create an IPNAT configuration that is
827: automatically started every time that a connection to the provider is activated
828: with the PPP link. With this configuration all the host of a home network (for
829: example) will be able to connect to the Internet through the gateway machine,
830: even if they don't use NetBSD.
831:
832: For the setup, first, create the `/etc/ipnat.conf` file containing the following
833: rules:
834:
835: map ppp0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp
836: map ppp0 192.168.1.0/24 -> 0/32 portmap tcp/udp 40000:60000
837: map ppp0 192.168.1.0/24 -> 0/32
838:
839: 192.168.1.0/24 are the network addresses that should be mapped. The first line
840: of the configuration file is optional: it enables active FTP to work through the
841: gateway. The second line is used to handle correctly tcp and udp packets; the
842: portmapping is necessary because of the many to one relationship). The third
843: line is used to enable ICMP, ping, etc.
844:
845: Next, create the `/etc/ppp/ip-up` file; it will be called automatically every
846: time that the PPP link is activated:
847:
848: #!/bin/sh
849: # /etc/ppp/ip-up
850: /etc/rc.d/ipnat forcestart
851:
852: Create the file `/etc/ppp/ip-down`; it will be called automatically when the PPP
853: link is closed:
854:
855: #!/bin/sh
856: # /etc/ppp/ip-down
857: /etc/rc.d/ipnat forcestop
858:
859: Both `ip-up` and `ip-down` must be executable:
860:
861: # chmod u+x ip-up ip-down
862:
863: The gateway machine is now ready.
864:
865: ### Configuring the clients
866:
867: Create a `/etc/resolv.conf` file like the one on the gateway machine, to make
868: the clients access the same DNS server as the gateway.
869:
870: Next, make all clients use the gateway as their default router. Use the
871: following command:
872:
873: # route add default 192.168.1.1
874:
875: 192.168.1.1 is the address of the gateway machine configured in the previous
876: section.
877:
878: Of course you don't want to give this command every time, so it's better to
879: define the `defaultroute` entry in the `/etc/rc.conf` file: the default route
880: will be set automatically during system initialization, using the defaultroute
881: option as an argument to the `route add default` command.
882:
883: If the client machine is not using NetBSD, the configuration will be different.
884: On Windows PCs you need to set the gateway property of the TCP/IP protocol to
885: the IP address of the NetBSD gateway.
886:
887: That's all that needs to be done on the client machines.
888:
889: ### Some useful commands
890:
891: The following commands can be useful for diagnosing problems:
892:
893: * `ping` -- tries to connect to other computers via ICMP (usually used for
894: testing if a connection exists).
895: * `netstat -r` -- Displays the routing tables (similar to `route show`).
896: * `traceroute` -- On the client it shows the route followed by the packets to
897: their destination.
898: * `tcpdump` -- Use on the gateway to monitor TCP/IP traffic.
899:
900: ## Setting up a network bridge device
901:
902: A bridge can be used to combine different physical networks into one logical
903: network, i.e. connect them at layer 2 of the ISO-OSI model, not at layer 3,
904: which is what a router would do. The NetBSD `bridge` driver provides bridge
905: functionality on NetBSD systems.
906:
907: ### Bridge example
908:
909: In this example two physical networks are going to be combined in one logical
910: network, 192.168.1.0, using a NetBSD bridge. The NetBSD machine which is going
911: to act as bridge has two interfaces, ne0 and ne1, which are each connected to
912: one physical network.
913:
914: The first step is to make sure support for the `bridge` is compiled in the
915: running kernel. Support is included in the GENERIC kernel.
916:
917: When the system is ready the bridge can be created, this can be done using the
918: [[!template id=man name="brconfig" section="8"]]
919: command. First of a bridge interface has to be created. With the following
920: `ifconfig` command the `bridge0` interface will be created:
921:
922: $ ifconfig bridge0 create
923:
924: Please make sure that at this point both the ne0 and ne1 interfaces are up. The
925: next step is to add the ne0 and ne1 interfaces to the bridge.
926:
927: $ brconfig bridge0 add ne0 add ne1 up
928:
929: This configuration can be automatically set up by creating an
930: `/etc/ifconfig.interface` file, in this case `/etc/ifconfig.bridge0`, with the
931: following contents:
932:
933: create
934: !brconfig $int add ne0 add ne1 up
935:
936: After setting up the bridge the bridge configuration can be displayed using the
937: `brconfig -a` command. Remember that if you want to give the bridge machine an
938: IP address you can only allocate an IP address to one of the interfaces which
939: are part of the bridge.
940:
941: ## A common LAN setup
942:
943: The small home network discussed in the previous section contained many items
944: that were configured manually. In bigger LANs that are centrally managed, one
945: can expect Internet connectivity being available via some router, a DNS server
946: being available, and most important, a DHCP server which hands out IP addresses
947: to clients on request. To make a NetBSD client run in such an environment, it's
948: usually enough to set
949:
950: dhcpcd=yes
951:
952: in `/etc/rc.conf`, and the IP address will be set automatically,
953: `/etc/resolv.conf` will be created and routing setup to the default router.
954:
955: ## Connecting two PCs through a serial line
956:
957: If you need to transfer files between two PCs which are not networked there is a
958: simple solution which is particularly handy when copying the files to a floppy
959: is not practical: the two machines can be networked with a serial cable (a *null
960: modem* cable). The following sections describe some configurations.
961:
962: ### Connecting NetBSD with BSD or Linux
963:
964: The easiest case is when both machines run NetBSD: making a connection with the
965: SLIP protocol is very easy. On the first machine write the following commands:
966:
967: # slattach /dev/tty00
968: # ifconfig sl0 inet 192.168.1.1 192.168.1.2
969:
970: On the second machine write the following commands:
971:
972: # slattach /dev/tty00
973: # ifconfig sl0 inet 192.168.1.2 192.168.1.1
974:
975: Now you can test the connection with `ping`; for example, on the second PC
976: write:
977:
978: # ping 192.168.1.1
979:
980: If everything worked there is now an active network connection between the two
981: machines and ftp, telnet and other similar commands can be executed. The textual
982: aliases of the machines can be written in the `/etc/hosts` file.
983:
984: * In the previous example both PCs used the first serial port (`/dev/tty0`).
985: Substitute the appropriate device if you are using another port.
986:
987: * IP addresses like 192.168.x.x are reserved for `internal` networks. The first
988: PC has address 192.168.1.1 and the second 192.168.1.2.
989:
990: * To achieve a faster connection the `-s speed` option to `slattach` can be
991: specified.
992:
993: * `ftp` can be used to transfer files only if inetd is active and the ftpd
994: * server is enabled.
995:
996: ### Linux
997:
998: If one of the two PCs runs Linux, the commands are slightly different (on the
999: Linux machine only). If the Linux machine gets the 192.168.1.2 address, the
1000: following commands are needed:
1001:
1002: # slattach -p slip -s 115200 /dev/ttyS0 &
1003: # ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up
1004: # route add 192.168.1.1 dev sl0
1005:
1006: Don't forget the `&` in the first command.
1007:
1008: ### Connecting NetBSD and Windows NT
1009:
1010: NetBSD and Windows NT can be (almost) easily networked with a serial *null
1011: modem* cable. Basically what needs to be done is to create a *Remote Access*
1012: connection under Windows NT and to start pppd on NetBSD.
1013:
1014: Start pppd as root after having created a `.ppprc` in `/root`. Use the following
1015: example as a template.
1016:
1017: connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
1018: local
1019: tty00
1020: 115200
1021: crtscts
1022: lock
1023: noauth
1024: nodefaultroute
1025: :192.168.1.2
1026:
1027: The meaning of the first line will be explained later in this section;
1028: 192.168.1.2 is the IP address that will be assigned by NetBSD to the Windows NT
1029: host; `tty00` is the serial port used for the connection (first serial port).
1030:
1031: On the NT side a *null modem* device must be installed from the Control Panel
1032: (Modem icon) and a Remote Access connection using this modem must be created.
1033: The null modem driver is standard under Windows NT 4 but it's not a 100% null
1034: modem: when the link is activated, NT sends the string CLIENT and expects to
1035: receive the answer CLIENTSERVER. This is the meaning of the first line of the
1036: `.ppprc` file: `chat` must answer to NT when the connection is activated or
1037: the connection will fail.
1038:
1039: In the configuration of the Remote Access connection the following must be
1040: specified: use the null modem, telephone number `1` (it's not used, anyway), PPP
1041: server, enable only TCP/IP protocol, use IP address and nameservers from the
1042: server (NetBSD in this case). Select the hardware control flow and set the port
1043: to 115200 8N1.
1044:
1045: Now everything is ready to activate the connection.
1046:
1047: * Connect the serial ports of the two machines with the null modem cable.
1048: * Launch pppd on NetBSD. To see the messages of pppd:
1049: `tail -f /var/log/messages`).
1050: * Activate the Remote Access connection on Windows NT.
1051:
1052: ### Connecting NetBSD and Windows 95
1053:
1054: The setup for Windows 95 is similar to the one for Windows NT: Remote Access on
1055: Windows 95 and the PPP server on NetBSD will be used. Most (if not all) Windows
1056: 95 releases don't have the *null modem* driver, which makes things a little more
1057: complicated. The easiest solution is to find one of the available null modem
1058: drivers on the Internet (it's a small `.INF` file) and repeat the same steps as
1059: for Windows NT. The only difference is that the first line of the `.ppprc` file
1060: (the one that calls `chat`) can be removed.
1061:
1062: If you can't find a real null modem driver for Windows 95 it's still possible to
1063: use a little trick:
1064:
1065: * Create a Remote Access connection like the one described before for Windows
1066: NT, but using the *Standard Modem*.
1067:
1068: * In `.ppprc` substitute the line that calls `chat` with the following line
1069:
1070: connect '/usr/sbin/chat -v ATH OK AT OK ATE0V1 OK AT OK ATDT CONNECT'
1071:
1072: * Activate the connection as described in the section before for Windows NT.
1073:
1074:
1075: In this way the `chat` program, called when the connection is activated,
1076: emulates what Windows 95 thinks is a standard modem, returning to Windows 95 the
1077: same answers that a standard modem would return. Whenever Windows 95 sends a
1078: modem command string, `chat` returns OK.
1079:
1080: ## IPv6 Connectivity & Transition via 6to4
1081:
1082: This section will concentrate on how to get network connectivity for IPv6 and -
1083: as that is rarely available directly - talk at length about the alternatives to
1084: native IPv6 connectivity as a transitional method until native IPv6 peers are
1085: available.
1086:
1087: Finding an ISP that offers IPv6 natively needs quite some luck. What you need
1088: next is a router that will be able to handle the traffic. To date, not all
1089: router manufacturers offer IPv6 or hardware accelerated IPv6 features, and
1090: gateway NAT boxes only rarely support IPv6 and also block IPv6 tunnels. An
1091: alternative approach involves configuring a standard PC running NetBSD to act as
1092: a router. The base NetBSD system contains a complete IPv6 routing solution, and
1093: for special routing needs software like Zebra can provide additional routing
1094: protocols. This solution is rather common for sites that want IPv6
1095: connectivity today. The drawbacks are that you need an ISP that supports
1096: IPv6 and that you may need a dedicated uplink only for IPv6.
1097:
1098: IPv6 to-the-door may be rare, but you can still get IPv6 connectivity by using
1099: tunnels. Instead of talking IPv6 on the wire, the IPv6 packets are encapsulated
1100: in IPv4 packets, as shown in the next image. Using the existing IPv4
1101: infrastructure, the encapsulated packets are sent to a IPv6-capable uplink that
1102: will then remove the encapsulation, and forward the IPv6 packets.
1103:
1104: 
1105: **A frequently used method for transition is tunneling IPv6 in IPv4 packets**
1106:
1107: When using tunnels, there are two possibilities. One is to use a so-called
1108: *configured* tunnel, the other is called an *automatic* tunnel. A *configured*
1109: tunnel is one that required preparation from both ends of the tunnel, usually
1110: connected with some kind of registration to exchange setup information. An
1111: example for such a configured tunnel is the IPv6-over-IPv4 encapsulation
1112: described in
1113: [RFC1933](http://tools.ietf.org/html/rfc1933) ("RFC 1933: Transition Mechanisms
1114: for IPv6 Hosts and Routers"), and that's implemented e.g. by the
1115: [[!template id=man name="gif" section="4"]]
1116: device found in NetBSD.
1117:
1118: An *automatic* tunnel consists of a public server that has some kind of IPv6
1119: connectivity, e.g. via 6Bone. That server has made its connectivity data public,
1120: and also runs a tunneling protocol that does not require an explicit
1121: registration of the sites using it as uplink. A well-used example of such a
1122: protocol is the 6to4 mechanism described in
1123: [RFC3056](http://tools.ietf.org/html/rfc3056) ("RFC 3056: Connection of IPv6
1124: Domains via IPv4 Clouds"), and that is implemented in the
1125: [[!template id=man name="stf" section="4"]] device
1126: found in NetBSD's. Another mechanism that does not require registration of
1127: IPv6-information is the 6over4 mechanism, which implements transporting of IPv6
1128: over a multicast-enabled IPv4 network, instead of e.g. ethernet or FDDI. 6over4
1129: is documented in [RFC2529](http://tools.ietf.org/html/rfc2529) ("RFC 2529:
1130: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"). It's main
1131: drawback is that you do need existing multicast infrastructure. If you don't
1132: have that, setting it up is about as much effort as setting up a configured IPv6
1133: tunnel directly, so it's usually not worth bothering in that case.
1134:
1135: ### Getting 6to4 IPv6 up & running
1136:
1137: 6to4 is an easy way to get IPv6 connectivity for hosts that only have an IPv4
1138: uplink, especially if you have the background given in
1139: [[the chapter about IPv6|guide/net-intro#ipv6-intro]]. It can be used with
1140: static as well as dynamically assigned IPv4 addresses, e.g. as found in modem
1141: dialup scenarios today. When using dynamic IPv4 addresses, a change of IP
1142: addresses will be a problem for incoming traffic, i.e. you can't run persistent
1143: servers.
1144:
1145: Example configurations given in this section are for NetBSD 1.5.2.
1146:
1147: ### Obtaining IPv6 Address Space for 6to4
1148:
1149: The 6to4 IPv6 setup on your side doesn't consist of a single IPv6 address;
1150: Instead, you get a whole /48 network! The IPv6 addresses are derived from your
1151: (single) IPv4 address. The address prefix *2002:` is reserved for 6to4 based
1152: addresses (i.e. IPv6 addresses derived from IPv4 addresses). The next 32 bits
1153: are your IPv4 address. This results in a /48 network that you can use for your
1154: very own purpose. It leaves 16 bits space for 2^16^ IPv6 subnets, which can take
1155: up to 2^64^ nodes each. The next figure illustrates the building of your IPv6
1156: address (range) from your IPv4 address.
1157:
1158: Thanks to the 6to4 prefix and your worldwide unique IPv4 address, this address
1159: block is unique, and it's mapped to your machine carrying the IPv4 address in
1160: question.
1161:
1162: 
1163: **6to4 derives an IPv6 from an IPv4 address**
1164:
1165: ### How to get connected
1166:
1167: In contrast to the configured *IPv6-over-IPv4 tunnel* setup, you do not have to
1168: register at a 6bone-gateway, which would only then forward your IPv6 traffic
1169: encapsulated in IPv4. Instead, as your IPv6 address is derived from your IPv4
1170: address, inbound traffic can be sent through the nearest 6to4 relay router.
1171: De-encapsulation of the packet is done via a 6to4-capable network interface,
1172: which then forwards the resulting IPv6 packet according to your routing setup
1173: (in case you have more than one machine connected on your 6to4 assigned
1174: network).
1175:
1176: To transmit IPv6 packets, the 6to4 router will encapsulate them inside IPv4
1177: packets; a system performing these functions is called a 6to4 border router.
1178: These packets have a default route to the *6to4 relay anycast prefix*. This
1179: anycast prefix will route the tunnel to a *6to4 relay router*.
1180:
1181: 
1182: **Request and reply can be routed via different gateways in 6to4**
1183:
1184: ### Security Considerations
1185:
1186: In contrast to the *configured tunnel* setup, you usually can't setup packet
1187: filters to block 6to4-packets from unauthorized sources, as this is exactly how
1188: (and why) 6to4 works at all. As such, malicious users can send packets with
1189: invalid/hazardous IPv6 payload. If you don't already filter on your border
1190: gateways anyways, packets with the following characteristics should not be
1191: allowed as valid 6to4 packets, and some firewalling seems to be justified for
1192: them:
1193:
1194: * unspecified IPv4 source/destination address: 0.0.0.0/8
1195: * loopback address in outer (v4) source/destination: 127.0.0.0/8
1196: * IPv4 multicast in source/destination: 224.0.0.0/4
1197: * limited broadcasts: 255.0.0.0/8
1198: * subnet broadcast address as source/destination: depends on your IPv4 setup
1199:
1200: The NetBSD
1201: [[!template id=man name="stf" section="4"]] manual
1202: page documents some common configuration mistakes intercepted by default by the
1203: KAME stack as well as some further advice on filtering, but keep in mind that
1204: because of the requirement of these filters, 6to4 is not perfectly secure.
1205: Still, if forged 6to4 packets become a problem, you can use IPsec authentication
1206: to ensure the IPv6 packets are not modified.
1207:
1208: ### Data Needed for 6to4 Setup
1209:
1210: In order to setup and configure IPv6 over 6to4, a few bits of configuration data
1211: must be known in advance. These are:
1212:
1213: * Your local IPv4 address. It can be determined using either the `ifconfig -a`
1214: or `netstat -i` commands on most Unix systems. If you use a NATing gateway or
1215: something, be sure to use the official, outside-visible address, not your
1216: private (10/8 or 192.168/16) one.
1217:
1218: We will use 62.224.57.114 as the local IPv4 address in our example.
1219:
1220: * Your local IPv6 address, as derived from the IPv4 address. See the previous
1221: figure ("6to4 derives an IPv6 from an IPv4 address") about how to do so.
1222:
1223: For our example, this is 2002:3ee0:3972:0001::1 (62.224.57.114 == 0x3ee03972,
1224: 0001::1 arbitrarily chosen).
1225:
1226: * The *6to4 IPv6 relay anycast address*. which is 2002:c058:6301::, or the IPv6
1227: address of a specific 6to4 relay router you want to use. The IPv6 address
1228: will do, as it also contains the IPv4 address in the usual 6to4 translation.
1229:
1230: ### Kernel Preparation
1231:
1232: To process 6to4 packets, the operating system kernel needs to know about them.
1233: For that a driver has to be compiled in that knows about 6to4, and how to handle
1234: it. In NetBSD 4.0 and newer, the driver is already present in GENERIC kernel
1235: configurations, so the procedure below is usually unnecessary.
1236:
1237: For a NetBSD kernel, put the following into your kernel config file to prepare
1238: it for using IPv6 and 6to4, e.g. on NetBSD use:
1239:
1240: options INET6 # IPv6
1241: pseudo-device stf # 6to4 IPv6 over IPv4 encapsulation
1242:
1243: Note that the
1244: [[!template id=man name="stf" section="4"]] device is
1245: not enabled by default on NetBSD releases older than 4.0. Rebuild your kernel,
1246: then reboot your system to use the new kernel. Please consult
1247: [[Compiling the kernel|guide/kernel]] for further information on configuring,
1248: building and installing a new kernel!
1249:
1250: ### 6to4 Setup
1251:
1252: This section describes the commands to setup 6to4. In short, the steps performed
1253: here are:
1254:
1255: 1. Configure interface
1256: 2. Set default route
1257: 3. Setup Router Advertisement, if wanted
1258:
1259: The first step in setting up 6to4 is creating the 6to4 interface and assigning
1260: an IPv6 address to it. This is achieved with the
1261: [[!template id=man name="ifconfig" section="8"]]
1262: command. Assuming the example configuration above, the commands for NetBSD are:
1263:
1264: # ifconfig stf0 create
1265: # ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias
1266:
1267: After configuring the 6to4 device with these commands, routing needs to be
1268: setup, to forward all tunneled IPv6 traffic to the 6to4 relay router. The best
1269: way to do this is by setting a default route, the command to do so is, for
1270: NetBSD:
1271:
1272: # route add -inet6 default 2002:c058:6301::
1273:
1274: Note that NetBSD's
1275: [[!template id=man name="stf" section="4"]] device
1276: determines the IPv4 address of the 6to4 uplink from the routing table. Using
1277: this feature, it is easy to setup your own 6to4 (uplink) gateway if you have an
1278: IPv6 uplink, e.g. via 6Bone.
1279:
1280: After these commands, you are connected to the IPv6-enabled world -
1281: Congratulations! Assuming name resolution is still done via IPv4, you can now
1282: ping an IPv6-site like www.kame.net or www6.NetBSD.org:
1283:
1284: # /sbin/ping6 www.kame.net
1285:
1286: As a final step in setting up IPv6 via 6to4, you will want to setup Router
1287: Advertisement if you have several hosts on your network. While it is possible to
1288: setup 6to4 on each node, doing so will result in very expensive routing from one
1289: node to the other - packets will be sent to the remote 6to4 gateway, which will
1290: then route the packets back to the neighbor node. Instead, setting up 6to4 on
1291: one machine and talking native IPv6 on-wire is the preferred method of handling
1292: things.
1293:
1294: The first step to do so is to assign an IPv6-address to your ethernet. In the
1295: following example we will assume subnet `2` of the IPv6-net is used for the
1296: local ethernet and the MAC address of the ethernet interface is
1297: 12:34:56:78:9a:bc, i.e. your local gateway's ethernet interface's IP address
1298: will be 2002:3ee0:3972:2:1234:56ff:fe78:9abc. Assign this address to your
1299: ethernet interface, e.g.
1300:
1301: # ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc
1302:
1303: Here, `ne0` is an example for your ethernet card interface. This will most
1304: likely be different for your setup, depending on what kind of card is used.
1305:
1306: Next thing that needs to be ensured for setting up the router is that it will
1307: actually forward packets from the local 6to4 device to the ethernet device and
1308: back. To enable IPv6 packet forwarding, set `ip6mode=router` in NetBSD's
1309: `/etc/rc.conf`, which will result in the `net.inet6.ip6.forwarding` sysctl being
1310: set to `1`:
1311:
1312: # sysctl -w net.inet6.ip6.forwarding=1
1313:
1314: 
1315: **Enabling packet forwarding is needed for a 6to4 router**
1316:
1317: To setup router advertisement on BSD, the file `/etc/rtadvd.conf` needs to be
1318: checked. It allows configuration of many things, but usually the default config
1319: of not containing any data is ok. With that default, IPv6 addresses found on all
1320: of the router's network interfaces will be advertised.
1321:
1322: After checking the router advertisement configuration is correct and IPv6
1323: forwarding is turned on, the daemon handling it can be started. Under NetBSD, it
1324: is called `rtadvd`. Start it up either manually (for testing it the first time)
1325: or via the system's startup scripts, and see all your local nodes automagically
1326: configure the advertised subnet address in addition to their already-existing
1327: link local address.
1328:
1329: # rtadvd
1330:
1331: ### Quickstart using pkgsrc/net/hf6to4
1332:
1333: So far, we have described how 6to4 works and how to set it up manually. For an
1334: automated way to make everything happen e.g. when going online, the 'hf6to4'
1335: package is convenient. It will determine your IPv6 address from the IPv4 address
1336: you got assigned by your provider, then set things up that you are connected.
1337:
1338: Steps to setup the pkgsrc/net/hf6to4 package are:
1339:
1340: 1. Install the package either by compiling it from pkgsrc, or by `pkg_add`'ing
1341: the 6to4-1.2 package.
1342:
1343: # cd /usr/pkgsrc/net/hf6to4
1344: # make install
1345:
1346: 2. Make sure you have the
1347: [[!template id=man name="stf" section="4"]]
1348: pseudo-device in your kernel, see above.
1349:
1350: 3. Configure the 'hf6to4' package. First, copy
1351: `/usr/pkg/share/examples/hf6to4/hf6to4.conf` to `/usr/pkg/etc/hf6to4.conf`,
1352: then adjust the variables. Note that the file is in /bin/sh syntax.
1353:
1354: # cd /usr/pkg/etc
1355: # cp ../share/examples/hf6to4/hf6to4.conf hf6to4.conf
1356: # vi hf6to4.conf
1357:
1358: Please see the
1359: [[!template id=man name="hf6to4" section="8"]]
1360: manpage for an explanation of all the variables you can set in
1361: `hf6to4.conf`. If you have dialup IP via PPP, and don't want to run Router
1362: Advertizing for other IPv6 machines on your home or office network, you
1363: don't need to configure anything. If you want to setup Router Advertising,
1364: you need to set the `in_if` to the internal (ethernet) interface, e.g.
1365:
1366: $in_if="rtk0"; # Inside (ethernet) interface
1367:
1368: 4. Now dial up, then start the 6to4 command manually:
1369:
1370: # /usr/pkg/sbin/hf6to4 start
1371:
1372: 5. After that, you should be connected, use
1373: [[!template id=man name="ping6" section="8"]]: to
1374: see if everything works:
1375:
1376: # ping6 www.NetBSD.org
1377: PING6(56=40+8+8 bytes) 2002:d954:110b:1::1 --> 2001:4f8:4:7:2e0:81ff:fe52:9a6b
1378: 16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=0 hlim=60 time=250.234 ms
1379: 16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=1 hlim=60 time=255.652 ms
1380: 16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=2 hlim=60 time=251.237 ms
1381: ^C
1382: --- www.NetBSD.org ping6 statistics ---
1383: 3 packets transmitted, 3 packets received, 0.0% packet loss
1384: round-trip min/avg/max/std-dev = 250.234/252.374/255.652/2.354 ms
1385:
1386: # traceroute6 www.NetBSD.org
1387: traceroute6 to www.NetBSD.org (2001:4f8:4:7:2e0:81ff:fe52:9a6b)
1388: from 2002:d954:110b:1::1, 64 hops max, 12 byte packets
1389: 1 2002:c25f:6cbf:1::1 66.31 ms 66.382 ms 69.062 ms
1390: 2 nr-erl1.6win.dfn.de 76.134 ms * 76.87 ms
1391: 3 nr-fra1.6win.dfn.de 76.371 ms 80.709 ms 79.482 ms
1392: 4 dfn.de6.de.6net.org 92.763 ms 90.863 ms 94.322 ms
1393: 5 de.nl6.nl.6net.org 116.115 ms 93.463 ms 96.331 ms
1394: 6 nl.uk6.uk.6net.org 103.347 ms 99.334 ms 100.803 ms
1395: 7 uk1.uk61.uk.6net.org 99.481 ms 100.421 ms 100.119 ms
1396: 8 2001:798:28:300::2 89.711 ms 90.435 ms 90.035 ms
1397: 9 ge-1-0-0-2.r20.londen03.uk.bb.verio.net 179.671 ms 185.141 ms 185.86 ms
1398: 10 p16-0-0-0.r81.nycmny01.us.bb.verio.net 177.067 ms 179.086 ms 178.05 ms
1399: 11 p16-1-1-3.r20.nycmny01.us.bb.verio.net 178.04 ms 179.727 ms 184.165 ms
1400: 12 p16-0-1-1.r20.mlpsca01.us.bb.verio.net 249.856 ms 247.476 ms 249.012 ms
1401: 13 p64-0-0-0.r21.snjsca04.us.bb.verio.net 239.691 ms 241.404 ms 240.998 ms
1402: 14 p64-0-0-0.r21.plalca01.us.bb.verio.net 247.541 ms 246.661 ms 246.359 ms
1403: 15 xe-0-2-0.r20.plalca01.us.bb.verio.net 240.987 ms 239.056 ms 241.251 ms
1404: 16 ge-6-1.a01.snfcca05.us.ra.verio.net 240.868 ms 241.29 ms 242.337 ms
1405: 17 fa-5-2.a01.snfcca05.us.ce.verio.net 249.477 ms 250.4 ms 256.035 ms
1406: 18 2001:4f8:4:7:2e0:81ff:fe52:9a6b 268.164 ms 252.97 ms 252.366 ms
1407:
1408: Please note that `traceroute6` shows the v6 hops only, any underlying
1409: tunnels are invisible and thus not displayed.
1410:
1411: 6. If this works, you can put the following lines into your `/etc/ppp/ip-up`
1412: script to run the command each time you go online:
1413:
1414: logger -p user.info -t ip-up Configuring 6to4 IPv6
1415: /usr/pkg/sbin/hf6to4 stop
1416: /usr/pkg/sbin/hf6to4 start
1417:
1418: 7. If you want to route IPv6 for your LAN, you can instruct `6to4.pl` to setup
1419: Router Advertising for you too:
1420:
1421: # /usr/pkg/sbin/hf6to4 rtadvd-start
1422:
1423: You can put that command into `/etc/ppp/ip-up` as well to make it permanent.
1424:
1425: 8. If you have changed `/etc/ppp/ip-up` to setup 6to4 automatically, you will
1426: most likely want to change `/etc/ppp/ip-down` too, to shut it down when you
1427: go offline. Here's what to put into `/etc/ppp/ip-down`:
1428:
1429: logger -p user.info -t ip-down Shutting down 6to4 IPv6
1430: /usr/pkg/sbin/hf6to4 rtadvd-stop
1431: /usr/pkg/sbin/hf6to4 stop
1432:
1433: ### Known 6to4 Relay Routers
1434:
1435: It is normally not necessary to pick a specific 6to4 relay router, but if
1436: necessary, you may find a list of known working routers at
1437: [http://www.kfu.com/\~nsayer/6to4/](http://www.kfu.com/~nsayer/6to4/). In tests,
1438: only 6to4.kfu.com and 6to4.ipv6.microsoft.com were found working. Cisco has one
1439: that requires registration, see
1440: [http://www.cisco.com/ipv6/](http://www.cisco.com/ipv6/).
1441:
1442: There's also an experimental 6to4 server located in Germany,
1443: 6to4.ipv6.fh-regensburg.de. This server runs under NetBSD 1.6 and was setup
1444: using the configuration steps described above. The whole configuration of the
1445: machine can be seen at
1446: [http://www.feyrer.de/IPv6/netstart.local](http://www.feyrer.de/IPv6/netstart.local).
1447:
1448: ### Tunneling 6to4 through an IPFilter firewall
1449:
1450: The 6to4 protocol encapsulates IPv6 packets in IPv4, and gives them their own IP
1451: type, which most firewalls block as unknown, as their payload type is directly
1452: `TCP`, `UDP` or `ICMP`. Usually, you want to setup your 6to4 gateway on the same
1453: machine that is directly connected to the (IPv4) internet, and which usually
1454: runs the firewall. For the case that you want to run your 6to4 gateway behind a
1455: firewall, you need to drill a hole into the firewall, to let 6to4 packets
1456: through. Here is how to do this!
1457:
1458: The example assumes that you use the `ppp0` interface on your firewall to
1459: connect to the Internet.
1460:
1461: Put the following lines into `/etc/ipf.conf` to allow your IPFilter firewall let
1462: all 6to4 packets pass (lines broken with `\` due to space restrictions; please
1463: put them lines continued that way all in one line):
1464:
1465: # Handle traffic by different rulesets
1466: block in quick on ppp0 all head 1
1467: block out quick on ppp0 all head 2
1468:
1469: ### Incoming packets:
1470: # allow some IPv4:
1471: pass in log quick on ppp0 proto tcp from any to any \
1472: port = www flags S keep state keep frags group 1
1473: pass in quick on ppp0 proto tcp from any to any \
1474: port = ssh keep state group 1
1475: pass in quick on ppp0 proto tcp from any to any \
1476: port = mail keep state group 1
1477: pass in log quick on ppp0 proto tcp from any to any \
1478: port = ftp keep state group 1
1479: pass in log quick on ppp0 proto tcp from any to any \
1480: port = ftp-data keep state group 1
1481: pass in log quick on ppp0 proto icmp from any to any group 1
1482: # allow all IPv6:
1483: pass in quick on ppp0 proto ipv6 from any to any group 1
1484: pass in log quick on ppp0 proto ipv6-route from any to any group 1
1485: pass in log quick on ppp0 proto ipv6-frag from any to any group 1
1486: pass in log quick on ppp0 proto ipv6-icmp from any to any group 1
1487: pass in log quick on ppp0 proto ipv6-nonxt from any to any group 1
1488: pass in log quick on ppp0 proto ipv6-opts from any to any group 1
1489: # block rest:
1490: blockin log quick on ppp0 all group 1
1491:
1492: ### Outgoing packets:
1493: # allow usual stuff:
1494: pass out quick on ppp0 proto tcp from any to any flags S \
1495: keep state keep frags group 2
1496: pass out quick on ppp0 proto udp from any to any \
1497: keep state keep frags group 2
1498: pass out quick on ppp0 proto icmp from any to any \
1499: keep state group 2
1500: # allow all IPv6:
1501: pass out quick on ppp0 proto ipv6 from any to any group 2
1502: pass out log quick on ppp0 proto ipv6-route from any to any group 2
1503: pass out log quick on ppp0 proto ipv6-frag from any to any group 2
1504: pass out log quick on ppp0 proto ipv6-icmp from any to any group 2
1505: pass out log quick on ppp0 proto ipv6-nonxt from any to any group 2
1506: pass out log quick on ppp0 proto ipv6-opts from any to any group 2
1507: # block rest:
1508: block out log quick on ppp0 all group 2
1509:
1510: Now any host on your network can send (the `out` rules) and receive (the `in`
1511: rules) v4-encapsulated IPv6 packets, allowing setup of any of them as a 6to4
1512: gateway. Of course you only want to do this on one host and use native IPv6
1513: between your hosts, and you may also want to enforce this with more restrictive
1514: rulesets, please see
1515: [[!template id=man name="ipf.conf" section="5"]]
1516: for more information on IPFilter rules.
1517:
1518: After your firewall lets pass encapsulated IPv6 packets, you may want to set up
1519: your 6to4 gateway to monitor the IPv6 traffic, or even restrict it. To do so,
1520: you need to setup IPFilter on your 6to4 gateway as well. For basic monitoring,
1521: enable `ipfilter=yes` in `/etc/rc.conf` and put the following into
1522: `/etc/ipf6.conf`:
1523:
1524: pass in log quick on stf0 from any to any
1525: pass out log quick on stf0 from any to any
1526:
1527: This logs all (IPv6) traffic going in and out of your `stf0` tunneling
1528: interface. You can add filter rules as well if needed.
1529:
1530: If you are more interested in traffic stats than a general overview of your
1531: network traffic, using MRTG in conjunction with the `net-snmp` package is
1532: recommended instead of analyzing IPFilter log files.
1533:
1534: ### Conclusion & Further Reading
1535:
1536: Compared to where IPv4 is today, IPv6 is still in its early steps. It is
1537: working, there are all sort of services and clients available, only the userbase
1538: is missing. It is hoped the information provided here helps people better
1539: understand what IPv6 is, and to start playing with it.
1540:
1541: A few links should be mentioned here for interested parties:
1542:
1543: * An example script to setup 6to4 on BSD based machines is available at
1544: <http://www.NetBSD.org/packages/net/hf6to4/>. The script determines your IPv6
1545: address and sets up 6to4 and (if wanted) router advertising. It was designed
1546: to work in dialup setups with changing IPv4 addresses.
1547:
1548: * Given that there isn't a standard for IPv6 in Linux land today, there are
1549: different setup instructions for most distributions. The setup of IPv6 on
1550: Debian GNU/Linux can be found at
1551: [http://people.debian.org/\~csmall/ipv6/setup.html](http://people.debian.org/~csmall/ipv6/setup.html).
1552:
1553: * The BSD Unix implementations have their own IPv6 documentation each,
1554: interesting URLs are <http://www.NetBSD.org/docs/network/ipv6/> for NetBSD,
1555: <http://www.freebsd.org/doc/en\_US.ISO8859-1/books/handbook/network-ipv6.html>
1556: for FreeBSD.
1557:
1558: * Projects working on implementing IPv6 protocol stacks for free Unix like
1559: operating systems are KAME for BSD and USAGI for Linux. Their web sites can
1560: be found at <http://www.kame.net/> and <http://www.linux-ipv6.org/>. A list
1561: of host and router implementations can be found at
1562: <http://playground.sun.com/pub/ipng/html/ipng-implementations.html>.
1563:
1564: * Besides the official RFC archive at <ftp://ftp.isi.edu/in-notes>, information
1565: on IPv6 can be found at several web sites. First and foremost, the 6Bone's
1566: web page at <http://www.6bone.net/> must be mentioned. 6Bone was started as
1567: the testbed for IPv6, and is now an important part of the IPv6-connected
1568: world. Other web pages that contain IPv6-related contents include
1569: <http://www.ipv6.org/>, <http://playground.sun.com/pub/ipng/html/> and
1570: <http://www.ipv6forum.com/>. Most of these sites carry further links - be
1571: sure to have a look!
1572:
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb
![[BACK]](/icons/back.gif){kind=icon}
Return to net-practice.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / guide