RFC 7381
Enterprise IPv6 Deployment Guidelines
Pages: 34
Informational
Informational
Part 2 of 2 – Pages 17 to 34
3. External Phase
The External Phase for enterprise IPv6 adoption covers topics that deal with how an organization connects its infrastructure to the external world. These external connections may be toward the Internet at large or to other networks. The External Phase covers connectivity, security and monitoring of various elements, and outward-facing or accessible services.
3.1. Connectivity
The enterprise will need to work with one or more service providers to gain connectivity to the Internet or transport service infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] and [RFC4659]. One significant factor that will guide how an organization may need to communicate with the outside world will involve the use of PI and/or PA IPv6 space. Enterprises should be aware that, depending on which address type they selected (PI vs. PA) in their planning phase, they may need to implement new routing functions and/or behaviors to support their connectivity to the ISP. In the case of PI, the upstream ISP may offer options to route the prefix (typically a /48) on the enterprise's behalf and update the relevant routing databases. Otherwise, the enterprise may need to perform this task on their own and use BGP to inject the prefix into the global BGP system. Note that the rules set by the RIRs for an enterprise acquiring PI address space have changed over time. For example, in the European region, the RIPE-NCC no longer requires an enterprise to be multihomed to be eligible for an IPv6 PI allocation. Requests can be made directly or via a LIR. It is possible that the rules may change again and may vary between RIRs. When seeking IPv6 connectivity to a service provider, native IPv6 connectivity is preferred since it provides the most robust and efficient form of connectivity. If native IPv6 connectivity is not possible due to technical or business limitations, the enterprise may utilize readily available transition tunnel IPv6 connectivity. There are IPv6 transit providers that provide robust tunneled IPv6 connectivity that can operate over IPv4 networks. It is important to understand the transition-tunnel mechanism used and to consider that it will have higher latency than native IPv4 or IPv6, and may have other problems, e.g., related to MTUs. It is important to evaluate MTU considerations when adding IPv6 to an existing IPv4 network. It is generally desirable to have the IPv6 and IPv4 MTU congruent to simplify operations (so the two address families behave similarly, that is, as expected). If the enterprise uses transition tunnels inside or externally for IPv6 connectivity, then modification of the MTU on hosts/routers may be needed as mid- stream fragmentation is no longer supported in IPv6. It is preferred that Path MTU Discovery (pMTUD) be used to optimize the MTU, so erroneous filtering of the related ICMPv6 message types should be monitored. Adjusting the MTU may be the only option if undesirable upstream ICMPv6 filtering cannot be removed.
3.2. Security
The most important part of security for external IPv6 deployment is filtering and monitoring. Filtering can be done by stateless ACLs or a stateful firewall. The security policies must be consistent for IPv4 and IPv6 (or else the attacker will use the less-protected protocol stack), except that certain ICMPv6 messages must be allowed through and to the filtering device (see [RFC4890]): o Packet Too Big: essential to allow Path MTU discovery to work o Parameter Problem o Time Exceeded In addition, NDP messages (including Neighbor Solicitation, RAs, etc.) are required for local hosts. It could also be safer to block all fragments where the transport layer header is not in the first fragment to avoid attacks as described in [RFC5722]. Some filtering devices allow this filtering. Ingress filters and firewalls should follow [RFC5095] in handling routing extension header type 0, dropping the packet and sending ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case, ignore the header). If an IPS is used for IPv4 traffic, then an IPS should also be used for IPv6 traffic. In general, make sure IPv6 security is at least as good as IPv4. This also includes all email content protection (anti- spam, content filtering, data leakage prevention, etc.). The edge router must also implement anti-spoofing techniques based on [RFC2827] (also known as BCP 38). In order to protect the networking devices, it is advised to implement control plane policing as per [RFC6192]. The potential NDP cache exhaustion attack (see [RFC6583]) can be mitigated by two techniques: o Good NDP implementation with memory utilization limits as well as rate limiters and prioritization of requests. o Or, as the external deployment usually involves just a couple of exposed statically configured IPv6 addresses (virtual addresses of web, email, and DNS servers), then it is straightforward to build an ingress ACL allowing traffic for those addresses and denying traffic to any other addresses. This actually prevents the attack
as a packet for a random destination will be dropped and will
never trigger a neighbor resolution.
3.3. Monitoring
Monitoring the use of the Internet connectivity should be done for
IPv6 as it is done for IPv4. This includes the use of IPFIX
[RFC7012] to report abnormal traffic patterns (such as port scanning,
SYN flooding, and related IP source addresses) from monitoring tools
and evaluating data read from SNMP MIBs [RFC4293] (some of which also
enable the detection of abnormal bandwidth utilization) and syslogs
(finding server and system errors). Where NetFlow is used, Version 9
is required for IPv6 support. Monitoring systems should be able to
examine IPv6 traffic, use IPv6 for connectivity, and record IPv6
addresses, and any log parsing tools and reporting need to support
IPv6. Some of this data can be sensitive (including personally
identifiable information) and care in securing it should be taken,
with periodic purges. Integrity protection on logs and sources of
log data is also important to detect unusual behavior
(misconfigurations or attacks). Logs may be used in investigations,
which depend on trustworthy data sources (tamper resistant).
In addition, monitoring of external services (such as web sites)
should be made address specific, so that people are notified when
either the IPv4 or IPv6 version of a site fails.
3.4. Servers and Applications
The path to the servers accessed from the Internet usually involves
security devices (firewall and IPS), server load balancing (SLB), and
real physical servers. The latter stage is also multi-tiered for
scalability and security between presentation and data storage. The
ideal transition is to enable native dual stack on all devices; but
as part of the phased approach, operators have used the following
techniques with success:
o Use a network device to apply NAT64 and basically translate an
inbound TCP connection (or any other transport protocol) over IPv6
into a TCP connection over IPv4. This is the easiest to deploy as
the path is mostly unchanged, but it hides all IPv6 remote users
behind a single IPv4 address, which leads to several audit trail
and security issues (see [RFC6302]).
o Use the server load balancer, which acts as an application proxy
to do this translation. Compared to the NAT64, it has the
potential benefit of going through the security devices as native
IPv6 (so more audit and trace abilities) and is also able to
insert an HTTP X-Forward-For header that contains the remote IPv6
address. The latter feature allows for logging and rate limiting
on the real servers based on the IPV6 address even if those
servers run only IPv4.
In either of these cases, care should be taken to secure logs for
privacy reasons and to periodically purge them.
3.5. Network Prefix Translation for IPv6
Network Prefix Translation for IPv6, or NPTv6 as described in
[RFC6296], provides a framework to utilize prefix ranges within the
internal network that are separate (address independent) from the
assigned prefix from the upstream provider or registry. As mentioned
above, while NPTv6 has potential use cases in IPv6 networks, the
implications of its deployment need to be fully understood,
particularly where any applications might embed IPv6 addresses in
their payloads.
Use of NPTv6 can be chosen independently from how addresses are
assigned and routed within the internal network, how prefixes are
routed towards the Internet, or whether PA or PI addresses are used.
4. Internal Phase
This phase deals with the delivery of IPv6 to the internal user-
facing side of the Information Technology (IT) infrastructure, which
comprises various components such as network devices (routers,
switches, etc.), end-user devices and peripherals (workstations,
printers, etc.), and internal corporate systems.
An important design paradigm to consider during this phase is "dual
stack when you can, tunnel when you must". Dual stacking allows a
more robust, production-quality IPv6 network than is typically
facilitated by internal use of transition tunnels that are harder to
troubleshoot and support, and that may introduce scalability and
performance issues. Of course, tunnels may still be used in
production networks, but their use needs to be carefully considered,
e.g., where the transition tunnel may be run through a security or
filtering device. Tunnels do also provide a means to experiment with
IPv6 and gain some operational experience with the protocol.
[RFC4213] describes various transition mechanisms in more detail.
[RFC6964] suggests operational guidance when using Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP) tunnels [RFC5214],
though we would recommend use of dual stack wherever possible.
4.1. Security
IPv6 must be deployed in a secure way. This means that all existing IPv4 security policies must be extended to support IPv6; IPv6 security policies will be the IPv6 equivalent of the existing IPv4 ones (taking into account the difference for ICMPv6 [RFC4890]). As in IPv4, security policies for IPv6 will be enforced by firewalls, ACL, IPS, VPN, and so on. Privacy extension addresses [RFC4941] raise a challenge for an audit trail as explained in Section 2.4.3 of this document. The enterprise may choose to attempt to enforce use of DHCPv6 or deploy monitoring tools that harvest accountability data from switches and routers (thus making the assumption that devices may use any addresses inside the network). One major issue is threats against ND. This means, for example, that the internal network at the access layer (where hosts connect to the network over wired or wireless) should implement RA-Guard [RFC6105] and the techniques being specified by the SAVI WG [RFC6959]; see also Section 2.4.3 of this document for more information.4.2. Network Infrastructure
The typical enterprise network infrastructure comprises a combination of the following network elements -- wired access switches, wireless access points, and routers (although it is fairly common to find hardware that collapses switching and routing functionality into a single device). Basic wired access switches and access points operate only at the physical and link layers and don't really have any special IPv6 considerations other than being able to support IPv6 addresses themselves for management purposes. In many instances, these devices possess a lot more intelligence than simply switching packets. For example, some of these devices help assist with link- layer security by incorporating features such as ARP inspection and DHCP snooping, or they may help limit where multicast floods by using IGMP (or, in the case of IPv6, Multicast Listener Discovery (MLD)) snooping. Another important consideration in enterprise networks is first-hop router redundancy. This directly ties into network reachability from an end host's point of view. IPv6 ND [RFC4861] provides a node with the capability to maintain a list of available routers on the link, in order to be able to switch to a backup path should the primary be unreachable. By default, ND will detect a router failure in 38 seconds and cycle onto the next default router listed in its cache. While this feature provides a basic level of first-hop router redundancy, most enterprise IPv4 networks are designed to fail over
much faster. Although this delay can be improved by adjusting the default timers, care must be taken to protect against transient failures and to account for increased traffic on the link. Another option in which to provide robust first-hop redundancy is to use the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for IPv6 [RFC5798]. This protocol provides a much faster switchover to an alternate default router than default ND parameters. Using VRRPv3, a backup router can take over for a failed default router in around three seconds (using VRRPv3 default parameters). This is done without any interaction with the hosts and a minimum amount of VRRP traffic. Last but not least, one of the most important design choices to make while deploying IPv6 on the internal network is whether to use SLAAC [RFC4862], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or a combination thereof. Each option has advantages and disadvantages, and the choice will ultimately depend on the operational policies that guide each enterprise's network design. For example, if an enterprise is looking for ease of use, rapid deployment, and less administrative overhead, then SLAAC makes more sense for workstations. Manual or DHCPv6 assignments are still needed for servers, as described in the Address Plan and External Phase sections of this document; see Sections 2.6 and 3, respectively. However, if the operational policies call for precise control over IP address assignment for auditing, then DHCPv6 may be preferred. DHCPv6 also allows you to tie into DNS systems for host entry updates and gives you the ability to send other options and information to clients. It is worth noting that in general operation, RAs are still needed in DHCPv6 networks, as there is no DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA networks for other configuration information, e.g., NTP servers or, in the absence of support for DNS resolvers in RAs [RFC6106], DNS resolver information.4.3. End-User Devices
Most operating systems (OSes) that are loaded on workstations and laptops in a typical enterprise support IPv6 today. However, there are various out-of-the-box nuances that one should be mindful about. For example, the default behavior of OSes vary; some may have IPv6 turned off by default, some may only have certain features such as privacy extensions to IPv6 addresses (RFC 4941) turned off, while others have IPv6 fully enabled. Further, even when IPv6 is enabled, the choice of which address is used may be subject to source address selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is advised that enterprises investigate the default behavior of their installed OS base and account for it during the Inventory Phases of their IPv6 preparations. Furthermore, some OSes may have some
transition tunneling mechanisms turned on by default, and in such cases, it is recommended to administratively shut down such interfaces unless required. It is important to note that it is recommended that IPv6 be deployed at the network and system infrastructure level before it is rolled out to end-user devices; ensure IPv6 is running and routed on the wire, and secure and correctly monitored, before exposing IPv6 to end users. Smartphones and tablets are significant IPv6-capable platforms, depending on the support of the carrier's data network. IPv6 support for peripherals varies. Much like servers, printers are generally configured with a static address (or DHCP reservation) so clients can discover them reliably.4.4. Corporate Systems
No IPv6 deployment will be successful without ensuring that all the corporate systems that an enterprise uses as part of its IT infrastructure support IPv6. Examples of such systems include, but are not limited to, email, video conferencing, telephony (VoIP), DNS, RADIUS, etc. All these systems must have their own detailed IPv6 rollout plan in conjunction with the network IPv6 rollout. It is important to note that DNS is one of the main anchors in an enterprise deployment, since most end hosts decide whether or not to use IPv6 depending on the presence of IPv6 AAAA records in a reply to a DNS query. It is recommended that system administrators selectively turn on AAAA records for various systems as and when they are IPv6 enabled; care must be taken though to ensure all services running on that host name are IPv6 enabled before adding the AAAA record. Care with web proxies is advised; a mismatch in the level of IPv6 support between the client, proxy, and server can cause communication problems. All monitoring and reporting tools across the enterprise will need to be modified to support IPv6.5. IPv6 Only
Early IPv6 enterprise deployments have generally taken a dual-stack approach to enabling IPv6, i.e., the existing IPv4 services have not been turned off. Although IPv4 and IPv6 networks will coexist for a long time, the long-term enterprise network roadmap should include steps to simplify engineering and operations by deprecating IPv4 from the dual-stack network. In some extreme cases, deploying dual-stack networks may not even be a viable option for very large enterprises due to the address space described in RFC 1918 not being large enough to support the network's growth. In such cases, deploying IPv6-only
networks might be the only choice available to sustain network growth. In other cases, there may be elements of an otherwise dual- stack network that may be run in IPv6 only. If nodes in the network don't need to talk to an IPv4-only node, then deploying IPv6-only networks should be straightforward. However, most nodes will need to communicate with some IPv4-only nodes; an IPv6-only node may, therefore, require a translation mechanism. As [RFC6144] points out, it is important to look at address translation as a transition strategy towards running an IPv6-only network. There are various stateless and stateful IPv4/IPv6 translation methods available today that help IPv6-to-IPv4 communication. RFC 6144 provides a framework for IPv4/IPv6 translation and describes in detail various scenarios in which such translation mechanisms could be used. [RFC6145] describes stateless address translation. In this mode, a specific IPv6 address range will represent IPv4 systems (IPv4-converted addresses), and the IPv6 systems have addresses (IPv4-translatable addresses) that can be algorithmically mapped to a subset of the service provider's IPv4 addresses. NAT64 [RFC6146] describes stateful address translation. As the name suggests, the translation state is maintained between IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv4 systems. DNS64 [RFC6147] describes a mechanism for synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 6146 and RFC 6147 provide a viable method for an IPv6-only client to initiate communications to an IPv4-only server. As described in Enterprise Assumptions, Section 1.1, the administrator will usually want most traffic or flows to be native and only translate as needed. The address translation mechanisms for the stateless and stateful translations are defined in [RFC6052]. It is important to note that both of these mechanisms have limitations as to which protocols they support. For example, RFC 6146 only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic only. The classic problems of IPv4 NAT also apply, e.g., handling IP literals in application payloads. The ultimate choice of which translation mechanism to chose will be dictated mostly by existing operational policies pertaining to application support, logging requirements, etc. There is additional work being done in the area of address translation to enhance and/or optimize current mechanisms. For example, [DIVI] describes limitations with the current stateless translation, such as IPv4 address sharing and application layer gateway (ALG) problems, and presents the concept and implementation of dual-stateless IPv4/IPv6 translation (dIVI) to address those issues.
It is worth noting that for IPv6-only access networks that use technologies such as NAT64, the more content providers (and enterprises) that make their content available over IPv6, the less the requirement to apply NAT64 to traffic leaving the access network. This particular point is important for enterprises that may start their IPv6 deployment well into the global IPv6 transition. As time progresses, and given the current growth in availability of IPv6 content, IPv6-only operation using NAT64 to manage some flows will become less expensive to run versus the traditional NAT44 deployments since only IPv6-to-IPv4 flows need translation. [RFC6883] provides guidance and suggestions for Internet Content Providers and Application Service Providers in this context. Enterprises should also be aware that networks may be subject to future convergence with other networks (i.e., mergers, acquisitions, etc.). An enterprise considering IPv6-only operation may need to be aware that additional transition technologies and/or connectivity strategies may be required depending on the level of IPv6 readiness and deployment in the merging networking.6. Considerations for Specific Enterprises
6.1. Content Delivery Networks
Some guidance for Internet Content and Application Service Providers can be found in [RFC6883], which includes a dedicated section on Content Delivery Networks (CDNs). An enterprise that relies on a CDN to deliver a 'better' e-commerce experience needs to ensure that their CDN provider also supports IPv4/IPv6 traffic selection so that they can ensure 'best' access to the content. A CDN could enable external IPv6 content delivery even if the enterprise provides that content over IPv4.6.2. Data Center Virtualization
IPv6 Data Center considerations are described in [IPv6-DC].6.3. University Campus Networks
A number of campus networks around the world have made some initial IPv6 deployments. This has been encouraged by their National Research and Education Network (NREN) backbones, having made IPv6 available natively since the early 2000's. Universities are a natural place for IPv6 deployment to be considered at an early stage, perhaps compared to other enterprises, as they are involved by their very nature in research and education.
Campus networks can deploy IPv6 at their own pace; there is no need
to deploy IPv6 across the entire enterprise from day one. Rather,
specific projects can be identified for an initial deployment that
are both deep enough to give the university experience but small
enough to be a realistic first step. There are generally three areas
in which such deployments are currently made.
In particular, those initial areas commonly approached are:
o External-facing services. Typically, the campus web presence and
commonly also external-facing DNS and mail exchange (MX) services.
This ensures early IPv6-only adopters elsewhere can access the
campus services as simply and as robustly as possible.
o Computer science department. This is where IPv6-related research
and/or teaching is most likely to occur, and where many of the
next generation of network engineers are studying, so enabling
some or all of the campus computer science department network is a
sensible first step.
o The eduroam wireless network. Eduroam [EDUROAM] is the de facto
wireless roaming system for academic networks and uses
authentication based on 802.1X, which is agnostic to the IP
version used (unlike web-redirection gateway systems). Making a
campus' eduroam network dual stack is a very viable early step.
The general IPv6 deployment model in a campus enterprise will still
follow the general principles described in this document. While the
above early stage projects are commonly followed, these still require
the campus to acquire IPv6 connectivity and address space from their
NREN (or other provider in some parts of the world) and to enable
IPv6 on the wire on at least part of the core of the campus network.
This implies a requirement to have an initial address plan, and to
ensure appropriate monitoring and security measures are in place, as
described elsewhere in this document.
Campuses that have deployed to date do not use ULAs, nor do they use
NPTv6. In general, campuses have very stable PA-based address
allocations from their NRENs (or their equivalent). However, campus
enterprises may consider applying for IPv6 PI; some have already done
so. The discussions earlier in this text about PA vs. PI still
apply.
Finally, campuses may be more likely than many other enterprises to
run multicast applications, such as IP TV or live lecture or seminar
streaming, so they may wish to consider support for specific IPv6
multicast functionality, e.g., the Embedded Rendezvous Point
(Embedded-RP) [RFC3956] in routers and MLDv1 and MLDv2 snooping in switches.7. Security Considerations
This document has multiple security sections detailing with how to securely deploy an IPv6 network within an enterprise network.8. Informative References
[CYMRU] Team CYMRU Community Services, "THE BOGON REFERENCE", Version 7, April 2012, <http://www.team-cymru.org/Services/Bogons/>. [DHCPv6-SLAAC-PROBLEM] Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, draft- liu-bonica-dhcpv6-slaac-problem-02, September 2013. [DIVI] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- Stateless IPv4/IPv6 Translation", Work in Progress, draft- xli-behave-divi-06, January 2014. [EDUROAM] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam architecture for network roaming", Work in Progress, draft-wierenga-ietf-eduroam-04, August 2014. [HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host- scanning-04, June 2014. [IPv6-DC] Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, "IPv6 Operational Guidelines for Datacenters", Work in Progress, draft-ietf-v6ops-dc-ipv6-01, February 2014. [IPv6-DESIGN] Matthews, P. and V. Kuarsingh, "Design Choices for IPv6 Networks", Work in Progress, draft-ietf-v6ops-design- choices-02, September 2014. [IPv6-SECURITY] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-04, October 2013.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982, <http://www.rfc-editor.org/info/rfc826>. [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", RFC 1687, August 1994, <http://www.rfc-editor.org/info/rfc1687>. [RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1995, <http://www.rfc-editor.org/info/rfc1817>. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>. [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996, <http://www.rfc-editor.org/info/rfc2011>. [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997, <http://www.rfc-editor.org/info/rfc2096>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004, <http://www.rfc-editor.org/info/rfc3956>. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005, <http://www.rfc-editor.org/info/rfc4038>. [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005, <http://www.rfc-editor.org/info/rfc4057>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>. [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006, <http://www.rfc-editor.org/info/rfc4292>. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006, <http://www.rfc-editor.org/info/rfc4293>. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-editor.org/info/rfc4659>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007, <http://www.rfc-editor.org/info/rfc5095>. [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008, <http://www.rfc-editor.org/info/rfc5157>. [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008, <http://www.rfc-editor.org/info/rfc5211>. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>. [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008, <http://www.rfc-editor.org/info/rfc5375>. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>. [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010, <http://www.rfc-editor.org/info/rfc5798>. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>. [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011, <http://www.rfc-editor.org/info/rfc6105>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010, <http://www.rfc-editor.org/info/rfc6106>. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>. [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- Router Links", RFC 6164, April 2011, <http://www.rfc-editor.org/info/rfc6164>. [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>. [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <http://www.rfc-editor.org/info/rfc6192>. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>. [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011, <http://www.rfc-editor.org/info/rfc6302>. [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011, <http://www.rfc-editor.org/info/rfc6434>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>. [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>. [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013, <http://www.rfc-editor.org/info/rfc6866>. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013, <http://www.rfc-editor.org/info/rfc6879>. [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, March 2013, <http://www.rfc-editor.org/info/rfc6883>. [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, May 2013, <http://www.rfc-editor.org/info/rfc6959>. [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 6964, May 2013, <http://www.rfc-editor.org/rfc/rfc6964.txt>. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>. [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>. [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014, <http://www.rfc-editor.org/info/rfc7113>. [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on IPv4 Networks", RFC 7123, February 2014, <http://www.rfc-editor.org/info/rfc7123>. [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, August 2014, <http://www.rfc-editor.org/info/rfc7359>. [SMURF] The Cert Division of the Software Engineering Institute, "Smurf IP Denial-of-Service Attacks", CERT Advisory CA- 1998-01, March 2000, <http://www.cert.org/advisories/CA-1998-01.html>. [ULA-USAGE] Liu, B. and S. Jiang, "Considerations of Using Unique Local Addresses", Work in Progress, draft-ietf-v6ops-ula- usage-recommendations-03, July 2014.Acknowledgements
The authors would like to thank Robert Sparks, Steve Hanna, Tom Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou, Christian Jacquenet, and Fred Templin for their substantial comments and contributions.
Authors' Addresses
Kiran K. Chittimaneni Dropbox, Inc. 185 Berry Street, Suite 400 San Francisco, CA 94107 United States EMail: kk@dropbox.com Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 United States Phone: +1 703 345 3513 EMail: lee.howard@twcable.com Victor Kuarsingh Dyn, Inc. 150 Dow Street Manchester, NH United States EMail: victor@jvknet.com Yanick Pouffary Hewlett Packard 950 Route Des Colles Sophia-Antipolis 06901 France EMail: Yanick.Pouffary@hp.com Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2 778 4677 EMail: evyncke@cisco.com