By buckwalter at 2004-11-22 20:18
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.
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):
would be divided into four bytes:
which in turn would be translated into decimal equivalents as:
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:
With IPv6 addresses, some shorthand can be taken. For instance, leading "0"s within each 2-byte piece can be dropped:
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:
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:
The subnet mask 255.255.255.0 would be represented in binary as:
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:
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:
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:
The subnet mask for a /64 network would be:
Then "bitwise AND" the 2 values together to get the network address:
(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:
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:
Or, by using the "First Octet" Rule:
Allocation 1st Octet
Class "A" 0 - 126
Class "B" 128 - 191
Class "C" 192 - 223
Class "D" 224 - 239
Class "E" 240 - 254
Figure 1.2 IPv4 Network Allocations
Bit Pattern Class of Address
However, in IPv6 we have 2 octets of information with which to divide our networks (also see RFC 3513).
Figure 1-3 IPv6 Network Allocations
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
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:
then the resulting 64-bit IPv6 interface ID will be:
or, in shorthand notation:
* 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: <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:
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:
Figure 1-5 IPv6 Multicast Scope Diagram
1 Interface-local (network interface card)
2 Link-local scope (same as link-local addr)
5 Site-Local scope (same as site-local addr)
8 Organizational scope
e Global scope
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:
Figure 1-6 IPv6 Well-Known Multicast Group Identifiers
Group Identifier Description
::1 All nodes
::2 All routers
::9 RIP routers
::1:3 DHCP servers
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]:
Figure 1-7 IPv4 Common ICMP Types
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
In IPv6, the common ICMP messages are retained, but there are a few additions:
Figure 1-8 IPv6 Common ICMP Types
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
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
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.
Figure 2-2 Registering for an IPv6 Tunnel
3. Once your tunnel is approved, you will be notified and given your tunnel information.
Figure 2-3 IPv6 Tunnel Information
4. And additionally, you will be given some examples of setting up a tunnel on a server machine:
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
All times are GMT -5. The time now is 01:48 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.