NIST SP 800-119 日本語訳

Special Publication 800-119

NIST Special Publication 800-119

NIST Special Publication 800-119

原本PDFの抜粋画像

Recommendations of the National Institute of Standards and Technology

Sheila Frankel

Richard Graveman

John Pearce

Mark Rooks

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

December 2010

U.S. Department of Commerce

Gary Locke, Secretary

National Institute of Standards and Technology

Dr. Patrick D. Gallagher, Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Techn ology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

The authors, Sheila Frankel of the National Institute of Standards and Technology (NIST), Richard Graveman of RFG Security, John Pearce of Booz Allen Hamilton and Mark Rooks of L-1 Identity Solutions (formerly of Booz Allen Hamilton) wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content.

The authors would like to acknowledge Tim Grance of NIST for his keen and insightful assistance and encouragement throughout the development of the document. The authors particularly want to thank Mark Carson, Doug Montgomery and Stephen Nightingale of NIST and Scott Hogg for their careful review and valuable contributions to improving the quality of this publication.

The authors also appreciate the efforts of those individuals, agencies, and other organizations that contributed input during the public comment period, including John Baird, DREN; Alistair de B Clarkson, nCipher; Vint Cerf, Google; John Curran, ARIN; Terry Davis, Boeing; Francois Donze and Michael Scott Pontillo, HP; Jeffrey Dunn, Chern Liou, and Jeffrey Finke, Mitre; Fernando Gont, the UK Centre for the Protection of National Infrastructure (UK CPNI); Bob Grillo, US Army; Cecilia Hall, Don Radeke and Joseph Bertrand, USMC; J. Holland, David Leach, Sam Nguyen, M. Roed, Beth Scruggs, D. Wellington and Joe Williams, Aerospace Corp.; Ed Jankiewicz, SRI International; Ralph Kenyon, Caida; Lovell King II, Dept. of State; Joe Klein, IPv6 Security Researcher; Dan Luu, VA; Trung Nguyen, FAA; Carroll Perkins, Serco-NA; and Martin Radford, University of Bristol.

Due to the exhaustion of IPv4 (Internet Protocol version 4) address space, and the Office of Management and Budget (OMB)¹ mandate that U.S. federal agencies begin to use the IPv6 (Internet Protocol version 6) protocol, NIST undertook the development of a guide to help educate federal agencies about the possible security risks during their initial IPv6 deployment. This document provides guidelines for organizations to aid in securely deploying IPv6. Since the majority of organizations will most likely run both IPv6 and IPv4 on their networks for the foreseeable future, this document speaks about the deployment of IPv6 rather than the transition to IPv6.2

The deployment of IPv6 can lead to new challenges and types of threats facing an organization. The goals of this document are:

The migration to IPv6 services is inevitable as the IPv4 address space is almost exhausted. IPv6 is not backwards compatible with IPv4, which means organizations will have to change their network infrastructure and systems to deploy IPv6. Organizations should begin now to understand the risks of deploying IPv6, as well as strategies to mitigate such risks. Detailed planning will enable an organization to navigate the process smoothly and securely.

Federal agencies will most likely face security challenges throughout the deployment process, including:

Organizations planning the deployment of IPv6 should consider the following during the planning process:

To overcome possible obstacles associated with deploying IPv6, organizations should consider the following recommendations:

Organizations that are not yet deploying IPv6 globally should implement the following recommendations:

Organizations that are deploying IPv6 should implement the following recommendations to mitigate IPv6 threats:

After reviewing this document, the reader should have a reasonable understanding of IPv6 and how it compares to IPv4, as well as security impacts of IPv6 features and capabilities, and increased knowledge and awareness about the range of IPv4 to IPv6 transition mechanisms.

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

The purpose of Guidelines for the Secure Deployment of IPv6 is to provide information security guidance to organizations that are planning to deploy IPv6 technologies or are simply seeking a better understanding of IPv6. The scope of this document encompasses the IPv6 protocol and related protocol specifications. IPv6-related security considerations are discussed with emphasis on deployment-related security concerns. The document also includes general guidance on secure IPv6 deployment and integration planning.

This document is intended primarily for network engineers and administrators who are responsible for planning, building, and operating IP networks, as well as security engineers and administrators who are responsible for providing Information Assurance support. Anyone interested in deploying IPv6 technologies and related security implications may also find the document useful. It includes a discussion of the major features and protocols that constitute IPv6. For each of these, the description is comprised of an introductory section, a more in-depth description, and three analytical sections: differences between the IPv4 and the IPv6 versions, security ramifications and unknown aspects. Managers or users who are trying to understand IPv6 might want to skip the in-depth descriptions but read the other sections (Introduction, Differences, Security Ramifications and Unknown Aspects). They should also read Section 1 (Introduction) and Sections 6.8-6.9 (IPv6 Deployment). It is assumed that readers are already familiar with basic IPv4, data networking, and network security concepts.

The remainder of this document is composed of the following sections and appendices:

Appendix A provides a list of acronyms and abbreviations used in this document.

Appendix B lists references and other resources related to IPv6.

Internet Protocol version 6 (IPv6) is a new network layer protocol. It is an enhancement to Internet Protocol version 4 (IPv4), the protocol in use since the 1980s. There are numerous upgrades in IPv6. Most significantly, in comparison with IPv4, IPv6 has increased its network address size from 32 bits to 128. This provides more than enough addresses to satisfy the global demand for unique IP addresses.

This chapter provides an overview of IPv6 as a foundation for later sections. The section starts with the early history of IPv6 and the limitations of IPv4, followed by descriptions of the major features of the IPv6 specifications. This is followed by a threat comparison between IPv4 and IPv6 and concludes with motivations for deploying to IPv6.

IPv4 was developed in the 1970s and early 1980s for use in government and academic communities in the United States to facilitate communication and information sharing. Today’s networking demand, in particular web pages, email, peer-to-peer services, and the use of mobile devices, has grown well beyond its originators’ expectations. Widespread deployment and growth of networking technologies and mobile communications have surpassed IPv4’s ability to provide adequate globally unique address space⁴.

Efforts to develop a successor to IPv4 started in the early 1990s within the Internet Engineering Task Force (IETF)⁵. The objective was to solve the address space limitations as well as provide additional functionality. The IETF started the Internet Protocol Next Generation (IPng) work in 1993 to investigate different proposals and to make recommendations for further actions. The IETF recommended IPv6 in 1994. (The name IPv5 had previously been allocated to an experimental stream protocol.) Their recommendation is specified in RFC 1752, The Recommendation for IP Next Generation Protocol. Several proposals followed; the Internet Engineering Steering Group approved the IPv6 recommendation and drafted a Proposed Standard on November 17, 1994. RFC 1883, Internet Protocol, Version 6 (IPv6) Specification, was published in 1995. The core set of IPv6⁶ protocols became an IETF Draft Standard on August 10, 1998. This included RFC 2460, which replaced RFC 1883.

IPv6 is a protocol designed to handle the growth rate of the Internet and to cope with the demanding requirements of services, mobility, and end-to-end security. The following sections describe the limitations of IPv4, the major features of IPv6, and motivations for deploying IPv6.

IPv4 (RFC 791) was designed over 30 years ago for a relatively small number of users. At that time, it seemed unlikely that personal computing technology would become as widespread as it is today in the United States and worldwide. The rapid, universal adoption and growth of personal computing technologies, including IP networking, were unforeseen in 1981. At that time, the Internet was used almost exclusively by scholars and researchers, and IPv4’s 4.3 billion theoretically available addresses were considered to be more than sufficient.

As a result of growing Internet use, IPv4’s address capacity could not meet the demand. In practice, the supply of available IPv4 addresses has been limited since the early 1990s. Previously, an organization could apply for and receive an order of magnitude more IPv4 addresses than it could actually justify. However, as a result of regulatory advances, IP address allocations are now bound by strict policies that include formal justification to a Regional Internet Registry (RIR). During the 1990s, address allocation policies, along with address reuse and restriction technologies, were put into place to conserve IPv4 addresses.

Technologies widely adopted in response to the constrained supply of IPv4 addresses are network address translation (NAT [RFC 3022]) and classless inter-domain routing (CIDR [RFC 4632]); both are discussed in detail in Chapter 3. NAT essentially makes private IPv4 addresses (also known as non-routable addresses) at least partially functional on the global Internet. Despite their adaptation to other uses, private IPv4 addresses were designed for testing and other non-production purposes and never intended to be usable on the Internet. Nevertheless, a NAT-capable router positioned at an organization’s boundary has the ability to connect an entire network of privately addressed nodes within the organization to the Internet via a single routable IP address.

This technology saves IPv4 address space because nodes bearing private addresses are essentially “on” the Internet but do not have globally unique IP addresses. Nevertheless, this address conservation technology can actually defeat certain aspects of the design intent of IPv4: network layer end-to-end security, peer-to-peer (host-to-host connectivity), and interoperability. A host using private addressing behind a NAT device cannot have a full peer-to-peer relationship with another host via the Internet or backbone enterprise network using globally unique addressing. This is because NAT does not allow communication sessions to be initiated from globally addressed nodes to the privately addressed nodes.

NAT traversal technologies are available to work around some of these barriers. They typically work in one of two ways: (1) by maintaining stateful address lookup tables and redirecting inbound traffic to appropriate private addresses; (2) by employing application layer gateways that listen for specific port numbers and redirect traffic according to pre-configured parameters. Neither of these approaches to NAT traversal lends itself to scalability or guarantees compatibility with all forms of NAT, not to mention the efforts put into each of these work-arounds. In addition, neither approach lends itself to dynamic configuration when, for example, hosts move or networks are renumbered.

Another limitation of IPv4 is that its design favored interoperability over security and did not contain features that protected the confidentiality, integrity, or availability of communications. For example, IPv4 could not cryptographically protect data from eavesdropping or manipulation, and IPv4 did not provide a method for endpoints to authenticate each other. Over time, the open nature of IPv4 was increasingly a target of exploitation. The multi-path nature of the Internet, which was designed for high availability, also allows multiple attack vectors for a variety of threats. As a response, new technologies were added to IPv4 to provide needed security functionality. With IPv6, these features were designed into the new protocol as mandatory components.

IPv6 has many new or improved features that make it significantly different from its predecessor. These features include extended address space, autoconfiguration, header structure, extension headers, IPsec, mobility, quality of service, route aggregation, and efficient transmission. This section discusses these features and compares specific aspects of IPv4 and IPv6 to help establish an understanding of the protocols’ similarities and differences.

Each IPv4 address is typically 32 bits long and is written as four decimal numbers representing 8-bit octets and separated by decimal points or periods. An example address is 172.30.128.97. Each IPv6 address is 128 bits long (as defined in RFC 4291) and is written as eight 16-bit fields in colon-delimited hexadecimal notation (an example is fe80:43e3:9095:02e5:0216:cbff:feb2:7474). This new 128-bit address space provides an enormous number of unique addresses, \(2^{128}\) (or \(3.4 \times 10^{38}\)) addresses, compared with IPv4’s \(2^{32}\) (or \(4.3 \times 10^{9}\)) addresses. That is enough for many trillions of addresses to be assigned to every human being on the planet. Moreover, these address bits are divided between the network prefix and the host identifier portions of the address. The network prefix designates the network upon which the host bearing the address resides. The host identifier identifies the node or interface within the network upon which it resides. The network prefix may change while the host identifier can remain static. The static host identifier allows a device to maintain a consistent identity despite its location in a network. This enormous number of addresses allows for end-to-end communication between devices with globally unique IP addresses and can better support the delivery of peer-to-peer services with data-rich content such as voice and video. Chapter 3 describes IPv6 addressing in detail.

Essentially plug-and-play networking, autoconfiguration, defined in RFC 4862, IPv6 Stateless Address Autoconfiguration, is one of the most interesting and potentially valuable addressing features in IPv6. This feature allows devices on an IPv6 network to configure themselves independently using a stateless protocol. In IPv4, hosts are configured manually or with host configuration protocols like Dynamic Host Configuration Protocol (DHCP); with IPv6, autoconfiguration takes this a step further by defining a method for some devices to configure their IP addresses and other parameters without the need for a server. Moreover, it also defines a method, renumbering, whereby the time and effort required to renumber a network by replacing an old prefix with a new prefix are vastly reduced. Section 3.5.4 describes autoconfiguration in detail.

The IPv6 header is much simpler than the IPv4 header and has a fixed length of 40 bytes (as defined in RFC 2460).

Even though this header is almost twice as long as the minimum IPv4 header, much of the header is taken up by two 16-byte IPv6 addresses, leaving only 8 bytes for other header information. This allows for improved fast processing of packets and protocol flexibility. IPv6 datagrams use a structure that always includes a 40-byte base header and, optionally, one or more extension headers. This base header is like the header of IPv4 datagrams, though it has a different format. Five IPv4 header fields have been removed: IP header length, identification, flags, fragment offset, and header checksum. The IPv6 header fields are as follows: version (IP version 6), traffic class (replacing IPv4’s type of service field), flow label (a new field for Quality of Service (QoS) management), payload length (length of data following the fixed part of the IPv6 header), next header (replacing IPv4’s protocol field), hop limit (number of hops, replacing IPv4’s time to live field), and source and destination addresses. The IPv6 header format is illustrated in Figure 2-1. The payload can be up to 64KB in size in standard mode, or larger with a jumbo payload option. Section 3.3 describes these headers in detail.

Figure 2-1. The IPv6 Packet Header Format (Field Sizes in Bits)⁷

An IPv4 header can be extended from 20 bytes to a maximum of 60 bytes, but this option is rarely used because it impedes performance and is often administratively prohibited for security reasons. IPv6 has a new method to handle options, which allows substantially improved processing and avoids some of the security problems that IPv4 options generated. IPv6 RFC 2460 defines six extension headers: hop-by-hop option header, routing header, fragment header, destination options header, authentication header (AH), and encapsulating security payload (ESP) header. Each extension header is identified by the Next Header field in the preceding header. Section 3.4 describes extension headers in detail.

IP security (IPsec) is a suite of protocols for securing Internet Protocol (IP) communications by authenticating the sender and providing integrity protection plus optionally confidentiality for the transmitted data. This is accomplished through the use of two extension headers: the Encapsulating Security Payload (ESP) and the Authentication Header (AH). The negotiation and management of IPsec security protections and the associated secret keys is handled by the Internet Key Exchange (IKE) protocol. IPsec is a mandatory part of an IPv6 implementation; however, its use is not required. IPsec is also specified for securing particular IPv6 protocols (e.g., Mobile IPv6 and OSPFv3 [Open Shortest Path First version 3]). Section 5.3 describes IPsec in detail.

Mobile IPv6 (MIPv6) is an enhanced protocol supporting roaming for a mobile node, so that it can move from one network to another without losing IP-layer connectivity (as defined in RFC 3775). RFC 3344, IP Mobility Support for IPv4, describes Mobile IP concepts and specifications for IPv4. Nevertheless, using Mobile IP with IPv4 has various limitations, such as limited address space, dependence on address resolution protocol (ARP), and challenges with handover when a device moves from one access point to another. Mobile IPv6 uses IPv6’s vast address space and Neighbor Discovery (RFC 4861) to solve the handover problem at the network layer and maintain connections to applications and services if a device changes its temporary IP address. Mobile IPv6 also introduces new security concerns such as route optimization (RFC 4449) where data flow between the home agent and mobile node will need to be appropriately secured.

Section 4.4 describes Mobile IPv6 in detail.

IP (for the most part) treats all packets alike, as they are forwarded with best effort treatment and no guarantee for delivery through the network. TCP (Transmission Control Protocol) adds delivery confirmations but has no options to control parameters such as delay or bandwidth allocation. QoS offers enhanced policy-based networking options to prioritize the delivery of information. Existing IPv4 and IPv6 implementations use similar QoS capabilities, such as Differentiated Services and Integrated Services, to identify and prioritize IP-based communications during periods of network congestion. Within the IPv6 header two fields can be used for QoS, the Traffic Class and Flow Label fields. The new Flow Label field and enlarged Traffic Class field in the main IPv6 header allow more efficient and finer grained differentiation of various types of traffic. The new Flow Label field can contain a label identifying or prioritizing a certain packet flow such as voice over IP (VoIP) or videoconferencing, both of which are sensitive to timely delivery. IPv6 QoS is still a work in progress and security should be given increased consideration in this stage of development. Section 4.3 describes QoS in detail.

IPv6 incorporates a hierarchal addressing structure and has a simplified header allowing for improved routing of information from a source to a destination. The large amount of address space allows organizations with large numbers of connections to obtain blocks of contiguous address space. Contiguous address space allows organizations to aggregate addresses under one prefix for identification on the Internet. This structured approach to addressing reduces the amount of information Internet routers must maintain and store and promotes faster routing of data77. Additionally, it is envisioned that IPv6 addresses will primarily be allocated only from Internet Service Providers (ISPs) to customers. This will allow for ISPs to summarize route advertisements to minimize the size of the IPv6 Internet routing tables. This is covered in more detail in Section 3.2.

IPv6 packet fragmentation control occurs at the IPv6 source host, not at an intermediate IPv6 router. With IPv4, a router can fragment a packet when the Maximum Transmission Unit (MTU) of the next link is smaller than the packet it has to send. The router does this by slicing a packet to fit into the smaller MTU and sends it out as a set of fragments. The destination host collects the fragments and reassembles them. All fragments must arrive for the higher level protocol to get the packet. Therefore, when one fragment is missing or an error occurs, the entire transmission has to be redone. In IPv6, a host uses a procedure called Path Maximum Transmission Unit (PMTU) Discovery to learn the path MTU size and eliminate the need for routers to perform fragmentation. The IPv6 Fragment Extension Header is used when an IPv6 host wants to fragment a packet, so fragmentation occurs at the source host, not the router, which allows efficient transmission. PMTU is discussed in Section 3.5.5, and Section 4.5 describes efficient transmission in detail.

The deployment of IPv6 can lead to new challenges with respect to the types of threats facing an organization. This section provides a high-level overview as to how threats differ from an IPv4 environment to an IPv6 environment and combined IPv4-IPv6 environment. The following chapters provide additional details to these threats as required. It should be noted that many IPv6 threat discussions rely on IPsec to provide protection against attack. Due to issues with key management and overall configuration complexity (including applications), it is possible that IPsec will not be deployed much more than it is with IPv4 today for initial IPv6 use. IPsec is covered in detail in Section 5.3.

Network reconnaissance is typically the first step taken by an attacker to identify assets for exploitation (RFC 5157).⁸ Reconnaissance attacks in an IPv6 environment differ dramatically from current IPv4 environments. Due to the size of IPv6 subnets (264 in a typical IPv6 environment compared to 28 in a typical IPv4 environment), traditional IPv4 scanning techniques that would normally take seconds could take years on a properly designed IPv6 network. This does not mean that reconnaissance attacks will go away in an IPv6 environment; it is more likely that the tactics used for network reconnaissance will be modified. Attackers will still be able to use passive techniques, such as Domain Name System (DNS) name server resolution, to identify victim networks for more targeted exploitation. Additionally, if an attacker is able to obtain access to one system on an IPv6 subnet, the attacker will be able to leverage IPv6 neighbor discovery to identify hosts on the local subnet for exploitation. Neighbor discovery-based attacks will also replace counterparts on IPv4 such as ARP spoofing.

Prevention of unauthorized access to IPv6 networks will likely be more difficult in the early years of IPv6 deployments. IPv6 adds more components to be filtered than IPv4, such as extension headers, multicast addressing, and increased use of ICMP. These extended capabilities of IPv6, as well as the possibility of an IPv6 host having a number of global IPv6 addresses, potentially provides an environment that will make network-level access easier for attackers due to improper deployment of IPv6 access controls. Moreover, security related tools and accepted best practices have been slow to accommodate IPv6. Either these items do not exist or have not been stress tested in an IPv6 environment. Nevertheless, global aggregation of IPv6 addresses by ISPs should allow enhanced anti-spoofing filtering across the Internet where implemented.

Attacks that focus on exploitation above the IP layer, such as application-based attacks and viruses, will not see a difference in the types of threats faced in an IPv6 environment. Most likely, some worms will use modified IPv6 reconnaissance techniques for exploitation. Additionally, because many IPv4 broadcast capabilities have been replaced with IPv6 multicast functionality, broadcast amplification attacks will no longer exist in an IPv6 environment.

From this comparison of IPv4 and IPv6 threats, one can surmise that IPv6 will not inherently be either more or less secure than IPv4. While organizations are in the process of deploying IPv6, the lack of robust IPv6 security controls (described in Section 6) and a lack of overall understanding of IPv6 by security staff may allow attackers to exploit IPv6 assets or leverage IPv6 access to further exploit IPv4 assets. There is a very likely possibility that many IPv6 services will rely on tunneling IPv6 traffic in IPv4 for infrastructures that do support the protocol, which will also increase the complexity for security staff. Additionally, since IPv6 systems and capabilities are not yet widely used in production environments, there is a distinct possibility that the number of vulnerabilities in software from implementing IPv6 capabilities could rise, as IPv6 networks are increasingly deployed.

Based on of the threat comparison between IPv4 and IPv6, the following actions are recommended to mitigate IPv6 threats during the deployment process:

IP technologies were invented in the United States, and the early adoption of those technologies occurred predominantly in the United States. As mentioned in Section 2.2, early address allocation policies were relatively relaxed and large quantities of IPv4 addresses were assigned upon request, even when those allocations were not thoroughly justified. This resulted in a high concentration of IPv4 address allocations in the United States, with more than half of all routable IPv4 addresses assigned to U.S.-based organizations. Some large U.S.-based Internet backbone service providers have more IPv4 addresses than all of the nations that comprise the Asian region of the world.

These circumstances have left most of the world, especially Asia, with little choice other than to adopt the IPv6 specification if they are to become pervasive participants in IP technologies or the global Internet at large. Nations such as Japan have built IPv6-capable Internet infrastructures to support their growing demand for Internet connectivity. Further, the advanced state of wireless telecommunications in Asia produced an environment where globally unique IP addresses are required to enable the features of Third Generation (3G) wireless technologies. In essence, every mobile 3G device becomes a mobile personal computing platform, and each of those devices requires true end-to-end connectivity to realize its full potential.

All organizations making use of IP networking should study and consider IPv6’s feature set when designing and managing their networks. Even with no intent to replace IPv4, the IPv6 security controls discussed later in this document should be planned and deployed to detect unauthorized use of IPv6. Fundamental knowledge of IPv6—what it is, what its attributes are, and how it operates—is critical to any organization.

As the IPv6 protocol becomes increasingly ubiquitous, all enterprise and Internet-connected networks need to be prepared for specific threats and vulnerabilities that the new protocol will bring. For example, an IPv4-only network segment may contain several newly installed hosts that are both IPv4 and IPv6-capable, as well as hosts that have IPv6 enabled by default. This circumstance can come about simply as a result of the normal systems life cycles. Additionally, IPv6 could be enabled on a host by an attacker to circumvent security controls that may not be IPv6-aware; these hosts can then be leveraged to create covert or backdoor channels. Taken further, IPv6 traffic could be encapsulated within IPv4 packets using readily available tools and services and exchanged with malicious hosts via the Internet.

Interoperability of geographically dispersed Internet-connected nodes may become a profit motivation for some organizations to deploy IPv6. For instance, content providers are making more multimedia features available via a diverse set of customer platforms. Mobile phones, handheld personal computers, notebook computers, desktop PCs, and home multimedia and gaming centers are all IPv4-capable today. Delivering multimedia content to those platforms is increasingly viable given the broadband network bandwidths available. Nevertheless, IPv4 clearly cannot address all of these devices without using an address conservation technology like NAT, and NAT by its nature denies true end-to-end IP connectivity. Multimedia service offerings and ultimately the market for those offerings are likely always to be constrained by IPv4, while IPv6 may prove to be an enabling technology.

If an organization is not constrained by IPv4 address availability or the disruption that NAT causes to true end-to-end connectivity between nodes, it should still plan for a world in which IPv6 will eventually be ubiquitous. All major vendors of IT products are shipping IPv6-capable products. Wholesale replacement of computing platforms and network infrastructure as a deployment requirement is less likely now than only five years ago, since many operating systems and networking products contain a native IPv6 protocol stack. Also, tunneling IPv6 over the existing IPv4 Internet is possible today by using free, readily available tunnel clients. An end user may download client software, obtain a routable IPv6 address, and begin tunneling IPv6 over IPv4 networks with few technical or administrative barriers. Many open source IP networking tools are IPv6-capable, as are many consumer-oriented wireless access points. Many consumers of personal computing and home networking equipment are IPv6-capable, even if they do not use the features.

Because of the increasing availability and use of IPv6, as well as many years of coexistence between IPv6 and IPv4, management and technical experts within any organization should understand IPv6 technology—its background, basis, and capabilities, and how they can mitigate risks associated with running dual stack IPv4 and IPv6 networks. In the context of this document, dual stack means that nodes are running both IPv4 and IPv6 protocols concurrently. The remainder of this document examines certain aspects of the IPv6 specification in detail, and discusses threats, vulnerabilities, and the mitigation of risks, in detail.

From the standpoint of header design, IPv6 is both more powerful and more flexible than its IPv4 predecessor. Section 2.3 introduced a number of enhancements and features in IPv6. Most significant is the vast amount of address space, along with support for orderly address assignment and efficient network address aggregation on the Internet. Illustrated in Table 3-1 are some of the major differences between IPv4 and IPv6 followed by basic IPv6 terminology used later in this guide. These differences can have implications for IPv6 security and are discussed throughout this and subsequent sections.

Table 3-1. Differences between IPv4 and IPv69

Basic Terms (RFC 2460, RFC 4862)

The following basic IPv6 definitions are important for any IPv6 discussion.

This section provides general information about IPv6 as a foundation for later sections. The rest of this section is a resource for understanding the similarities and differences between IPv4 and IPv6, with a focus on addressing (RFC 4291). Section 3.1 discusses IPv6 addresses, how the IPv6 address space is used, and IPv6 address types and scope. This is followed by a review of IPv4 addressing and IPv4 Classless Inter-Domain Routing (CIDR) addressing. Then IPv4 and IPv6 addressing are summarized and compared. Section 3.2 covers IPv6 address allocation. IPv6 headers, their formats, and fields are discussed in Section 3.3. Sections 3.4 through 3.7 cover extension headers, ICMPv6, IPv6 routing, and IPv6 Domain Name System (DNS) respectively.

Described in RFC 4291, IPv6 addresses are 128 bits long and are written in what is called colon-delimited hexadecimal notation. An IPv6 address is comprised of eight distinct numbers representing 16 bits each and written in base-16 (hexadecimal or hex) notation. The valid hex digits are 0 through 9 and A through F and together with the colon separator are the only characters that can be used for writing an IPv6 address. A comparison of IPv4 and IPv6 addressing conventions is illustrated in Figure 3-5 and discussed in more detail in Section 3.1.7.

An example of an IPv6 address is:

2001:0db8:9095:02e5:0216:cbff:feb2:7474

Note that the address contains eight distinct four-place hex values, separated by colons. Each of these values represents 16 bits, for a total of 128 bits in the entire address.

IPv6 addresses are divided among the network prefix, the subnet identifier and the host identifier portions of the address. The network prefix is the high-order bits of an IP address, used to identify a specific network and, in some cases, a specific type of address (see Table 3-2). The subnet identifier (ID) identifies a link within a site. The subnet ID is assigned by the local administrator of the site; a single site can have multiple subnet IDs. This is used as a designator for the network upon which the host bearing the address is resident. The host identifier (host ID) of the address is a unique identifier for the node within the network upon which it resides. It is identified with a specific interface of the host. Figure 3-1 depicts the IPv6 address format with the network prefix, subnet identifier and host identifier.

Figure 3-1. IPv6 Address Format

RFC 4291 also describes the notation for prefixes. The network prefix is analogous, but not equivalent, to the subnet mask in IPv4. IPv4 addresses are written in Classless Inter-domain Routing (CIDR) notation, with a subnet mask that contains “1”s in the bit positions that identify the network ID (see Section 3.1.6). There is no subnet mask in IPv6, although the slash notation used to identify the network address bits is similar to IPv4’s subnet mask notation. The IPv6 notation appends the prefix length and is written as a number of bits with a slash, which leads to the following format:

IPv6 address/prefix length

The prefix length specifies how many of the address’s left-most bits comprise the network prefix. An example address with a 32-bit network prefix is:

2001:0db8:9095:02e5:0216:cbff:feb2:7474/32

Quantities of IPv6 addresses are assigned by the international registry services and Internet service providers (ISP) (see Section 3.2.2) based in part upon the size of the entity receiving the addresses. Large, top-tier networks may receive address allocations with a network prefix of 32 bits as long as the need is justified. In this case, the first two groupings of hex values, separated by colons, comprise the network prefix for the assignee of the addresses. The remaining 96 bits are available to the local administrator primarily for reallocation of the subnet ID and the host ID. The subnet ID identifies a link within a site, which can have multiple subnet IDs. The host ID within a network must be unique and identifies an interface on a subnet for the organization, similar to an assigned IPv4 address. Figure 3-2 depicts an IPv6 address with 32 bits allocated to the network prefix.

Figure 3-2. 32-Bit Network Prefix

Government, educational, commercial, and other networks typically receive address allocations from top-tier providers (ISPs) with a network prefix of 48 bits (/48), leaving 80 bits for the subnet identifier and host identifier. Figure 3-3 depicts an IPv6 address with 48 bits allocated to the network prefix.

Figure 3-3. 48-Bit Network Prefix

Subnets within an organization often have network prefixes of 64 bits (/64), leaving 64 bits for allocation to hosts’ interfaces. The host ID should use a 64-bit interface identifier that follows EUI-64 (Extended Unique Identifier) format when a global network prefix is used (001 to 111), except in the case when multicast addresses (1111 1111) are used¹⁰. Figure 3-4 depicts an IPv6 address with 64 bits allocated to the network prefix.

Figure 3-4. 64-Bit Network Prefix

Due to their length, IPv6 addresses do not lend themselves to human memorization. Administrators of IPv4 networks typically can recall multiple IPv4 network and host addresses; remembering multiple IPv6 network and host addresses is more challenging. The notation for IPv6 addresses may be compressed and simplified under specific circumstances.

One to three zeroes that appear as the leading digits in any colon-delimited hexadecimal grouping may be dropped. This simplifies the address and makes it easier to read and to write. For example:

2001:0db8:0aba:02e5:0000:0ee9:0000:0444/48 becomes 2001:db8:aba:2e5:0:ee9:0:444/48

It is important to note that trailing zeroes may not be dropped, because they have intrinsic place value in the address format.

Further efficiency is gained by combining all-zero portions of the address. Any colon-delimited portion of an address containing all zeros may be compressed so that nothing appears between the leading and trailing colons. For example:

2001:0db8:0055:0000:cd23:0000:0000:0205/48 becomes 2001:db8:55:0:cd23::205/48

In this example, the sixth and seventh 16-bit groupings contain all zeroes; they were compressed by eliminating the zeroes completely, as well as the colon that divided the two groupings. Nevertheless, compressing an address by removing one or more consecutive colons between groups of zeroes may only be done once per address. The fourth 16 bit-grouping in the example also contains all zeroes, but in the condensed form of the address, it is represented with a single zero. A choice had to be made as to which group of zeroes was to be compressed. The example address could be written:

2001:db8:55::cd23:0:0:205/48, but this is not as efficient as 2001:db8:55:0:cd23::205/48.

It is important to note that both of the addresses in the preceding paragraph are properly formatted, but the latter address is shorter. Compression is just a convention for writing addresses, it does not affect how an address is used, and it makes no difference whether compression falls within the network prefix, host identifier, or across both portions of the address.

This section introduces the different types of IPv6 addresses, their scope, and use. It introduces IPv6 addressing as basic information needed for secure adoption and deployment of the protocol. RFC 4291, IP Version 6 Addressing Architecture, is the authoritative source for information on IPv6 addressing, and it should be referenced for comprehensive details. Mechanisms for generating and assigning IPv6 addresses are discussed in detail in subsequent sections of this document.

Table 3-2. IPv6 Address Types

IPv6 addressing differs from IPv4 in several ways aside from the address size. In both IPv4 and IPv6, addresses specifically belong to interfaces, not to nodes. However, because IPv6 addresses are not in short supply, interfaces often have multiple addresses. As discussed in 3.1, IPv6 addresses consist of a network prefix in the higher order bits and an interface identifier in the lower order bits. Moreover, the prefix indicates a subnet or link within a site, and a link can be assigned multiple subnet IDs.

Many IPv6 address ranges are reserved or defined for special purposes by the IETF’s IPv6 standards and by the Internet Assigned Number Authority (IANA). Table 3-2 lists the major assignments and how to identify the different types of IPv6 address from the high-order bits.

All address ranges not listed in Table 3-2 are reserved or unassigned. IANA currently assigns only out of the binary range starting with 001.11

IPv6 uses the notion of address types for different situations. These different address types are defined below:

The format of anycast addresses is indistinguishable from unicast addresses.

n bits

128 − n bits

subnet prefix

00000000000000

The subnet prefix in an anycast address is the prefix that identifies a specific link. Anycast addresses are intended for efficiently providing services that any one of a number of nodes can perform (e.g., a Home Agent for a Mobile IP node). Anycast addresses may not be used as source addresses and, as of the writing of this guide, may only be assigned to routers. It should be noted that there are no defined mechanisms for security or registration for anycast, nor is there a way to verify that a response to a packet sent to an anycast address was sent by an interface authorized to do so. This leaves open the possibility of impersonating anycast servers.

The shortage of IPv4 addresses led to the designation of non-routable addresses in RFC 1918 and the widespread use of Network Address Translation (NAT) to share globally routable addresses (with certain limits placed on the hosts using so-called RFC 1918 addresses). IPv6 has no such shortage, so the use of NAT is unnecessary; nevertheless, the usefulness of addresses with limited scope was identified and maintained in IPv6. IPv6 addresses with different scopes were defined. In the original design for IPv6, link local, site local, and global addresses were defined; later, it was realized that site local addresses were not well enough defined to be useful. Site local addresses were abandoned and replaced with unique local addresses. Older implementations of IPv6 may still use site local addresses, so IPv6 firewalls need to recognize and handle site local addresses correctly.

The IPv6 standards define several scopes for meaningful IPv6 addresses:

Link-local address:

Link-local addresses are used for administrative purposes such as neighbor and router discovery.

IPv4-compatible IPv6 address:

IPv4-mapped IPv6 address:

The two IPv4 embedded address types are similar. The only difference is the sixth group of 16 bits. IPv4-compatible addresses set these to 0; IPv4-mapped addresses set these to 1.

A more generalized form of IPv4-embedded IPv6 addresses has been defined (RFC 6052), to aid the process of automated translation from one type of address to the other. Two new variants of IPv4-embedded IPv6 addresses are:

It is quite likely that additional special-use variants will be defined in the future.

An essential design consideration for IPv6 is to simplify routing in enterprise and global networks. One of the intents of the IPv6 address schema is to facilitate hierarchical routing. Hierarchical routing in turn accelerates the end-to-end routing function, and routing table convergence and maintenance are vastly simplified.

A typical IPv6 interface is configured to receive packets sent to several addresses. In addition to its link local and global unicast addresses, it may have a unique local address. It can also receive multicast messages sent to the all hosts and solicited node multicast addresses, as well as possibly to other multicast addresses. Finally, because of renumbering, multiple instances of some of these addresses may be active at once. How these addresses are selected is covered in the Sections 4.6, Address Selection, and 4.2, Multicast.

Each IPv4 address is 32 bits long and is typically written as four decimal numbers (0-255) representing eight bits each and separated by decimal points or periods. This is called dotted decimal. An example of an IPv4 address is 172.30.128.97. Each IPv4 address is associated with an additional component called a subnet mask, which denotes how many high-order bits of the address are assigned to the network address (RFC 950). The remaining lower-order bits are used to identify the node.

Three primary subnet types or network classifications were designed for IPv4: Class A, Class B, and Class C (RFC 791). Typically, Class A networks were assigned to the early pioneers of the Internet. Class B networks typically were assigned to larger enterprises and service providers, and Class C network addresses usually were allocated to smaller organizations and treated as subnets of larger networks. The following are examples of IPv4 network addresses and their related subnet masks:

CIDR addresses do not follow the Class A/B/C model. Netmasks in CIDR addresses are not confined to the octet boundaries of an IPv4 address. For example, the CIDR address 192.168.1.1/27 indicates that the IP address is 192.168.1.1 and the netmask splits the address after the 27th bit.¹² The first 27 bits are designated for the network address, and the final five bits are available to provide 30 node or host addresses within that network. This allows for a much more granular approach to address allocation because ranges of addresses can be sized appropriately to the organization receiving them. Of equal importance to address conservation is the related mechanism for routing efficiency that CIDR brings. CIDR addressing allows multiple subnets, defined by common netmasks and having adjacent addresses, to be supernetted together. This means that multiple networks are aggregated and reachable under one routing table entry.

The Internet and many large enterprise networks are comprised of core routers (also known as backbone routers) that move vast amounts of data between networks. These routers connect disparate networks and thus make the Internet what it truly is: a network of networks. This same concept applies to large, geographically dispersed enterprise networks. Core routers maintain large, complex routing tables that contain accurate and timely information about how to reach nearly every network that is a part of the global Internet.

The number of entries in these backbone routing tables has increased dramatically since CIDR addressing was introduced in 1993 (RFC 4632), despite the best intentions of supernetting CIDR address space together. As a result, core routers are burdened with ever increasing demands on their memory and processing capacities. In short, IPv4 does not lend itself to a highly scalable and efficient Internet backbone infrastructure.

Routing prefix aggregation allows contiguous groupings of CIDR addresses to be advertised to the global Internet as a single network rather than as multiple, distinct networks. Separate routing table entries no longer need to be made for each allocation of address space. Much like the concept of supernetting, this means that two distinct organizations sharing only one common attribute, their Internet Service Provider (ISP), can be attached to the Internet with unique IP addresses from an appropriately sized allocation. Yet those two distinct entities are reachable through the global Internet using only one globally unique network route. The two concepts discussed here, scalability of address allocations and routing efficiency through prefix aggregation, are integral aspects of the design of IPv6.

IPv6 was designed to provide sufficient numbers of globally unique IP addresses to enable true peer-to-peer communication between nodes on interconnected networks. It was also designed to provide a simplified hierarchical routing architecture across the Internet backbone—one that does not suffer from inefficiencies and increasing demands for memory and processing capacities on backbone Internet routers. Several accommodations have been made to retrofit these concepts onto IPv4, while these same concepts are native to the IPv6 specification.

IPv6 provides an enormous number of unique addresses, about 3.4 x 1038 compared with IPv4’s roughly 4.3 x 109 addresses. The number of possible IPv6 addresses is so large that many analogies and metaphors have been created that attempt to convey its magnitude. For example, if each IPv6 address weighed one gram, the sum total weight of all IPv6 addresses would be greater than the weight of 56 Earths. The available address space under IPv6 is generally considered to be sufficient for the foreseeable future, even considering the historical growth of the Internet and the devices expected to connect to it in the future. See Figure 3-5 for a comparison of IPv4 and IPv6 addressing conventions.

Figure 3-5. A Comparison of IPv4 and IPv6 Addressing7

The constraints of IPv4 addressing were major considerations when IPv6 addressing was designed. The IPv6 addressing architecture is different not only in terms of address length, but also in terms of address types, address notation, and address aggregation. As discussed in Section 2, as well as later in Sections 3 and 4, each of these differences enables new features in IPv6.

In both IPv4 and IPv6, Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS) can be used to assign, monitor, administer, and change IP addresses. IPv6 also includes an autoconfiguration capability for assigning IP addresses to hosts. Due to the smaller amount of address space available with IPv4, address management was often not complex, with some organizations manually tracking address assignments. The longer, more complex IPv6 addresses, as well as the much larger amount of address space, will most likely require the use of address management tools to avoid errors. In IPv4, it is customary to allocate addresses sequentially, whether they are allocated manually or using DHCP. In IPv6, with an address space large enough to defeat attackers’ scanning attempts, addresses should be allocated non-sequentially (e.g., randomly), to preserve that advantage.

IPv6 addresses have a flexible structure for address assignments. This enables registries, ISPs, network designers, and others to assign address ranges to organizations and networks based on different criteria, such as size of networks and estimated growth rate. Often, an initial assignment does not scale well if a small network becomes larger than expected and hence needs more addresses. The assignment authority may not be able to allocate contiguous addresses if they were already assigned to another network.

Section 3.2.1 describes address assignments using leftmost, rightmost, and centermost strategies. With these methods, organizations have the flexibility to aggregate their IPv6 address allocations efficiently. Section 3.2.2 explains how organizations can obtain IPv6 addresses allocations globally through several regional registry services.

IPv6 network prefix assignment is the first step in network deployment. Understanding several methods such as leftmost, rightmost, and centermost helps provide for flexibility and efficient aggregation of an assigned IPv6 block, as described in RFC 3531, A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block. If done without foresight, boundaries between sub-allocations become difficult to move, and future increases in the use of address space cannot be kept contiguous.

The easiest but least flexible solution is to make block address assignment in order from the beginning of the organization’s allocated IPv6 block. For example, if an organization is assigned the prefix 2001:0db8:9095::/48, prefixes can be distributed in simple sequential order:

2001:0db8:9095:0001::/64 2001:0db8:9095:0002::/64 2001:0db8:9095:0003::/64

This is the simplest way to distribute address assignments, but it lacks consideration for future needs and does not take into account grouping networks by site for clean routing aggregation. Additionally, this method makes it impossible to make an existing network assignment larger and keep its address space contiguous.

RFC 3531 proposes a method to manage the assignment of bits of an IPv6 address block or range. First, the scheme defines parts of the IP address as p1, p2, p3, ….pN in order, so that an IP address is composed of these parts contiguously. Boundaries between each part are based on the prefix assigned by the next level authority. Part (p1) is the leftmost part probably assigned to a registry, Part (p2) can be allocated to a large ISP or national registry. Part (p3) can be allocated to a large customer or a smaller provider, etc. Each part can be of different length.

←

→

IPv6 addresses

The algorithm for allocating addresses is as follows: (p1) for the left-most part, assign addresses using the leftmost bits first; (pN) for the rightmost part, assign addresses using the rightmost bits first; and for all other parts (center parts), predefine an arbitrary boundary (prefix) and then assign addresses using center bits of the part being assigned first.

This algorithm increases the assigned bits in such way that it keeps unassigned bits near the boundaries between the parts. This means that the boundary between any two parts can be changed forward or backward, later on, up to the assigned bits. See Table 3-3 for the assignment of leftmost, centermost, and rightmost bits.

Table 3-3. Assignment of Leftmost, Centermost, and Rightmost Bits

A brief example based on RFC 3531 uses a provider called P1. This provider has been assigned the 3ffe:0b00/24 prefix and wants to assign prefixes to its connected networks. It expects in the foreseeable future a maximum of 256 customers consuming 8 bits. One of these customers, named C2, expects a maximum of 1024 customers’ assignments under it, consuming 10 other bits (see RFC 3531 for greater detail). The assignment will be as follows, not showing the first 24 leftmost bits (3ffe:0b00/24 or 0011 1111 1111 1110 0000 1011):

P1 assigns address space to its customers using leftmost bits:

1000 0000 : assigned to customer 1 (C1) 0100 0000 : assigned to customer 2 (C2) 1100 0000 : assigned to customer 3 (C3) 0010 0000 : assigned to customer 4 (C4)

C2 assigns address space to its customers (C2C1, C2C2, ….) using centermost bits:

0000 10000 : assigned to C2C1 0001 00000 : assigned to C2C2 0001 10000 : assigned to C2C3

Customer of C2 uses centermost bits for maximum flexibility and then the last aggregators (which should be networks within a site) will be assigned using rightmost bits.

Putting all bits together for C2C3:

By using this method, P1 will be able to expand the number of customers, and the customers will be able to modify their first assumptions about the size of their own customers, until the reserved bits are assigned.

Predicting future network requirements will always be a challenge with ever changing business needs and unforeseen technological advances. Nonetheless, a strategy to account for organizational needs, possible growth areas, and consideration to address assignment will provide as much downstream flexibility as possible.

The Internet Corporation for Assigned Names and Numbers (ICANN)¹³ and IANA¹⁴ have delegated most IPv6 address allocation to five Regional Internet Registries (RIR):

ISPs find information about their regional registries at these Web sites. Organizations and end users get their address allocations from their ISPs. Normally, a RIR allocates a /32 address to qualified ISPs, which are called Local Internet Registries (LIR), and the ISP allocates /48 addresses to its customers¹⁶.

American Registry for Internet Numbers (ARIN) is allowing some large government agencies to get provider independent (PI) IPv6 address assignments, defined in ARIN’s Number Resource Policy Manual (NRPM) Section 6.5.8, Direct Assignments from ARIN to end-user organizations¹⁷. To qualify for a direct assignment, an organization must not be an IPv6 local Internet registry and must qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. If these criteria are met, an organization is eligible to receive a minimum assignment of /48, and with justification can request additional subnets. These assignments will be made from a distinctly identified prefix with a reservation of growth of at least /44.

From one point of view, the case for PI assignments can allow for a small number of large organizations to avoid a significant expense due to address renumbering. In addition, organizations may not want to be locked in to a specific Internet provider. On the other hand, the main concerns regarding PI assignment include two major issues. The first is the possibility of a large increase in the size of the IPv6 default-free routing table; these tables generally point only to top-level domains of aggregated routes. PI assignments do not fit into the normal aggregation and will increase the size of these tables. Secondly, the fear is that early adopters, similarly to IPv4, would have an unfair advantage vis à vis those who adopted later.

IPv6 address allocation is designed to allow routing prefix aggregation. IPv6 network addresses may be aggregated in the same sense that IPv4 CIDR addresses are. IPv6 address allocation is based on the hierarchy mentioned previously, and allocated blocks of addresses are widely dispersed with top-tier allocations having network prefixes of 32 bits. This leaves 96 bits’ worth of addresses that can all be aggregated through a single route advertisement on the Internet backbone.

Consider routing prefix aggregation for a large backbone service provider. The service provider, hypothetically, receives a block of address space with a 32-bit network prefix. In turn, the provider allocates this address space to customers. Those customers could be multiple regional network service providers or large enterprises that receive blocks of addresses with 48-bit network prefixes from that single large backbone service provider. Subnets within those enterprises and smaller regional service providers may have address space with 64-bit network prefixes.

This arrangement may easily result in tens of millions of nodes attached to millions of subnets, all of which are aggregated and reachable via the global Internet through one route on the Internet’s backbone routers.

IPv6 address allocation is a work in progress. Organizations should familiarize themselves with assignment and reporting requirements that differ from those for IPv4. RFC 3177, IAB/IESG Recommendations on IPv6 Address Allocations to Sites, documents an ongoing effort to provide the latest information for the Internet community regarding current practices, status, and clarifications for IPv6 address allocations. ARIN¹⁸ will document its policy as well.

The design of the IPv6 header is the culmination of lessons learned from more than 20 years of experience with IPv4. Two primary design goals for the new header were efficiency and extensibility. The IPv6 header is always 40 bytes long and contains only eight fields, whereas IPv4 headers may be as short as 20 bytes or as long as 60 bytes and contain at least 12 different fields (some of which may be unused). When comparing these attributes, it becomes apparent that the IPv6 header is simpler and more efficient to process. Three examples are:

The design also pays careful attention to alignment for 64-bit processors; for example, the addresses are aligned on 64-bit boundaries.

The constant size of IPv6 headers makes the header length field found in IPv4 unnecessary. Routers and intermediate nodes handling the packets are not required to accommodate variability in the length of the headers, which expedites packet handling. The IPv6 header format is illustrated in Figure 3-6.

Figure 3-6. The IPv6 Packet Header Format (Field Sizes in Bits) (RFC 2460)

The fixed length of the IPv6 header does not preclude flexibility in favor of function. Options are handled with extension headers, which are described in detail in the next section. The following are the eight fields in the fixed IPv6 header:

A packet capture of an IPv6 header is illustrated in Figure 3-7.

Figure 3-7. Example IPv6 Packet Header

Extension headers provide major services and functions for the IPv6 protocol. As discussed, the IPv6 header is much simpler with its eight fields and 40-byte header allowing faster processing. Moreover, IPv6 has a new way to deal with options that has substantially improved processing: it handles options in additional headers called extension headers.⁴ Extension headers are inserted into a packet only if the options are needed.

Within the IPv6 packet header and its eight fields, the first extension header is identified in the NH field. In IPv6, optional Internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet (RFC 2460). There are a small number of such extension headers, each identified by a distinct NH value (see Table 3-4, IPv6 Extension Headers and Upper Layer Protocols). An IPv6 packet may carry zero, one, or more extension headers, each identified by the NH field of the preceding header and thus forming a chain illustrated below in Figure 3-8. The NH fields indicate the Routing extension header; next, the Fragment extension header; the ESP extension header; and, finally, the TCP header.

Figure 3-8. Next Header Fields in IPv6 and Extension Headers

Except for Hop-by-Hop Options, extension headers are examined or processed only by the node identified in the Destination address field of the IPv6 header (or a set of nodes, in the case of multicast)⁴ and must be processed strictly in the order in which they appear in the packet. The Hop-by-Hop Option Header is indicated by the value zero (0) in the NH field and requires that information within the packet be examined and processed by every node along the path of the packet.

Figure 3-9. IPv6 Extension Header Chaining9

Figure 3-9 illustrates further how the NH field in the IPv6 packet header points to the following header in a chain of NHs, which defines the different parts of the payload in the packet. In this example, the NH field of the last extension header in the packet contains the type of the upper-layer protocol, e.g., TCP (value 6) or UDP (value 17). See Table 3-4 for the most common NH values. The IPv6 specification (RFC 2460) defines six NH values or extension headers. Other extension headers such as the Mobility Header are defined elsewhere.

Extension headers are established at the source before transmission of the packet. Their order and contents are not altered by intermediary nodes.

Extension headers provide important services and functions for the IPv6 protocol. They may direct intermediary nodes about how packet payloads are to be handled prior to reaching their ultimate destination. Defined extension headers for the IPv6 protocol should occur in a recommended order. RFC 2460, Internet Protocol, version 6 (IPv6) Specification, indicates that future extension header specifications may be more precise when it comes to ordering. To accommodate the definition and deployment of additional extension headers, each extension header includes information that instructs the receiver how to behave if it does not recognize a new extension header type. The two basic types of behavior are: skip the unrecognized extension header but continue processing the packet or discard the packet.

The following table illustrates the recommended order for extension headers. Only the Hop-by-Hop Options are required by the specification to be placed immediately after the IPv6 header (literally the IPv6 “next header”). Note that more than one extension header may be used in a packet. In those cases, RFC 2460 recommends the first four extension headers be prioritized according to the first four entries in the table below.

Table 3-4. IPv6 Extension Headers and Upper Layer Protocols¹⁹

Note that, from a security point of view, simply examining the Destination Address in the IPv6 header may not provide all of the information needed to make packet filtering decisions. An amplification attack, resulting in severe congestion and DoS, can be caused by a packet with a Routing Header containing multiple instances of the same address. Thus, it is crucial to perform ingress filtering that prohibits the forwarding of packets with a Type 0 Routing Header (RFC 5095).

The NH field and the related extension headers provide IPv6 with flexibility and extensibility, while taking advantage of fixed-length headers with a reduced number of fields as compared with IPv4. NH functionality in IPv6 provides the foundation for enhanced services such as IPv6 security and mobility. They should be kept in mind when securing IPv6 networks, to be discussed later in this document.

Using extension headers can have a number of security implications. Packets containing hop-by-hop extension headers must be analyzed at every node along the forwarding path, and can potentially cause a resource consumption attack. Extension headers also incorporate additional complexity for the purpose of traffic filtering. An example is enforcing a policy that blocks IPv6 traffic with mobility headers if IPv6 mobility is not being used by an organization. Incorporating extension header filtering policies may also impact a device’s overall performance. Filtering is discussed in greater detail in Section 6, and ICMPv6 recommended filtering recommendations are provided in Table 3-7. Extension headers can also be used as a “covert channel” to hide communications between two systems, e.g., in Destination Options.

The IPv6 specifications redefine the Internet Control Message Protocol (ICMP) of IPv4 with a number of additions and changes. The resulting protocol is documented in RFC 4443 and called ICMPv6. Specific details regarding ICMPv6 are provided here, along with examples of how the protocol differs from its counterpart under IPv4.

ICMPv6 is an integral aspect of the IPv6 specification. It reports errors if packets cannot be processed properly and sends informational messages about the status of the network. An operational IPv6 network depends upon proper implementation and functionality of ICMPv6. To achieve secure IPv6 operations, it is crucial that network administrators and managers understand the design of ICMPv6 and how it functions. Managers of IPv4-only networks should consider adding the capability of detecting ICMPv6 traffic to enhance security on their networks.

ICMPv6 provides IPv6 with administrative and network diagnostic functions. ICMPv6 provides familiar capabilities like ping and destination unreachable. In IPv6, as in IPv4, ping can be used by network administrators as a diagnostic tool to confirm that a node’s address is properly configured and responsive to specific ICMPv6 requests, called echo requests. ICMPv6 also makes new features like Neighbor Discovery (ND) and path MTU discovery possible within IPv6. ND, described in RFC 4861, is the process by which an IPv6 node may learn important information such as link layer addresses of interfaces on its own link.

ND effectively replaces the Address Resolution Protocol (ARP) used with IPv4. ND’s multicast messages eliminate the need for the link-level broadcast messages associated with ARP.

This section provides an overview of the ICMPv6 specification. The intent of this section is to introduce the reader to fundamentals of the ICMPv6 specification: message format, error handling, and diagnostics. As mentioned previously, specific applications of ICMPv6 (MTU discovery, ND, etc.) are defined in their respective RFCs.

A standard IPv6 header precedes every ICMPv6 message. The IPv6 header may or may not contain extension headers. The IPv6 header identifies the ICMPv6 header with a NH value of 58.

ICMPv6 messages have the following general format, illustrated in Figure 3-10:

Figure 3-10. ICMPv6 Message Format

The ICMPv6 specification defines two classes of ICMP messages: error and informational. Other protocols such as Mobile IPv6 define additional messages within each class. Tables 3-5 and 3-6 provide an overview of some of the most common message types²⁰, along with the additional code information, which depends on the message type.

Table 3-5. ICMPv6 Error Messages and Code Type

Table 3-6. ICMPv6 Informational Messages

Error messages are used, for example, if a transmitting node sends a packet of 1500 bytes, but an intermediary hop has an MTU of only 1300. The intermediary node then sends an ICMPv6 Packet Too Big (Type = 2) error message to the sender with information about the problem. For ICMPv6 error messages, the sender includes, at least, the start of the packet causing the error to allow the originator of the packet to identify the upper-layer protocol and perhaps the process that sent the packet. Informational messages may contain configuration information such as a local router’s address in a Router Advertisement (RA) message.

Several differences exist between the ICMP specifications for IPv4 and IPv6. These include using ND to replace ARP, dynamic PMTU discovery, and several automated administrative functions unique to IPv6. In particular, some of these differences are:

ICMPv6 specifies a framework for control messages to provide IPv6 with error handling and parameter establishment functions. Several of ICMPv6’s functions are new or different from ICMP under IPv4. Furthermore, ICMPv6 is a fundamental and essential component of any IPv6 implementation. For example, no IPv6 or dual stack IPv4/IPv6 network can function properly without ICMPv6. The next sections contain more detail about ND, Autoconfiguration, and the security ramifications of ICMPv6.

ND, described in RFC 4861, is the process by which an IPv6 node may learn important information such as link layer addresses of interfaces on the same local segment. ND effectively replaces the ARP found in IPv4. Additionally, it combines this with ICMP Router Discovery and Redirect capabilities. This subsection describes ND in brief, and improvements over the IPv4 set of protocols are noted.

IPv4 is limited in determining whether a neighbor is reachable. The Neighbor Discovery Protocol (NDP) for IPv6 specification is used by all nodes, hosts and routers. IPv6 nodes use ND for the following purposes:4

As described in RFC 4861, nodes use ND to determine the link-layer addresses for neighbors known to reside on attached links and to purge cached values that become invalid. Hosts also use ND to find neighboring routers that are willing to forward packets on their behalf. Finally, nodes use the protocol to keep track of which neighbors are reachable and which are not, and to detect changed link-layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternates.

ND plays an important role in addressing because it provides address resolution and address autoconfiguration. These are accomplished through the different processes in the ND protocol, which consists of five different ICMP packet types: a pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisement messages, and a Redirect message (listed above under ICMPv6 informational messages). RFC 4861 defines the purpose of these messages, which are all sent via multicast ICMPv6:

A common use of the NS and NA messages is to resolve IP addresses by discovering the MAC (Media Access Control) addresses of nodes on the same link. A sender must discover the recipient’s MAC address to send a data packet. Figure 3-11 illustrates this example of the ND process.

Figure 3-11. Example of Neighbor Discovery

For NS, the sending node (Host A) knows the unicast address of the destination node (Host B) is local because of the network prefix. Knowing this, it uses a link-local solicited-node multicast address to send its NS message. The process that allows the sending node to resolve this link-local MAC address is as follows:

Destination Node Unicast Address: 2001:DB8::1234:5678:BBBB

NS solicited node multicast destination address (last 24-bits of the unicast address): FF02::1:FFxx:xxxx final form → FF02::1:FF78:BBBB

The sending node takes the low-order 24-bits of the unicast address of the destination node and uses them to fill in the link-local solicited-node multicast address with format “FF02::1:FFxx:xxxx”. The NS message includes both the IPv6 and MAC address of the sender, so the recipient can answer directly and supply its own MAC address. The destination node, knowing its unicast address, will listen for the corresponding solicited node multicast address. When the multicast message arrives at the destination, the destination node analyses the packet. Seeing the FF02::1 multicast with the ICMPv6 MAC request, the destination checks that it is the intended recipient, updates its neighbor cache, and replies with a NA sending its true MAC address.

ND is essential to the correct operation of an IPv6 network, as well as associated procedures like NUD and DAD. Routers must provide multicast services correctly and obey scope rules, and interfaces must be able to receive solicited node multicast messages. ND security ramifications are discussed in Section 3.5.6; Secure Neighbor Discovery is discussed in Section 5.4.

Autoconfiguration, described in RFC 4862, is essentially plug-and-play networking.

One of the most interesting and potentially valuable addressing features implemented in IPv6, this new feature allows devices on an IPv6 network to configure addresses independently using stateless address autoconfiguration (SLAAC). Whereas in IPv4, hosts were originally configured manually or with host configuration protocols like DHCP, IPv6 autoconfiguration goes a step further by defining a method for devices to configure their IP address and other parameters automatically without the need for a server. Moreover, it also defines a method, renumbering, whereby large numbers of IP addresses on a network can be renumbered. This subsection describes autoconfiguration in brief as well as several improvements over the IPv4 set of protocols.

IPv6 defines both Stateful and Stateless address autoconfiguration. SLAAC, illustrated in Figure 3-12, requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. This allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Locally available information is delivered to a host when routers advertise prefixes that identify the subnets associated with a link. In turn, a host generates an interface identifier that uniquely identifies an interface on a subnet. As previously discussed, an address is formed by combining the two. If a router is not available to advertise subnet prefixes, a host can only generate link-local addresses, which are sufficient for allowing communication among nodes attached to the same link; in the presence of a router, a host will generate its link-local address in addition to other addresses.

Stateful autoconfiguration for IPv4 is known as DHCP. In this case, hosts obtain interface addresses or configuration information and parameters from a server. DHCP servers maintain a database to keep track of which addresses have been assigned to each host. The IPv6 version, DHCPv6, is described in Section 4.7.

As defined in RFC 4862, an IPv6 address can have different states:

Figure 3-12. Example of Stateless Address Autoconfiguration (SLAAC)

With IPv4, a router can fragment a packet when the Maximum Transmission Unit (MTU) of the next link is smaller than the packet it has to send. The router does this by slicing the packet to fit into the smaller MTU and sending it out as a series of fragments. The packet is then reassembled at the final destination, which can be very inefficient. It can also introduce additional traffic into the network, in the form of an increased number of smaller-than-necessary packets, as well as necessitating re-transmission of packets if all of the fragments do not arrive within a specific time interval. With IPv6, routers do not fragment packets; instead, the sender discovers the maximum packet size by using Path Maximum Transmission Unit (or PMTU) for the entire path. PMTU discovery is the process by which each node on the network establishes an important IPv6 parameter for a given communication session. The PMTU establishes the maximum packet size, measured in bytes, which may be carried across a sequence of network nodes. PMTU for a local network segment can be determined directly from the MTU in RA messages.

The IPv6 specification calls for a MTU of at least 1280 bytes. In other words, all links must accept packets of any size up through 1280 bytes. The minimum recommended MTU for IPv6 is 1500 bytes. The IPv6 specification does not allow intermediate nodes (such as routers) to fragment packets in transit. Instead, PMTU is determined dynamically and maintained throughout each communication session. By disallowing fragmentation by intermediary devices, IPv6 achieves a level of efficiency that is generally not available under IPv4. Intermediate nodes operate faster and with less processing overhead by not having to fragment packets, and destinations receive fewer packets requiring reassembly. Since originating nodes know the PMTU, they can in most cases ensure that traffic is sent with no fragmentation at all.

The PMTU of any given network path is equal to the smallest MTU along that path. For example, Figure 3-13 depicts two nodes establishing a communications session across three intermediate nodes. The links to the two end nodes (A and B) have MTUs of 1500, whereas the links connecting the three intermediary nodes (1 and 2; 2 and 3) have MTUs of 1300 and 1800, respectively. The PMTU of the network path between nodes A and B is 1300 bytes. This is because the MTU from node 1 to node 2 is only 1300 bytes, the smallest of the four hops.

In this example, ICMPv6 is employed by all nodes to recognize and configure the PMTU automatically. The two endpoints of the path set the PMTU to 1300 without administrative intervention. The size of an IPv6 packet traversing this path for this session needs to conform to the PMTU for the path; otherwise it is dropped and the sender receives an ICMPv6 error message requesting it to retransmit using a smaller packet size.

Figure 3-13. Significance of MTU under IPv6

The PMTU protocol is detailed in RFC 1981.

This section describes security considerations for ICMPv6. Examples include denial of ICMPv6 traffic that can effectively result in a denial of service condition for a given network. The functions of Neighbor Discovery and PMTU discovery are entirely dependent upon the proper functioning of ICMPv6. Not only is proper Neighbor Discovery configuration essential to a functional IPv6 network, but misconfiguration of RA and RS parameters can compromise the security of the network.

Rogue routers or misconfigured nodes may be inserted on a local network segment and configured to propagate false or inaccurate RA messages. Network nodes on this segment might then learn false routing information that would result in network traffic being sent through the rogue router. Further, forged RA messages may be sent from legitimate hosts on an IPv6 network segment, possibly causing other nodes to forward packets to non-existent routers and resulting in a denial of service or man-in-the-middle attack. Additionally, malicious responses to DAD messages can cause denial of service conditions on a local network segment; DAD can be disabled on specific network or security device interfaces to prevent Denial of Service (DOS) attacks. Spoofed NS/NA packets can cause redirect or DOS attacks. Secure Neighbor Discovery (SEND) was developed to help mitigate some of the security issues caused by rogue devices. SEND is discussed in more detail in Section 5.4.

Router access control lists (ACLs), firewalls, and other security components must be carefully managed to retain ICMPv6 functionality. Any security measures on a network segment must allow IPv6 nodes to use ICMPv6 to accomplish Neighbor Discovery, PMTU discovery, and other essential tasks. If an IPv6 default router on a network segment is unable to receive and reply to legitimate RS messages, nodes sending those messages may experience a denial of service condition. PMTU messages should also be allowed to traverse network perimeters, to enable proper functioning of IPv6 end-to-end communications.

Some ICMPv6 traffic (e.g., RS and RA) is only useful on the local segment, uses link-local addresses, and should never be routed. Port-based ACLs can be used to prevent any Ethernet port from receiving RA messages coming inbound to the network from an end-user computer. ACLs implemented on common routers can be configured to allow other appropriate ICMPv6 traffic to pass despite the presence of the default deny all parameter. Network administrators should confirm the inherent ICMPv6 capabilities of their router’s operating system and confirm the configuration parameters that govern the handling of ICMPv6. There may be places in the network (e.g., a Demilitarized Zone [DMZ]) where it makes sense to disable Neighbor Discovery and use static neighbor cache entries instead.

Any IP network, whether it is IPv4-only or a dual stack IPv4/IPv6 network, must have the capability to detect and examine ICMPv6 and IPv6 packets. Without this capability, rogue IPv6 nodes may be operating on a network that is intended to handle only IPv4. ICMPv6 is fundamental to the operation of IPv6 networks, and even malicious IPv6 nodes will depend upon ICMPv6 to operate. Network administrators and managers should evaluate the capability of their existing tools used to monitor ICMP traffic for similar support for ICMPv6.

Use of IPsec to authenticate the sender and validate the contents of ICMPv6 messages is often not possible. Additionally, establishing security associations with all possible sources of ICMPv6 messages is generally not possible. Furthermore, some ICMP messages (e.g., PMTU) may be returned from intermediate routers, not from the message’s ultimate destination. A further discussion about the use of IPsec with ICMPv6 is included in Section 5.4.1. Due to this inability to establish security associations, alternatives should be used to reduce the vulnerability to ICMPv6-based attacks.

It is essential to establish strict filtering policies in site firewalls to limit ICMPv6 messages that can pass between the site and the Internet. Firewall treatment of ICMPv6 traffic requires finer-grained handling than may have sufficed for IPv4. Certain IPv6 features, such as Path MTU Discovery, require the transmission of the associated ICMPv6 messages (e.g., Packet Too Big) for proper functionality. On the other hand, messages associated with other features, like Network Discovery, should not be transmitted from outside the local link.

Hence, providing only a blanket "allow all"/"block all" choice for ICMP traffic handling, which may have been adequate for IPv4, is not appropriate for IPv6. The Federal IPv6 Profile²¹ requires firewalls to at least be able to block/allow ICMPv6 traffic selectively based on type and code.

More sophisticated firewalls can do better: by associating connection-specific ICMPv6 types (such as

Packet Too Big or, in some situations, Destination Unreachable) with the corresponding state records for existing connections (TCP, UDP, or SCTP streams), such stateful firewalls can limit even allowed types to those that could legitimately be part of permitted traffic flows.

Table 3-7 gives recommended ICMPv6 firewall settings for various possible traffic types. The “Maintenance of Communications” and “Error Messages” sections of the table assume the more sophisticated connection-association capabilities mentioned above; less-sophisticated firewalls would have to allow these messages whenever a corresponding connection could occur, based on other rules (e.g., allowed source and destination addresses).

The recommendations for ICMPv6 firewall filtering in Table 3-7 are based on RFC 4890, Recommendation for Filtering ICMPv6 Messages in Firewalls. These recommendations allow propagation of ICMPv6 messages needed to maintain functionality of the network but drop messages posing potential security risks. Many ICMPv6 messages should only be used in a link-local context, rather than end-to-end, and filters need to be concerned with the types of addresses in ICMPv6 packets as well as the specific source address, destination addresses, and ICMPv6 Type. RFC 4890 classifies ICMPv6 messages according to whether they are designed for end-to-end communications (traffic to transit a firewall) or local communications within a link (local traffic addressed to an interface on a firewall). All experimental and undefined ICMPv6 messages should be dropped. ACLs should permit only those ICMPv6 messages that are required, based on specific local needs and policies; all others should be dropped.

Table 3-7. ICMPv6 Recommended Filtering Actions – Must Not Drop & Should Not Drop

Routing protocols fall into two general types. Interior Gateway Protocols (IGPs) are designed for use within an autonomous system (AS), that is, among routers that are all controlled by the same enterprise or organization. Exterior Gateway Protocols (EGPs) are designed for exchanging routes between autonomous systems, such as between network carriers or between a large enterprise and its network service providers. To support IPv6, routing protocols, such as Routing Information Protocol (RIP), OSPF, Intermediate System to Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), and Border Gateway Protocol (BGP), had to be updated. This section covers changes to routing protocols, as well as security support for such protocols.

Open Shortest Path First (OSPF) is a link-state hierarchical Interior Gateway Protocol (IGP). Dijkstra’s algorithm is used to calculate the shortest path tree. It uses path cost as its routing metric. Path cost is determined generally by the speed (i.e., bandwidth) of a given route. IPv4 networks run OSPF version 2 (OSPFv2) as specified in RFC 2328.

OSPF version 3 (OSPFv3) is designed specifically for IPv6 and is specified in RFC 5340. OSPFv3 for IPv6 is a completely independent routing protocol from OSPFv2 for IPv4. OSPFv3 expands on OSPFv2 to provide support for IPv6 routing prefixes and the larger size of IPv6 addresses. OSPF is commonly used in large enterprise networks.

The Routing Information Protocol (RIP) is a distance-vector routing protocol that employs hop count as a routing metric. IPv4 uses RIP version 2 (RIPv2) as specified in RFC 2453. The IPv6 version of RIP is standardized in RFC 2080. It is easy to configure, but offers limited flexibility and scalability. RIP enhancements for IPv6, detailed in RFC 2080, also known as RIPng, include support for IPv6 addresses and prefixes and the use of the all-RIP-routers multicast group address FF02::9 as the destination address for RIP update messages. Each RIPng update contains a copy of the entire routing table. RIPng is suited for networks of modest size only.

IS-IS is an IGP that advertises link-state information throughout the network to create a picture of the network topology. IS-IS is an Open Systems Interconnection (OSI) hierarchical routing protocol that designates an intermediate system as a Level 1 or Level 2 device. Level 2 devices route between Level 1 areas to create an intradomain routing backbone. Integrated IS-IS uses a single routing algorithm to support several network address families, such as IPv6, IPv4, and OSI. It runs point to point over the link layer protocol; it does not use IPv4 or IPv6. Each IS-IS update contains only changes to the network topology. IS-IS is flexible, efficient, and suitable for large IPv4/IPv6 networks.

Enhanced Interior Gateway Routing Protocol (EIGRP) is Cisco’s proprietary routing protocol. EIGRP is an advanced distance-vector routing protocol, with optimizations to minimize both the routing instability incurred after topology changes, as well as the use of bandwidth and processing power in the router. EIGRP and IGRP are compatible with each other. EIGRP for IPv4 and EIGRP for IPv6 are configured and managed separately.

BGP4 is the Exterior Gateway Protocol (EGP) used mainly to connect separate routing domains that contain independent routing policies (autonomous systems). Connecting to a service provider for access to the Internet is a common use for Border Gateway Protocol (BGP). BGP version 4 with multi-protocol extensions supports both IPv4 and IPv6. Each BGP update contains only changes to the network topology. BGP is efficient and flexible. Multi-protocol BGP is standardized in RFC 4760.

Routing protocols can be subject to threats such as unauthorized updates for either IPv4 or IPv6 routes. Security capabilities have been designed for routing protocols to mitigate unauthorized update threats. Some IPv6 routing protocols rely on similar mechanisms to those in IPv4 for protection, while others have incorporated IPsec for protection. These security mechanisms do not provide end-to-end security for routing protocols across multiple hops, because while they provide integrity assurance for routing protocol messages between nodes, they do not verify the integrity of messages received from other nodes that are not part of a security association. This is a major security concern for EGPs and a somewhat lesser one for IGPs.

RIPng

RIP for IPv4 uses an MD5-based integrity mechanism; this was removed from RIPng. RIPng offers no integrity assurance features. Per RFC 2080, RIPng leverages IPsec for security. It should be noted that hardware vendors have not incorporated IPsec features as a configuration option, instead relying on native IPv6 IPsec support from the operating platform for protection. RIPng is suitable only for small, private networks where the threat of routing attacks is substantially reduced.

OSPFv3

Securing OSPFv2 in a dual stack environment will protect neither the OSPFv3 protocol nor the OSPFv3 routing table. OSPFv2 allows null, password-based, or cryptographic authentication using MD5-based integrity for routing updates. The authentication fields found in OSPFv2 have been removed from the OSPFv3 packet for IPv6, so MD5 is not an authentication option. OSPFv3 offers no integrity assurance features itself and relies on IPsec AH or ESP for authentication, integrity, and confidentiality. Note that OSPFv3 uses unicast and multicast, and IKE does not work with multicast, so the default method is to use manual keying. Since replay protection cannot be provided using manual keying, OSPFv3 messages are vulnerable to replay attacks, which can lead to DoS attacks, Central Processing Unit (CPU) overload, and localized routing loops. IPsec for OSPFv3 is detailed in RFC 4552.

With routing protocols, routing integrity is usually a greater concern than confidentiality. The ESP parameter NULL indicating no encryption is generally regarded to be an acceptable choice for OSPF security.

IS-IS and EIGRP

Both IS-IS and EIGRP support simple MD5-based integrity for protecting IPv6 routing updates, similar to protecting routing updates for IS-IS and EIGRP for IPv4.

The use of BGP as an inter-AS routing protocol means that it can be subject to serious threats. Three mechanisms exist to mitigate threats to BGP. The first is the use of MD5-based integrity to protect routing updates. The second mechanism to mitigate threats to BGP is GTSM (RFC 5082). GTSM is a simple security mechanism for rejecting spoofed BGP messages based on their IP TTL or Hop Limit.

The sending BGP router always uses a TTL=255, and the receiving BGP router checks that the TTL has the expected value of 255. Any packets from a remote attacker would have to travel via intervening routers, would have a smaller-than-maximum TTL, and would be dropped on receipt. Note however that a router operating as the endpoint of a tunneling protocol may not decrement the hop count upon receiving packets through the tunnel, so these could conceivably come from anywhere with TTL=255. The third mechanism to mitigate threats to BGP is IPsec. IPsec key management can use shared secrets or public key certificates, which allow IPsec to offer scalability. GTSM has the lowest overhead of the three mechanisms, and is the easiest to configure. It also offers the least effective protection. The MD5 signature mechanism offers low overhead and effective protection, but it forces administrators to disrupt their BGP sessions at each key update, and it does not scale well. IPsec offers the most effective protection, least disruption, and best scalability. It also imposes the highest overhead (although the overhead is still small), and it is the most complex mechanism to configure. In summary, using an MD5 checksum is certainly better than nothing, but MD5 itself can be attacked successfully, and most of these methods have no easy ways to change hash functions or even change keys. IPsec is preferable for routing protocols that support its use. All of the above security mechanisms protect against unauthorized insertion or manipulation of routing protocol messages.²² They do not protect against a corrupted or malfunctioning router that may construct and pass along incorrect routing information. Many approaches to providing better end-to-end security for BGP have been proposed, but consensus on a single solution has not yet been achieved.

As IPv6 deployment grows globally so will the Internet’s IPv6 global routing tables. It is very well possible that this expanded growth can impact service providers that already are faced with large IPv4-only routing tables. By assigning IPv6 addresses through service providers, in a hierarchical fashion, there is a greater possibility that efficient aggregation for IPv6 addressing will occur. If more organizations succeed in obtaining PI addressing, then there is a higher risk that global routing tables could explode in size, and hence cause possibly costly hardware upgrades to deal with extremely large routing tables. To assist with developing a scalable Internet architecture, use of techniques that separate end-systems’ addressing space and routing locators’ space (locator-ID split) are also being investigated.

The Domain Name System (DNS) is essential for almost all use of the Internet. It must be available, and it must provide accurate information. Threats such as denial of service against the top-level servers are taken extremely seriously. Perhaps the biggest network security story of 2008 was the demonstration of a new attack that can insert false information into a DNS server’s cache. Upgrading DNS security is one of the major current challenges for ISPs²³.

The Secure Domain Name System (DNS) Deployment Guide²⁴ contains background information on DNS as it is used with IPv4, the possible attacks against DNS, and appropriate security measures. The Domain Name System – Security Technical Implementation Guide version 4r125 covers similar topics for Department of Defense (DoD) networks and also has advice on using DNS on particular computing platforms and operating systems. Both of these documents emphasize extensive experience with IPv4. Architecting and structuring DNS services is a complex topic that is outside the scope of this publication; extensive guidance about secure DNS services can be found in NIST SP (Special Publication) 800-81.

This section reviews the main aspects of DNS briefly to help understand the changes needed to make DNS work with IPv6 and how these affect the secure operation of DNS.

DNS is a hierarchical, distributed database that translates logical, human readable names such as www.example.com into binary IP addresses used by applications like email and web browsers. The most common format of a DNS name is referred to as the Uniform Resource Locator (URL), or simply as the web address. DNS database entries are called resource records²⁶. IPv4 and IPv6 addresses are different types of resource records, but the DNS handles both essentially the same. What is important to remember is that a single URL may have IPv4 addresses, IPv6 addresses, both, or neither.

DNS services are fully defined for IPv6 in RFC 3596. Additional information can be found in RFC 4472, Operational Considerations and Issues with IPv6 DNS. The root and common top-level domain (TLD) servers are all IPv6 capable today. Nevertheless, IPv6 addresses for production services usually cannot be found in the DNS, particularly for services based in the United States or North America. Most of these services do not have IPv6 access enabled, and most users would not have easy IPv6 connectivity to them if they were. Getting IPv6 DNS entries close to parity with IPv4 DNS on the Internet is unlikely to happen without demand for IPv6 access to popular, high-volume web sites and other services.

Most DNS implementations have been upgraded to support IPv6, but older software applications may assume that DNS address queries return only 32-bit IPv4 addresses. Fully IPv6-capable DNS implementations not only need to handle 128-bit IPv6 addresses but also need to run over IPv6 with the same UDP and TCP port number, 53, as used by IPv4 (RFC 3901, DNS IPv6 Transport Operational Guidelines)²⁷.

The primary components of DNS are the DNS root and TLD servers, authoritative DNS servers, local caching servers, and clients called resolvers. A resolver requests resource records from a local caching server. If the local caching server does not have a requested record, it uses the information it does have to start querying authoritative servers.

It is important to note that while IPv6 address queries may be made over an IPv4 or IPv6 network, IPv6 transport of DNS messages is not required for looking up IPv6 addresses in DNS. The query, not the transport protocol, should always determine what information is returned in the Answer, Authority, and Additional sections of a response. A host can request an IPv6 address even if the network on which that host resides is IPv4-only. To obtain both the IPv4 and IPv6 addresses, a single DNS query could be used, but it is recommended that two separate requests be used. The choice as to which protocol to use first is configurable. Hosts and DNS servers running both IPv4 and IPv6 should have no problem with this aspect of DNS, but all zones should be set up so that they have at least one IPv4-enabled authoritative server, and IPv6-only systems should follow or exceed the minimum configuration guidelines in RFC 3901 to ensure that they do not get cut off from the rest of the DNS tree because they cannot communicate with any IPv4-only DNS servers.

RFC 3596, DNS Extensions to Support IP Version 6, defines the changes needed to DNS to support IPv6.

A new resource record type, AAAA (pronounced quad-A), is defined to store a host’s IPv6 address. A 128-bit IPv6 address is encoded in the data portion of a AAAA resource record in network byte order (high-order byte first). A AAAA resource record stores a single IPv6 address, so a host with more than one IPv6 address may have more than one such record. AAAA queries for a specified domain name return all associated AAAA resource records in the answer section of a response.

A special domain is defined to look up names corresponding to an IPv6 address. The intent of this domain is to provide a reverse mapping of an IPv6 address to a host name (stored as a DNS PTR resource record). The domain is rooted at IP6.ARPA. An IPv6 address is represented as a name in the IP6.ARPA domain with a sequence of four-bit nibbles written as hexadecimal digits and separated by dots with the suffix IP6.ARPA. The sequence of 32 nibbles is encoded in reverse order, i.e., the low-order nibble is encoded first, followed by the next low-order nibble and so on. For example, the reverse lookup domain name corresponding to the address 2001:db8:2:3:4:5:678:90ab is:

b.a.0.9.8.7.6.0.5.0.0.0.4.0.0.0.3.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA

Note that zero suppression and double-colon compression cannot be used in reverse DNS names.

All existing query types that perform type A (IPv4 address) additional section processing, i.e., name server (NS), service location (SRV), and mail exchange (MX) query types, must be modified or redefined to perform both type A and type AAAA additional section processing. This means that a name server must add any relevant IPv4 addresses and any relevant IPv6 addresses available locally to the Additional Section of a response when processing any one of the above queries.

Several DNS implementations have been observed handling queries for AAAA records incorrectly, and these have been documented in RFC 4074. They may return the wrong data, wrong error codes, or nothing at all. Most of these errors result in unreachable services, delays, timeouts, or faulty assumptions by caching servers, but the RFC indicates places where these errors can also be exploited in denial-of-service attacks. In addition, some firewalls and Intrusion Detection Systems (IDSs) have experienced problems handling DNS responses that are larger than 512 bytes.

When performing a DNS address query, DNS is responsible only for resolving a domain name to a set of IP addresses. Applications and operating systems are responsible for choosing how to use the IPv6 AAAA or IPv4 A records that may be returned. This topic is called address selection, and it is an important part of using IPv6 and dual IPv4-IPv6 networks correctly. As a result, receiving unexpected AAAA records may cause an application that is not IPv6 aware to fail. Combining both IPv6 and IPv4 records into the same domain can lead to application problems that are beyond the scope of the DNS administrator. The Domain Name System – Security Technical Implementation Guide version 4r1 mentioned above recommends using different DNS names for IPv6-enabled hosts until all such problems (or at least the critical ones) are fixed. It also may be useful during pilot tests or early deployment to use names in separate domains for IPv6 servers, e.g., imap.IPv6.example.com, although one would like such names to handle IPv4 and IPv6 completely transparently in the long term.

A dual stack host needs a mechanism for choosing between IPv4 and IPv6. When DNS returns a set of different addresses, resolvers need to be configured either to choose which addresses to pass to an application or to forward all of the addresses and leave the choice to the application.

IPv6 link-local addresses should never be put into the DNS (and site-local addresses should not be used at all). Temporary (RFC 3041) addresses are usually meant to be anonymous, so putting them into DNS would be an unusual choice and would require frequent updates. Putting 6to4 addresses into DNS may be sensible, but one may need cooperation from a local or regional registry to set up the IP6.ARPA PTR records for 6to4 addresses and for other address formats with specific prefixes and embedded IPv4 addresses.

For additional details about adding DNS records for new services, handling time-to-live values in caches, obtaining a list of DNS servers when DHCPv6 is not used, updating forward (AAAA) and reverse (PTR) entries, handling dynamic DNS, and renumbering, see RFC 4472.

All of the general accounts of threats against DNS (RFC 3833) and advice for securing DNS, independent of IPv6, apply. This begins with host security and software security for DNS servers. It includes keeping up with new software releases, vulnerability alerts, and patches. The security of DNS servers can be improved with isolation, redundancy, geographic diversity, network path diversity, and potentially platform diversity. Administrative access should be controlled and secured. Tools for checking that a zone file is well formed or that other configuration variables are correctly set should be used. DNS servers should be included in any penetration testing exercises.

It is good practice to implement certain well-known security best practices, which rely on not divulging more information than necessary. The IP address of a hidden master server should not be advertised, nor should the DNS software version number, lest an attacker easily exploit bugs known to be in a certain release. Common implementations of DNS support access control lists based on IP addresses, and at least some of these support access control lists based on both IPv4 and IPv6 addresses. Address-based security is regarded as a rather weak form of authentication, particularly for important actions like DNS dynamic update, but nevertheless it is an efficient way to provide some protection if it is used together with ingress and egress address filtering. The widely-used technique of “split DNS,” whereby an enterprise’s DNS servers provide different answers to internal and external queries, can be used the same way with either A records or AAAA records.

Based on recent experiences, two attack scenarios are particularly likely. One is denial of service. Excess capacity and diversity help. Firewalls and intrusion detection systems can help protect a server located in a “demilitarized zone.” Administrators should be prepared to contact the appropriate emergency response teams and law enforcement agencies. RFC 5358 contains advice for configuring DNS servers to make using them as amplifiers in a denial-of-service attack against a third party more difficult.

The second scenario is so-called cache poisoning—inserting false information into a server’s cache, so that, for example, users may be misdirected to a bogus web site. This is an old idea, but a much more effective method for accomplishing it became well known in 2008. With or without cryptographic protection, the recommended remedy is to force the attacker to guess two randomly chosen 16-bit values simultaneously instead of just one (RFC 5452).

Two standard cryptographic protocols are available for securing DNS. They can be used equally with IPv4, IPv6, and combined IPv4-IPv6 implementations. DNSSEC, the DNS security extensions, is defined in three RFCs (RFC 4033, 4034, 4035), and TSIG, the Secret Key Transaction Authentication protocol is described in a fourth RFC (RFC 2845).

The TSIG protocol provides data origin authentication and message integrity for DNS transactions by adding message authentication codes based on shared secrets. Originally, only the HMAC-MD5 algorithm was specified, but TSIG now requires HMAC-SHA-1 and HMAC-SHA-256 as well (RFC 4635)²⁸. It can be used to authenticate dynamic updates as coming from an approved client, responses as coming from an approved recursive name server, or zone transfers as coming from an authoritative server. Its most common use is to protect zone transfers, but protecting dynamic updates is an important application as well.

TSIG is widely deployed and strongly recommended. Normally, network administrators use an out-of-band mechanism to configure name servers and resolvers with shared secrets. However, a secure, automated mechanism for key distribution and key update is a much more desirable solution. It simplifies operations and enhances security. The TKEY (Transaction Key) protocol (RFC 2930) offers several options—the Diffie-Hellman method is a practical choice. One limitation with TSIG is that there are no levels of authority, so any host with the secret key may update any record.

An alternative to TSIG called SIG(0) and described in RFC 2931 uses public keys and digital signatures instead of message authentication codes based on shared secrets. It is far less widely used than TSIG, but it may be a practical alternative especially for securing dynamic updates.

DNSSEC provides an entirely different set of cryptographic security mechanisms. Its objective is to secure the DNS database itself by deploying a hierarchical infrastructure of signed resource records and its own built-in public key infrastructure. It accomplishes this by defining four new types of resource record. The RRSIG resource record (RR) contains a digital signature of another resource record. The DNSKEY (Domain Name System Key) resource record contains a signature verification key; it, in turn, is signed with an RRSIG resource record. The DS (delegation signer) RR names the signer of a delegation. If DNSSEC is fully deployed, the DS records can form a chain from any zone to the root. The NSEC (next secure) resource record specifies the name of the next secured entry in a zone (in lexicographic order), so that the non-existence of a resource record can be verified cryptographically.

Besides its added complexity, especially for signing large zones, DNSSEC also increases the size of files and messages substantially. Also, administrators need to protect the secrecy of their private signing keys carefully. DNSSEC has not been deployed widely yet, but this is gradually changing. Newer releases of DNS software support DNSSEC, and plans are underway to sign the root and many major top-level domains. The US Government’s .gov root was signed in Feb. 2009, and OMB mandated²⁹ that the Government’s second-level domains should be signed by Dec. 2009. OMB Memorandum M-08-23 states: “The Government’s reliance on the Internet to disseminate and provide access to information has increased significantly over the years, as have the risks associated with potential unauthorized use, compromise, and loss of the .gov domain space. Almost every instance of network communication begins with a request to the Domain Name System (DNS) to resolve a human readable name for a network resource (e.g., www.usa.gov) into the technical information (e.g., Internet Protocol address) necessary to actually access the remote resource. DNSSEC provides cryptographic protections to DNS communication exchanges, thereby removing threats of DNS-based attacks and improving the overall integrity and authenticity of information processed over the Internet.” It is hoped that this will provide the impetus and experience necessary to get DNSSEC deployed for commonly used services and large enterprises throughout the Internet.

During any IPv6 deployment, DNS services may have to support both IPv4 and IPv6. In fact, DNS services should be among the first to be fully dual stack capable in any deployment effort. Software applications need to be modified to query for both forms of addresses and to choose between them. IPv4 may need to remain the network protocol between a caching server and authoritative DNS servers to ensure continuity of service. Many factors can affect network performance and availability during this conversion process, and these can impact both IPv4 and IPv6 access. DNS may supply AAAA records before services are fully turned on and reachable, and timeouts may occur. Applications may be unprepared to handle them. Caching resolvers may have to deal with A and AAAA records having different time-to-live values.

It is important to verify that client resolvers are receiving the correct responses and resource records. An ongoing testing phase for IPv6-capable DNS services is a necessary step during any organization’s IPv6 deployment process. When this process includes testing IPv6 application software, separate DNS servers and domain names should be used to support simultaneous IPv6 testing and operational IPv4 name resolution.

DNS responses with AAAA records are longer than similar IPv4 responses, because the records are simply larger than comparable A records and interfaces may have more than one IPv6 address in the DNS. Zone file transfer sizes will increase and, potentially, responses returning multiple AAAA resource records (e.g. MX requests) may require fragmentation. Since IPv6 fragments are discouraged, and sometimes are blocked, this could impact availability.

Some authoritative servers ignore queries for an AAAA record and cause a resolver first to wait and timeout and then to fall back to a query for an A record, which may cause a fatal timeout at the application that called the resolver. Even if the resolver and application eventually succeed, the result can be an unacceptable delay for the application’s user, especially with interactive applications like web browsing.

Advertising IPv6 addresses in DNS during the initial deployment requires additional care. Availability problems can easily arise if AAAA records are inserted into the DNS zone before IPv6 services are working. The recommendation is that AAAA records for a service should not be added to a DNS zone until the address is assigned to an interface on a host, the address is configured and enabled on the host’s interface, and finally the interface is on a link connected to the IPv6 infrastructure.

This chapter provides specific details about the status, requirements, capabilities, and security impacts of more advanced IPv6 topics such as multihoming, multicast, quality of service, mobile IPv6, jumbograms, address selection, DHCPv6, and IPv6 renumbering. As of the writing of this guide, some of these topics have not yet been fully specified or implemented and are not ready to deploy. In these cases, this is noted and interim methods are recommended where appropriate.

Multihoming means having the ability to utilize more than one connection to the Internet. A host, for example, may have more than one network connection (e.g., 100baseT and WiFi); a connection to a LAN with more than one router to the Internet on it; or a connection to a single router that has more than one Internet connection. Frequently, one refers to multihoming for an entire site, which may be a home, small office, or campus location within a large enterprise.

Multihoming is extremely useful but has a potentially large impact on the global Internet architecture. This section describes the motivations for multihoming, the problems it creates, the requirements for a good solution, potential solutions, and their security implications.

Users have several strong motivations for multihoming. First and foremost, having more than one Internet connection provides greater reliability and resiliency should one link fail or one ISP have a prolonged outage. Other reasons for multihoming include better performance (load balancing or QoS differentiation) and policy enforcement (including security policy).

While multihoming offers obvious advantages, it is complicated by another issue: the use of Internet addresses for two purposes. On the one hand, addresses are used for forwarding packets to the right location. On the other hand, they are used for identifying an endpoint, e.g., a transport protocol (TCP or UDP addresses plus port numbers) or IPsec security association (destination address plus security parameters index). For multihoming to work, either the entire Internet has to know multiple paths to a multihomed site, or the nodes at a site have to be able to use multiple addresses seamlessly and transparently. The former implies enormous growth in the Internet’s core forwarding tables. The latter implies that nodes have to cope with TCP connections, UDP responses, IPsec security associations, and other upper layer protocols (ULPs) tied to addresses.

Multihoming solutions also need to satisfy other requirements. They need to avoid causing problems with fragmentation, renumbering, and domain names. They need to scale to the size of the global Internet and not affect performance too greatly. They also need to work with firewalls and ingress filtering.

Any multihoming solution must satisfy two main goals. The first is to make multihoming transparent to upper layer protocols. Otherwise, multihoming is no better than changing service providers and renumbering one’s network manually. The second is to avoid causing explosive growth in the global routing and forwarding tables. Dealing with this growth is the number one challenge Internet engineers face today, with IPv4 or IPv6, with or without multihoming.

Compared with IPv6, IPv4 interfaces are normally limited to a single address, the entire supply of IPv4 network prefixes is much more limited, and the addresses themselves are four times shorter, all of which constrains the problem somewhat. IPv4 users with provider independent (PI) addresses can achieve fully transparent multihoming with resiliency and load balancing at the expense of global router table growth.

If NAT is used, resiliency is not transparent, and load balancing within a connection is impossible, so IPv6 multihoming without NAT potentially offers more powerful capabilities.

On the one hand, obtaining PI addresses is the most practical way to achieve IPv6 multihoming, whereas, on the other hand, the router table growth caused by IPv4 multihoming (frequently called CIDR address prefix de-aggregation) is problematical for the Internet, and it is a potentially overwhelming problem with IPv6. Therefore, provisioning IPv6 PI addresses has been a vigorously debated topic. Policies differ among the Regional Internet Registries (RIRs). The ARIN Number Resource Policy Manual³⁰ requires that an organization must be an end site and not a local registry and “qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA”.

Qualifying organizations may obtain a /48 PI IPv6 assignment. Until a solution both satisfying the global forwarding problem and providing host transparency is available, IPv6 sites needing multihoming and not qualifying for a PI assignment should attempt to get their primary ISP to accept /48 prefixes from secondary ISPs and thus achieve partial multihoming, although such requests may or may not be honored.

Several architectural approaches to IPv6 multihoming have been considered. These are described in detail in RFC 4177:

The most forward looking solutions to the multihoming problem introduce the notion of splitting an IP address into an identifier and locator. The idea is that upper layer protocols use the identifier, and core network routing and forwarding use the locator. Multihoming is accomplished by dynamically managing the bindings between the two. To make this work, protocols for establishing and maintaining these relationships must be provided. This requires protocol elements that update locator lists, switch locators in use, and so forth.

More than one proposal has been made along these lines, but the active standards track work on specifying split IPv6 identifiers and locators is called SHIM6 and is being done in the IETF’s SHIM6 Working Group. The name is derived from the way the additional address is specified in a shim header inserted into the packet.

SHIM6 (RFC 5533) is a network layer, host-based protocol to establish identifier-locator bindings. Its goals are³¹:

The general idea is to use IPv6 normally but, through SHIM6 signaling, set up alternative locators that can be used when needed. The steps, roughly, are:

An important design paradigm is that no new name space is needed. The SHIM6 protocol uses four IPv6 extension header messages called I1, I2, R1, and R2 to accomplish all of this. Figure 4-1 shows where the shim header fits into the IPv6 protocol stack.

Although the most promising work on IPv6 multihoming is SHIM6, this is likely to get much more discussion and revision. Some concerns about this approach have been expressed. In particular, it may be difficult to provide adequate traffic engineering with a host-based solution like SHIM6. For large enterprises with complex routed networks, site-based multihoming may be more useful. One example of site-based multihoming that is currently being considered within the IETF is the Locator/ID Separation Protocol (LISP)³². On large servers with many simultaneous connections, the overhead of maintaining SHIM6 state information may impact performance significantly.

Figure 4-1. SHIM6 Protocol Stack

RFC 4218 presents an overview of security vulnerabilities inherent in multihoming. In summary, one must be concerned about denial of service, re-routing packets to unintended destinations or black holes, and multicast issues. It advises, in general, that connectionless transport protocols like UDP present more security problems than connection-oriented transport protocols. Also, if identifiers and locators are split, security should be tied to the identifiers to lessen the impact of attacks on the identifier-locator binding. Securing other parts of the infrastructure such as the DNS and routing protocols helps minimize the potential attacks on multihoming. Multihoming solutions also need to account for and work with ingress filtering so that spoofed addresses can not be used to attack systems. (RFC 2827 and RFC 3704).

Networks need to ensure that they do not announce their prefixes in a way that generates asymmetric traffic flows. Traffic following asymmetrical paths might get blocked by strict Reverse Path Forwarding (RPF) checks or stateful packet filters. It may also make it impossible to implement IPsec at site border routers.

The SHIM6 protocol contains several security measures:

Packet filters may need to be aware of SHIM6 and modify their actions accordingly. First, along with upper layer protocol and port numbers, they may need to match on the upper layer identifiers as well as or instead of the IPv6 locator addresses. Second, they may need to understand when established sessions begin using shim headers or change locators.

Multicast refers to sending a packet to an IP address designated as a multicast address; one or more hosts specifically interested in the communication then receive a copy of that single packet. This differs from broadcast, which delivers packets to all hosts on a subnet, because multicast traffic is only sent to hosts subscribed to the multicast group. Multicasting is often used, for example, to stream audio and video more efficiently. Senders achieve two primary advantages by using multicast. First, the sender only needs to create and send one packet, instead of creating and sending a separate packet to each recipient. Second, the sender does not need to keep track of who the actual recipients are. Multicasting can also be advantageous from a network perspective, because it reduces network bandwidth consumption.

This section describes how multicast works in an IPv6 environment. In IPv6, broadcast has been eliminated and multicast takes on a much larger role. In addition to replacing broadcast, it also works with ICMPv6 neighbor discovery and router discovery on the local link to perform stateless address autoconfiguration and address resolution.

First, consider an example of how IPv6 multicast makes Neighbor Discovery in IPv6 more efficient than using ARP with IPv4. Running IPv4, when a host has an IP address on its own subnet and needs to know the corresponding link layer address, it broadcasts an ARP request containing the IPv4 address. Every host on the subnet gets a copy.

Suppose, running IPv6, an interface wants to find the link layer address for the link local IP address FE80::4DF2:54C8:B8C7:113A. It takes the low-order 24 bits of this address (C7:113A) and appends them to the well-known solicited node multicast prefix, FF02:0:0:0:0:1:FF00::/104 to form the solicited node multicast address FF02::1:FFC7:113A. Then it sends an ICMPv6 Neighbor Solicitation message to this multicast address. The message gets delivered to the interface at FE80::4DF2:54C8:B8C7:113A because it belongs to the multicast group FF02::1:FFC7:113A. Interfaces using any unicast or anycast address must join the solicited node multicast group corresponding to the above prefix and low-order 24 bits of their address. They use ICMPv6 Multicast Listener Discovery (MLD) to join a multicast group. The result is a more efficient address resolution procedure, in which a smaller number of hosts are queried to determine the address.

The solicited node multicast addresses range from FF02::1:FF00:0 to FF02::1:FFFF:FFFF, so the Neighbor Solicitation traffic is partitioned into 224 solicited node multicast groups. This makes receiving a Neighbor Solicitation intended for a different address highly unlikely.

IPv6 multicast addresses are easy to recognize. They always begin with eight 1 bits: FF. The next eight bits, 02 in this case, specify that this is a well-known multicast address with link local scope. Other examples of well-known multicast addresses with link-local scope are:

FF02::1 All Nodes FF02::2 All Routers FF02::1:2 All DHCP Agents

In addition to scoped multicast addresses, other features such as source-specific multicast have been added to IPv6. These different features and their applications are described below, and areas still needing work are noted (e.g., multicast with SHIM6 and IPsec).

In addition to providing an essential part of the IPv6 infrastructure, multicast applications include groupware, multimedia distribution, searching, routing, database replication, grid computing, and real-time information delivery.

With IPv6, multicast addresses have scope ranging from a single interface or link to the global Internet. They can be permanently assigned and well-known, as in the examples above, or they can be used transiently for specific purposes.

RFC 4291, IP Version 6 Addressing Architecture, defines a multicast address as: “An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address.” Normally, these are the addresses that have previously joined a given multicast group. The Multicast Listener Discovery (MLD) Protocol is the method interfaces use to join and leave multicast groups, and routers keep track of these groups for each interface on which they forward packets. Version 2 (MLDv2) (RFC 3810) manages multicast group membership with two ICMPv6 message types:

MLDv2 is backward compatible with MLDv1 (RFC 2710), so MLDv2 also supports:

All of these messages are sent with a link-local IPv6 source address (or the unspecified source address if necessary), an IPv6 Hop Limit of 1, and an IPv6 Router Alert option (RFC 2711) in a Hop-by-Hop Options header. (The Router Alert option forces routers to examine MLD messages sent to IPv6 multicast addresses in which the routers themselves previously had no interest.)

How routers actually implement multicast depends on the Layer 2 networking technology. It is trivial on point-to-point links; it may be implemented by using promiscuous mode on link layers with a natural broadcast capability; or it may require Layer 2 protocol logic on non-broadcast multi-access link layers.

The biggest change introduced in MLDv2 is Source Specific Multicast. MLDv2 allows an interface to specify, for each multicast address, from which source addresses it does or does not want to receive packets.

RFC 4604 updates MLDv2 and describes source-specific multicast for IPv4 (IGMPv3) and IPv6 (MLDv2) in a single document.

As stated above, IPv6 multicast addresses are easy to recognize. They are exactly the addresses beginning with eight 1 bits or hexadecimal FF:

| 8 | 4 | 4 | 112 bits +--------+----+----+--------------------------------/.../---------+ |11111111|flgs|scop| group ID | +--------+----+----+--------------------------------/.../---------+

The next eight bits in a multicast address specify the flags and scope. The final 112 bits in the multicast address are called the Group ID and are used to specify the set of nodes that are members of a multicast group. In a previous version, the Group ID was only 32 bits, and some implementations still stick to 32 bits.

In the IPv6 specification, multicast addresses always have a scope that limits the set of receiving nodes. The scope is the group of nodes for which the packet is intended relative to its source. Its values are shown in Table 4-1.

Table 4-1. IPv6 Scoped Multicast Values (from RFC 4291)

Some well-known multicast Group IDs are defined for variable scopes. A good example is the “All NTP [Network Time Protocol] Servers” address:

FF02::101 All NTP Servers Link Local FF04::101 All NTP Servers Admin Local FF05::101 All NTP Servers Site Local FF08::101 All NTP Servers Organization Local FF0E::101 All NTP Servers Global

RFC 2375 contains a list of well-known IPv6 multicast addresses categorized by scope, and that list has been extended by newer specifications. The complete and current version is at http://www.iana.org/assignments/ipv6-multicast-addresses.

The flags specify, first, whether a multicast address is a well-known, pre-defined address, or whether it is a transient address not permanently defined. Second, the flags specify whether a transient multicast address has an authorized and properly scoped unicast prefix embedded in it, and, if so, whether it also specifies a rendezvous point (RFC 3956). The unicast prefix eliminates the need for an additional protocol to allocate unique multicast addresses.

A rendezvous point for a multicast group is the root of a tree used with Protocol Independent Multicast— Sparse Mode (PIM-SM) (RFC 4601), a sophisticated multicast routing protocol. PIM-SM builds a tree of senders and group members. Then, traffic from senders is first routed upstream towards the rendezvous point and then downstream to group members (receivers).

For well-known multicast addresses, the four flag bits are always all zeros. The first flag bit is reserved and must be 0. The remaining three flag bits are called R, P, and T (for rendezvous, prefix, and transient) and are non-zero for transient multicast addresses:

+-+-+-+-+ |0|R|P|T| +-+-+-+-+

The flags are set as follows (see RFC 3306 and RFC 3956):

0 0 0 0 — Well-known, pre-defined multicast address (as in all of the examples above)

0 0 0 1 — Transient multicast address without an embedded unicast prefix

0 0 1 1 — Transient multicast address with an embedded unicast prefix and no rendezvous point

0 1 1 1 — Transient multicast address with an embedded unicast prefix and rendezvous point

This provides a simple way to allocate multicast addresses belonging to or allocated by a given network prefix in the following format, without adding any new multicast address allocation protocol:

| 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+--------+----------------+----------+ |11111111|flgs|scop|reserved| p-len | network prefix | group ID | +--------+----+----+--------+--------+----------------+----------+

The eight bits after the flags and scope must be zero. The next eight bits specify a prefix length, up to 64, followed by the prefix, left justified and zero filled.

This example comes from RFC 3306. The address FF38:0030:3FFE:FFFF:0001:0:1234:5678 is:

Note that the scope of such multicast addresses must not be greater than the scope of their embedded prefixes.

Although multicast addresses are common in both IPv4 and IPv6, several important differences exist:

IPv6 routers, packet filters, firewalls, and tunnel endpoints need to enforce multicast scope boundaries. Firewalls should inspect all source IPv6 addresses and filter any packets with a multicast source address. Furthermore, firewalls in Layer 3 mode should never forward link-layer multicast packets.

Attackers may take advantage of well-known multicast addresses to find hidden resources such as routers or particular servers. These addresses need to be blocked at the appropriate places according to local security policy.

Denial of service attacks may use multicast to amplify bandwidth consumption or attempt to exhaust other resources. So-called reflector attacks may send packets with a source address of the target of attack and a multicast destination address, to try to get all multicast receivers to respond to the target. These attacks need to be intercepted and dropped.

IPsec coverage for multicast is incomplete. If a multicast group has more than one sender, the replay protection mechanism does not work. More importantly, IKE is a unicast UDP protocol that only works between two parties, so automated key management for multicast IPsec is lacking. For additional details about using IPsec with IPv6 multicast, see Section 5.3.3.

Attacks on the MLD protocol include denial of service, causing unwanted traffic to be delivered, and downgrading capabilities from MLDv2 to MLDv1. By properly enforcing the unicast scope and hop count rules for MLD, these attacks can be confined to a local link.

Forging Protocol Independent Multicast (PIM) messages can cause unwanted traffic to be sent to replace the role of designated routers (RFC 5294). IPsec can be used for cryptographic protection of these messages. Cryptographically protecting PIM messages (RFC 5796) also stops many denial-of-service attacks. Other precautions include limiting the set of neighbors from which Join, Prune, Assert, and Hello messages are accepted. Routers should check that a valid Hello message was received first and that source addresses are legal for the interfaces on which they are received. See also RFC 4609 for a list of suggestions for rate limiting PIM messages, in particular, the inter-domain multi-source discovery protocol (MSDP).

Issues concerning how link-local ICMPv6 multicast traffic used for neighbor discovery and autoconfiguration can be secured are covered in Section 5.4.

IPsec and IKE were not designed with multicast security in mind, and three important unresolved aspects of multicast security are related to IPsec and key management for IPsec.

The fundamental IPsec security association architecture and protection protocols, ESP and AH, were designed mainly for unicast, and, although they work with multicast in principle, they are incompletely specified for multicast, and many open issues exist. (For example, what happens to a multicast security association when members join or leave the group?)

Key management for IPsec, provided by IKE, is inherently a two-party protocol. Different protocols for group key management have been proposed, but an agreed-upon and widely implemented standard for IPsec multicast key management has not emerged. Protocol specifications like PIM suggest using IPsec with manual keying, but this solution that does not scale well over time or space and has other limitations. For example, the IPsec replay detection feature is not supposed to be used with manual keying,

The security recommendations for PIM call for using IPsec AH, even for unicast messages. Where IPsec is used with IPv4, AH has generally fallen out of use in favor of ESP, with NULL encryption when authentication-only is desired. Thus the IPsec standard (RFC 4301) no longer requires AH, and many implementations omit it. See Section 5.3.6 for additional discussion of this topic.

The TCP/IP Network Layer—IPv4 and IPv6—was intentionally designed without any of the features normally associated with QoS such as admission controls; resource guarantees; and in-order, lossless delivery. QoS on TCP/IP networks or the Internet is a somewhat imprecise concept, which may have different meanings varying from “anything except undifferentiated best effort” to specific service level contracts between a provider and user. It may mean:

Many aspects of engineering QoS depend on technologies running at multiple layers, such as MPLS (MultiProtocol Label Switching) and ATM (Asynchronous Transfer Mode). IETF work on QoS for TCP/IP began with Integrated Services (intserv), which was designed to provide QoS guarantees. Intserv has been replaced with Differentiated Services (diffserv), which simply recognizes that different types of traffic have different QoS requirements and need to be marked accordingly. The signaling protocol (i.e., the protocol used for QoS setup and specification) to establish QoS requests is RSVP—Resource Reservation Protocol. IPv6 end-to-end addressing allows services that are difficult to deploy with NAT as well as end-to-end use of diffserv and RSVP. Many of these services may have real-time and multimedia content, so QoS is likely to become a more important topic with the widespread use of IPv6.

The notion of improved QoS has always been linked with IPv6. In fact, IPv6 was designed to support certain QoS improvements, but not all of these have been completely specified or implemented.

Several aspects of IPv6 implicitly or explicitly support QoS. These include:

The IPv6 Traffic Class field replaces the IPv4 Type of Service field. The original intent of the IPv4 Type of Service field has been replaced by diffserv (RFC 2474), which provides a use for the field. Although the RFCs are vague on this point, this is the way the IPv6 Traffic Class is usually used, and the functionality in IPv6 is equivalent to that in IPv4. Because of the way diffserv works, this field may be rewritten in transit. For example, RFC 2474 describes how packet marking is performed by traffic conditioners at network boundaries, including the edges of the network (first-hop router or source host) and administrative boundaries, and RFC 3168 sets aside two bits in this field called Explicit Congestion Notification for routers to indicate network congestion to end hosts.

When IPv6 QoS is mentioned, most frequently the last of these aspects, especially the Flow Label, is cited. Rudimentary use of the Flow Label is defined in RFC 1809 and RFC 3697. A Flow label value is always associated with a source and destination address pair with the same Hop-by-Hop options and Routing Header. (A zero value means that the field is not being used.) This has the advantage of specifying flows completely in the main header. It is not necessary to examine extension headers, upper layer protocols, and port numbers to identify the packet. RFC 3697 recommends that each new transport connection and application data stream be given a new value, and it requires that applications be able to specify this value. It stipulates that Flow Labels be delivered intact, and it gives rules for timeouts and reuse. Finally, it prohibits using specific bits or mathematical interpretations of the value—it is just a 20-bit label.

Many IPv6 implementations do choose different Flow Label values for each TCP connection, for example, but few if any make additional use of the field. Thus, realizing the potential for providing better QoS offered by the IPv6 Flow Label lies in finding improved ways to use this feature in the future.

The specific differences in QoS capabilities between IPv4 and IPv6 are covered point-by-point in the preceding section. The overall design of IPv6 is better thought out with respect to QoS; several specific improvements in IPv6 allow for more efficient network usage, and room has been left for additional QoS capabilities when these are defined.

One aspect is securing the QoS mechanisms themselves, to prevent theft of service, traffic analysis, or other attacks. For example, the Type of Service and Flow Label in the IPv6 header are not protected, even by AH. This is because the Type of Service can be altered while a packet is in transit. Although RFC 3697 specifies a nonalterable Flow Label field, when AH was originally designed, the Flow Label was also thought to be capable of alteration; the updated version of AH maintained that view for backwards compatibility. An application able to forge these fields may be able obtain preferred service fraudulently. If this is a major concern, IPsec can be run in tunnel mode, the QoS parameters can be copied from the inner header to the outer header, and the protected inner header can be compared with the outer header upon delivery.

Because the QoS fields in the outer header are not protected, firewalls cannot blindly trust the Type of Service and Flow Label alone for access control decisions. Also, traffic analysis may become simpler, because someone monitoring traffic flows can take advantage of the same efficiencies as legitimate routers forwarding traffic.

A different aspect is making sure that security does not impede the required QoS. QoS may need to be applied to packets secured with IPsec, in which case information about the upper layer protocols may not be accessible, but in this case, the methods in RFC 2207 can be used to differentiate IPsec-protected traffic. When planning to provide QoS, one must take into account that cryptographic protection, packet filtering, and examination by intrusion prevention systems all add some delay.

A third consideration is that securing QoS signaling protocols such as RSVP presents some difficulties, because these protocols often do not run strictly end to end but presume that intermediate points examine (or, worse, modify) the contents. For an overview of RSVP security, see RFC 4230.

Since the flow label field is currently for the most part unused, it could be used as a covert channel. Therefore, unless it is in use, its contents should always be zero.

General aspects of using Flow Labels have been specified, but details needed to take advantage of them are still missing. Because of the ways QoS depends on lower-layer protocols, it is unclear where and how progress on this front will be made.

IP-layer mobility has long been considered a useful and important feature, but today, with the exploding growth of laptop computers, PDAs, and mobile phones connecting to the Internet from more than one location, and, tomorrow, with the Internet in every motor vehicle and yet unimagined portable devices, it is becoming an essential ingredient in advanced services.

The work on Mobile IPv4 (MIPv4) envisioned many of the features and functions of Mobile IPv6 (MIPv6), but MIPv4 has never been practical on a large scale. The capabilities built into IPv6 make widespread use of MIPv6 practical: plentiful end-to-end addresses, security, optimized routing, increased reliability, and more. Thus, it is expected that use of mobility will increase with IPv6.

The central issue with IP mobility is the same as with multihoming: disconnecting from one network and reconnecting to another is easy; changing IP addresses while keeping one’s TCP connections, IPsec security associations, and streaming protocols running takes more work. Not surprisingly, MIPv4 and MIPv6 have common elements, but mobility is inherently a difficult problem, and MIPv6 involves quite a bit of sophisticated protocol design.

MIPv6 allows an IPv6 interface to disconnect and reconnect physically in an internet topology while logically retaining its “home” IPv6 address, so MIPv6 nodes can change their point of attachment to the network while maintaining seamless connectivity. The primary document describing MIPv6 is RFC

3775, Mobility Support in IPv6,33 but many other published RFCs and work still in progress support MIPv6.

As one might expect, MIPv6 has its own terminology, a certain amount of which is essential for understanding how it works. The most important terms are:

As with SHIM6, MIPv6 solves the problems created by using IP addresses for both identity and location. A MN’s identity is its HoA, and its location is its CoA. The goal is to establish and use bindings between these securely and efficiently, and the first step is for a MN to set up IPsec-secured communications with a HA. This may be done before leaving the home link. Figure 4-2 shows the main components of MIPv6.

Figure 4-2. The Main MIPv6 Components

To make this work, several functions must be provided, and these require underlying protocol elements. The four new protocol elements added for MIPv6 are: