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