draft-ietf-v6ops-icp-guidance-00.txt   draft-ietf-v6ops-icp-guidance-01.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: October 19, 2012 Huawei Technologies Co., Ltd Expires: December 14, 2012 Huawei Technologies Co., Ltd
April 17, 2012 June 12, 2012
IPv6 Guidance for Internet Content and Application Service Providers IPv6 Guidance for Internet Content and Application Service Providers
draft-ietf-v6ops-icp-guidance-00 draft-ietf-v6ops-icp-guidance-01
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 any enterprise network preparing for IPv6 users. also apply to hosting providers, or to any enterprise network
preparing for IPv6 users.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 19, 2012. This Internet-Draft will expire on December 14, 2012.
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 15 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 10 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11
8.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10 8.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 11
9. Coping with Transition Technologies . . . . . . . . . . . . . 11 9. Coping with Transition Technologies . . . . . . . . . . . . . 11
10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 12 10. Content Delivery Networks . . . . . . . . . . . . . . . . . . 13
11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 13 11. Business Partners . . . . . . . . . . . . . . . . . . . . . . 13
12. Operations and Management . . . . . . . . . . . . . . . . . . 13 12. Operations and Management . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
16. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 15 16. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 16
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
17.1. Normative References . . . . . . . . . . . . . . . . . . . 15 17.1. Normative References . . . . . . . . . . . . . . . . . . . 16
17.2. Informative References . . . . . . . . . . . . . . . . . . 17 17.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 customers. The time for action is now,
while the number of such customers is small, so that appropriate while the number of such customers is small, so that appropriate
skills, software and equipment can be acquired in good time to scale skills, software and equipment can be acquired in good time to scale
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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
Providers (ASPs) who wish to offer their services to both IPv6 and Providers (ASPs) who wish to offer their services to both IPv6 and
IPv4 customers. For simplicity, the term ICP is mainly used in the IPv4 customers, but who are currently supporting only IPv4. For
body of this document, but the guidance also applies to ASPs. Many simplicity, the term ICP is mainly used in the body of this document,
of the points in this document will also apply to enterprise networks but the guidance also applies to ASPs. Any hosting provider whose
that do not classify themselves as ICPs. Any enterprise or customers include ICPs or ASPs is also concerned. Many of the points
department that runs at least one externally accessible server, such in this document will also apply to enterprise networks that do not
as an HTTP server, may also be concerned. Although specific classify themselves as ICPs. Any enterprise or department that runs
managerial and technical approaches are described, this is not a rule at least one externally accessible server, such as an HTTP server,
book; each operator will need to make its own plan, tailored to its may also be concerned. Although specific managerial and technical
own services and customers. 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.
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 departure 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 day-by-day 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
skipping to change at page 7, line 52 skipping to change at page 7, line 52
using only Stateless Address Autoconfiguration [RFC4862]. In using only Stateless Address Autoconfiguration [RFC4862]. In
practice, an ICP of reasonable size will probably choose to operate practice, an ICP of reasonable size will probably choose to operate
DHCPv6 [RFC3315] and use it to support stateful and/or on-demand DHCPv6 [RFC3315] and use it to support stateful and/or on-demand
address assignment. address assignment.
5.2. Routing 5.2. Routing
In a dual stack network, IPv4 and IPv6 routing protocols operate In a dual stack network, IPv4 and IPv6 routing protocols operate
quite independently and in parallel. The common routing protocols quite independently and in parallel. The common routing protocols
all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS
[RFC5308], and even RIPng [RFC2080] [RFC2081]. For trained staff, [RFC5308], and even RIPng [RFC2080] [RFC2081]. It is worth noting
there should be no particular difficulty in deploying IPv6 routing that whereas OSPF and RIP differ significantly between IPv4 and IPv6,
without disturbance to IPv4 services. IS-IS has the advantage of handling them both in the same way, with
the potential for operational simplification in the long term. In
any case, for trained staff, there should be no 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 performance does the router vendor claim for
IPv6? If the performance is significantly inferior compared to IPv4, IPv6? If the performance is significantly inferior compared to IPv4,
will this be an operational problem? Is extra memory or TCAM space will this be an operational problem? Is extra memory or TCAM space
needed to accommodate both IPv4 and IPv6 tables? To answer these needed to accommodate both IPv4 and IPv6 tables? To answer these
questions, the ICP will need a projected model for the amount of IPv6 questions, the ICP will need a projected model for the amount of IPv6
traffic expected initially, and its likely rate of increase. [[Note: traffic expected initially, and its likely rate of increase.
further input from the WG is needed on this point.]]
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].
skipping to change at page 8, line 49 skipping to change at page 9, line 7
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.
6. Load Balancers 6. Load Balancers
It is to be expected that IPv6 traffic will initially be low, i.e. a Most available load balancers now support IPv6. However, it is
small percentage of IPv4 traffic. For this reason, updating load important to obtain appropriate assurances from vendors about their
balancers to fully support IPv6 can perhaps be delayed; however, such IPv6 support, including performance aspects (as discussed for routers
an update needs to be planned in anticipation of significant growth in Section 5.2). The update needs to be planned in anticipation of
over a period of several years. The same would apply to TLS or HTTP expected traffic growth. It is to be expected that IPv6 traffic will
proxies used for load balancing purposes. It is important to obtain initially be low, i.e., a small percentage of IPv4 traffic. For this
appropriate assurances from vendors about their IPv6 support, reason, it might be acceptable to have IPv6 traffic bypass load
including performance aspects (as discussed for routers in balancing initially, by publishing an AAAA record for a specific
Section 5.2). server instead of the load balancer. However, it would be more
straightforward to implement IPv6 load balancing immediately, which
would also provide support for IPv6 server fail-over.
The same would apply to TLS or HTTP proxies used for load balancing
purposes.
7. Proxies 7. Proxies
An HTTP proxy [RFC2616] can readily be configured to handle incoming An HTTP proxy [RFC2616] can readily be configured to handle incoming
connections over IPv6 and to proxy them to a server over IPv4. 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 Therefore, a single proxy can be used as the first step in an
outside-in strategy, as shown in the following diagram: outside-in strategy, as shown in the following diagram:
___________________________________________ ___________________________________________
( ) ( )
skipping to change at page 10, line 35 skipping to change at page 11, line 24
One important recommendation here is that all applications should use One important recommendation here is that all applications should use
domain names, which are IP-version-independent, rather than IP domain names, which are IP-version-independent, rather than IP
addresses. Applications based on middlware platforms which have addresses. Applications based on middlware platforms which have
uniform support for IPv4 and IPv6, for example Java, may be able to uniform support for IPv4 and IPv6, for example Java, may be able to
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 guarentee 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 not its /64 prefix) might change quite frequently. Any
cookie mechanism based on 32-bit IPv4 addresses will need significant cookie mechanism based on 32-bit IPv4 addresses will need significant
remodelling. 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
As time goes on, it is to be assumed that geolocation methods and Initially, ICPs may observe some weakness in geolocation for IPv6
databases will be updated to fully support IPv6 prefixes. There is clients. As time goes on, it is to be assumed that geolocation
no reason they will be more or less accurate in the long term than methods and databases will be updated to fully support IPv6 prefixes.
those available for IPv4. However, we can expect many more clients There is no reason they will be more or less accurate in the long
to be mobile as time goes on, so geolocation based on IP addresses term than those available for IPv4. However, we can expect many more
alone may become problematic. Initially, at least, ICPs may observe clients to be mobile as time goes on, so geolocation based on IP
some weakness in geolocation for IPv6 clients. addresses alone may in any case become problematic.
9. Coping with Transition Technologies 9. Coping with Transition Technologies
As mentioned above, an ICP should obtain native IPv6 connectivity As mentioned above, an ICP should obtain native IPv6 connectivity
from its ISPs. In this way, the ICP can avoid most of the from its ISPs. In this way, the ICP can avoid most of the
complexities of the numerous IPv4-to-IPv6 transition technologies complexities of the numerous IPv4-to-IPv6 transition technologies
that have been developed; they are all second-best solutions. that have been developed; they are all second-best solutions.
However, some clients are sure to be using such technologies. An ICP 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 needs to be aware of the operational issues this may cause and how to
deal with them. deal with them.
skipping to change at page 11, line 50 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 with validated IPv6 connectivity [RFC6589].
[I-D.ietf-v6ops-v6-aaaa-whitelisting-implications].
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
eyeballs" [I-D.ietf-v6ops-happy-eyeballs] approach will improve the eyeballs" [RFC6555] approach will improve the ability for clients to
ability for clients to deal with such problems. deal with such problems.
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.
skipping to change at page 14, line 42 skipping to change at page 15, line 28
tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this 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 kind should be blocked except for the case noted in Section 4.5 of
[RFC6343]. ICMPv6 traffic should only be blocked in accordance with [RFC6343]. ICMPv6 traffic should only be blocked in accordance with
[RFC4890]; in particular, Packet Too Big messages, which are [RFC4890]; in particular, Packet Too Big messages, which are
essential for PMTU discovery, must not be blocked. essential for PMTU discovery, must not be blocked.
Scanning attacks to discover the existence of hosts are much less Scanning attacks to discover the existence of hosts are much less
likely to succeed for IPv6 than for IPv4 [RFC5157]. However, this is likely to succeed for IPv6 than for IPv4 [RFC5157]. However, this is
only true if IPv6 hosts are configured with interface identifiers only true if IPv6 hosts are configured with interface identifiers
that are hard to guess; for example, it is not advisable to manually that are hard to guess; for example, it is not advisable to manually
configure servers with static interface identifiers starting from configure hosts with consecutive interface identifiers starting from
"1". "1".
Transport Layer Security version 1.2 [RFC5246] and its predecessors Transport Layer Security version 1.2 [RFC5246] and its predecessors
work correctly with TCP over IPv6, meaning that HTTPS-based security work correctly with TCP over IPv6, meaning that HTTPS-based security
solutions are immediately applicable. The same should apply to any solutions are immediately applicable. The same should apply to any
other transport-layer or application-layer security techniques. other transport-layer or application-layer security techniques.
If an ASP uses IPsec [RFC4301] and IKE [RFC5996] in any way to secure If an ASP uses IPsec [RFC4301] and IKE [RFC5996] in any way to secure
connections with clients, these too are fully applicable to IPv6, but connections with clients, these too are fully applicable to IPv6, but
only if the software stack at each end has been appropriately only if the software stack at each end has been appropriately
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, Victor received from Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel
Kuarsingh, Bing Liu, John Mann, and other participants in the V6OPS Jaeggli, Victor Kuarsingh, Bing Liu, John Mann, Michael Newbery,
working group. Arturo Servin, and other participants in the V6OPS working group.
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-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.
draft-carpenter-v6ops-icp-guidance-01: multiple clarifications after draft-carpenter-v6ops-icp-guidance-01: multiple clarifications after
skipping to change at page 17, line 14 skipping to change at page 17, line 47
17.2. Informative References 17.2. Informative References
[I-D.carpenter-6renum-static-problem] [I-D.carpenter-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-carpenter-6renum-static-problem-02 (work in draft-carpenter-6renum-static-problem-02 (work in
progress), February 2012. progress), February 2012.
[I-D.ietf-v6ops-6204bis] [I-D.ietf-v6ops-6204bis]
Singh, H., Beebee, W., Donley, C., Stark, B., and O. Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Troan, "Basic Requirements for IPv6 Customer Edge Requirements for IPv6 Customer Edge Routers",
Routers", draft-ietf-v6ops-6204bis-08 (work in progress), draft-ietf-v6ops-6204bis-09 (work in progress), May 2012.
April 2012.
[I-D.ietf-v6ops-happy-eyeballs]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07
(work in progress), December 2011.
[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
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.ietf-v6ops-v6-aaaa-whitelisting-implications]
Livingood, J., "Considerations for Transitioning Content
to IPv6",
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11
(work 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.
[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,
skipping to change at page 19, line 5 skipping to change at page 19, line 20
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180, Transition Mechanisms during IPv6 Deployment", RFC 6180,
May 2011. May 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011. Translation", RFC 6296, June 2011.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011. RFC 6343, August 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6589] Livingood, J., "Considerations for Transitioning Content
to IPv6", RFC 6589, April 2012.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 24 change blocks. 
69 lines changed or deleted 73 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/