draft-ietf-v6ops-icp-guidance-04.txt   draft-ietf-v6ops-icp-guidance-05.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 21, 2013 Huawei Technologies Co., Ltd Expires: July 15, 2013 Huawei Technologies Co., Ltd
September 17, 2012 January 11, 2013
IPv6 Guidance for Internet Content and Application Service Providers IPv6 Guidance for Internet Content and Application Service Providers
draft-ietf-v6ops-icp-guidance-04 draft-ietf-v6ops-icp-guidance-05
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 21, 2013. This Internet-Draft will expire on July 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . . 21 18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . . 22 18.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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
dual stack connectivity, direct IPv6 access might provide more dual stack connectivity, direct IPv6 access might provide more
satisfactory performance than indirect access via NAT. satisfactory performance than indirect access via NAT.
skipping to change at page 3, line 51 skipping to change at page 3, line 51
in this document will also apply to enterprise networks that do not in this document will also apply to enterprise networks that do not
classify themselves as ICPs. Any enterprise or department that runs classify themselves as ICPs. Any enterprise or department that runs
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 important 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 experience for most modern organisations, and it cannot be done new experience for most modern organisations, and it cannot be done
casually on a unplanned basis. Even if it is impossible to write a casually on an 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. Other documents about IPv6 into account in defining the strategy. Other documents about IPv6
deployment, such as [I-D.matthews-v6ops-design-guidelines], should be deployment, such as [I-D.matthews-v6ops-design-guidelines], should be
consulted as well. 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
skipping to change at page 9, line 24 skipping to change at page 9, line 24
the long term. Some versions of OSPFv3 may also have this advantage the long term. Some versions of OSPFv3 may also have this advantage
[RFC5838]. In any case, for trained staff, there should be no [RFC5838]. In any case, for trained staff, there should be no
particular difficulty in deploying IPv6 routing without disturbance particular difficulty in deploying IPv6 routing without disturbance
to IPv4 services. In some cases, firmware upgrades may be needed on to IPv4 services. In some cases, firmware upgrades may be needed on
some network devices. some network devices.
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 forwarding performance does the router vendor In particular, what forwarding performance does the router vendor
claim for IPv6? If the forwarding performance is significantly claim for IPv6? If the forwarding performance is significantly
inferior compared to IPv4, will this be an operational problem? Is inferior compared to IPv4, will this be an operational problem? Is
extra memory or TCAM space needed to accommodate both IPv4 and IPv6 extra memory or ternary content-addressable memory (TCAM) space
tables? To answer these questions, the ICP will need a projected needed to accommodate both IPv4 and IPv6 tables? To answer these
model for the amount of IPv6 traffic expected initially, and its questions, the ICP will need a projected model for the amount of IPv6
likely rate of increase. traffic expected initially, and its 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]. Note that the [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Note that the
prefix translation technique discussed in [RFC6296] does not describe prefix translation technique discussed in [RFC6296] does not describe
skipping to change at page 10, line 46 skipping to change at page 10, line 46
IPv6 support, including performance aspects (as discussed for routers IPv6 support, including performance aspects (as discussed for routers
in Section 5.2). The update needs to be planned in anticipation of in Section 5.2). The update needs to be planned in anticipation of
expected traffic growth. It is to be expected that IPv6 traffic will expected traffic growth. It is to be expected that IPv6 traffic will
initially be low, i.e., a small but growing percentage of total initially be low, i.e., a small but growing percentage of total
traffic. For this reason, it might be acceptable to have IPv6 traffic. For this reason, it might be acceptable to have IPv6
traffic bypass load balancing initially, by publishing an AAAA record traffic bypass load balancing initially, by publishing an AAAA record
for a specific server instead of the load balancer. However, load for a specific server instead of the load balancer. However, load
balancers often also provide for server fail-over, in which case it balancers often also provide for server fail-over, in which case it
would be better to implement IPv6 load balancing immediately. would be better to implement IPv6 load balancing immediately.
The same would apply to TLS or HTTP proxies used for load balancing The same would apply to Transport Layer Security (TLS) or HTTP
purposes. 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 12, line 39 skipping to change at page 12, line 39
network layer to introduce IPv6 addresses can ripple through network layer to introduce IPv6 addresses can ripple through
applications, testing of both client and server applications should applications, testing of both client and server applications should
be performed in both IPv4-only, IPv6-only, and dual-stack be performed in both IPv4-only, IPv6-only, and dual-stack
environments prior to dual-stacking a production environment. environments prior to dual-stacking a production environment.
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.
Security certificates should also contain domain names rather than
addresses.
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, such as when cookies are used for federated authentication. If site, such as when cookies are used for federated authentication. If
the client is using privacy addresses [RFC4941], the IPv6 address the client is using privacy addresses [RFC4941], the IPv6 address
skipping to change at page 13, line 35 skipping to change at page 13, line 36
form of translation mechanism, interfering with traceback. form of translation mechanism, interfering with traceback.
8.4. Geolocation 8.4. 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
methods and databases will be updated to fully support IPv6 prefixes. methods and databases will be updated to fully support IPv6 prefixes.
There is no reason they will be more or less accurate in the long There is no reason they will be more or less accurate in the long
term than those available for IPv4. However, we can expect many more term than those available for IPv4. However, we can expect many more
clients to be mobile as time goes on, so geolocation based on IP clients to be mobile as time goes on, so geolocation based on IP
addresses alone may in any case become problematic. addresses alone may in any case become problematic. A more robust
technique such as HTTP-Enabled Location Delivery (HELD) [RFC5985]
could be considered.
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 16, line 40 skipping to change at page 16, line 45
Many modern web sites and applications now use a collection of Many modern web sites and applications now use a collection of
resources and applications, some operated by the ICP and other by resources and applications, some operated by the ICP and other by
third parties. While most clients support sites containing a mixture third parties. While most clients support sites containing a mixture
of IPv4-only and dual-stack elements, an ICP should track the IPv6 of IPv4-only and dual-stack elements, an ICP should track the IPv6
availability of embedded resources (such as images) as otherwise availability of embedded resources (such as images) as otherwise
their site may only be partially functional or may have degraded their site may only be partially functional or may have degraded
performance for IPv6-only users. performance for IPv6-only users.
DNS-based load balancing techniques for diverting users to servers in DNS-based load balancing techniques for diverting users to servers in
multiple POPs will work for IPv6, if the load balancer supports IPv6 multiple POPs will work for IPv6, if the load balancer supports IPv6
and if AAAA records are provid. Depending on the architecture of the and if AAAA records are provided. Depending on the architecture of
load balancer, an ICP may need to operate a full dual stack service the load balancer, an ICP may need to operate a full dual stack
at each POP. With other architectures, it may be acceptable to service at each POP. With other architectures, it may be acceptable
initially only have IPv6 at a subset of locations. Some to initially only have IPv6 at a subset of locations. Some
architectures will make it preferable for IPv6 routing to mirror IPv4 architectures will make it preferable for IPv6 routing to mirror IPv4
routing (for example running BGP4+ [RFC4760] if appropriate) but this routing (for example running BGP4+ [RFC4760] if appropriate) but this
may not always be possible as IPv6 and IPv4 connectivity can be may not always be possible as IPv6 and IPv4 connectivity can be
independent. independent.
Some complexities may arise when a client supporting both IPv4 and Some complexities may arise when a client supporting both IPv4 and
IPv6 uses different POPs for each IP version (such as when IPv6 is IPv6 uses different POPs for each IP version (such as when IPv6 is
only available in a subset of locations). There are also scenarios only available in a subset of locations). There are also scenarios
where a dual-stack client would be diverted to a mixture of IPv4 and where a dual-stack client would be diverted to a mixture of IPv4 and
IPv6 POPs for different URLs, according to the A and AAAA records IPv6 POPs for different URLs, according to the A and AAAA records
skipping to change at page 17, line 37 skipping to change at page 17, line 42
operational impact, as well as requiring education and training as operational impact, as well as requiring education and training as
mentioned in Section 3. Staff will have to update network elements mentioned in Section 3. Staff will have to update network elements
such as routers, update configurations, provide information to end such as routers, update configurations, provide information to end
users, and diagnose new problems. However, for an enterprise users, and diagnose new problems. However, for an enterprise
network, there is plenty of experience, e.g. on numerous university network, there is plenty of experience, e.g. on numerous university
campuses, showing that dual stack operation is no harder than IPv4- campuses, showing that dual stack operation is no harder than IPv4-
only in the steady state. only in the steady state.
Whatever management, monitoring and logging is performed for IPv4 is Whatever management, monitoring and logging is performed for IPv4 is
also needed for IPv6. Therefore, all products and tools used for also needed for IPv6. Therefore, all products and tools used for
these purposes must be updated to fully support IPv6. It is these purposes must be updated to fully support IPv6 management data.
important to verify that tools have been fully updated to support 128 It is important to verify that tools have been fully updated to
bit addresses entered and displayed in hexadecimal [RFC5952]. Since support 128 bit addresses entered and displayed in hexadecimal
an IPv6 network may operate with more than one IPv6 prefix and [RFC5952]. Since an IPv6 network may operate with more than one IPv6
therefore more than one address per host, the tools must deal with prefix and therefore more than one address per host, the tools must
this as a normal situation. This includes any address management deal with this as a normal situation. This includes any address
tool in use (see Section 5.1) as well as tools used for creating DHCP management tool in use (see Section 5.1) as well as tools used for
and DNS configurations. There is significant overlap here with the creating DHCP and DNS configurations. There is significant overlap
tools involved in site renumbering [I-D.ietf-6renum-enterprise]. here with the tools involved in site renumbering
As far as possible, however, mutual dependency between IPv4 and IPv6 [I-D.ietf-6renum-enterprise].
operations should be avoided. A failure of one should not cause a
failure of the other. One precaution to avoid this would be for At an early stage of IPv6 deployment, it is likely that IPv6 will be
back-end systems such as network management databases to be dual mainly managed via IPv4 transport. This allows network management
stacked as soon as convenient. It should also be possible to use systems to test for dependencies between IPv4 and IPv6 management
IPv4 connectivity to repair IPv6 configurations, and vice versa. data. For example, will reports mixing IPv4 and IPv6 addresses
display correctly?
In a second phase, IPv6 transport should be used to manage the
network. Note that it will also be necessary for an ICP to provide
IPv6 connectivity for its operations and support staff, even when
working remotely. As far as possible mutual dependency between IPv4
and IPv6 should be avoided, for both the management data and the
transport. Failure of one should not cause a failure of the other.
One precaution to avoid this would be for network management systems
to be dual-stacked. It would then be possible to use 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. In forgotten for many years would be highly inconvenient. In
particular, a management tool that manages IPv6 but itself runs only particular, a management tool that manages IPv6 but itself runs only
over IPv4 would prove disastrous on the day that IPv4 is switched over IPv4 would prove disastrous on the day that IPv4 is switched
skipping to change at page 18, line 47 skipping to change at page 19, line 15
firewalls and other network security appliances protecting servers firewalls and other network security appliances protecting servers
support IPv6 and have rules tested and configured. support IPv6 and have rules tested and configured.
Security experience with IPv4 should be used as a guide as to the Security experience with IPv4 should be used as a guide as to the
threats that may exist in IPv6, but they should not be assumed to be threats that may exist in IPv6, but they should not be assumed to be
equally likely, and nor should they assumed to be the only threats equally likely, and nor should they assumed to be the only threats
that could exist in IPv6. However, essentially every threat that that could exist in IPv6. However, essentially every threat that
exists for IPv4 exists or will exist for IPv6, to a greater or lesser exists for IPv4 exists or will exist for IPv6, to a greater or lesser
extent. It is essential to update firewalls, intrusion detection extent. It is essential to update firewalls, intrusion detection
systems, denial of service precautions, and security auditing systems, denial of service precautions, and security auditing
technology to fully support IPv6. Otherwise, IPv6 will become an technology to fully support IPv6. Needless to say, it is also
essential to turn on well-known security mechanisms such as DNS
Security and DHCPv6 Authentication. Otherwise, IPv6 will become an
attractive target for attackers. 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
between the two protocols. For example, a successful IPv4-based between the two protocols. For example, a successful IPv4-based
denial of service attack might also deplete resources needed by the denial of service attack might also deplete resources needed by the
IPv6 service, or vice versa. This risk strengthens the argument that IPv6 service, or vice versa. This risk strengthens the argument that
IPv6 security must be up to the same level as IPv4. IPv6 security must be up to the same level as IPv4. Risks can also
occur with dual stack Virtual Private Network (VPN) solutions
[I-D.ietf-opsec-vpn-leakages].
A general overview of techniques to protect an IPv6 network against A general overview of techniques to protect an IPv6 network against
external attack is given in [RFC4864]. Assuming an ICP has native external attack is given in [RFC4864]. Assuming an ICP has native
IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4 IPv6 connectivity, it is advisable to block incoming IPv6-in-IPv4
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.
skipping to change at page 20, line 25 skipping to change at page 20, line 43
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-05: IESG comments, 2013-01-11.
draft-ietf-v6ops-icp-guidance-04: text on multiple PA prefixes tuned draft-ietf-v6ops-icp-guidance-04: text on multiple PA prefixes tuned
again, brief mention of NPTv6, 2012-09-17. 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.
skipping to change at page 22, line 19 skipping to change at page 22, line 42
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3", Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010. RFC 5838, April 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
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, Considerations and
draft-ietf-6renum-enterprise-02 (work in progress), Methods", draft-ietf-6renum-enterprise-05 (work in
September 2012. progress), December 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 in Enterprise
draft-ietf-6renum-static-problem-01 (work in progress), Networks", draft-ietf-6renum-static-problem-03 (work in
August 2012. progress), December 2012.
[I-D.ietf-opsec-vpn-leakages]
Gont, F., "Virtual Private Network (VPN) traffic leakages
in dual-stack hosts/ networks",
draft-ietf-opsec-vpn-leakages-00 (work in progress),
December 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-12 (work in progress),
August 2012. October 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
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.matthews-v6ops-design-guidelines] [I-D.matthews-v6ops-design-guidelines]
Matthews, P., "Design Guidelines for IPv6 Networks", Matthews, P., "Design Guidelines for IPv6 Networks",
draft-matthews-v6ops-design-guidelines-00 (work in draft-matthews-v6ops-design-guidelines-01 (work in
progress), June 2012. progress), October 2012.
[RFC1912] Barr, D., "Common DNS Operational and Configuration [RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996. Errors", RFC 1912, February 1996.
[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.
 End of changes. 22 change blocks. 
47 lines changed or deleted 77 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/