|
version 1.7, 2019/09/02 20:48:36
|
version 1.8, 2021/04/12 13:15:03
|
|
Line 1
|
Line 1
|
| **Contents** |
This page was moved to: |
| |
[The NetBSD Guide - Setting up TCP/IP on NetBSD in practice](//www.NetBSD.org/docs/guide/en/chap-net-practice.html) |
| [[!toc levels=3]] |
|
| |
|
| # Setting up TCP/IP on NetBSD in practice |
|
| |
|
| ## A walk through the kernel configuration |
|
| |
|
| Before we dive into configuring various aspects of network setup, we want to |
|
| walk through the necessary bits that have to or can be present in the kernel. |
|
| See [[Compiling the kernel|guide/kernel]] for more details on compiling the |
|
| kernel, we will concentrate on the configuration of the kernel here. We will |
|
| take the i386/GENERIC config file as an example here. Config files for other |
|
| platforms should contain similar information, the comments in the config files |
|
| give additional hints. Besides the information given here, each kernel option is |
|
| also documented in the |
|
| [[!template id=man name="options" section="4"]] |
|
| manpage, and there is usually a manpage for each driver too, e.g. |
|
| [[!template id=man name="tlp" section="4"]]. |
|
| |
|
| The first line of each config file shows the version. It can be used to compare |
|
| against other versions via CVS, or when reporting bugs. |
|
| |
|
| options NTP # NTP phase/frequency locked loop |
|
| |
|
| If you want to run the Network Time Protocol (NTP), this option can be enabled |
|
| for maximum precision. If the option is not present, NTP will still work. See |
|
| [[!template id=man name="ntpd" section="8"]] for |
|
| more information. |
|
| |
|
| file-system NFS # Network File System client |
|
| |
|
| If you want to use another machine's hard disk via the Network File System |
|
| (NFS), this option is needed. The guide article about the |
|
| [[Network File System|guide/net-services#nfs]] gives more information on NFS. |
|
| |
|
| options NFSSERVER # Network File System server |
|
| |
|
| This option includes the server side of the NFS remote file sharing protocol. |
|
| Enable if you want to allow other machines to use your hard disk. The mentioned |
|
| article in the guide about [[NFS|guide/net-services#nfs]] contains more |
|
| information on NFS. |
|
| |
|
| #options GATEWAY # packet forwarding |
|
| |
|
| If you want to setup a router that forwards packets between networks or network |
|
| interfaces, setting this option is needed. It doesn't only switch on packet |
|
| forwarding, but also increases some buffers. See |
|
| [[!template id=man name="options" section="4"]] |
|
| for details. |
|
| |
|
| options INET # IP + ICMP + TCP + UDP |
|
| |
|
| This enables the TCP/IP code in the kernel. Even if you don't want/use |
|
| networking, you will still need this for machine-internal communication of |
|
| subsystems like the X Window System. See |
|
| [[!template id=man name="inet" section="4"]] for |
|
| more details. |
|
| |
|
| options INET6 # IPV6 |
|
| |
|
| If you want to use IPv6, this is your option. If you don't want IPv6, which is |
|
| part of NetBSD since the 1.5 release, you can remove/comment out that option. |
|
| See the |
|
| [[!template id=man name="inet6" section="4"]] |
|
| manpage and [[Next generation Internet protocol - |
|
| IPv6|guide/net-intro#ipv6-intro]] for more information on the next generation |
|
| Internet protocol. |
|
| |
|
| #options IPSEC # IP security |
|
| |
|
| Includes support for the IPsec protocol, including key and policy management, |
|
| authentication and compression. This option can be used without the previous |
|
| option INET6, if you just want to use IPsec with IPv4, which is possible. See |
|
| [[!template id=man name="ipsec" section="4"]] for |
|
| more information. |
|
| |
|
| #options IPSEC_ESP # IP security (encryption part; define w/IPSEC) |
|
| |
|
| This option is needed in addition to IPSEC if encryption is wanted in IPsec. |
|
| |
|
| #options MROUTING # IP multicast routing |
|
| |
|
| If multicast services like the MBone services should be routed, this option |
|
| needs to be included. Note that the routing itself is controlled by the |
|
| [[!template id=man name="mrouted" section="8"]] |
|
| daemon. |
|
| |
|
| options ISO,TPIP # OSI |
|
| #options EON # OSI tunneling over IP |
|
| |
|
| These options include the OSI protocol stack, which was said for a long time to |
|
| be the future of networking. It's mostly history these days. :-) See the |
|
| [[!template id=man name="iso" section="4"]] manpage |
|
| for more information. |
|
| |
|
| options NETATALK # AppleTalk networking protocols |
|
| |
|
| Include support for the AppleTalk protocol stack. Userland server programs are |
|
| needed to make use of that. See pkgsrc/net/netatalk and pkgsrc/net/netatalk-asun |
|
| for such packages. More information on the AppleTalk protocol and protocol stack |
|
| are available in the |
|
| [[!template id=man name="atalk" section="4"]] |
|
| manpage. |
|
| |
|
| options PPP_BSDCOMP # BSD-Compress compression support for PPP |
|
| options PPP_DEFLATE # Deflate compression support for PPP |
|
| options PPP_FILTER # Active filter support for PPP (requires bpf) |
|
| |
|
| These options tune various aspects of the Point-to-Point protocol. The first two |
|
| determine the compression algorithms used and available, while the third one |
|
| enables code to filter some packets. |
|
| |
|
| options PFIL_HOOKS # pfil(9) packet filter hooks |
|
| options IPFILTER_LOG # ipmon(8) log support |
|
| |
|
| These options enable firewalling in NetBSD, using IPFilter. See the |
|
| [[!template id=man name="ipf" section="4"]] and |
|
| [[!template id=man name="ipf" section="8"]] manpages |
|
| for more information on operation of IPFilter, and [[Configuring the |
|
| gateway/firewall|guide/net-practice#ipnat-configuring-gateway]] for a |
|
| configuration example. |
|
| |
|
| # Compatibility with 4.2BSD implementation of TCP/IP. Not recommended. |
|
| #options TCP_COMPAT_42 |
|
| |
|
| This option is only needed if you have machines on the network that still run |
|
| 4.2BSD or a network stack derived from it. If you've got one or more |
|
| 4.2BSD-systems on your network, you've to pay attention to set the right |
|
| broadcast-address, as 4.2BSD has a bug in its networking code, concerning the |
|
| broadcast address. This bug forces you to set all host-bits in the |
|
| broadcast-address to `0`. The `TCP_COMPAT_42` option helps you ensuring this. |
|
| |
|
| options NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM |
|
| |
|
| These options enable lookup of data via DHCP or the BOOTPARAM protocol if the |
|
| kernel is told to use a NFS root file system. See the |
|
| [[!template id=man name="diskless" section="8"]] |
|
| manpage for more information. |
|
| |
|
| # Kernel root file system and dump configuration. |
|
| config netbsd root on ? type ? |
|
| #config netbsd root on sd0a type ffs |
|
| #config netbsd root on ? type nfs |
|
| |
|
| These lines tell where the kernel looks for its root file system, and which |
|
| filesystem type it is expected to have. If you want to make a kernel that uses a |
|
| NFS root filesystem via the tlp0 interface, you can do this with |
|
| |
|
| root on tlp0 type nfs |
|
| |
|
| If a `?` is used instead of a device/type, the kernel tries to |
|
| figure one out on its own. |
|
| |
|
| # ISA serial interfaces |
|
| com0 at isa? port 0x3f8 irq 4 # Standard PC serial ports |
|
| com1 at isa? port 0x2f8 irq 3 |
|
| com2 at isa? port 0x3e8 irq 5 |
|
| |
|
| If you want to use PPP or SLIP, you will need some serial (com) interfaces. |
|
| Others with attachment on USB, PCMCIA or PUC will do as well. |
|
| |
|
| # Network Interfaces |
|
| |
|
| This rather long list contains all sorts of network drivers. Please pick the one |
|
| that matches your hardware, according to the comments. For most drivers, there's |
|
| also a manual page available, e.g. |
|
| [[!template id=man name="tlp" section="4"]], |
|
| [[!template id=man name="ne" section="4"]], etc. |
|
| |
|
| # MII/PHY support |
|
| |
|
| This section lists media independent interfaces for network cards. Pick one that |
|
| matches your hardware. If in doubt, enable them all and see what the kernel |
|
| picks. See the |
|
| [[!template id=man name="mii" section="4"]] manpage |
|
| for more information. |
|
| |
|
| # USB Ethernet adapters |
|
| aue* at uhub? port ? # ADMtek AN986 Pegasus based adapters |
|
| cue* at uhub? port ? # CATC USB-EL1201A based adapters |
|
| kue* at uhub? port ? # Kawasaki LSI KL5KUSB101B based adapters |
|
| |
|
| USB-ethernet adapters only have about 2MBit/s bandwidth, but they are very |
|
| convenient to use. Of course this needs other USB related options which we won't |
|
| cover here, as well as the necessary hardware. See the corresponding manpages |
|
| for more information. |
|
| |
|
| # network pseudo-devices |
|
| pseudo-device bpfilter 8 # Berkeley packet filter |
|
| |
|
| This pseudo-device allows sniffing packets of all sorts. It's needed for |
|
| tcpdump, but also rarpd and some other applications that need to know about |
|
| network traffic. See |
|
| [[!template id=man name="bpf" section="4"]] for more |
|
| information. |
|
| |
|
| pseudo-device ipfilter # IP filter (firewall) and NAT |
|
| |
|
| This one enables the IPFilter's packet filtering kernel interface used for |
|
| firewalling, NAT (IP Masquerading) etc. See |
|
| [[!template id=man name="ipf" section="4"]] and |
|
| [Configuring the gateway/firewall|guide/net-practice#ipnat-configuring-gateway]] |
|
| for more information. |
|
| |
|
| pseudo-device loop # network loopback |
|
| |
|
| This is the `lo0` software loopback network device which is used by some |
|
| programs these days, as well as for routing things. It should not be omitted. |
|
| See [[!template id=man name="lo" section="4"]] for |
|
| more details. |
|
| |
|
| pseudo-device ppp 2 # Point-to-Point Protocol |
|
| |
|
| If you want to use PPP either over a serial interface or ethernet (PPPoE), you |
|
| will need this option. See |
|
| [[!template id=man name="ppp" section="4"]] for |
|
| details on this interface. |
|
| |
|
| pseudo-device sl 2 # Serial Line IP |
|
| |
|
| Serial Line IP is a simple encapsulation for IP over (well :) serial lines. It |
|
| does not include negotiation of IP addresses and other options, which is the |
|
| reason that it's not in widespread use today any more. See |
|
| [[!template id=man name="sl" section="4"]]. |
|
| |
|
| pseudo-device strip 2 # Starmode Radio IP (Metricom) |
|
| |
|
| If you happen to have one of the old Metricom Ricochet packet radio wireless |
|
| network devices, use this pseudo-device to use it. See the |
|
| [[!template id=man name="strip" section="4"]] |
|
| manpage for detailed information. |
|
| |
|
| pseudo-device tun 2 # network tunneling over tty |
|
| |
|
| This network device can be used to tunnel network packets to a device file, |
|
| `/dev/tun*`. Packets routed to the tun0 interface can be read from `/dev/tun0`, |
|
| and data written to `/dev/tun0` will be sent out the tun0 network interface. |
|
| This can be used to implement e.g. QoS routing in userland. See |
|
| [[!template id=man name="tun" section="4"]] for |
|
| details. |
|
| |
|
| pseudo-device gre 2 # generic L3 over IP tunnel |
|
| |
|
| The GRE encapsulation can be used to tunnel arbitrary layer 3 packets over IP, |
|
| e.g. to implement VPNs. See |
|
| [[!template id=man name="gre" section="4"]] for more. |
|
| |
|
| pseudo-device gif 4 # IPv[46] over IPv[46] tunnel (RFC 1933) |
|
| |
|
| Using the GIF interface allows to tunnel e.g. IPv6 over IPv4, which can be used |
|
| to get IPv6 connectivity if no IPv6-capable uplink (ISP) is available. Other |
|
| mixes of operations are possible, too. See the |
|
| [[!template id=man name="gif" section="4"]] manpage |
|
| for some examples. |
|
| |
|
| #pseudo-device faith 1 # IPv[46] tcp relay translation i/f |
|
| |
|
| The faith interface captures IPv6 TCP traffic, for implementing userland |
|
| IPv6-to-IPv4 TCP relays e.g. for protocol transitions. See the |
|
| [[!template id=man name="faith" section="4"]] |
|
| manpage for more details on this device. |
|
| |
|
| #pseudo-device stf 1 # 6to4 IPv6 over IPv4 encapsulation |
|
| |
|
| This adds a network device that can be used to tunnel IPv6 over IPv4 without |
|
| setting up a configured tunnel before. The source address of outgoing packets |
|
| contains the IPv4 address, which allows routing replies back via IPv4. See the |
|
| [[!template id=man name="stf" section="4"]] manpage |
|
| and [IPv6 Connectivity & Transition via 6to4|guide/net-practice#ipv6-6to4]] for |
|
| more details. |
|
| |
|
| pseudo-device vlan # IEEE 802.1q encapsulation |
|
| |
|
| This interface provides support for IEEE 802.1Q Virtual LANs, which allows |
|
| tagging Ethernet frames with a `vlan` ID. Using properly configured switches |
|
| (that also have to support VLAN, of course), this can be used to build virtual |
|
| LANs where one set of machines doesn't see traffic from the other (broadcast and |
|
| other). The |
|
| [[!template id=man name="vlan" section="4"]] manpage |
|
| tells more about this. |
|
| |
|
| ## Overview of the network configuration files |
|
| |
|
| The following is a list of the files used to configure the network. The usage of |
|
| these files, some of which have already been met the first chapters, will be |
|
| described in the following sections. |
|
| |
|
| * `/etc/hosts` -- Local hosts database file. Each line contains information |
|
| regarding a known host and contains the internet address, the host's name and |
|
| the aliases. Small networks can be configured using only the hosts file, |
|
| without a *name server*. |
|
| |
|
| * `/etc/resolv.conf` -- This file specifies how the routines which provide |
|
| access to the Internet Domain Name System should operate. Generally it |
|
| contains the addresses of the name servers. |
|
| |
|
| * `/etc/ifconfig.xxx` -- This file is used for the automatic configuration of |
|
| the network card at boot. |
|
| |
|
| * `/etc/mygate` -- Contains the IP address of the gateway. |
|
| |
|
| * `/etc/nsswitch.conf` -- Name service switch configuration file. It controls |
|
| how a process looks up various databases containing information regarding |
|
| hosts, users, groups, etc. Specifically, this file defines the order to look |
|
| up the databases. For example, the line: |
|
| |
|
| hosts: files dns |
|
| |
|
| specifies that the hosts database comes from two sources, *files* (the local |
|
| `/etc/hosts` file) and *DNS*, (the Internet Domain Name System) and that the |
|
| local files are searched before the DNS. |
|
| |
|
| It is usually not necessary to modify this file. |
|
| |
|
| ## Connecting to the Internet with a modem |
|
| |
|
| There are many types of Internet connections: this section explains how to |
|
| connect to a provider using a modem over a telephone line using the PPP |
|
| protocol, a very common setup. In order to have a working connection, the |
|
| following steps must be done: |
|
| |
|
| 1. Get the necessary information from the provider. |
|
| 2. Edit the file `/etc/resolv.conf` and check `/etc/nsswitch.conf`. |
|
| 3. Create the directories `/etc/ppp` and `/etc/ppp/peers` if they don't exist. |
|
| 4. Create the connection script, the chat file and the pppd options file. |
|
| 5. Created the user-password authentication file. |
|
| |
|
| Judging from the previous list it looks like a complicated procedure that |
|
| requires a lot of work. Actually, the single steps are very easy: it's just a |
|
| matter of modifying, creating or simply checking some small text files. In the |
|
| following example it will be assumed that the modem is connected to the second |
|
| serial port `/dev/tty01` (COM2 in DOS). |
|
| |
|
| A few words on the difference between `com`, `COM` and `tty`. For NetBSD, `com` |
|
| is the name of the serial port driver (the one that is displayed by `dmesg`) and |
|
| `tty` is the name of the port. Since numbering starts at 0, `com0` is the driver |
|
| for the first serial port, named `tty00`. In the DOS world, instead, `COM1` |
|
| refers to the first serial port (usually located at 0x3f8), `COM2` to the |
|
| second, and so on. Therefore `COM1` (DOS) corresponds to `/dev/tty00` (NetBSD). |
|
| |
|
| Besides external modems connected to COM ports (using `/dev/tty0[012]` on i386, |
|
| `/dev/tty[ab]` on sparc, ...) modems on USB (`/dev/ttyU*`) and pcmcia/cardbus |
|
| (`/dev/tty0[012]`) can be used. |
|
| |
|
| ### Getting the connection information |
|
| |
|
| The first thing to do is ask the provider the necessary information for the |
|
| connection, which means: |
|
| |
|
| * The phone number of the nearest POP. |
|
| * The authentication method to be used. |
|
| * The username and password for the connection. |
|
| * The IP addresses of the name servers. |
|
| |
|
| ### resolv.conf and nsswitch.conf |
|
| |
|
| The `/etc/resolv.conf` file must be configured using the information supplied by |
|
| the provider, especially the addresses of the DNS. In this example the two DNS |
|
| will be `194.109.123.2` and `191.200.4.52`: |
|
| |
|
| nameserver 194.109.123.2 |
|
| nameserver 191.200.4.52 |
|
| |
|
| And now an example of the `/etc/nsswitch.conf` file: |
|
| |
|
| # /etc/nsswitch.conf |
|
| group: compat |
|
| group_compat: nis |
|
| hosts: files dns |
|
| netgroup: files [notfound=return] nis |
|
| networks: files |
|
| passwd: compat |
|
| passwd_compat: nis |
|
| shells: files |
|
| |
|
| The defaults of doing hostname lookups via `/etc/hosts` followed by the DNS |
|
| works fine and there's usually no need to modify this. |
|
| |
|
| ### Creating the directories for pppd |
|
| |
|
| The directories `/etc/ppp` and `/etc/ppp/peers` will contain the configuration |
|
| files for the PPP connection. After a fresh install of NetBSD they don't exist |
|
| and must be created (chmod 700). |
|
| |
|
| # mkdir /etc/ppp |
|
| # mkdir /etc/ppp/peers |
|
| |
|
| ### Connection script and chat file |
|
| |
|
| The connection script will be used as a parameter on the pppd command line; it |
|
| is located in `/etc/ppp/peers` and has usually the name of the provider. For |
|
| example, if the provider's name is BigNet and your user name for the connection |
|
| to the provider is alan, an example connection script could be: |
|
| |
|
| # /etc/ppp/peers/bignet |
|
| connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat' |
|
| noauth |
|
| user alan |
|
| remotename bignet.it |
|
| |
|
| In the previous example, the script specifies a *chat file* to be used for the |
|
| connection. The options in the script are detailed in the |
|
| [[!template id=man name="pppd" section="8"]] man |
|
| page. |
|
| |
|
| ### Note |
|
| |
|
| If you are experiencing connection problems, add the following two lines to the |
|
| connection script |
|
| |
|
| debug |
|
| kdebug 4 |
|
| |
|
| You will get a log of the operations performed when the system tries to connect. |
|
| See [[!template id=man name="pppd" section="8"]], |
|
| [[!template id=man name="syslog.conf" section="5"]]. |
|
| |
|
| The connection script calls the chat application to deal with the physical |
|
| connection (modem initialization, dialing, ...) The parameters to chat can be |
|
| specified inline in the connection script, but it is better to put them in a |
|
| separate file. If, for example, the telephone number of the POP to call is |
|
| `02 99999999`, an example chat script could be: |
|
| |
|
| # /etc/ppp/peers/bignet.chat |
|
| ABORT BUSY |
|
| ABORT "NO CARRIER" |
|
| ABORT "NO DIALTONE" |
|
| '' ATDT0299999999 |
|
| CONNECT '' |
|
| |
|
| *Note*: If you have problems with the chat file, you can try connecting manually |
|
| to the POP with the |
|
| [[!template id=man name="cu" section="1"]] program and |
|
| verify the exact strings that you are receiving. |
|
| |
|
| ### Authentication |
|
| |
|
| During authentication each of the two systems verifies the identity of the other |
|
| system, although in practice you are not supposed to authenticate the provider, |
|
| but only to be verified by him, using one of the following methods: |
|
| |
|
| * PAP/CHAP |
|
| * login |
|
| |
|
| Most providers use a PAP/CHAP authentication. |
|
| |
|
| #### PAP/CHAP authentication |
|
| |
|
| The authentication information (speak: password) is stored in the |
|
| `/etc/ppp/pap-secrets` for PAP and in `/etc/ppp/chap-secrets` for CHAP. The |
|
| lines have the following format: |
|
| |
|
| user * password |
|
| |
|
| For example: |
|
| |
|
| alan * pZY9o |
|
| |
|
| For security reasons the `pap-secrets` and `chap-secrets` files should be owned |
|
| by root and have permissions 600. |
|
| |
|
| # chown root /etc/ppp/pap-secrets |
|
| # chown root /etc/ppp/chap-secrets |
|
| # chmod 600 /etc/ppp/pap-secrets |
|
| # chmod 600 /etc/ppp/chap-secrets |
|
| |
|
| #### Login authentication |
|
| |
|
| This type of authentication is not widely used today; if the provider uses login |
|
| authentication, user name and password must be supplied in the chat file instead |
|
| of the PAP/CHAP files, because the chat file simulates an interactive login. In |
|
| this case, set up appropriate permissions for the chat file. |
|
| |
|
| The following is an example chat file with login authentication: |
|
| |
|
| # /etc/ppp/peers/bignet.chat |
|
| ABORT BUSY |
|
| ABORT "NO CARRIER" |
|
| ABORT "NO DIALTONE" |
|
| '' ATDT0299999999 |
|
| CONNECT '' |
|
| TIMEOUT 50 |
|
| ogin: alan |
|
| ssword: pZY9o |
|
| |
|
| ### pppd options |
|
| |
|
| The only thing left to do is the creation of the pppd options file, which is |
|
| `/etc/ppp/options` (chmod 644): |
|
| |
|
| /dev/tty01 |
|
| lock |
|
| crtscts |
|
| 57600 |
|
| modem |
|
| defaultroute |
|
| noipdefault |
|
| |
|
| Check the |
|
| [[!template id=man name="pppd" section="8"]] man |
|
| page for the meaning of the options. |
|
| |
|
| ### Testing the modem |
|
| |
|
| Before activating the link it is a good idea to make a quick modem test, in |
|
| order to verify that the physical connection and the communication with the |
|
| modem works. For the test the |
|
| [[!template id=man name="cu" section="1"]] program can |
|
| be used, as in the following example. |
|
| |
|
| 1. Create the file `/etc/uucp/port` with the following lines: |
|
| |
|
| type modem |
|
| port modem |
|
| device /dev/tty01 |
|
| speed 115200 |
|
| |
|
| (substitute the correct device in place of `/dev/tty01`). |
|
| |
|
| 2. Write the command `cu -p modem` to start sending commands to the modem. For |
|
| example: |
|
| |
|
| # cu -p modem |
|
| Connected. |
|
| ATZ |
|
| OK |
|
| ~. |
|
| |
|
| Disconnected. |
|
| # |
|
| |
|
| In the previous example the reset command (ATZ) was sent to the modem, which |
|
| replied with OK: the communication works. To exit |
|
| [[!template id=man name="cu" section="1"]], write |
|
| `~` (tilde) followed by `.` (dot), as in the example. |
|
| |
|
| If the modem doesn't work, check that it is connected to the correct port (i.e. |
|
| you are using the right port with |
|
| [[!template id=man name="cu" section="1"]]. Cables are |
|
| a frequent cause of trouble, too. |
|
| |
|
| When you start |
|
| [[!template id=man name="cu" section="1"]] and a |
|
| message saying `Permission denied` appears, check who is the owner of the |
|
| `/dev/tty##` device, it must be "uucp". For example: |
|
| |
|
| $ ls -l /dev/tty00 |
|
| crw------- 1 uucp wheel 8, 0 Mar 22 20:39 /dev/tty00 |
|
| |
|
| If the owner is root, the following happens: |
|
| |
|
| $ ls -l /dev/tty00 |
|
| crw------- 1 root wheel 8, 0 Mar 22 20:39 /dev/tty00 |
|
| $ cu -p modem |
|
| cu: open (/dev/tty00): Permission denied |
|
| cu: All matching ports in use |
|
| |
|
| ### Activating the link |
|
| |
|
| At last everything is ready to connect to the provider with the following |
|
| command: |
|
| |
|
| # pppd call bignet |
|
| |
|
| where `bignet` is the name of the already described connection script. To see |
|
| the connection messages of pppd, give the following command: |
|
| |
|
| # tail -f /var/log/messages |
|
| |
|
| To disconnect, do a `kill -HUP` of `pppd`. |
|
| |
|
| # pkill -HUP pppd |
|
| |
|
| ### Using a script for connection and disconnection |
|
| |
|
| When the connection works correctly, it's time to write a couple of scripts to |
|
| avoid repeating the commands every time. These two scripts can be named, for |
|
| example, `ppp-start` and `ppp-stop`. |
|
| |
|
| `ppp-start` is used to connect to the provider: |
|
| |
|
| #!/bin/sh |
|
| MODEM=tty01 |
|
| POP=bignet |
|
| if [ -f /var/spool/lock/LCK..$MODEM ]; then |
|
| echo ppp is already running... |
|
| else |
|
| pppd call $POP |
|
| tail -f /var/log/messages |
|
| fi |
|
| |
|
| `ppp-stop` is used to close the connection: |
|
| |
|
| #!/bin/sh |
|
| MODEM=tty01 |
|
| if [ -f /var/spool/lock/LCK..$MODEM ]; then |
|
| echo -f killing pppd... |
|
| kill -HUP `cat /var/spool/lock/LCK..$MODEM` |
|
| echo done |
|
| else |
|
| echo ppp is not active |
|
| fi |
|
| |
|
| The two scripts take advantage of the fact that when pppd is active, it creates |
|
| the file `LCK..tty01` in the `/var/spool/lock` directory. This file contains the |
|
| process ID (*pid*) of the pppd process. |
|
| |
|
| The two scripts must be executable: |
|
| |
|
| # chmod u+x ppp-start ppp-stop |
|
| |
|
| ### Running commands after dialin |
|
| |
|
| If you find yourself to always run the same set of commands each time you dial |
|
| in, you can put them in a script `/etc/ppp/ip-up` which will be called by |
|
| [[!template id=man name="pppd" section="8"]] after |
|
| successful dial-in. Likewise, before the connection is closed down, |
|
| `/etc/ppp/ip-down` is executed. Both scripts are expected to be executable. See |
|
| [[!template id=man name="pppd" section="8"]] for |
|
| more details. |
|
| |
|
| ## Creating a small home network |
|
| |
|
| Networking is one of the main strengths of Unix and NetBSD is no exception: |
|
| networking is both powerful and easy to set up and inexpensive too, because |
|
| there is no need to buy additional software to communicate or to build a server. |
|
| [[Setting up an Internet gateway with IPNAT|guide/net-practice#ipnat]] explains |
|
| how to configure a NetBSD machine to act as a gateway for a network: with IPNAT |
|
| all the hosts of the network can reach the Internet with a single connection to |
|
| a provider made by the gateway machine. The only thing to be checked before |
|
| creating the network is to buy network cards supported by NetBSD (check the |
|
| `INSTALL.*` files for a list of supported devices). |
|
| |
|
| First, the network cards must be installed and connected to a hub, switch or |
|
| directly (see the next image for an example configuration). |
|
| |
|
| Next, check that the network cards are recognized by the kernel, studying the |
|
| output of the `dmesg` command. In the following example the kernel recognized |
|
| correctly an NE2000 clone: |
|
| |
|
| ... |
|
| ne0 at isa0 port 0x280-0x29f irq 9 |
|
| ne0: NE2000 Ethernet |
|
| ne0: Ethernet address 00:c2:dd:c1:d1:21 |
|
| ... |
|
| |
|
| If the card is not recognized by the kernel, check that it is enabled in the |
|
| kernel configuration file and then that the card's IRQ matches the one that the |
|
| kernel expects. For example, this is the isa NE2000 line in the configuration |
|
| file; the kernel expects the card to be at IRQ 9. |
|
| |
|
| ... |
|
| ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards |
|
| ... |
|
| |
|
| If the card's configuration is different, it will probably not be found at boot. |
|
| In this case, either change the line in the kernel configuration file and |
|
| compile a new kernel or change the card's setup (usually through a setup disk |
|
| or, for old cards, a jumper on the card). |
|
| |
|
| The following command shows the network card's current configuration: |
|
| |
|
| # ifconfig ne0 |
|
| ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 |
|
| address: 00:50:ba:aa:a7:7f |
|
| media: Ethernet autoselect (10baseT) |
|
| inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1 |
|
| |
|
| The software configuration of the network card is very easy. The IP address |
|
| 192.168.1.1 is assigned to the card. |
|
| |
|
| # ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00 |
|
| |
|
| Note that the networks 10.0.0.0/8 and 192.168.0.0/16 are reserved for private |
|
| networks, which is what we're setting up here. |
|
| |
|
| Repeating the previous command now gives a different result: |
|
| |
|
| # ifconfig ne0 |
|
| ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 |
|
| address: 00:50:ba:aa:a7:7f |
|
| media: Ethernet autoselect (10baseT) |
|
| inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 |
|
| inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1 |
|
| |
|
| The output of `ifconfig` has now changed: the IP address is now printed and |
|
| there are two new flags, `UP` and `RUNNING` If the interface isn't `UP`, it will |
|
| not be used by the system to send packets. |
|
| |
|
| The host was given the IP address 192.168.1.1, which belongs to the set of |
|
| addresses reserved for internal networks which are not reachable from the |
|
| Internet. The configuration is finished and must now be tested; if there is |
|
| another active host on the network, a `ping` can be tried. For example, if |
|
| 192.168.1.2 is the address of the active host: |
|
| |
|
| # ping 192.168.1.2 |
|
| PING ape (192.168.1.2): 56 data bytes |
|
| 64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms |
|
| 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms |
|
| 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms |
|
| 64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms |
|
| ^C |
|
| ----ape PING Statistics---- |
|
| 4 packets transmitted, 4 packets received, 0.0% packet loss |
|
| round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms |
|
| |
|
| With the current setup, at the next boot it will be necessary to repeat the |
|
| configuration of the network card. In order to avoid repeating the card's |
|
| configuration at each boot, add the following lines to `/etc/rc.conf`: |
|
| |
|
| auto_ifconfig=yes |
|
| ifconfig_ne0="inet 192.168.1.1 netmask 0xffffff00" |
|
| |
|
| In this example the variable `ifconfig_ne0` was set because the network card was |
|
| recognized as *ne0* by the kernel; if you are using a different adapter, |
|
| substitute the appropriate name in place of ne0. |
|
| |
|
| At the next boot the network card will be configured automatically. |
|
| |
|
| If you have a router that is connected to the internet, you can use it as |
|
| default router, which will handle all your packets. To do so, set `defaultroute` |
|
| to the router's IP address in `/etc/rc.conf`: |
|
| |
|
| defaultroute=192.168.0.254 |
|
| |
|
| Be sure to use the default router's IP address instead of name, in case your DNS |
|
| server is beyond the default router. In that case, the DNS server couldn't be |
|
| reached to resolve the default router's hostname and vice versa, creating a |
|
| chicken-and-egg problem. |
|
| |
|
| To reach hosts on your local network, and assuming you really have very few |
|
| hosts, adjust `/etc/hosts` to contain the addresses of all the hosts belonging |
|
| to the internal network. For example: |
|
| |
|
| # |
|
| # Host Database |
|
| # This file should contain the addresses and aliases |
|
| # for local hosts that share this file. |
|
| # It is used only for "ifconfig" and other operations |
|
| # before the nameserver is started. |
|
| # |
|
| # |
|
| 127.0.0.1 localhost |
|
| ::1 localhost |
|
| # |
|
| # RFC 1918 specifies that these networks are "internal". |
|
| # 10.0.0.0 10.255.255.255 |
|
| # 172.16.0.0 172.31.255.255 |
|
| # 192.168.0.0 192.168.255.255 |
|
| |
|
| 192.168.1.1 ape.insetti.net ape |
|
| 192.168.1.2 vespa.insetti.net vespa |
|
| 192.168.1.0 insetti.net |
|
| |
|
| If you are dialed in via an Internet Service Provider, or if you have a local |
|
| Domain Name Server (DNS) running, you may want to use it to resolve hostnames to |
|
| IP addresses, possibly in addition to `/etc/hosts`, which would only know your |
|
| own hosts. To configure a machine as DNS client, you need to edit |
|
| `/etc/resolv.conf`, and enter the DNS server's address, in addition to an |
|
| optional domain name that will be appended to hosts with no domain, in order to |
|
| create a FQDN for resolving. Assuming your DNS server's IP address is |
|
| 192.168.1.2 and it is setup to serve for "home.net", put the following into |
|
| `/etc/resolv.conf`: |
|
| |
|
| # /etc/resolv.conf |
|
| domain home.net |
|
| nameserver 192.168.1.2 |
|
| |
|
| The `/etc/nsswitch.conf` file should be checked as explained in the previous |
|
| [[nsswitch.conf example|guide/net-practice#rc.conf_and_nsswitch.conf]]. |
|
| |
|
| Summing up, to configure the network the following must be done: the network |
|
| adapters must be installed and physically connected. Next they must be |
|
| configured (with `ifconfig`) and, finally, the file `/etc/rc.conf` must be |
|
| modified to configure the interface and possibly default router, and |
|
| `/etc/resolv.conf` and `/etc/nsswitch.conf` should be adjusted if DNS should be |
|
| used. This type of network management is sufficient for small networks without |
|
| sophisticated needs. |
|
| |
|
| ## Setting up an Internet gateway with IPNAT |
|
| |
|
| The mysterious acronym IPNAT hides the Internet Protocol Network Address |
|
| Translation, which enables the routing of an internal network (e.g. your home |
|
| network as described in the previous section) on a real network (Internet). This |
|
| means that with only one *real* IP, static or dynamic, belonging to a gateway |
|
| running IPNAT, it is possible to create simultaneous connections to the Internet |
|
| for all the hosts of the internal network. |
|
| |
|
| Some usage examples of IPNAT can be found in the subdirectory |
|
| `/usr/share/examples/ipf`: look at the files `BASIC.NAT` and `nat-setup`. |
|
| |
|
| The setup for the example described in this section is detailed in the following |
|
| figure: *host 1* can connect to the Internet calling a provider with a modem and |
|
| getting a dynamic IP address. *host 2* and *host 3* can't communicate with the |
|
| Internet with a normal setup: IPNAT allows them to do it: host 1 will act as a |
|
| Internet gateway for hosts 2 and 3. Using host 1 as default router, hosts 2 and |
|
| 3 will be able to access the Internet. |
|
| |
|
|  |
|
| **Network with gateway** |
|
| |
|
| ### Configuring the gateway/firewall |
|
| |
|
| To use IPNAT, the *pseudo-device ipfilter* must be compiled into the kernel, and |
|
| IP packet forwarding must be enabled in the kernel. To check, run: |
|
| |
|
| # sysctl net.inet.ip.forwarding |
|
| net.inet.ip.forwarding = 1 |
|
| |
|
| If the result is `1` as in the previous example, the option is enabled, |
|
| otherwise, if the result is `0` the option is disabled. You can do two things: |
|
| |
|
| 1. Compile a new kernel, with the GATEWAY option enabled. |
|
| |
|
| 2. Enable the option in the current kernel with the following command: |
|
| |
|
| # sysctl -w net.inet.ip.forwarding=1 |
|
| |
|
| You can add sysctl settings to `/etc/sysctl.conf` to have them set |
|
| automatically at boot. In this case you would want to add |
|
| |
|
| net.inet.ip.forwarding=1 |
|
| |
|
| |
|
| The rest of this section explains how to create an IPNAT configuration that is |
|
| automatically started every time that a connection to the provider is activated |
|
| with the PPP link. With this configuration all the host of a home network (for |
|
| example) will be able to connect to the Internet through the gateway machine, |
|
| even if they don't use NetBSD. |
|
| |
|
| For the setup, first, create the `/etc/ipnat.conf` file containing the following |
|
| rules: |
|
| |
|
| map ppp0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp |
|
| map ppp0 192.168.1.0/24 -> 0/32 portmap tcp/udp 40000:60000 |
|
| map ppp0 192.168.1.0/24 -> 0/32 |
|
| |
|
| 192.168.1.0/24 are the network addresses that should be mapped. The first line |
|
| of the configuration file is optional: it enables active FTP to work through the |
|
| gateway. The second line is used to handle correctly tcp and udp packets; the |
|
| portmapping is necessary because of the many to one relationship). The third |
|
| line is used to enable ICMP, ping, etc. |
|
| |
|
| Next, create the `/etc/ppp/ip-up` file; it will be called automatically every |
|
| time that the PPP link is activated: |
|
| |
|
| #!/bin/sh |
|
| # /etc/ppp/ip-up |
|
| /etc/rc.d/ipnat forcestart |
|
| |
|
| Create the file `/etc/ppp/ip-down`; it will be called automatically when the PPP |
|
| link is closed: |
|
| |
|
| #!/bin/sh |
|
| # /etc/ppp/ip-down |
|
| /etc/rc.d/ipnat forcestop |
|
| |
|
| Both `ip-up` and `ip-down` must be executable: |
|
| |
|
| # chmod u+x ip-up ip-down |
|
| |
|
| The gateway machine is now ready. |
|
| |
|
| ### Configuring the clients |
|
| |
|
| Create a `/etc/resolv.conf` file like the one on the gateway machine, to make |
|
| the clients access the same DNS server as the gateway. |
|
| |
|
| Next, make all clients use the gateway as their default router. Use the |
|
| following command: |
|
| |
|
| # route add default 192.168.1.1 |
|
| |
|
| 192.168.1.1 is the address of the gateway machine configured in the previous |
|
| section. |
|
| |
|
| Of course you don't want to give this command every time, so it's better to |
|
| define the `defaultroute` entry in the `/etc/rc.conf` file: the default route |
|
| will be set automatically during system initialization, using the defaultroute |
|
| option as an argument to the `route add default` command. |
|
| |
|
| If the client machine is not using NetBSD, the configuration will be different. |
|
| On Windows PCs you need to set the gateway property of the TCP/IP protocol to |
|
| the IP address of the NetBSD gateway. |
|
| |
|
| That's all that needs to be done on the client machines. |
|
| |
|
| ### Some useful commands |
|
| |
|
| The following commands can be useful for diagnosing problems: |
|
| |
|
| * `ping` -- tries to connect to other computers via ICMP (usually used for |
|
| testing if a connection exists). |
|
| * `netstat -r` -- Displays the routing tables (similar to `route show`). |
|
| * `traceroute` -- On the client it shows the route followed by the packets to |
|
| their destination. |
|
| * `tcpdump` -- Use on the gateway to monitor TCP/IP traffic. |
|
| |
|
| ## Setting up a network bridge device |
|
| |
|
| A bridge can be used to combine different physical networks into one logical |
|
| network, i.e. connect them at layer 2 of the ISO-OSI model, not at layer 3, |
|
| which is what a router would do. The NetBSD `bridge` driver provides bridge |
|
| functionality on NetBSD systems. |
|
| |
|
| ### Bridge example |
|
| |
|
| In this example two physical networks are going to be combined in one logical |
|
| network, 192.168.1.0, using a NetBSD bridge. The NetBSD machine which is going |
|
| to act as bridge has two interfaces, ne0 and ne1, which are each connected to |
|
| one physical network. |
|
| |
|
| The first step is to make sure support for the `bridge` is compiled in the |
|
| running kernel. Support is included in the GENERIC kernel. |
|
| |
|
| When the system is ready the bridge can be created, this can be done using the |
|
| [[!template id=man name="brconfig" section="8"]] |
|
| command. First of a bridge interface has to be created. With the following |
|
| `ifconfig` command the `bridge0` interface will be created: |
|
| |
|
| $ ifconfig bridge0 create |
|
| |
|
| Please make sure that at this point both the ne0 and ne1 interfaces are up. The |
|
| next step is to add the ne0 and ne1 interfaces to the bridge. |
|
| |
|
| $ brconfig bridge0 add ne0 add ne1 up |
|
| |
|
| This configuration can be automatically set up by creating an |
|
| `/etc/ifconfig.interface` file, in this case `/etc/ifconfig.bridge0`, with the |
|
| following contents: |
|
| |
|
| create |
|
| !brconfig $int add ne0 add ne1 up |
|
| |
|
| After setting up the bridge the bridge configuration can be displayed using the |
|
| `brconfig -a` command. Remember that if you want to give the bridge machine an |
|
| IP address you can only allocate an IP address to one of the interfaces which |
|
| are part of the bridge. |
|
| |
|
| ## A common LAN setup |
|
| |
|
| The small home network discussed in the previous section contained many items |
|
| that were configured manually. In bigger LANs that are centrally managed, one |
|
| can expect Internet connectivity being available via some router, a DNS server |
|
| being available, and most important, a DHCP server which hands out IP addresses |
|
| to clients on request. To make a NetBSD client run in such an environment, it's |
|
| usually enough to set |
|
| |
|
| dhcpcd=yes |
|
| |
|
| in `/etc/rc.conf`, and the IP address will be set automatically, |
|
| `/etc/resolv.conf` will be created and routing setup to the default router. |
|
| |
|
| ## Connecting two PCs through a serial line |
|
| |
|
| If you need to transfer files between two PCs which are not networked there is a |
|
| simple solution which is particularly handy when copying the files to a floppy |
|
| is not practical: the two machines can be networked with a serial cable (a *null |
|
| modem* cable). The following sections describe some configurations. |
|
| |
|
| ### Connecting NetBSD with BSD or Linux |
|
| |
|
| The easiest case is when both machines run NetBSD: making a connection with the |
|
| SLIP protocol is very easy. On the first machine write the following commands: |
|
| |
|
| # slattach /dev/tty00 |
|
| # ifconfig sl0 inet 192.168.1.1 192.168.1.2 |
|
| |
|
| On the second machine write the following commands: |
|
| |
|
| # slattach /dev/tty00 |
|
| # ifconfig sl0 inet 192.168.1.2 192.168.1.1 |
|
| |
|
| Now you can test the connection with `ping`; for example, on the second PC |
|
| write: |
|
| |
|
| # ping 192.168.1.1 |
|
| |
|
| If everything worked there is now an active network connection between the two |
|
| machines and ftp, telnet and other similar commands can be executed. The textual |
|
| aliases of the machines can be written in the `/etc/hosts` file. |
|
| |
|
| * In the previous example both PCs used the first serial port (`/dev/tty0`). |
|
| Substitute the appropriate device if you are using another port. |
|
| |
|
| * IP addresses like 192.168.x.x are reserved for `internal` networks. The first |
|
| PC has address 192.168.1.1 and the second 192.168.1.2. |
|
| |
|
| * To achieve a faster connection the `-s speed` option to `slattach` can be |
|
| specified. |
|
| |
|
| * `ftp` can be used to transfer files only if inetd is active and the ftpd |
|
| * server is enabled. |
|
| |
|
| ### Linux |
|
| |
|
| If one of the two PCs runs Linux, the commands are slightly different (on the |
|
| Linux machine only). If the Linux machine gets the 192.168.1.2 address, the |
|
| following commands are needed: |
|
| |
|
| # slattach -p slip -s 115200 /dev/ttyS0 & |
|
| # ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up |
|
| # route add 192.168.1.1 dev sl0 |
|
| |
|
| Don't forget the `&` in the first command. |
|
| |
|
| ### Connecting NetBSD and Windows NT |
|
| |
|
| NetBSD and Windows NT can be (almost) easily networked with a serial *null |
|
| modem* cable. Basically what needs to be done is to create a *Remote Access* |
|
| connection under Windows NT and to start pppd on NetBSD. |
|
| |
|
| Start pppd as root after having created a `.ppprc` in `/root`. Use the following |
|
| example as a template. |
|
| |
|
| connect '/usr/sbin/chat -v CLIENT CLIENTSERVER' |
|
| local |
|
| tty00 |
|
| 115200 |
|
| crtscts |
|
| lock |
|
| noauth |
|
| nodefaultroute |
|
| :192.168.1.2 |
|
| |
|
| The meaning of the first line will be explained later in this section; |
|
| 192.168.1.2 is the IP address that will be assigned by NetBSD to the Windows NT |
|
| host; `tty00` is the serial port used for the connection (first serial port). |
|
| |
|
| On the NT side a *null modem* device must be installed from the Control Panel |
|
| (Modem icon) and a Remote Access connection using this modem must be created. |
|
| The null modem driver is standard under Windows NT 4 but it's not a 100% null |
|
| modem: when the link is activated, NT sends the string CLIENT and expects to |
|
| receive the answer CLIENTSERVER. This is the meaning of the first line of the |
|
| `.ppprc` file: `chat` must answer to NT when the connection is activated or |
|
| the connection will fail. |
|
| |
|
| In the configuration of the Remote Access connection the following must be |
|
| specified: use the null modem, telephone number `1` (it's not used, anyway), PPP |
|
| server, enable only TCP/IP protocol, use IP address and nameservers from the |
|
| server (NetBSD in this case). Select the hardware control flow and set the port |
|
| to 115200 8N1. |
|
| |
|
| Now everything is ready to activate the connection. |
|
| |
|
| * Connect the serial ports of the two machines with the null modem cable. |
|
| * Launch pppd on NetBSD. To see the messages of pppd: |
|
| `tail -f /var/log/messages`). |
|
| * Activate the Remote Access connection on Windows NT. |
|
| |
|
| ### Connecting NetBSD and Windows 95 |
|
| |
|
| The setup for Windows 95 is similar to the one for Windows NT: Remote Access on |
|
| Windows 95 and the PPP server on NetBSD will be used. Most (if not all) Windows |
|
| 95 releases don't have the *null modem* driver, which makes things a little more |
|
| complicated. The easiest solution is to find one of the available null modem |
|
| drivers on the Internet (it's a small `.INF` file) and repeat the same steps as |
|
| for Windows NT. The only difference is that the first line of the `.ppprc` file |
|
| (the one that calls `chat`) can be removed. |
|
| |
|
| If you can't find a real null modem driver for Windows 95 it's still possible to |
|
| use a little trick: |
|
| |
|
| * Create a Remote Access connection like the one described before for Windows |
|
| NT, but using the *Standard Modem*. |
|
| |
|
| * In `.ppprc` substitute the line that calls `chat` with the following line |
|
| |
|
| connect '/usr/sbin/chat -v ATH OK AT OK ATE0V1 OK AT OK ATDT CONNECT' |
|
| |
|
| * Activate the connection as described in the section before for Windows NT. |
|
| |
|
| |
|
| In this way the `chat` program, called when the connection is activated, |
|
| emulates what Windows 95 thinks is a standard modem, returning to Windows 95 the |
|
| same answers that a standard modem would return. Whenever Windows 95 sends a |
|
| modem command string, `chat` returns OK. |
|
| |
|
| ## IPv6 Connectivity & Transition via 6to4 |
|
| |
|
| This section will concentrate on how to get network connectivity for IPv6 and - |
|
| as that is rarely available directly - talk at length about the alternatives to |
|
| native IPv6 connectivity as a transitional method until native IPv6 peers are |
|
| available. |
|
| |
|
| Finding an ISP that offers IPv6 natively needs quite some luck. What you need |
|
| next is a router that will be able to handle the traffic. To date, not all |
|
| router manufacturers offer IPv6 or hardware accelerated IPv6 features, and |
|
| gateway NAT boxes only rarely support IPv6 and also block IPv6 tunnels. An |
|
| alternative approach involves configuring a standard PC running NetBSD to act as |
|
| a router. The base NetBSD system contains a complete IPv6 routing solution, and |
|
| for special routing needs software like Zebra can provide additional routing |
|
| protocols. This solution is rather common for sites that want IPv6 |
|
| connectivity today. The drawbacks are that you need an ISP that supports |
|
| IPv6 and that you may need a dedicated uplink only for IPv6. |
|
| |
|
| IPv6 to-the-door may be rare, but you can still get IPv6 connectivity by using |
|
| tunnels. Instead of talking IPv6 on the wire, the IPv6 packets are encapsulated |
|
| in IPv4 packets, as shown in the next image. Using the existing IPv4 |
|
| infrastructure, the encapsulated packets are sent to a IPv6-capable uplink that |
|
| will then remove the encapsulation, and forward the IPv6 packets. |
|
| |
|
|  |
|
| **A frequently used method for transition is tunneling IPv6 in IPv4 packets** |
|
| |
|
| When using tunnels, there are two possibilities. One is to use a so-called |
|
| *configured* tunnel, the other is called an *automatic* tunnel. A *configured* |
|
| tunnel is one that required preparation from both ends of the tunnel, usually |
|
| connected with some kind of registration to exchange setup information. An |
|
| example for such a configured tunnel is the IPv6-over-IPv4 encapsulation |
|
| described in |
|
| [RFC1933](http://tools.ietf.org/html/rfc1933) ("RFC 1933: Transition Mechanisms |
|
| for IPv6 Hosts and Routers"), and that's implemented e.g. by the |
|
| [[!template id=man name="gif" section="4"]] |
|
| device found in NetBSD. |
|
| |
|
| An *automatic* tunnel consists of a public server that has some kind of IPv6 |
|
| connectivity, e.g. via 6Bone. That server has made its connectivity data public, |
|
| and also runs a tunneling protocol that does not require an explicit |
|
| registration of the sites using it as uplink. A well-used example of such a |
|
| protocol is the 6to4 mechanism described in |
|
| [RFC3056](http://tools.ietf.org/html/rfc3056) ("RFC 3056: Connection of IPv6 |
|
| Domains via IPv4 Clouds"), and that is implemented in the |
|
| [[!template id=man name="stf" section="4"]] device |
|
| found in NetBSD's. Another mechanism that does not require registration of |
|
| IPv6-information is the 6over4 mechanism, which implements transporting of IPv6 |
|
| over a multicast-enabled IPv4 network, instead of e.g. ethernet or FDDI. 6over4 |
|
| is documented in [RFC2529](http://tools.ietf.org/html/rfc2529) ("RFC 2529: |
|
| Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"). It's main |
|
| drawback is that you do need existing multicast infrastructure. If you don't |
|
| have that, setting it up is about as much effort as setting up a configured IPv6 |
|
| tunnel directly, so it's usually not worth bothering in that case. |
|
| |
|
| ### Getting 6to4 IPv6 up & running |
|
| |
|
| 6to4 is an easy way to get IPv6 connectivity for hosts that only have an IPv4 |
|
| uplink, especially if you have the background given in |
|
| [[the chapter about IPv6|guide/net-intro#ipv6-intro]]. It can be used with |
|
| static as well as dynamically assigned IPv4 addresses, e.g. as found in modem |
|
| dialup scenarios today. When using dynamic IPv4 addresses, a change of IP |
|
| addresses will be a problem for incoming traffic, i.e. you can't run persistent |
|
| servers. |
|
| |
|
| Example configurations given in this section are for NetBSD 1.5.2. |
|
| |
|
| ### Obtaining IPv6 Address Space for 6to4 |
|
| |
|
| The 6to4 IPv6 setup on your side doesn't consist of a single IPv6 address; |
|
| Instead, you get a whole /48 network! The IPv6 addresses are derived from your |
|
| (single) IPv4 address. The address prefix *2002:` is reserved for 6to4 based |
|
| addresses (i.e. IPv6 addresses derived from IPv4 addresses). The next 32 bits |
|
| are your IPv4 address. This results in a /48 network that you can use for your |
|
| very own purpose. It leaves 16 bits space for 2^16^ IPv6 subnets, which can take |
|
| up to 2^64^ nodes each. The next figure illustrates the building of your IPv6 |
|
| address (range) from your IPv4 address. |
|
| |
|
| Thanks to the 6to4 prefix and your worldwide unique IPv4 address, this address |
|
| block is unique, and it's mapped to your machine carrying the IPv4 address in |
|
| question. |
|
| |
|
|  |
|
| **6to4 derives an IPv6 from an IPv4 address** |
|
| |
|
| ### How to get connected |
|
| |
|
| In contrast to the configured *IPv6-over-IPv4 tunnel* setup, you do not have to |
|
| register at a 6bone-gateway, which would only then forward your IPv6 traffic |
|
| encapsulated in IPv4. Instead, as your IPv6 address is derived from your IPv4 |
|
| address, inbound traffic can be sent through the nearest 6to4 relay router. |
|
| De-encapsulation of the packet is done via a 6to4-capable network interface, |
|
| which then forwards the resulting IPv6 packet according to your routing setup |
|
| (in case you have more than one machine connected on your 6to4 assigned |
|
| network). |
|
| |
|
| To transmit IPv6 packets, the 6to4 router will encapsulate them inside IPv4 |
|
| packets; a system performing these functions is called a 6to4 border router. |
|
| These packets have a default route to the *6to4 relay anycast prefix*. This |
|
| anycast prefix will route the tunnel to a *6to4 relay router*. |
|
| |
|
|  |
|
| **Request and reply can be routed via different gateways in 6to4** |
|
| |
|
| ### Security Considerations |
|
| |
|
| In contrast to the *configured tunnel* setup, you usually can't setup packet |
|
| filters to block 6to4-packets from unauthorized sources, as this is exactly how |
|
| (and why) 6to4 works at all. As such, malicious users can send packets with |
|
| invalid/hazardous IPv6 payload. If you don't already filter on your border |
|
| gateways anyways, packets with the following characteristics should not be |
|
| allowed as valid 6to4 packets, and some firewalling seems to be justified for |
|
| them: |
|
| |
|
| * unspecified IPv4 source/destination address: 0.0.0.0/8 |
|
| * loopback address in outer (v4) source/destination: 127.0.0.0/8 |
|
| * IPv4 multicast in source/destination: 224.0.0.0/4 |
|
| * limited broadcasts: 255.0.0.0/8 |
|
| * subnet broadcast address as source/destination: depends on your IPv4 setup |
|
| |
|
| The NetBSD |
|
| [[!template id=man name="stf" section="4"]] manual |
|
| page documents some common configuration mistakes intercepted by default by the |
|
| KAME stack as well as some further advice on filtering, but keep in mind that |
|
| because of the requirement of these filters, 6to4 is not perfectly secure. |
|
| Still, if forged 6to4 packets become a problem, you can use IPsec authentication |
|
| to ensure the IPv6 packets are not modified. |
|
| |
|
| ### Data Needed for 6to4 Setup |
|
| |
|
| In order to setup and configure IPv6 over 6to4, a few bits of configuration data |
|
| must be known in advance. These are: |
|
| |
|
| * Your local IPv4 address. It can be determined using either the `ifconfig -a` |
|
| or `netstat -i` commands on most Unix systems. If you use a NATing gateway or |
|
| something, be sure to use the official, outside-visible address, not your |
|
| private (10/8 or 192.168/16) one. |
|
| |
|
| We will use 62.224.57.114 as the local IPv4 address in our example. |
|
| |
|
| * Your local IPv6 address, as derived from the IPv4 address. See the previous |
|
| figure ("6to4 derives an IPv6 from an IPv4 address") about how to do so. |
|
| |
|
| For our example, this is 2002:3ee0:3972:0001::1 (62.224.57.114 == 0x3ee03972, |
|
| 0001::1 arbitrarily chosen). |
|
| |
|
| * The *6to4 IPv6 relay anycast address*. which is 2002:c058:6301::, or the IPv6 |
|
| address of a specific 6to4 relay router you want to use. The IPv6 address |
|
| will do, as it also contains the IPv4 address in the usual 6to4 translation. |
|
| |
|
| ### Kernel Preparation |
|
| |
|
| To process 6to4 packets, the operating system kernel needs to know about them. |
|
| For that a driver has to be compiled in that knows about 6to4, and how to handle |
|
| it. In NetBSD 4.0 and newer, the driver is already present in GENERIC kernel |
|
| configurations, so the procedure below is usually unnecessary. |
|
| |
|
| For a NetBSD kernel, put the following into your kernel config file to prepare |
|
| it for using IPv6 and 6to4, e.g. on NetBSD use: |
|
| |
|
| options INET6 # IPv6 |
|
| pseudo-device stf # 6to4 IPv6 over IPv4 encapsulation |
|
| |
|
| Note that the |
|
| [[!template id=man name="stf" section="4"]] device is |
|
| not enabled by default on NetBSD releases older than 4.0. Rebuild your kernel, |
|
| then reboot your system to use the new kernel. Please consult |
|
| [[Compiling the kernel|guide/kernel]] for further information on configuring, |
|
| building and installing a new kernel! |
|
| |
|
| ### 6to4 Setup |
|
| |
|
| This section describes the commands to setup 6to4. In short, the steps performed |
|
| here are: |
|
| |
|
| 1. Configure interface |
|
| 2. Set default route |
|
| 3. Setup Router Advertisement, if wanted |
|
| |
|
| The first step in setting up 6to4 is creating the 6to4 interface and assigning |
|
| an IPv6 address to it. This is achieved with the |
|
| [[!template id=man name="ifconfig" section="8"]] |
|
| command. Assuming the example configuration above, the commands for NetBSD are: |
|
| |
|
| # ifconfig stf0 create |
|
| # ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias |
|
| |
|
| After configuring the 6to4 device with these commands, routing needs to be |
|
| setup, to forward all tunneled IPv6 traffic to the 6to4 relay router. The best |
|
| way to do this is by setting a default route, the command to do so is, for |
|
| NetBSD: |
|
| |
|
| # route add -inet6 default 2002:c058:6301:: |
|
| |
|
| Note that NetBSD's |
|
| [[!template id=man name="stf" section="4"]] device |
|
| determines the IPv4 address of the 6to4 uplink from the routing table. Using |
|
| this feature, it is easy to setup your own 6to4 (uplink) gateway if you have an |
|
| IPv6 uplink, e.g. via 6Bone. |
|
| |
|
| After these commands, you are connected to the IPv6-enabled world - |
|
| Congratulations! Assuming name resolution is still done via IPv4, you can now |
|
| ping an IPv6-site like www.kame.net or www6.NetBSD.org: |
|
| |
|
| # /sbin/ping6 www.kame.net |
|
| |
|
| As a final step in setting up IPv6 via 6to4, you will want to setup Router |
|
| Advertisement if you have several hosts on your network. While it is possible to |
|
| setup 6to4 on each node, doing so will result in very expensive routing from one |
|
| node to the other - packets will be sent to the remote 6to4 gateway, which will |
|
| then route the packets back to the neighbor node. Instead, setting up 6to4 on |
|
| one machine and talking native IPv6 on-wire is the preferred method of handling |
|
| things. |
|
| |
|
| The first step to do so is to assign an IPv6-address to your ethernet. In the |
|
| following example we will assume subnet `2` of the IPv6-net is used for the |
|
| local ethernet and the MAC address of the ethernet interface is |
|
| 12:34:56:78:9a:bc, i.e. your local gateway's ethernet interface's IP address |
|
| will be 2002:3ee0:3972:2:1234:56ff:fe78:9abc. Assign this address to your |
|
| ethernet interface, e.g. |
|
| |
|
| # ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc |
|
| |
|
| Here, `ne0` is an example for your ethernet card interface. This will most |
|
| likely be different for your setup, depending on what kind of card is used. |
|
| |
|
| Next thing that needs to be ensured for setting up the router is that it will |
|
| actually forward packets from the local 6to4 device to the ethernet device and |
|
| back. To enable IPv6 packet forwarding, set `ip6mode=router` in NetBSD's |
|
| `/etc/rc.conf`, which will result in the `net.inet6.ip6.forwarding` sysctl being |
|
| set to `1`: |
|
| |
|
| # sysctl -w net.inet6.ip6.forwarding=1 |
|
| |
|
|  |
|
| **Enabling packet forwarding is needed for a 6to4 router** |
|
| |
|
| To setup router advertisement on BSD, the file `/etc/rtadvd.conf` needs to be |
|
| checked. It allows configuration of many things, but usually the default config |
|
| of not containing any data is ok. With that default, IPv6 addresses found on all |
|
| of the router's network interfaces will be advertised. |
|
| |
|
| After checking the router advertisement configuration is correct and IPv6 |
|
| forwarding is turned on, the daemon handling it can be started. Under NetBSD, it |
|
| is called `rtadvd`. Start it up either manually (for testing it the first time) |
|
| or via the system's startup scripts, and see all your local nodes automagically |
|
| configure the advertised subnet address in addition to their already-existing |
|
| link local address. |
|
| |
|
| # rtadvd |
|
| |
|
| ### Quickstart using pkgsrc/net/hf6to4 |
|
| |
|
| So far, we have described how 6to4 works and how to set it up manually. For an |
|
| automated way to make everything happen e.g. when going online, the 'hf6to4' |
|
| package is convenient. It will determine your IPv6 address from the IPv4 address |
|
| you got assigned by your provider, then set things up that you are connected. |
|
| |
|
| Steps to setup the pkgsrc/net/hf6to4 package are: |
|
| |
|
| 1. Install the package either by compiling it from pkgsrc, or by `pkg_add`'ing |
|
| the 6to4-1.2 package. |
|
| |
|
| # cd /usr/pkgsrc/net/hf6to4 |
|
| # make install |
|
| |
|
| 2. Make sure you have the |
|
| [[!template id=man name="stf" section="4"]] |
|
| pseudo-device in your kernel, see above. |
|
| |
|
| 3. Configure the 'hf6to4' package. First, copy |
|
| `/usr/pkg/share/examples/hf6to4/hf6to4.conf` to `/usr/pkg/etc/hf6to4.conf`, |
|
| then adjust the variables. Note that the file is in /bin/sh syntax. |
|
| |
|
| # cd /usr/pkg/etc |
|
| # cp ../share/examples/hf6to4/hf6to4.conf hf6to4.conf |
|
| # vi hf6to4.conf |
|
| |
|
| Please see the |
|
| [[!template id=man name="hf6to4" section="8"]] |
|
| manpage for an explanation of all the variables you can set in |
|
| `hf6to4.conf`. If you have dialup IP via PPP, and don't want to run Router |
|
| Advertizing for other IPv6 machines on your home or office network, you |
|
| don't need to configure anything. If you want to setup Router Advertising, |
|
| you need to set the `in_if` to the internal (ethernet) interface, e.g. |
|
| |
|
| $in_if="rtk0"; # Inside (ethernet) interface |
|
| |
|
| 4. Now dial up, then start the 6to4 command manually: |
|
| |
|
| # /usr/pkg/sbin/hf6to4 start |
|
| |
|
| 5. After that, you should be connected, use |
|
| [[!template id=man name="ping6" section="8"]]: to |
|
| see if everything works: |
|
| |
|
| # ping6 www.NetBSD.org |
|
| PING6(56=40+8+8 bytes) 2002:d954:110b:1::1 --> 2001:4f8:4:7:2e0:81ff:fe52:9a6b |
|
| 16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=0 hlim=60 time=250.234 ms |
|
| 16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=1 hlim=60 time=255.652 ms |
|
| 16 bytes from 2001:4f8:4:7:2e0:81ff:fe52:9a6b, icmp_seq=2 hlim=60 time=251.237 ms |
|
| ^C |
|
| --- www.NetBSD.org ping6 statistics --- |
|
| 3 packets transmitted, 3 packets received, 0.0% packet loss |
|
| round-trip min/avg/max/std-dev = 250.234/252.374/255.652/2.354 ms |
|
| |
|
| # traceroute6 www.NetBSD.org |
|
| traceroute6 to www.NetBSD.org (2001:4f8:4:7:2e0:81ff:fe52:9a6b) |
|
| from 2002:d954:110b:1::1, 64 hops max, 12 byte packets |
|
| 1 2002:c25f:6cbf:1::1 66.31 ms 66.382 ms 69.062 ms |
|
| 2 nr-erl1.6win.dfn.de 76.134 ms * 76.87 ms |
|
| 3 nr-fra1.6win.dfn.de 76.371 ms 80.709 ms 79.482 ms |
|
| 4 dfn.de6.de.6net.org 92.763 ms 90.863 ms 94.322 ms |
|
| 5 de.nl6.nl.6net.org 116.115 ms 93.463 ms 96.331 ms |
|
| 6 nl.uk6.uk.6net.org 103.347 ms 99.334 ms 100.803 ms |
|
| 7 uk1.uk61.uk.6net.org 99.481 ms 100.421 ms 100.119 ms |
|
| 8 2001:798:28:300::2 89.711 ms 90.435 ms 90.035 ms |
|
| 9 ge-1-0-0-2.r20.londen03.uk.bb.verio.net 179.671 ms 185.141 ms 185.86 ms |
|
| 10 p16-0-0-0.r81.nycmny01.us.bb.verio.net 177.067 ms 179.086 ms 178.05 ms |
|
| 11 p16-1-1-3.r20.nycmny01.us.bb.verio.net 178.04 ms 179.727 ms 184.165 ms |
|
| 12 p16-0-1-1.r20.mlpsca01.us.bb.verio.net 249.856 ms 247.476 ms 249.012 ms |
|
| 13 p64-0-0-0.r21.snjsca04.us.bb.verio.net 239.691 ms 241.404 ms 240.998 ms |
|
| 14 p64-0-0-0.r21.plalca01.us.bb.verio.net 247.541 ms 246.661 ms 246.359 ms |
|
| 15 xe-0-2-0.r20.plalca01.us.bb.verio.net 240.987 ms 239.056 ms 241.251 ms |
|
| 16 ge-6-1.a01.snfcca05.us.ra.verio.net 240.868 ms 241.29 ms 242.337 ms |
|
| 17 fa-5-2.a01.snfcca05.us.ce.verio.net 249.477 ms 250.4 ms 256.035 ms |
|
| 18 2001:4f8:4:7:2e0:81ff:fe52:9a6b 268.164 ms 252.97 ms 252.366 ms |
|
| |
|
| Please note that `traceroute6` shows the v6 hops only, any underlying |
|
| tunnels are invisible and thus not displayed. |
|
| |
|
| 6. If this works, you can put the following lines into your `/etc/ppp/ip-up` |
|
| script to run the command each time you go online: |
|
| |
|
| logger -p user.info -t ip-up Configuring 6to4 IPv6 |
|
| /usr/pkg/sbin/hf6to4 stop |
|
| /usr/pkg/sbin/hf6to4 start |
|
| |
|
| 7. If you want to route IPv6 for your LAN, you can instruct `6to4.pl` to setup |
|
| Router Advertising for you too: |
|
| |
|
| # /usr/pkg/sbin/hf6to4 rtadvd-start |
|
| |
|
| You can put that command into `/etc/ppp/ip-up` as well to make it permanent. |
|
| |
|
| 8. If you have changed `/etc/ppp/ip-up` to setup 6to4 automatically, you will |
|
| most likely want to change `/etc/ppp/ip-down` too, to shut it down when you |
|
| go offline. Here's what to put into `/etc/ppp/ip-down`: |
|
| |
|
| logger -p user.info -t ip-down Shutting down 6to4 IPv6 |
|
| /usr/pkg/sbin/hf6to4 rtadvd-stop |
|
| /usr/pkg/sbin/hf6to4 stop |
|
| |
|
| ### Known 6to4 Relay Routers |
|
| |
|
| It is normally not necessary to pick a specific 6to4 relay router, but if |
|
| necessary, you may find a list of known working routers at |
|
| [http://www.kfu.com/\~nsayer/6to4/](http://www.kfu.com/~nsayer/6to4/). In tests, |
|
| only 6to4.kfu.com and 6to4.ipv6.microsoft.com were found working. Cisco has one |
|
| that requires registration, see |
|
| <http://www.cisco.com/ipv6/>. |
|
| |
|
| There's also an experimental 6to4 server located in Germany, |
|
| 6to4.ipv6.fh-regensburg.de. This server runs under NetBSD 1.6 and was setup |
|
| using the configuration steps described above. The whole configuration of the |
|
| machine can be seen at |
|
| <http://www.feyrer.de/IPv6/netstart.local>. |
|
| |
|
| ### Tunneling 6to4 through an IPFilter firewall |
|
| |
|
| The 6to4 protocol encapsulates IPv6 packets in IPv4, and gives them their own IP |
|
| type, which most firewalls block as unknown, as their payload type is directly |
|
| `TCP`, `UDP` or `ICMP`. Usually, you want to setup your 6to4 gateway on the same |
|
| machine that is directly connected to the (IPv4) internet, and which usually |
|
| runs the firewall. For the case that you want to run your 6to4 gateway behind a |
|
| firewall, you need to drill a hole into the firewall, to let 6to4 packets |
|
| through. Here is how to do this! |
|
| |
|
| The example assumes that you use the `ppp0` interface on your firewall to |
|
| connect to the Internet. |
|
| |
|
| Put the following lines into `/etc/ipf.conf` to allow your IPFilter firewall let |
|
| all 6to4 packets pass (lines broken with `\` due to space restrictions; please |
|
| put them lines continued that way all in one line): |
|
| |
|
| # Handle traffic by different rulesets |
|
| block in quick on ppp0 all head 1 |
|
| block out quick on ppp0 all head 2 |
|
| |
|
| ### Incoming packets: |
|
| # allow some IPv4: |
|
| pass in log quick on ppp0 proto tcp from any to any \ |
|
| port = www flags S keep state keep frags group 1 |
|
| pass in quick on ppp0 proto tcp from any to any \ |
|
| port = ssh keep state group 1 |
|
| pass in quick on ppp0 proto tcp from any to any \ |
|
| port = mail keep state group 1 |
|
| pass in log quick on ppp0 proto tcp from any to any \ |
|
| port = ftp keep state group 1 |
|
| pass in log quick on ppp0 proto tcp from any to any \ |
|
| port = ftp-data keep state group 1 |
|
| pass in log quick on ppp0 proto icmp from any to any group 1 |
|
| # allow all IPv6: |
|
| pass in quick on ppp0 proto ipv6 from any to any group 1 |
|
| pass in log quick on ppp0 proto ipv6-route from any to any group 1 |
|
| pass in log quick on ppp0 proto ipv6-frag from any to any group 1 |
|
| pass in log quick on ppp0 proto ipv6-icmp from any to any group 1 |
|
| pass in log quick on ppp0 proto ipv6-nonxt from any to any group 1 |
|
| pass in log quick on ppp0 proto ipv6-opts from any to any group 1 |
|
| # block rest: |
|
| blockin log quick on ppp0 all group 1 |
|
| |
|
| ### Outgoing packets: |
|
| # allow usual stuff: |
|
| pass out quick on ppp0 proto tcp from any to any flags S \ |
|
| keep state keep frags group 2 |
|
| pass out quick on ppp0 proto udp from any to any \ |
|
| keep state keep frags group 2 |
|
| pass out quick on ppp0 proto icmp from any to any \ |
|
| keep state group 2 |
|
| # allow all IPv6: |
|
| pass out quick on ppp0 proto ipv6 from any to any group 2 |
|
| pass out log quick on ppp0 proto ipv6-route from any to any group 2 |
|
| pass out log quick on ppp0 proto ipv6-frag from any to any group 2 |
|
| pass out log quick on ppp0 proto ipv6-icmp from any to any group 2 |
|
| pass out log quick on ppp0 proto ipv6-nonxt from any to any group 2 |
|
| pass out log quick on ppp0 proto ipv6-opts from any to any group 2 |
|
| # block rest: |
|
| block out log quick on ppp0 all group 2 |
|
| |
|
| Now any host on your network can send (the `out` rules) and receive (the `in` |
|
| rules) v4-encapsulated IPv6 packets, allowing setup of any of them as a 6to4 |
|
| gateway. Of course you only want to do this on one host and use native IPv6 |
|
| between your hosts, and you may also want to enforce this with more restrictive |
|
| rulesets, please see |
|
| [[!template id=man name="ipf.conf" section="5"]] |
|
| for more information on IPFilter rules. |
|
| |
|
| After your firewall lets pass encapsulated IPv6 packets, you may want to set up |
|
| your 6to4 gateway to monitor the IPv6 traffic, or even restrict it. To do so, |
|
| you need to setup IPFilter on your 6to4 gateway as well. For basic monitoring, |
|
| enable `ipfilter=yes` in `/etc/rc.conf` and put the following into |
|
| `/etc/ipf6.conf`: |
|
| |
|
| pass in log quick on stf0 from any to any |
|
| pass out log quick on stf0 from any to any |
|
| |
|
| This logs all (IPv6) traffic going in and out of your `stf0` tunneling |
|
| interface. You can add filter rules as well if needed. |
|
| |
|
| If you are more interested in traffic stats than a general overview of your |
|
| network traffic, using MRTG in conjunction with the `net-snmp` package is |
|
| recommended instead of analyzing IPFilter log files. |
|
| |
|
| ### Conclusion & Further Reading |
|
| |
|
| Compared to where IPv4 is today, IPv6 is still in its early steps. It is |
|
| working, there are all sort of services and clients available, only the userbase |
|
| is missing. It is hoped the information provided here helps people better |
|
| understand what IPv6 is, and to start playing with it. |
|
| |
|
| A few links should be mentioned here for interested parties: |
|
| |
|
| * An example script to setup 6to4 on BSD based machines is available at |
|
| <http://www.NetBSD.org/packages/net/hf6to4/>. The script determines your IPv6 |
|
| address and sets up 6to4 and (if wanted) router advertising. It was designed |
|
| to work in dialup setups with changing IPv4 addresses. |
|
| |
|
| * Given that there isn't a standard for IPv6 in Linux land today, there are |
|
| different setup instructions for most distributions. The setup of IPv6 on |
|
| Debian GNU/Linux can be found at |
|
| [http://people.debian.org/\~csmall/ipv6/setup.html](http://people.debian.org/~csmall/ipv6/setup.html). |
|
| |
|
| * The BSD Unix implementations have their own IPv6 documentation each, |
|
| interesting URLs are <http://www.NetBSD.org/docs/network/ipv6/> for NetBSD, |
|
| <http://www.freebsd.org/doc/en\_US.ISO8859-1/books/handbook/network-ipv6.html> |
|
| for FreeBSD. |
|
| |
|
| * Projects working on implementing IPv6 protocol stacks for free Unix like |
|
| operating systems are KAME for BSD and USAGI for Linux. Their web sites can |
|
| be found at <http://www.kame.net/> and <http://www.linux-ipv6.org/>. A list |
|
| of host and router implementations can be found at |
|
| <http://playground.sun.com/pub/ipng/html/ipng-implementations.html>. |
|
| |
|
| * Besides the official RFC archive at <ftp://ftp.isi.edu/in-notes>, information |
|
| on IPv6 can be found at several web sites. First and foremost, the 6Bone's |
|
| web page at <http://www.6bone.net/> must be mentioned. 6Bone was started as |
|
| the testbed for IPv6, and is now an important part of the IPv6-connected |
|
| world. Other web pages that contain IPv6-related contents include |
|
| <http://www.ipv6.org/>, <http://playground.sun.com/pub/ipng/html/> and |
|
| <http://www.ipv6forum.com/>. Most of these sites carry further links - be |
|
| sure to have a look! |
|
| |
|
![[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