IPv6 Deployment in Linux

IPv6 deployment
Please note: An updated version of this document that has slightly better formatting and a TOC can be found in the LQ Wiki.

IPv6 deployment and upgrade strategies - introduction

This article is intended as a guide to assist new entrants into the IPv6 world. We will show three successively more complex examples of migration strategies from IPv4 to IPv6. The examples utilize Linux-based routers, firewalls, and proxy servers, although the attached workstations are assumed to be Windows-based machines. These examples will help the user understand the deployment of (or migration to) an IPv6 network.
Read More

Internet Protocol Version 6 (IPv6), also referred to as Internet Protocol Next Generation (IPng), is the latest major network layer protocol. It is an extension to Internet Protocol Version 4 (IPv4), which is the current Internet standard. IPv6 was originally developed to handle a number of issues that were either considered weaknesses or limitations of IPv4. Most notably and obviously, IPv6 has an address space of 128 bits (versus 32 bits in IPv4), which allows a much larger number of machines to be connected to any network. In addition, IPv6 improves router performance through the use of more succinct network datagram headers, multicast membership maintenance, reduced network broadcasts, and delegation of packet fragmentation. These techniques provide more efficient network architecture from which to deploy next generation Internet technologies.

Although IPv6 contains a number of improvements over IPv4, there are also a number of challenges that face implementers and administrators wishing to deploy this advanced architecture. First of all, the fact that the technology is new and not widely used represents a major challenge to implementers. However, many of the challenges are superficial because the underlying system design has not changed radically. Thus many of the changes from IPv4 to IPv6 are superficial. For instance, IPv6 no longer uses "private addresses" [RFC1918] but instead uses two types of network addresses called "site-local" and "link-local" addresses. The Address Resolution Protocol and the Router Discovery Protocol have been replaced with the Neighbor Discovery Protocol. DHCP (Dynamic Host Configuration Protocol) is no longer necessary in IPv6 since hosts can negotiate their addresses on startup. The only major change is that Network Address Translation (employed in routers and firewalls when acting as a surrogate source in network communications) is no longer implemented in IPv6 (nor is it necessary since there are enough IP addresses for every device).

IPv6 and IPv4 headers compared

Although we like to think of the Internet as a new technology, the actual design of the Internet infrastructure began in the late 1960's with contracts from the United States Department of Defense. By 1981, RFC 791 standardized IPv4, which is the key technology for building an "internet" of networks. In the past 22 years, we have seen quite a few changes to the Internet's infrastructure. To understand some of the issues with IPv4, let us take a look at its header layout.

http://dons.usfca.edu/buckwalt/ipv6/image002.jpg

Figure 1-1 IPv6, IPv4 Side by Side Comparison

In Figure 1-1, we can compare the IPv4 and IPv6 headers. In IPv4, the Version field (A) has a value indicating that this datagram is of type IPv4. The Header Length Field (B) indicates the length of the IPv4 header, (since the options field (N) is optional or can contain up to 40 bytes of data). The next field (C) represents what is generally considered to be 'Type of Service' and is a way to specify the priority of a packet. The Total Length of the packet is stored in field (D) and represents the size of the packet header + payload.

Fields E, F, G and H are used in fragmentation calculations. The Identification Header (E) is used to determine which group of fragmented packets a datagram belongs to. The 'Don't Fragment' Flag (F) (which follows an unused bit) is used to specify that this datagram should not be fragmented. The 'More Fragments' flag (G) specifies that fragment reassembly at the receiver must wait until the rest of the fragments are received. The last fragmentation field (H) specifies where the fragment fits within the original datagram.

The 'Time to Live' byte (I) specifies how long a packet can travel along a route until it is dropped (and an alert sent back to the originating host). The 'Time to Live' is now measured in hops. The 'Protocol' byte (J) tells the recipient about the type of protocol in its payload (typically TCP, UDP, etc). The header checksum (K) tells the recipient if there were any transmission errors in the header. And finally, the standard packet header ends with the Source (L) and Destination (M) addresses of the packet. If it exists, the options header (N) follows the standard packet header, and may be up to 40 bytes in length.

If reading the description of the headers is confusing, imagine how much computation must be done by the routers managing the packets. Imagine having to wade through a possible 40 more bytes of optional headers (twice the length of the standard header described on this page). The IPv4 software has to do a considerable amount of processing as each packet is received, analyzed, possibly fragmented, and then retransmitted. With knowledge of the complexities of IPv4, the designers of IPv6 decided to simplify the headers of the IPv6 protocol to eliminate many of these problems.

First, they eliminated the "options" header. There is a set of optional headers in IPv6, but unless the router sees a special routing header as the very first optional header (comprising 18 bytes) it is ignored. Because the "options" header was eliminated, packets would always be the same size. This means that the IPv6 header does not need a Header Length Field. Next, a decision was made on the way IPv6 behaves about packet fragmentation.... and the decision is that routers just won't do it. The end hosts are responsible for determining the maximum transmission unit of the link between it and its partner and sending datagrams of that size or smaller... thus fragmentation is eliminated in the routing consideration (and packet re-assembly phases). Finally, since modern routers have build in error detection at the datalink layer, it became unnecessary to compute header checksums for IPv6 headers.

In this way, the IPv6 header starts to look like a "stripped down" version of the original IPv4 specification. The first field (A) represents the version of the protocol (IPv6). The next field (B) represents the "Traffic Class" (a fancy way of saying Type of Service). The field (C) is the "Flow Label" and is a shortcut for the router that means the router has to make routing decisions on this packet insomuch as it must do to this packet the same thing it does to every other packet with the same flow label. The Payload Length (D) is the length of the entire datagram minus the header. The Next Header (E) is used by router only under very special circumstances but generally tells the receiving station the protocol of the datagram's payload (i.e. TCP, UDP, etc). Next, we have the "Hop Limit" (F) which is analogous to "Time to Live" in IPv4 but represents a simple counter that can be decremented (instead of a time to be computed). Finally, the Source (G) and Destination (H) headers are each 16 bytes long.

The IPv6 headers are always 40 bytes long. IPv4 headers are a minimum of 20 bytes long but are quite often longer (up to a rare maximum of 60 bytes long). This represents on a normal network (1500 bytes MTU) of 2.6 percent of the overall traffic for IPv6 and an estimate of 1.3 to 3.9% of traffic on an IPv4 network for headers alone.

IPv6 and IPv4 addressing compared

For the networking professional, the most obvious change from IPv4 to IPv6 is the vast increase in address space. IPv6 addresses have a 128 bit address space, which yields approximately 2128 addresses (3.4 * 1038) Compare this with IPv4, where the address space is 32 bits, which yields approximately 232 addresses (4.3 billion or 4.3 * 109). This represents a significantly larger number of addresses! This helps because many studies conducted have estimated that we will run out of address space in the IPv4 Internet within the next few years [RFC 1744].

In IPv6, the _expression of an address as a "dotted-quad," or "dotted-decimal" has been replaced by a different representation. As you may recall, IPv4 addresses are typically represented as a sequence of four 8-bit values (bytes), each byte separated by a period. Thus, the following IPv4 address (in binary):

10111101001000001100111101100001

would be divided into four bytes:

10111101.00100000.11001111.01100001

which in turn would be translated into decimal equivalents as:

189.32.207.97

With IPv6 addresses, the notation is slightly different. Each address is broken into eight 2-byte pieces which are delimited by a colon. Thus, the following IPv6 address (in binary):

11111110 11000000 00000000 00000000 00000000 00000000 00000000 00000000 00000010 00100000 11101101 11111111 11111110 01101010 00001111 01110110

would be divided into eight 2-byte pieces (note that we insert extra spaces for readability, but they are not required in the notation):

1111111011000000: 0000000000000000: 0000000000000000: 0000000000000000: 0000001000100000: 1110110111111111: 1111111001101010: 0000111101110110

which in turn would be translated into hexadecimal equivalents as:

fec0:0000:0000:0000: 0220:edff:fe6a:0f76

With IPv6 addresses, some shorthand can be taken. For instance, leading "0"s within each 2-byte piece can be dropped:

fec0:0:0:0:220:edff:fe6a:f76

Also, a single series of "0"s can be dropped and replaced with two adjacent colons to signify that "0"s can be added to make the address fit into 128 bits:

fec0::220:edff:fe6a:f76

However, this reduction can only be used once in any address in order to not violate uniqueness. Imagine the trouble we would get into trying to represent the following addresses with more than one double colon:

8d:0:0:2d69:0:0:0:1234 can safely be represented as 8d:0:0:2d69::1234
8d:0:2d69:0:0:0:0:1234 can safely be represented as 8d:0:2d69::1234
8d:0:0:0:2d69:0:0:1234 can safely be represented as 8d::2d69:0:0:1234

This reduction can be used for the localhost interface in IPv6 (the equivalent of IPv4's 127.0.0.1). This localhost address is 0:0:0:0:0:0:0:1 or ::1. The reduction can also be applied to the default network (the equivalent of IPv4's 0.0.0.0) as simply ::.

Subnetting in IPv6 follows similar rules as in IPv4. The general idea is that a subnet mask can be applied to any address. Using this subnet mask, a router can determine which bits represent the network membership of an address and which bits represent the host's address. In the IPv4 world, the network address 192.168.1.4/24 (or alternative notation of subnet mask 255.255.255.0) means that the network address is represented by the first 24 bits of the address and that the host address is represented by the remaining 8 bits (32 bit address space minus 24 bit network address = 8 bits for host address). The notation 192.168.1.4/24 is usually referred to as a CIDR (Classless Interdomain Routing) address. We give an example of subnet masking in binary, which is easier to visualize:

The IPv4 address 192.168.1.4 would be represented in binary as:
11000000.10101000.00000001.00000100
The subnet mask 255.255.255.0 would be represented in binary as:
11111111.11111111.11111111.00000000
which shows that the first 24 bits of the subnet mask are "1". Then "bitwise AND" the 2 values together to get the network address:
11000000.10101000.00000001.000000000
which indicates that the network portion of the address is 192.168.1.0 (24 bits of network address, plus a trailing zero byte). Then subtract the network address from the original address to get the host's address:
00000000.00000000.00000000.00000100
which indicates that the host is 0.0.0.4, or, more simply, just 4.


In IPv6, the idea of subnet masks is similar, but the network addresses are much larger (explained later in this section). We illustrate with our previous IPv6 address example, assuming a network of /64 (meaning that the network address is the left-hand 64 bits of the total 128 bits). We will use hexadecimal arithmetic rather than binary arithmetic, because binary is just too cumbersome for IPv6 addresses.
The IPv6 address fec0::220:edff:fe6a:f76 would be expanded to:
fec0:0000:0000:0000:0220:edff:fe6a:0f76
The subnet mask for a /64 network would be:
ffff:ffff:ffff:ffff:0000:0000:0000:0000
Then "bitwise AND" the 2 values together to get the network address:
fec0:0000:0000:0000:0000:0000:0000:0000
(64 bits of network address, plus a 64 trailing zero bits). Then subtract the network address from the original address to get the host's address:
0000:0000:0000:0000: 0220:edff:fe6a:0f76


In IPv4, there is a traditional classification of network, based on the first octet (leftmost byte) of the address. However, this classification is no longer formally part of the IP addressing architecture, and has been replaced by CIDR (Classless Interdomain Routing). In summary:


Allocation 1st Octet
----------- --------
Class "A" 0 - 126
Reserved 127

Class "B" 128 - 191
Class "C" 192 - 223

Class "D" 224 - 239
Class "E" 240 - 254
Reserved 255

Or, by using the "First Octet" Rule:

Bit Pattern Class of Address
------------ ----------------
0 A
10 B
110 C
1110 D

1111 E

Figure 1.2 IPv4 Network Allocations


However, in IPv6 we have 2 octets of information with which to divide our networks (also see RFC 3513).



Allocation Prefix Fraction of
(binary) Address Space
------------------------------ -------- -------------
Reserved 0000 0000 1/256
Unassigned 0000 0001 1/256

Reserved for NSAP Allocation 0000 001 1/128
Reserved for IPX Allocation 0000 010 1/128

Unassigned 0000 011 1/128
Unassigned 0000 1 1/32
Unassigned 0001 1/16
Unassigned 001 1/8

Provider-Based Unicast Address 010 1/8

Unassigned 011 1/8

Reserved for Geographic-
Based Unicast Addresses 100 1/8

Unassigned 101 1/8
Unassigned 110 1/8
Unassigned 1110 1/16
Unassigned 1111 0 1/32
Unassigned 1111 10 1/64
Unassigned 1111 110 1/128

Unassigned 1111 1110 0 1/512

Link-Local Use Addresses 1111 1110 10 1/1024
Site-Local Use Addresses 1111 1110 11 1/1024

Multicast Addresses 1111 1111 1/256

Figure 1-3 IPv6 Network Allocations

For the scope of our paper, we are interested in four types of addresses. These are link-local addresses, site-local addresses, global unicast addresses (basically anything marked "unassigned" above) and multicast addresses. The term "global unicast address" supersedes the IPv4 term "IP address." We will not discuss anycast addresses which are used by routers specifically for failover, redundancy, and broadcast in IPv6. In IPv6, link-local and site-local addresses represent private address space just as reserved addresses represent them in IPv4, (RFC 1918):
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

In IPv6, any network address fe80::/10 is a "link-local" address. The concept of link-local means that machines are physically located in the same data link layer broadcast domain. This would include machines attached via hubs, bridges, and layer 2 switches as well as any machines directly connected. The addresses in network address fec0::/10 are "site-local" addresses and should not be routed outside of your locally-controlled infrastructure (because of the possibility of address collisions with addresses defined at other sites). All other legal addresses are considered to be "global unicast addresses" and are validly used on any node whether connected to the Internet or not. Global unicast addresses must be globally unique, of course.

As with IPv4, IPv6 addresses can be either statically or dynamically assigned. However, the definition of dynamically assigned has changed somewhat with IPv6. There are two dynamic address mechanisms in IPv6. The first (and primary) mechanism for dynamic IP address assignment is called "stateless autoconfiguration"; and uses the hardware address of the machine's interface to negotiate the IP address. For stateless autoconfiguration on a link-local network, an example is:

1. If the node (host or router) has a 48-bit MAC interface identifier of:
00:01:03:31:AA:DD
then the resulting 64-bit IPv6 interface ID will be:
0201:03ff:fe31:aadd
or, in shorthand notation:
201:3ff:fe31:aadd*
* Note: A 48-bit MAC address must be expanded to a 64-bit address for stateless autoconfiguration. To do so, the value fffe is inserted between the third and fourth bytes of the MAC address. Next, the second low-order bit of the first byte of the MAC address is complemented. In binary, our original MAC address looks like this, after expansion:

00000000: 00000001: 00000011: : 00110001: 10101010: 11011101
The binary string in italics represents the first byte. The "0" in boldface represents the second low order bit. More colloquially, we could call this the "next to last bit in the first byte". [Stateless Autoconfiguration: RFC 2462]

2. The node prepends this 64-bit interface identifier with the 64-bit link-local interface identifier fe80::0. This address becomes the "tentative address."

3. The node joins the "all-nodes" multicast group (ff02::1) and the solicited node multicast group (ff02:0:0:0:0:1:ffxx:xxxx, where xx:xxxx is the low-order 24 bits of the MAC address of the node's interface). (Multicast groups are explained later in this section.)

4. The node broadcasts a "neighbor solicitation" message to the "all-nodes" multicast group asking if the selected address is taken. If the address is taken, the node stops and manual configuration is required. Otherwise, the state of the address is set to "preferred."

5. The node then sends a "router solicitation request" to the "all routers" multicast group (ff02::2) to determine default routes.
The drawback with stateless autoconfiguration is that wherever this mechanism is employed, the size of the host portion of the IP address must be no smaller than 64 bits. This causes quite a few wasted unicast addresses in a typical network address architecture.

The second form of autoconfiguration occurs through the use of the dynamic host configuration protocol (DHCP) and is called "stateful autoconfiguration". DHCP can also be used in conjunction with stateful autoconfiguration to broadcast information other than IP addresses, such as DNS servers, network names, and proxy-servers. This mechanism can subnet a network into much smaller segments than stateless autoconfiguration (creating less wasted network address space) but requires additional management of the DHCP server and the addition of a DHCP client on all machines that require stateful autoconfiguration. Both stateless and stateful autoconfiguration protocols can be used for networks other than site-local through various control protocol mechanisms.

Finally, in IPv6, multicast addresses are used quite frequently for control of network hosts and services. There are two types of multicast addresses; well known and temporary. A diagram for multicast address bits looks like this:

http://dons.usfca.edu/buckwalt/ipv6/image004.gif

Figure 1-4 IPv6 Multicast Address Diagram

The second field, 000x, represents the flags field. The first 3 bits are reserved and must be set to "0". The last bit, x, represents the permanence of the address. 1 represents a temporary multicast address, while 0 represents a permanent (or termed "well-known") address.

The third field, yyyy, represents the "scope" field. The scope of the multicast address can be determined by looking at this table:




Value Description
----- -----------
0 Reserved
1 Interface-local (network interface card)
2 Link-local scope (same as link-local addr)
3,4 Unassigned
5 Site-Local scope (same as site-local addr)
6,7 Unassigned
8 Organizational scope
9,a,b,c,d Unassigned
e Global scope
f Reserved

Figure 1-5 IPv6 Multicast Scope Diagram

And finally, the group identifier is used to determine the subscriber (or function) of the multicast listening nodes. For instance, a multicast address of ff01::1 represents the "all nodes" multicast address of scope "interface local," while ff02::1 and ff05::1 represent the "all nodes" multicast address of link-local and site-local scope, respectively. The group identifier of the addresses is the same, only the scope address is different.

Some well-known group identifiers are:

Group Identifier Description
---------------- -----------
::1 All nodes
::2 All routers
::9 RIP routers
::1:3 DHCP servers

Figure 1-6 IPv6 Well-Known Multicast Group Identifiers

For more information on multicast addresses, please see RFC 2375.

IPv6 and IPv4 maintenance protocols compared

With IPv4, we were introduced to a number of maintenance protocols. These protocols gave us the ability to detect errors in our network, receive alerts when our endpoints became unreachable, and to detect the layout of our network.

In IPv4, the major protocol used for network maintenance is called ICMP (Internet Message Control Protocol) and is defined in RFC 792. The most important types are described below [Computer Networks 4th Ed, p. 449, ISBN 0130661023]:

Message Type Description
------------ ---------------
Destination Unreachable Datagram could not be delivered
Time Exceeded Time to Live reached 0
Parameter Problem Invalid Header Field
Echo Ping Request
Echo Reply Ping Reply

Figure 1-7 IPv4 Common ICMP Types

In IPv6, the common ICMP messages are retained, but there are a few additions:


Message Type Description
------------ ----------------
Destination Unreachable Datagram could not be delivered,
i.e. no route to destination
Packet Too Big Since fragmentation cannot be done,
MTU size was too large for some
link in transmission path.
Time Exceeded Hop Limit reached 0
Parameter Problem Invalid Header Field
Echo Ping Request
Echo Reply Ping Reply
Multicast Listener Query What multicast addresses are on a link?
Multicast Listener Report Node is joining a multicast group
Multicast Listener Done Node is resigning multicast group
Router Solicitation Node needs to know routes
Router Advertisement Router sends routing table
Neighbor Solicitation Node wants to build ARP table
Neighbor Advertisement Node responds to solicitation

Figure 1-8 IPv6 Common ICMP Types

Assuming a familiarity with IPv4, we will discuss only the new ICMP messages. The first (and probably most used) error message is the "Packet Too Big" message type. This can occur when a packet is transmitted along different links of differing MTU (Maximum Transmission Unit) sizes. When the datagram is initially constructed, the node will assume that its link MTU size is safe for transmission to all destination nodes. However, if a router along the path to the destination has a smaller link size, the packet will be discarded and a "Packet Too Big" ICMP message will be directed towards the source. The data payload of the ICMP message gives the MTU size of the link that caused the problem. The source node then has the responsibility of encapsulating the data into the proper size for the bottleneck link and then retransmitting. This mechanism may be repeated by other routers that may have increasingly smaller MTU sizes. This mechanism is called Path MTU Discovery and is defined in RFC 1981.

The next set of ICMP messages are informational in nature and are used to coordinate information between nodes and routers. The simplest information exchange mechanism is called Neighbor Solicitation and Advertisement. This pair of messages has two functions. The first is the resolution of link layer addresses (similar to ARP in IPv4) and the second is detecting when a neighbor is unreachable. When a node attempts to resolve a hardware level address, the destination for the Neighbor Solicitation message will be a multicast address. When a node attempts to determine the reachability of a neighbor, the destination is the unicast address of that neighbor. When Neighbor Solicitation messages are sent by hosts that are determining the reachability of their neighbors, Neighbor Advertisements will be sent as replies to the solicitations. Neighbor Advertisements are also sent unsolicited when a new node joins a link. In this way, the overhead of the ARP protocol is bypassed since hosts will have local address caches for all machines on their network.

The next pair of informational ICMP messages are the Router Solicitation and Advertisement types. Routers regularly send out Router Advertisements, which contain routing information to be used on their link. However, nodes can request routing information outside of this normal interval by sending a Router Solicitation to the Link-local All-routers multicast address (ff02::2). This mechanism ensures that routing tables for all nodes are consistent.

The final informational messages in our list are the multicast management messages. These messages comply with the Multicast Listener Discovery protocol as defined in RFC 2710, which is a descendant of the Internet Group Management Protocol used in IPv4. The idea is that routers are responsible for keeping track of multicast group membership in their subnets, based on information that they obtain from their nodes. Whenever a node joins a multicast group, it must send a "Multicast Listener Report" packet to its router. When it leaves a multicast group, it sends a "Multicast Listener Done" packet to its router. In turn, the affected router must subscribe/unsubscribe to the multicast group with its parent router, and so on. At certain intervals (and under certain circumstances), the router can send a "Multicast Listener Query" to determine which multicast groups exist on a specific link, or to determine which hosts subscribe to a particular multicast group. The answers to these requests are also "Multicast Listener Report" messages.

Why use IPv6 - conclusions

Simply put, IPv6 has significant improvements over IPv4. Using IPv6 extends the life of the Internet, whose address space is doomed to become saturated within a few years. It also simplifies router processing of the network datagrams because of its simplified header design. Finally, IPv6 offers "plug and play" network management because of its stateless autoconfiguration, router discovery, neighbor discovery, multicast discovery, and management protocols.

Implementing a simple SOHO network using IPv6

http://dons.usfca.edu/buckwalt/ipv6/image006.gif

Figure 2-1 SOHO Network Diagram

Infrastructure requirements and layout
In this section, we will describe the network layout, design, and example implementation for a small network used by a 5-person real estate office. The requirements for this office represent those of non-technology professionals, whose needs include:
**Access to the World Wide Web
**Access to email (provided by their ISP)
**File and print sharing
**A web presence, represented by a web server
**Modest budget for IT expenses

Although we could design this infrastructure using many market technologies, we will assume that the customer is agreeable to open-source network software (Linux, apache) for their infrastructure while retaining their local workstation machines on Windows XP (which supports IPv6).


Implementation strategy in IPv4
If we were to implement this environment using IPv4, we would most likely make the following recommendations:
# All traffic to and from our network will go through a proxy server with the "outside interface" controlling a public IPv4 address, labeled (A) in Figure 2.1, and the "inside interface" controlling a public IPv4 address (B).
# A proxy server makes sense for this environment because, most likely, the network link from the ISP is very slow and we want to maximize our available bandwidth. A web proxy allows us to do web filtering, block popup ads, and most importantly, cache the content so that expensive requests over our ISP link are reduced.
# To minimize cost, we could install the proxy server and web server on the same machine.
# Access outside of the network MUST go through the proxy server which is configured for HTTP/HTTPS and SOCKS connections.

Implementation strategy in IPv6
Not surprisingly, our implementation strategy in IPv6 is similar to the IPv4 solution described above. We built and tested a live implementation using a lab network. Details of the implementation are given below:

Obtain an IPv6 address from the customer's ISP
We simulated this step by using the IPv6 tunnel broker Hurricane Electric (http://www.he.net):

1. First, you must sign-up for an account by registering at their main page, http://www.he.net.

2. Once your account is approved, log in and request an IPv6 address by providing your public IPv4 address.

http://dons.usfca.edu/buckwalt/ipv6/image008.jpg

Figure 2-2 Registering for an IPv6 Tunnel

3. Once your tunnel is approved, you will be notified and given your tunnel information.

http://dons.usfca.edu/buckwalt/ipv6/image010.jpg

Figure 2-3 IPv6 Tunnel Information

4. And additionally, you will be given some examples of setting up a tunnel on a server machine:

http://dons.usfca.edu/buckwalt/ipv6/image012.jpg

Figure 2-4 IPv6 Configuration Settings

5. Your next step is to configure your server to use this globally accessible unicast address. This is described later in this section.

Enabling IPv6 on a Linux server
Ensure that your Linux server is capable of running IPv6. In short, check the following items:

1. If IPv6 is compiled as a module, ensure it can be loaded with
# modprobe IPv6
2. /proc/net/if_inet6 exists

3. Ensure your "nettools" package is IPv6-compatible:
# ifconfig lo - should contain the addr ::1
# route ?A inet6 ?rn - should not return an error
4. The "ip" package should be IPv6 compatible:
# ip -f inet6 addr - should list le0 with addr ::1
5. The following commands should reside on your machine:
** ping6
** traceroute6
** tracepath6
6. The proper startup script exists to start IPv6 at startup time.
Based on the information obtained from Hurricane Electric, my IPv6 startup script looks like this:

******/etc/rc.d/init.d
jspears@sparta:> cat IPv6-setup
#!/bin/bash
/sbin/ifconfig sit0 up
/sbin/ifconfig sit0 tunnel ::64.71.128.82
/sbin/ifconfig sit1 up
/sbin/ifconfig sit1 inet6 add 2001:470:1f00:ffff::759/127
/sbin/route -A inet6 add ::/0 dev sit1

7. Ensure that the IPv6 initialization script will be run at startup.

Installing an IPv6-compatible proxy server
For most open source network servers and applications, we can quite easily find either IPv6-enabled versions or patches to deploy on our new network. Since we are looking for a proxy server, we have a few choices. First, we can user the Squid proxy server (available at [http://www.squid-cache.org/ squid], but which requires an IPv6 patch) or we can install the prometeo proxy server (available at [http://sourceforge.net/projects/prometeo-proxy/ prometeo], which supports IPv6 natively). We chose to install prometeo because of its ease of installation and its simplicity. For flexibility, though, squid is probably a better choice.

To install prometeo:

1. Download the source from sourceforge (follow the download link from prometeo) onto your local machine.

2. Extract the source files from the tar ball with the following command:
$ tar xzf prometeo-1.2.tar.gz
This creates a directory called prometeo-1.2.

3. Enter the directory and configure the source:
$ cd prometeo-1.2
$ ./configure -enable-IPv6

4. Compile the source:
$ make

5. Install the compiled binaries as the "root" user:
$ su ?root ?c "make install"

6. Next, you need to edit the prometeo configuration file:
$ vi /usr/local/prometeo/etc/prometeo.xml
For the section ensure that:
1
By reading the documentation you can also create custom settings for the proxy, such as configuring SOCKS proxies, etc.

7. Create a system startup script:
#!/bin/bash
case "$1" in
start)
/usr/local/prometeo/sbin/prometeo
;;
stop)
/usr/local/prometeo/bin/prometeoctl stop
;;
esac
8. Ensure that this startup script is run at startup:
# ln ?s /etc/rc.d/rc3.d/S99prometeo
# ln ?s /etc/rc.d/rc3.d/K01prometeo

Install and configure an IPv6-compatible web server
In addition to version 2 of the Apache web server having significant improvements in performance and modular functionality, it also has native support for IPv6. Although we could choose to patch an earlier version of Apache, it is tedious and unnecessary for most cases. In our example, we will use the Apache web server (version 2) as our web infrastructure.

1. Download the Apache web server source code from apache.org (http://httpd.apache.org/download.cgi)

2. Extract the source files from the tar ball with the following command:
$ tar xzf httpd-2.0.45.tar.gz
This creates a directory called httpd-2.0.45.

3. Enter the directory and configure the source:
$ cd httpd-2.0.45
$ ./configure
4. Compile the source:
$ make
5. Install the compiled binaries as the "root" user:
$ su ?root ?c "make install"
6. Next, you need to edit the Apache configuration file:
$ vi /usr/local/apache2/conf/httpd.conf
Change the "Listen" directive to your IPv6-compatible web URL i.e.:
Listen [2001:470:1f00:ffff::759]:80
Also, apply any other appropriate Apache tuning for your environment, which is beyond the scope of this document.

7. By default, the Apache startup script works very well as a system startup script. It is only necessary to link to it for system startup:
# ln ?s /usr/local/apache2/bin/apachectl \ /etc/rc.d/rc3.d/S99apache
# ln ?s /usr/local/apache2/bin/apachectl \ /etc/rc.d/rc3.d/K01apache
8. Register your IPv6 address with DNS for your domain. The DNS entry for an IPv6-compatible site is:
my.server.hostname IN AAAA my.ip.address
An example is:
IPv6.jspears.org IN AAAA 2001:470:1f00:ffff::759
You can verify the changes to DNS with the nslookup command:
$ nslookup -type=AAAA IPv6.jspears.org
Server: sparta.jspears.org
Address: 192.168.1.6

IPv6.jspears.org AAAA IPv6 address = fec0::c0a8:106
jspears.org nameserver = dns0.jspears.org
jspears.org nameserver = dns1.jspears.org


Configuring an IPv6-compatible DNS server is covered in a later section of this document.

Install and configure workstation machines as IPv6-compatible machines
Make sure that the customer is using an IPv6-compatible operating system. As of this writing, the only Microsoft operating system that supports IPv6 is Windows XP Service Pack 1 and greater. For Apple Macintosh operating systems there are no published compatibility notes for IPv6. Linux and kernel versions 2.4 and greater have IPv6 support. Many BSD variants also have IPv6 support.

1. For this step, we assume that Windows XP SP1a is installed at the customer site and that IPv6 is not configured. To enable IPv6, perform the following sequence of actions:
** Log on as an administrator user
** Open the Control Panel
**Select the "Network Connections" Icon
** Right-click the icon which represents the network connection. Then select "Properties".
** In the "Properties" dialogue, click the "Install" button.
** In the new window, select the item labeled "Protocol" and then select "Microsoft IPv6 Developer Edition" in the protocol selection dialogue window.
** Reboot the machine.

2. Once the machine comes back online, we need to tell it to use the proxy server. Unfortunately, most of our software doesn't understand IPv6 notation, even if the applications do. This is especially problematic for mapping hostnames to IPv6 addresses. For Windows, we can make the following change to the workstation's operating system so that hostname resolution for our proxy server will work.
** With Notepad or another text editor, open the file:
c:\windows\system32\drivers\etc\hosts
** Add the following line:

Here is an example:

http://dons.usfca.edu/buckwalt/ipv6/image014.jpg
Figure 2-5 Example Hosts File
** Save the file
3. Now we can configure our browsers to use the new proxy server.


In Microsoft Internet Explorer Version 6:
** Open the Control Panel
** Select the "Internet Options" Icon.
** Select the tab labeled "Connections"
** Click the button labeled "LAN Settings"
** Input the IPv6 hostname (from above) and port number (from prometeo.xml) in the proxy dialogue and click "OK"
Here is an example:

http://dons.usfca.edu/buckwalt/ipv6/image016.jpg
Figure 2-6 Internet Explorer Proxy Dialogue


In Netscape Navigator Version 7:
** Open Netscape Navigator, select the menu item "Edit->Preferences"
** In the new dialogue box, select the tree branch labeled "Advanced->Proxies" and input the proxy settings:

http://dons.usfca.edu/buckwalt/ipv6/image018.jpg
Figure 2-7 Netscape Proxy Dialogue

If you use your web browser to travel to an IPv6-aware website, you should be able to get the correct content:

http://dons.usfca.edu/buckwalt/ipv6/image020.jpg
Figure 2-8 Web Browser Display Using IPv4

http://dons.usfca.edu/buckwalt/ipv6/image022.jpg
Figure 2-9 IPv6-Aware Web Browser Display


Implementing a small development network using IPv6

http://dons.usfca.edu/buckwalt/ipv6/image024.gif
Figure 3-1 Small Routable Network Diagram
Infrastructure requirements and layout
In this section, we will describe the network layout, design, and an example implementation for a network used by a small software consulting firm. The requirements for this office represent those of technology professionals, whose needs include:
** All requirements of a SOHO Office, as in the previous section
** The ability to directly connect to client networks and public internets
** The ability to keep information and technology resources safe behind a firewall

As in the SOHO case earlier, everything that we wish to accomplish with IPv6 can be done with "off the shelf" components, including Linux as the firewall/router.

Implementation strategy in IPv4
If we were deploying this architecture for an IPv4 environment, we would base it on our previous SOHO configuration, with a couple of notable exceptions:
** We would use public Internet addresses instead of private addressing assuming that we do not use Network Address Translation but still require access to miscellaneous resources on the Internet.
** We would configure a firewall to limit incoming connections to our network
** We would have to route traffic and therefore establish default routes.
** We may configure a DNS server to answer DNS requests locally for our growing network. However this is probably not necessary because our ISP likely provides DNS and mail service for us.
** The firewall?s outside interface (A) is a globally accessible Internet address. The firewall?s inside interface (B) is also a public IP address pool which must be routable. All hosts (D) on the network are on the same subnet as the firewall?s inside interface (B). All web traffic travels through the web proxy (C) to take advantage of filtering, virus scanning, and caching.

Implementation strategy in IPv6
In IPv6, as in the previous example, the implementation is simple and almost identical to the IPv4 deployment. The simplest configuration options would allow us to take advantage of stateless autoconfiguration on a publicly accessible network address space. To do this, we will need to obtain a 64 bit address block from our ISP. We will also need to configure a firewall to block incoming traffic. Our web-proxy is inside of the firewall. Later, we will configure our firewall/router to perform router advertisements through the Neighbor Advertisement and Solicitation mechanism described in Section 1.

Configuring the firewall in Linux
For a long time, Linux has been a favorite inexpensive firewall solution for small businesses and IT professionals. While the default Linux kernel still has a few bugs in its IPv6 stack (http://www.linux-IPv6.org/overview.html#overview) IPv6 bugs, we can still implement a suitable firewall for our minimalist purposes.

In our previous SOHO example, we used a configuration script to ensure that the proxy server would initialize the IPv6 interfaces for outbound communication. In this example, the firewall, rather than the proxy server, is the outward facing host and therefore needs the configuration of the IPv6 addresses defined previously. In addition, we will need a 64 bit address allocation block from our ISP for our internal address space (so we can do stateless autoconfiguration). In my firewall, I have 2 interfaces, eth0 which faces inward (or toward the "clean side" of the network) and eth3 (which faces the "dirty" side). The "clean side" will have an address from our 64 bit allocation block "hard-coded" to it while the "dirty side" will have the IPv6 address used originally by our proxy sit0 interface. (Also see the original SOHO example in Section 2.) The revised script will look like this:
#!/bin/bash
# the address on eth0 is an arbitrary address on our allocated netw.
/sbin/ifconfig eth0 inet6 add 2001:470:1f00:1040::192.168.1.6/64
/sbin/ifconfig sit0 up
/sbin/ifconfig sit0 tunnel ::64.71.128.82
/sbin/ifconfig sit1 up
/sbin/ifconfig sit1 inet6 add 2001:470:1f00:ffff::759/127
/sbin/route -A inet6 add ::/0 dev sit1

1. First make sure that your system is configured to serve as a firewall AND as an IPv6 host. For the firewall requirement, please see the document http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/Firewall-HOWTO.pdf Firewall-HOWTO. For the IPv6 host requirement, please refer to the requirements for our SOHO proxy server in the previous section.
2. Next, make sure the netfilter6 package has been installed on the firewall. This can be seen by issuing the following command, and observing the output:
# ******/usr/local/prometeo
root@sparta:> ip6tables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

This happens to be a very poor firewall configuration, but demonstrates that at least the firewall can be configured.

3. Next, we need to create our firewall rules. There are a number of ways to do this, but the best way is to use the "Firewall-HOWTO" guide to determine the proper firewall rules and then make copies of the rules replacing the iptables commands with '''ip6tables''' in a separate script. (It is VERY important that you firewall both the IPv4 AND IPv6 protocols on your firewall if you have IPv4 enabled as well. Otherwise, you could inadvertently leave something open on IPv4 that is closed on IPv6.)