Annotation of wikisrc/guide/net-intro.mdwn, revision 1.1

1.1     ! jdf         1: ## Introduction to TCP/IP Networking
        !             2: 
        !             3: ## Audience
        !             4: 
        !             5: This section explains various aspects of networking. It is intended to help
        !             6: people with little knowledge about networks to get started. It is divided into
        !             7: three big parts. We start by giving a general overview of how networking works
        !             8: and introduce the basic concepts. Then we go into details for setting up various
        !             9: types of networking in the second parts, and the third part of the networking
        !            10: section covers a number of *advanced* topics that go beyond the basic operation
        !            11: as introduced in the first two sections.
        !            12: 
        !            13: The reader is assumed to know about basic system administration tasks: how to
        !            14: become root, edit files, change permissions, stop processes, etc. See the other
        !            15: chapters of this NetBSD guide and
        !            16: e.g.\[[[AeleenFrisch|guide/index#bibliography]]\]
        !            17: for further information on this topic. Besides that, you should know how to
        !            18: handle the utilities we're going to set up here, i.e. you should know how to
        !            19: use telnet, FTP, ... I will not explain the basic features of those
        !            20: utilities, please refer to the appropriate man-pages, the references listed
        !            21: or of course the other parts of this document instead.
        !            22: 
        !            23: This introduction to TCP/IP Networking was written with the intention in mind to
        !            24: give starters a basic knowledge. If you really want to know what it's all about,
        !            25: read \[[[CraigHunt|guide/index#bibliography]]\]. This book does not only cover
        !            26: the basics, but goes on and explains all the concepts, services and how to set
        !            27: them up in detail. It's great, I love it! :-)
        !            28: 
        !            29: ## Supported Networking Protocols
        !            30: 
        !            31: There are several protocol suites supported by NetBSD, most of which were
        !            32: inherited from NetBSD's predecessor, 4.4BSD, and subsequently enhanced and
        !            33: improved. The first and most important one today is DARPA's Transmission Control
        !            34: Protocol/Internet Protocol (TCP/IP). Other protocol suites available in NetBSD
        !            35: include the Xerox Network System (XNS) which was only implemented at UCB to
        !            36: connect isolated machines to the net, Apple's AppleTalk protocol suite and the
        !            37: ISO protocol suite, CCITT X.25 and ARGO TP. They are only used in some special
        !            38: applications these days.
        !            39: 
        !            40: Today, TCP/IP is the most widespread protocol of the ones mentioned above. It is
        !            41: implemented on almost every hardware and operating system, and it is also the
        !            42: most-used protocol in heterogenous environments. So, if you just want to connect
        !            43: your computer running NetBSD to some other machine at home or you want to
        !            44: integrate it into your company's or university's network, TCP/IP is the right
        !            45: choice. Besides the "old" IP version 4, NetBSD also supports the "new" IP
        !            46: version 6 (IPv6) since NetBSD 1.5, thanks to code contributed by the KAME
        !            47: project.
        !            48: 
        !            49: There are other protocol suites such as DECNET, Novell's IPX/SPX or Microsoft's
        !            50: NetBIOS, but these are not currently supported by NetBSD. These protocols differ
        !            51: from TCP/IP in that they are proprietary, in contrast to the others, which are
        !            52: well-defined in several RFCs and other open standards.
        !            53: 
        !            54: ## Supported Media
        !            55: 
        !            56: The TCP/IP protocol stack behaves the same regardless of the underlying media
        !            57: used, and NetBSD supports a wide range of these, among them are Ethernet
        !            58: (10/100/1000MBd), Arcnet, serial line, ATM, FDDI, Fiber Channel, USB, HIPPI,
        !            59: FireWire (IEEE 1394), Token Ring, and serial lines.
        !            60: 
        !            61: ### Serial Line
        !            62: 
        !            63: There are a couple of reasons for using TCP/IP over a serial line.
        !            64: 
        !            65:  * If your remote host is only reachable via telephone, you can use a modem to access it.
        !            66:  * Many computers have a serial port, and the cable needed is rather cheap.
        !            67: 
        !            68: The disadvantage of a serial connection is that it's slower than other methods.
        !            69: NetBSD can use at most 115200 bit/s, making it a lot slower than e.g. Ethernet's
        !            70: minimum 10 Mbit/s and Arcnet's 4 Mbit/s.
        !            71: 
        !            72: There are two possible protocols to connect a host running NetBSD to another
        !            73: host using a serial line (possibly over a phone-line):
        !            74: 
        !            75:  * Serial Line IP (SLIP)
        !            76:  * Point to Point Protocol (PPP)
        !            77: 
        !            78: The choice here depends on whether you use a dial-up connection through a modem
        !            79: or if you use a static connection (null-modem or leased line). If you dial up
        !            80: for your IP connection, it's wise to use PPP as it offers some possibilities to
        !            81: auto-negotiate IP-addresses and routes, which can be quite painful to do by
        !            82: hand. If you want to connect to another machine which is directly connected,
        !            83: use SLIP, as this is supported by about every operating system and more easy
        !            84: to set up with fixed addresses and routes.
        !            85: 
        !            86: PPP on a direct connection is a bit difficult to setup, as it's easy to timeout
        !            87: the initial handshake; with SLIP, there's no such initial handshake, i.e. you
        !            88: start up one side, and when the other site has its first packet, it will send it
        !            89: over the line.
        !            90: 
        !            91: [RFC1331](http://tools.ietf.org/html/rfc1331) ("The Point-to-Point Protocol
        !            92: (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point
        !            93: Links") and [RFC1332](http://tools.ietf.org/html/rfc1332) ("The PPP Internet
        !            94: Protocol Control Protocol (IPCP)") describe PPP and TCP/IP over PPP. SLIP is
        !            95: defined in [RFC1055](http://tools.ietf.org/html/rfc1055) ("Nonstandard for
        !            96: transmission of IP datagrams over serial lines: SLIP").
        !            97: 
        !            98: ### Ethernet
        !            99: 
        !           100: Ethernet is the medium commonly used to build local area networks (LANs) of
        !           101: interconnected machines within a limited area such as an office, company or
        !           102: university campus. Ethernet is based on a bus structure to which many machines
        !           103: can connect to, and communication always happens between two nodes at a time.
        !           104: When two or more nodes want to talk at the same time, both will restart
        !           105: communication after some timeout. The technical term for this is CSMA/CD
        !           106: (Carrier Sense w/ Multiple Access and Collision Detection).
        !           107: 
        !           108: Initially, Ethernet hardware consisted of a thick (yellow) cable that machines
        !           109: tapped into using special connectors that poked through the cable's outer
        !           110: shielding. The successor of this was called 10base5, which used BNC-type
        !           111: connectors for tapping in special T-connectors and terminators on both ends of
        !           112: the bus. Today, ethernet is mostly used with twisted pair lines which are used
        !           113: in a collapsed bus system that are contained in switches or hubs. The twisted
        !           114: pair lines give this type of media its name - 10baseT for 10 Mbit/s networks,
        !           115: and 100baseT for 100 MBit/s ones. In switched environments there's also the
        !           116: distinction if communication between the node and the switch can happen in half-
        !           117: or in full duplex mode.
        !           118: 
        !           119: ## TCP/IP Address Format
        !           120: 
        !           121: TCP/IP uses 4-byte (32-bit) addresses in the current implementations (IPv4),
        !           122: also called IP-numbers (Internet-Protocol numbers), to address hosts.
        !           123: 
        !           124: TCP/IP allows any two machines to communicate directly. To permit this all hosts
        !           125: on a given network must have a unique IP address. To assure this, IP addresses
        !           126: are administrated by one central organisation, the InterNIC. They give certain
        !           127: ranges of addresses (network-addresses) directly to sites which want to
        !           128: participate in the internet or to internet-providers, which give the addresses
        !           129: to their customers.
        !           130: 
        !           131: If your university or company is connected to the Internet, it has (at least)
        !           132: one such network-address for its own use, usually not assigned by the InterNIC
        !           133: directly, but rather through an Internet Service Provider (ISP).
        !           134: 
        !           135: If you just want to run your private network at home, see below on how to
        !           136: "build" your own IP addresses. However, if you want to connect your machine to
        !           137: the (real :-) Internet, you should get an IP addresses from your local
        !           138: network-administrator or -provider.
        !           139: 
        !           140: IP addresses are usually written in *dotted quad* notation - the four bytes are
        !           141: written down in decimal (most significant byte first), separated by dots. For
        !           142: example, 132.199.15.99 would be a valid address. Another way to write down
        !           143: IP-addresses would be as one 32-bit hex-word, e.g. 0x84c70f63. This is not as
        !           144: convenient as the dotted-quad, but quite useful at times, too. (See below!)
        !           145: 
        !           146: Being assigned a network means nothing else but setting some of the
        !           147: above-mentioned 32 address-bits to certain values. These bits that are used for
        !           148: identifying the network are called network-bits. The remaining bits can be used
        !           149: to address hosts on that network, therefore they are called host-bits. The
        !           150: following figure illustrates the separation.
        !           151: 
        !           152: ![IPv4-addresses are divided into more significant network- and less significant hostbits](/guide/images/ipv4-en-0bits.png)  
        !           153: **IPv4-addresses are divided into more significant network- and less significant hostbits**
        !           154: 
        !           155: In the above example, the network-address is 132.199.0.0 (host-bits are set to 0
        !           156: in network-addresses) and the host's address is 15.99 on that network.
        !           157: 
        !           158: How do you know that the host's address is 16 bit wide? Well, this is assigned
        !           159: by the provider from which you get your network-addresses. In the classless
        !           160: inter-domain routing (CIDR) used today, host fields are usually between as
        !           161: little as 2 to 16 bits wide, and the number of network-bits is written after the
        !           162: network address, separated by a `/`, e.g. 132.199.0.0/16 tells that the network
        !           163: in question has 16 network-bits. When talking about the *size* of a network,
        !           164: it's usual to only talk about it as `/16`, `/24`, etc.
        !           165: 
        !           166: Before CIDR was used, there used to be four classes of networks. Each one starts
        !           167: with a certain bit-pattern identifying it. Here are the four classes:
        !           168: 
        !           169:  * Class A starts with `0` as most significant bit. The next seven bits of a
        !           170:    class A address identify the network, the remaining 24 bit can be used to
        !           171:    address hosts. So, within one class A network there can be 2^24 hosts. It's
        !           172:    not very likely that you (or your university, or company, or whatever) will
        !           173:    get a whole class A address.
        !           174: 
        !           175:    The CIDR notation for a class A network with its eight network bits is an `/8`.
        !           176: 
        !           177:  * Class B starts with `10` as most significant bits. The next 14 bits are used
        !           178:    for the networks address and the remaining 16 bits can be used to address
        !           179:    more than 65000 hosts. Class B addresses are very rarely given out today,
        !           180:    they used to be common for companies and universities before IPv4 address
        !           181:    space went scarce.
        !           182: 
        !           183:    The CIDR notation for a class B network with its 16 network bits is an `/16`.
        !           184: 
        !           185:    Returning to our above example, you can see that 132.199.15.99 (or
        !           186:    0x84c70f63, which is more appropriate here!) is on a class B network, as
        !           187:    0x84... = **10**00... (base 2).
        !           188: 
        !           189:    Therefore, the address 132.199.15.99 can be split into an network-address of
        !           190:    132.199.0.0 and a host-address of 15.99.
        !           191: 
        !           192:  * Class C is identified by the MSBs being `110`, allowing only 256 (actually:
        !           193:    only 254, see below) hosts on each of the 2^21 possible class C networks.
        !           194:    Class C addresses are usually found at (small) companies.
        !           195: 
        !           196:    The CIDR notation for a class C network with its 24 network bits is an `/24`.
        !           197: 
        !           198:  * There are also other addresses, starting with `111`. Those are used for
        !           199:    special purposes (e. g. multicast-addresses) and are not of interest here.
        !           200: 
        !           201: Please note that the bits which are used for identifying the network-class are
        !           202: part of the network-address.
        !           203: 
        !           204: When separating host-addresses from network-addresses, the *netmask* comes in
        !           205: handy. In this mask, all the network-bits are set to `1`, the host-bits are `0`.
        !           206: Thus, putting together IP-address and netmask with a logical AND-function, the
        !           207: network-address remains.
        !           208: 
        !           209: To continue our example, 255.255.0.0 is a possible netmask for 132.199.15.99.
        !           210: When applying this mask, the network-address 132.199.0.0 remains.
        !           211: 
        !           212: For addresses in CIDR notation, the number of network-bits given also says how
        !           213: many of the most significant bits of the address must be set to `1` to get the
        !           214: netmask for the corresponding network. For classful addressing, every
        !           215: network-class has a fixed default netmask assigned:
        !           216: 
        !           217:  * Class A (/8): default-netmask: 255.0.0.0, first byte of address: 1-127
        !           218:  * Class B (/16): default-netmask: 255.255.0.0, first byte of address: 128-191
        !           219:  * Class C (/24): default-netmask: 255.255.255.0, first byte of address: 192-223
        !           220: 
        !           221: Another thing to mention here is the *broadcast-address*. When sending to this
        !           222: address, *all* hosts on the corresponding network will receive the message sent.
        !           223: The broadcast address is characterized by having all host-bits set to `1`.
        !           224: 
        !           225: Taking 132.199.15.99 with its netmask 255.255.0.0 again, the broadcast-address
        !           226: would result in 132.199.255.255.
        !           227: 
        !           228: You'll ask now: But what if I want a host's address to be all bits `0` or `1`?
        !           229: Well, this doesn't work, as network- and broadcast-address must be present!
        !           230: Because of this, a class B (/16) network can contain at most 2^16-2 hosts, a
        !           231: class C (/24) network can hold no more than 2^8-2 = 254 hosts.
        !           232: 
        !           233: Besides all those categories of addresses, there's the special IP-address
        !           234: 127.0.0.1 which always refers to the *local* host, i.e. if you talk to 127.0.0.1
        !           235: you'll talk to yourself without starting any network-activity. This is sometimes
        !           236: useful to use services installed on your own machine or to play around if you
        !           237: don't have other hosts to put on your network.
        !           238: 
        !           239: Let's put together the things we've introduced in this section:
        !           240: 
        !           241:  * *IP-address* -- 32 bit-address, with network- and host-bits.
        !           242:  * *Network-address* -- IP-address with all host bits set to `0`.
        !           243:  * *Netmask* -- 32-bit mask with `1` for network- and `0` for host-bits.
        !           244:  * *Broadcast* -- IP-address with all host bits set `1`.
        !           245:  * *localhost's address* -- The local host's IP address is always 127.0.0.1.
        !           246: 
        !           247: ## Subnetting and Routing
        !           248: 
        !           249: After talking so much about netmasks, network-, host- and other addresses, I
        !           250: have to admit that this is not the whole truth.
        !           251: 
        !           252: Imagine the situation at your university, which usually has a class B (/16)
        !           253: address, allowing it to have up to 2^16 \~= 65534 hosts on that net. Maybe it
        !           254: would be a nice thing to have all those hosts on one single network, but it's
        !           255: simply not possible due to limitations in the transport media commonly used
        !           256: today.
        !           257: 
        !           258: For example, when using thinwire ethernet, the maximum length of the cable is
        !           259: 185 meters. Even with repeaters in between, which refresh the signals, this is
        !           260: not enough to cover all the locations where machines are located. Besides that,
        !           261: there is a maximum number of 1024 hosts on one ethernet wire, and you'll lose
        !           262: quite a bit of performance if you go to this limit.
        !           263: 
        !           264: So, are you hosed now? Having an address which allows more than 60000 hosts, but
        !           265: being bound to media which allows far less than that limit?
        !           266: 
        !           267: Well, of course not! :-)
        !           268: 
        !           269: The idea is to divide the *big* class B net into several smaller networks,
        !           270: commonly called sub-networks or simply subnets. Those subnets are only allowed
        !           271: to have, say, 254 hosts on them (i.e. you divide one big class B network into
        !           272: several class C networks!).
        !           273: 
        !           274: To do this, you adjust your netmask to have more network- and less host-bits on
        !           275: it. This is usually done on a byte-boundary, but you're not forced to do it
        !           276: there. So, commonly your netmask will not be 255.255.0.0 as supposed by a class
        !           277: B network, but it will be set to 255.255.255.0.
        !           278: 
        !           279: In CIDR notation, you now write a `/24` instead of the `/16` to show that 24
        !           280: bits of the address are used for identifying the network and subnet, instead of
        !           281: the 16 that were used before.
        !           282: 
        !           283: This gives you one additional network-byte to assign to each (physical!)
        !           284: network. All the 254 hosts on that subnet can now talk directly to each other,
        !           285: and you can build 256 such class C nets. This should fit your needs.
        !           286: 
        !           287: To explain this better, let's continue our above example. Say our host
        !           288: 132.199.15.99 (I'll call him `dusk` from now; we'll talk about assigning
        !           289: hostnames later) has a netmask of 255.255.255.0 and thus is on the subnet
        !           290: 132.199.15.0/24. Let's furthermore introduce some more hosts so we have
        !           291: something to play around with, see the next figure.
        !           292: 
        !           293: ![Our demo-network](/guide/images/net-pic1.gif)  
        !           294: **Our demo-network**
        !           295: 
        !           296: In the above network, `dusk` can talk directly to `dawn`, as they are both on
        !           297: the same subnet. (There are other hosts attached to the 132.199.15.0/24-subnet
        !           298: but they are not of importance for us now)
        !           299: 
        !           300: But what if `dusk` wants to talk to a host on another subnet?
        !           301: 
        !           302: Well, the traffic will then go through one or more gateways (routers), which are
        !           303: attached to two subnets. Because of this, a router always has two different
        !           304: addresses, one for each of the subnets it is on. The router is functionally
        !           305: transparent, i.e. you don't have to address it to reach hosts on the *other*
        !           306: side. Instead, you address that host directly and the packets will be routed to
        !           307: it correctly.
        !           308: 
        !           309: Example. Let's say `dusk` wants to get some files from the local ftp-server. As
        !           310: `dusk` can't reach `ftp` directly (because it's on a different subnet), all its
        !           311: packets will be forwarded to its "defaultrouter" `rzi` (132.199.15.1), which
        !           312: knows where to forward the packets.
        !           313: 
        !           314: `Dusk` knows the address of its defaultrouter in its network (`rzi`,
        !           315: 132.199.15.1), and it will forward any packets to it which are not on the same
        !           316: subnet, i.e. it will forward all IP-packets in which the third address-byte
        !           317: isn't 15.
        !           318: 
        !           319: The (default)router then gives the packets to the appropriate host, as it's also
        !           320: on the FTP-server's network.
        !           321: 
        !           322: In this example, *all* packets are forwarded to the 132.199.1.0/24-network,
        !           323: simply because it's the network's backbone, the most important part of the
        !           324: network, which carries all the traffic that passes between several subnets.
        !           325: Almost all other networks besides 132.199.15.0/24 are attached to the backbone
        !           326: in a similar manner.
        !           327: 
        !           328: But what if we had hooked up another subnet to 132.199.15.0/24 instead of
        !           329: 132.199.1.0/24? Maybe something the situation displayed in the next figure.
        !           330: 
        !           331: ![Attaching one subnet to another one](/guide/images/net-pic2.gif)  
        !           332: **Attaching one subnet to another one**
        !           333: 
        !           334: When we now want to reach a host which is located in the 132.199.16.0/24-subnet
        !           335: from `dusk`, it won't work routing it to `rzi`, but you'll have to send it
        !           336: directly to `route2` (132.199.15.2). `Dusk` will have to know to forward those
        !           337: packets to `route2` and send all the others to `rzi`.
        !           338: 
        !           339: When configuring `dusk`, you tell it to forward all packets for the
        !           340: 132.199.16.0/24-subnet to `route2`, and all others to `rzi`. Instead of
        !           341: specifying this default as 132.199.1.0/24, 132.199.2.0/24, etc., 0.0.0.0 can be
        !           342: used to set the default-route.
        !           343: 
        !           344: Returning to our demo network, there's a similar problem when `dawn` wants to
        !           345: send to `noon`, which is connected to `dusk` via a serial line running. When
        !           346: looking at the IP-addresses, `noon` seems to be attached to the
        !           347: 132.199.15.0-network, but it isn't really. Instead, `dusk` is used as gateway,
        !           348: and `dawn` will have to send its packets to `dusk`, which will forward them to
        !           349: `noon` then. The way `dusk` is forced into accepting packets that aren't
        !           350: destined at it but for a different host (`noon`) instead is called *proxy arp*.
        !           351: 
        !           352: The same goes when hosts from other subnets want to send to `noon`. They have to
        !           353: send their packets to `dusk` (possibly routed via `rzi`),
        !           354: 
        !           355: ## Name Service Concepts
        !           356: 
        !           357: In the previous sections, when we talked about hosts, we referred to them by
        !           358: their IP-addresses. This was necessary to introduce the different kinds of
        !           359: addresses. When talking about hosts in general, it's more convenient to give
        !           360: them *names*, as we did when talking about routing.
        !           361: 
        !           362: Most applications don't care whether you give them an IP address or a hostname.
        !           363: However, they'll use IP addresses internally, and there are several methods for
        !           364: them to map hostnames to IP addresses, each one with its own way of
        !           365: configuration. In this section we'll introduce the idea behind each method, in
        !           366: the next chapter, we'll talk about the configuration-part.
        !           367: 
        !           368: The mapping from hostnames (and domainnames) to IP-addresses is done by a piece
        !           369: of software called the *resolver*. This is not an extra service, but some
        !           370: library routines which are linked to every application using networking-calls.
        !           371: The resolver will then try to resolve (hence the name ;-) the hostnames you give
        !           372: into IP addresses. See [RFC1034](http://tools.ietf.org/html/rfc1034) ("Domain
        !           373: names - concepts and facilities") and
        !           374: [RFC1035](http://tools.ietf.org/html/rfc1035) ("Domain names - implementation
        !           375: and specification") for details on the resolver.
        !           376: 
        !           377: Hostnames are usually up to 256 characters long, and contain letters, numbers
        !           378: and dashes (`-`); case is ignored.
        !           379: 
        !           380: Just as with networks and subnets, it's possible (and desirable) to group hosts
        !           381: into domains and subdomains. When getting your network-address, you usually also
        !           382: obtain a domainname by your provider. As with subnets, it's up to you to
        !           383: introduce subdomains. Other as with IP-addresses, (sub)domains are not directly
        !           384: related to (sub)nets; for example, one domain can contain hosts from several
        !           385: subnets.
        !           386: 
        !           387: Our demo-network shows this: Both subnets 132.199.1.0/24 and 132.199.15.0/24
        !           388: (and others) are part of the subdomain `rz.uni-regensburg.de`. The domain the
        !           389: University of Regensburg got from its IP-provider is `uni-regensburg.de` (`.de`
        !           390: is for Deutschland, Germany), the subdomain `rz` is for Rechenzentrum, computing
        !           391: center.
        !           392: 
        !           393: Hostnames, subdomain- and domainnames are separated by dots (`.`). It's also
        !           394: possible to use more than one stage of subdomains, although this is not very
        !           395: common. An example would be `fox_in.socs.uts.edu.au`.
        !           396: 
        !           397: A hostname which includes the (sub)domain is also called a fully qualified
        !           398: domain name (FQDN). For example, the IP-address 132.199.15.99 belongs to the
        !           399: host with the FQDN `dusk.rz.uni-regensburg.de`.
        !           400: 
        !           401: Further above I told you that the IP-address 127.0.0.1 always belongs to the
        !           402: local host, regardless what's the `real` IP-address of the host. Therefore,
        !           403: 127.0.0.1 is always mapped to the name `localhost`.
        !           404: 
        !           405: The three different ways to translate hostnames into IP addresses are:
        !           406: `/etc/hosts`, the Domain Name Service (DNS) and the Network Information Service
        !           407: (NIS).
        !           408: 
        !           409: ### `/etc/hosts`
        !           410: 
        !           411: The first and simplest way to translate hostnames into IP-addresses is by using
        !           412: a table telling which IP address belongs to which hostname(s). This table is
        !           413: stored in the file `/etc/hosts` and has the following format:
        !           414: 
        !           415:     IP-address        hostname [nickname [...]]
        !           416: 
        !           417: Lines starting with a hash mark (`#`) are treated as comments. The other lines
        !           418: contain one IP-address and the corresponding hostname(s).
        !           419: 
        !           420: It's not possible for a hostname to belong to several IP addresses, even if I
        !           421: made you think so when talking about routing. `rzi` for example has really two
        !           422: distinct names for each of its two addresses: `rzi` and `rzia` (but please don't
        !           423: ask me which name belongs to which address!).
        !           424: 
        !           425: Giving a host several nicknames can be convenient if you want to specify your
        !           426: favorite host providing a special service with that name, as is commonly done
        !           427: with FTP-servers. The first (leftmost) name is usually the real (canonical) name
        !           428: of the host.
        !           429: 
        !           430: Besides giving nicknames, it's also convenient to give a host's full name
        !           431: (including domain) as its canonical name, and using only its hostname (without
        !           432: domain) as a nickname.
        !           433: 
        !           434: *Important:* There *must* be an entry mapping localhost to 127.0.0.1 in
        !           435: `/etc/hosts`!
        !           436: 
        !           437: ### Domain Name Service (DNS)
        !           438: 
        !           439: `/etc/hosts` bears an inherent problem, especially in big networks: when one
        !           440: host is added or one host's address changes, all the `/etc/hosts` files on all
        !           441: machines have to be changed! This is not only time-consuming, it's also very
        !           442: likely that there will be some errors and inconsistencies, leading to problems.
        !           443: 
        !           444: Another approach is to hold only one hostnames-table (-database) for a network,
        !           445: and make all the clients query that *nameserver*. Updates will be made only on
        !           446: the nameserver.
        !           447: 
        !           448: This is the basic idea behind the Domain Name Service (DNS).
        !           449: 
        !           450: Usually, there's one nameserver for each domain (hence DNS), and every host
        !           451: (client) in that domain knows which domain it is in and which nameserver to
        !           452: query for its domain.
        !           453: 
        !           454: When the DNS gets a query about a host which is not in its domain, it will
        !           455: forward the query to a DNS which is either the DNS of the domain in question or
        !           456: knows which DNS to ask for the specified domain. If the DNS forwarded the query
        !           457: doesn't know how to handle it, it will forward that query again to a DNS one
        !           458: step higher. This is not ad infinitum, there are several *root*-servers, which
        !           459: know about any domain.
        !           460: 
        !           461: See [[the separate article|guide/dns]] for details on DNS.
        !           462: 
        !           463: ### Network Information Service (NIS/YP)
        !           464: 
        !           465: Yellow Pages (YP) was invented by Sun Microsystems. The name has been changed
        !           466: into Network Information Service (NIS) because YP was already a trademark of the
        !           467: British telecom. So, when I'm talking about NIS you'll know what I mean. ;-)
        !           468: 
        !           469: There are quite some configuration files on a Unix-system, and often it's
        !           470: desired to maintain only one set of those files for a couple of hosts. Those
        !           471: hosts are grouped together in a NIS-domain (which has *nothing* to do with the
        !           472: domains built by using DNS!) and are usually contained in one workstation
        !           473: cluster.
        !           474: 
        !           475: Examples for the config-files shared among those hosts are `/etc/passwd`,
        !           476: `/etc/group` and - last but not least - `/etc/hosts`.
        !           477: 
        !           478: So, you can "abuse" NIS for getting a unique name-to-address-translation on all
        !           479: hosts throughout one (NIS-)domain.
        !           480: 
        !           481: There's only one drawback, which prevents NIS from actually being used for that
        !           482: translation: In contrast to the DNS, NIS provides no way to resolve hostnames
        !           483: which are not in the hosts-table. There's no hosts "one level up" which the
        !           484: NIS-server can query, and so the translation will fail! Suns NIS+ takes measures
        !           485: against that problem, but as NIS+ is only available on Solaris-systems, this is
        !           486: of little use for us now.
        !           487: 
        !           488: Don't get me wrong: NIS is a fine thing for managing e.g. user-information
        !           489: (`/etc/passwd`, ...) in workstation-clusters, it's simply not too useful for
        !           490: resolving hostnames.
        !           491: 
        !           492: ### Other
        !           493: 
        !           494: The name resolving methods described above are what's used commonly today to
        !           495: resolve hostnames into IP addresses, but they aren't the only ones. Basically,
        !           496: every database mechanism would do, but none is implemented in NetBSD. Let's have
        !           497: a quick look what you may encounter.
        !           498: 
        !           499: With NIS lacking hierarchy in data structures, NIS+ is intended to help out in
        !           500: that field. Tables can be setup in a way so that if a query cannot be answered
        !           501: by a domain's server, there can be another domain "above" that might be able to
        !           502: do so. E.g. you could choose to have a domain that lists all the hosts (users,
        !           503: groups, ...) that are valid in the whole company, one that defines the same
        !           504: for each division, etc. NIS+ is not used a lot today, even Sun went back to
        !           505: ship back NIS by default.
        !           506: 
        !           507: Last century, the X.500 standard was designed to accommodate both simple
        !           508: databases like `/etc/hosts` as well as complex, hierarchical systems as can be
        !           509: found e.g. in DNS today. X.500 wasn't really a success, mostly due to the fact
        !           510: that it tried to do too much at the same time. A cut-down version is available
        !           511: today as the Lightweight Directory Access Protocol (LDAP), which is becoming
        !           512: popular in the last years to manage data like users but also hosts and others in
        !           513: small to medium sized organisations.
        !           514: 
        !           515: ## Next generation Internet protocol - IPv6
        !           516: 
        !           517: ### The Future of the Internet
        !           518: 
        !           519: According to experts, the Internet as we know it will face a serious problem in
        !           520: a few years. Due to its rapid growth and the limitations in its design, there
        !           521: will be a point at which no more free addresses are available for connecting new
        !           522: hosts. At that point, no more new web servers can be set up, no more users can
        !           523: sign up for accounts at ISPs, no more new machines can be setup to access the
        !           524: web or participate in online games - some people may call this a serious
        !           525: problem.
        !           526: 
        !           527: Several approaches have been made to solve the problem. A very popular one is to
        !           528: not assign a worldwide unique address to every user's machine, but rather to
        !           529: assign them *private* addresses, and hide several machines behind one official,
        !           530: globally unique address. This approach is called *Network Address Translation*
        !           531: (NAT, also known as IP Masquerading). It has problems, as the machines hidden
        !           532: behind the global address can't be addressed, and as a result of this, opening
        !           533: connections to them - which is used in online gaming, peer to peer networking,
        !           534: etc. - is not possible. For a more in-depth discussion of the drawbacks of NAT,
        !           535: see \[[[RFC3027|guide/index#bilbiography]]\] ("Protocol Complications with the
        !           536: IP Network Address Translator").
        !           537: 
        !           538: A different approach to the problem of internet addresses getting scarce is to
        !           539: abandon the old Internet protocol with its limited addressing capabilities, and
        !           540: use a new protocol that does not have these limitations. The protocol - or
        !           541: actually, a set of protocols - used by machines connected to form today's
        !           542: Internet is know as the TCP/IP (Transmission Control Protocol, Internet
        !           543: Protocol) suite, and version 4 currently in use has all the problems described
        !           544: above. Switching to a different protocol version that does not have these
        !           545: problems of course requires for a 'better' version to be available, which
        !           546: actually is. Version 6 of the Internet Protocol (IPv6) does fulfill any possible
        !           547: future demands on address space, and also addresses further features such as
        !           548: privacy, encryption, and better support of mobile computing.
        !           549: 
        !           550: Assuming a basic understanding of how today's IPv4 works, this text is intended
        !           551: as an introduction to the IPv6 protocol. The changes in address formats and name
        !           552: resolution are covered. With the background given here, the next sections will
        !           553: show how to use IPv6 even if your ISP doesn't offer it by using a simple yet
        !           554: efficient transition mechanism called 6to4. The goal is to get online with IPv6,
        !           555: giving an example configuration for NetBSD.
        !           556: 
        !           557: ### What good is IPv6?
        !           558: 
        !           559: When telling people to migrate from IPv4 to IPv6, the question you usually hear
        !           560: is *why?*. There are actually a few good reasons to move to the new version:
        !           561: 
        !           562:  * Bigger address space
        !           563:  * Support for mobile devices
        !           564:  * Built-in security
        !           565: 
        !           566: #### Bigger Address Space
        !           567: 
        !           568: The bigger address space that IPv6 offers is the most obvious enhancement it has
        !           569: over IPv4. While today's internet architecture is based on 32-bit wide
        !           570: addresses, the new version has 128 bit available for addressing. Thanks to the
        !           571: enlarged address space, work-arounds like NAT don't have to be used any more.
        !           572: This allows full, unconstrained IP connectivity for today's IP based machines as
        !           573: well as upcoming mobile devices like PDAs and cell phones will benefit from full
        !           574: IP access through GPRS and UMTS.
        !           575: 
        !           576: #### Mobility
        !           577: 
        !           578: When mentioning mobile devices and IP, another important point to note is that
        !           579: some special protocol is needed to support mobility, and implementing this
        !           580: protocol - called *Mobile IP* - is one of the requirements for every IPv6 stack.
        !           581: Thus, if you have IPv6 going, you have support for roaming between different
        !           582: networks, with everyone being updated when you leave one network and enter the
        !           583: other one. Support for roaming is possible with IPv4 too, but there are a number
        !           584: of hoops that need to be jumped in order to get things working. With IPv6,
        !           585: there's no need for this, as support for mobility was one of the design
        !           586: requirements for IPv6. See [RFC3024](http://tools.ietf.org/html/rfc3024)
        !           587: ("Reverse Tunneling for Mobile IP") for some more information on the issues that
        !           588: need to be addressed with Mobile IP on IPv4.
        !           589: 
        !           590: #### Security
        !           591: 
        !           592: Besides support for mobility, security was another requirement for the successor
        !           593: to today's Internet Protocol version. As a result, IPv6 protocol stacks are
        !           594: required to include IPsec. IPsec allows authentication, encryption and
        !           595: compression of any IP traffic. Unlike application level protocols like SSL or
        !           596: SSH, all IP traffic between two nodes can be handled, without adjusting any
        !           597: applications. The benefit of this is that all applications on a machine can
        !           598: benefit from encryption and authentication, and that policies can be set on a
        !           599: per-host (or even per-network) base, not per application/service. An
        !           600: introduction to IPsec with a roadmap to the documentation can be found in
        !           601: [RFC2411](http://tools.ietf.org/html/rfc2411) ("IP Security Document Roadmap"),
        !           602: the core protocol is described in [RFC2401](http://tools.ietf.org/html/rfc2401)
        !           603: ("Security Architecture for the Internet Protocol").  
        !           604: 
        !           605: ### Changes to IPv4
        !           606: 
        !           607: After giving a brief overview of all the important features of IPv6, we'll go
        !           608: into the details of the basics of IPv6 here. A brief understanding of how IPv4
        !           609: works is assumed, and the changes in IPv6 will be highlighted. Starting with
        !           610: IPv6 addresses and how they're split up we'll go into the various types of
        !           611: addresses there are, what became of broadcasts, then after discussing the IP
        !           612: layer go into changes for name resolving and what's new in DNS for IPv6.
        !           613: 
        !           614: #### Addressing
        !           615: 
        !           616: An IPv4 address is a 32 bit value, that's usually written in *dotted quad*
        !           617: representation, where each *quad* represents a byte value between 0 and 255, for
        !           618: example:
        !           619: 
        !           620:     127.0.0.1
        !           621: 
        !           622: This allows a theoretical number of 2^32 or \~4 billion hosts to be connected on
        !           623: the internet today. Due to grouping, not all addresses are available today.
        !           624: 
        !           625: IPv6 addresses use 128 bit, which results in 2^128 theoretically addressable
        !           626: hosts. This allows for a Really Big number of machines to addressed, and it sure
        !           627: fits all of today's requirements plus all those nifty PDAs and cell phones with
        !           628: IP phones in the near future without any sweat. When writing IPv6 addresses,
        !           629: they are usually divided into groups of 16 bits written as four hex digits, and
        !           630: the groups are separated by colons. An example is:
        !           631: 
        !           632:     fe80::2a0:d2ff:fea5:e9f5
        !           633: 
        !           634: This shows a special thing - a number of consecutive zeros can be abbreviated by
        !           635: a single `::` once in the IPv6 address. The above address is thus equivalent to
        !           636: `fe80:0:00:000:2a0:d2ff:fea5:e9f5` - leading zeros within groups can be omitted,
        !           637: and only one `::` can be used in an IPv6 address.
        !           638: 
        !           639: To make addresses manageable, they are split in two parts, which are the bits
        !           640: identifying the network a machine is on, and the bits that identify a machine on
        !           641: a (sub)network. The bits are known as netbits and hostbits, and in both IPv4 and
        !           642: IPv6, the netbits are the *left*, most significant bits of an IP address, and
        !           643: the host bits are the *right*, least significant bits, as shown in the following
        !           644: figure:
        !           645: 
        !           646: ![IPv6-addresses are divided into more significant network- and less significant hostbits, too](/guide/images/ipv6-en-0bits.gif)  
        !           647: **IPv6-addresses are divided into more significant network- and less significant hostbits, too**
        !           648: 
        !           649: In IPv4, the border is drawn with the aid of the netmask, which can be used to
        !           650: mask all net/host bits. Typical examples are 255.255.0.0 that uses 16 bit for
        !           651: addressing the network, and 16 bit for the machine, or 255.255.255.0 which takes
        !           652: another 8 bit to allow addressing 256 subnets on e.g. a class B net.
        !           653: 
        !           654: When addressing switched from classful addressing to CIDR routing, the borders
        !           655: between net and host bits stopped being on 8 bit boundaries, and as a result the
        !           656: netmasks started looking ugly and not really manageable. As a replacement, the
        !           657: number of network bits is used for a given address, to denote the border, e.g.
        !           658: 
        !           659:     10.0.0.0/24
        !           660: 
        !           661: is the same as a netmask of 255.255.255.0 (24 1-bits). The same scheme is used
        !           662: in IPv6:
        !           663: 
        !           664:     2001:638:a01:2::/64
        !           665: 
        !           666: tells us that the address used here has the first (leftmost) 64 bits used as the
        !           667: network address, and the last (rightmost) 64 bits are used to identify the
        !           668: machine on the network. The network bits are commonly referred to as (network)
        !           669: *prefix*, and the *prefixlen* here would be 64 bits.
        !           670: 
        !           671: Common addressing schemes found in IPv4 are the (old) class B and class C nets.
        !           672: With a class C network (/24), you get 24 bits assigned by your provider, and it
        !           673: leaves 8 bits to be assigned by you. If you want to add any subnetting to that,
        !           674: you end up with *uneven* netmasks that are a bit nifty to deal with. Easier for
        !           675: such cases are class B networks (/16), which only have 16 bits assigned by the
        !           676: provider, and that allow subnetting, i.e. splitting of the rightmost bits into
        !           677: two parts. One to address the on-site subnet, and one to address the hosts on
        !           678: that subnet. Usually, this is done on byte (8 bit) boundaries. Using a netmask
        !           679: of 255.255.255.0 (or a /24 prefix) allows flexible management even of bigger
        !           680: networks here. Of course there is the upper limit of 254 machines per subnet,
        !           681: and 256 subnets.
        !           682: 
        !           683: With 128 bits available for addressing in IPv6, the scheme commonly used is the
        !           684: same, only the fields are wider. Providers usually assign /48 networks, which
        !           685: leaves 16 bits for a subnetting and 64 hostbits.
        !           686: 
        !           687: ![IPv6-addresses have a similar structure to class B addresses](/guide/images/ipv6-en-6adrformats.gif)
        !           688: **IPv6-addresses have a similar structure to class B addresses**
        !           689: 
        !           690: Now while the space for network and subnets here is pretty much ok, using 64
        !           691: bits for addressing hosts seems like a waste. It's unlikely that you will want
        !           692: to have several billion hosts on a single subnet, so what is the idea behind
        !           693: this?
        !           694: 
        !           695: The idea behind fixed width 64 bit wide host identifiers is that they aren't
        !           696: assigned manually as it's usually done for IPv4 nowadays. Instead, IPv6 host
        !           697: addresses are recommended (not mandatory!) to be built from so-called EUI64
        !           698: addresses. EUI64 addresses are - as the name says - 64 bit wide, and derived
        !           699: from MAC addresses of the underlying network interface. E.g. for ethernet, the 6
        !           700: byte (48 bit) MAC address is usually filled with the hex bits `fffe` in the
        !           701: middle and a bit is set to mark the address as unique (which is true for
        !           702: Ethernet), e.g. the MAC address
        !           703: 
        !           704:     01:23:45:67:89:ab
        !           705: 
        !           706: results in the EUI64 address
        !           707: 
        !           708:     03:23:45:ff:fe:67:89:ab
        !           709: 
        !           710: which again gives the host bits for the IPv6 address as
        !           711: 
        !           712:     ::0323:45ff:fe67:89ab
        !           713: 
        !           714: These host bits can now be used to automatically assign IPv6 addresses to hosts,
        !           715: which supports autoconfiguration of IPv6 hosts - all that's needed to get a
        !           716: complete IPv6 address is the first (net/subnet) bits, and IPv6 also offers a
        !           717: solution to assign them automatically.
        !           718: 
        !           719: When on a network of machines speaking IP, there's usually one router which acts
        !           720: as the gateway to outside networks. In IPv6 land, this router will send *router
        !           721: advertisement* information, which clients are expected to either receive during
        !           722: operation or to solicit upon system startup. The router advertisement
        !           723: information includes data on the router's address, and which address prefix it
        !           724: routes. With this information and the host-generated EUI64 address, an IPv6-host
        !           725: can calculate its IP address, and there is no need for manual address
        !           726: assignment. Of course routers still need some configuration.
        !           727: 
        !           728: The router advertisement information they create are part of the Neighbor
        !           729: Discovery Protocol (NDP, see [RFC2461](http://tools.ietf.org/html/rfc2461)
        !           730: ("Neighbor Discovery for IP Version 6 (IPv6)")), which is the successor to
        !           731: IPv4's ARP protocol. In contrast to ARP, NDP does not only do lookup of IPv6
        !           732: addresses for MAC addresses (the neighbor solicitation/advertisement part), but
        !           733: also does a similar service for routers and the prefixes they serve, which is
        !           734: used for autoconfiguration of IPv6 hosts as described in the previous paragraph.
        !           735: 
        !           736: #### Multiple Addresses
        !           737: 
        !           738: In IPv4, a host usually has one IP address per network interface or even per
        !           739: machine if the IP stack supports it. Only very rare applications like web
        !           740: servers result in machines having more than one IP address. In IPv6, this is
        !           741: different. For each interface, there is not only a globally unique IP address,
        !           742: but there are two other addresses that are of interest: The link local address,
        !           743: and the site local address. The link local address has a prefix of fe80::/64,
        !           744: and the host bits are built from the interface's EUI64 address. The link local
        !           745: address is used for contacting hosts and routers on the same network only, the
        !           746: addresses are not visible or reachable from different subnets. If wanted,
        !           747: there's the choice of either using global addresses (as assigned by a provider),
        !           748: or using site local addresses. Site local addresses are assigned the network
        !           749: address fec0::/10, and subnets and hosts can be addressed just as for
        !           750: provider-assigned networks. The only difference is, that the addresses will not
        !           751: be visible to outside machines, as these are on a different network, and their
        !           752: *site local* addresses are in a different physical net (if assigned at all). As
        !           753: with the 10/8 network in IPv4, site local addresses can be used, but don't have
        !           754: to. For IPv6 it's most common to have hosts assigned a link-local and a global
        !           755: IP address. Site local addresses are rather uncommon today, and are no
        !           756: substitute for globally unique addresses if global connectivity is required.
        !           757: 
        !           758: #### Multicasting
        !           759: 
        !           760: In IP land, there are three ways to talk to a host: unicast, broadcast and
        !           761: multicast. The most common one is by talking to it directly, using its unicast
        !           762: address. In IPv4, the unicast address is the *normal* IP address assigned to a
        !           763: single host, with all address bits assigned. The broadcast address used to
        !           764: address all hosts in the same IP subnet has the network bits set to the network
        !           765: address, and all host bits set to `1` (which can be easily done using the
        !           766: netmask and some bit operations). Multicast addresses are used to reach a number
        !           767: of hosts in the same multicast group, which can be machines spread over the
        !           768: whole internet. Machines must join multicast groups explicitly to participate,
        !           769: and there are special IPv4 addresses used for multicast addresses, allocated
        !           770: from the 224/8 subnet. Multicast isn't used very much in IPv4, and only few
        !           771: applications like the MBone audio and video broadcast utilities use it.
        !           772: 
        !           773: In IPv6, unicast addresses are used the same as in IPv4, no surprise there - all
        !           774: the network and host bits are assigned to identify the target network and
        !           775: machine. Broadcasts are no longer available in IPv6 in the way they were in
        !           776: IPv4, this is where multicasting comes into play. Addresses in the ff::/8
        !           777: network are reserved for multicast applications, and there are two special
        !           778: multicast addresses that supersede the broadcast addresses from IPv4. One is the
        !           779: *all routers* multicast address, the others is for *all hosts*. The addresses
        !           780: are specific to the subnet, i.e. a router connected to two different subnets can
        !           781: address all hosts/routers on any of the subnets it's connected to. Addresses
        !           782: here are:
        !           783: 
        !           784:  * ff0*`X`*::1 for all hosts and
        !           785:  * ff0*`X`*::2 for all routers,
        !           786: 
        !           787: where `X` is the scope ID of the link here, identifying the network. Usually
        !           788: this starts from `1` for the *node local* scope, `2` for the first link, etc.
        !           789: Note that it's perfectly ok for two network interfaces to be attached to one
        !           790: link, thus resulting in double bandwidth:
        !           791: 
        !           792: ![Several interfaces attached to a link result in only one scope ID for the link](/guide/images/ipv6-en-4scope.gif)  
        !           793: **Several interfaces attached to a link result in only one scope ID for the link**
        !           794: 
        !           795: One use of the *all hosts* multicast is in the neighbor solicitation code of
        !           796: NDP, where any machine that wants to communicate with another machine sends out
        !           797: a request to the *all hosts* group, and the machine in question is expected to
        !           798: respond.
        !           799: 
        !           800: #### Name Resolving in IPv6
        !           801: 
        !           802: After talking a lot about addressing in IPv6, anyone still here will hope that
        !           803: there's a proper way to abstract all these long & ugly IPv6 addresses with some
        !           804: nice hostnames as one can do in IPv4, and of course there is.
        !           805: 
        !           806: Hostname to IP address resolving in IPv4 is usually done in one of three ways:
        !           807: using a simple table in `/etc/hosts`, by using the Network Information Service
        !           808: (NIS, formerly YP) or via the Domain Name System (DNS).
        !           809: 
        !           810: As of this writing, NIS/NIS+ over IPv6 is currently only available on Solaris 8,
        !           811: for both database contents and transport, using a RPC extension.
        !           812: 
        !           813: Having a simple address<-\>name map like `/etc/hosts` is supported in all IPv6
        !           814: stacks. With the KAME implementation used in NetBSD, `/etc/hosts` contains IPv6
        !           815: addresses as well as IPv4 addresses. A simple example is the `localhost` entry
        !           816: in the default NetBSD installation:
        !           817: 
        !           818:     127.0.0.1               localhost
        !           819:     ::1                     localhost
        !           820: 
        !           821: For DNS, there are no fundamentally new concepts. IPv6 name resolving is done
        !           822: with AAAA records that - as the name implies - point to an entity that's four
        !           823: times the size of an A record. The AAAA record takes a hostname on the left
        !           824: side, just as A does, and on the right side there's an IPv6 address, e.g.
        !           825: 
        !           826:     noon            IN      AAAA    3ffe:400:430:2:240:95ff:fe40:4385
        !           827: 
        !           828: For reverse resolving, IPv4 uses the in-addr.arpa zone, and below that it writes
        !           829: the bytes (in decimal) in reversed order, i.e. more significant bytes are more
        !           830: right. For IPv6 this is similar, only that hex digits representing 4 bits are
        !           831: used instead of decimal numbers, and the resource records are also under a
        !           832: different domain, ip6.int.
        !           833: 
        !           834: So to have the reverse resolving for the above host, you would put into your
        !           835: `/etc/named.conf` something like:
        !           836: 
        !           837:     zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {
        !           838:           type master;
        !           839:           file "db.reverse";
        !           840:     };
        !           841: 
        !           842: and in the zone file db.reverse you put (besides the usual records like SOA and
        !           843: NS):
        !           844: 
        !           845:     5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0 IN   PTR   noon.ipv6.example.com.
        !           846: 
        !           847: The address is reversed here, and written down one hex digit after the other,
        !           848: starting with the least significant (rightmost) one, separating the hex digits
        !           849: with dots, as usual in zone files.
        !           850: 
        !           851: One thing to note when setting up DNS for IPv6 is to take care of the DNS
        !           852: software version in use. BIND 8.x does understand AAAA records, but it does not
        !           853: offer name resolving via IPv6. You need BIND 9.x for that. Beyond that, BIND 9.x
        !           854: supports a number of resource records that are currently being discussed but not
        !           855: officially introduced yet. The most noticeable one here is the A6 record which
        !           856: allows easier provider/prefix changing.
        !           857: 
        !           858: To sum up, this section talked about the technical differences between IPv4 and
        !           859: IPv6 for addressing and name resolving. Some details like IP header options, QoS
        !           860: and flows were deliberately left out to not make this document more complex than
        !           861: necessary.
        !           862: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb