draft-ietf-v6ops-icp-guidance-01.txt   draft-ietf-v6ops-icp-guidance-02.txt 
V6OPS B. Carpenter V6OPS B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational S. Jiang Intended status: Informational S. Jiang
Expires: December 14, 2012 Huawei Technologies Co., Ltd Expires: January 12, 2013 Huawei Technologies Co., Ltd
June 12, 2012 July 11, 2012
IPv6 Guidance for Internet Content and Application Service Providers IPv6 Guidance for Internet Content and Application Service Providers
draft-ietf-v6ops-icp-guidance-01 draft-ietf-v6ops-icp-guidance-02
Abstract Abstract
This document provides guidance and suggestions for Internet Content This document provides guidance and suggestions for Internet Content
Providers and Application Service Providers who wish to offer their Providers and Application Service Providers who wish to offer their
service to both IPv6 and IPv4 customers. Many of the points will service to both IPv6 and IPv4 customers. Many of the points will
also apply to hosting providers, or to any enterprise network also apply to hosting providers, or to any enterprise network
preparing for IPv6 users. preparing for IPv6 users.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2012. This Internet-Draft will expire on January 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Strategy . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Strategy . . . . . . . . . . . . . . . . . . . . . . . 3
3. Education and Skills . . . . . . . . . . . . . . . . . . . . . 5 3. Education and Skills . . . . . . . . . . . . . . . . . . . . . 5
4. Arranging IPv6 Connectivity . . . . . . . . . . . . . . . . . 6 4. Arranging IPv6 Connectivity . . . . . . . . . . . . . . . . . 6
5. IPv6 Infrastructure . . . . . . . . . . . . . . . . . . . . . 7 5. IPv6 Infrastructure . . . . . . . . . . . . . . . . . . . . . 7
5.1. Address and subnet assignment . . . . . . . . . . . . . . 7 5.1. Address and subnet assignment . . . . . . . . . . . . . . 7
5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11
8.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 11
9. Coping with Transition Technologies . . . . . . . . . . . . . 11 9. Coping with Transition Technologies . . . . . . . . . . . . . 11
10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 13 10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 13
11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 13 11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 13
12. Operations and Management . . . . . . . . . . . . . . . . . . 14 12. Operations and Management . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
16. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 16 16. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 16
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
17.1. Normative References . . . . . . . . . . . . . . . . . . . 16 17.1. Normative References . . . . . . . . . . . . . . . . . . . 17
17.2. Informative References . . . . . . . . . . . . . . . . . . 17 17.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The deployment of IPv6 [RFC2460] is now in progress, and users with The deployment of IPv6 [RFC2460] is now in progress, and users with
no IPv4 access are likely to appear in increasing numbers in the no IPv4 access are likely to appear in increasing numbers in the
coming years. Any provider of content or application services over coming years. Any provider of content or application services over
the Internet will need to arrange for IPv6 access or else risk losing the Internet will need to arrange for IPv6 access or else risk losing
large numbers of potential customers. The time for action is now, large numbers of potential users. In this document, we refer to the
while the number of such customers is small, so that appropriate users of content or application services as "customers" to clarify
skills, software and equipment can be acquired in good time to scale the part they play, but this is not intended to limit the scope to
up the IPv6 service as demand increases. An additional advantage of commercial sites.
early support for IPv6 customers is that it will reduce the number of
customers connecting later via IPv4 "extension" solutions such as The time for action is now, while the number of IPv6-only customers
double NAT, which will otherwise degrade the user experience. 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, which will
otherwise degrade the user experience.
Nevertheless, it is important that the introduction of IPv6 service Nevertheless, it is important that the introduction of IPv6 service
should not make service for IPv4 customers worse. In some should not make service for IPv4 customers worse. In some
circumstances, technologies intended to assist in the transition from circumstances, technologies intended to assist in the transition from
IPv4 to IPv6 are known to have negative effects on the user IPv4 to IPv6 are known to have negative effects on the user
experience. A deployment strategy for IPv6 must avoid these effects experience. A deployment strategy for IPv6 must avoid these effects
as much as possible. as much as possible.
The purpose of this document is to provide guidance and suggestions The purpose of this document is to provide guidance and suggestions
for Internet Content Providers (ICPs) and Application Service for Internet Content Providers (ICPs) and Application Service
skipping to change at page 3, line 45 skipping to change at page 3, line 50
at least one externally accessible server, such as an HTTP server, at least one externally accessible server, such as an HTTP server,
may also be concerned. Although specific managerial and technical may also be concerned. Although specific managerial and technical
approaches are described, this is not a rule book; each operator will approaches are described, this is not a rule book; each operator will
need to make its own plan, tailored to its own services and need to make its own plan, tailored to its own services and
customers. customers.
2. General Strategy 2. General Strategy
The most importance advice here is to actually have a general The most importance advice here is to actually have a general
strategy. Adding support for a second network layer protocol is a strategy. Adding support for a second network layer protocol is a
new departure for most modern organisations, and it cannot be done new experience for most modern organisations, and it cannot be done
casually on a day-by-day basis. Even if it is impossible to write a 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 precisely dated plan, the intended steps in the process need to be
defined well in advance. There is no single blueprint for this. The 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 rest of this document is meant to provide a set of topics to be taken
into account in defining the strategy. into account in defining the strategy. Other documents about IPv6
deployment, such as [I-D.matthews-v6ops-design-guidelines], should be
consulted as well.
In determining the urgency of this strategy, it should be noted that In determining the urgency of this strategy, it should be noted that
the central IPv4 registry (IANA) ran out of spare blocks of IPv4 the central IPv4 registry (IANA) ran out of spare blocks of IPv4
addresses in February 2011 and the various regional registries are addresses in February 2011 and the various regional registries are
expected to exhaust their reserves over the next one to two years. expected to exhaust their reserves over the next one to two years.
After this, Internet Service Providers (ISPs) will run out at dates After this, Internet Service Providers (ISPs) will run out at dates
determined by their own customer base. No precise date can be given determined by their own customer base. No precise date can be given
for when IPv6-only customers will appear in commercially significant for when IPv6-only customers will appear in commercially significant
numbers, but - particularly in the case of mobile users - it may be numbers, but - particularly in the case of mobile users - it may be
quite soon. Complacency about this is therefore not an option for quite soon. Complacency about this is therefore not an option for
any ICP that wishes to grow its customer base over the coming years. any ICP that wishes to grow its customer base over the coming years.
The most common strategy for an ICP is to provide dual stack services 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 - both IPv4 and IPv6 on an equal basis - to cover both existing and
future customers. This is the recommended strategy in [RFC6180] for future customers. This is the recommended strategy in [RFC6180] for
straightforward situations. Some ICPs who already have satisfactory straightforward situations. Some ICPs who already have satisfactory
operational experience with IPv6 might consider an IPv6-only operational experience with IPv6 might consider an IPv6-only
strategy, with IPv4 clients being supported by translation or proxy strategy, with IPv4 clients being supported by translation or proxy
at their ISP border. However, the present document is addressed to in front of their IPv6 content servers. However, the present
ICPs without IPv6 experience, who are likely to prefer the dual stack document is addressed to ICPs without IPv6 experience, who are likely
model to build on their existing IPv4 service. to prefer the dual stack model to build on their existing IPv4
service.
Within the dual stack model, two approaches could be adopted, Within the dual stack model, two approaches could be adopted,
sometimes referred to as "outside in" and "inside out": sometimes referred to as "outside in" and "inside out":
o Outside in: start by providing external users with an IPv6 public o Outside in: start by providing external users with an IPv6 public
access to your services, for example by running a reverse proxy access to your services, for example by running a reverse proxy
that handles IPv6 customers (see Section 7 for details). that handles IPv6 customers (see Section 7 for details).
Progressively enable IPv6 internally. Progressively enable IPv6 internally.
o Inside out: start by enabling internal networking infrastructure, o Inside out: start by enabling internal networking infrastructure,
hosts, and applications to support IPv6. Progressively reveal hosts, and applications to support IPv6. Progressively reveal
skipping to change at page 6, line 7 skipping to change at page 6, line 15
not a desirable result. There is another anecdote of a help desk 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 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 problem. It should be a goal to avoid having untrained staff who
don't understand hexadecimal or who can't even spell "IPv6". don't understand hexadecimal or who can't even spell "IPv6".
It is very useful to have a small laboratory network available for It is very useful to have a small laboratory network available for
training and self-training in IPv6, where staff may experiment and training and self-training in IPv6, where staff may experiment and
make mistakes without disturbing the operational IPv4 service. This make mistakes without disturbing the operational IPv4 service. This
lab should run both IPv4 and IPv6, to gain experience with a dual- lab should run both IPv4 and IPv6, to gain experience with a dual-
stack environment and new features such as having multiple addresses stack environment and new features such as having multiple addresses
per interface. per interface, and addresses with lifetimes and deprecation.
A final remark about training is that it should not be given too 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 soon, or it will be forgotten. Training has a definite need to be
done "just in time" in order to properly "stick." Training, lab done "just in time" in order to properly "stick." Training, lab
experience, and actual deployment should therefore follow each other experience, and actual deployment should therefore follow each other
immediately. If possible, training should even be combined with immediately. If possible, training should even be combined with
actual operational experience. actual operational experience.
4. Arranging IPv6 Connectivity 4. Arranging IPv6 Connectivity
skipping to change at page 6, line 38 skipping to change at page 6, line 46
IPv4. Any ISP that has no definite plan to offer native IPv6 IPv4. Any ISP that has no definite plan to offer native IPv6
service should be avoided. service should be avoided.
o Tunnel. It is possible to configure an IPv6-in-IPv4 tunnel to a o 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 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 ICP's network will act as a tunnel end-point, or this function
could be included in the ICP's border router. could be included in the ICP's border router.
A tunnel is a reasonable way to obtain IPv6 connectivity for A tunnel is a reasonable way to obtain IPv6 connectivity for
initial testing and skills acquisition. However, it introduces an initial testing and skills acquisition. However, it introduces an
inevitable extra latency compared to native IPv6, giving users a inevitable extra latency compared to native IPv6, giving users a
noticeably worse response time for complex web pages. It is also noticeably worse response time for complex web pages. A tunnel
likely to limit the IPv6 MTU size. In normal circumstances, may become a performance bottleneck (especially if offered as a
native IPv6 will provide an MTU size of at least 1500 bytes, but free service) or a target for malicious attack. It is also likely
it will almost inevitably be less for a tunnel, possibly as low as to limit the IPv6 MTU size. In normal circumstances, native IPv6
1280 bytes (the minimum MTU allowed for IPv6). Apart from the 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 resulting loss of efficiency, there are cases in which Path MTU
Discovery fails, therefore IPv6 fragmentation fails, and in this Discovery fails, therefore IPv6 fragmentation fails, and in this
case the lower tunnel MTU will actually cause connectivity case the lower tunnel MTU will actually cause connectivity
failures for customers. failures for customers.
For these reasons, ICPs are strongly recommended to obtain native For these reasons, ICPs are strongly recommended to obtain native
IPv6 service before attempting to offer a production-quality IPv6 service before attempting to offer a production-quality
service to their users. service to their users.
5. IPv6 Infrastructure 5. IPv6 Infrastructure
skipping to change at page 7, line 42 skipping to change at page 8, line 6
subnets may be found in [RFC5375]. subnets may be found in [RFC5375].
Since IPv6 provides for operating multiple prefixes simultaneously, Since IPv6 provides for operating multiple prefixes simultaneously,
it is important to check that all relevant tools, such as address it is important to check that all relevant tools, such as address
management packages, can deal with this. In particular, the need to management packages, can deal with this. In particular, the need to
allow for multiple PA prefixes with IPv6, and the possible need to allow for multiple PA prefixes with IPv6, and the possible need to
renumber, means that using manually assigned static addresses for renumber, means that using manually assigned static addresses for
servers is problematic [I-D.carpenter-6renum-static-problem]. servers is problematic [I-D.carpenter-6renum-static-problem].
Theoretically, it would be possible to operate an ICP's IPv6 network Theoretically, it would be possible to operate an ICP's IPv6 network
using only Stateless Address Autoconfiguration [RFC4862]. In using only Stateless Address Autoconfiguration [RFC4862], and Dynamic
practice, an ICP of reasonable size will probably choose to operate DNS [RFC3007] or Multicast DNS [RFC4795]. In practice, an ICP of
DHCPv6 [RFC3315] and use it to support stateful and/or on-demand reasonable size will probably choose to operate DHCPv6 [RFC3315] with
address assignment. standard DNS, and use it to support stateful and/or on-demand address
assignment.
5.2. Routing 5.2. Routing
In a dual stack network, IPv4 and IPv6 routing protocols operate In a dual stack network, most IPv4 and IPv6 interior routing
quite independently and in parallel. The common routing protocols protocols operate quite independently and in parallel. The common
all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS routing protocols all support IPv6, such as OSPFv3 [RFC5340], IS-IS
[RFC5308], and even RIPng [RFC2080] [RFC2081]. It is worth noting [RFC5308], and even RIPng [RFC2080] [RFC2081]. It is worth noting
that whereas OSPF and RIP differ significantly between IPv4 and IPv6, that whereas OSPF and RIP differ significantly between IPv4 and IPv6,
IS-IS has the advantage of handling them both in the same way, with IS-IS has the advantage of handling them both in a single instance of
the potential for operational simplification in the long term. In the protocol, with the potential for operational simplification in
any case, for trained staff, there should be no particular difficulty the long term. In any case, for trained staff, there should be no
in deploying IPv6 routing without disturbance to IPv4 services. particular difficulty in deploying IPv6 routing without disturbance
to IPv4 services.
The performance impact of dual stack routing needs to be evaluated. The performance impact of dual stack routing needs to be evaluated.
In particular, what performance does the router vendor claim for In particular, what forwarding performance does the router vendor
IPv6? If the performance is significantly inferior compared to IPv4, claim for IPv6? If the forwarding performance is significantly
will this be an operational problem? Is extra memory or TCAM space inferior compared to IPv4, will this be an operational problem? Is
needed to accommodate both IPv4 and IPv6 tables? To answer these extra memory or TCAM space needed to accommodate both IPv4 and IPv6
questions, the ICP will need a projected model for the amount of IPv6 tables? To answer these questions, the ICP will need a projected
traffic expected initially, and its likely rate of increase. model for the amount of IPv6 traffic expected initially, and its
likely rate of increase.
If a site operates multiple PA prefixes as mentioned in Section 5.1, If a site operates multiple PA prefixes as mentioned in Section 5.1,
complexities may appear in routing configuration. In particular, complexities may appear in routing configuration. In particular,
source-based routing rules may be needed to ensure that outgoing source-based routing rules may be needed to ensure that outgoing
packets are routed to the appropriate border router and ISP link. packets are routed to the appropriate border router and ISP link.
Normally, a packet sourced from an address assigned by ISP X should Normally, a packet sourced from an address assigned by ISP X should
not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] not be sent via ISP Y, to avoid ingress filtering by Y [RFC2827]
[RFC3704]. Additional considerations may be found in [RFC3704]. Additional considerations may be found in
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat].
Each IPv6 subnet normally has a /64 prefix, leaving another 64 bits Each IPv6 subnet that supports end hosts normally has a /64 prefix,
for the interface identifiers of individual hosts. In contrast, a leaving another 64 bits for the interface identifiers of individual
typical IPv4 subnet will have no more than 8 bits for the host hosts. In contrast, a typical IPv4 subnet will have no more than 8
identifier, thus limiting the subnet to 256 or fewer hosts. A dual bits for the host identifier, thus limiting the subnet to 256 or
stack design will typically use the same subnet topology for IPv4 and fewer hosts. A dual stack design will typically use the same
IPv6, and therefore the same router topology. This means that the physical or VLAN subnet topology for IPv4 and IPv6, and therefore the
limited subnet size of IPv4 will be imposed on IPv6. It would be same router topology. In other words the IPv4 and IPv6 topologies
theoretically possible to avoid this limitation by implementing a are congruent. This means that the limited subnet size of IPv4 (such
different subnet and router topology for IPv6, for example by as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix
ingenious use of VLANs. This is not advisable, as it would result in will allow many more hosts. It would be theoretically possible to
extremely complex fault diagnosis when something went wrong. 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.
5.3. DNS 5.3. DNS
This is largely a case of "just do it." Each externally visible host This is largely a case of "just do it." Each externally visible host
(or virtual host) that has an A record for its IPv4 address needs an (or virtual host) that has an A record for its IPv4 address needs an
AAAA record [RFC3596] for its IPv6 address, and a reverse entry if AAAA record [RFC3596] for its IPv6 address, and a reverse entry if
applicable. One important detail is that some clients (especially applicable. One important detail is that some clients (especially
Windows XP) can only resolve DNS names via IPv4, even if they can use Windows XP) can only resolve DNS names via IPv4, even if they can use
IPv6 for application traffic. It is therefore advisable for all DNS IPv6 for application traffic. It is therefore advisable for all DNS
servers to respond to queries via both IPv4 and IPv6. servers to respond to queries via both IPv4 and IPv6.
skipping to change at page 11, line 28 skipping to change at page 11, line 28
support both IPv4 and IPv6 naturally without additional work. support both IPv4 and IPv6 naturally without additional work.
A specific issue for HTTP-based services is that IP address-based A specific issue for HTTP-based services is that IP address-based
cookie authentication schemes will need to deal with dual-stack cookie authentication schemes will need to deal with dual-stack
clients. Servers might create a cookie for an IPv4 connection or an 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 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 whims of the client operating system. There is no guarantee that a
given client will consistently use the same address family, given client will consistently use the same address family,
especially when accessing a collection of sites rather than a single especially when accessing a collection of sites rather than a single
site. If the client is using privacy addresses [RFC4941], the IPv6 site. If the client is using privacy addresses [RFC4941], the IPv6
address (but not its /64 prefix) might change quite frequently. Any address (but usually not its /64 prefix) might change quite
cookie mechanism based on 32-bit IPv4 addresses will need significant frequently. Any cookie mechanism based on 32-bit IPv4 addresses will
remodelling. need significant remodelling.
Generic considerations on application transition are discussed in Generic considerations on application transition are discussed in
[RFC4038], but many of them will not apply to the dual-stack ICP [RFC4038], but many of them will not apply to the dual-stack ICP
scenario. An ICP that creates and maintains its own applications scenario. An ICP that creates and maintains its own applications
will need to review them for any dependency on IPv4. will need to review them for any dependency on IPv4.
8.3. Geolocation 8.3. Geolocation
Initially, ICPs may observe some weakness in geolocation for IPv6 Initially, ICPs may observe some weakness in geolocation for IPv6
clients. As time goes on, it is to be assumed that geolocation clients. As time goes on, it is to be assumed that geolocation
skipping to change at page 12, line 40 skipping to change at page 12, line 40
affect clients connected using the Anycast 6to4 solution [RFC3068]. affect clients connected using the Anycast 6to4 solution [RFC3068].
Advice on how ICPs may mitigate these 6to4 problems is given in Advice on how ICPs may mitigate these 6to4 problems is given in
Section 4.5. of [RFC6343]. For the benefit of all tunnelled clients, Section 4.5. of [RFC6343]. For the benefit of all tunnelled clients,
it is essential to verify that Path MTU Discovery works correctly it is essential to verify that Path MTU Discovery works correctly
(i.e., the relevant ICMPv6 packets are not blocked) and that the (i.e., the relevant ICMPv6 packets are not blocked) and that the
server-side TCP implementation correctly supports the Maximum Segment server-side TCP implementation correctly supports the Maximum Segment
Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic. Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic.
Some ICPs have implemented an interim solution to mitigate transition Some ICPs have implemented an interim solution to mitigate transition
problems by limiting the visibility of their AAAA records to users problems by limiting the visibility of their AAAA records to users
with validated IPv6 connectivity [RFC6589]. with validated IPv6 connectivity [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.
Neither of these solutions is appropriate in the long term.
Another approach taken by some ICPs is to offer IPv6-only support via 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 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 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 record only. This has some value for testing purposes, but is
otherwise only of interest to hobbyist users willing to type in otherwise only of interest to hobbyist users willing to type in
special URLs. special URLs.
There is little an ICP can do to deal with client-side or remote ISP 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 deficiencies in IPv6 support, but it is hoped that the "happy
skipping to change at page 13, line 16 skipping to change at page 13, line 20
10. Content Delivery Networks 10. Content Delivery Networks
DNS-based techniques for diverting users to Content Delivery Network DNS-based techniques for diverting users to Content Delivery Network
(CDN) points of presence (POPs) will work for IPv6, if AAAA records (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 are provided as well as A records. In general the CDN should follow
the recommendations of this document, especially by operating a full the recommendations of this document, especially by operating a full
dual stack service at each POP. Additionally, each POP will need to dual stack service at each POP. Additionally, each POP will need to
handle IPv6 routing exactly like IPv4, for example running BGP4+ handle IPv6 routing exactly like IPv4, for example running BGP4+
[RFC4760] if appropriate. [RFC4760] if appropriate.
Note that if an ICP supports IPv6 but its CDN does not, its clients Note that if an ICP supports IPv6 but its external CDN provider does
will continue to use IPv4 and any IPv6-only clients will have to use not, its clients will continue to use IPv4 and any IPv6-only clients
a transition solution of some kind. This is not a desirable will have to use a transition solution of some kind. This is not a
situation, since the ICP's work to support IPv6 will be wasted. The desirable situation, since the ICP's work to support IPv6 will be
converse is not true: if the CDN supports IPv6 but the ICP does not, wasted. The converse is not true: if the CDN supports IPv6 but the
dual-stack and IPv6-only clients will obtain IPv6 access. ICP does not, dual-stack and IPv6-only clients will obtain IPv6
access, assuming the CDN provider announces AAAA DNS Resource
Records.
An ICP might face a complex situation, if its CDN provider supports 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 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 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 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 POPs for different URLs, according to the A and AAAA records provided
and the availability of optimisations such as "happy eyeballs." and the availability of optimisations such as "happy eyeballs." A
These complications do not affect the viability of relying on a dual- related side effect is that copies of the same content viewed at the
stack CDN, however. 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.
The CDN itself faces related complexity: "As IPv6 rolls out, it's 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 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 around congestion points that much more important but also that much
harder," stated John Summers of Akamai in 2010. harder," stated John Summers of Akamai in 2010.
11. Business Partners 11. Business Partners
As noted earlier, it is in an ICP's or ASP's best interests that 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 their users have direct IPv6 connectivity, rather than indirect IPv4
skipping to change at page 14, line 39 skipping to change at page 14, line 48
back-end systems such as network management databases to be dual back-end systems such as network management databases to be dual
stacked as soon as convenient. It should also be possible to use stacked as soon as convenient. It should also be possible to use
IPv4 connectivity to repair IPv6 configurations, and vice versa. IPv4 connectivity to repair IPv6 configurations, and vice versa.
Dual stack, while necessary, does have management scaling and Dual stack, while necessary, does have management scaling and
overhead considerations. As noted earlier, the long term goal is to overhead considerations. As noted earlier, the long term goal is to
move to single-stack IPv6, when the network and its customers can move to single-stack IPv6, when the network and its customers can
support this. This is an additional reason why mutual dependency support this. This is an additional reason why mutual dependency
between the address families should be avoided in the management between the address families should be avoided in the management
system in particular; a hidden dependency on IPv4 that had been system in particular; a hidden dependency on IPv4 that had been
forgotten for many years would be highly inconvenient. 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.
13. Security Considerations 13. Security Considerations
Essentially every threat that exists for IPv4 exists or will exist Security experience with IPv4 should be used as a guide as to the
for IPv6. Therefore, it is essential to update firewalls, intrusion threats that may exist in IPv6, but they should not be assumed to be
detection systems, denial of service precautions, and security equally likely, and nor should they assumed to be the only threats
auditing technology to fully support IPv6. Otherwise, IPv6 will that could exist in IPv6. However, essentially every threat that
become an attractive target for attackers. 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.
When multiple PA prefixes are in use as mentioned in Section 5.1, When multiple PA prefixes are in use as mentioned in Section 5.1,
firewall rules must allow for all valid prefixes, and must be set up 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 to work as intended even if packets are sent via one ISP but return
packets arrive via another. packets arrive via another.
Performance and memory size aspects of dual stack firewalls must be Performance and memory size aspects of dual stack firewalls must be
considered (as discussed for routers in Section 5.2). considered (as discussed for routers in Section 5.2).
In a dual stack operation, there may be a risk of cross-contamination In a dual stack operation, there may be a risk of cross-contamination
skipping to change at page 15, line 49 skipping to change at page 16, line 19
updated. updated.
14. IANA Considerations 14. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
15. Acknowledgements 15. Acknowledgements
Valuable contributions were made by Erik Kline. Useful comments were Valuable contributions were made by Erik Kline. Useful comments were
received from Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel received from Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel
Jaeggli, Victor Kuarsingh, Bing Liu, John Mann, Michael Newbery, Jaeggli, Roger Jorgensen, Victor Kuarsingh, Bing Liu, Trent Lloyd,
Arturo Servin, and other participants in the V6OPS working group. John Mann, Michael Newbery, Arturo Servin, Mark Smith, and other
participants in the V6OPS working group.
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge
University during part of this work.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
16. Change log [RFC Editor: Please remove] 16. Change log [RFC Editor: Please remove]
draft-ietf-v6ops-icp-guidance-02: additional WG review, 2012-07-11.
draft-ietf-v6ops-icp-guidance-01: additional WG comments, 2012-06-12. draft-ietf-v6ops-icp-guidance-01: additional WG comments, 2012-06-12.
draft-ietf-v6ops-icp-guidance-00: adopted by WG, small updates, 2012- draft-ietf-v6ops-icp-guidance-00: adopted by WG, small updates, 2012-
04-17. 04-17.
draft-carpenter-v6ops-icp-guidance-03: additional WG comments, 2012- draft-carpenter-v6ops-icp-guidance-03: additional WG comments, 2012-
02-23. 02-23.
draft-carpenter-v6ops-icp-guidance-02: additional WG comments, 2012- draft-carpenter-v6ops-icp-guidance-02: additional WG comments, 2012-
01-07. 01-07.
skipping to change at page 16, line 44 skipping to change at page 17, line 23
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
skipping to change at page 17, line 19 skipping to change at page 17, line 47
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
January 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008. October 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
skipping to change at page 18, line 16 skipping to change at page 18, line 47
Translation", Translation",
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work
in progress), February 2012. in progress), February 2012.
[I-D.jiang-6renum-enterprise] [I-D.jiang-6renum-enterprise]
Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios and Guidelines", Network Renumbering Scenarios and Guidelines",
draft-jiang-6renum-enterprise-02 (work in progress), draft-jiang-6renum-enterprise-02 (work in progress),
December 2011. December 2011.
[I-D.matthews-v6ops-design-guidelines]
Matthews, P., "Design Guidelines for IPv6 Networks",
draft-matthews-v6ops-design-guidelines-00 (work in
progress), June 2012.
[RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", [RFC2081] Malkin, G., "RIPng Protocol Applicability Statement",
RFC 2081, January 1997. RFC 2081, January 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, September 2000. RFC 2923, September 2000.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
 End of changes. 28 change blocks. 
81 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/