draft-ietf-v6ops-icp-guidance-03.txt   draft-ietf-v6ops-icp-guidance-04.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: March 4, 2013 Huawei Technologies Co., Ltd Expires: March 21, 2013 Huawei Technologies Co., Ltd
August 31, 2012 September 17, 2012
IPv6 Guidance for Internet Content and Application Service Providers IPv6 Guidance for Internet Content and Application Service Providers
draft-ietf-v6ops-icp-guidance-03 draft-ietf-v6ops-icp-guidance-04
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 March 4, 2013. This Internet-Draft will expire on March 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Network Stack . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12
8.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 13
9. Coping with Transition Technologies . . . . . . . . . . . . . 13 9. Coping with Transition Technologies . . . . . . . . . . . . . 13
10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 15 10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 15
11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 16 11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 16
12. Possible Complexities . . . . . . . . . . . . . . . . . . . . 16 12. Possible Complexities . . . . . . . . . . . . . . . . . . . . 16
13. Operations and Management . . . . . . . . . . . . . . . . . . 17 13. Operations and Management . . . . . . . . . . . . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
17. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 20 17. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 20
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . . 20 18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . . 22 18.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The deployment of IPv6 [RFC2460] is now in progress, and users The deployment of IPv6 [RFC2460] is now in progress, and users
without direct IPv4 access are likely to appear in increasing numbers without direct IPv4 access are likely to appear in increasing numbers
in the coming years. Any provider of content or application services in the coming years. Any provider of content or application services
over the Internet will need to arrange for IPv6 access or else risk over the Internet will need to arrange for IPv6 access or else risk
losing large numbers of potential users. For users who already have losing large numbers of potential users. For users who already have
skipping to change at page 7, line 48 skipping to change at page 7, line 48
IPv6 connectivity. Note that unmanaged tunnels (such as 6to4 and IPv6 connectivity. Note that unmanaged tunnels (such as 6to4 and
Teredo) are generally not useful for support staff as recent client Teredo) are generally not useful for support staff as recent client
software will avoid them when accessing dual-stack sites. software will avoid them when accessing dual-stack sites.
5. IPv6 Infrastructure 5. IPv6 Infrastructure
5.1. Address and subnet assignment 5.1. Address and subnet assignment
An ICP must first decide whether to apply for its own Provider An ICP must first decide whether to apply for its own Provider
Independent (PI) address prefix for IPv6. This option is available Independent (PI) address prefix for IPv6. This option is available
to an ICP willing to deal directly with the relevant Regional either from an ISP that acts as a Local Internet Registry, or
Internet Registry and pay the associated fees. The alternative is to directly from the relevant Regional Internet Registry. The
obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions alternative is to obtain a Provider Aggregated (PA) prefix from an
are viable in IPv6. However, the scaling properties of the wide area ISP. Both solutions are viable in IPv6. However, the scaling
routing system (BGP4) limit the routing of PI prefixes, so only large properties of the wide area routing system (BGP4) mean that the
content providers can justify the bother and expense of obtaining a number of PI prefixes should be limited, so only large content
PI prefix and convincing their ISPs to route it. Millions of providers can justify obtaining a PI prefix and convincing their ISPs
enterprise networks, including smaller content providers, will use PA to route it. Millions of enterprise networks, including smaller
prefixes. In this case, a change of ISP would necessitate a change content providers, will use PA prefixes. In this case, a change of
of the corresponding PA prefix, using the procedure outlined in ISP would necessitate a change of the corresponding PA prefix, using
[RFC4192]. the procedure outlined in [RFC4192].
An ICP that has connections via multiple ISPs, but does not have a PI 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 prefix, would therefore have multiple PA prefixes, one from each ISP.
would result in multiple IPv6 addresses for the ICP's servers or load This would result in multiple IPv6 addresses for the ICP's servers or
balancers. If one address fails due to an ISP malfunction, sessions load balancers. If one address fails due to an ISP malfunction,
using that address would be lost. At the time of this writing, there sessions using that address would be lost. At the time of this
is very limited operational experience with this approach writing, there is very limited operational experience with this
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. approach [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat].
An ICP may also choose to operate a Unique Local Address prefix An ICP may also choose to operate a Unique Local Address prefix
[RFC4193] for internal traffic only, as described in [RFC4864]. [RFC4193] for internal traffic only, as described in [RFC4864].
Depending on its projected future size, an ICP might choose to obtain 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 /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 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 the choice of /48 is more future-proof. Advice on the numbering of
subnets may be found in [RFC5375]. An ICP with multiple locations subnets may be found in [RFC5375]. An ICP with multiple locations
will probably need a prefix per location will probably need a prefix per location
An ICP that has its service hosted by a colocation provider, cloud
provider, or the like, will need to follow the addressing policy of
that provider.
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 possible management packages, can deal with this. In particular, the possible
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 the common technique of manually need to renumber, means that the common technique of manually
assigned static addresses for servers, proxies or load balancers, assigned static addresses for servers, proxies or load balancers,
with statically defined DNS entries, could be problematic with statically defined DNS entries, could be problematic
[I-D.ietf-6renum-static-problem]. An ICP of reasonable size might [I-D.ietf-6renum-static-problem]. An ICP of reasonable size might
instead choose to operate DHCPv6 [RFC3315] with standard DNS, to instead choose to operate DHCPv6 [RFC3315] with standard DNS, to
support stateful assignment. In either case a configuration support stateful assignment. In either case a configuration
skipping to change at page 9, line 31 skipping to change at page 9, line 36
model for the amount of IPv6 traffic expected initially, and its model for the amount of IPv6 traffic expected initially, and its
likely rate of increase. likely rate of increase.
If a site has multiple PA prefixes as mentioned in Section 5.1, If a site has multiple PA prefixes as mentioned in Section 5.1,
complexities will appear in routing configuration. In particular, complexities will appear in routing configuration. In particular,
source-based routing rules might be needed to ensure that outgoing source-based routing rules might 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]. Note that the
prefix translation technique discussed in [RFC6296] does not describe
a solution for enterprises that offer publicly available content
servers.
Each IPv6 subnet that supports end hosts normally has a /64 prefix, Each IPv6 subnet that supports end hosts normally has a /64 prefix,
leaving another 64 bits for the interface identifiers of individual leaving another 64 bits for the interface identifiers of individual
hosts. In contrast, a typical IPv4 subnet will have no more than 8 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 bits for the host identifier, thus limiting the subnet to 256 or
fewer hosts. A dual stack design will typically use the same fewer hosts. A dual stack design will typically use the same
physical or VLAN subnet topology for IPv4 and IPv6, and therefore the physical or VLAN subnet topology for IPv4 and IPv6, and therefore the
same router topology. In other words the IPv4 and IPv6 topologies same router topology. In other words the IPv4 and IPv6 topologies
are congruent. This means that the limited subnet size of IPv4 (such 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 as 256 hosts) will be imposed on IPv6, even though the IPv6 prefix
skipping to change at page 20, line 21 skipping to change at page 20, line 25
Nygren, Arturo Servin, Mark Smith, and other participants in the Nygren, Arturo Servin, Mark Smith, and other participants in the
V6OPS working group. V6OPS working group.
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge Brian Carpenter was a visitor at the Computer Laboratory, Cambridge
University during part of this work. University during part of this work.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
17. Change log [RFC Editor: Please remove] 17. Change log [RFC Editor: Please remove]
draft-ietf-v6ops-icp-guidance-04: text on multiple PA prefixes tuned
again, brief mention of NPTv6, 2012-09-17.
draft-ietf-v6ops-icp-guidance-03: text on multiple PA prefixes draft-ietf-v6ops-icp-guidance-03: text on multiple PA prefixes
updated, numerous other WGLC comments, 2012-08-31. updated, numerous other WGLC comments, 2012-08-31.
draft-ietf-v6ops-icp-guidance-02: additional WG review, 2012-07-11. 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.
skipping to change at page 22, line 24 skipping to change at page 22, line 31
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
18.2. Informative References 18.2. Informative References
[I-D.ietf-6renum-enterprise] [I-D.ietf-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-ietf-6renum-enterprise-01 (work in progress), draft-ietf-6renum-enterprise-02 (work in progress),
July 2012. September 2012.
[I-D.ietf-6renum-static-problem] [I-D.ietf-6renum-static-problem]
Carpenter, B. and S. Jiang, "Problem Statement for Carpenter, B. and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses", Renumbering IPv6 Hosts with Static Addresses",
draft-ietf-6renum-static-problem-00 (work in progress), draft-ietf-6renum-static-problem-01 (work in progress),
July 2012. August 2012.
[I-D.ietf-v6ops-6204bis] [I-D.ietf-v6ops-6204bis]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", Requirements for IPv6 Customer Edge Routers",
draft-ietf-v6ops-6204bis-10 (work in progress), draft-ietf-v6ops-6204bis-10 (work in progress),
August 2012. August 2012.
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]
Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D.
Wing, "IPv6 Multihoming without Network Address Wing, "IPv6 Multihoming without Network Address
 End of changes. 14 change blocks. 
34 lines changed or deleted 44 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/