One document matched: draft-ietf-v6ops-icp-guidance-03.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!-- You need one entry like the following for each RFC referenced -->

<!ENTITY RFC2119 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC2460 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY RFC6146 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml'>
<!ENTITY RFC6343 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6343.xml'>
<!ENTITY RFC2923 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2923.xml'>
<!ENTITY RFC5246 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC4301 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY RFC5996 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
<!ENTITY RFC5157 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5157.xml'>
<!ENTITY RFC3068 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml'>
<!ENTITY RFC2616 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC4941 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml'>
<!ENTITY RFC4038 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4038.xml'>
<!ENTITY RFC4864 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml'>
<!ENTITY RFC4890 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4890.xml'>
<!ENTITY RFC5375 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5375.xml'>
<!ENTITY RFC6180 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6180.xml'>
<!ENTITY RFC4192 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4192.xml'>
<!ENTITY RFC4193 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY RFC4862 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
<!ENTITY RFC3315 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY RFC5340 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml'>
<!ENTITY RFC3596 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596.xml'>
<!ENTITY RFC4760 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml'>
<!ENTITY RFC6296 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml'>
<!ENTITY RFC5308 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml'>
<!ENTITY RFC2080 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2080.xml'>
<!ENTITY RFC2081 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2081.xml'>
<!ENTITY RFC2827 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml'>
<!ENTITY RFC3704 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml'>
<!ENTITY RFC6434 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6434.xml'>
<!ENTITY RFC6555 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6555.xml'>
<!ENTITY RFC6589 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6589.xml'>
<!ENTITY RFC3007 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007.xml'>
<!ENTITY RFC4795 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4795.xml'>
<!ENTITY RFC6105 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6105.xml'>
<!ENTITY RFC6583 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6583.xml'>
<!ENTITY RFC5952 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml'>
<!ENTITY RFC5838 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5838.xml'>
<!ENTITY RFC1912 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1912.xml'>





<!-- You need one entry like the following for each I-D referenced -->

<!ENTITY DRAFT-static SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6renum-static-problem.xml">
<!ENTITY DRAFT-renum SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6renum-enterprise.xml">
<!ENTITY DRAFT-multi SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat.xml">
<!ENTITY DRAFT-6204bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-6204bis.xml">
<!ENTITY DRAFT-design SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matthews-v6ops-design-guidelines.xml">

]>


<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-ietf-v6ops-icp-guidance-03" category="info" >


<front>
<title abbrev="IPv6 ICP and ASP Guidance">IPv6 Guidance for Internet Content and Application Service Providers</title>


<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <city>Auckland</city>
        <region></region>
        <code>1142</code>
        <country>New Zealand</country>
      </postal>
      
      <email>brian.e.carpenter@gmail.com</email>
    </address>
</author>


   <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus</street>
          <street>No.156 Beiqing Road</street>
          <city>Hai-Dian District, Beijing</city>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>


 <date day="31" month="August" year="2012" />

<area>Operations and Management</area>
<workgroup>V6OPS</workgroup>


<abstract>

<t>This document provides guidance and suggestions for Internet Content Providers and Application Service Providers
who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting
providers, or to any enterprise network preparing for IPv6 users.
</t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">

<t>The deployment of IPv6 <xref target="RFC2460"/> is now in progress, and users 
without direct IPv4 access are likely to appear in increasing
numbers in the coming years. Any provider of content or application services over the Internet will need to arrange for
IPv6 access or else risk losing large numbers of potential users. For users who already have dual stack
connectivity, direct IPv6 access might provide more satisfactory performance than indirect access via
NAT. </t>

<t>In this document, we often refer to the users of
content or application services as "customers" to clarify the part they play, but this is not intended to limit
the scope to commercial sites. </t>

<t>The time for action is now, while
the number of IPv6-only customers is small, so that appropriate skills, software and equipment can be acquired
in good time to scale up the IPv6 service as demand increases. An additional advantage of early support for
IPv6 customers is that it will reduce the number of customers connecting later via IPv4 "extension" solutions
such as double NAT or NAT64 <xref target="RFC6146"/>, which will otherwise degrade the user experience. </t>

<t>Nevertheless, it is important that the introduction of IPv6 service should not make service for IPv4
customers worse. In some circumstances, technologies intended to assist in the transition from IPv4 to IPv6
are known to have negative effects on the user experience. A deployment strategy for IPv6 must avoid these
effects as much as possible.  </t>

<t>The purpose of this document is to provide guidance and suggestions for Internet Content Providers (ICPs)
and Application Service Providers (ASPs) who wish to offer their services to both IPv6 and IPv4 customers,
but who are currently supporting only IPv4. 
For simplicity, the term ICP is mainly used in the body of this document, but the guidance
also applies to ASPs. Any hosting provider whose customers include ICPs or ASPs is also concerned.
Many of the points in this document will also apply to enterprise networks that do not
classify themselves as ICPs. Any enterprise or department that runs at least one externally accessible
server, such as an HTTP server, may also be concerned. Although specific managerial and technical
approaches are described, this is not a rule book; each operator will need to make its own plan, tailored
to its own services and customers. </t>

</section> <!-- intro -->

<section anchor="strat" title="General Strategy">

<t>The most importance advice here is to actually have a general strategy. Adding support for a second
network layer protocol is a new experience for most modern organisations, and it cannot be done casually
on a unplanned basis. Even if it is impossible to write a precisely dated
plan, the intended steps in the process need to be defined well in advance. There is no single
blueprint for this. The rest of this document is meant to provide a set of topics to be taken
into account in defining the strategy. Other documents about IPv6 deployment, such as
<xref target="I-D.matthews-v6ops-design-guidelines"/>, should be consulted as well. </t>

<t>In determining the urgency of this strategy, it should be noted that the central IPv4 registry
(IANA) ran out of spare blocks of IPv4 addresses in February 2011 and the various regional
registries are expected to exhaust their reserves over the next one to two years. After this, Internet
Service Providers (ISPs) will run out at dates determined by their own customer base. No precise
date can be given for when IPv6-only customers will appear in commercially significant numbers,
but - particularly in the case of mobile users - it may be quite soon. Complacency about this
is therefore not an option for any ICP that wishes to grow its customer base over the coming
years. </t>

<t>The most common strategy for an ICP is to provide dual stack services - both IPv4 and IPv6
on an equal basis - to cover both existing and future customers. This is the recommended
strategy in <xref target="RFC6180"/> for straightforward situations. Some ICPs who already have
satisfactory operational experience with IPv6 might consider an IPv6-only strategy, with IPv4
clients being supported by translation or proxy in front of their IPv6 content servers. However, the present document
is addressed to ICPs without IPv6 experience, who are likely to prefer the dual stack model to build
on their existing IPv4 service. </t>

<t>Due to the widespread impact of supporting IPv6 everywhere within an environment,
it is important to select a focussed initial approach based on clear business needs and real technical
dependencies. </t>

<t>Within the dual stack model,
two approaches could be adopted, sometimes referred to as "outside in" and "inside out":</t>
  <t><list style = "symbols">
    <t>Outside in: start by providing external users with an IPv6 public access to your services,
       for example by running a reverse proxy that handles IPv6 customers (see <xref target="proxy"/> for details).
       Progressively enable IPv6 internally. </t>
    <t>Inside out: start by enabling internal networking infrastructure, hosts, and applications
       to support IPv6. Progressively reveal IPv6 access to external customers. </t>
  </list></t>

<t>Which of these approaches to choose depends on the precise circumstances of the ICP concerned.
"Outside in" has the benefit of giving interested customers IPv6 access at an early stage, and thereby
gaining precious operational experience, before meticulously updating every piece of equipment
and software. For example, if some back-office system, that is never exposed to users, only supports
IPv4, it will not cause delay. "Inside out" has the benefit of completing the implementation of
IPv6 as a single project. Any ICP could choose this approach, but it might be most appropriate
for a small ICP without complex back-end systems. </t>

<t>A point that must be considered in the strategy is that some customers will remain IPv4-only for
many years, others will have both IPv4 and IPv6 access, and yet others will have only IPv6. Additionally,
mobile customers may find themselves switching between IPv4 and IPv6 access as they travel, even within
a single session. Services and applications must be able to deal with this, just as easily as they
deal today with a user whose IPv4 address changes (see the discussion of cookies in <xref target="appl"/>). </t>

<t>Nevertheless, the end goal is to have a network that does not need major changes when at some point
in the future it becomes possible to transition to IPv6-only, even if only for some parts of the network.
That is, the IPv6 deployment should be designed in such a way as to more or less assume that IPv4 is
already absent, so the network will function seamlessly when it is indeed no longer there. </t>

<t>An important step in the strategy is to determine from hardware and software
suppliers details of their planned dates for providing sufficient IPv6 support, with performance
equivalent to IPv4, in their products and services. Relevant specifications such
as <xref target="RFC6434"/> <xref target="I-D.ietf-v6ops-6204bis"/> should be used. 
Even if complete information cannot be
obtained, it is essential to determine which components are on the critical path during
successive phases of deployment. This
information will make it possible to draw up a logical sequence of events and identify
any components that may cause holdups. </t>

</section> <!-- strat -->

<section anchor="edu" title="Education and Skills">

<t>Some staff may have experience of running multiprotocol networks, which were common
twenty years ago before the dominance of IPv4. However, IPv6 will be new to them, and also
to staff brought up only on TCP/IP. It is not enough to have one "IPv6 expert" in a team.
On the contrary, everybody who knows about IPv4 needs to know about IPv6, from network architect
to help desk responder. Therefore, an early and essential part of the strategy must be 
education, including practical training, so that all staff acquire a general understanding 
of IPv6, how it affects basic features such as the DNS, and the relevant practical skills. 
To take a trivial example, any staff used to dotted-decimal IPv4 addresses need to become
familiar with the colon-hexadecimal format used for IPv6. </t>

<t>There is an anecdote of one IPv6 deployment in which prefixes including the letters A to F
were avoided by design, to avoid confusing system administrators unfamiliar with hexadecimal notation.
This is not a desirable result. There is another anecdote of a help desk responder telling a customer
to "disable one-Pv6" in order to solve a problem. It should be a goal to avoid having untrained staff who
don't understand hexadecimal or who can't even spell "IPv6". </t>

<t>It is very useful to have a small laboratory network available for training and self-training
in IPv6, where staff may experiment and make mistakes without disturbing the operational IPv4
service. This lab should run both IPv4 and IPv6, to gain experience with a dual-stack environment
and new features such as having multiple addresses per interface, and addresses with lifetimes and deprecation. </t>

<t>Once staff are trained, they will likely need to support both IPv4, IPv6, and dual-stack customers.
Rather than having separate internal escalation paths for IPv6, it generally makes sense for
questions that may have an IPv6 element to follow normal escalation paths; there should
not be an "IPv6 Department" once training is completed. </t>


<t>A final remark about training is that it should not be given too soon, or it will be forgotten.
Training has a definite need to be done "just in time" in order to properly "stick."
Training, lab experience, and actual deployment should therefore follow each other immediately.
If possible, training should even be combined with actual operational experience. </t>

</section> <!-- edu -->

<section anchor="isp" title="Arranging IPv6 Connectivity">

<t>There are, in theory, two ways to obtain IPv6 connectivity to the Internet. </t>
  <t><list style="symbols">
    <t>Native. In this case the ISP simply provides IPv6 on exactly the same basis
       as IPv4 - it will appear at the ICP's border router(s), which must then be
       configured in dual-stack mode to forward IPv6 packets in both directions.
       This is by far the better method. An ICP should contact all its ISPs to
       verify when they will provide native IPv6 support, whether this has any
       financial implications, and whether the same service level agreement will
       apply as for IPv4. Any ISP that has no definite plan to offer native IPv6 service
       should be avoided. </t>
    <t>Managed Tunnel. It is possible to configure an IPv6-in-IPv4 tunnel to a remote ISP
       that offers such a service. A dual-stack router in the ICP's network will act
       as a tunnel end-point, or this function could be included in the ICP's border router.
    <vspace blankLines="1" />
       A managed tunnel is a reasonable way to obtain IPv6 connectivity for initial testing and
       skills acquisition. However, it introduces an inevitable extra latency compared
       to native IPv6, giving customers a noticeably worse response time for complex web pages.
       A tunnel may become a performance bottleneck (especially if offered as a free
       service) or a target for malicious attack.
       It is also likely to limit the IPv6 MTU size. In normal circumstances, native IPv6
       will provide an MTU size of at least 1500 bytes, but it will almost inevitably be less
       for a tunnel, possibly as low as 1280 bytes (the minimum MTU allowed for IPv6).
       Apart from the resulting loss of efficiency, there are cases in which Path MTU
       Discovery fails, therefore IPv6 fragmentation fails, and in this case the lower
       tunnel MTU will actually cause connectivity failures for customers.
    <vspace blankLines="1" />
       For these reasons,
       ICPs are strongly recommended to obtain native IPv6 service before attempting
       to offer a production-quality service to their customers. Unfortunately it is impossible to
       prevent customers from using unmanaged tunnel solutions (see <xref target="xition"/>). </t>
   </list></t>

<t>Some larger organizations may find themselves needing multiple forms of IPv6 connectivity,
for their ICP data centres and for their staff working elsewhere. It is important to obtain
IPv6 connectivity for both, as testing and supporting an IPv6-enabled service is challenging
for staff without IPv6 connectivity. This may involved short-term alternatives to provide
IPv6 connectivity to operations and support staff, such as a managed tunnel or HTTP proxy
server with IPv6 connectivity.  Note that unmanaged tunnels (such as 6to4 and Teredo) 
are generally not useful for support staff as recent client software will avoid them when
accessing dual-stack sites.</t>



</section> <!-- isp -->

<section anchor="site" title="IPv6 Infrastructure">
 <section anchor="addr" title="Address and subnet assignment">
 <t>An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix
 for IPv6. This option is available to an ICP willing to deal directly with the relevant
 Regional Internet Registry and pay the associated fees. The alternative is to obtain a 
 Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However,
 the scaling properties of the wide area routing system (BGP4) limit the routing of PI prefixes,
 so only large content providers can justify the bother and expense of obtaining a PI prefix and
 convincing their ISPs to route it.
 Millions of enterprise networks, including smaller content providers, will use PA prefixes.
 In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using
 the procedure outlined in <xref target="RFC4192"/>. 
 <vspace blankLines="1" />
 An ICP that has connections via multiple ISPs, but does not have a PI prefix, would
 have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers
 or load balancers. If one address fails due to an ISP malfunction,
 sessions using that address would be lost. At the time of this writing, there is very limited
 operational experience with this approach <xref target="I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat"/>.
 
 </t>

 <t>An ICP may also choose to operate a Unique Local Address prefix <xref target="RFC4193"/> for internal
 traffic only, as described in <xref target="RFC4864"/>. </t>

 <t>Depending on its projected future size, an ICP might choose to obtain /48 PI or PA prefixes (allowing
 16 bits of subnet address) or longer PA prefixes, e.g. /56 (allowing 8 bits of subnet address). 
 Clearly the choice of /48 is more future-proof. Advice
 on the numbering of subnets may be found in <xref target="RFC5375"/>.
 An ICP with multiple locations will probably need a prefix per location </t> 


 <t>Since IPv6 provides for operating multiple prefixes simultaneously, it is important to check that
 all relevant tools, such as address management packages, can deal with this. In particular, the possible
 need to allow for multiple PA prefixes with IPv6, and the possible need to renumber, means that 
 the common technique of manually assigned static addresses for servers, proxies or load balancers,
 with statically defined DNS entries, could be problematic <xref target="I-D.ietf-6renum-static-problem"/>.
 An ICP of reasonable size might instead choose to operate DHCPv6 <xref target="RFC3315"/> with standard
 DNS, to support stateful assignment. In either case a configuration management system is likely
 to be used to support stateful and/or on-demand address assignment.</t>

 <t>Theoretically, it would also be possible to operate an ICP's IPv6 network using only
 Stateless Address Autoconfiguration <xref target="RFC4862"/>, with Dynamic DNS <xref target="RFC3007"/>
 to publish server addresses for external users.
 </t>
 </section>

 <section anchor="rout" title="Routing">
 <t>In a dual stack network, most IPv4 and IPv6 interior routing protocols operate quite independently and 
 in parallel. The common routing protocols all support IPv6, such as OSPFv3 <xref target="RFC5340"/>,
 IS-IS <xref target="RFC5308"/>, and even RIPng <xref target="RFC2080"/> <xref target="RFC2081"/>. 
 It is worth noting that whereas OSPF and RIP differ significantly between IPv4 and IPv6,
 IS-IS has the advantage of handling them both in a single instance of the protocol, with the potential
 for operational  simplification in the long term. Some versions of OSPFv3 may also have
 this advantage <xref target="RFC5838"/>. In any case, for
 trained staff, there should be no particular difficulty in deploying IPv6 routing without
 disturbance to IPv4 services. In some cases, firmware upgrades may be needed on
 some network devices. </t>

 <t>The performance impact of dual stack routing needs to be evaluated. In particular, what
 forwarding performance does the router vendor claim for IPv6? If the forwarding performance is significantly
 inferior compared to IPv4, will this be an operational problem? Is extra memory or TCAM space needed
 to accommodate both IPv4 and IPv6 tables? To answer these questions, the ICP will
 need a projected model for the amount of IPv6 traffic expected initially, and its likely
 rate of increase. </t>

 <t>If a site has multiple PA prefixes as mentioned in <xref target="addr"/>, complexities will appear in
routing configuration. In particular, source-based routing rules might be needed
to ensure that outgoing packets are routed to the appropriate border router and ISP link.
Normally, a packet sourced from an address assigned by ISP X should not be sent via ISP Y,
to avoid ingress filtering by Y <xref target="RFC2827"/> <xref target="RFC3704"/>. 
Additional considerations may be found in <xref target="I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat"/>. </t>

 <t>Each IPv6 subnet that supports end hosts normally has a /64 prefix, leaving another 64 bits for the
 interface identifiers of individual hosts. In contrast, a typical IPv4 subnet will have no more than 8 bits
 for the host identifier, thus limiting the subnet to 256 or fewer hosts. A dual stack design will typically
 use the same physical or VLAN subnet topology for IPv4 and IPv6, and therefore the same router topology.
 In other words the IPv4 and IPv6 topologies are congruent. This means that the limited subnet size of IPv4
 (such as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix will allow many more hosts. It would
 be theoretically possible to avoid this limitation by implementing a different physical or VLAN subnet topology
 for IPv6. This is not advisable, as it would result in extremely complex fault diagnosis when something went wrong. </t>
 </section>

 <section title="DNS">

 <t>It must be understood that as soon as an AAAA record for a well-known name
 is published in the DNS, the corresponding server will start to receive IPv6 traffic. Therefore,
 it is essential that an ICP tests thoroughly that IPv6 works on its servers, load
 balancers, etc., before adding their AAAA records to DNS. There have been numerous
 cases of ICPs breaking their sites for all IPv6 users during a roll-out by returning
 AAAA records for servers improperly configured for IPv6. </t>

 <t>Once such tests have succeeded, each externally visible host
 (or virtual host) that has an A record for its IPv4 address needs an AAAA
 record <xref target="RFC3596"/> for its IPv6 address, and a reverse entry 
 (in ip6.arpa) if applicable. Note that if CNAME records are in use, the AAAA
 record must be added alongside the A record at the end of the CNAME chain.
 It is not possible to have the AAAA record on the same 
 name as a CNAME record, as per <xref target="RFC1912"/>. </t>

 <t>One important
 detail is that some clients (especially Windows XP) can only resolve DNS names
 via IPv4, even if they can use IPv6 for application traffic. Also, a dual stack
 resolver might attempt to resolve queries for A records via IPv6, or AAAA records
 via IPv4. It is therefore
 advisable for all DNS servers to respond to queries via both IPv4 and IPv6. </t>


 </section>

</section> <!-- site -->

<section anchor="load" title="Load Balancers">
 
<t>Most available load balancers now support IPv6. However, it is important to obtain appropriate 
assurances from vendors about their IPv6 support, including performance aspects (as discussed for 
routers in <xref target="rout"/>). The update needs to be planned in anticipation of expected traffic
growth. It is to be expected that IPv6 traffic will initially be low, 
i.e., a small but growing percentage of total traffic. For this reason, it might be acceptable to have IPv6
traffic bypass load balancing initially, by publishing an AAAA record for a specific server instead
of the load balancer. However, load balancers often also provide for server fail-over, in which case
it would be better to implement IPv6 load balancing immediately. </t>

<t>The same would apply to TLS or HTTP proxies used for load balancing purposes. </t>

</section> <!-- load -->

<section anchor="proxy" title="Proxies">

<t>An HTTP proxy <xref target="RFC2616"/> can readily be configured to handle incoming connections over IPv6 and to proxy them
to a server over IPv4. Therefore, a single proxy can be used as the first step in an outside-in strategy, as
shown in the following diagram: </t>
<figure><artwork>
     ___________________________________________
    (                                           )
    (        IPv6 Clients in the Internet       )
    (___________________________________________)
                         | 
                   -------------
                   |  Ingress  |
                   |  router   |
                   -------------
             ____________|_____________
                         |            
                   -------------
                   | IPv6 stack|
                   |-----------|
                   | HTTP proxy|
                   |-----------|
                   | IPv4 stack| 
                   -------------
             ____________|_____________
                         |            
                   -------------
                   | IPv4 stack|
                   |-----------|
                   |   HTTP    |
                   |  server   | 
                   -------------

 </artwork> </figure>               
<t>In this case, the AAAA record for the service would provide the IPv6 address of the proxy.
This approach will work for any HTTP or HTTPS applications that operate successfully
via a proxy, as long as IPv6 load remains low. Additionally, many load balancer products
incorporate such a proxy, in which case this approach would be possible at high load. </t>

<t>Note that in any proxy scenario, an ICP will 
need to make sure that both IPv4 and IPv6 addresses are being properly passed
to application servers in any relevant HTTP headers, and that those application
servers are properly handling the IPv6 addresses.</t>

</section> <!-- proxy -->

<section anchor="serv" title="Servers">

 <section title="Network Stack">
 <t>The TCP/IP network stacks in popular operating systems have supported IPv6 for many years. In most
 cases, it is sufficient to enable IPv6 and possibly DHCPv6; the rest will follow. Servers inside an ICP network will
 not need to support any transition technologies beyond a simple dual stack, with a possible exception
 for 6to4 mitigation noted below in <xref target="xition"/>. </t>

 <t>As some operating systems have separate firewall rule sets for IPv4 and IPv6,
 an ICP should also evaluate those rule sets and ensure that appropriate firewall rules
 are configured for IPv6.  More details are discussed in <xref target="security"/>. </t>
 </section>

 <section anchor="appl" title="Application Layer">

 <t>Basic HTTP servers have been able to handle an IPv6-enabled network stack for some years, so at the most
 it will be necessary to update to a more recent software version. The same is true of generic applications
 such as email protocols. No general statement can be made about other applications, especially proprietary
 ones, so each ASP will need to make its own determination. 
 As changes to the network layer to introduce IPv6 addresses can ripple through applications,
 testing of both client and server applications should be performed in both IPv4-only, IPv6-only,
 and dual-stack environments prior to dual-stacking a production environment. </t>


  <t>One important recommendation here is that all applications should use domain names, which are IP-version-independent, 
 rather than IP addresses. Applications based on middlware platforms which have uniform support for IPv4 and IPv6,
  for example Java, may be able to support both IPv4 and IPv6 naturally without additional work. </t>
 
<t>A specific issue for HTTP-based services is that IP address-based cookie authentication schemes
 will need to deal with dual-stack clients. Servers might create a cookie for an
 IPv4 connection or an IPv6 connection, depending on the setup at the client site and
 on the whims of the client operating system. There is no guarantee that a given client
 will consistently use the same address family, especially when accessing a collection
 of sites rather than a single site, such as when cookies are used for federated authentication.
 If the client is using privacy addresses <xref target="RFC4941"/>,
 the IPv6 address (but usually not its /64 prefix) might change quite frequently. Any cookie mechanism
 based on 32-bit IPv4 addresses will need significant remodelling. </t>

 <t>Generic considerations on application transition are discussed in <xref target="RFC4038"/>, but
 many of them will not apply to the dual-stack ICP scenario. An ICP that creates and maintains its
 own applications will need to review them for any dependency on IPv4. </t>
 </section>

 <section anchor="logs" title="Logging">
   <t>The introduction of IPv6 clients will generally also result in IPv6 addresses
   appearing in the "client ip" field of server logs.  It might be convenient to use
   the same log field to hold a client's IP address, whether it is IPv4 or IPv6.
   Downstream systems looking at logs and client IP addresses may also need
   testing to ensure that they can properly handle IPv6 addresses.
   This includes any of an ICP's databases recording client IP addresses, such
   as for recording IP addresses of online purchases and comment posters.</t>

   <t>It is worth noting that accurate traceback from logs to individual customers
   requires end-to-end address transparency. This is additional motivation for
   an ICP to support native IPv6 connectivity, since otherwise, IPv6-only customers
   will inevitably connect via some form of translation mechanism, interfering with
   traceback. </t>
  </section>

 <section title="Geolocation">
 <t>Initially, ICPs may observe some weakness in geolocation for IPv6 clients. As time goes on,
 it is to be assumed that geolocation methods and databases will be updated to
 fully support IPv6 prefixes. There is no reason they will be more or less accurate in the long term
 than those available for IPv4. However, we can expect many more clients to be mobile
 as time goes on, so geolocation based on IP addresses alone may in any case become problematic. </t>
 </section> 

</section> <!-- serv -->

<section anchor="xition" title="Coping with Transition Technologies">

<t>As mentioned above, an ICP should obtain native IPv6 connectivity from
its ISPs. In this way, the ICP can avoid most of the complexities of the numerous
IPv4-to-IPv6 transition technologies that have been developed; they are all second-best solutions.
However, some clients are sure to be using such technologies. An ICP needs to be aware of
the operational issues this may cause and how to deal with them. </t>

<t>In some cases outside the ICP's control, clients might reach a content server via a network-layer
translator from IPv6 to IPv4. ICPs who are offering a dual stack service and providing both A
and AAAA records, as recommended in this document, should not normally receive IPv4 traffic from NAT64
translators <xref target="RFC6146"/>. Exceptionally, however, such traffic could arrive via IPv4 
from an IPv6-only client whose DNS resolver failed to receive the ICP's AAAA record for some reason.
Such traffic would be indistinguishable from regular IPv4-via-NAT traffic. </t>

<t>Alternatively, ICPs who are offering a dual stack service might exceptionally receive
IPv6 traffic translated from an IPv4-only client that somehow failed to receive the ICP's
A record. An ICP could also receive IPv6 traffic with translated prefixes <xref target="RFC6296"/>.
These two cases would only be an issue if the ICP was offering any service that depends
on the assumption of end-to-end IPv6 address transparency. </t>

<t>Finally, some traffic might reach an ICP that has been translated twice en route (e.g.,
from IPv6 to IPv4 and back again). Again, the ICP will be unable to detect this. It is likely
that real-time geolocation will be highly inaccurate for such traffic, since it will at best indicate
the location of the second translator, which could be very distant from the customer. </t>

<t>In other cases, also outside the ICP's control, IPv6 clients may reach the IPv6 Internet via 
some form of IPv6-in-IPv4 tunnel. In this case a variety of problems can arise, the most acute 
of which affect clients connected using the Anycast 6to4 solution <xref target="RFC3068"/>. 
Advice on how ICPs may mitigate these 6to4 problems is given in Section 4.5. of <xref target="RFC6343"/>.
For the benefit of all tunnelled clients, it is essential to verify
that Path MTU Discovery works correctly (i.e., the relevant ICMPv6 packets are not blocked)
and that the server-side TCP implementation correctly supports the Maximum Segment Size (MSS) 
negotiation mechanism <xref target="RFC2923"/> for IPv6 traffic. </t>

<t>Some ICPs have implemented an interim solution to mitigate transition problems 
by limiting the visibility of their AAAA records to users with validated IPv6 
connectivity <xref target="RFC6589"/> (known as "DNS whitelisting"). At the time of this writing,
this solution seems to be passing out of use, being replaced by "DNS blacklisting" of
customer sites known to have problems with IPv6 connectivity. 
In the reverse direction, it is worth being 
aware that some ISPs with significant populations of clients with broken IPv6 setups have begun
filtering AAAA record lookups by their clients.
None of these solutions is appropriate in the long term. </t>

<t>Another approach taken by some ICPs is to offer IPv6-only support via a specific DNS
name, e.g., ipv6.example.com, if the primary service is www.example.com. In this case
ipv6.example.com would have an AAAA record only. This has some
value for testing purposes, but is otherwise only of interest to hobbyist users
willing to type in special URLs. </t>

<t>There is little an ICP can do to deal with client-side or remote ISP deficiencies in IPv6 support,
but it is hoped that the "happy eyeballs" <xref target="RFC6555"/> approach
will improve the ability for clients to deal with such problems. </t>

</section> <!-- xition -->

<section anchor="cdn" title="Content Delivery Networks">

<t>DNS-based techniques for diverting users to Content Delivery Network (CDN) points of presence (POPs)
will work for IPv6, if AAAA records are provided as well as A records. In general the CDN should follow
the recommendations of this document, especially by operating a full dual stack service
at each POP. Additionally, each POP will need to handle IPv6 routing exactly like IPv4,
for example running BGP4+ <xref target="RFC4760"/>. </t>

<t>Note that if an ICP supports IPv6 but its external CDN provider does not, its clients will continue to use
IPv4 and any IPv6-only clients will have to use a transition solution of some kind. This is
not a desirable situation, since the ICP's work to support IPv6 will be wasted. </t>

<t>An ICP might face a complex situation, if its CDN provider
supports IPv6 at some POPs but not at others. IPv6-only clients could only be diverted
to a POP supporting IPv6. There are also scenarios where a dual-stack client would be diverted
to a mixture of IPv4 and IPv6 POPs for different URLs, according to the A and AAAA records provided
and the availability of optimisations such as "happy eyeballs." A related side effect is that
copies of the same content viewed at the same time via IPv4 and IPv6 may be different,
due to latency in the underlying data synchronisation process used by the CDN. This effect has
in fact been observed in the wild for a major social network supporting dual stack.
These complications do not affect the viability of relying on a dual-stack CDN, however. </t>

<t>The CDN itself faces related complexity: "As IPv6 rolls out, it's going to roll 
out in pockets, and that's going to make the routing around congestion points that much more 
important but also that much harder," stated John Summers of Akamai in 2010. 
</t>

<t>A converse situation that might arise is that an ICP has not yet started its
deployment of IPv6, but finds that its CDN provider already supports IPv6. 
Then, assuming the CDN provider announces appropriate AAAA DNS Resource Records,
dual-stack and IPv6-only customers will obtain IPv6 access
and the ICP's content may well be delivered to them via IPv6. In normal
circumstances this should create no problems, but it is a situation that the
ICP and its support staff need to be aware of. In particular, support staff
should be given IPv6 connectivity in order to be able to investigate
any problems that might arise (see <xref target="isp"/>). </t> 

</section> <!-- cdn -->

<section anchor="partner" title="Business Partners">
<t>As noted earlier, it is in an ICP's or ASP's best interests that their users have direct
IPv6 connectivity, rather than indirect IPv4 connectivity via double NAT. If the ICP or ASP 
has a direct business relationship with some of their clients, or with the networks that connect them to their
clients, they are advised to coordinate with those partners to ensure that they have a plan to enable IPv6.
They should also verify and test that there is first-class IPv6 connectivity end-to-end between the networks concerned.
This is especially true for implementations that require IPv6 support in specialized programs or systems
in order for the IPv6 support on the ICP/ASP side to be useful. </t>

</section> <!-- partner -->


<section anchor="complex" title="Possible Complexities">

<t>Some additional considerations come into play for some types of complex or distributed
sites and applications that an ICP may be delivering.  For example, an ICP
may have a site spread across many hostnames (not all under their control).  
Other ICPs may have their sites or applications distributed across multiple locations
for availability, scale, or performance.</t>

<t>Many modern web sites and applications now use a collection of resources
and applications, some operated by the ICP and other by third parties.
While most clients support sites containing a mixture of IPv4-only and dual-stack
elements, an ICP should track the IPv6 availability of embedded resources (such 
as images) as otherwise their site may only be partially functional or may
have degraded performance for IPv6-only users.</t>

<t>DNS-based load balancing techniques for diverting users to servers in multiple POPs
will work for IPv6, if the load balancer supports IPv6 and if AAAA records are provid. 
Depending on the architecture of the load balancer, an ICP may need
to operate a full dual stack service
at each POP.  With other architectures, it may be acceptable to initially
only have IPv6 at a subset of locations. Some architectures will make it preferable
for IPv6 routing to mirror IPv4 routing (for example running BGP4+ <xref target="RFC4760"/> if appropriate)
but this may not always be possible as IPv6 and IPv4 connectivity can be independent. </t>

<t>Some complexities may arise when a client supporting both IPv4 and IPv6 
uses different POPs for each IP version (such as when IPv6 is only available
in a subset of locations). There are also scenarios where a dual-stack client would be diverted
to a mixture of IPv4 and IPv6 POPs for different URLs, according to the A and AAAA records provided
and the availability of optimisations such as "happy eyeballs" <xref target="RFC6555"/>. A related side effect is that
copies of the same content viewed at the same time via IPv4 and IPv6 may be different,
due to latency in the underlying data synchronisation process used at the application layer. This effect has
in fact been observed in the wild for a major social network supporting dual-stack.</t>

<t>Even with a single POP, unexpected behaviour may arise if a client switches spontaneously
between IPv4 and IPv6 as a performance optimisation <xref target="RFC6555"/> or if its
IPv6 address changes frequently for privacy reasons <xref target="RFC4941"/>. Such
changes may affect cookies, geolocation, load balancing, and transactional integrity. Although
unexpected changes of client address also occur in an IPv4-only environment, they may be
more frequent with IPv6. </t>

</section> <!-- complex -->



<section anchor="oam" title="Operations and Management">

<t>There is no doubt that, initially, IPv6 deployment will have operational impact, as well as
requiring education and training as mentioned in <xref target="edu"/>. Staff will have to update
network elements such as routers, update configurations, provide information to end users,
and diagnose new problems. However, for an enterprise network, there is plenty of experience,
e.g. on numerous university campuses, showing that dual stack operation is no harder than IPv4-only
in the steady state. </t>

<t>Whatever management, monitoring and logging is performed for IPv4 is also needed for IPv6. Therefore,
all products and tools used for these purposes must be updated to fully support IPv6. 
It is important to verify that tools have been fully updated to support 128 bit addresses
entered and displayed in hexadecimal <xref target="RFC5952"/>.
Since an IPv6 network may operate with more than one IPv6 prefix and therefore more than
one address per host, the tools must deal with this as a normal situation. This includes
any address management tool in use (see <xref target="addr"/>) as well as tools used
for creating DHCP and DNS configurations. There is significant overlap here with the
tools involved in site renumbering <xref target="I-D.ietf-6renum-enterprise"/>. </t>

<t>As far as possible, however, mutual dependency between IPv4 and IPv6 operations should be avoided.
A failure of one should not cause a failure of the other. One precaution to avoid this would be for
back-end systems such as network management databases to be dual stacked as soon as convenient.
It should also be possible to use IPv4 connectivity to repair IPv6 configurations, and 
vice versa. </t>

<t>Dual stack, while necessary, does have management scaling and overhead considerations. As
noted earlier, the long term goal is to move to single-stack IPv6, when the network and 
its customers can support this. This is an additional reason why mutual dependency between the
address families should be avoided in the management system in particular; a hidden dependency
on IPv4 that had been forgotten for many years would be highly inconvenient. In particular,
a management tool that manages IPv6 but itself runs only over IPv4 would prove disastrous
on the day that IPv4 is switched off. </t>

<t>An ICP should ensure that any end-to-end availability monitoring systems are updated
to monitor dual-stacked servers over both IPv4 and IPv6.  A particular challenge here may be 
monitoring systems relying on DNS names as this may result in monitoring only
one of IPv4 or IPv6, resulting in a loss of visibility to failures in 
network connectivity over either address family.</t>

<t>As mentioned above, it will also be necessary for an ICP to provide IPv6 connectivity
for its operations and support staff, even when working remotely.</t>

</section> <!-- oam -->


<section anchor="security" title="Security Considerations">

<t>While many ICPs may still be in the process of experimenting with
and configuring IPv6, there is mature malware in the wild that will launch
attacks over IPv6. For example, if an AAAA DNS record is added for a hostname,
malware using client OS libraries may automatically switch from attacking that hostname over IPv4
to attacking that hostname over IPv6. As a result, it is crucial that firewalls and 
other network security appliances protecting servers support IPv6 and have rules
tested and configured. </t>

<t>Security experience with IPv4 should be used as a guide as to the threats that may exist in IPv6,
but they should not be assumed to be equally likely, and nor should they assumed to be the only threats
that could exist in IPv6. However, essentially every threat that exists for IPv4 exists or will
exist for IPv6, to a greater or lesser extent. It is essential to update firewalls, intrusion detection
systems, denial of service precautions, and security auditing technology to fully support IPv6.
Otherwise, IPv6 will become an attractive target for attackers. </t>

<t>When multiple PA prefixes are in use as mentioned in <xref target="addr"/>, firewall rules
must allow for all valid prefixes, and must be set up to work as intended even if
packets are sent via one ISP but return packets arrive via another. </t>

<t>Performance and memory size aspects of dual stack firewalls must be considered (as discussed for routers in <xref target="rout"/>). </t>

<t>In a dual stack operation, there may be a risk of cross-contamination between the two
protocols. For example, a successful IPv4-based denial of service attack might also
deplete resources needed by the IPv6 service, or vice versa. This risk strengthens the
argument that IPv6 security must be up to the same level as IPv4. </t>

<t>A general overview of techniques to protect an IPv6 network against external attack is given in
<xref target="RFC4864"/>. Assuming an ICP has native IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4
tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this kind should be blocked except
for the case noted in Section 4.5 of <xref target="RFC6343"/>. ICMPv6 traffic should only be blocked
in accordance with <xref target="RFC4890"/>; in particular, Packet Too Big messages, which are
essential for PMTU discovery, must not be blocked. </t>

<t>Brute-force scanning attacks to discover the existence of hosts are much less
likely to succeed for IPv6 than for IPv4 <xref target="RFC5157"/>. However, this should not
lull an ICP into a false sense of security, as various naming or addressing conventions can result
in IPv6 address space being predictable or guessable.  In the extreme case, IPv6 hosts
might be configured with interface identifiers that are very easy to guess; for example, 
hosts or subnets manually numbered with consecutive interface identifiers starting from "1"
would be much easier to guess. Such practices should be avoided, and other useful
precautions are discussed in <xref target="RFC6583"/>.
Also, attackers might find IPv6 addresses in logs, packet traces, DNS records (including
reverse records), or elsewhere. </t>

<t>Protection against rogue Router Advertisements (RA Guard) should also be considered
<xref target="RFC6105"/>. </t>

<t>Transport Layer Security version 1.2 <xref target="RFC5246"/> and its predecessors work
correctly with TCP over IPv6, meaning that HTTPS-based security solutions are immediately
applicable. The same should apply to any other transport-layer or application-layer security
techniques. </t>

<t>If an ASP uses IPsec <xref target="RFC4301"/> and IKE <xref target="RFC5996"/>
in any way to secure connections with clients, these too are fully
applicable to IPv6, but only if the software stack at each end has been appropriately updated. </t>

</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">
   <t>This document requests no action by IANA. </t>
</section> <!-- iana -->




<section anchor="ack" title="Acknowledgements">

<t>
Valuable contributions were made by Erik Kline. Useful comments were
received from
Tore Anderson,
Cameron Byrne,
Tassos Chatzithomaoglou,
Wesley George,
Deng Hui,
Joel Jaeggli,
Roger Jorgensen,
Victor Kuarsingh,
Bing Liu,
Trent Lloyd,
John Mann,
Michael Newbery,
Erik Nygren,
Arturo Servin,
Mark Smith,

and other participants in the V6OPS working group.
 </t>

<t>Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work. </t>

<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor: Please remove]">

<t>draft-ietf-v6ops-icp-guidance-03: text on multiple PA prefixes updated, numerous other WGLC comments, 2012-08-31.</t>

<t>draft-ietf-v6ops-icp-guidance-02: additional WG review, 2012-07-11.</t>

<t>draft-ietf-v6ops-icp-guidance-01: additional WG comments, 2012-06-12.</t>

<t>draft-ietf-v6ops-icp-guidance-00: adopted by WG, small updates, 2012-04-17.</t>

<t>draft-carpenter-v6ops-icp-guidance-03: additional WG comments, 2012-02-23.</t>

<t>draft-carpenter-v6ops-icp-guidance-02: additional WG comments, 2012-01-07.</t>

<t>draft-carpenter-v6ops-icp-guidance-01: multiple clarifications after WG comments, 2011-12-06.</t>

<t>draft-carpenter-v6ops-icp-guidance-00: original version, 2011-10-22.</t>


</section> <!-- changes -->

</middle>

<back>

<references title="Normative References">

&RFC2460;
&RFC5246;
&RFC4301;
&RFC5996;
&RFC2616;
&RFC4193;
&RFC4862;
&RFC3315;
&RFC5340;
&RFC3596;
&RFC4760;
&RFC5308;
&RFC2080;
&RFC2827;
&RFC3704;
&RFC6434;
&RFC3007;
<!-- &RFC4795; -->
&RFC5952;
&RFC5838;
&RFC4941;

</references>

<references title="Informative References">

&RFC2629;
&RFC6146;
&RFC6343;
&RFC2923;
&RFC5157;
&RFC3068;
&RFC4038;
&RFC4864;
&RFC4890;
&RFC5375;
&RFC6180;
&RFC4192;
&RFC6296;
&RFC2081;
&RFC6589;
&RFC6555;
&RFC6105;
&RFC6583;
&RFC1912;
&DRAFT-static;
&DRAFT-renum;
&DRAFT-multi;
&DRAFT-6204bis;
&DRAFT-design;

  
</references>




</back>
</rfc>