Originaly Posted by: buckwalter on 11-23-2004. (http://www.linuxquestions.org/questions/answers.php?action=viewarticle&artid=324) 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.


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:

code:

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:

code:

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).

code:

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:

000000 0 0: 00000001: 00000011: <fffe goes here>: 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:

code:

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:

code:

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]:

code:

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:

code:

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

code:

#!/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 <Key name="http"> ensure that:
<Value type="integer" name="enabled">1</Value>
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:

code:

#!/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 <my startup script> /etc/rc.d/rc3.d/S99prometeo
# ln –s <my startup script> /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:windowssystem32driversetchosts
** Add the following line:
<IPv6 address> <hostname>
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.)

Here is my simple firewall script:

code:

#!/bin/sh

#

#  This is automatically generated file. DO NOT MODIFY !

#

#  Firewall Builder  fwb_ipt v1.0.8-3

#

#  Generated Thu Apr 24 15:48:38 2003 PDT by root

#

#

#

#

check() {

if test ! -x "$1"; then

echo "$1 not found or is not executable"

exit 1

fi

}

log() {

if test -x "$LOGGER"; then

logger -p info "$1"

fi

}

MODPROBE="/sbin/modprobe"

IPTABLES="/sbin/ip6tables"

IP="/sbin/ip"

LOGGER="/usr/bin/logger"

SYSCTL="/sbin/sysctl"

check $MODPROBE

check $IPTABLES

check $IP

cd /etc || exit 1

log "Activating firewall script generated Thu Apr 24 15:48:38 2003 PDT by root"

va_num=1

$SYSCTL -w net.IPv6.conf.all.forwarding=0

$IP -4 neigh flush dev eth0

$IP -4 addr flush dev eth0 label "eth0:FWB*"

$IP -4 neigh flush dev eth3

$IP -4 addr flush dev eth3 label "eth3:FWB*"

$IP -4 neigh flush dev eth1

$IP -4 addr flush dev eth1 label "eth1:FWB*"

$IP -4 neigh flush dev eth2

$IP -4 addr flush dev eth2 label "eth2:FWB*"

$IPTABLES -P OUTPUT  DROP

$IPTABLES -P INPUT   DROP

$IPTABLES -P FORWARD DROP

MODULE_DIR="/lib/modules/`uname -r`/kernel/net/IPv6/netfilter/"

MODULES=`(cd $MODULE_DIR; ls | sed "s/.o.*$//")`

for module in $(echo $MODULES); do

if [ -e "${MODULE_DIR}/${module}.o" -o -e "${MODULE_DIR}/${module}.o.gz" ]; then

$MODPROBE ${module} ||  exit 1

fi

done

$IPTABLES -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#

# Rule 0(eth3)

#

# Anti-spoofing rule

#

$IPTABLES -N eth3_In_RULE_0

$IPTABLES -A INPUT  -i eth3  -s <my IPv6 address> -j eth3_In_RULE_0

$IPTABLES -A FORWARD  -i eth3  -s <my IPv6 address> -j eth3_In_RULE_0

$IPTABLES -A eth3_In_RULE_0  -j LOG  --log-level info --log-prefix <br>"RULE 0 -- DROP "

$IPTABLES -A eth3_In_RULE_0 -j DROP

#

# Rule 1(eth3)

#

# Anti-spoofing rule

#

$IPTABLES -N ptmp001

$IPTABLES -A OUTPUT  -o eth3 -j ptmp001

$IPTABLES -A FORWARD  -o eth3 -j ptmp001

$IPTABLES -A ptmp001  -o eth3  -s <my <br>IPv6 address> -j RETURN

$IPTABLES -N eth3_Out_RULE_1_3

$IPTABLES -A ptmp001  -o eth3 -j eth3_Out_RULE_1_3

$IPTABLES -A eth3_Out_RULE_1_3  -j LOG  --log-level info --log-prefix <br>"RULE 1 -- DROP "

$IPTABLES -A eth3_Out_RULE_1_3 -j DROP

#

# Rule 0(lo)

#

# allow everything on loopback

#

$IPTABLES -A INPUT  -i lo -j ACCEPT

$IPTABLES -A FORWARD  -i lo -j ACCEPT

$IPTABLES -A OUTPUT  -o lo -j ACCEPT

$IPTABLES -A FORWARD  -o lo -j ACCEPT

#

# Rule 1(lo)

#

# allow everything on loopback

#

$IPTABLES -A INPUT  -i lo -j ACCEPT

$IPTABLES -A FORWARD  -i lo -j ACCEPT

$IPTABLES -A OUTPUT  -o lo -j ACCEPT

$IPTABLES -A FORWARD  -o lo -j ACCEPT

#

# Rule 1(global)

#

# allow access from the firewall on certain ports

#

$IPTABLES -A OUTPUT -p tcp  -m multiport  -d <my web server address>  --destination-port 80  -m state --state NEW -j ACCEPT

$IPTABLES -A INPUT -p tcp  -m multiport  -d <my web server address>  --destination-port 80  -m state --state NEW -j ACCEPT

#

# Rule 7(global)

#

#

# "catch all" rule

#

$IPTABLES -N RULE_7

$IPTABLES -A OUTPUT -j RULE_7

$IPTABLES -A INPUT -j RULE_7

$IPTABLES -A FORWARD -j RULE_7

$IPTABLES -A RULE_7 -j LOG  --log-level info --log-prefix "RULE 7 -- DROP "

$IPTABLES -A RULE_7 -j DROP

#

#

$SYSCTL -w net.IPv6.conf.all.forwarding=1

4. Finally, ensure that this script (and its IPv4 counterpart) is executed on every system startup.

Configuring router advertisements in Linux
Once we have a dynamic IPv6 address allocation pool from our ISP, we need to tell our clients that they are to use the addresses. As noted in Section 1 of the document, this is done through the use of router advertisements.

Please keep in mind that there are two types of router advertisements. The first type, discussed here, represent the advertisements that routers give to their end-nodes in the router advertisement and solicitation messages. These advertisements are analogous to the router advertisements given to DHCP clients during the DHCP address allocation process. The advertisements are handled as ICMP traffic. The second type of router advertisement occurs when a routing protocol such as RIP or OSPF sends routing information to other routers so that they
can synchronize their routing tables. This type of router advertisement is done through higher level protocols and is discussed in more detail later in this paper.

In Linux, router advertisements are done through a daemon process called radvd. This program, available from (http://v6web.litech.org/radvd/) litech allows us to configuration the router advertisement process.

1. Download the source from http://v6web.litech.org/radvd/dist/radvd-0.7.2.tar.gz

2. Extract the source files from the tarball with the following command:
$ tar xzf radvd-0.7.2.tar.gz
This creates a directory called radvd-0.7.2

3. Enter the directory and configure the source
$ cd radvd-0.7.2
$ ./configure --prefix=/usr/local --sysconfdir=/etc
--mandir=/usr/share/man
4. Compile the source
$ make
5. Install the compiled binaries as the "root" user
$ su – root –c "make install"
6. Next, edit the radvd configuration file:

$ vi /etc/radvd.conf
This is my example (using the network address block given to me by my ISP):
interface eth0 {
AdvSendAdvert on;
# AdvSendAdvert off;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSourceLLAddress on;
AdvDefaultLifetime 300;
AdvHomeAgentFlag off;
prefix 2001:470:1f00:1040::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
7. The creators of radvd have conveniently created a startup script for us. We need only to copy it and symlink it:
# cp <src-dir>/redhat/radvd.init /etc/rc.d/init.d/radvd
# chmod 755 /etc/rc.d/init.d/radvd
# ln –s /etc/rc.d/init.d/radvd /etc/rc.d/rc3.d/S99radvd
# ln –s /etc/rc.d/init.d/radvd /etc/rc.d/rc3.d/K01radvd

Once we start the script, our clients should see their new IPv6 addresses appear (as if by magic!):

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

Figure 3-2 Windows XP Stateless Autoconfiguration Addresses

Amazingly enough, they will also be aware of the proper routing table:


http://dons.usfca.edu/buckwalt/ipv6/image028.jpg
Figure 3-3 Windows XP Stateless Autoconfiguration Routing

At this point, all of our machines can connect directly to the IPv6 Internet through our firewall. At some point, we may consider moving to a DHCP server to reduce the amount of wasted address space, but we have successfully completed a simple network configuration.


Implementing a medium-sized IPv6 campus network

http://dons.usfca.edu/buckwalt/ipv6/image030.gif
Figure 4-1 Hierarchical Network with Global Addressing

Infrastructure requirements and layout
In this section, we describe the network layout, design, and example implementation for a network used by a medium-sized law firm. The requirements for this office represent those of
technology-aware professionals whose needs include:
** All requirements of a SOHO office, as described in the earlier section
** The ability to keep information and technology resources safe behind a firewall
** The ability to separate traffic based on local geographic divisions, for instance, floors in a building, in an effort to increase network efficiency (reduction in broadcasts, etc)

Again, everything that we wish to accomplish for 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 include our "small development network" configuration from the previous section, with a few notable exceptions:
** We would use private Internet addresses since we do not require direct connections to the Internet
** Since there are multiple routers, we would employ a routing protocol among the routers.

** We may configure a DNS server to answer DNS requests locally for our growing network. However, as before, 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 (C) is a private IP address pool which is not routable. All backbone routers (D) on the network are on the same subnet as the firewall’s inside interface. All web traffic takes place through the web proxy (B) to take advantage of filtering, virus scanning, and caching. Each backbone router is responsible for its own subnet (E).

Implementation strategy in IPv6
Once again, the IPv6 implementation strategy is an extension of the IPv4 strategy. Thus the IPv6 strategy must include:

# Each router must be configured with its own unicast address.
# Each backbone router must advertise its site-local addresses (which can be routed within the
company's network) to its end nodes.
# Each backbone router (and the firewall) must share routing information. In our case, we can assume the use of the RIPng routing protocol.

In the hands-on example given below, we introduce a new server that acts as a pure router and functions as a backbone router, as in the diagram. The firewall, proxy server, and backbone routers will communicate on the network fec0::/64. The four backbone routers in our diagram will communicate on networks fec0:0:0:1::/64, fec0:0:0:2::/64, fec0:0:0:3::/64, and fec0:0:0:4::/64 respectively. (We choose 64 bit address spaces since stateless autoconfiguration requires 64 bits for the node address.) We will concentrate on the configuration of the router for fec0:0:0:1::/64 only. The other backbone routers are similar.

First, we must configure our firewall to use its new address space. We do this by once again changing the /etc/rc.d/init.d/IPv6-init script so that it looks like this:

/sbin/ifconfig eth0 inet6 add fec0::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

Also, we must configure our Router Advertisement daemon to broadcast the new address space. Thus /etc/radvd.conf looks like this:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSourceLLAddress on;
AdvDefaultLifetime 300;
AdvHomeAgentFlag off;
prefix fec0::/64 { # this is subnet0 on our site network
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Once again, note that we have configured the use of Router Advertisement using the ICMP protocol. This is a built-in function of IPv6 and allows our router to tell its clients the network addresses for which it is responsible during the autoconfiguration process. Additionally, the router tells the end nodes about a subset of available routes. This is not to be confused with routing protocols, which are used by routers to share routing table information among each other.

After configuration of Router Solicitation, we reboot the machine (of course).

Next, we need to setup a second Linux machine which acts as a backbone router. Because the machine is not a firewall, the configuration is quite simple. We need only to install the radvd software and make the following configurations:

/etc/rc.d/init.d/IPv6-init:

code:

#!/bin/bash

##

##

## The following lines are for a complex network

##   in which this machine is a router (and not a host)

##

/sbin/sysctl -w net.IPv6.conf.all.forwarding=1

/sbin/ifconfig eth1 inet6 add fec0::192.168.1.16/64

/sbin/ifconfig eth0 inet6 add fec0:0:0:1::192.168.1.16/64

And then our radvd.conf file looks like this:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSourceLLAddress on;
AdvDefaultLifetime 300;
AdvHomeAgentFlag off;
prefix fec0:0:0:1::/64 { #this is the 2nd site-local netw.
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Finally, we should create a routing protocol so that all backbone routers (and the firewall) can share routing information. Many textbooks state that an administrator "must" configure a routing protocol, but in high-society, we are also told that if we go to Paris, we must see the Louvre. In fact, just as there is no law regarding the necessity of tourists seeing the Louvre, there is no absolute requirement that a routing protocol must be configured. However, there are some good reasons to do it.


The best reason to implement a routing protocol is for administrative efficiency. A routing protocol allows an administrator to rapidly propagate changes to the network. The changes could be due to adding new equipment to enhance performance or could be due to link failure, in which case redundant links would be used to propagate the information about the failure. Imagine if an administrator added a router to a backbone system of a very large network. In a manually configured architecture, routing entries would have to be changed in potentially hundreds of places (introducing a greater chance of error).

A second reason for using a routing protocol is that, when used in combination with stateless autoconfiguration, the administrator can take advantage of dynamic IP readdressing. IP readdressing would be necessary, for instance, if the ISP for the user's network changes.

Finally, routing protocols (especially cost-based protocols like OSPF and EIGRP) allow
multiple routes for traffic and can compensate for slow links, etc. Manual routing tables do not provide any easy way to express that 80% of traffic should take one route and the remaining 20% should take another route, based on bandwidth utilization. However, using cost-based routing, traffic can be dynamically shaped to best use the resources. Thus gives the designer of the network some flexibility in its implementation.

Fortunately, the Linux community has a software package that allows use of many different routing protocols, including RIPng, which is the simplest dynamic routing protocol and is appropriate for our simple network. The package is called "zebra" and is available at [http://www.zebra.org zebra].

Installation of the software is quite simple.

1. Download the source ftp://ftp.zebra.org/pub/zebra/zebra-0.93b.tar.gz

2. Extract the source files from the tar ball with the following command:
$ tar xzf zebra-0.93b.tar.gz

This creates a directory called zebra-0.93b

3. Enter the directory and configure the source:
$ cd zebra-0.93b
$ ./configure
4. Compile the source:
$ make
5. Install the compiled binaries as the "root" user:
$ su – root –c ‘make install’

6. Next, edit the zebra configuration file:
# vi /usr/local