Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7381

Pages: 34
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: V6OPS

Enterprise IPv6 Deployment Guidelines

Part 1 of 2, p. 1 to 17
None       Next RFC Part


Top       ToC       Page 1 
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


   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

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

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

Top       Page 3 
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

Top      ToC       Page 4 
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].

Top      ToC       Page 5 
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

   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

Top      ToC       Page 6 
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.

Top      ToC       Page 7 
   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

   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,

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
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).

Top      ToC       Page 11 
   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

   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

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
   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

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
   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

Top      ToC       Page 16 
   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 zone.  For more details, please refer to Section 4.4 of

   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

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

   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

Top      ToC       Page 17 
   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

   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.

(page 17 continued on part 2)

Next RFC Part