draft-ietf-6renum-enterprise-01.txt   draft-ietf-6renum-enterprise-02.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: January 14, 2013 B. Carpenter Expires: March 04, 2013 B. Carpenter
University of Auckland University of Auckland
July 16, 2012 September 01, 2012
IPv6 Enterprise Network Renumbering Scenarios and Guidelines IPv6 Enterprise Network Renumbering Scenarios and Guidelines
draft-ietf-6renum-enterprise-01.txt draft-ietf-6renum-enterprise-02.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 January 14, 2013. This Internet-Draft will expire on March 04, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
According to the different stages of renumbering events, According to the different stages of renumbering events,
considerations and best current practices are described in three considerations and best current practices are described in three
categories: during network design, for preparation of renumbering, categories: during network design, for preparation of renumbering,
and during a 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........... 5 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
Design ....................................................... 6 Design ....................................................... 6
4.2. Considerations and Best Current Practices for the Preparation 4.2. Considerations and Best Current Practices for the Preparation
of Renumbering ............................................... 9 of Renumbering ............................................... 9
4.3. Considerations and Best Current Practices during Renumbering 4.3. Considerations and Best Current Practices during Renumbering
Operation ................................................... 10 Operation ................................................... 10
5. Security Considerations ..................................... 12 5. Security Considerations ..................................... 12
6. IANA Considerations ......................................... 13 6. IANA Considerations ......................................... 13
7. Acknowledgements ............................................ 13 7. Acknowledgements ............................................ 13
8. Change Log [RFC Editor please remove] ....................... 13 8. References .................................................. 13
9. References .................................................. 13 8.1. Normative References ................................... 13
9.1. Normative References ................................... 13 8.2. Informative References ................................. 14
9.2. Informative References ................................. 14
Author's Addresses ............................................. 16 Author's Addresses ............................................. 16
1. Introduction 1. Introduction
IPv6 site renumbering is considered difficult. Network managers IPv6 site renumbering is considered difficult. Network managers might
currently prefer to use Provider Independent (PI) addressing for IPv6 prefer to use Provider Independent (PI) addressing for IPv6 to
to attempt to minimize the need for future renumbering. However, attempt to minimize the need for future renumbering. However,
widespread use of PI may create very serious BGP4 scaling problems widespread use of PI may create very serious BGP4 scaling problems
and PI space is not always available for enterprise according to the and PI space is not always available for enterprises according to the
RIR (Regional Internet Registry) policies. It is thus desirable to RIR (Regional Internet Registry) policies. It is thus desirable to
develop tools and practices that may make renumbering a simpler develop mechanisms and practice guidelines that could make
process to reduce demand for IPv6 PI space. In any case, renumbering renumbering a simpler process to reduce demand for IPv6 PI spaces.
may be necessary for other reasons.
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.
The IPv4 and IPv6 are logically separated from the perspective of The IPv4 and IPv6 are logically separated 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, by leaving IPv4 out of devices. This document focuses on IPv6 only, by 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
skipping to change at page 3, line 37 skipping to change at page 3, line 36
This document focuses on enterprise network renumbering, though most This document focuses on enterprise network renumbering, though most
of the analysis is also applicable to ISP network renumbering. of the analysis is also applicable to ISP network renumbering.
Renumbering in home networks is considered out of scope, though it Renumbering in home networks is considered out of scope, though it
may also benefit from the analysis in this document. may also benefit 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, according to the different stages of
renumbering events, considerations and best current practices are renumbering events, considerations and best current practices are
described in three categories: during network design, for preparation described in three categories: during network design, for preparation
of renumbering, and during renumbering operation. A gap inventory is of renumbering, and during renumbering operation.
listed at the end of this document.
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 The enterprise network architecture is illustrated in the figure
below. Those entities relevant to renumbering are highlighted. below. Those entities relevant to renumbering are highlighted.
Address reconfiguration is fulfilled either by DHCPv6 or ND Address reconfiguration is fulfilled either by DHCPv6 or ND
protocols. During the renumbering event, the DNS records need to be protocols. During the renumbering event, the DNS records need to be
synchronized while routing tables, ACLs and IP filtering tables in synchronized while routing tables, ACLs and IP filtering tables in
various gateways also need to be updated, too. various devices also need to be updated, too.
Static address issue is described in a dedicated draft [I- Static address issue is described in a dedicated draft
D.carpenter-6renum-static-problem]. (Editor's note: some major [I-D.ietf-6renum-static-problem].
conclusions would be included in this document if we can get
consensus on the discussion of the static address problem.)
Uplink 1 Uplink 2 Uplink 1 Uplink 2
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
+---- |Gateway| --------- |Gateway| -----+ +---- |Gateway| --------- |Gateway| -----+
| +-------+ +-------+ | | +-------+ +-------+ |
| Enterprise Network | | Enterprise Network |
| +------+ +------+ +------+ | | +------+ +------+ +------+ |
| | APP | |DHCPv6| | DNS | | | | APP | |DHCPv6| | DNS | |
| |Server| |Server| +Server+ | | |Server| |Server| +Server+ |
skipping to change at page 5, line 5 skipping to change at page 4, line 48
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 most influential external network factor is the uplink ISP.
o The enterprise network switches to a new ISP. Of course, the o The enterprise network switches to a new ISP. Of course, the
prefixes received from different ISPs are different. This is the prefixes received from different ISPs are different. This is the
most common scenario. most common scenario.
Whether there is an overlap time between the old and new ISPs Whether there is an overlap time between the old and new ISPs
would also influence the possibility whether the enterprise can would also influence the possibility whether the enterprise can
fulfill renumbering without a flag day [RFC4192]. fulfill renumbering without a flag day [RFC4192].
o The renumbering event may be initiated by receiving new prefixes o The renumbering event may 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.
o The enterprise network adds new uplink(s) for multihoming o The enterprise network adds new uplink(s) for multihoming purposes.
purposes. This may not a typical renumbering because the original This may not be a typical renumbering case because the original
addresses will not be changed. However, initial numbering may be addresses will not be changed. However, initial numbering may be
considered as a special renumbering event. The enterprise network considered as a special renumbering event. The enterprise network
removes uplink(s) or old prefixes. 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 may need to be re-built. This enterprise network architectures may need to be re-built. This
will trigger the internal renumbering. will trigger the internal renumbering.
skipping to change at page 6, line 5 skipping to change at page 5, line 47
o The enterprise network may reorganize its topology or subnets. o The enterprise network may reorganize its topology or subnets.
4. Network Renumbering Considerations and Best Current Practices 4. Network Renumbering Considerations and Best Current Practices
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.
Carefully planning and preparation could make the renumbering process Carefully planning and preparation could make the renumbering process
smoother. smoother.
This section tries to give the recommended solutions or strategies This section recommends some solutions or strategies for the
for the enterprise renumbering, chosen among existing mechanisms. enterprise renumbering, chosen among existing mechanisms. There are
There are known gaps analyzed by [I-D.liu-6renum-gap-analysis]. If known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps
these gaps are filled in the future, the enterprise renumbering may are filled in the future, the enterprise renumbering may be processed
be processed more automatically, with fewer issues. more automatically, with fewer issues.
4.1. Considerations and Best Current Practices during Network Design 4.1. Considerations and Best Current Practices 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.
- 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] [I-D.ietf-dhc-pd- The DHCPv6 Prefix Delegation options [RFC3633] and
exclude] 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. internal enterprise routers, for example, a router receives
prefix(es) from its upstream router (may be a border gateway or
edge router .etc) through DHCPv6 PD options and then advertise it
(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 whenever possible. The capability to use FQDNs as endpoint names
has been standardized in several RFCs, such as [RFC5996], although has 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.
skipping to change at page 7, line 34 skipping to change at page 7, line 32
routable externally. Hence one may at least internally make use of routable externally. Hence one may at least internally make use of
ULA for multicast specific infrastructure. ULA for multicast specific infrastructure.
- Address Types - Address Types
This document focuses on the dynamically-configured global unicast This document focuses on the dynamically-configured global unicast
addresses in enterprise networks. They are the targets of addresses in enterprise networks. They are the targets of
renumbering events. renumbering events.
Manual-configured addresses are not scalable in medium to large Manual-configured addresses are not scalable in medium to large
sites, hence are out of scope. Manual-configured addresses/hosts sites, hence are out of scope. Manually-configured addresses/hosts
should be avoided as much as possible. should be avoided as much as possible.
- Address configuration models - Address configuration models
In IPv6 networks, there are two auto-configuration models for In IPv6 networks, there are two auto-configuration models for
address assignment: Stateless Address Auto-Configuration (SLAAC) address assignment: Stateless Address Auto-Configuration (SLAAC,
by Neighbor Discovery (ND, [RFC4861, RFC4862]) and stateful [RFC4862]) by Neighbor Discovery (ND, [RFC4861]) and stateful
address configuration by Dynamic Host Configuration Protocol for address configuration by Dynamic Host Configuration Protocol for
IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also IPv6 (DHCPv6, [RFC3315]). In the latest work, DHCPv6 can also
support host-generated address model by assigning a prefix through support host-generated address model by assigning a prefix through
DHCPv6 messages [I-D.ietf-dhc-host-gen-id]. DHCPv6 messages [I-D.ietf-dhc-host-gen-id].
ND is considered easier to renumber by broadcasting a Router ND is considered easier to renumber by broadcasting a Router
Advertisement message with a new prefix. DHCPv6 can also trigger Advertisement message with a new prefix. DHCPv6 can also trigger
the renumbering process by sending unicast RECONFIGURE messages, the renumbering process by sending unicast RECONFIGURE messages,
though it may cause a large number of interactions between hosts though it may cause a large number of interactions between hosts
and DHCPv6 server. and DHCPv6 server.
skipping to change at page 8, line 27 skipping to change at page 8, line 27
However, since DHCPv6 is also used to configure many other network However, since DHCPv6 is also used to configure many other network
parameters, there are ND and DHCPv6 co-existence scenarios. parameters, there are ND and DHCPv6 co-existence scenarios.
Combinations of address configuration models may coexist within a Combinations of address configuration models may coexist within a
single enterprise network. [I-D.ietf-savi-mix] provides single enterprise network. [I-D.ietf-savi-mix] provides
recommendations to avoid collisions and to review collision recommendations to avoid collisions and to review collision
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/synchronising 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 has a lot of unsolved technical issues [RFC3364].
Therefore, it has been moved to experimental status [RFC3363], and Therefore, it has been moved to experimental status [RFC3363], and
will move to historic status by [RFC6563] (Moving A6 to Historic will move to historic status by [RFC6563] (Moving A6 to Historic
Status). So A6 is not recommended. Status). So A6 is not recommended.
In order to simplify the operation procedure, the network In order to simplify the operation procedure, the network
skipping to change at page 9, line 13 skipping to change at page 9, line 13
associated AAAA and PTR RRs. For example, if a client wants the associated AAAA and PTR RRs. For example, if a client wants the
server to update the FQDN-address mapping in the DNS server, it server to update the FQDN-address mapping in the DNS server, it
can include the Client FQDN option with proper settings in the can include the Client FQDN option with proper settings in the
SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message
originated by the client. When DHCPv6 server gets this option, it originated by the client. When DHCPv6 server gets this option, it
can use the dynamic DNS update on behalf of the client. In this can use the dynamic DNS update on behalf of the client. In this
document, we promote to support this FQDN option. But since it's a document, we promote to support this FQDN option. But since it's a
DHCPv6 option, it implies that only the DHCP-managed networks are DHCPv6 option, it implies that only the DHCP-managed networks are
suitable for this operation. In SLAAC mode, sometimes hosts also suitable for this operation. In SLAAC mode, sometimes hosts also
need to register addresses on a registration server, which could need to register addresses on a registration server, which could
in fact be a DHCPv6 server (as described in [I-D.ietf-dhc-addr- in fact be a DHCPv6 server (as described in
registration]); then the server would update corresponding DNS [I-D.ietf-dhc-addr-registration]); then the server would update
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
so far. Comparing the non-trivial deployment of SEND, RA guard so far. Comparing the non-trivial deployment of SEND, RA guard
[RFC6105] is a light-weight alternative, however, it also hasn't [RFC6105] is a light-weight alternative, which focuses on rogue
been widely deployed since it hasn't been published for long. router advertisements proof in a L2 network. However, it also
hasn't been widely deployed since it hasn't been published for
long.
For DHCPv6, there are built-in secure mechanisms (like Secure For DHCPv6, there are built-in secure mechanisms (like Secure
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
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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
site could be renumbered more easily. However, these recommendations site could be renumbered more easily. However, these recommendations
are not cost free. They might increase the daily burden of network might increase the daily traffic, server load, or burden of network
operation. Therefore, only those networks that are expected to be operation. Therefore, only those networks that are expected to be
renumbered soon or very frequently should adopt these recommendations, renumbered soon or very frequently should adopt these
with balanced consideration between daily cost and renumbering cost. recommendations, with balanced consideration between daily cost and
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 may cause issues for renumbering events. Long-lifetime addresses may cause issues for renumbering events.
Particularly, some offline hosts may reconnect using these Particularly, some offline hosts may 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
renewals. renewals.
- Reduce the DNS record TTL on the local DNS server. - Reduce the DNS record TTL on the local DNS server.
The DNS AAAA resource record TTL on the local DNS server should be The DNS AAAA resource record TTL on the local DNS server should be
manipulated to ensure that stale addresses are not cached. manipulated to ensure that stale addresses are not cached.
- Reduce the DNS configuration lifetime on the hosts. - Reduce the DNS configuration lifetime on the hosts.
Since the DNS server could be renumbered as well, the DNS Since the DNS server could be renumbered as well, the DNS
configuration lifetime on the hosts should also be reduced if configuration lifetime on the hosts should also be reduced if
renumbering events are expected. The DNS configuration can be done renumbering events are expected. In ND, The DNS configuration can
through either ND [RFC6106] or DHCPv6 [RFC3646]. be done through reducing the lifetime value in RDNSS option
[RFC6106]. In DHCPv6, the DNS configuration option specified in
[RFC3646] doesn't provide lifetime attribute, but we can reduce
the DHCPv6 client lease time to achieve similar effect.
- 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 Best Current Practices during Renumbering 4.3. Considerations and Best Current Practices during Renumbering
Operation Operation
skipping to change at page 12, line 18 skipping to change at page 12, line 23
DNS configuration on hosts should be updated if local recursive DNS configuration on hosts should be updated if local recursive
DNS servers are renumbered. During the transition period, both old DNS servers are renumbered. During the transition period, both old
and new DNS server addresses may co-exist on the hosts. If the and new DNS server addresses may co-exist on the hosts. If the
lifetime of DNS configuration is shorter than the transition lifetime of DNS configuration is shorter than the transition
period, name resolving failure may be reduced to minimum. A period, name resolving failure may be reduced to minimum. A
notification mechanism may be needed to indicate to the hosts that notification mechanism may be needed to indicate to the hosts that
a renumbering event of local recursive DNS happens or is going to a renumbering event of local recursive DNS happens or is going to
take place. take place.
[Bing] Gap 7.1
- Tunnel concentrator renumbering - Tunnel concentrator renumbering
A tunnel concentrator itself might be renumbered. This change A tunnel concentrator itself might be renumbered. This change
should be reconfigured in relevant hosts or routers, unless the should be reconfigured in relevant hosts or routers, unless the
configuration of tunnel concentrator was based on FQDN. configuration of tunnel concentrator was based on FQDN. However,
even if FQDN is used, some other tunnel-relevant configuration may
still exist, for example IPSec, so fail in renumbering.
- Connectivity session survivability - Connectivity session survivability
During the renumbering operations, connectivity sessions in IP During the renumbering operations, connectivity sessions in IP
layer would break if the old address is deprecated before the layer would break if the old address is deprecated before the
session ends. However, the upper layer sessions may survive by session ends. However, the upper layer sessions may survive by
using session survivability technologies, such as SHIM6 [RFC5533]. using session survivability technologies, such as SHIM6 [RFC5533].
As mentioned above, some long-living applications may need to be As mentioned above, some long-living applications may need to be
handled specially. handled specially.
skipping to change at page 13, line 8 skipping to change at page 13, line 12
verified whether they are suitable for ensuring security while not verified whether they are suitable for ensuring security while not
bringing too much operational complexity and cost. bringing too much operational complexity and cost.
Dynamic DNS update may bring risk of DoS attack to the DNS server. So Dynamic DNS update may bring risk of DoS attack to the DNS server. So
along with the update authentication, session filtering/limitation along with the update authentication, session filtering/limitation
may also be needed. may 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 new
prefixes may cause potential risk to the enterprise routing system. prefixes may cause potential risk to the enterprise routing system
However, enterprise scenarios may not involve the extreme situation; since the old address relevant route path may already invalid and the
this issue needs to be identified in the future. routing system just doesn't know it. However, normally enterprise
scenarios don't involve the extreme situation.
The security configuration updates will need to be made in two stages
(immediately before and immediately after the event).
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 illuminated by RFC5887, so thank for RFC 5887 authors, This work is illuminated 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 and other 6renum members to thank Wesley George, Olivier Bonaventure and other 6renum members
for valuable comments. for valuable comments.
8. Change Log [RFC Editor please remove] 8. References
draft-jiang-6renum-enterprise-00, original version, 2011-07-01
draft-jiang-6renum-enterprise-01, Update according to IETF81 and mail
list discussions, 2011-10-09
draft-jiang-6renum-enterprise-02, Update according to IETF82
discussions, 2011-12-06
draft-ietf-6renum-enterprise-00, Update according to mail list
discussions, 2012-02-06
9. References
9.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 "Service
Location Protocol, Version 2", RFC 2608, June 1999. 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., and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(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 14, line 46 skipping to change at page 14, line 30
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, "Internet
Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, Key Exchange Protocol Version 2 (IKEv2)", RFC 5996,
September 2010. 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.
9.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.
[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, June 2005. 4057, 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.
[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.
[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", working
in progress. 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),
April, 2011. 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. progress, April 2012.
[I-D.ietf-dhc-pd-exclude] [RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix
J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC
Exclude Option for DHCPv6-based Prefix Delegation", working 6603, May 2012.
in progress.
[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 Registration
Solution Using DHCPv6", working in progress. 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. Analysis", working in progress, August 2012.
[I-D.carpenter-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. progress, August 2012.
Author's Addresses Author's Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd., Q14, Huawei Campus
Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
EMail: jiangsheng@huawei.com EMail: jiangsheng@huawei.com
Bing Liu Bing Liu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd., Q14, Huawei Campus
Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
EMail: leo.liubing@huawei.com EMail: leo.liubing@huawei.com
Brian Carpenter Brian Carpenter
D Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
 End of changes. 44 change blocks. 
98 lines changed or deleted 85 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/