Chapter 9. IPv6 Addressing

Return Home

Chapter 9

IPv6 Addressing

Introduction to IPv6 Addressing

IPv6 Addressing Scheme Characteristics

Version

Traffic Class

Flow Label

Payload Length

Next Header

Hop by Hop Options Header

Destination Options Header I

Fragment Header

Authentication Header

Encrypted Security Payload Header

Destination Options Header II

Hop Limit

Source Address

Destination Address

More Bits!

A More Flexible Hierarchical Organization of Addresses

FP: Format Prefix

TLA ID

RES

NLA ID

SLA ID

Interface ID

Minimizing the Size of Routing Tables

Global Addresses for the Internet and Local Addresses for Intranet

IPv6 Benefits

Increased IP Address Size

Increased Addressing Hierarchy Support

Simplified Host Addressing

Simpler Autoconfiguration of Addresses

Improved Scalability of Multicast Routing

The Anycast Address

The Need for Further Development

The Multihoming Problem

The 6Bone

Summary

FAQ

 

Solutions in this chapter:

        Introduction to IPv6 Addressing

        IPv6 Addressing Scheme Characteristics

        IPv6 Benefits

        The Need for Further Development

First, in order to understand how IP version 6 (IPv6) can solve some of the current and future problems encountered with IP version 4 (IPv4), we must understand the motivation for its inception. This chapter will give a short introduction to the history and development of the IPv6 protocol, through its current accepted form.

Second, we will look at some of the key aspects of IPv6 that separate the protocol from IPv4, and look into the benefits that we can gain by utilizing IPv6 and its addressing schemas to build a more scalable network. From there, we can begin to build real-world examples of how this addressing can be deployed in Internet-connected networks to come.

Finally, we will look into some of IPv6s outstanding issues IPand its addressing schemes, and some of the proposed solutions to cope with these yet unsolved issues. Also in this section, we will give a brief introduction to the IPv6 test network, the 6Bone.

Introduction to IPv6 Addressing

By the early 1990s, it was clear that the Internet was going to take off. The average person was becoming aware of its existence, and the killer-apps of today (web browsers) were coming into their own. This dramatic increase in usage of the Internet, which stemmed from outside the research community, was clearly not going to go away. Address space delegations increased at an alarming rate, and it was clear that the Internet Protocol version 4 had a foreseeable upper limit in terms of the number of entities it could connect to the ever-increasing worldwide Internet. The Internet Engineering Task Force (IETF), the standards group from which a large portion of Internet technologies emerge, was beginning to see this as an issue that needed to be tackled earlier rather than later. At present, for example, regional numbering authorities (such as ARIN, RIPE, APNIC, etc.) are delegating numbers from within the 216/8 network block. In 1996, by contrast, ARIN was only delegating in the 208/8 range. This would mean that just over 150 million hosts were added to the Internet in this three-year span (if delegations and address assignments were made efficiently ). We calculate this by raising 2 to the power of 24 (for each /8) and multIPlying by 9. Although the Internet is growing at an alarming rate, and slowly working its way into our day-to-day lives, it is clear that 150 million hosts were not added. There was a major problem with address allocation, even after the efforts of CIDR (Classless Inter-Domain Routing) were implemented. Address space was being wasted . Furthermore, we know that 224/8239/8 is set aside for multicast, and that 240/8255/8 is reserved. From this, we can see that we are nearing our end (although some of the addresses in the middle, from 64/8128/8, are just now being delegated, so it will buy a little more time than expected).

Now we see that not only was there not enough space to take us far beyond the millennium , but also much of the current delegated address space was being wasted. Additionally, a greater need for enhanced Network-Layer (Layer 3 on the OSI stack) features was beginning to emerge, for example, end-to-end encryption, authentication of packets, source-routing, and Quality of Service. For all of these reasons, it was becoming apparent that a new Internet Protocol, or IP, was going to have to be conceived and adopted for the future of the Internet. This is where the fun began .

As people began to see these factors as a reality, many proposals for a new Internet Protocol emerged. The first draft that gained widespread notice was loosely based on the CLNP (Connection-Less Network Protocol), which was based upon another protocol suite, the OSI stack. This stack originally ran on the early Internet, but was quickly replaced by IPv4 when the Internet began to take on size and popularity. The proposal was coined TUBA (TCP/UDP over Bigger Addresses). CLNP does provide for a much larger address range than the current IPv4. Its Network Service Access Point (NSAP) address consisted of 20 octets, and would provide adequate addressing ranges for the Internets foreseeable future. However, this proposal was rejected because CLNP lacked some of the value-added features that were already installed into the current IP (quality of service, multicast, etc.), and these were determined to be important to the Internets future growth.

There was a proposal that attempted to create a packet format compatible with current IP, CLNP, and IPX. Yet another proposal, known as SIPP (Simple IP Plus), simply advocated increasing the current IP addressing format to 64 bits, and fine-tuning some of the feature sets of IPv4, as well as establishing better routing strategies. SIPP turned out to be the closest match for what the Internet needed, after some modifications. The addressing range was changed from 64 to 128 bits, and the name was changed to IP version 6, or IPv6 (IPv5 was already delegated to another protocol). This would be the protocol to solve the Internet scalability problems, and put us into the next millennium (and the foreseeable future).

In this chapter, we will learn more about the specifics of IPv6. We will begin by looking at IPv6 addressing schemes, and discuss how they can improve routing stability and efficiency. Then we will look at how the protocol design will aid in numbering and renumbering networks. Finally, we will discuss some of the value-added services that come with IPv6, and how they can benefit both residential users and big businesses on the Internet. We will also go into some details about the 6Bone, the IPv6 proving ground, where deployment and transition strategies are developed and tested .

IPv6 Addressing Scheme Characteristics

Now that we have looked at some of the history of IPv6, as well as some of proposals that competed with IPv6 as the new Internet standard, let us take a look at some of the generic characteristics of IP version 6. A full discussion of IPv6 can be found at www.ietf.org/rfc/rfc2460.txt. Figure 9.1 is the IPv6 packet header, taken from this RFC.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |Version| Traffic Class |            Flow Label                   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |          Payload Length         |   Next Header   |    Hop Limit    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                                 |

   +                                                                +

   |                                                                |

   +                          Source Address                         +

   |                                                                 |

   +                                                                +

   |                                                                |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                                 |

   +                                                                +

   |                                                                |

   +                       Destination Address                        +

   |                                                                |

   +                                                                +

   |                                                                |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9.1 IPv6 header format.

Lets look at these fields in a little detail (the next chapter will provide a more intense study of the specifics of the IPv6 protocol).

Version

The version field in the IPv6 header is so that Internet mechanisms that know how to route, or even speak routing protocols, will know what type of routing protocol they are about to deal with. Notice the similarities to IPv4. In the case of IPv6, the Version field is a 4-bit integer, with the value of 6 (0110 in binary), to designate this packet as an IP version 6 packet.

Traffic Class

The Traffic Class field is an 8-bit field in which some sort of traffic differentiation identifier can be placed. Currently, in the IETF, many working groups are dedicated to coming up with the best way to utilize this type of differentiation mechanism (though they mostly concentrate on IPv4 today). One example of such a group is the DiffServ (Differentiated Services). The members of DiffServ are trying to come up with a way to give more important traffic a higher priority for routing on the Internet today. This field was designed for things such as IP Precedence bits (giving certain values of this field higher priority, and then using differentiated queuing strategies in the router to tell who goes first). You can learn more about DiffServ on the Web at www.ietf.org/html. charters /diffserv-charter.html. A number of drafts and RFCs have been written with ideas as to how to implement such a policy. The list of current open drafts (they are only good for six months after writing, at which time they need to be resubmitted, just to keep things current) and RFCs is at the bottom of the aforementioned URL.

Flow Label

This is a 20-bit field used when special handling of a packet is needed. Common interpretation of this field at the time of this writing is that the field will assign flow labels in order to engineer different traffic patterns in an IPv6 network. The major player in this (though for mostly IPv4 at this time) is the MPLS (Multi-Protocol Label Switching) working group. To see the groups charter, please see www.ietf.org/html.charters/mpls-charter.html. This groups main intention is to come up with an efficient way to assign labels to flows, and to come up with an efficient and scalable way to route based on these flows. A flow can be defined as any class of traffic going from one point to anther, whether point-to-point traffic, or a TCP flow from one end-station at a given port to a destination end-station on a given port. The possibility of assigning flows opens up many interesting options for deployment. Perhaps Quality of Service (quite a buzzword in the field today!) can be deployed with scalability this way. Many Internet providers are keeping their eyes wide open as this working group develops, since advanced services that the MPLS working group sees as feasible could lead to ground-breaking new developments in the Internet industry as a whole.

Payload Length

This 16-bit integer is used to designate the length of the payload (the data) in the IPv6 packet, in octets. Notice this field is 16 bits long (2 raised to the power 16), which gives us over 64,000 different possibilities, allowing IPv6 to have fairly big packets (over 64,000 octets). To have the ability to make big packets can increase the efficiency of the Internet as a whole. When your packets are bigger, the number of packets needed to send a given amount of data becomes smaller for a given flow. When there are fewer packets to route, then a router has more time to route other packets, or perform other tasks (routing table maintenance, cache aging, etc.). You can see how this can help to increase Internet efficiency altogether. Note that any extension headers (see later) outside of this header are included in the total packet length in this case. Compare this with the IPv4 case (RFC791) where the total length field includes the IPv4 main header.

Next Header

This field is designated to tell routers if there are any other headers that need be looked at for the packet to route according to instruction. This differs drastically with the IPv4 case, where there is only one header with a fixed length. The IPv6 main header is fixed length as well (allowing routers to know beforehand how much of the packet they need to read), but has built-in functionality to stack other headers that provide other value-added services, on top of the main header. This field is 8 bits in length, allowing for up to 255 types of next-headers. Currently, only a finite amount of next-headers are developed. Here is a list of the ones currently on the plate:

        Hop by Hop Options Header

        Destination Options Header I

        Routing Header

        Fragment Header

        Authentication Header

        Encapsulating Security Payload Header

        Destination Options Header II

The preceding list shows the selection of Next-Header fields that can occur in an IPv6 packet. These headers are listed in order of the appearance they would make in an IPv6 packet utilizing this extra functionality. All of these headers will be discussed in detail in the next chapter, but for now, we can give a brief explanation of each one, and why they are in a particular order.

Hop by Hop Options Header

This header designates properties that are to be examined by each IPv6 speaking node in the path .

Destination Options Header I

This header is reserved for options to be performed by the destination concerning handling of the packet. Notice this header is the first of two with the same name. In the case of IPv6 packets, with the Hop by Hop header in use, the destination can be the next hop on the router. This is the motivation for putting the Destination Options header right behind the Hop by Hop header. For a full descrIPtion of this header and its options, read on, and see RFC 2460, the protocol specification.

 

Routing Header

The routing header designates a list of intermediate nodes that a packet must traverse prior to arrival at the final packet destination. This is analogous to the functionality in IPv4 known as Loose Source Route and Record. This allows you to designate, at the very least, a set of routing devices that a packet must travel through on its way to its destination.

For IT Professionals Only

How Much of IPv6 to Enable

As an Internet backbone engineer, you can see that this may not be something that Service Providers would want to enable on their networks. Think of the ramifications : Suddenly, the way that you design your network can become irrelevant! Customers can now pick and choose their path through the network. This can lead to very difficult build-out strategies. Although this may have benefits for organizations savvy enough to route around congested areas, I believe there are other considerations to look at prior to deploying this on a live Backbone.

Fragment Header

This header is used by the source to send packets that are bigger than the defined Maximum Transmission Unit, or MTU of the path. Normally, in IPv4, intermediate nodes may fragment packets in order to fit the standards of given media that the packet may traverse. Each media, be it Ethernet, FDDI, or other, is designed with a specific MTU in mind for optimal performance of the given media. In contrast, IPv6 does not allow for fragmentation of a packet at an intermediate point through the path. Instead, the IPv6 speaking device will undergo MTU Discovery. In this, IPv6 will use ICMPv6 (Internet Control and Message Protocol version 6) to send packets hop-by-hop through the path from source to destination, each time reporting the MTU for that particular link between hops. The lowest value for MTU is used as the maximum size packet that the source will send (again, this can increase routing stability and efficiency, since routing entities now dont have to spend time and CPU fragmenting packets, but can concentrate on simply routing them). This header is used when the source wants or needs to send a bigger packet than the largest MTU that was discovered .

Authentication Header

This header is used if the need for end-to-end authentication exists. It contains a method of authentication so that a destination can be sure that a given packet is, in fact, from the source that it says it is. Please note the order of this header in the line. We allow for the preceding headers to come first for good reasons. For instance, if a source and destination are using complex authentication, but we still want to utilize the Hop by Hop header, no authentication information needs to be read or tampered with along the path. Think of the extra CPU time if all routers had to authenticate packets prior to routing them! We can still use the Hop by Hop or Destination Options I (the hop by hop destination) without having to check or tamper with the authentication.

Encrypted Security Payload Header

Now that we have methods to ensure that packets come from the source that they say they do, we need some way to ensure that no one can read the payload of the packet along the way. The Encrypted Security Payload (ESP) header allows for encryption of both the data in the packet, and all headers behind it, in order to ensure security of the data in the packet. Details of this header can be found later in the next chapter, or in the RFC archives. The combination of this header and the Authentication header make up IPSec (IP Security). This is currently being implemented with IPv4, but since it is not inherent in the protocol, the IETF is challenged to make this work in a way that is not severely performance enhancing. This is one of the benefits of IPv6: It is already built into the protocol, so minimal performance hits are required to enable this functionality.

Destination Options Header II

This is similar to the Destination Options header I, except this header is designated for options destined for the final destination only. Note that the ESP and Authentication headers come prior to this header in order. This will allow secure Options to be passed without worrying about someone learning something valuable about the destination while the packet is in transit across the Internet.

So as we can see, the next header field is of vast importance to security and value-added services associated with IPv6. Also of note, Service Providers may not always have their Backbones listen to certain next headers, as they can cause routing inefficiency. Notice the VPN solutions that can result from the Authentication and ESP headers alone. Does this mean that Internet data will now be secure? At the time of this writing, it definitely looks like a good attempt at data security over the Internet. Ramifications of IPv6 deployment with full functionality could include the collapse of the Intranet (secure Internet), which uses physically separate backhaul facilities in order to prevent data or machines from getting attacked or stolen by mean Internet users.

Hop Limit

This is similar in function to the TTL field in IPv4. It specifies the number of Layer 3 (Network Layer) hops that a given packet can traverse before a routing system will discard the packet. Having a limit such as this is of vital importance. If a routing loop occurs on the Internet, as they sometimes do even today, packets have the potential to circle around and around to infinity. If a user gets tired of waiting, and sends more packets, you can see how quickly this can bring certain areas where a loop exists to its knees. To fix this, the TTL field is used in IPv4. This originally was meant as a Time To Live (in seconds) parameter, by which a packet will be discarded if it exists on a network for a specified amount of time. It was quickly determined that this was not the best approach, so the concept of Hop Limit came into being. Every time a router receives a packet, the TTL field is decremented by 1. When a packet is received with a TTL of zero, the packet is discarded. This helps to ensure that packets do not exist forever on the Internet, taking up valuable CPU cycles and bandwidth. In IPv6, the Hop Limit field is 8 bits long, giving a maximum of 255 routed hops between source and destination. Although we would be extremely dissatisfied if we had to traverse even 100 hops from a source to a destination today, this field is given a high available maximum value to ensure that future routing requirements are met. Who knows how many hops your home refrigerator will be from your office?

Source Address

This is the IPv6 address of the machine that originates the packet. This is discussed in detail later in the section.

Destination Address

This is the 128-bit IPv6 address of the destination for the packet (note that based on the Next-Header field discussed earlier, this can be the final destination, or an intermediary destination, depending on which next headers are used).

More Bits!

Internet Protocol version 6 was developed to rescue the Internet from current problems discussed in the Introduction section of this chapter. First and foremost of these problems is the address scalability problem that the Internet faces today. The current Internet Protocol address field, being only 32 bits in length (see IPv4Figure 9.2), can be shown to have scaling problems given current Internet growth. It is becoming clear that the number of Internet-connected entities will only increase as time passes . Eventually everyone will be connected, and given population expansion alone, we can see scaling problems already (a 32-bit address field provided for roughly 4.2 billion addresses). When you take into account other devices that either already are, or may be, connected to the Internet in years to come (phones, television, routers, radios, diagnostic equIPment, Web servers, refrigerators!), we can see this problem only getting worse . If you then factor in the legacy problems with IP wasting (owning more IP addresses than you have assigned to Internet entities), it is clear that another solution is needed.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |Version|   IHL   |Type of Service|           Total Length          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |          Identification         |Flags|       Fragment Offset     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Time to Live |     Protocol    |          Header Checksum        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                        Source Address                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Destination Address                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Options                     |     Padding     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9.2 IPv4 packet header format.

IPv6 does a good job at handling this problem. Rather than the 32-bit address field of IPv4, IPv6 was designed with four times as many bits for addressing. With 128 bits for addressing (see IPv6Figure 9.3), we are left with enough address space to accommodate future growth as predicted within the IETF (128 bits is roughly enough for 4.2 E37 (4.2 *10 to the power of 37) Internet connected entities. This is roughly equivalent to having 8.27E+016 unicast Internet addresses for each square millimeter of Earths surface! As we can see, this appears to scale to future growth for what hopefully will be a long time.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |Version| Traffic Class |            Flow Label                   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |          Payload Length         |   Next Header   |    Hop Limit    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                                 |

   +                                                                +

   |                                                                |

   +                          Source Address                         +

   |                                                                 |

   +                                                                +

   |                                                                |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                                 |

   +                                                                +

   |                                                                |

   +                       Destination Address                        +

   |                                                                |

   +                                                                +

   |                                                                |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9.3 IPv6 packet header format.

Before we dive into the addressing schemes inherent to IPv6, let us first look at the new convention for expressing IPv6 addresses. Contrary to IPv4, which uses dotted decimal notation, with one number per octet of its 32-bit address, IPv6 utilizes hex notation for describing its addresses. Although dotted decimal notation is well suited for the relatively short IPv4 host address, it does not scale well to the 128-bit IPv6 host address (with dotted decimal notation, we would need 16 numbers to designate each host). With hex notation, each digit signifies 4 bits of address space, cutting address length, when written, substantially. Table 9.1 summarizes how hex notation differs from dotted decimal notation. Notice that hex notation has 16 values, instead of the classical 10 values of decimal notation. This allows a byte of data to be summarized by two digits. Therefore, an address in IPv6 will look a little different from what you are used to. However, with a little practice, hex notation becomes easy to use. For instance, the IPv4 address 24.172.96.240 can be written in hex (with dots in the same place) as 18.AC.60.F0.

For IT Professionals

This Is the Trick

This is something to become proficient at as soon as possible when deploying IPv6. Subnetting, as you have known it, is usually the hardest part to master with Hex notation. Practice, however, will make this easy after continued use. The trick is to forget about trying to translate between dotted decimal and hex. Instead, allow yourself to actually think in hex, and things will become a lot easier much more quickly.

Hex notation is useful for condensing large numerical expressions. Each digit expresses 4 bits of the address. The next convention to know about that differs from IPv4 is that addresses are grouped together in groups of 16 bits. For instance, a sample IPv6 address may be 3FFE:2900:B002:CA96:85D1:109D:0002:00AD. The colon (:) is used as a delimiter in IPv6 addresses. Most implementations will support dotted decimal notation as well, to aid in a smooth transition in the networking community (old habits are hard to break, you know), but the agreed upon convention will be hex with colon delimiters.

Now that we see how IPv6 addresses are formed , we can use a couple additional conventions to aid in IPv6-address hex expressions. The convention carries over from IPv4: All zeroes that are to the left of a given 16-bit expression may be left out. For instance, the IPv6 address 3FFE:2900:C005:001A:0000:0000:0AD0:0001 can be reduced to 3FFE:2900:C005:1A:0:0:AD01:1, which saves substantial time. This is analogous to the writing of the addresss (for example) in IPv4 of 199.000.055.085 as 199.0.55.85. The second convention helps even more. It states that if there is more than one string of 16 binary zeroes in a row, they can be omitted. In place of the zero strings, we simply use the double-colon (::).From the preceding address, we can express this address as 3FFE:2900:C005:1A::AD0:1, which shortens the expression even further. Please note that the double colon can only be used once in an address. Since the length of the zero string is unknown, any IPv6 node interpretting the expression would not know how many 16-bit zero strings to pad the address with, if this shortcut were to be used more than once. For instance, 3ffe:2900:1::1::2 could be 3ffe:2900:1:0:1:0:0:2 or 3ffe:2900:1:0:0:1:0:2.

When we look at both of these shortcuts in full use, we can see that addresses can become especially easy to express. For instance, the IPv6 6Bone address 3FFE:2900:0000:0000:0000:0000:0000:0001 can be written as 3FFE:2900::1. This dramatically reduces both the time to write IPv6 addresses, and the thinking associated with making sure that you get all 128 bits into your expression. Now that we have all of these rules down, we can begin to look at the protocol addressing scheme in more detail. Familiarize yourself with Table 9.1 prior to moving into the next sections of this book, as hex will be the normal method for expressing IPv6 addresses from here on out.

Value      Hex Notation   Decimal Notation    Binary

0     0          0              00000000

1     1          1              00000001

2     2          2              00000010

3     3          3              00000011

4     4          4              00000100

5     5          5              00000101

6     6          6              00000110

7     7          7              00000111

8     8          8              00001000

9     9          9              00001001

10    a          10             00001010

11    b          11             00001011

12    c          12             00001100

13    d          13             00001101

14    e          14             00001110

15    f          15             0000111

Table 9.1 Hex to Decimal Translation Cheat Chart

Now that we have more bits from which to address Internet entities, we need to make sure that we have sufficient means for all of these machines to talk with one another. In other words, we must also incorporate into the new Internet Protocol ways for routing to maintain an efficient state. Just imagine the processing power Internet backbone routers would need to have in order to retain and process against a list of every host in IPv6! At the time of this writing, there are between 62,000 and 65,000 classless routing entries in the Internet default-free backbone routing tables. This number is increasing, but at a much slower rate than address allocations (providers are delegating address space that can be aggregated into supernets; this keeps global routing table growth less than that of Internet connected entity growth). We need to ensure that the upper limit of routing entries with IPv6 is still within foreseeable limits of what Backbone routers can hold, and process upon, quickly. In the following sections, we will first look at how IPv6 addressing works, and then look at how this addressing scheme ensures that these concerns are sufficiently addressed.

A More Flexible Hierarchical Organization of Addresses

As stated earlier, any protocol that replaces the current IP will need to not only provide for more Internet routable addresses, but it will also have to contain inherent mechanisms by which to ensure a stable and efficient backbone routing system. If we were to adopt an Internet Protocol without addressing this issue, we may solve an address space problem, but getting from one point in the Internet to another will become cumbersome for Backbone routing equIPment and could lead to a less stable Internet on the whole. Many Internet gurus today envision the Internet replacing all prior means of communication, be it phone, television, radio, etc., so the routing stability issue has to be held in high priority for this dream to become reality. In this section we will look at one of the main improvements IPv6 attempts to make over IPv4, and study the effects this can have on Backbone routing tables.

Although IPv4 first routed based on classful entries (Class A, B, C blocks), it was apparent that this was not sufficient for wide-scale deployment. Then, the concept for Classless Inter-Domain Routing was developed. With CIDR, the concept of classes went away, allowing the ability to aggregate smaller networks into supernets, or to break up big blocks into subnets. This increased the efficiency of network addressing, because we could now address a network with the appropriate sized network block, regardless of what class the address fell into. With this new development, IPv4 addresses were now used more efficiently, but there was a side effect on the Backbone routing tables of the Internet. Instead of carrying the first 128 blocks of network space with 128 entries, these networks could now be spread out over large noncontiguous geographic areas. This caused routing-table size to grow at an increased rate.

Let us perform a mental exercise to help demonstrate this point. Suppose that Internet-connected Network I has two Internet Providers, A and B. Network I has been delegated a subnet from Provider A from which to address their Internet connected machines, to provide for Internet routability. When this provider runs BGP, he announces this subnet up to both providers. This is where the problems occur. If Provider A decides to announce to its peers only the aggregate of the Address block from which Network I was given a subnet, only traffic originating on Provider As network (and sometimes not even that) would use the connection from Provider A to Network I to get to Network I. Since Provider B receives, and passes on, the subnet that Network I announces, all Internet traffic will use Provider Bs connectivity to Network I for its best path (via the longest match routing rule). We can see that this limits a downstream networks ability to load-balance between multIPle provider links. The only solution that would allow Network I to control its traffic load on either connection would have to include the external announcement of both the Aggregate and the subnet from Provider A to its peers.

For IT Professionals

BGP Functionality

BGP4 (Border Gateway Protocol version 4) will do this automatically, since the originator of the subnet will be the Autonomous System of Network I in this example. The route will be announced to both providers, unless either one has a policy in place to filter this announcement. This is how most Internet Backbones today take care of this problem. This is also why most Tier 1 providers will not allow a customer to use static routing between the Provider and the customer, if that customer is multihomed to multIPle providers, since this would break this model of deaggregation via BGP4.

So as we can see, the inception of CIDR provided for more efficient use of Internet Routable addresses, but in turn , it also reduced the efficiency of Internet routing tables. When this example is expanded to the global Internet, we can see that this is a problem. IPv6 makes some good modifications in policy to rid the Internet of both problems.

The IPv6 address consists of 128 bits. One thing that IPv6 has over CIDR is a built-in, well-defined set of boundaries from which to define sets of address space to delegate downstream to other people who get Internet connectivity from you.

   | 3|   13 | 8 |    24    |    16    |           64 bits                |

   +--+-----+---+--------+--------+--------------------------------+

   |FP| TLA |RES|   NLA    |   SLA    |          Interface ID            |

   |   | ID   |    |   ID     |   ID     |                                 |

   +--+-----+---+--------+--------+--------------------------------+

Figure 9.4 Globally routable IPv6 addressing architecture.

Notice in Figure 9.4 that the IPv6 globally routable unicast prefix is divided into six different sections. Let us look at each section in detail.

FP: Format Prefix

The Format Prefix for globally routable unicast prefixes will always have the same three bits (in the initial deployment of IPv6). These first three bits will always be set to 001, and are there to designate (to any routing entity on the Internet) that this address is a globally routable unicast address. For each type of IPv6 address that we discuss, the FP will be unique to that type of address, thus making it easier for routing entities to discern packet types, and process them according to the rules that apply to the respective packet type. For instance, multicast packets and unicast packets are routed in very different ways. Unicast packet routing is 1-to-1 (a packet with an IPv6 Globally Routable Unicast destination originates from one host, and is delivered to one host), and multicast packets are are1-to-N (one multicast packet may be delivered to N interested destination hosts), or N-to-N (N sources delivering packets to N destinations), so these packets are handled in vastly different ways on an Internet backbone. The FP serves as a delimiter, so a routing device can make a quick decision as to how to handle the incoming packet, and ensure that it is handled correctly. Note that using the first few bits of an address to designate type of address is more efficient than putting it into the packet, because now we can utilize more of the packet for other valuable features, discussed earlier.

TLA ID

This is the Top Level Aggregator Identifier, 13 bits used to signify to which Top Level Aggregator the address belongs. A Top Level Aggregator is a Network Provider that sits at the top level of aggregation of Internet traffic. In unicast terms, Top Level Aggregators are sometimes referred to as Tier-1 Providers. These are Internet Providers who make up the core of the Internet Backbone. They usually have equal part peering (they dont pay the other provider to receive the other providers routes) relationshIPs with other TLAs (nonpaid connectivity to other TLAs), encompass a large area of the globe with coverage of Internet core routing, and provide the high-speed transport that moves packets from one part of the globe to another. Their Backbones are composed of highly sophisticated, fast-routing devices, and their cores carry full Internet routes. Current examples of Top Level Aggregators include Sprint and WorldCom. In IPv6, providers of this caliber are given blocks of IPv6 Globally Routable Unicast addresses (a TLA assignment), and they, in turn, delegate pieces of this block down to their customers.

RES

These bits are reserved for now. It has not been determined by the IETF what course of action should be used for these bits. At this stage, it is appropriate for TLAs to subnet their assignment using these 8 bits to increase the amount of Globally Routable Unicast address space that a TLA can use to delegate to their customers, or use on their Backbone.

NLA ID

These 24 bits depict the Next Level Aggregator Identifier. A Next Level Aggregator can be thought of today as a Tier-2 Network Service Provider or ISP. An NLA can range from a small organization with one TLA connection, to a large, regional Provider with many upstream TLA connections, and complex Backbones. An NLA will receive an NLA ID from their upstream TLA, and in turn, will break their NLA ID into chunks , which will be delegated to their customers.

SLA ID

A Site Level Aggregator Identifier describes an entity that has no downstream customers who are network service providers. A SLA could be a small to large business, or a small Service Provider who does not delegate address space to its providers (for instance, todays cable-modem providers could fit into a SLA arrangement).

Interface ID

The final 64 bits of the globally routable IPv6 unicast address is reserved for the Interface Identifier. In IPv4 terms, this is known as the host id. These 64 bits will be designated to distinguish one host from another on a given network segment. Each Interface ID on a given network segment must be unique. We will see that IPv6 builds in a clever way to ensure this is so.

Aggregation Realized

Now that we know how the IPv6 Globally Routable Unicast address format is split up, we can begin to see how aggregation based on this format is possible. Figure 9.5 depicts a TLA that has a variety of customers for which they provide transit Internet connectivity. By delegating a subset of their address space (TLA ID) to each customer, depending on that customers purpose, they are ensured that all address space that is advertised to them from their downstream customers is a subset of their address space. This brings up a good point regarding the political changes surrounding IPv6. With IPv6, small to regional Network Service Providers as well as end-users will no longer have the ability to obtain address space directly from registries. Instead, Top Level Aggregators will be assigned address blocks, which they will in turn be in charge of managing and delegating down to their downstream connections (NLAs and SLAs). This shift in address management is thought to be much more efficient than the current address management policies of today. If a small to midsize ISP/NSP can no longer get address space from registries, and therefore put a burden on Backbone TLA core providers to carry these routes as transit, then the possibility of aggregation beyond what IPv4 can do today becomes a reality. In the next section, we will look at how this aggregation works, and why it will increase the stability of the Internet as a whole.

Figure 9.5 A generic IPv6 Internet.

Minimizing the Size of Routing Tables

As we have discovered, IPv6 will allow ample address space for the future of the Internet. With 128 bits of address spacing, there should be adequate addresses for Internet connected entities to grow in number and complexity. With a well-defined format for IPv6 addressing, we can see that addressing becomes more organized than classical IPv4. From this, we will now look at how the addressing scheme for IPv6 helps to minimize the number or Internet Core routing entries that need to be carried, thus limiting the scope of future Internet routing complexity. In Figure 9.6, we see two TLAs, with various connected customers of both the NLA and SLA variety. Let us look at the routing announcements necessary for this scenario to function with stability and efficiency.

Figure 9.6 Generic addressed IPv6 Internet.

In Figure 9.6, we have two TLAs (Tier 1 Network Service Providers) and a variety of NLAs and SLAs in various configurations. TLA I is in a bilateral peering arrangement for TLA II, and both exchange routes via BGP (there are changes to BGP that are currently in IETF working groups to support different types of NLRI (Network-Layer Reachability Information), so BGP4 very well may not be the standard BGP by the time IPv6 is deployed; for the purposes of this example, BGP4 will serve adequately). TLA I owns a Top Level Aggregator Block. In this example, we designate TLA I with 3FFE:2900::/24 as its TLA delegation, and TLA II with 3FFE:4200::/24 as its TLA delegation. So we know that TLA I and TLA II must supply each other with these routes at a minimum for routing to operate properly between TLA I and TLA II Backbones.

TLA I will subdelegate blocks of address space to its NLA and SLA customers. In this case, let us assign NLA I with 3FFE:2900:1::/48, and NAL II with 3FFE:2900:2::/48. Furthermore, these NLAs must delegate blocks down to their customers out of this block. Let us assume SLA I will be given 3FFE:2900:1:10::/63, SLA II 3FFE:2900:2:20::/63, and SLA III 3FFE:4200:D:E::/63.

Starting at the bottom aggregators, SLA I must announce its block 3FFE:2900:1:10::/63 up to NLA I. Because this is a subset of NLA Is space, NLA A is not required to announce this SLA (from SLA I) up to TLA I. A similar situation exists with NLA II. TLA I only needs to hear the NLA aggregations that it delegated down to these two NLAs, regardless of how that NLA has subdelegated its space.

So from this, we can see that at this point, TLA I has to carry only three announcements for nonbackbone space:

3FFE:2900:1::/48 (from NLA I)

3FFE:2900:2::/48 (from NLA II)

3FFE:4200::/24     (from TLA II)

Figure 9.7 Routing advertisements along aggregation paths.

Even further, we notice that the first two of these announcements are simply subsets of the block assigned to TLA I. Therefore, in the bilateral peering between TLA I and TLA II, we can see that only one route needs to be exchanged between these peers. Although this is a limited example, we can see the routing simplicity that has come to pass as a result of this aggregation. The beauty of this comes from two facts.

The first is that no address blocks are portable . Today, a large part of IP space is known as portable. A portable address block is a block that can be taken with you when you leave a certain service providers jurisdiction, and go to another provider. This leads to many extraneous announcements in the core of the Internet backbone, as Network Service Providers lose the ability to aggregate announcements properly. For example, if a service provider is given the classless block 71.16.0.0/16, and loses one part of this, say 71.16.241.0/24, from its possession (a customer takes it with them when they leave), we are left with a suboptimal routing scenario. Now,

The Service provider has to announce this block one /16 to peers and customers as many different subnetsin this case, eight announcements (71.16.0.0/17, 71.16.128.0/18, 71.16.224.0/19, 71.16.240.0/24, 71.16.242.0/23, 71.16,244.0/22, 71.16.248.0/21).

 

The Service Provider has to update its filters to peers to allow this lost block to be heard via BPG from peers.

Normally, this block would be denied , to prevent routing loops (see the note regarding BGP in a previous section of this chapter; the BGP4 provider helps a little due to the originating ASN). Not only is this a management nightmare for Network Service Providers, it is also extremely inefficient for the Internet core.

For IT Professionals

Not All Allocations Are as Depicted

It is important to note that not all allocations will go exactly as we cited earlier (in the IPv6 Internet example corresponding to Figures 9.6 and 9.7). NLAs generally will be given whatever address space is necessary for them to operate. They should be given as much address space as they can deploy efficiently, or delegate down to SLAs. So in reality, a TLA will delegate down a /X prefix, where 24<X<48, depending on what the NLA needs. The same scenario applies to the SLA. We dont want to waste IPv6 address space, but we dont want to limit business or world interconnectivity either.

So by removing portability, we have greatly increased the long- term efficiency of the Internet backbone routing tables. Some may ask, why dont we eliminate this in IPv4? This has been done for the most part; however, legacy portability has taken its toll on the Internet. Second, pressure still remains from downstream Internet entities. The argument is that not allowing IP blocks to be portable puts the customer under pressure not to change providers, because a big network is cumbersome to renumber with new IP space (DNS entries, as well as host reconfiguration is required). There is no way for IPv4 to provide a smooth transition from one Provider-delegated block of IPv4 addresses to another. IPv6 will need some mechanism to allow for smooth migration from one providers address space to another. We will see that this is the case. The use of anycast addressing, as well as auto-configuration of interfaces, aid in the pain of renumbering upon switching providers, or renumbering for any other reason. But lets put this aside for the moment to complete our study of routing tables. We will discuss strategies for renumbering in the next section.

The second reason is that only TLAs will be assigned address space from the Numbering Authorities. Today, IANA (the Internet Assigned Numbers Authority) is the responsible party for numbering, which in turn delegates numbers to Regional Registries, such as ARIN, RIPE, and APNIC. These regional numbers authorities in turn assign IPv4 address space to Internet providers, or businesses and organizations that can demonstrate sufficient need for their own IP blocks. Notice how this leads to more small blocks being carried in the core Internet table. This all goes back to renumbering problems. If renumbering were simple, then getting IP space directly from our upstream providers of connectivity would not be a big deal. If we are dissatisfied with service, we can simply get another provider, and then renumber. Many businesses today feel restricted in doing this, as renumbering in IPv4 is sufficiently complex to sway people away from going somewhere else when their provider is not satisfactorily providing service. By ensuring that only TLAs get address space, the Internet is assured that only big blocks of space are delegated, which will make sure that aggregation can always occur.

Global Addresses for the Internet and Local Addresses for Intranet

Now that we can see how the Internet core can benefit from IPv6, and we have touched on some of the nice things it provides to end-user networks, let us look at how a typical LAN will be addressed, and how its routing allows for robust and easily managed connectivity.

So far we have learned that Globally Routable Unicast IPv6 addresses follow a strict aggregation scheme. But does every machine need to have a Globally Routable Unicast address? Most companies today that are connected to the Internet have some subset of systems that route and speak IPv4, but do not necessarily need to be routed across the Internet, nor do they need to have their very own Globally Routable Unicast address. Certain systems, such as internal-only servers, printers, and other systems need be able to route on a company network, but do not need to be globally routed across the Internet. Furthermore, many companies wish there were a way to ensure that these systems could not be seen from the outside world. Today, this is remedied through security precautions : the firewall and the packet filter are the best ways to ensure (or hope to ensure) that some secret or important machines are not accessible from the outside. Although security is important, and will not go away with the invention of IPv6, there are other possibilities. IPv6 incorporates the idea of scoped addressing into its protocol stack. Scoped addressing, in addition to providing other functionality, provides for this problem.

Addresses are said to be scoped when the address in question has a well-defined boundary in which it will route. Furthermore, the scoped address does not route outside of this boundary, nor does it have a routing entry associated with it that leaves this boundary. To better understand, let us look at a diagram of a simple IPv6 network, and a generic example of how scoping can be used to ensure that machines operate only within their jurisdiction. Refer to Figure 9.8 to picture this type of scenario.

Figure 9.8 A scoped IPv6 network.

The machine labeled secure server cannot route outside of the boundary of its network, because it does not know about the rest of the world (it has no default route). The rest of the world does not know about it either (no routing entry is advertised to other routers about the existence of the link-local network[jjd1]   .)

 

In this network, we have some people who may be in another side of the building, who need to access Machine A. Also, Machine A can talk to other parts of the building. We still have the ability to use filters and firewalls (or some sort of security measures) to ensure this machine is invisible from the outside. However, classically, this can be dangerous, as most operators, no matter how good and careful, can make mistakes. Addresses that are not supposed to get announced to the rest of the world eventually will get announced, even if by accident and for a short period of time, when a mistake gets made. RFC 1918 designates reserved address space for IPv4 (RFC 1918: Address Allocation for Private Internets, www.ietf.org/rfc/rfc1918.txt). Note that in IPv4, it is left to the competence of the Network Operator to ensure that reserved address space is not announced globally. In IPv6, it is conceivable that a routing system will automatically know not to route link-local or site-local space between ASs.

As you have probably guessed by now, IPv6 addresses this problem, and does what many feel   IPv4 has tried to do too late. IPv6 has a set of address space that is scoped for different types of applications. Table 9.2 summarizes delegation of IP spaces.

    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
    Aggregatable Global Unicast Addresses 001            1/8
    Unassigned                             010            1/8
    Unassigned                             011            1/8
    Unassigned                             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 Unicast Addresses           1111 1110 10   1/1024
    Site-Local Unicast Addresses           1111 1110 11   1/1024
    Multicast Addresses                    1111 1111      1/256

Table 9.2 IPv6 Address First-Bits Standards

Table 9.2 summarizes how the first few bits of the IPv6 address will tell us what type of address it is. Notice that in three bits, we can see whether or not a given address is a Globally Routable Unicast address or not (001; which leaves as hex, either 0010 (2) or 0011 (3)). As a side note, this is pretty nice for routing systems!

So we can see that there are two levels of unicast scoped addresses. The first type of scoped address for IPv6 is the Link Local Unicast address, which exists only on the media that connects two or more machines together. For instance, on a PPP link (or HDLC, Frame-Relay, Ethernet, Token Ring) there will be a specific set of address space especially designed for that link. The motivation for this was to allow IPv6 speaking machines to have a set of addresses from which to link groups of machines together in order to communicate functions that are specific to that link. For instance, Link Local addresses can be used for things like Neighbor Discovery, or Auto-Configuration (discussed later). This allows all machines to have an address that allows them to talk to other directly connected machines (directly connected at layer 1 or 2 in this case; consider two machines that are on the same Ethernet subnet as being directly connected). Notice that in itself, this relieves some of the burden of renumbering. Although an administrator renumbers a network, for whatever reason, at least machines that need to talk to each other can still do so outside of the Globally Routable Unicast address. Link Local addresses are to be routed only on that link, and are not to be sent into any IGP (interior gateway protocol) or EGP (exterior gateway protocol; to other routing domains), for obvious reasons. They are Link Local after all! Most routing systems for IPv6 today have this functionality built into their operating systems (it is unclear whether routing systems will need to have this automatically built in at this time, but it seems to make the best sense that they do).

The second type of scoped address is the site-local address. This address designates a routing domain, or subset of a routing domain. Machines that are addressed site-locally will be able to communicate with other designated subnets through this addressing scheme, but will not route globally on the Internet. This can benefit us in some ways as well. Perhaps there is a need for a machine to speak with other internal machines at an office, but the administrator wants to make sure that that particular machine (perhaps an accounting machine for a company, for example) cannot route through the Internet. Through the use of Site Local addressing, we can accomplish this, without the intervention of complex security schemes to ensure that a machine is invisible to the bad guys out there that want to cause trouble (this does not substitute for a network security, but does ensure that packets coming from this host do not reach the global internet). The basic routing princIPles associated with Site Local addresses are common sense. A Site Local address may be routed through an IGP, but should never pass into an EGP. Again, most of the time, an intelligent routing system will have the ability to discern these routes by their unique addressing, and make sure that they are not leaked to the Internet.

Note

I am not implying that using Site Local addressing only on secure machines is the only security precautions that need to take place. For instance, someone who wants this information can always capture control of a machine that is at the same site, but has a Globally Routable Unicast address, and can then attack the site-locally addressed machine; security concerns to not go away, but obscurity does increase with this method.

Figure 9.9 Scoped addresses on a LAN.

So as we can see, IPv6 makes an attempt (and a pretty good one at that) for separating out addresses that are internal to a routing domain, or internal to a given network or link, and makes sure that the Internet routing table integrity is maintained . Now that we have an idea of what types of local addressing IPv6 has for us, let us look at some of the benefits of scoping. Figure 9.9 shows addresses that have been assigned to hosts in the Site Local, Link Local, and Globally Routable Unicast space.

Now that we have machines that can speak to each other on a LAN or link with well-known addresses that are always in the same range, we can look at some of the benefits associated with this scenario. Earlier in the chapter, we mentioned the problems associated with renumbering today in IPv4. Renumbering a network is rather complex with IPv4, because not only would you have to sit at every machine (or DHCP server at the least) for every network and reconfigure the LAN to use new IPv4 addresses, but also there would be considerable downtime with this approach. Furthermore, services such as Domain Name Service potentially could be drastically impacted by this undergoing, in that zone files would need to be changed to reflect new forward and reverse DNS entries for machines. If you are in the Internet business, providing access to services or information that needs to be reachable to consumers at any time, you can see how this can cost businesses money. Today, downtime is becoming more and more pricey as people begin to rely more and more upon Internet availability for business critical applications and information. We will see in the following sections how IP version 6 will help us to minimize downtime, while also helping administrators (those poor fellows) to keep up with network changes such as renumbering, more efficiently.

IPv6 Benefits

Now that we have looked into the promise that IPv6 gives to the Internet of the future, let us discuss some of the benefits of IPv6 in more detail, in order to see how this protocol attempts to deal with the Internet and business network problems of today. We will look at the two main problems that IPv6 solves address depletion and routing scalabilityin more detail, and then look at some of the added benefits that IPv6 gives to network designers and administrators.

Increased IP Address Size

We now understand that IPv6 has 128 bits for reserving. Let us look at this closer and appreciate the vastness of this degree of address space.128 bits of address space means that there are 2 128 different addresses available. Because we already know that the first three bits of 001 are reserved for Globally Routable Unicast addresses, we now have 125 bits left to play with (1283=125). So now we have 2 125 addresses available before Globally Routable Unicast address space is depleted, roughly, 4.25 E+037 addresses. To put this into perspective, let us compare this to IPv4. In IPv4, we use all address space between 0.0.0.0 and 223.255.255.255 for unicast routing (we will not take into account the addresses delegated as nonroutable reserved addresses as defined by RFC 1918), which is approximately 2.15E+09 addresses (3 times 2 29 , as there are three legal possibilities for the first three bits, 000, 100, 110, and 101). This means that there 2 31 more addresses than IPv4! Clearly, 128 bits provides enough address space to take current Internet trends well into the future. We could even argue that this is a seemingly inexhaustible amount of address space. Although this number is big, we will see, when we get into the details of LAN and WAN configuration, that this is not quite the case, but there is still many times the address space of IPv4. One thing to get used to thinking of in order to appreciate IPv6 is the number of networks that IPv6 can support. From the address format discussed previously, we know that, in an IPv6 address, the last 64 bits describes the host ID for a system on a network. Did this seem fishy when you read it? It probably should have. IPv6 actually uses the last 64 bits of the address to distinguish hosts from one another. Whether using the Link Local, Site Local, or Globally Routable Unicast address format, the last 64 bits on a machine will remain the same. This is because IPv6 uses the Layer 2 MAC address (the address that is burned into all Layer 2 hardware; for example, Ethernet cards or other Network Interface Cards) as the host ID for a machine. This does, in fact, limit the number of addresses that are out there, because there will rarely be 2 64 addresses in use on a typical Ethernet LAN (we could argue that there will never be 2 64 machines on a LAN; especially on 10 or 100 Meg Ethernet!). Some address space definitely gets wasted. However, if you remove the 64 bits used for host id, and the first three bits of address space to designate Globally Routable Unicast addresses, you get 2 61 possible (2.31E+018) networks, compared to 1.07E+09 that IPv4 provides ( assuming that every network in IPv4 is a /28, of which most are not; this number is derived by multIPlying 4 times the first 28 bits of address space). Notice that this is still 2.1 billion times as many networks as IPv4 allows, and IPv6 does not have the network restriction that we assume here for IPv4 (the number of IPv4 networks used here is for the number of LANs if all IPv4 networks were subnetted down to /28s; 13 hosts, one default router, one reserved, and one broadcast for the network). So we see that we have 2.1 billion times as many networks as this, and the IPv6 networks here can have up to 1.8E+19 hosts on each network (minus one for the default router). So even without using all of the addresses that IPv6 can use, we have the scaling ability to take us well beyond the future of IPv4, and in all likelihood , the scaling ability to take all of us through all of our careers in the IT field (or any other field). Clearly, IPv6 frees up the ability to use Addressing efficiently, without having to worry about running out. Please keep in mind that I do not mean to say that address space should be used in a carefree manner. This is how IPv4 came into the predicament that it is in so early in its life cycle!

Increased Addressing Hierarchy Support

As we learned earlier in the chapter, IPv6 addressing has restructured the means by which address blocks are delegated. Although IPv4 first used the classful IP assignment rules, and then began to assign based on the princIPles of CIDR, IPv6 corrects the deaggregation problems associated with each by splitting the IPv6 address into a set of definite scopes, or boundaries, by which IPv6 addresses are delegated.

The Format Prefix is used to show that an address is Globally Routable Unicast, or another type of address, and is always set to the same value. This allows a routing system to discern quickly whether or not a packet is Globally Routable Unicast, or another. By knowing this quickly, the routing device can more efficiently pass the packet off to routing subsystems for proper handling.

The Top Level Aggregator ID is used for two purposes. First, it is used to designate a big block of address from which smaller blocks of addresses are carved, in order to give downstream connectivity to those who need to get to the Internet. Second, it is used to distinguish where a route has come from. If big blocks of address space are given out to Providers only, and then in turn delegated down to customers, it becomes easier to see which transit network a route has traversed, or from which transit network the route first originated. With IPv4, where historically, many addresses were portable and the numbers authorities were delegating blocks down to small businesses, it became impossible to know where a route came from without tracerouting back towards the source of the packet. Now, with IPv6, the possibilities for determining the source of a route are more feasible. Imagine an Internet consisting of 500 Tier 1 providers. If this were the case (which is most likely not too far off from today, though what makes a provider a Tier 1 provider is very ambiguous) then at the very least a quick search through a text file could tell you where a route originated, based on the TLA ID of the longest match route. Its even possible to contain software that has this functionality built into it (though I know of none currently in existence, and this software would most likely become outdated quickly, as new delegations were assigned).

Let us look at the size of the TLA in more detail. We discussed in prior sections how the address space would be given only to Providers, or those who needed their own IPv6 space (the term needed is used cautiously here, as it is ambiguous as wellthere are currently no set boundaries or requirements with respect to what need means). This way, we are able to sufficiently aggregate prefixes into big blocks at the Internet core, and pass fewer routes between routing domains, as well as internally, which will increase the efficiency of the Internet core.

For fun, let us assume that we have the delegation 3D00::B234::/24. Let us further assume that all of our customers have sufficient need for a /48 delegation for their networks. This leaves us with 24 bits of addressing to delegate out! This is quite a lot of address space. The number of networks we can support with this scheme is equivalent to the number of hosts that we could support with a classful Class A IPv4 address block! You can see that there will be much more pressure on Tier 1 Service Providers to efficiently track the delegation of address space that they make. Today, a Tier 1 Service provider gets addresses in blocks of perhaps /16 or less. If we assume that a Service Provider today only delegates addresses up to /24, that leaves only 256 delegations (8 bits) that the Service Provider can make prior to applying for more address space. Most Tier-1 Service Providers today are required to subnet delegations down to at least /28 in order to qualify for more address space, so this example may not be entirely realistic, but we can still grasp the size of a TLA as being monumental compared to that of the assignments that happen today.

For IT Professionals and Managers

We can see that this amount of address space presents tremendous support infrastructure problems. Service Providers that today provide DNS service for their downstream customers will have to think long and hard of the best way to implement these support structures, prior to getting into the IPv6 market.

As we can see from the previous example, Tier 1 Service Providers will have an extremely big set of address space to deal with. This will not only eliminate much of the politics surrounding address delegation and obtaining more address blocks, but will also provide motivation for major support and automation infrastructure upgrades within an organization. Many Service Providers today have difficulty in upgrading support structure due to the engrained functionality and interdependencies of many support platforms integrated together. IPv6 provides for great challenges and opportunities not only in network engineering and architecture, but also in IT development and integration. The trick will be making a move from the old to the new world look like a fresh start, rather than a workaround for support.

The Next Level Aggregator address block is a block of addresses that are assigned to a downstream out of a TLA block. We know that these addresses are to be aggregated as much as possible into bigger TLA blocks, when they are exchanged between providers, in the Internet core. Let us look at the benefits of this type of addressing structure from the NLA perspective.

There are two main values in getting address space from a provider. The first advantage or value has to do with individual Backbone routing stability. If we are a NLA and wish to provide downstream service to our customers, we will most likely wish to provide the fullest, most robust service we can to our client base in order to retain current clients , and to gain market share. Perhaps we wish to allow customer to connect to us at multIPle locations, as we are fairly geographically diverse for a given region, and have rich connectivity upstream to Internet Tier-1 (the core) providers. Furthermore, we want to allow our customers to receive a full routing table should they desire one, if they want to use explicit routes to form their routing policy. Perhaps they wish to load-balance between two connections, using some destinations preferred through one connection, and the rest preferred through the other connection to us. To do this, we have to carry full routes in our Backbone, so we may pass them down to our customers. Though an Internet core is usually composed of very modern, robust routing equIPment, a Tier-2 provider may not be able to afford to upgrade their Backbones constantly in order to keep up with new technology, as well as increased routing table size. Luckily, processing power is not as big of a worry as it could be with IPv6. Because the Internet core is fundamentally aggregated efficiently, we now have a much smaller routing table to maintain. We can provide full routes to a customer, and that set of routes may not be too big for us to handle. So by everyone playing nice and following aggregations strategies, we are able to reap the benefits of the cores minimized routing table size in our own Backbone.

The second benefit to NLA aggregation has to do with actual route stability of our routes across the Internet core globally. A little background is needed in order to fully appreciate this point. In the beginning of the Internet explosion in size, there were times when the Internet was not very stable. BGP speakers would lose routes, due to Backbone links failing, immature software, and the like. Because of this, routes were constantly being advertised, and then withdrawn (when the route becomes unreachable), causing considerably more processing to take place on core routers, which are required to keep an up to date set of full Internet routes at all times. To combat this BGP instability, the concept of route dampening came into being. Essentially, route dampening works in the following way: Every time a route is withdrawn and readvertised, it is assigned a penalty, which is kept track of at the place of instability (usually an EBGP session). The more the route flaps, the higher the penalty associated with that route gets. When the penalty associated with that route reaches a certain level, the route is withdrawn, and not accepted for advertisement for a given period of time. When this happens, the route is known as dampened . The dampened route must undergo some period of wait time, without flapping more (or the penalty gets even higher) before it can be re-introduced into a routers BGP table. When the route goes for a long enough period of time without flapping (the penalty decreases with time) then the route is again allowed, and it is inserted back into the routers BGP table, and treated like other routes. This route dampening allowed a way for the Internet core to deal with instabilities in a manner that minimized the cost of other crucial processing.

Now that we understand route dampening, we can appreciate the second benefit of aggregation. When our upstream provider aggregates this route for us, and only announces the aggregate to their peers, this aggregate will in all likelihood remain stable, without respect to the stability of our own network. Because of this, we are virtually certain that another provider will never dampen our routes somewhere else in the Internet. None of the more specific routes that we use need be spread across the Internet core, outside of our own upstream provider. This improved routing stability is a major benefit to aggregation as a whole, both in IPv4, and in IPv6. The good part is that it is required in IPv6, instead of only being recommended. So now, the only place that we may need to worry about being dampened is within our own upstream providers network. Fortunately, because in most cases, we are paying for our upstream connectivity, it is substantially easier to get our own upstream provider to help us to remove the penalties on dampened routes than it is with another provider, with whom we have no financial obligation.

So as we can see, with the exception of more addresses and smaller routing table sizes, there are more ramifications of IPv6 aggregation schemes than first meet the eye.

The Site Level Aggregator enjoys most of the benefits that an NLA does, except for its size. The Site Level Aggregator is usually a network or network provider with a much smaller network. Because of this, a smaller delegation of address space is needed. It retains the values of aggregations, in that its routing tables are kept smaller, even when receiving a full Internet routing table from its upstream provider. It also enjoys the benefits of global route stability, in that its upstream providers, whether an NLA or a TLA, aggregate according to the princIPles of the IPv6 aggregations model.

Simplified Host Addressing

As we have studied earlier, the IPv6 model defines 128 bits of address space. The first 64 bits are used for network numbering, and the last 64 bits are used for host numbering. We also remember that the last 64 bits of the host ID is obtained from the MAC address of the hosts Network Interface. You may wonder how the 64-bit address is derived from a MAC address, which is classically only 48 bits. In this section we will look into how address is derived, and what developments we may see in the future as a result of the IPv6s addressing scheme.

When assigning a host in IPv4, by convention, IPv4 one will break up the subnet given, and assign host addresses based upon the addresses that are available. Normally, again by convention, the first address is given to the designated router, and the rest of the addresses get assigned to hosts on that subnet, reserving the last address in the subnet for the broadcast addresses for that subnet. In IPv6, the situation changes somewhat. With IPv6, we know that the host ID is a 64-bit address that is obtained from the MAC address. Although the MAC addresses of today are classically 48 bits, we need a way to get the host ID to come out to 64 bits. The answer to this problem is to pad the MAC address with some well-defined set of bits that will be known by routing systems on that subnet. Today, we use the string 0XFF and 0xFE (:FF:FE: in IPv6 terms) to pad the MAC address between the company ID and the vendor supplied ID of the MAC address (MAC addresses are delegated in much the same way as IP addresses today, except companies who make NIC cards are given a piece of MAC space, rather than providers being given IPv4 space). This way, every host will have a 64-bit host ID that is related to their MAC address in the same way. Furthermore, we know that the 64-bit MAC address will be unique on a given network, because every NIC card will have a unique MAC address. By using this well-defined padding, it now becomes possible to learn IPv6 addresses (or at least host IDs) of other machines on the subnet, simply by learning the layer 2 MAC information.

One interesting debate is whether or not MAC addresses will need to become 64 bits in length prior to the widespread deployment of IPv6. If there is a need for MAC addresses to become longer (if all MAC addresses are used) then 64 bits will most likely be the next option for length, as this will supply over 1.8E019 more MAC addresses to use (2 64 2 48 ). Moreover, if this becomes the case, we may simply stop the padding of the MAC address, and use the full 64 bits of the MAC address for the Host ID.

Now that we see where the Host ID comes from, let us now look into one of an administrators favorite things about IPv6. Not only is Host ID already determined prior to configuring an IPv6 speaking machine, but the network on which it resides can be deduced as well.

Simpler Autoconfiguration of Addresses

Not that we understand where the Host ID comes from, let us look at one of the newest inventions of IPv6, the ability for autoconfiguration to take place. Before we go into detail about autoconfiguration, a new type of address will have to be brought into our repertoire , the multicast address.

A multicast address can be assigned to more than one machine simultaneously . It differs from an anycast address: anycast packets are routed to the destination (one of the set of machines with the same address) that is closest, but multicast packets are routed to all machines that are assigned this address. This is fundamentally different than a Globally Routable Unicast address, because more than one host can be numbered with the same address, so the address that a given host is assigned need not necessarily be unique for the given scope on which the multicast address is acting. All machines assigned this multicast address are said to be in a multicast group, whose address is the multicast address they use. Multicast-speaking machines send and receive data from more than one host (every member on that group). This type of addressing and routing classically has been used for 1 to N or M to N type Internet transactions (when one or more people need to get identical information to more than one destination). Multicast provides efficient means by which to do so.

Now that we understand the idea of multicast, if we unite this idea with the idea of Host ID coming from the hardware on a given machine, we can see how autoconfiguration is possible. When a machine first powers up onto a network, and realizes that it is connected, and is supposed to speak IPv6, it will send an multicast packet that is well known and defined by standard, out onto the LAN segment to which it is attached. This packet will be destined towards a locally scoped (see earlier) multicast address, known as the Solicited Node Multicast address. When the router sees this packet come in, it then can reply with the network address from which the machine should be numbered, in the payload of the reply packet. The machine receives the packet, and in turn reads the network number that the router has sent. It then assigns itself an IPv6 address that consists of that network number, appending its Host ID (obtained from its MAC address of the interface that it connected to that subnet) to the network number, and it now has an IPv6 address. Not only does this not involve manual intervention by the administrator to configure this machine (though it may or may not involve manual configuration of the router on that subnet), but it also does not require any worry about the address being nonunique . The machine is guaranteed to have a unique address because the network number is assigned uniquely by the router on that network, and the Host ID is unique because the MAC address of the interface by which that machine is attached is provided by the vendor and unique. Furthermore, it can learn the default route that it needs in order to get off of that subnet, now that it has a routable address. Notice the ease of configuration that we now have when we move from one network to another. Not only do we no longer have to reconfigure an end-station manually (and then reboot in most cases), we also no longer have to take time out of our network administrators busy day for him to delegate an address in order to ensure its uniqueness. Also, the administrator no longer has to keep track of the addresses that he has assigned, and which ones are free at any given time! Certainly, this can be seen to save a network administrator much time, but in paperwork associated with keeping track of addresses used, but in reconfiguration that must occur for a network to be renumbered. Think of the things an administrator could be doing if he isnt constantly being hounded for IP addresses, or network numbers! We will get into the concept of the multicast address, and its possible uses, in more detail in a later section. See Figure 9.10 for a graphical representation of autoconfiguration:

Figure 9.10 LAN discovery mechanism.

Improved Scalability of Multicast Routing

Now that we have studied unicast addressing, looked at the primary merits of multicast addressing, and discovered the potential of routing table size scalability in the Internet with IPv6, let us take a moment to discuss the multicast address in a little more detail. Multicast servers are perhaps the most misunderstood technology of today. IPv6Lets look into the concept of multicasting in general.

In the beginning, the Internet was primarily a research network upon which research data flowed between one university and another. This was not big business, so congestion problems were tolerated, and the data that people were sending was not dated (because data didnt need to be received in real-time). Today, by contrast, businesses and consumers are using the Internet for a vast array of applications. More and more, we are seeing different types of media going over the Internet, whether it is stock quotes, phone calls, or even our favorite TV channel. We see the need for media to not only arrive quickly, but also to be sent to an increased audience. Even things such as newsgroups are getting information out to millions of people each day. This 1 to N transmission trend is bringing about a need for a new type of traffic sending, in which one person can send a piece of data to many people. In the past, if we wanted to send a piece of data to 10 friends , we would simply make 10 copies of that data, and send them to each person one at a time. However, as this type of transmission gains popularity, a scaling problem takes place. For instance, perhaps we have a video or a radio show that we wish to send out over the Internet. If we want to send this media to 10,000 people that all want to see this show in a fashion as close to real-time as possible, we run into a problem. Now in order to do so, we have to make sure that our upstream bandwidth is sufficient to handle up to 10,000 times the data rate of one transmission. We now must spend much more money in order to purchase this upstream bandwidth and satisfy our client base (our viewers or listeners). Fortunately, the concept of multicast was conceived some time ago, and has been in a testing phase for quite some time. The concept of taking one piece of data, and sending it to many interested parties at once, efficiently, becomes quite a complex routing problem, especially if we become caught in the unicast paradigm we are all used to. The concept of multicast addresses this problem.

In a multicast situation, we have a 1 to N (or M to N) relationshIP between the source and the destination. Instead of using a unicast address to designate that we are interested in receiving a given multicast feed, the concept of a multicast address is used. A multicast address, in IPv4, is usually referred to as a group address. This group address, when applied to a machine, or to an application on that machine, signifies that we are interested in listening to any data that is sent to that address. In IPv4, the address range from 224.0.0.0 through 239.255.255.255 is used to designate multicast group addresses. When someone wants to receive multicast feeds, they (temporarily or permanently, depending on the situation) address themselves with that address, and effectively listen for packets coming along that are have that multicast address listed as a destination. The routing for multicast becomes rather complex, and is out of the scope of this book, but you are encouraged to read more about this. Good information can be found either in the Multicast Forum home page at http://www.IPmulticast.com, or in the IETF working groups regarding multicast. Some of the working groups you may wish to check out include the Mbone Deployment Working Group (www.ietf.org/html.charters/mboned-charter.html) or the Inter-Domain Multicast Routing Working Group (www.ietf.org/html.charters/idmr-charter.html). There are also a number of protocol-specific working groups currently active within the IETF, including the Multicast Source Discovery Protocol Working Group (MSDP) and the Protocol Independent Multicast Working Group (PIM). I leave it up to you to learn as much as you wish about the current updates to multicast routing in general. For the purposes of this book, let us assume that multicast works, and will help save us bandwidth, since now we only need to send one stream out of our Internet connection, and the Backbone will reproduce it as seen fit to make sure it gets to all the interested destinations.

IPv6 has in it the concept of a multicast scoping. One of nice uses of multicast can be in a corporate network. Perhaps a memo needs to be sent to all employees workstations at once, or a live videoconference from the CEO needs to be sent over the corporate network to all employees . In a corporate network we want to save as much money as possible on bandwidth, while maintaining an efficient routing structure. Multicast buys us just that. However, in most cases, we only want multicast information (streams) to get to the places that are supposed to see them. We do not want the whole Internet to hear our CEO talk about our newest secret initiative to take over our competition! For this, IPv6 has built in the concept of multicast scoping. With IPv6, we can designate certain multicast streams to be routed only within a certain area, and never to allow packets to get out of that area, for fear of who may see them. This scoping will be well known and understood by all routing entities, in order to ensure, through minimal configuration, that multicast data and multicast routes do not get outside the edges of the routing domain for which they are meant to exist. Figure 9.11 presents multicast addressing format in a little detail.

   |    8     |   4 |   4 |                   112 bits                    |

   +------ -+----+----+---------------------------------------------+

   |11111111|flgs|scop|                   group ID                    |

   +--------+----+----+---------------------------------------------+

Figure 9.11 IPv6 multicast address format.

So as we can see, the multicast addressing architecture is a little different than that of the Globally Routable Unicast addressing format. Notice the first eight bits are all set to 1, which will allow a routing device to know immediately that the packet is multicast in nature, and subject to special handling associated with this packet type. The next four bits are used for flags. Currently, the first three bits in the flgs field are reserved, and undefined, so they should always be set to 0 (though you will find some implementers of protocols will use these bits fallaciously for some sort of proprietary signaling. This is fine, until the bits get standardized to something in the future, at which time incompatibilities arise). The fourth bit is known as the T bit (see RFC 2460), and is used to decide whether the multicast address is a permanently assigned address (also known as well-known ) or a temporary assignment (also known as transient ). So this field will tell us if the multicast address being used is one that is standard (perhaps a group address used to contact all nodes within a given routing domain, for example) or a temporarily assigned address (perhaps the Monday night football game broadcast over the Internet). The next field is the one we are interested in here. The scope field will determine how far the multicast packet can go, in what areas of a routing domain the packet can travel, and the group address that can be advertised. The scope field has the values in Table 9.3.

         0   reserved
         1   node-local scope
         2   link-local scope
         3   (unassigned)
         4   (unassigned)
         5   site-local scope
         6   (unassigned)
         7   (unassigned)
         8   organization-local scope
         9   (unassigned)
         A   (unassigned)
         B   (unassigned)
         C   (unassigned)
         D   (unassigned)
         E   global scope
         F   reserved

Table 9.3 Scope Definitions

So as we can see, depending on how we assign our multicast address, we can control how far the multicast packets will travel, and how far the routing announcements associated with that multicast group will get advertised. For instance, if you would like to advertise a multicast session of your fish tank in your office, and you would like the whole world to see it, you would assign a scope of E (1110 in binary). However, if you want to set up a multicast group so you and your coworkers can have a video conference over the corporate network, you would want to make sure to give the address used a scope of 5 (0101 in binary), or 2 if everyone involved is on the same LAN as you (0010 in binary). See how this makes life a little easier for controlling how far information gets propagated. Now, instead of relying on a Network Administrator to apply filters at the borders of each routing domain, we can rely on software (which generally is not susceptible to the same sort of random changes that networks are) to keep our traffic inside of the scope we want. This allows for privacy at a much easier level to implement. This is another benefit of IPv6. Not only are multicast boundaries well defined, they are also easy to maintain.

The Anycast Address

IPv6 defines a new type of address, known as the anycast address. Although this form of address is deployed in a limited fashion in IPv4, IPv6 integrates this address type into its operations, which improves routing efficiency. In this section we will look into some of the characteristics of the anycast address in detail, and discuss some of the interesting applications of the anycast address in the IPv6 Internet of the future.

An anycast address is an IPv6 address, which is assigned to a group of one or more hosts, which serve a common purpose or function. When packets are sent to the IPv6 anycast address, routing will dictate which member of the group receives the packet, via the closest machine to the source, as decided by the IGP (Interior Gateway Protocol: the routing protocol you use in your routing domain; e.g., RIP, EIGRP, IS-IS) of the network in question. In this way, it becomes possible to disperse functionality geographically across your network in a way that helps efficiency in two ways. This differs fundamentally with the multicast address. Although both the anycast and the multicast address are assigned to more than one host, the anycast address serves for data transmissions that are 1 to 1, whereas multicast addressing is used when a data transmission to multIPle destinations is required. Let us look at the two main benefits of the anycast addressing scheme.

First, if you are going to the closest machine in a group, and it is irrelevant which group member you exchange information with in the anycast group, you are usually saving time by communicating with the closest (IGP-wise) group member. Second, when you are going to the closest anycast group member, you are saving bandwidth, because the amount of distance a packet has to travel is in most cases minimized by this approach. So not only do you save time with anycast, but you also save money (bandwidth IS money these days) with this approach.

The anycast address does not have its own set of bits to define it, however; instead, anycast addressing is derived from either scoped or Globally Routable Unicast addresses. From the point of an IPv6-speaking machine, the anycast address is no different than a unicast address. The only difference is that there may be other machines that are also numbered with the same scope of unicast address, within the same region for which that scope is defined (for instance, you may have more than one machine with a Site Local anycast address within a given site).

Now that we understand the differences between anycast and multicast addresses, let us look into some possible uses of the anycast address. One nice application that anycast can help with is DNS (Domain Name Service). If we were to offer DNS to many people or customers, as in the case of most Tier-1 Service Providers today, we would need to build our DNS in a way that can handle a large number of queries, from all parties for which we provide this service. Because of this, many times it is more efficient to deploy multIPle DNS servers, and spread them out geographically. This will allow for fail-over, if one DNS server becomes unreachable due to network failures, and will also allow us to spread the load of our DNS service between these servers. However, we do not want to make our customers assign too many different IP addresses of DNS servers to point to for resolution, as most people only use one or two. Also, we want some way for one or two IP addresses to be used for all of our service geographically, for the fail-over reason just stated. One way to do this would be to assign each DNS server that has identical configuration and authoritative information the SAME IP address. If we then inject routes to each of these DNS servers into our Backbone routing table, when someone wants to query our DNS, the request will be sent to the geographically closest DNS server. This will allow us not only to split up the load between multIPle DNS servers, but also will avoid backhauling DNS queries across our Backbone too much. So by this method of deployment, we are saving both time for our customers (DNS servers are close, so they the data transmission takes less time), and money for ourselves (bandwidth = money for Service Providers). Because DNS is UDP based, rather than TCP based, transactions between DNS servers and end- stations are quick, short, and not kept track of with sequencing, error checking, etc. When we want to resolve a host name, a packet is sent to the DNS server requesting the address associated with a given Internet Domain Name, and a response is sent back with the answer. This makes the anycast-addressing model viable for this type of application. For more information on this specific type of deployment, you can read draft-catalone-rockell-hadns.00.txt.

For IT Professionals

Which Applications Are Good Candidates for Anycast?

Some applications may not be well suited for anycast deployment. For instance, TCP-based applications using anycast addressing for deployment will not provide the fail-over capabilities that the previous example provides. When we are using a UDP-based application, there is no sequencing information to keep track of. With TCP, we run into a problem: when a network problem occurs and users are in the middle of a TCP session with an anycast machine, , the TCP sequencing will be all wrong when the traffic gets rerouted to the next-closest anycast server. In the case of Web traffic, which is largely TCP-based, the user would need to reload the Web page at least, to get to where he or she was when the failure occurred on the network. Other applications could have even more painful consequences associated with rerouting, so careful consideration should be given to which types of service are supplied using an anycast model.

The Need for Further Development

Although IPv6 does in fact present many new and useful ideas aimed at increased efficiency and ease of routing and configuration, the work that is needed prior to IPv6 deployment natively on the Internet is not done. In this section, we will look at one current issue that is gaining increased attention by the IETF working group IPNGWG (Internet Protocol, Next-Generation Working Group; please see http://www.ietf.org/html.charters/IPngwg-charter.html for more the working groups charter and the current status on their goals and how close they are to reaching them).

The Multihoming Problem

Now that we have basic familiarity with how IPv6 addressing and routing works, let us look at one of the potential problems associated with IPv6 routing. We know from earlier in this chapter that Tier 1 Service Providers will be given large chunks of address space, from which they will delegate smaller bits of that space to their customers, to number their own networks. We also know that fundamental to IPv6 is the concept of firm route aggregation, by which that Tier 1 Service Provider will need to announce the aggregate of their space only to other Tier 1 peers. This will keep the routing table size small, compared to what it could be without aggregation, and route stability maximized, as changes in small areas of ones network need not withdraw routes globally. This causes route dampening to affect reachability once a network failure occurs and is corrected. However, what do we do when a smaller network, such as an ISP or a business, is buying Internet connectivity through multIPle providers? Classically, in IPv4, the way to do this is to run BGP from that ISP or business to its upstreams, announcing the IP space that you obtained from one of your providers to both of your upstream providers. These announcements in turn will need to be announced everywhere, in order for the Network Administrators of this small ISP or business to retain the ability to load-share over both of these Internet connections inbound. So the subnet that is delegated now has to be accepted into the global route table. With IPv6, this violates fundamental princIPles regarding aggregation. If we look at the IPv4 scenario listed earlier in the chapter, and substitute IPv6 addresses, we are left with the identical problems. Not only will the Service Provider (the one that delegates the customer the address block) need to allow the smaller block announced from his customer, and heard through his peer (the one through which the customer also buys connectivity), but he will have to export the more specific route to all of his peers as well, so they automatically do not choose the other provider (from whom the address block was not delegated) as the more specific route advertisement, and therefore the best path to the customer. Both the IPNGWG and the NGTRANSWG (Next-Generation TRANSition Working Group) are looking into this problem. At the time of this writing, there are a couple of proposed solutions to this problem, but each of them presents other interesting dilemmas as well.

The first proposed solution to this problem is now written as an RFC (RFC2260). This approach, summed up, is to follow the aggregation princIPles as outlined previously in the chapter, until such time as a network failure occurs. When everything is working, the border router to upstream 1 sends only the prefix that was delegated by upstream 1 to upstream 1, and conversely, the border router that connects to upstream 2 announces only the prefix that upstream 2 has delegated, up to upstream 2. When a failure occurs, however, the border router that does not have a failure will announce both prefixes up to the upstream that is still working. When the connectivity failure is fixed, the illegal prefix is withdrawn, and the situation returns to normal. Although this proposal has merits, since it allows for fail-over for a downstream that is multihomed and assigns addresses in its network from both providers, it does present some management problems for the upstream provider. If the upstream provider has an efficient routing policy towards its downstream customers, this usually includes a filter on the BGP session to that downstream that allows only routes that the upstream expects to hear from its downstream customer. Now the upstream would have to allow both the route it has delegated, and the route that the other upstream provider has delegated to its customer. Furthermore, the upstream provider who receives both prefixes has no way of knowing when or even if a network failure has occurred between its downstream customer, and the other provider. Also, the upstream provider has no way of determining when the downstream customers other provider connection has been fixed, and the route should be withdrawn. The only way to know would be to rely on the downstream customer to have their configuration done correctly to avoid announcing both routes when everything works, and to have a software implementation that has the capability of automatically withdrawing the illegal route when the problem is fixed. A downstream customer in this case could easily misconfigure their outbound policy to announce both routes illegally, even when there is no failure. So in summation, although this proposal does have merits, the implementation specifics are not nearly as controllable as an upstream provider would like.

The second proposal, which is currently in use in the 6Bone IPv6 test network, is to assign each multihomed host an address for each upstream connection, and therefore IPv6 delegation, that the downstream customer has. For instance, if you are delegated two prefixes, one from Provider A, and one from Provider B, then each machine that wishes to use the benefits of multihoming would need to be assigned a prefix from each of the delegations received from Provider A and Provider B (let us call these delegations Prefix A and Prefix B). So each host now has two Globally Routable Unicast addresses, one from Prefix A and one from Prefix B. Then, each border router that speaks with the upstream providers can announce only the prefix delegated from that provider, and the routing is stable. In theory, if there is a network failure, and one provider becomes unreachable, then machines that were using the address associated with that provider can switch over to the address associated with the other provider, and connectivity is established. However, this solution comes with its own host of problems. First, this approach is not that optimal when it comes to efficient delegation of IPv6 address space. Now each network with N upstream providers will have N addresses assigned to them. Furthermore, and perhaps more important, is that currently, TCP does not allow for address changing in the middle of a TCP session. The only solution to this is to adjust TCP to allow for this, which in itself seems easy, but the ramifications are far more than meet the eye. Most TCP applications are built in such a way that modifications of TCP would require modifications of the application. This could mean drastic reworking of current network software. Also, current operating systems themselves may need overhauling in order to switch source addresses dynamically when a network becomes unreachable. How does a source know that a network failure has occurred in the right place? What if the destination had a problem? How would the source know if switching IPv6 source addresses would fix the problem? All of these factors lead us to believe that this is not a viable long-term solution either.

So as you can see, multihoming with IPv6 still has some work. It is currently of top priority in the IETF working group IPNGWG. Hopefully, their work will produce a solution that is both scalable, and able to accommodate the problems associated with either of the previous proposals. Stay tuned to this one!

The 6Bone

Now that we have the basis for understanding elementary IPv6 addressing and routing, let us look into current IPv6 deployment, and the successes and shortcomings of them. The primary example of IPv6 deployment is the IETF Next-Generation Transition Working Group (NGTRANSWG) 6Bone. The 6Bone is a network of IPv6-speaking entities interconnected over the classical IPv4 Internet. It consists of both native networks (where IPv6 is running without being tunneled through another layer 3 protocol) and IPv4 tunnels between different IPv6 speaking entities. The purpose of this network is twofold. The first reason for the 6Bone is to provide implementers a means to test their IPv6 implementations in a large network where other vendors have deployed their own version of IPv6 implementations. By allowing this, we can ensure that IPv6 implementations are interoperable. This way, protocol developers can make sure that the protocol specifications are specific enough to allow for implementers to develop IPv6-speaking machines without ambiguity. The second reason for the 6Bone is to give networks operators a chance to design networks and get their feet wet with the new protocol. Also, it allows operators to uncover any problems with the IPv6 protocol (such as the previous multihoming problems) that may have been missed or underappreciated during the protocol's conception . Although the fathers of the IPv6 protocol were extremely meticulous in the protocols design, it never hurts to get the new technology running on a live network somewhere prior to implementation on a grand scale. The 6Bone helps to work all of the details out, and test new features, prior to deployment, in a cooperative, multinational fashion. It follows all routing practices as defined by the IETF. For the most current IPv6 routing practices on the 6Bone, see www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-02.txt. (Note: This is an Internet draft. At the time of this writing it is in the last-call stage for RFC.) For more information on the 6Bone, please see http://www.6bone.net.

Summary

We can see that IPv6 provides for many of the much-needed improvements in the Internet that we will need shortly. Not only does it solve the address depletion problems of todays IPv4, but it also makes for a more scalable Internet core, which can help improve routing efficiency of the Internet as a whole. By allowing for 128 bits of addresses, we can see that there is adequate address space for the future. By then aggregating this address space in an efficient manner, we may establish a firm upper limit on routing table size in the Internet core. This, in turn, can help us to build an Internet to take us into the future.

Although the two primary problems of the Internet can be solved with IPv6, the protocol improvements do not stop there. Also built into the IPv6 protocol are means for hop-by-hop routing, authentication of packets, encrypted packets, tag switching, Quality of Service, and other things to make the protocol more versatile than its grandfather, IPv4. Furthermore, IPv6 has built into it the ability to use multicast and unicast routing in a manner such that boundaries easily can be scoped to ensure that data does not get to places where it is not allowed. IPv6 also introduces the use of an anycast address, for applications that may be serviced by multIPle machines, but the need for distribution of these services in a scalable manner is required.

We can also see that IPv6 is already in testing, and is starting into production in some areas, connected via the 6Bone. This virtual backbone will provide for testing of both IPv6 implementations and the protocol itself. Clearly, we can see that IPv6 is getting more and more attention, and is looking like a promising aspect for the future of the Internet.

FAQ

Q: How can I get onto the 6Bone?

A: The 6Bone has a mailing list where operational issues associated with it, as well as new proposals for transition strategies, are discussed and collaborated upon. This list can be joined by sending e-mail to majordomo@isi.edu, with subscribe 6bone as the contents of the message. It is encouraged that all mailing list members of the 6Bone actually become IPv6 speakers on the 6Bone as well. Refer to the Web page www.6bone.net for information on how to get connected, and to find the nearest upstream provider to obtain a tunnel.

Q: Where do I get an IPv6 address?

A: IPv6 addresses are delegated out by the Providers who have them. When you join the 6Bone or any other IPv6 network, your upstream Provider is responsible for providing you with adequate IPv6 address space to take care of your needs.

Q: Where do I get the IPv6 protocol specifications for more details?

A: All protocol specifications are in the form of IETF RFCs (Requests for Comments). These can be found at www.ietf.org; there is a search engine where you can pull up all current IPv6 RFC and Internet drafts.




IP Addressing and Subnetting, Including IPv6
IP Addressing and Subnetting, Including IPv6
ISBN: 672328704
EAN: N/A
Year: 1999
Pages: 15

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net