draft-ietf-6renum-enterprise-03.txt   draft-ietf-6renum-enterprise-04.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: April 14, 2013 B. Carpenter Expires: May 27, 2013 B. Carpenter
University of Auckland University of Auckland
October 15, 2012 November 28, 2012
IPv6 Enterprise Network Renumbering Scenarios and Guidelines IPv6 Enterprise Network Renumbering Scenarios and Guidelines
draft-ietf-6renum-enterprise-03.txt draft-ietf-6renum-enterprise-04.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 working
documents as Internet-Drafts. The list of current Internet-Drafts is documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/. 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 April 14, 2013. This Internet-Draft will expire on May 27, 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 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
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
This document analyzes enterprise renumbering events and describes This document analyzes events that cause renumbering and describes
the best current practice among the existing renumbering mechanisms. the best renumbering practice. Best practices are described in three
According to the different stages of renumbering events, categories: those applicable during network design, those applicable
considerations and best current practices are described in three during preparation for renumbering, and those applicable during the
categories: during network design, for preparation of renumbering, renumbering operation.
and during a renumbering operation.
Table of Contents Table of Contents
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 ........... 4 3. Enterprise Network Renumbering Scenario Categories ........... 4
3.1. Renumbering Caused by External Network Factors........... 4 3.1. Renumbering Caused by External Network Factors........... 4
3.2. Renumbering caused by Internal Network Factors........... 5 3.2. Renumbering caused by Internal Network Factors........... 5
4. Network Renumbering Considerations and Best Current Practices. 5 4. Network Renumbering Considerations and Best Current Practices. 5
4.1. Considerations and Best Current Practices during Network 4.1. Considerations and Best Current Practices during Network
skipping to change at page 3, line 7 skipping to change at page 3, line 7
5. Security Considerations ..................................... 13 5. Security Considerations ..................................... 13
6. IANA Considerations ......................................... 13 6. IANA Considerations ......................................... 13
7. Acknowledgements ............................................ 13 7. Acknowledgements ............................................ 13
8. References .................................................. 13 8. References .................................................. 13
8.1. Normative References ................................... 13 8.1. Normative References ................................... 13
8.2. Informative References ................................. 15 8.2. Informative References ................................. 15
Author's Addresses ............................................. 17 Author's Addresses ............................................. 17
1. Introduction 1. Introduction
IPv6 site renumbering is considered difficult. Network managers might Site renumbering is difficult. Network managers frequently attempt to
prefer to use Provider Independent (PI) addressing for IPv6 to avoid renumbering by numbering their network resources from Provider
attempt to minimize the need for future renumbering. However, Independent (PI) address space. However, widespread use of PI might
widespread use of PI might create very serious BGP4 scaling create serious BGP4 scaling problems and according to Regional
problems and PI space is not always available for enterprises Internet Registry (RIR) policies, PI space is not always available
according to the RIR (Regional Internet Registry) policies. It is for enterprises Therefore, it is desirable to develop mechanisms that
thus desirable to develop mechanisms and practice guidelines that simplify IPv6 renumbering.
could make renumbering a simpler process to reduce demand for IPv6 PI
spaces.
This document undertakes scenario descriptions, including This document undertakes scenario descriptions, including
documentation of current capabilities and existing BCPs, for documentation of current capabilities and existing BCPs, for
enterprise networks. It takes [RFC5887] and other relevant documents enterprise networks. It takes [RFC5887] and other relevant documents
as the primary input. as the primary input.
Since the IPv4 and IPv6 are logically separated from the perspective Since the IPv4 and IPv6 are logically separated from the perspective
of renumbering, regardless of overlapping of the IPv4/IPv6 networks of renumbering, regardless of overlapping of the IPv4/IPv6 networks
or devices, this document focuses on IPv6 only, by leaving IPv4 out or devices, this document focuses on IPv6 only, by leaving IPv4 out
of scope. Dual-stack network or IPv4/IPv6 transition scenarios are of scope. Dual-stack network or IPv4/IPv6 transition scenarios are
out of scope, too. out 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 considered out of scope, but it can Renumbering in home networks is out of scope, but it can also benefit
also benefit from the analysis in this document. from the analysis in this document.
The concept of enterprise network and a typical network illustration The concept of enterprise network and a typical network illustration
are introduced first. Then, according to the different stages of are introduced first. Then, best renumbering practices are introduced
renumbering events, considerations and best current practices are according to the following categories: those applicable during
described in three categories: during network design, for preparation network design, those applicable during preparation for renumbering,
of renumbering, and during renumbering operation. and those applicable during the 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.
The enterprise network architecture is illustrated in the figure Figure 1 provides a sample enterprise network architecture. Those
below. Those entities relevant to renumbering are highlighted. entities relevant to renumbering are highlighted.
Address reconfiguration is fulfilled either by DHCPv6 or ND Address reconfiguration is fulfilled either by Dynamic Host
protocols. During the renumbering event, the DNS records need to be configuration Protocol for IPv6 (DHCPv6) or Neighbor Discovery for
synchronized while routing tables, ACLs and IP filtering tables in IPv6 (ND) protocols. During the renumbering event, the Domain Name
various devices also need to be updated, too. Service (DNS) records need to be synchronized while routing tables,
Access Control Lists (ACLs) and IP filtering tables in various
devices also need to be updated, too.
Static address issue is described in a dedicated draft Static address issue is described in a dedicated draft
[I-D.ietf-6renum-static-problem]. [I-D.ietf-6renum-static-problem].
Uplink 1 Uplink 2 Uplink 1 Uplink 2
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+ +---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ | | +-------+ +-------+ |
| Enterprise Network | | Enterprise Network |
skipping to change at page 4, line 36 skipping to change at page 4, line 36
| | | | | | | |
| -+---+----+-------+---+--+- | | -+---+----+-------+---+--+- |
| | | | | | | | | | | |
| +-+--+ +--+-+ +--+-+ +-+--+ | | +-+--+ +--+-+ +--+-+ +-+--+ |
| |Host| |Host| |Host| |Host| | | |Host| |Host| |Host| |Host| |
| +----+ +----+ +----+ +----+ | | +----+ +----+ +----+ +----+ |
+----------------------------------------+ +----------------------------------------+
Figure 1 Enterprise network illustration 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. The stack in which a logical IPv6 plane is independent from IPv4.
complicated IPv4/IPv6 co-existence scenarios are out of scope. IPv4/IPv6 co-existence scenarios are out of scope.
This document focuses on the unicast addresses; site-local, link- This document focuses on the unicast addresses; site-local, link-
local, multicast and anycast addresses are out of scope. local, multicast and anycast addresses are out of scope.
3. Enterprise Network Renumbering Scenario Categories 3. Enterprise Network Renumbering Scenario Categories
In this section, we divide enterprise network renumbering scenarios In this section, we divide enterprise network renumbering scenarios
into two categories defined by external and internal network factors, into two categories defined by external and internal network factors,
which require renumbering for different reasons. which require renumbering for different reasons.
3.1. Renumbering Caused by External Network Factors 3.1. Renumbering Caused by External Network Factors
The most influential external network factor is the uplink ISP. The following ISP uplink-related events can cause renumbering:
o The enterprise network switches to a new ISP. Of course, the o The enterprise network switches to a new ISP. When this occurs,
prefixes received from different ISPs are different. This is the the enterprise stop numbering its resources form the prefix
most common scenario. allocated by the old ISP and renumbers its resources from the
prefix allocated by the new ISP.
Whether there is an overlap time between the old and new ISPs When the enterprise switches ISPs, a "flag day" renumbering event
would also influence the possibility whether the enterprise can [RFC4192] may be averted if, during a transitional period, the
fulfill renumbering without a flag day [RFC4192]. enterprise network may number its resources from either prefix.
One way to facilitate such a transitional period is for the
enterprise to contract for service from both ISPs during the
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 of
the same ISP due to various considerations, such as commercial, 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 to
a different or additional prefix. These ISP renumbering events 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.
skipping to change at page 6, line 20 skipping to change at page 6, line 26
- Prefix Delegation - Prefix Delegation
In a large or a multi-site enterprise network, the prefix should In a large or a multi-site enterprise network, the prefix should
be carefully managed, particularly during renumbering events. be carefully managed, particularly during renumbering events.
Prefix information needs to be delegated from router to router. Prefix information needs to be delegated from router to router.
The DHCPv6 Prefix Delegation options [RFC3633] and The DHCPv6 Prefix Delegation options [RFC3633] and
[RFC6603] provide a mechanism for automated delegation of IPv6 [RFC6603] provide a mechanism for automated delegation of IPv6
prefixes. Normally, DHCPv6 PD options are used between the prefixes. Normally, DHCPv6 PD options are used between the
internal enterprise routers, for example, a router receives internal enterprise routers, for example, a router receives
prefix(es) from its upstream router (might be a border gateway or prefix (es) from its upstream router (might be a border gateway or
edge router .etc) through DHCPv6 PD options and then advertise it edge router .etc) through DHCPv6 PD options and then advertise it
(them) to the local hosts through RA messages. (them) to the local hosts through RA messages.
- Usage of FQDN - Usage of FQDN
In general, Fully-Qualified Domain Names (FQDNs) are recommended In general, Fully-Qualified Domain Names (FQDNs) are recommended
to be used to configure network connectivity, such as tunnels, to be used to configure network connectivity, such as tunnels,
whenever possible. The capability to use FQDNs as endpoint names servers etc. The capability to use FQDNs as endpoint names has
has been standardized in several RFCs, such as [RFC5996], although been standardized in several RFCs, such as [RFC5996], although
many system/network administrators do not realize that it is there many system/network administrators do not realize that it is there
and works well as a way to avoid manual modification during and works well as a way to avoid manual modification during
renumbering. renumbering.
Service Location Protocol [RFC2608], multicast DNS Note that, using FQDN would rely on DNS systems. For a link local
[I-D.cheshire-dnsext-multicastdns] with SRV records, and DNS network that does not have a DNS system, multicast DNS
Service Discovery [I-D.cheshire-dnsext-dns-sd] for service [I-D.cheshire-dnsext-multicastdns] could be utilized. For some
discovery can reduce the number of places that IP addresses need specific circumstances, using FQDN might not be proper if adding
to be configured. But it should be noted that multicast DNS is DNS service in the node/network would cause un-desired complexity
link-local only. or issues.
Service discovery protocols such as Service Location Protocol
[RFC2608], multicast DNS with SRV records and DNS Service
Discovery [I-D.cheshire-dnsext-dns-sd] can engage using FQDN and
reduce the number of places that IP addresses need to be
configured. But it should be noted that these protocols are
normally used link-local only.
- 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, and they are globally unique to provider-independent prefixes. And since there is a 40 bits pseudo
avoid collision. For enterprise networks, using ULA along with PA random field in the ULA prefix, there is no practical risk of
can provide a logically local routing plane separated from the collision (please refer to section 3.2.3 in [RFC4193] for more
detail). For enterprise networks, using ULA along with PA can
provide a logically local routing plane separated from the
globally routing plane. The benefit is to ensure stable and globally routing plane. The benefit is to ensure stable and
specific local communication regardless of the ISP uplink failure. specific local communication regardless of the ISP uplink failure.
This benefit is especially meaningful for renumbering. It mainly This benefit is especially meaningful for renumbering. It mainly
includes three use cases as the following. includes three use cases as the following.
When renumbering, as RFC4192 suggested, it has a period to keep During the transition period, it is desirable to isolate local
using the old prefix(es) before the new prefix(es) is(are) stable. communication changes in the global routing plane. If we use ULA
In the process of adding new prefix(es) and deprecating old for the local communication, this isolation is achieved.
prefix(es), it is not easy to keep the local communication immune
of global routing plane change. If we use ULA for the local
communication, the separated local routing plane can isolate the
affecting by global routing change.
Enterprise administrators might want to avoid the need to renumber Enterprise administrators might want to avoid the need to renumber
their internal-only, private nodes when they have to renumber the their internal-only, private nodes when they have to renumber the
PA addresses of the whole network because of changing ISPs, ISPs PA addresses of the whole network because of changing ISPs, ISPs
restructuring their address allocation, or any other reasons. In restructuring their address allocation, or any other reasons. In
these situations, ULA is an effective tool for the internal-only these situations, ULA is an effective tool for the internal-only
nodes. nodes.
For multicast, ULA can be a way of avoiding renumbering from For multicast, ULA can be a way of avoiding renumbering from
having an impact on multicast. In most deployments multicast is having an impact on multicast. In most deployments multicast is
skipping to change at page 8, line 32 skipping to change at page 8, line 45
handling in such scenarios. handling in such scenarios.
- DNS - DNS
It is recommended that the site have an automatic and systematic It is recommended that the site have an automatic and systematic
procedure for updating/synchronizing its DNS records, including procedure for updating/synchronizing its DNS records, including
both forward and reverse mapping [RFC2874]. A manual on-demand both forward and reverse mapping [RFC2874]. A manual on-demand
updating model does not scale, and increases the chance of errors. updating model does not scale, and increases the chance of errors.
Although the A6 DNS record model [RFC2874] was designed for easier Although the A6 DNS record model [RFC2874] was designed for easier
renumbering, it has a lot of unsolved technical issues [RFC3364]. renumbering, it left many unsolved technical issues [RFC3364].
Therefore, it has been moved to experimental status [RFC3363], and Therefore, it has been moved to historic status [RFC6563] and is
will move to historic status by [RFC6563] (Moving A6 to Historic not recommended.
Status). So A6 is not recommended.
In order to simplify the operation procedure, the network In order to simplify the operational procedure, the network
architect should combine the forward and reverse DNS updates in a architect should combine the forward and reverse DNS updates in a
single procedure. single procedure.
Often, a small site depends on its ISP's DNS system rather than Often, a small site depends on its ISP's DNS system rather than
maintaining its own. When renumbering, this requires maintaining its own. When renumbering, this requires
administrative coordination between the site and its ISP. administrative coordination between the site and its ISP.
The DNS synchronization can be completed through the Secure DNS The DNS synchronization can be completed through the Secure DNS
Dynamic Update [RFC3007]. Dynamic DNS update can be provided by Dynamic Update [RFC3007]. Dynamic DNS update can be provided by
the DHCPv6 client or by the server on behalf of individual hosts. the DHCPv6 client or by the server on behalf of individual hosts.
skipping to change at page 9, line 15 skipping to change at page 9, line 30
For example, if a client wants the server to update the FQDN- For example, if a client wants the server to update the FQDN-
address mapping in the DNS server, it can include the Client FQDN address mapping in the DNS server, it can include the Client FQDN
option with proper settings in the SOLICIT with Rapid Commit, option with proper settings in the SOLICIT with Rapid Commit,
REQUEST, RENEW, and REBIND message originated by the client. When REQUEST, RENEW, and REBIND message originated by the client. When
DHCPv6 server gets this option, it can use the dynamic DNS update DHCPv6 server gets this option, it can use the dynamic DNS update
on behalf of the client. In this document, we promote to support on behalf of the client. In this document, we promote to support
this FQDN option. But since it's a DHCPv6 option, it implies that this FQDN option. But since it's a DHCPv6 option, it implies that
only the DHCP-managed networks are suitable for this operation. In only the DHCP-managed networks are suitable for this operation. In
SLAAC mode, sometimes hosts also need to register addresses on a SLAAC mode, sometimes hosts also need to register addresses on a
registration server, which could in fact be a DHCPv6 server (as registration server, which could in fact be a DHCPv6 server (as
described in described in [I-D.ietf-dhc-addr-registration]); then the server
[I-D.ietf-dhc-addr-registration]); then the server would update would update corresponding DNS records.
corresponding DNS records.
- Security - Security
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking. Malicious entity in the network can forge prefixes to hijacking. Malicious entity in the network can forge prefixes to
renumber the hosts. So proper network security mechanisms are renumber the hosts. So proper network security mechanisms are
needed. needed.
For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible For ND, Secure Neighbor Discovery (SEND, [RFC3971]) is a possible
solution, but it is complex and there's almost no real deployment solution, but it is complex and there's almost no real deployment
skipping to change at page 9, line 45 skipping to change at page 10, line 11
DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6 DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]), and authentication of DHCPv6
messages [RFC3315] could be utilized. But these security messages [RFC3315] could be utilized. But these security
mechanisms also haven't been verified by wide real deployment. mechanisms also haven't been verified by wide real deployment.
- Miscellaneous - Miscellaneous
A site or network should also avoid embedding addresses from other A site or network should also avoid embedding addresses from other
sites or networks in its own configuration data. Instead, the sites or networks in its own configuration data. Instead, the
Fully-Qualified Domain Names should be used. Thus, these Fully-Qualified Domain Names should be used. Thus, these
connections can survive after renumbering events at other sites. connections can survive after renumbering events at other sites.
This also applies to host-based connectivities. This also applies to host-based connectivity.
4.2. Considerations and Best Current Practices for the Preparation of 4.2. Considerations and Best Current Practices 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 of
enterprise renumbering event. By adopting these recommendations, a enterprise renumbering event. By adopting these recommendations, a
skipping to change at page 14, line 20 skipping to change at page 14, line 27
(DHCPv6)", RFC 3315, July 2003. (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.
[RFC3956] Savola, P., and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005
[RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R., and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6 [RFC4704] B. Volz, "The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
RFC 4706, October 2006. RFC 4706, October 2006.
skipping to change at page 15, line 22 skipping to change at page 15, line 22
2000. 2000.
[RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain, [RFC3363] R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain,
"Representing Internet Protocol version 6 (IPv6) Addresses "Representing Internet Protocol version 6 (IPv6) Addresses
in the Domain Name System (DNS)", RFC 3363, August 2002. in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support [RFC3364] R. Austein, "Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)", RFC 3364, August for Internet Protocol version 6 (IPv6)", RFC 3364, August
2002. 2002.
[RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC [RFC4057] J. Bound, Ed. "IPv6 Enterprise Network Scenarios", RFC 4057,
4057, June 2005. June 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4864] Van de Velde, G., T. Hain, R. Droms, B. Carpenter, E. Klein,
Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E., and Bagnulo, M., "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010. Still Needs Work", RFC 5887, May 2010.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
 End of changes. 26 change blocks. 
77 lines changed or deleted 76 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/