This chapter discusses the following: Internet evolution and the need for IPv6, IPv6 in the IETF, Enterprise IPv6 deployment status, and IPv4 Address Exhaustion and the Workaround Options.
Excerpt from IPv6 for Enterprise Networks. | |
By Shannon McFarland, Muninder Sambi, Nikhil Sharma, and Sanjay Hooda Published by Cisco Press ISBN-10: 1-58714-227-9 ISBN-13: 978-1-58714-227-7 |
Newsletters: Sign-Up & Save Receive Special Offers, Free Chapters, Articles Reference Guide Updates.
This chapter discusses the following:
Internet evolution and the need for IPv6: This section focuses on the existing solutions that extend the life of the Internet and the advantages that IPv6 provides over other solutions. This section also outlines the IPv6 market drivers and the frequently asked questions/concerns about IPv6.
IPv6 in the IETF: As IPv6 goes mainstream, it is important for the standards bodies like IETF to standardize on these capabilities, which can be adopted across all network and computing devices.
Enterprise IPv6 deployment status: While many enterprises are looking to enable IPv6 or establish plans for the deployment of IPv6, some of the enterprise verticals such as Retail, Manufacturing, Web 2.0 and Enterprise IT organizations are leading the adoption both by enabling network and computing devices to support IPv6 and also enabling their business applications over IPv6.
The Internet has evolved from an internal distributed computing system used by the U.S. Department of Defense to a medium that enables enterprise business to be innovative and more productive in providing goods and services to its global customers. The Internet Protocol Suite (TCP/IP) is the underlying technology used to enable this communication.
Although the Internet has no centralized governance, it does have overarching organizations that help implement and maintain policy and operation of key Internet elements such as the IP address space and the Domain Name System (DNS). These critical elements are maintained and managed by the Internet Corporation for Assigned Names and Numbers (ICANN), which operates the Internet Assigned Numbers Authority (IANA). ICANN/IANA assigns unique identifiers for use on the Internet, which include domain names, Internet Protocol (IP) addresses, and application port numbers.
More information can be found at
- ICANN: http://www.icann.org
- IANA: http://www.iana.org
The Internet Engineering Task Force (IETF) (http://www.ietf.org), a nonprofit organization, standardizes the core protocols based on the technical expertise of loosely affiliated international participants. These protocols are used in all products that provide network connectivity, and individual product manufacturers provide a user interface to configure and use these protocols.
The IETF evaluated the growth of the Internet protocol with emphasis on addressing. The organization evaluated the following:
- Address space exhaustion: The IETF, along with industry participation from the IANA, the Regional Internet Registry (RIR), and the private sector, predict the exhaustion of the public IPv4 address pool by 2011.
- Expanding routing tables: The practice of classifying and allocating IP addresses based on classes has lead to an alarming expansion of the routing tables in the Internet backbone routers.
The next sections describe in more detail some of the issues surrounding IPv4 address exhaustion and options developed as temporary workarounds. You then learn how this lead the IETF to develop IPv6.
IPv4 Address Exhaustion and the Workaround Options
Without sufficient global IPv4 address space, hosts are forced to work with mechanisms that provide the capability for an internal (private) IP address space to be translated to a smaller or single externally routable IP address space. Network Address Translation (NAT) enables multiple devices to use local private addresses (RFC 1918) within an enterprise while sharing one or more global IPv4 addresses for external communications. Although NAT has to some extent delayed the exhaustion of IPv4 address space for the short term, it complicates general application bidirectional communication. These workarounds have resulted in the following:
- Establishing gateways, firewalls, and applications that require specialized code to deal with the presence of NAT/PATs (for example, NAT transparency using UDP)
- Mapping of standard ports to nonstandard ports (port forwarding)
Establishment and use of NAT workaround code (STUN, TURN, ICE, and so on)
- Nested NAT/PAT addresses
- Complexity of the supporting infrastructure, applications, and security
- Complexity of installing and managing multiple address pools
- More time, energy, and money spent coding and managing the workaround
- Inability to easily identify all connected devices on an organization's network
Note - Sensors, even inline, might not be completely successful at dropping packets of an attack. An attack could be on its way, if only partially, before even an inline sensor starts dropping packets matching a composite pattern signature. The drop action is much more effective for atomic signatures because the sensor makes a single packet match.
Note - It took 40 years for radio to achieve an audience of 50 million; it took 15 years for TV and just 5 years for the Internet!
IPv6 is designed to replace IPv4. It enables an unimaginably large number of addresses and brings with it easier network management, end-to-end transparency, and the opportunity for improved security and mobility, as discussed in the following section.
IPv6 Market Drivers
IPv6 helps open doors for new revenue stream opportunities by enabling new applications and enabling enterprises to expand their businesses globally. The four primary factors driving IPv6 adoption, as illustrated in Figure 1-1, include
- IPv4 address considerations
- Government IT strategy
- Infrastructure evolution
- Operating system support
The following sections describe the key market drivers shown in Figure 1-1.
IPv6 Market Drivers
IPv4 Address Considerations
The following IPv4 address considerations drive the need for IPv6:
- IPv4 address depletion: The growing number of applications and global users are fueling the demand for IP addresses. The number of devices that are "always on," such as smartphones, Internet appliances, connected automobiles, integrated telephony services, media centers, and so on, are also increasing. IPv4 provides 4.2 billion (4.294 x 109) addresses. In today's global and mobile world, it is only a matter of time before IPv4 addresses are exhausted. Although the primary reason for IPv4 address exhaustion is the insufficient capacity of the original Internet infrastructure, new business drivers including globalization, the explosion of mobile devices, virtualization, and mergers and acquisitions have pushed the IPv4 technology to a limit where we need to evaluate new technologies like IPv6 to further extend the life of the Internet.
- Globalization: The network today enables all enterprise business transactions. As enterprises move into emerging markets to expand their business, the network needs to grow, and more IP addresses need to be allocated.
- Mobile devices: Because the cost of embedding substantial computing power into handheld devices dropped, mobile phones have become viable Internet hosts and increase the need for addressing.
- Inefficient address use: Organizations that obtained IP addresses in the 1980s and early 90s were often allocated far more addresses than they actually required. For example, large companies or universities were assigned class A address blocks with more than 16 million IPv4 addresses each. Some of these allocations were never used, and some of the organizations that received them have diminished in size, whereas other organizations then left out of these large address block assignments have expanded.
- Virtualization: A physical system can now host many virtual systems. Each of these virtual systems might require one or multiple IP addresses. One example is with Virtual Desktop Infrastructure (VDI) and the deployment of Hosted Virtual Desktops (HVD).
- Mergers and acquisitions (M&A): When one company acquires or merges with another, this often causes a conflict or "collision" in the RFC 1918 IPv4 private addressing scheme. For example, one company might run a 10.x.x.x address space, and the company it acquires might also use this same address space (as seen in Figure 1-2). Many companies deploy a NAT overlap pool for a period of time, where both companies communicate with each other over a nonoverlapping address space such as 172.16.x.x. This enables the hosts at both companies to communicate until one of the sites is readdressed.
IPv6 Overlay Model - Resolving M&A Address Collision
IPv6 is used in this scenario to help ease the M&A burden of colliding address spaces by the deployment of an "overlay" network using IPv6, where critical systems and hosts are enabled for IPv6 operation and communicate with each other over this overlay network. This enables the rapid connection of hosts while buying time for the IT staff to either readdress one company's IPv4 network or to better deploy a dual-stack IPv6 network at both companies.
Government IT Strategy
National IT strategies and government mandates across the globe have caused many enterprises and service providers to implement IPv6 to better support these government agencies (that is, private-sector companies working with government agencies). One example of how a government mandate influences the private sector to deploy IPv6 is when multiple U.S.-based defense contractors rapidly started their planning and deployment of IPv6 to support the U.S. federal IPv6 mandate of June 30, 2008. Many of these companies not only peer with federal agency networks but also provide IP-enabled services and products that would one day require IPv6.
Infrastructure Evolution
The underlying infrastructure for the Internet, and emerging developments in verticals such as energy management, power distribution, and other utility advancements, have matured and grown in size to the point of applying pressure to existing technologies, products, and IPv4. The evolution of technologies in SmartGrid, broadband cable, and mobile operators now require more and more devices to connect to the Internet. Regardless of the use case or technology, all these maturing technologies and use cases either already or soon will depend on IP as their means of communication. IPv4 cannot support these demands, and IPv6 is the way forward for each of these areas of development.
Operating System Support
All widely deployed operating systems support IPv6 by default. These operating systems enable IPv6 addresses by default, thereby accelerating the adoption of IPv6 in enterprises. Key operating systems include Microsoft Windows 7, Server 2008, Apple Mac OS X, and Linux. Many enterprises are finding that IPv6 is used on their networks without their knowledge because of the default preference of IPv6 over IPv4. IT staff realize that they must understand and implement IPv6 in a managed way to control the behavior of IPv6, but also to embrace the capabilities of IPv6.
Summary of Benefits of IPv6
Market drivers or initiatives that often occur externally to the enterprise are at times forced upon an enterprise from the industry they are in or by other external forces (for example, Internet IPv4 address exhaustion), whereas others are beneficial to the enterprise based on business or technical advantages. Table 1-1 summarizes a few of the many benefits for an enterprise to deploy IPv6. Several of these have been talked about in this chapter already, and many will be expanded upon throughout this book.
Table 1-1 Benefits of IPv6
Technical Benefits of IPv6 | Details |
Abundance of IP addresses | This is the most significant benefit that IPv6 provides over IPv4. An IPv6 address is made up of 128-bit values instead of the traditional 32 bits in IPv4, thereby providing approxunately 340 trillion trillion trillion globally routable addresses. |
Simpler address deployment | IP address assignment is required by any host looking to communicate with network resources. This IP address has traditionally been assigned manually or obtained through DHCP. In addition to manual and DHCP address assignment, IPv6 inherently enables autoconfiguration of addressing through Stateless Address Autoconfiguration (SLAAC), which can make the deployment of IP-enabled endpoints faster and more simplistic. SLAAC is commonly used for configuring devices that do not need end-user access. These devices include network sensors on cars, telemetry devices, manufacturing equipment, and so on. For user-connected hosts including desktops and servers, the lack of DNS information in the router advertisement limits the deployment of SLAAC. The IETF community has put together an experimental draft (RFC 5006) that extends the router advertisement messages (RA messages) to include DNS information. There is also active engagement in the standards body to standardize RA extensions to not only include DNS server information but also to include NTP, BOOTP, and vendor-specific DHCP options. Depending on the host operating system implementation, when an IPv6 network adapter is activated, it assigns itself an IP address based on a well-known prefix and its own MAC address. The new host uses its automatic configuration mechanism to derive its own address from the information made available by the neighboring routers, relying on a protocol called the neighbor discovery (ND) protocol. This method does not require any intervention on the administrator's part, and there is no need to maintain a central server for address allocation-an additional advantage over IPv4, where automatic address allocation requires a DHCP server. |
End-to-end network connectivity integrity | With IPv4 NAT, a single address masks thousands of nonroutable addresses, making end-to-end integrity unachievable. With the larger address space available with IPv6, the need for Network Address Translation devices is effectively eliminated. |
Opportunity for enhanced security capabilities com-pared to IPv4 | Although rarely deployed today, IPv6 has built-in security capabilities with built-in IPsec support, which can enable end-to-end control packet (routing adjacencies, neighbor discovery) encryption between two or more hosts. For data plane encryption of IPv6 flows, it relies on existing IPv4 mechanisms like IPsec. |
Improved attribute extension headers for security, QoS, and encryption | IPv6 has extension attribute headers that are not part of the main packet header. These extension headers, with their own unique packet structures, help provide encryption, mobility, optimized routing, and more. When needed, these headers are inserted between the basic IPv6 header and the payload. The basic IPv6 header includes an indication as to the presence of extension headers through the Next Header field. This vastly speeds the router packet-forwarding rates and improves efficiency. |
Improved mobility | Mobile IP (MIP) was developed to ensure that the original gateway is made aware when a host moves from one network segment to another. Originally with MIP (IPv4 based), all the traffic to and from the mobile device needs to go back to the original gateway (home gateway); this is called "triangular routing." MIP has been extended in IPv6 to overcome this inefficient triangulation. In MIPv6, a foreign correspondent server is continuously updated as to the network the device is on and which gateway to use to reach the traveling device. The bulk of the packets flow directly between the mobile device and its communicators, and not through the home address. This process is known as direct routing. This reduces cost and vastly improves performance and reliability. |
Improved flow resource allocation with flow labels | All the Differentiated Services (DiffServ) and Integrated Services (IntServ) quality of service (QoS) attributes from IPv4 are preserved in IPv6. In addition, IPv6 also has a 20-byte Flow Label field that can be used by the end application to provide resource allocation for a particular application or flow type. Even though the standards bodies have defined flow labels in IPv6, not many enterprise applications tend to leverage this capability. |
Commonly Asked Questions About IPv6
IPv6 has been on the way for more than 10 years now, yet for much of the world, it has been irrelevant until recently. Now, as the shortage of IPv4 addresses begins to become obvious to even the most hardened skeptic, awareness and interest are growing.
The following sections address some commonly asked questions or myths that have been created over time with respect to IPv6.
Does My Enterprise Need IPv6 for Business Growth?
This is the most commonly asked question, especially because most organizations continue to connect to the Internet without IPv6 today. There are three key reasons why organizations might need IPv6:
- Need for a larger address space (beyond IPv4) for business continuity and growing globally.
- IPv6 is also a generator of new opportunities and a platform for innovation. There are still classes of network applications that aren't possible with IPv4-for example, vehicle-mounted telemetry, which might involve millions of networked sensors on cars.
- IPv6 is on by default in operating systems like Windows 7 and Linux.
Growth countries like India and China, with huge populations and burgeoning technical competence, will almost certainly move to IPv6 directly. Enterprises that want to be active in those markets but do not use IPv6 will be at a competitive disadvantage.
Will IPv6 Completely Replace IPv4?
IPv6 and IPv4 will continue to operate for a long time before the entire infrastructure is moved to IPv6 only. Enterprises and service providers have made significant investments in IPv4 and are well versed with the IPv4 technology.
As IPv6 adoption grows, enterprises need to invest in solutions that enable their legacy IPv4 domains to seamlessly and effectively communicate with IPv6 domains, thereby providing better return on investment. In summary, enterprises looking to adopt IPv6 do not need to discard their IPv4 infrastructure but instead should leverage transition technologies to enable them to coexist.
Is IPv6 More Complicated and Difficult to Manage and Deploy Compared to IPv4?
The larger IP address space provided by IPv6 has created a perception for network architects and administrators that IPv6 is more complicated compared to IPv4; this is not true. The vast address space equips architects to no longer reconfigure their limited address space, making network designs much easier.
All ancillary protocols like DNS continue to work pretty much the same for IPv4 and IPv6. In addition, IPv6 has better autoconfiguration and multicast capabilities (with embedded rendezvous point) that are simpler in implementation compared to IPv4.
There are some new ancillary protocols, such as multicast listener discovery and neighbor discovery, but for the most part, these replace similar mechanisms in IPv4.
Other than IPv6 addressing being in hexadecimal format, it is easier to perform address allocation planning and deployment because the focus is no longer on the number of hosts, but rather on the number of links or "subnets" allocated out of the address block. In many ways, IPv6 is just IP with a higher version number. Similar to IPv4, the IPv6 addressing plan would still need to be designed to ensure that there are natural points of address summarization in the network.
For the entire IT department (including network, computing, storage architects and administrators, application developers, and so on) to leverage IPv6 capabilities, an investment is needed to train them on this upcoming technology.
Does IPv6 continue to allow my enterprise network to be multihomed to several service providers?
Prior to 2007, IPv6 address allocation policies were strictly hierarchical and allowed only enterprises to obtain a network address from a single service provider to avoid overlapping the global routing table.
This has changed since 2007, where enterprises can now get provider-independent (PI) allocations similar to that of IPv4. When an organization applies for PI space, it can obtain IPv6 address space that is not tied to any provider.
By getting provider-independent allocations, enterprises can continue to build redundant, reliable solutions similar to their existing IPv4 designs.
However, many new elements are in development and policy changes are being discussed in the industry that can impact how multihoming is done with IPv6. Today there are unanswered questions related to this topic, and the reader should watch the standards bodies and contact their service providers as time goes on to stay updated on these changes.
Is quality of service better with IPv6?
The only QoS mechanisms built into IPv6 are a few header fields that are supposed to be used to distinguish packets belonging to various classes of traffic and to identify related packets as a "flow." The intention is that these header fields should enable devices such as routers to identify flows and types of traffic and do fast lookups on them. In practice, the use of these header elements is entirely optional, which means that the vast majority of devices don't bother with anything other than the bare minimum support required.
However, IPv4 has similar header elements, intended to be used in similar ways, so the claim that IPv6 QoS is better than that in IPv4 is tenuous.
Is IPv6 automatically more secure than IPv4?
It would be more accurate to say that IPv6 is no less or no more secure than IPv4; it is just different. The main security-related mechanism incorporated into the IPv6 architecture is IPsec. Any RFC-based, standards-compliant implementation of IPv6 must support IPsec; however, there is no requirement that the functionality be enabled or used. This has led to the misconception that IPv6 is automatically more secure than IPv4. Instead, it still requires careful implementation and a well-educated system and network staff.
Does the lack of NAT support in IPv6 reduce security?
This is mostly a myth because NAT increases security. NAT exists to overcome a shortage of IPv4 addresses, and because IPv6 has no such shortage, IPv6 networks do not require NAT. To those who see NAT as security, this appears to mean a reduction in the security of IPv6. However, NAT does not offer any meaningful security. The mind-set of "security through obscurity" is mostly an outdated concept because the vast majority of attacks do not occur through directly routable IP-based methods from the Internet into the inside enterprise but rather through Layers 4-7 attacks. IPv6 was designed with the intention of making NAT unnecessary, and RFC 4864 outlines the concept of Local Network Protection (LNP) using IPv6; this provides the same or better security benefits than NAT.
IPv6 in the IETF
Since 1995, the IETF has actively worked on developing IPv6-related IETF drafts and RFCs in various working groups to include the following:
- Applications area
- Internet area
- Operations and management area
- Real-time applications and infrastructure area
- Routing area
- Security area
- Transport area
Some of the most active areas for IPv6 standardization have occurred in the Internet, operations and management, and transport areas. These areas have been and many still are quite active in the development of standards around addressing, deployment, management, transition, and security of IPv6. It is critical for implementations of IPv6 and its associated architectural components to be based on standards to ensure interoperability between vendors.
The IETF drafts and RFCs are numerous and change or are updated frequently. Research, read, and understand what is happening in the IETF and other standards organizations to be prepared for changes related to IPv6. You an find more information at http://www.ietf.org.
In addition to the IETF, the IPv6 Forum has also developed an IPv6 Ready logo program that certifies IT infrastructure (networking, computing, and storage) with respect to IPv6 conformance and interoperability testing. The key idea of this program is to increase user confidence by demonstrating that IPv6 is available now and is ready to be used. The IPv6 Ready Logo Committee defines conformance and interoperability test specifications to enable different vendors to certify their products toward IPv6 readiness. Additional details of the IPv6 Ready logo and certified products can be found at http://www.ipv6ready.org.
Enterprise IPv6 Deployment Status
With more than 15 years of standards body representation and 10 years of development, IPv6 is now adopted by many large service providers and enterprises. Today, IPv6 is a robust and mature protocol that enables revitalization and innovation of new applications.
IPv6 deployment is happening across many vertical industries, as shown in Table 1-2.
Table 1-2 IPv6 Deployment Across Vertical Markets
Vertical Market | Examples |
Higher education and research | Building sensors Media services Collaboration Mobility |
Manufacturing | Embedded devices Industrial Ethernet IP-enabled components |
Government (federal/public sector) | Department of Defense Warfighter Information Network-Tactical (WIN-T) Future Combat System (FCS) Joint Tactical Radio System (JTRS) Global Information Grid Bandwidth Expansion (GIG-BE) |
Transportation | Telematics Traffic control Hotspots Transit services |
Finance | Merger & acquisition - overlay networks |
Healthcare | Home care Wireless asset tracking Imaging Mobility |
Consumer | Set-top boxes Internet gaming Appliances Voice/video Security monitoring |
Utilities | SmartGrid IP Services over Powerline |
Originally, IPv6 was seen only in the research and vendor areas, where the first implementations of IPv6 were worked out. Since then, IPv6 deployment has grown into every vertical, some with specific use cases, such as sensor networks, robotic arms, environment controls, and sensors, whereas other use cases are similar in nature regardless of the vertical.
Most enterprises fall into one of three categories, as shown in Figure 1-3.
Enterprise Adoption Categories
The first category is often called the preliminary research phase. Here the enterprise is researching whether IPv6 is real, the advantages of IPv6, how it fits into its environment, preliminary product gaps, and costs of deploying. This phase involves educating the company leadership about the relevance of IPv6 to meet its evolving business needs through online details. For the technical IT group, the research phase involves understanding the IPv6 protocol and its dependencies on its existing infrastructure achieved through working labs, classroom education, and labwork. Many enterprises in this phase are not sure whether IPv6 is relevant to them.
The second category is the pilot/early deployment phase, where most of the "why" has been answered or at least a decision has been made to move forward with IPv6 deployment regardless of a clear business justification for it. Often many consider IPv6 deployment without a clear business case as a "getting our house ready for an unknown guest" undertaking. Many who lived though the early VoIP and IP telephony days recall how unprepared they were for the massive paradigm shift brought on by these technologies and that they did not have their networks enabled for high availability (at least high enough for voice) and QoS. Investing in IPv6 through time, energy, and budget before having a defined business case is often an endeavor in preparing for the unknown or, arguably, the evitable. More serious assessments are made, training has begun, and serious conversations with non-IPv6-compliant product vendors are happening in this phase.
Finally, the third category is the production phase, where the enterprise is looking for a high-quality production IPv6 deployment. At this point, it is moving most, if not all, IT elements to IPv6, and the mind-set is parity with what the enterprise has with IPv4 or is at least good enough to not interfere with the business. The business might still be dealing with noncompliant products or vendors, but most of that has been dealt with by getting rid of those without a strong road map. It is down to doing business as usual but also focusing on using IPv6-enabled applications and services as a competitive advantage.
Throughout the entire process, constant education happens on both the technical and business side, and at each step of the process, there must be continuous buy-in from all groups involved.
Historically there have been deployment challenges with IPv6 adoption, especially because enterprises would not deploy given that there were only a small subset of products supporting IPv6 and not many service providers had IPv6 deployed at their peering points. The service providers would not support it because no enterprises were asking for it, or there were too few products supporting it. Vendors were not building products to support it because there were no enterprises or service providers asking for it. It was and in some cases still is an ugly, vicious circle that can only be broken by innovators and leaders who step out first.
From a content provider perspective, one of the leaders and best deployments for IPv6 is Google, which has launched its "trusted adopter" program: http://www.google.com/ipv6. Other content providers and industry-leading websites are already IPv6-enabled for those hosts who support reaching them through IPv6. Some sites include Google (search and Gmail), YouTube, Netflix, Comcast, and Facebook.
Contrary to trade magazines, blogs, vendors, and skeptics, enterprises have already and are currently deploying IPv6. Many companies do not advertise that they are deploying IPv6, leading to the misconception that deployments are not occurring. Many companies are secretive about IPv6 deployment for security reasons (not knowing what all the attack vectors are and not having robust enough security measures in place), others for financial reasons. The remaining chapters in this book discuss these concerns and outline important deployment considerations.
Summary
IPv6 is the next-generation protocol for the Internet that overcomes the address limitations of IPv4 and removes or reduces the cases for NAT/PAT as they are used today. The key market driver for IPv6 is the abundance of IP addresses. This enables business continuity and opens the door for new applications across the Internet.
The IETF and other organizations continue to evaluate solutions and generate drafts and RFCs to ensure the interoperability of IPv6-enabled hosts.
The majority of service providers and content providers, and many enterprises, are planning, deploying, or have deployed IPv6 within their network infrastructure to future-proof them for new applications.
This book focuses on providing enterprises and service providers with a design framework to assist them in moving to IPv6 through a smooth transition with existing transition technologies and describes ways of integrating IPv6 into their existing infrastructures.
Additional References
Many notes and disclaimers in this chapter discuss the need to fully understand the technology and protocol aspects of IPv6. There are many design considerations associated with the implementation of IPv6 that include security, QoS, availability, management, IT training, and application support.
The following references are a few of the many that provide more details on IPv6, Cisco design recommendations, products and solutions, and industry activity:
Aoun, C. and E. Davies. RFC 4966, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status." http://www.rfc-editor.org/rfc/rfc4966.txt.
Cerf, Vinton G. "A Decade of Internet Evolution." http://bit.ly/cNzjga.
Curran, J. RFC 5211, "An Internet Transition Plan." http://www.rfc-editor.org/rfc/rfc5211.txt.
IANA: http://www.iana.org.
ICANN: http://www.icann.org.
IETF: http://www.ietf.org.
IETF Behavior Engineering for Hindrance Avoidance (behave) drafts: https://datatracker.ietf.org/wg/behave.
IPv6 address report: http://www.potaroo.net/tools/ipv4.
Jeong, J., S. Park, L. Beloeil, and S. Madanapalli. RFC 5006, "IPv6 Router Advertisement Option for DNS Configuration." http://www.rfc-editor.org/rfc/rfc5006.txt.
Rekhter, Y., B. Moskowitz, D. Karrenberg, J. de Groot, and E. Lear. RFC 1918, "Address Allocation for Private Internets." http://www.rfc-editor.org/rfc/rfc1918.txt.
Van de Velde, Hain, Droms, Carpenter, and Klein. RFC 4864, "Local Network Protection for IPv6." http://www.rfc-editor.org/rfc/rfc4864.txt
© Copyright Pearson Education. All rights reserved.