GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7381

Internet Engineering Task Force (IETF) K. Chittimaneni Request for Comments: 7381 Dropbox, Inc. Category: Informational T. Chown ISSN: 2070-1721 University of Southampton

                                                             L. Howard
                                                     Time Warner Cable
                                                          V. Kuarsingh
                                                             Dyn, Inc.
                                                           Y. Pouffary
                                                       Hewlett Packard
                                                             E. Vyncke
                                                         Cisco Systems
                                                          October 2014
               Enterprise IPv6 Deployment Guidelines

Abstract

 Enterprise network administrators worldwide are in various stages of
 preparing for or deploying IPv6 into their networks.  The
 administrators face different challenges than operators of Internet
 access providers and have reasons for different priorities.  The
 overall problem for many administrators will be to offer Internet-
 facing services over IPv6 while continuing to support IPv4, and while
 introducing IPv6 access within the enterprise IT network.  The
 overall transition will take most networks from an IPv4-only
 environment to a dual-stack network environment and eventually an
 IPv6-only operating mode.  This document helps provide a framework
 for enterprise network architects or administrators who may be faced
 with many of these challenges as they consider their IPv6 support
 strategies.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7381.

Chittimaneni, et al. Informational [Page 1] RFC 7381 Enterprise IPv6 Deployment October 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Chittimaneni, et al. Informational [Page 2] RFC 7381 Enterprise IPv6 Deployment October 2014

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Enterprise Assumptions  . . . . . . . . . . . . . . . . .   5
   1.2.  IPv4-Only Considerations  . . . . . . . . . . . . . . . .   5
   1.3.  Reasons for a Phased Approach . . . . . . . . . . . . . .   6
 2.  Preparation and Assessment Phase  . . . . . . . . . . . . . .   7
   2.1.  Program Planning  . . . . . . . . . . . . . . . . . . . .   7
   2.2.  Inventory Phase . . . . . . . . . . . . . . . . . . . . .   8
     2.2.1.  Network Infrastructure Readiness Assessment . . . . .   8
     2.2.2.  Application Readiness Assessment  . . . . . . . . . .   9
     2.2.3.  Importance of Readiness Validation and Testing  . . .   9
   2.3.  Training  . . . . . . . . . . . . . . . . . . . . . . . .  10
   2.4.  Security Policy . . . . . . . . . . . . . . . . . . . . .  10
     2.4.1.  IPv6 Is No More Secure Than IPv4  . . . . . . . . . .  10
     2.4.2.  Similarities between IPv6 and IPv4 Security . . . . .  11
     2.4.3.  Specific Security Issues for IPv6 . . . . . . . . . .  11
   2.5.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  13
   2.6.  Address Plan  . . . . . . . . . . . . . . . . . . . . . .  14
   2.7.  Tools Assessment  . . . . . . . . . . . . . . . . . . . .  16
 3.  External Phase  . . . . . . . . . . . . . . . . . . . . . . .  17
   3.1.  Connectivity  . . . . . . . . . . . . . . . . . . . . . .  18
   3.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  19
   3.3.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . .  20
   3.4.  Servers and Applications  . . . . . . . . . . . . . . . .  20
   3.5.  Network Prefix Translation for IPv6 . . . . . . . . . . .  21
 4.  Internal Phase  . . . . . . . . . . . . . . . . . . . . . . .  21
   4.1.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  22
   4.2.  Network Infrastructure  . . . . . . . . . . . . . . . . .  22
   4.3.  End-User Devices  . . . . . . . . . . . . . . . . . . . .  23
   4.4.  Corporate Systems . . . . . . . . . . . . . . . . . . . .  24
 5.  IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . .  24
 6.  Considerations for Specific Enterprises . . . . . . . . . . .  26
   6.1.  Content Delivery Networks . . . . . . . . . . . . . . . .  26
   6.2.  Data Center Virtualization  . . . . . . . . . . . . . . .  26
   6.3.  University Campus Networks  . . . . . . . . . . . . . . .  26
 7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
 8.  Informative References  . . . . . . . . . . . . . . . . . . .  28
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  34
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

Chittimaneni, et al. Informational [Page 3] RFC 7381 Enterprise IPv6 Deployment October 2014

1. Introduction

 An enterprise network is defined in [RFC4057] as a network that has
 multiple internal links, one or more router connections to one or
 more providers, and is actively managed by a network operations
 entity (the "administrator", whether a single person or a department
 of administrators).  Administrators generally support an internal
 network, consisting of users' workstations; personal computers;
 mobile devices; other computing devices and related peripherals; a
 server network, consisting of accounting and business application
 servers; and an external network, consisting of Internet-accessible
 services such as web servers, email servers, VPN systems, and
 customer applications.  This document is intended as guidance for
 enterprise network architects and administrators in planning their
 IPv6 deployments.
 The business reasons for spending time, effort, and money on IPv6
 will be unique to each enterprise.  The most common drivers are due
 to the fact that when Internet service providers, including mobile
 wireless carriers, run out of IPv4 addresses, they will provide
 native IPv6 and non-native IPv4.  The non-native IPv4 service may be
 NAT64, NAT444, Dual-Stack Lite (DS-Lite), Mapping of Address and Port
 using Translation (MAP-T), Mapping of Address and Port using
 Encapsulation (MAP-E), or other transition technologies.  Compared to
 tunneled or translated service, native traffic typically performs
 better and more reliably than non-native.  For example, for client
 networks trying to reach enterprise networks, the IPv6 experience
 will be better than the transitional IPv4 if the enterprise deploys
 IPv6 in its public-facing services.  The native IPv6 network path
 should also be simpler to manage and, if necessary, troubleshoot.
 Further, enterprises doing business in growing parts of the world may
 find IPv6 growing faster there, where again potential new customers,
 employees, and partners are using IPv6.  It is thus in the
 enterprise's interest to deploy native IPv6 at the very least in its
 public-facing services but ultimately across the majority or all of
 its scope.
 The text in this document provides specific guidance for enterprise
 networks and complements other related work in the IETF, including
 [IPv6-DESIGN] and [RFC5375].

Chittimaneni, et al. Informational [Page 4] RFC 7381 Enterprise IPv6 Deployment October 2014

1.1. Enterprise Assumptions

 For the purpose of this document, we assume the following:
 o  The administrator is considering deploying IPv6 (but see
    Section 1.2 below).
 o  The administrator has existing IPv4 networks and devices that will
    continue to operate and be supported.
 o  The administrator will want to minimize the level of disruption to
    the users and services by minimizing the number of technologies
    and functions that are needed to mediate any given application.
    In other words, provide native IP wherever possible.
 Based on these assumptions, an administrator will want to use
 technologies that minimize the number of flows being tunneled,
 translated, or intercepted at any given time.  The administrator will
 choose transition technologies or strategies that both allow most
 traffic to be native and manage non-native traffic.  This will allow
 the administrator to minimize the cost of IPv6 transition
 technologies by containing the number and scale of transition
 systems.
 Tunnels used for IPv6/IPv4 transition are expected as near-/mid-term
 mechanisms, while IPv6 tunneling will be used for many long-term
 operational purposes such as security, routing control, mobility,
 multihoming, traffic engineering, etc.  We refer to the former class
 of tunnels as "transition tunnels".

1.2. IPv4-Only Considerations

 As described in [RFC6302], administrators should take certain steps
 even if they are not considering IPv6.  Specifically, Internet-facing
 servers should log the source port number, timestamp (from a reliable
 source), and the transport protocol.  This will allow investigation
 of malefactors behind address-sharing technologies such as NAT444,
 MAP, or DS Lite.  Such logs should be protected for integrity,
 safeguarded for privacy, and periodically purged within applicable
 regulations for log retention.
 Other IPv6 considerations may impact ostensibly IPv4-only networks,
 e.g., [RFC6104] describes the rogue IPv6 Router Advertisement (RA)
 problem, which may cause problems in IPv4-only networks where IPv6 is
 enabled in end systems on that network.  Further discussion of the
 security implications of IPv6 in IPv4-only networks can be found in
 [RFC7123].

Chittimaneni, et al. Informational [Page 5] RFC 7381 Enterprise IPv6 Deployment October 2014

1.3. Reasons for a Phased Approach

 Given the challenges of transitioning user workstations, corporate
 systems, and Internet-facing servers, a phased approach allows
 incremental deployment of IPv6, based on the administrator's own
 determination of priorities.  This document outlines suggested
 phases: a Preparation and Assessment Phase, an Internal Phase, and an
 External Phase.  The Preparation Phase is highly recommended to all
 administrators, as it will save errors and complexity in later
 phases.  Each administrator must decide whether to begin with an
 External Phase (enabling IPv6 for Internet-facing systems, as
 recommended in [RFC5211]) or an Internal Phase (enabling IPv6 for
 internal interconnections first).
 Each scenario is likely to be different to some extent, but we can
 highlight some considerations:
 o  In many cases, customers outside the network will have IPv6 before
    the internal enterprise network.  For these customers, IPv6 may
    well perform better, especially for certain applications, than
    translated or tunneled IPv4, so the administrator may want to
    prioritize the External Phase such that those customers have the
    simplest and most robust connectivity to the enterprise, or at
    least its external-facing elements.
 o  Employees who access internal systems by VPN may find that their
    ISPs provide translated IPv4, which does not support the required
    VPN protocols.  In these cases, the administrator may want to
    prioritize the External Phase and any other remotely accessible
    internal systems.  It is worth noting that a number of emerging
    VPN solutions provide dual-stack connectivity; thus, a VPN service
    may be useful for employees in IPv4-only access networks to access
    IPv6 resources in the enterprise network (much like many public
    tunnel broker services, but specifically for the enterprise).
    Some security considerations are described in [RFC7359].
 o  Internet-facing servers cannot be managed over IPv6 unless the
    management systems are IPv6 capable.  These might be Network
    Management Systems (NMS), monitoring systems, or just remote
    management desktops.  Thus, in some cases, the Internet-facing
    systems are dependent on IPv6-capable internal networks.  However,
    dual-stack Internet-facing systems can still be managed over IPv4.
 o  Virtual Machines (VMs) may enable a faster rollout once initial
    system deployment is complete.  Management of VMs over IPv6 is
    still dependent on the management software supporting IPv6.

Chittimaneni, et al. Informational [Page 6] RFC 7381 Enterprise IPv6 Deployment October 2014

 o  IPv6 is enabled by default on all modern operating systems, so it
    may be more urgent to manage and have visibility on the internal
    traffic.  It is important to manage IPv6 for security purposes,
    even in an ostensibly IPv4-only network, as described in
    [RFC7123].
 o  In many cases, the corporate accounting, payroll, human resource,
    and other internal systems may only need to be reachable from the
    internal network, so they may be a lower priority.  As enterprises
    require their vendors to support IPv6, more internal applications
    will support IPv6 by default, and it can be expected that
    eventually new applications will only support IPv6.  The
    inventory, as described in Section 2.2, will help determine the
    systems' readiness, as well as the readiness of the supporting
    network elements and security, which will be a consideration in
    prioritization of these corporate systems.
 o  Some large organizations (even when using private IPv4 addresses
    [RFC1918]) are facing IPv4 address exhaustion because of the
    internal network growth (for example, the vast number of VMs) or
    because of the acquisition of other companies that often raise
    private IPv4 address overlapping issues.
 o  IPv6 restores end-to-end transparency even for internal
    applications (of course security policies must still be enforced).
    When two organizations or networks merge [RFC6879], the unique
    addressing of IPv6 can make the merger much easier and faster.  A
    merger may, therefore, prioritize IPv6 for the affected systems.
 These considerations are in conflict; each administrator must
 prioritize according to their company's conditions.  It is worth
 noting that the reasons given in "A Large Corporate User's View of
 IPng", described in [RFC1687], for reluctance to deploy have largely
 been satisfied or overcome in the intervening years.

2. Preparation and Assessment Phase

2.1. Program Planning

 Since enabling IPv6 is a change to the most fundamental Internet
 Protocol, and since there are so many interdependencies, having a
 professional project manager organize the work is highly recommended.
 In addition, an executive sponsor should be involved in determining
 the goals of enabling IPv6 (which will establish the order of the
 phases) and should receive regular updates.
 It may be necessary to complete the Preparation Phase before
 determining whether to prioritize the Internal or External Phase,

Chittimaneni, et al. Informational [Page 7] RFC 7381 Enterprise IPv6 Deployment October 2014

 since needs and readiness assessments are part of that phase.  For a
 large enterprise, it may take several iterations to really understand
 the level of effort required.  Depending on the required schedule, it
 may be useful to roll IPv6 projects into other architectural upgrades
 -- this can be an excellent way to improve the network and reduce
 costs.  However, by increasing the scope of projects, the schedule is
 often affected.  For instance, a major systems upgrade may take a
 year to complete, where just patching existing systems may take only
 a few months.
 The deployment of IPv6 will not generally stop all other technology
 work.  Once IPv6 has been identified as an important initiative, all
 projects, both new and in progress, will need to be reviewed to
 ensure IPv6 support.
 It is normal for assessments to continue in some areas while
 execution of the project begins in other areas.  This is fine, as
 long as recommendations in other parts of this document are
 considered, especially regarding security (for instance, one should
 not deploy IPv6 on a system before security has been evaluated).

2.2. Inventory Phase

 To comprehend the scope of the Inventory Phase, we recommend dividing
 the problem space in two: network infrastructure readiness and
 applications readiness.

2.2.1. Network Infrastructure Readiness Assessment

 The goal of this assessment is to identify the level of IPv6
 readiness of network equipment.  This will identify the effort
 required to move to an infrastructure that supports IPv6 with the
 same functional service capabilities as the existing IPv4 network.
 This may also require a feature comparison and gap analysis between
 IPv4 and IPv6 functionality on the network equipment and software.
 IPv6 support will require testing; features often work differently in
 vendors' labs than production networks.  Some devices and software
 will require IPv4 support for IPv6 to work.
 The inventory will show which network devices are already capable,
 which devices can be made IPv6 ready with a code/firmware upgrade,
 and which devices will need to be replaced.  The data collection
 consists of a network discovery to gain an understanding of the
 topology and inventory network infrastructure equipment and code
 versions with information gathered from static files and IP address
 management, DNS, and DHCP tools.

Chittimaneni, et al. Informational [Page 8] RFC 7381 Enterprise IPv6 Deployment October 2014

 Since IPv6 might already be present in the environment, through
 default configurations or VPNs, an infrastructure assessment (at
 minimum) is essential to evaluate potential security risks.

2.2.2. Application Readiness Assessment

 Just like network equipment, application software needs to support
 IPv6.  This includes OS, firmware, middleware, and applications
 (including internally developed applications).  Vendors will
 typically handle IPv6 enablement of off-the-shelf products, but often
 enterprises need to request this support from vendors.  For
 internally developed applications, it is the responsibility of the
 enterprise to enable them for IPv6.  Analyzing how a given
 application communicates over the network will dictate the steps
 required to support IPv6.  Applications should avoid instructions
 specific to a given IP address family.  Any applications that use
 APIs, such as the C language, that expose the IP version
 specifically, need to be modified to also work with IPv6.
 There are two ways to IPv6-enable applications.  The first approach
 is to have separate logic for IPv4 and IPv6, thus leaving the IPv4
 code path mainly untouched.  This approach causes the least
 disruption to the existing IPv4 logic flow, but introduces more
 complexity, since the application now has to deal with two logic
 loops with complex race conditions and error recovery mechanisms
 between these two logic loops.  The second approach is to create a
 combined IPv4/IPv6 logic, which ensures operation regardless of the
 IP version used on the network.  Knowing whether a given
 implementation will use IPv4 or IPv6 in a given deployment is a
 matter of some art; see Source Address Selection [RFC6724] and Happy
 Eyeballs [RFC6555].  It is generally recommended that the application
 developer use industry IPv6-porting tools to locate the code that
 needs to be updated.  Some discussion of IPv6 application porting
 issues can be found in [RFC4038].

2.2.3. Importance of Readiness Validation and Testing

 Lastly, IPv6 introduces a completely new way of addressing endpoints,
 which can have ramifications at the network layer all the way up to
 the applications.  So to minimize disruption during the transition
 phase, we recommend complete functionality, scalability, and security
 testing to understand how IPv6 impacts the services and networking
 infrastructure.

Chittimaneni, et al. Informational [Page 9] RFC 7381 Enterprise IPv6 Deployment October 2014

2.3. Training

 Many organizations falter in IPv6 deployment because of a perceived
 training gap.  Training is important for those who work with
 addresses regularly, as with anyone whose work is changing.  Better
 knowledge of the reasons IPv6 is being deployed will help inform the
 assessment of who needs training and what training they need.

2.4. Security Policy

 It is obvious that IPv6 networks should be deployed in a secure way.
 The industry has learned a lot about network security with IPv4, so
 network operators should leverage this knowledge and expertise when
 deploying IPv6.  IPv6 is not so different than IPv4: it is a
 connectionless network protocol using the same lower-layer service
 and delivering the same service to the upper layer.  Therefore, the
 security issues and mitigation techniques are mostly identical with
 the same exceptions that are described further.

2.4.1. IPv6 Is No More Secure Than IPv4

 Some people believe that IPv6 is inherently more secure than IPv4
 because it is new.  Nothing can be more wrong.  Indeed, being a new
 protocol means that bugs in the implementations have yet to be
 discovered and fixed and that few people have the operational
 security expertise needed to operate securely an IPv6 network.  This
 lack of operational expertise is the biggest threat when deploying
 IPv6: the importance of training is to be stressed again.
 One security myth is that, thanks to its huge address space, a
 network cannot be scanned by enumerating all IPv6 addresses in a /64
 LAN; hence, a malevolent person cannot find a victim.  [RFC5157]
 describes some alternate techniques to find potential targets on a
 network, for example, enumerating all DNS names in a zone.
 Additional advice in this area is also given in [HOST-SCANNING].
 Another security myth is that IPv6 is more secure because it mandates
 the use of IPsec everywhere.  While the original IPv6 specifications
 may have implied this, [RFC6434] clearly states that IPsec support is
 not mandatory.  Moreover, if all the intra-enterprise traffic is
 encrypted, both malefactors and security tools that rely on payload
 inspection (Intrusion Prevention System (IPS), firewall, Access
 Control List (ACL), IP Flow Information Export (IPFIX) ([RFC7011] and
 [RFC7012]), etc.) will be affected.  Therefore, IPsec is as useful in
 IPv6 as in IPv4 (for example, to establish a VPN overlay over a non-
 trusted network or to reserve for some specific applications).

Chittimaneni, et al. Informational [Page 10] RFC 7381 Enterprise IPv6 Deployment October 2014

 The last security myth is that amplification attacks (such as
 [SMURF]) do not exist in IPv6 because there is no more broadcast.
 Alas, this is not true as ICMP error (in some cases) or information
 messages can be generated by routers and hosts when forwarding or
 receiving a multicast message (see Section 2.4 of [RFC4443]).
 Therefore, the generation and the forwarding rate of ICMPv6 messages
 must be limited as in IPv4.
 It should be noted that in a dual-stack network, the security
 implementation for both IPv4 and IPv6 needs to be considered, in
 addition to security considerations related to the interaction of
 (and transition between) the two, while they coexist.

2.4.2. Similarities between IPv6 and IPv4 Security

 As mentioned earlier, IPv6 is quite similar to IPv4; therefore,
 several attacks apply for both protocol families, including:
 o  Application layer attacks: such as cross-site scripting or SQL
    injection
 o  Rogue device: such as a rogue Wi-Fi access point
 o  Flooding and all traffic-based denial of services (including the
    use of control plane policing for IPv6 traffic: see [RFC6192])
 A specific case of congruence is IPv6 Unique Local Addresses (ULAs)
 [RFC4193] and IPv4 private addressing [RFC1918], which do not provide
 any security by 'magic'.  In both cases, the edge router must apply
 strict filters to block those private addresses from entering and,
 just as importantly, leaving the network.  This filtering can be done
 by the enterprise or by the ISP, but the cautious administrator will
 prefer to do it in the enterprise.
 IPv6 addresses can be spoofed as easily as IPv4 addresses, and there
 are packets with bogon IPv6 addresses (see [CYMRU]).  Anti-bogon
 filtering must be done in the data and routing planes.  It can be
 done by the enterprise or by the ISP, or both, but again the cautious
 administrator will prefer to do it in the enterprise.

2.4.3. Specific Security Issues for IPv6

 Even if IPv6 is similar to IPv4, there are some differences that
 create some IPv6-only vulnerabilities or issues.  We give examples of
 such differences in this section.
 Privacy extension addresses [RFC4941] are usually used to protect
 individual privacy by periodically changing the interface identifier

Chittimaneni, et al. Informational [Page 11] RFC 7381 Enterprise IPv6 Deployment October 2014

 part of the IPv6 address to avoid tracking a host by its otherwise
 always identical and unique 64-bit Extended Unique Identifier
 (EUI-64) based on Media Access Control (MAC).  While this presents a
 real advantage on the Internet, moderated by the fact that the prefix
 part remains the same, it complicates the task of following an audit
 trail when a security officer or network operator wants to trace back
 a log entry to a host in their network because when the tracing is
 done, the searched IPv6 address could have disappeared from the
 network.  Therefore, the use of privacy extension addresses usually
 requires additional monitoring and logging of the binding of the IPv6
 address to a data-link layer address (see also the monitoring section
 in [IPv6-SECURITY], Section 2.5).  Some early enterprise deployments
 have taken the approach of using tools that harvest IP/MAC address
 mappings from switch and router devices to provide address
 accountability; this approach has been shown to work, though it can
 involve gathering significantly more address data than in equivalent
 IPv4 networks.  An alternative is to try to prevent the use of
 privacy extension addresses by enforcing the use of DHCPv6, such that
 hosts only get addresses assigned by a DHCPv6 server.  This can be
 done by configuring routers to set the M bit in RAs, combined with
 all advertised prefixes being included without the A bit set (to
 prevent the use of stateless autoconfiguration).  Of course, this
 technique requires that all hosts support stateful DHCPv6.  It is
 important to note that not all operating systems exhibit the same
 behavior when processing RAs with the M bit set.  The varying OS
 behavior is related to the lack of prescriptive definition around the
 A, M, and O bits within the Neighbor Discovery Protocol (NDP).
 [DHCPv6-SLAAC-PROBLEM] provides a much more detailed analysis on the
 interaction of the M bit and DHCPv6.
 Extension headers complicate the task of stateless packet filters
 such as ACLs.  If ACLs are used to enforce a security policy, then
 the enterprise must verify whether its ACLs (but also stateful
 firewalls) are able to process extension headers (this means
 understand them enough to parse them to find the upper-layer
 payloads) and to block unwanted extension headers (e.g., to implement
 [RFC5095]).  This topic is discussed further in [RFC7045].
 Fragmentation is different in IPv6 because it is done only by the
 source host and never during a forwarding operation.  This means that
 ICMPv6 packet-too-big messages must be allowed to pass through the
 network and not be filtered [RFC4890].  Fragments can also be used to
 evade some security mechanisms such as RA-Guard [RFC6105].  See also
 [RFC5722] and [RFC7113].
 One of the biggest differences between IPv4 and IPv6 is the
 introduction of NDP [RFC4861], which includes a variety of important
 IPv6 protocol functions, including those provided in IPv4 by the

Chittimaneni, et al. Informational [Page 12] RFC 7381 Enterprise IPv6 Deployment October 2014

 Address Resolution Protocol (ARP) [RFC0826].  NDP runs over ICMPv6
 (which as stated above means that security policies must allow some
 ICMPv6 messages to pass, as described in RFC 4890), but has the same
 lack of security as, for example, ARP, in that there is no inherent
 message authentication.  While Secure Neighbor Discovery (SEND)
 [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972]
 have been defined, they are not widely implemented).  The threat
 model for RAs within the NDP suite is similar to that of DHCPv4 (and
 DHCPv6), in that a rogue host could be either a rogue router or a
 rogue DHCP server.  An IPv4 network can be made more secure with the
 help of DHCPv4 snooping in edge switches, and likewise RA snooping
 can improve IPv6 network security (in IPv4-only networks as well).
 Thus, enterprises using such techniques for IPv4 should use the
 equivalent techniques for IPv6, including RA-Guard [RFC6105] and all
 work in progress from the Source Address Validation Improvement
 (SAVI) WG, e.g., [RFC6959], which is similar to the protection given
 by dynamic ARP monitoring in IPv4.  Other DoS vulnerabilities are
 related to NDP cache exhaustion, and mitigation techniques can be
 found in ([RFC6583]).
 As stated previously, running a dual-stack network doubles the attack
 exposure as a malevolent person has now two attack vectors: IPv4 and
 IPv6.  This simply means that all routers and hosts operating in a
 dual-stack environment with both protocol families enabled (even if
 by default) must have a congruent security policy for both protocol
 versions.  For example, permit TCP ports 80 and 443 to all web
 servers and deny all other ports to the same servers must be
 implemented both for IPv4 and IPv6.  It is thus important that the
 tools available to administrators readily support such behavior.

2.5. Routing

 An important design choice to be made is what IGP is to use inside
 the network.  A variety of IGPs (IS-IS, OSPFv3, and Routing
 Information Protocol Next Generation (RIPng)) support IPv6 today, and
 picking one over the other is a design choice that will be dictated
 mostly by existing operational policies in an enterprise network.  As
 mentioned earlier, it would be beneficial to maintain operational
 parity between IPv4 and IPv6; therefore, it might make sense to
 continue using the same protocol family that is being used for IPv4.
 For example, in a network using OSPFv2 for IPv4, it might make sense
 to use OSPFv3 for IPv6.  It is important to note that although OSPFv3
 is similar to OSPFv2, they are not the same.  On the other hand, some
 organizations may chose to run different routing protocols for
 different IP versions.  For example, one may chose to run OSPFv2 for
 IPv4 and IS-IS for IPv6.  An important design question to consider
 here is whether to support one IGP or two different IGPs in the
 longer term.  [IPv6-DESIGN] presents advice on the design choices

Chittimaneni, et al. Informational [Page 13] RFC 7381 Enterprise IPv6 Deployment October 2014

 that arise when considering IGPs and discusses the advantages and
 disadvantages to different approaches in detail.

2.6. Address Plan

 The most common problem encountered in IPv6 networking is in applying
 the same principles of conservation that are so important in IPv4.
 IPv6 addresses do not need to be assigned conservatively.  In fact, a
 single, larger allocation is considered more conservative than
 multiple non-contiguous small blocks because a single block occupies
 only a single entry in a routing table.  The advice in [RFC5375] is
 still sound and is recommended to the reader.  If considering ULAs,
 give careful thought to how well it is supported, especially in
 multiple address and multicast scenarios, and assess the strength of
 the requirement for ULA.  [ULA-USAGE] provides much more detailed
 analysis and recommendations on the usage of ULAs.
 The enterprise administrator will want to evaluate whether the
 enterprise will request address space from a Local Internet Registry
 (LIR) such as an ISP; a Regional Internet Registry (RIR) such as
 AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC; or a National Internet
 Registry (NIR) operated in some countries.  The normal allocation is
 Provider-Aggregated (PA) address space from the enterprise's ISP, but
 use of PA space implies renumbering when changing providers.
 Instead, an enterprise may request Provider-Independent (PI) space;
 this may involve an additional fee, but the enterprise may then be
 better able to be multihomed using that prefix and will avoid a
 renumbering process when changing ISPs (though it should be noted
 that renumbering caused by outgrowing the space, merger, or other
 internal reason would still not be avoided with PI space).
 The type of address selected (PI vs. PA) should be congruent with the
 routing needs of the enterprise.  The selection of address type will
 determine if an operator will need to apply new routing techniques
 and may limit future flexibility.  There is no right answer, but the
 needs of the External Phase may affect what address type is selected.
 Each network location or site will need a prefix assignment.
 Depending on the type of site/location, various prefix sizes may be
 used.  In general, historical guidance suggests that each site should
 get at least a /48, as documented in RFC 5375 and [RFC6177].  In
 addition to allowing for simple planning, this can allow a site to
 use its prefix for local connectivity, should the need arise, and if
 the local ISP supports it.
 When assigning addresses to end systems, the enterprise may use
 manually configured addresses (common on servers) or Stateless
 Address Autoconfiguration (SLAAC) or DHCPv6 for client systems.

Chittimaneni, et al. Informational [Page 14] RFC 7381 Enterprise IPv6 Deployment October 2014

 Early IPv6 enterprise deployments have used SLAAC both for its
 simplicity and the time DHCPv6 has taken to mature.  However, DHCPv6
 is now very mature; thus, workstations managed by an enterprise may
 use stateful DHCPv6 for addressing on corporate LAN segments.  DHCPv6
 allows for the additional configuration options often employed by
 enterprise administrators, and by using stateful DHCPv6,
 administrators correlating system logs know which system had which
 address at any given time.  Such an accountability model is familiar
 from IPv4 management, though DHCPv6 hosts are identified by a DHCP
 Unique Identifier (DUID) rather than a MAC address.  For equivalent
 accountability with SLAAC (and potentially privacy addresses), a
 monitoring system that harvests IP/MAC mappings from switch and
 router equipment could be used.
 A common deployment consideration for any enterprise network is how
 to get host DNS records updated.  Commonly, either the host will send
 DNS updates or the DHCP server will update records.  If there is
 sufficient trust between the hosts and the DNS server, the hosts may
 update (and the enterprise may use SLAAC for addressing).  Otherwise,
 the DHCPv6 server can be configured to update the DNS server.  Note
 that an enterprise network with this more controlled environment will
 need to disable SLAAC on network segments and force end hosts to use
 DHCPv6 only.
 In the data center or server room, assume a /64 per VLAN.  This
 applies even if each individual system is on a separate VLAN.  In a
 /48 assignment, typical for a site, there are then still 65,535 /64
 blocks.  Some administrators reserve a /64 but configure a small
 subnet, such as /112, /126, or /127, to prevent rogue devices from
 attaching and getting numbers; an alternative is to monitor traffic
 for surprising addresses or Neighbor Discovery (ND) tables for new
 entries.  Addresses are either configured manually on the server or
 reserved on a DHCPv6 server, which may also synchronize forward and
 reverse DNS (though see [RFC6866] for considerations on static
 addressing).  SLAAC is not recommended for servers because of the
 need to synchronize RA timers with DNS Times to Live (TTLs) so that
 the DNS entry expires at the same time as the address.
 All user access networks should be a /64.  Point-to-point links where
 NDP is not used may also utilize a /127 (see [RFC6164]).
 Plan to aggregate at every layer of network hierarchy.  There is no
 need for variable length subnet mask (VLSM) [RFC1817] in IPv6, and
 addressing plans based on conservation of addresses are shortsighted.
 Use of prefixes longer then /64 on network segments will break common
 IPv6 functions such as SLAAC [RFC4862].  Where multiple VLANs or
 other Layer 2 domains converge, allow some room for expansion.
 Renumbering due to outgrowing the network plan is a nuisance, so

Chittimaneni, et al. Informational [Page 15] RFC 7381 Enterprise IPv6 Deployment October 2014

 allow room within it.  Generally, plan to grow to about twice the
 current size that can be accommodated; where rapid growth is planned,
 allow for twice that growth.  Also, if DNS (or reverse DNS) authority
 may be delegated to others in the enterprise, assignments need to be
 on nibble boundaries (that is, on a multiple of 4 bits, such as /64,
 /60, /56, ..., /48, /44), to ensure that delegated zones align with
 assigned prefixes.
 If using ULAs, it is important to note that AAAA and PTR records for
 ULAs are not recommended to be installed in the global DNS.
 Similarly, reverse (address-to-name) queries for ULA must not be sent
 to name servers outside of the organization, due to the load that
 such queries would create for the authoritative name servers for the
 ip6.arpa zone.  For more details, please refer to Section 4.4 of
 [RFC4193].
 Enterprise networks are increasingly including virtual networks where
 a single, physical node may host many virtualized addressable
 devices.  It is imperative that the addressing plans assigned to
 these virtual networks and devices be consistent and non-overlapping
 with the addresses assigned to real networks and nodes.  For example,
 a virtual network established within an isolated lab environment may,
 at a later time, become attached to the production enterprise
 network.

2.7. Tools Assessment

 Enterprises will often have a number of operational tools and support
 systems that are used to provision, monitor, manage, and diagnose the
 network and systems within their environment.  These tools and
 systems will need to be assessed for compatibility with IPv6.  The
 compatibility may be related to the addressing and connectivity of
 various devices as well as IPv6 awareness of the tools and processing
 logic.
 The tools within the organization fall into two general categories:
 those that focus on managing the network and those that are focused
 on managing systems and applications on the network.  In either
 instance, the tools will run on platforms that may or may not be
 capable of operating in an IPv6 network.  This lack in functionality
 may be related to operating system version or based on some hardware
 constraint.  Those systems that are found to be incapable of
 utilizing an IPv6 connection, or which are dependent on an IPv4
 stack, may need to be replaced or upgraded.
 In addition to devices working on an IPv6 network natively, or via a
 transition tunnel, many tools and support systems may require
 additional software updates to be IPv6 aware or even a hardware

Chittimaneni, et al. Informational [Page 16] RFC 7381 Enterprise IPv6 Deployment October 2014

 upgrade (usually for additional memory, IPv6 addresses are larger and
 for a while, IPv4 and IPv6 addresses will coexist in the tool).  This
 awareness may include the ability to manage IPv6 elements and/or
 applications in addition to the ability to store and utilize IPv6
 addresses.
 Considerations when assessing the tools and support systems may
 include the fact that IPv6 addresses are significantly larger than
 IPv4, requiring data stores to support the increased size.  Such
 issues are among those discussed in [RFC5952].  Many organizations
 may also run dual-stack networks; therefore, the tools need to not
 only support IPv6 operation but may also need to support the
 monitoring, management, and intersection with both IPv6 and IPv4
 simultaneously.  It is important to note that managing IPv6 is not
 just constrained to using large IPv6 addresses, but also that IPv6
 interfaces and nodes are likely to use two or more addresses as part
 of normal operation.  Updating management systems to deal with these
 additional nuances will likely consume time and considerable effort.
 For networking systems, like node management systems, it is not
 always necessary to support local IPv6 addressing and connectivity.
 Operations such as SNMP MIB polling can occur over IPv4 transport
 while seeking responses related to IPv6 information.  Where this may
 seem advantageous to some, it should be noted that without local IPv6
 connectivity, the management system may not be able to perform all
 expected functions -- such as reachability and service checks.
 Organizations should be aware that changes to older IPv4-only SNMP
 MIB specifications have been made by the IETF and are related to
 legacy operation in [RFC2096] and [RFC2011].  Updated specifications
 are now available in [RFC4292] and [RFC4293] that modified the older
 MIB framework to be IP protocol agnostic, supporting both IPv4 and
 IPv6.  Polling systems will need to be upgraded to support these
 updates as well as the end stations, which are polled.

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.

Chittimaneni, et al. Informational [Page 17] RFC 7381 Enterprise IPv6 Deployment October 2014

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.

Chittimaneni, et al. Informational [Page 18] RFC 7381 Enterprise IPv6 Deployment October 2014

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

Chittimaneni, et al. Informational [Page 19] RFC 7381 Enterprise IPv6 Deployment October 2014

    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

Chittimaneni, et al. Informational [Page 20] RFC 7381 Enterprise IPv6 Deployment October 2014

    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.

Chittimaneni, et al. Informational [Page 21] RFC 7381 Enterprise IPv6 Deployment October 2014

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

Chittimaneni, et al. Informational [Page 22] RFC 7381 Enterprise IPv6 Deployment October 2014

 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

Chittimaneni, et al. Informational [Page 23] RFC 7381 Enterprise IPv6 Deployment October 2014

 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

Chittimaneni, et al. Informational [Page 24] RFC 7381 Enterprise IPv6 Deployment October 2014

 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.

Chittimaneni, et al. Informational [Page 25] RFC 7381 Enterprise IPv6 Deployment October 2014

 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.

Chittimaneni, et al. Informational [Page 26] RFC 7381 Enterprise IPv6 Deployment October 2014

 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

Chittimaneni, et al. Informational [Page 27] RFC 7381 Enterprise IPv6 Deployment October 2014

 (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.

Chittimaneni, et al. Informational [Page 28] RFC 7381 Enterprise IPv6 Deployment October 2014

 [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>.

Chittimaneni, et al. Informational [Page 29] RFC 7381 Enterprise IPv6 Deployment October 2014

 [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>.

Chittimaneni, et al. Informational [Page 30] RFC 7381 Enterprise IPv6 Deployment October 2014

 [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>.

Chittimaneni, et al. Informational [Page 31] RFC 7381 Enterprise IPv6 Deployment October 2014

 [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>.

Chittimaneni, et al. Informational [Page 32] RFC 7381 Enterprise IPv6 Deployment October 2014

 [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>.

Chittimaneni, et al. Informational [Page 33] RFC 7381 Enterprise IPv6 Deployment October 2014

 [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.

Chittimaneni, et al. Informational [Page 34] RFC 7381 Enterprise IPv6 Deployment October 2014

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

Chittimaneni, et al. Informational [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7381.txt · Last modified: 2014/10/23 21:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki