|
|
|
| Daemon News Ezine | BSD News | BSD Mall | BSD Support Forum | BSD Advocacy | BSD Updates |
Joining the 6boneMichael Paddon, <michael@paddon.org>
Why Is IPv6 Interesting?By now, you've probably heard of the next generation Internet Protocol, IPv6. While it provides many improvements and new capabilities, the driving force behind its adoption is likely to be the much larger (and more flexible) address space that it defines. Continuing growth in the population of IP enabled devices has already put severe stress on address allocation and the routing infrastructure. The roll out of new enabling technologies such as 3G wireless and broadband to the home will predictably create a new wave of demand. One way of dealing with these pressures is to use address translation technologies and accept the consequential degeneration and balkanisation of global connectivity. Another path is transition to a networking technology that can support the demands of today and tomorrow. In discussing this matter with my peers, I am often surprised by an ingrained reluctance to change, usually conjoined with an assertion that NAT solves the addressing problem. To me this is akin to defending the DOS 640K limit, and shows a marked lack of imagination about how we might be using the Net in ten or twenty years time. Where Do I Get IPv6 Software?The first step to using IPv6 is, of course, finding a suitable implementation. The good news is that, if you are using open source, chances are that you are already IPv6 ready. Current versions of {Free, Net, Open}BSD and Linux have a working version 6 stack out of the box. Solaris, AIX and MacOS X are reportedly in the same situation, whilst users of other flavours of Unix should check with their vendors. If you want to run IPv6 on your router appliance, you'll find that most major brands have the code either in beta test or ready for production. IPv6 stacks are designed to cohabit peacefully with IPv4 (the "classic" version), and a router or host can use both concurrently. This is the first step in the migration to the new standard. There will never be a "flag day" when everyone switches to IPv6; rather, we will see a gradual increase in version 6 traffic over a number of years until it is the dominant form of internet datagram. For instance, by using ping6(8) on my OpenBSD box, I can see that I am already running IPv6 without any special effort:
$ ping6 -c 5 localhost
PING6(56=40+8+8 bytes) ::1 --> ::1
16 bytes from ::1, icmp_seq=0 hlim=64 time=0.16 ms
16 bytes from ::1, icmp_seq=1 hlim=64 time=0.144 ms
16 bytes from ::1, icmp_seq=2 hlim=64 time=0.136 ms
16 bytes from ::1, icmp_seq=3 hlim=64 time=0.14 ms
16 bytes from ::1, icmp_seq=4 hlim=64 time=0.131 ms
--- ::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.131/0.142/0.160/0.010 ms
All the examples in this article were produced using OpenBSD 2.9. The commands should be pretty much the same for all the BSDs (although your interface names and addresses will differ), whilst other Unix variants may require slightly different invocations. Check your local man(1) pages for details. Using IPv6 on a LANThe next obvious step is to get two machines on your LAN communicating using IPv6. The machine on my desk, called lum, is equipped with a "rl" network card with the following configuration:
lum$ ifconfig rl0
rl0: flags=8843
You can see that there is an IPv6 address configured for the interface, although it looks very different and perhaps a little awkward, compared to a classic quad number address. Don't worry - it will all start to make sense soon enough, and remember that in the real world we type in DNS names and not addresses anyway. This address was automatically generated and configured when I enabled the network interface card, based on its underlying MAC address (yes, there is a standard for this). It is called a "link-local" address and is only valid on the network that the interface is directly connected to. The ability to auto-configure addresses, without engaging in a protocol such as RARP, is a powerful and robust bootstrap mechanism. An IPv6 address is 128 bits long (that's right - no more running out of address space until we go extra-terrestrial), and is conventionally written as 8 lots of 16 bit hex numbers, separated by colons. You are allowed to have one instance of two consecutive colons to show that all the digits in between are zeroes. For instance, "::1", the loopback address, is the same as "0:0:0:0:0:0:0:1" but a lot easier to type. IPv6 address come in many flavours, which can be distinguished by the first few bits of the address. A few common examples are:
Since link-local addresses are only good for a particular network, you have to specify the network interface as well. Conventionally, this is done with a trailing percent sign plus the interface name. So now the address "fe80::260:67ff:fe06:19a5%rl0" actually makes sense. I have another machine, called gunbuster, with a "de" card on the same LAN. Let's check out the interface configuration:
gunbuster$ ifconfig de0
de0: flags=8863
I can ping gunbuster from lum, using the existing link-local addresses. Note that I have to remember to tack lum's network card name to the end to gunbuster's link-local address, or I'll get a "no route to host" error.
lum$ ping6 -c 5 fe80::200:c0ff:fe4b:fdb%rl0
PING6(56=40+8+8 bytes) fe80::260:67ff:fe06:19a5%rl0
--> fe80::200:c0ff:fe4b:fdb%rl0
16 bytes from fe80::200:c0ff:fe4b:fdb%rl0, icmp_seq=0 hlim=64 time=0.445 ms
16 bytes from fe80::200:c0ff:fe4b:fdb%rl0, icmp_seq=1 hlim=64 time=0.44 ms
16 bytes from fe80::200:c0ff:fe4b:fdb%rl0, icmp_seq=2 hlim=64 time=0.437 ms
16 bytes from fe80::200:c0ff:fe4b:fdb%rl0, icmp_seq=3 hlim=64 time=0.441 ms
16 bytes from fe80::200:c0ff:fe4b:fdb%rl0, icmp_seq=4 hlim=64 time=0.443 ms
--- fe80::200:c0ff:fe4b:fdb%rl0 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.437/0.441/0.445/0.003 ms
Sitewide AddressingNo one in their right mind would use a link-local address for anything but low level configuration and diagnosis. If you are using IPv6 solely within a given organisation, the next step you can take is to assign site-wide addresses to your nodes. As with IPv4, you can technically assign any addresses you like, but you would be smart to stick to the defined "site-local" scheme and ensure future interoperability. Site-local addresses are rather like the RFC-1918 addresses used internally by many organisations today, in that they are guaranteed to never clash with a globally routable address. Site-local addresses are currently specified to be of the form "fec0:0:0:S:I:I:I:I", where "S" is the 16 bit subnet identifier, and "I:I:I:I" is the 64 bit node id. You can assign subnet and node identifiers as you see fit. There is a defined algorithm, for instance, for turning a 48 bit ethernet MAC address into a node id (which is the same one used for creating link-local addresses). However, I prefer to assign addresses manually, because I have only a few machines and I don't like addresses to change when I swap interface cards. I can assign site-local addresses to my machines with a few simple commands:
gunbuster$ ifconfig de0 inet6 alias fec0::1
lum$ ifconfig rl0 inet6 alias fec0::2
lum$ ping6 -c 5 fec0::1
PING6(56=40+8+8 bytes) fec0::2 --> fec0::1
16 bytes from fec0::1, icmp_seq=0 hlim=64 time=0.557 ms
16 bytes from fec0::1, icmp_seq=1 hlim=64 time=0.444 ms
16 bytes from fec0::1, icmp_seq=2 hlim=64 time=0.439 ms
16 bytes from fec0::1, icmp_seq=3 hlim=64 time=0.429 ms
16 bytes from fec0::1, icmp_seq=4 hlim=64 time=0.421 ms
--- fec0::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.421/0.458/0.557/0.050 ms
When you get sick of typing in raw addresses, you can map them to names in your /etc/hosts file or your DNS service. Modern implementations of named support the "AAAA" record type, which is used just like an "A" record only it holds an IPv6 address. Talk to your friendly DNS administrator for more information.
Global AddressingBefore you can connect to other IPv6 sites, you need to understand the structure of "aggregatable global unicast" addresses, which are the types of addresses being allocated for wide area interconnectivity. It should be noted, however, that only 1/8 of the total possible address space is reserved for this format, leaving room for the future development of alternative global addressing schemes. One problem that a huge address space does not address (and in fact could exacerbate) is that of routing table growth. Without some kind of topological structure, you potentially need a route for every destination in the universe which clearly does not scale well. As you might expect, aggregatable global unicast addresses deal with this problem by aggregating routes, in much the same way as is done today with the CIDR mechanism. Hence, addresses have a well defined structure:
What are all these TLA's? Addresses are organised in a four tiered topological hierarchy:
The TLA and NLA identifers are together referred to as the "public topology", since they define the collection of organisations which provide public transit services. The reserved bits between the TLA and NLA fields are there to allow for expansion of either or both in the future as demand and technical capacity dictates. There may be additional structure imposed at the NLA and SLA level, created by the way that the identifiers are handed out. For instance, if a regional registry is given a contiguous block of NLA identifiers, it can break it up into sub-blocks for different carriers, who may in turn break their blocks up into smaller allocations again. However, the Interface ID level may not be broken up in this way as the various standards for generating these identifiers demand a 64 bit space. To date, three TLA assignments have been made, each for a different purpose:
In practice, each of these TLAs structures its subordinate address space differently:
Global ConnectivityDon't you ever wonder who bought the first telephone? Lord knows, that salesman deserved his commission! Early adopters of IPv6 face a similar problem. How do you build critical mass without a backbone, and how do you build a backbone without critical mass? The answer is to build a virtual backbone, tunnelling IPv6 datagrams encapsulated in IPv4 packets. In other words, when two version 6 nodes wish to exchange traffic, they actually send version 4 packets whose payload is the IPv6 datagram. Each tunnel is a point to point link, and operates essentially as a physical connection. With this technology, it is possible to establish a globally operational IPv6 network immediately, with native IPv6 physical links being established as traffic volume and performance demands. The 6bone was established in exactly this manner, with the explicit goal of being a testbed for experimenters and early adopters. Right now, this is the best way to achieve global version 6 interconnection. Soon (hopefully), your ISP will be offering production address space along with supporting tunnels or physical links. Alternatively, you may like to experiment with the 6to4 mechanisms, although it is early days yet in that domain. Joining the 6bone is quite straightforward:
You can automate the tunnel configuration to occur at boot time by creating a /etc/hostname.gif0 file, containing something like this:
giftunnel <my IPv4 addr> <remote IPv4 addr>
!/sbin/route add -inet6 default fe80::%gif0
Don't forget to also add alias lines to your other interfaces' configuration files, so they are assigned the global unicast addresses that you choose. Now What?When you have a working connection to the wider IPv6 network, the obvious question is: what can I use this for? I've already introduced ping6. As you might expect, there is a corresponding traceroute6, which will allow you to explore the topology of the network. On an OpenBSD box, you will find that many network applications are already IPv6 enabled, including ftp(1), telnet(1) and ssh(1). All of these applications will use IPv6 if a version 6 address is specified or if the target has a "AAAA" DNS record. Any server that is designed to work with inetd may be made available on the IPv6 network simply by adding an appropriate "tcp6" or "udp6" entry to /etc/inetd.conf. For instance, you can offer IPv6 time services by adding the line:
time stream tcp6 nowait root internal
Some IP stacks will listen for both version 4 and version 6 connections if a wildcard is specified. OpenBSD does not work like this, due to security concerns. As a consequence, a standalone server must be modified to listen on an IPv6 socket as well as (or instead of) an IPv4 socket. Patches for popular servers are becoming common.
SecurityAs you begin to experiment with IPv6, it is important to watch out for security holes. Many servers have code that applies some form of address based security, and this may break in unexpected ways when handed an IPv6 socket. For instance, my anti-spamming code, which checks the incoming source address, failed miserably when I IPv6-enabled my SMTP server. Similarly, many packet filters and security proxies are not IPv6 ready, and you may be creating ways to simply bypass your security infrastructure if you open up an IPv6 tunnel without sufficient forethought. Last WordsThere is an enormous amount of information that could not be included in this article for reasons of space and time. The intent of this document, however, is to give you enough practical advice to bootstrap yourself onto the the next generation Internet. From there, although there is a growing body of new facts to learn and technology to understand, you should be able to proceed in a steady and incremental fashion.Did you ever wish that you were around when the Internet got started? This is a chance to be part of the complete re-engineering of the net, and its metamorphosis into something even larger and more ubiquitous than the original. Don't miss this opportunity, because the next one will be a long time coming...
References
|