draft-ietf-6renum-enterprise-05.txt   draft-ietf-6renum-enterprise-06.txt 
Network Working Group S. Jiang Network Working Group S. Jiang
Internet Draft B. Liu Internet Draft B. Liu
Intended status: Informational Huawei Technologies Co., Ltd Intended status: Informational Huawei Technologies Co., Ltd
Expires: June 23, 2013 B. Carpenter Expires: July 18, 2013 B. Carpenter
University of Auckland University of Auckland
December 21, 2012 January 15, 2013
IPv6 Enterprise Network Renumbering Scenarios, IPv6 Enterprise Network Renumbering Scenarios,
Considerations and Methods Considerations and Methods
draft-ietf-6renum-enterprise-05.txt draft-ietf-6renum-enterprise-06.txt
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 working Task Force (IETF). Note that other groups may also distribute
documents as Internet-Drafts. The list of current Internet-Drafts is working documents as Internet-Drafts. The list of current Internet-
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
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any 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 June 23, 2013. This Internet-Draft will expire on July 18, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
This document analyzes events that cause renumbering and describes This document analyzes events that cause renumbering and describes
the current renumbering methods. These are described in three the current renumbering methods. These are described in three
categories: those applicable during network design, those applicable categories: those applicable during network design, those applicable
during preparation for renumbering, and those applicable during the during preparation for renumbering, and those applicable during the
renumbering operation. renumbering operation.
Table of Contents Table of Contents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1. Introduction ................................................. 3 1. Introduction ................................................. 3
2. Enterprise Network Illustration for Renumbering .............. 3 2. Enterprise Network Illustration for Renumbering .............. 3
3. Enterprise Network Renumbering Scenario Categories ........... 5 3. Enterprise Network Renumbering Scenario Categories ........... 5
3.1. Renumbering Caused by External Network Factors .......... 5 3.1. Renumbering Caused by External Network Factors .......... 5
3.2. Renumbering caused by Internal Network Factors .......... 6 3.2. Renumbering caused by Internal Network Factors .......... 6
4. Network Renumbering Considerations and Current Methods ....... 6 4. Network Renumbering Considerations and Current Methods ....... 6
4.1. Considerations and Current Methods during Network Design. 6 4.1. Considerations and Current Methods during Network Design. 6
4.2. Considerations and Current Methods for the Preparation of 4.2. Considerations and Current Methods for the Preparation of
Renumbering ................................................. 10 Renumbering ................................................. 10
4.3. Considerations and Current Methods during Renumbering 4.3. Considerations and Current Methods during Renumbering
Operation ................................................... 11 Operation ................................................... 12
5. Security Considerations ..................................... 13 5. Security Considerations ..................................... 14
6. IANA Considerations ......................................... 14 6. IANA Considerations ......................................... 14
7. Acknowledgements ............................................ 14 7. Acknowledgements ............................................ 14
8. References .................................................. 14 8. References .................................................. 15
8.1. Normative References ................................... 14 8.1. Normative References .................................. 15
8.2. Informative References ................................. 15 8.2. Informative References ................................. 16
Author's Addresses ............................................. 17 Author's Addresses ............................................. 18
1. Introduction 1. Introduction
Site renumbering is difficult. Network managers frequently attempt to Site renumbering is difficult. Network managers frequently attempt
avoid future renumbering by numbering their network resources from to avoid future renumbering by numbering their network resources
Provider Independent (PI) address space. However, widespread use of from Provider Independent (PI) address space. However, widespread
PI would aggravate BGP4 scaling problems [RFC4116] and, depending on use of PI would aggravate BGP4 scaling problems [RFC4116] and,
Regional Internet Registry (RIR) policies, PI space is not always depending on Regional Internet Registry (RIR) policies, PI space is
available for enterprises of all sizes. Therefore, it is desirable to not always available for enterprises of all sizes. Therefore, it is
develop mechanisms that simplify IPv6 renumbering for enterprises. desirable to develop mechanisms that simplify IPv6 renumbering for
enterprises.
This document is an analysis of IPv6 site renumbering for enterprise This document is an analysis of IPv6 site renumbering for enterprise
networks. It undertakes scenario descriptions, including networks. It undertakes scenario descriptions, including
documentation of current capabilities and existing practices. The documentation of current capabilities and existing practices. The
reader is assumed to be familiar with [RFC4192] and [RFC5887]. reader is assumed to be familiar with [RFC4192] and [RFC5887].
Proposals for new technology and methods are out of scope. Proposals for new technology and methods are out of scope.
Since IPv4 and IPv6 are logically separate from the perspective of Since IPv4 and IPv6 are logically separate from the perspective of
renumbering, regardless of overlapping of the IPv4/IPv6 networks or renumbering, regardless of overlapping of the IPv4/IPv6 networks or
devices, this document focuses on IPv6 only, leaving IPv4 out of devices, this document focuses on IPv6 only, leaving IPv4 out of
scope. Dual-stack network or IPv4/IPv6 transition scenarios are out scope. Dual-stack network or IPv4/IPv6 transition scenarios are out
of scope, too. of scope, too.
This document focuses on enterprise network renumbering; however, This document focuses on enterprise network renumbering; however,
most of the analysis is also applicable to ISP network renumbering. most of the analysis is also applicable to ISP network renumbering.
Renumbering in home networks is out of scope, but it can also benefit Renumbering in home networks is out of scope, but it can also
from the analysis in this document. benefit from the analysis in this document.
The concept of an enterprise network and a typical network The concept of an enterprise network and a typical network
illustration are introduced first. Then, current renumbering methods illustration are introduced first. Then, current renumbering methods
are introduced according to the following categories: those are introduced according to the following categories: those
applicable during network design, those applicable during preparation applicable during network design, those applicable during
for renumbering, and those applicable during the renumbering preparation for renumbering, and those applicable during the
operation. renumbering operation.
2. Enterprise Network Illustration for Renumbering 2. Enterprise Network Illustration for Renumbering
An Enterprise Network as defined in [RFC4057] is a network that has An Enterprise Network as defined in [RFC4057] is a network that has
multiple internal links, one or more router connections to one or multiple internal links, one or more router connections to one or
more Providers, and is actively managed by a network operations more Providers, and is actively managed by a network operations
entity. entity.
Figure 1 provides a sample enterprise network architecture for a Figure 1 provides a sample enterprise network architecture for a
simple case. Those entities mainly affected by renumbering are simple case. Those entities mainly affected by renumbering are
skipping to change at page 4, line 13 skipping to change at page 4, line 15
* Gateway: Border router, firewall, web cache, etc. * Gateway: Border router, firewall, web cache, etc.
* Application server (for internal or external users) * Application server (for internal or external users)
* DNS and DHCP servers * DNS and DHCP servers
* Routers * Routers
* Hosts (desktops etc.) * Hosts (desktops etc.)
Uplink 1 Uplink 2
| |
+---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | |
| |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Figure 1 Enterprise network illustration
Address reconfiguration is fulfilled either by the Dynamic Host Address reconfiguration is fulfilled either by the Dynamic Host
configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for
IPv6 (ND) protocols. During a renumbering event, the Domain Name IPv6 (ND) protocols. During a renumbering event, the Domain Name
Service (DNS) records need to be synchronized while routing tables, Service (DNS) records need to be synchronized while routing tables,
Access Control Lists (ACLs) and IP filtering tables in various Access Control Lists (ACLs) and IP filtering tables in various
devices also need to be updated. It is taken for granted that devices also need to be updated. It is taken for granted that
applications will work entirely on the basis of DNS names, but any applications will work entirely on the basis of DNS names, but any
direct dependencies on IP addresses in application layer entities direct dependencies on IP addresses in application layer entities
must also be updated. must also be updated.
The issue of static addresses is described in a dedicated draft The issue of static addresses is described in a dedicated draft
[I-D.ietf-6renum-static-problem]. [I-D.ietf-6renum-static-problem].
Uplink 1 Uplink 2 The emerging cloud-based enterprise network architecture might be
| | different with Figure 1. But it is out of the scope of this document
+---+---+ +---+---+ since the it is far from mature and has not been widely deployed yet.
+---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ |
| Enterprise Network |
| +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | |
| |Server| |Server| |Server| |
| +---+--+ +---+--+ +--+---+ |
| | | | |
| ---+--+---------+------+---+- |
| | | |
| +--+---+ +---+--+ |
| |Router| |Router| |
| +--+---+ +---+--+ |
| | | |
| -+---+----+-------+---+--+- |
| | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ |
+----------------------------------------+
Figure 1 Enterprise network illustration
It is assumed that IPv6 enterprise networks are IPv6-only, or dual- It is assumed that IPv6 enterprise networks are IPv6-only, or dual-
stack in which a logical IPv6 plane is independent from IPv4. As stack in which a logical IPv6 plane is independent from IPv4. As
mentioned above, IPv4/IPv6 co-existence scenarios are out of scope. mentioned above, IPv4/IPv6 co-existence scenarios are out of scope.
This document focuses on routable unicast addresses; link-local, This document focuses on routable unicast addresses; link-local,
multicast and anycast addresses are also out of scope. multicast and anycast addresses are also out of scope.
3. Enterprise Network Renumbering Scenario Categories 3. Enterprise Network Renumbering Scenario Categories
skipping to change at page 5, line 36 skipping to change at page 5, line 40
When the enterprise switches ISPs, a "flag day" renumbering event When the enterprise switches ISPs, a "flag day" renumbering event
[RFC4192] may be averted if, during a transitional period, the [RFC4192] may be averted if, during a transitional period, the
enterprise network may number its resources from either prefix. enterprise network may number its resources from either prefix.
One way to facilitate such a transitional period is for the One way to facilitate such a transitional period is for the
enterprise to contract for service from both ISPs during the enterprise to contract for service from both ISPs during the
transition. transition.
o The renumbering event can be initiated by receiving new prefixes o The renumbering event can be initiated by receiving new prefixes
from the same uplink. This might happen if the enterprise network from the same uplink. This might happen if the enterprise network
is switched to a different location within the network topology of is switched to a different location within the network topology
the same ISP due to various considerations, such as commercial, of the same ISP due to various considerations, such as commercial,
performance or services reasons, etc. Alternatively, the ISP performance or services reasons, etc. Alternatively, the ISP
itself might be renumbered due to topology changes or migration to itself might be renumbered due to topology changes or migration
a different or additional prefix. These ISP renumbering events to a different or additional prefix. These ISP renumbering events
would initiate enterprise network renumbering events, of course. would initiate enterprise network renumbering events, of course.
o The enterprise network adds new uplink(s) for multihoming purposes. o The enterprise network adds new uplink(s) for multihoming
This might not be a typical renumbering case because the original purposes. This might not be a typical renumbering case because
addresses will not be changed. However, initial numbering may be the original addresses will not be changed. However, initial
considered as a special renumbering event. The enterprise network numbering may be considered as a special renumbering event. The
removes uplink(s) or old prefixes. enterprise network removes uplink(s) or old prefixes.
3.2. Renumbering caused by Internal Network Factors 3.2. Renumbering caused by Internal Network Factors
o As companies split, merge, grow, relocate or reorganize, the o As companies split, merge, grow, relocate or reorganize, the
enterprise network architectures might need to be re-built. This enterprise network architectures might need to be re-built. This
will trigger partial or total internal renumbering. will trigger partial or total internal renumbering.
o The enterprise network might proactively adopt a new address o The enterprise network might proactively adopt a new address
scheme, for example by switching to a new transition mechanism or scheme, for example by switching to a new transition mechanism or
stage of a transition plan. stage of a transition plan.
o The enterprise network might reorganize its topology or subnets. o The enterprise network might reorganize its topology or subnets.
4. Network Renumbering Considerations and Current Methods 4. Network Renumbering Considerations and Current Methods
In order to carry out renumbering in an enterprise network, In order to carry out renumbering in an enterprise network,
systematic planning and administrative preparation are needed. systematic planning and administrative preparation are needed.
Careful planning and preparation could make the renumbering process Careful planning and preparation could make the renumbering process
smoother. smoother.
This section describes current solutions or strategies for enterprise This section describes current solutions or strategies for
renumbering, chosen among existing mechanisms. There are known gaps enterprise renumbering, chosen among existing mechanisms. There are
analyzed by [I-D.ietf-6renum-gap-analysis] and known gaps analyzed by [I-D.ietf-6renum-gap-analysis] and
[I-D.ietf-6renum-static-problem]. If these gaps are filled in the [I-D.ietf-6renum-static-problem]. If these gaps are filled in the
future, enterprise renumbering can be processed more automatically, future, enterprise renumbering can be processed more automatically,
with fewer issues. with fewer issues.
4.1. Considerations and Current Methods during Network Design 4.1. Considerations and Current Methods during Network Design
This section describes the consideration or issues relevant to This section describes the consideration or issues relevant to
renumbering that a network architect should carefully plan when renumbering that a network architect should carefully plan when
building or designing a new network. building or designing a new network.
skipping to change at page 7, line 31 skipping to change at page 7, line 31
Discovery [I-D.cheshire-dnsext-dns-sd] use names and can reduce Discovery [I-D.cheshire-dnsext-dns-sd] use names and can reduce
the number of places that IP addresses need to be configured. But the number of places that IP addresses need to be configured. But
it should be noted that these protocols are normally used link- it should be noted that these protocols are normally used link-
local only. local only.
Network designers generally have little control over the design of Network designers generally have little control over the design of
application software. However, it is important to avoid any application software. However, it is important to avoid any
software that has built-in dependency on IP addresses instead of software that has built-in dependency on IP addresses instead of
FQDNs [I-D.ietf-6renum-static-problem]. FQDNs [I-D.ietf-6renum-static-problem].
- Usage of Parameterized Address Configuration
Besides DNS records, IP addresses might also be configured in many
other places such as ACLs, various IP filters, various kinds of
text-based configuration files, etc.
In some cases, one IP address can be defined as a value once, and
then the administrators can use either keywords or variables to
call the value in other places such as a sort of internal
inheritance in CLI (command line interface) or other local
configurations. Among the real current devices, some routers
support defining multiple loopback interfaces which can be called
in other configurations. For example, when defining a tunnel, it
can call the defined loopback interface to use its address as the
local address of the tunnel.
This kind of parameterized address configuration is recommended,
since it makes managing a renumbering event easier by reducing the
number of places where a device's configuration must be updated.
- Usage of ULA - Usage of ULA
Unique Local Addresses (ULAs) are defined in [RFC4193] as Unique Local Addresses (ULAs) are defined in [RFC4193] as
provider-independent prefixes. Since there is a 40 bits pseudo provider-independent prefixes. Since there is a 40 bits pseudo
random field in the ULA prefix, there is no practical risk of random field in the ULA prefix, there is no practical risk of
collision (please refer to section 3.2.3 in [RFC4193] for more collision (please refer to section 3.2.3 in [RFC4193] for more
detail). For enterprise networks, using ULA simultaneously with detail). For enterprise networks, using ULA simultaneously with
Provider Aggregated (PA) addresses can provide a logically local Provider Aggregated (PA) addresses can provide a logically local
routing plane separated from the global routing plane. The benefit routing plane separated from the global routing plane. The benefit
is to ensure stable and specific local communication regardless of is to ensure stable and specific local communication regardless of
skipping to change at page 10, line 30 skipping to change at page 10, line 49
be restored after renumbering events at other sites. This also be restored after renumbering events at other sites. This also
applies to host-based connectivity. applies to host-based connectivity.
4.2. Considerations and Current Methods for the Preparation of 4.2. Considerations and Current Methods for the Preparation of
Renumbering Renumbering
In ND, it is not possible to reduce a prefix's lifetime to below two In ND, it is not possible to reduce a prefix's lifetime to below two
hours. So, renumbering should not be an unplanned sudden event. This hours. So, renumbering should not be an unplanned sudden event. This
issue could only be avoided by early planning and preparation. issue could only be avoided by early planning and preparation.
This section describes several recommendations for the preparation of This section describes several recommendations for the preparation
enterprise renumbering event. By adopting these recommendations, a of enterprise renumbering event. By adopting these recommendations,
site could be renumbered more easily. However, these recommendations a site could be renumbered more easily. However, these
might increase the daily traffic, server load, or burden of network recommendations might increase the daily traffic, server load, or
operation. Therefore, only those networks that are expected to be burden of network operation. Therefore, only those networks that are
renumbered soon or very frequently should adopt these expected to be renumbered soon or very frequently should adopt these
recommendations, with balanced consideration between daily cost and recommendations, with balanced consideration between daily cost and
renumbering cost. renumbering cost.
- Reduce the address preferred time or valid time or both. - Reduce the address preferred time or valid time or both.
Long-lifetime addresses might cause issues for renumbering events. Long-lifetime addresses might cause issues for renumbering events.
Particularly, some offline hosts might reconnect using these Particularly, some offline hosts might reconnect using these
addresses after renumbering events. Shorter preferred lifetimes addresses after renumbering events. Shorter preferred lifetimes
with relatively long valid lifetimes may allow short transition with relatively long valid lifetimes may allow short transition
periods for renumbering events and avoid frequent address periods for renumbering events and avoid frequent address
skipping to change at page 11, line 31 skipping to change at page 12, line 7
- Identify long-living sessions - Identify long-living sessions
Any applications which maintain very long transport connections Any applications which maintain very long transport connections
(hours or days) should be identified in advance, if possible. Such (hours or days) should be identified in advance, if possible. Such
applications will need special handling during renumbering, so it applications will need special handling during renumbering, so it
is important to know that they exist. is important to know that they exist.
4.3. Considerations and Current Methods during Renumbering Operation 4.3. Considerations and Current Methods during Renumbering Operation
Renumbering events are not instantaneous events. Normally, there is a Renumbering events are not instantaneous events. Normally, there is
transition period, in which both the old prefix and the new prefix a transition period, in which both the old prefix and the new prefix
are used in the site. Better network design and management, better are used in the site. Better network design and management, better
pre-preparation and longer transition period are helpful to reduce pre-preparation and longer transition period are helpful to reduce
the issues during renumbering operation. the issues during renumbering operation.
- Within/without a flag day - Within/without a flag day
As is described in [RFC4192], "a 'flag day' is a procedure in As is described in [RFC4192], "a 'flag day' is a procedure in
which the network, or a part of it, is changed during a planned which the network, or a part of it, is changed during a planned
outage, or suddenly, causing an outage while the network outage, or suddenly, causing an outage while the network
recovers." recovers."
skipping to change at page 13, line 37 skipping to change at page 14, line 15
all network elements and hosts are using only the new prefixes and all network elements and hosts are using only the new prefixes and
that network management and monitoring systems themselves are that network management and monitoring systems themselves are
still operating correctly. A database clean-up may also be needed. still operating correctly. A database clean-up may also be needed.
5. Security Considerations 5. Security Considerations
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking by an insider attack. For attacks on ND, Secure Neighbor hijacking by an insider attack. For attacks on ND, Secure Neighbor
Discovery (SEND) [RFC3971] is a possible solution, but it is complex Discovery (SEND) [RFC3971] is a possible solution, but it is complex
and there is almost no real deployment at the time of writing. and there is almost no real deployment at the time of writing.
Compared to the non-trivial deployment of SEND, RA Guard [RFC6105] is Compared to the non-trivial deployment of SEND, RA Guard [RFC6105]
a lightweight alternative, which focuses on preventing rogue router is a lightweight alternative, which focuses on preventing rogue
advertisements in a network. However, it was also not widely deployed router advertisements in a network. However, it was also not widely
at the time when this memo was published. deployed at the time when this memo was published.
For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6 For DHCPv6, there are built-in secure mechanisms (like Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 messages [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 messages
[RFC3315] could be utilized. But these security mechanisms also have [RFC3315] could be utilized. But these security mechanisms also have
not been verified by widespread deployment at the time of writing. not been verified by widespread deployment at the time of writing.
A site that is listed by IP address in a black list can escape that A site that is listed by IP address in a black list can escape that
list by renumbering itself. However, the new prefix might be back on list by renumbering itself. However, the new prefix might be back on
a black list rather soon, if the root cause for being added to such a a black list rather soon, if the root cause for being added to such
list is not corrected. In practice, the cost of renumbering will be a list is not corrected. In practice, the cost of renumbering will
typically much larger than the cost of getting off the black list. be typically much larger than the cost of getting off the black list.
Dynamic DNS update might bring risk of DoS attack to the DNS server. Dynamic DNS update might bring risk of DoS attack to the DNS server.
So along with the update authentication, session filtering/limitation So along with the update authentication, session
might also be needed. filtering/limitation might also be needed.
The "make-before-break" approach of [RFC4192] requires the routers The "make-before-break" approach of [RFC4192] requires the routers
keep advertising the old prefixes for some time. But if the ISP keep advertising the old prefixes for some time. But if the ISP
changes the prefixes very frequently, the co-existence of old and new changes the prefixes very frequently, the co-existence of old and
prefixes might cause potential risk to the enterprise routing system, new prefixes might cause potential risk to the enterprise routing
since the old address relevant route path might already invalid and system, since the old address relevant route path might already
the routing system just doesn't know it. However, normally enterprise invalid and the routing system just doesn't know it. However,
scenarios don't involve the extreme situation. normally enterprise scenarios don't involve the extreme situation.
6. IANA Considerations 6. IANA Considerations
This draft does not request any IANA action. This draft does not request any IANA action.
7. Acknowledgements 7. Acknowledgements
This work is inspired by RFC5887, so thank for RFC 5887 authors, This work is inspired by RFC5887, so thank for RFC 5887 authors,
Randall Atkinson and Hannu Flinck. Useful ideas were also presented Randall Atkinson and Hannu Flinck. Useful ideas were also presented
in by documents from Tim Chown and Fred Baker. The authors also want in by documents from Tim Chown and Fred Baker. The authors also want
to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald to thank Wesley George, Olivier Bonaventure, Lee Howard, Ronald
Bonica, other 6renum members, and several reviewers for valuable Bonica, other 6renum members, and several reviewers for valuable
comments. comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day "Service [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day
Location Protocol, Version 2", RFC 2608, June 1999. "Service Location Protocol, Version 2", RFC 2608, June
1999.
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O., and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3646] R. Droms, "DNS Configuration options for Dynamic Host [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander
skipping to change at page 15, line 29 skipping to change at page 16, line 5
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
RFC 4706, October 2006. RFC 4706, October 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 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.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
September 2010. 5996, September 2010.
[RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli [RFC6106] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli
"IPv6 Router Advertisement Option for DNS Configuration", "IPv6 Router Advertisement Option for DNS Configuration",
RFC 6106, November 2011. RFC 6106, November 2011.
8.2. Informative References 8.2. Informative References
[RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000. 2000.
skipping to change at page 16, line 27 skipping to change at page 16, line 49
February 2011. February 2011.
[RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to [RFC6563] Jiang, S., Conrad, D. and Carpenter, B., "Moving A6 to
Historic Status", RFC 6563, May 2012. Historic Status", RFC 6563, May 2012.
[RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix
Exclude Option for DHCPv6-based Prefix Delegation", RFC Exclude Option for DHCPv6-based Prefix Delegation", RFC
6603, May 2012. 6603, May 2012.
[I-D.ietf-dhc-secure-dhcpv6] [I-D.ietf-dhc-secure-dhcpv6]
Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs", working Jiang, S., and S. Shen, "Secure DHCPv6 Using CGAs",
in progress, March 2012. working in progress, March 2012.
[I-D.ietf-dhc-host-gen-id] [I-D.ietf-dhc-host-gen-id]
S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in
DHCPv6", draft-ietf-dhc-host-gen-id (work in progress), DHCPv6", draft-ietf-dhc-host-gen-id (work in progress),
August, 2012. August, 2012.
[I-D.ietf-savi-mix] [I-D.ietf-savi-mix]
Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI Bi, J., Yao, G., Halpern, J., and Levy-Abegnoli, E., "SAVI
for Mixed Address Assignment Methods Scenario", working in for Mixed Address Assignment Methods Scenario", working in
progress, April 2012. progress, April 2012.
[I-D.ietf-dhc-addr-registration] [I-D.ietf-dhc-addr-registration]
Jiang, S., Chen, G., "A Generic IPv6 Addresses Registration Jiang, S., Chen, G., "A Generic IPv6 Addresses
Solution Using DHCPv6", working in progress, May 2012. Registration Solution Using DHCPv6", working in progress,
May 2012.
[I-D.ietf-6renum-gap-analysis] [I-D.ietf-6renum-gap-analysis]
Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap
Analysis", working in progress, August 2012. Analysis", working in progress, August 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", working in Renumbering IPv6 Hosts with Static Addresses", working in
progress, August 2012. progress, August 2012.
 End of changes. 30 change blocks. 
103 lines changed or deleted 130 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/