draft-ietf-6renum-enterprise-02.txt   draft-ietf-6renum-enterprise-03.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: March 04, 2013 B. Carpenter Expires: April 14, 2013 B. Carpenter
University of Auckland University of Auckland
September 01, 2012 October 15, 2012
IPv6 Enterprise Network Renumbering Scenarios and Guidelines IPv6 Enterprise Network Renumbering Scenarios and Guidelines
draft-ietf-6renum-enterprise-02.txt draft-ietf-6renum-enterprise-03.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 March 04, 2013. This Internet-Draft will expire on April 14, 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 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 ........... 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
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 .............................................. 10
4.3. Considerations and Best Current Practices during Renumbering 4.3. Considerations and Best Current Practices during Renumbering
Operation ................................................... 10 Operation ................................................... 11
5. Security Considerations ..................................... 12 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 ................................. 14 8.2. Informative References ................................. 15
Author's Addresses ............................................. 16 Author's Addresses ............................................. 17
1. Introduction 1. Introduction
IPv6 site renumbering is considered difficult. Network managers might IPv6 site renumbering is considered difficult. Network managers might
prefer to use Provider Independent (PI) addressing for IPv6 to prefer to use Provider Independent (PI) addressing for IPv6 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 might create very serious BGP4 scaling
and PI space is not always available for enterprises according to the problems and PI space is not always available for enterprises
RIR (Regional Internet Registry) policies. It is thus desirable to according to the RIR (Regional Internet Registry) policies. It is
develop mechanisms and practice guidelines that could make thus desirable to develop mechanisms and practice guidelines that
renumbering a simpler process to reduce demand for IPv6 PI spaces. 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.
The IPv4 and IPv6 are logically separated from the perspective of Since the IPv4 and IPv6 are logically separated from the perspective
renumbering, regardless of overlapping of the IPv4/IPv6 networks or of renumbering, regardless of overlapping of the IPv4/IPv6 networks
devices. This document focuses on IPv6 only, by leaving IPv4 out of or devices, this document focuses on IPv6 only, by leaving IPv4 out
scope. Dual-stack network or IPv4/IPv6 transition scenarios are out of scope. Dual-stack network or IPv4/IPv6 transition scenarios are
of scope, too. out of scope, too.
This document focuses on enterprise network renumbering, though most This document focuses on enterprise network renumbering, however,
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, though it Renumbering in home networks is considered out of scope, but it can
may also benefit from the analysis in this document. 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. of renumbering, and during 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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
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 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.
o The enterprise network adds new uplink(s) for multihoming purposes. o The enterprise network adds new uplink(s) for multihoming purposes.
This may not be a typical renumbering case because the original This might 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 might need to be re-built. This
will trigger the internal renumbering. will trigger the internal renumbering.
o The enterprise network may proactively adopt a new address scheme, o The enterprise network might proactively adopt a new address
for example by switching to a new transition mechanism or stage of scheme, for example by switching to a new transition mechanism or
a transition plan. stage of a transition plan.
o The enterprise network may reorganize its topology or subnets. o The enterprise network might 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 recommends some solutions or strategies for the This section recommends some solutions or strategies for the
enterprise renumbering, chosen among existing mechanisms. There are enterprise renumbering, chosen among existing mechanisms. There are
known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps known gaps analyzed by [I-D.ietf-6renum-gap-analysis]. If these gaps
are filled in the future, the enterprise renumbering may be processed are filled in the future, the enterprise renumbering can 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] 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 (may 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 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.
Service Location Protocol [RFC2608] and multicast DNS with SRV Service Location Protocol [RFC2608], multicast DNS
records for service discovery can reduce the number of places that [I-D.cheshire-dnsext-multicastdns] with SRV records, and DNS
IP addresses need to be configured. But it should be noted that Service Discovery [I-D.cheshire-dnsext-dns-sd] for service
multicast DNS is link-local only. discovery can reduce the number of places that IP addresses need
to be configured. But it should be noted that multicast DNS is
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 they are globally unique to
avoid collision. For enterprise networks, using ULA along with PA avoid collision. For enterprise networks, using ULA along with PA
can provide a logically local routing plane separated from the 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
skipping to change at page 7, line 4 skipping to change at page 7, line 7
provider-independent prefixes, and they are globally unique to provider-independent prefixes, and they are globally unique to
avoid collision. For enterprise networks, using ULA along with PA avoid collision. For enterprise networks, using ULA along with PA
can provide a logically local routing plane separated from the 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 When renumbering, as RFC4192 suggested, it has a period to keep
using the old prefix(es) before the new prefix(es) is(are) stable. using the old prefix(es) before the new prefix(es) is(are) stable.
In the process of adding new prefix(es) and deprecating old In the process of adding new prefix(es) and deprecating old
prefix(es), it is not easy to keep the local communication immune prefix(es), it is not easy to keep the local communication immune
of global routing plane change. If we use ULA for the local of global routing plane change. If we use ULA for the local
communication, the separated local routing plane can isolate the communication, the separated local routing plane can isolate the
affecting by global routing change. affecting by global routing change.
Enterprise administrators may 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
restructure their address allocations, 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 may 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
only used internally (intra-domain), and the addresses used for only used internally (intra-domain), and the addresses used for
multicast sources and Rendezvous-Points need not be reachable nor multicast sources and Rendezvous-Points need not be reachable nor
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
skipping to change at page 7, line 48 skipping to change at page 7, line 50
address assignment: Stateless Address Auto-Configuration (SLAAC, address assignment: Stateless Address Auto-Configuration (SLAAC,
[RFC4862]) by Neighbor Discovery (ND, [RFC4861]) 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 might cause a large number of interactions between hosts
and DHCPv6 server. and DHCPv6 server.
This document has no preference between ND and DHCPv6 address This document has no preference between ND and DHCPv6 address
configuration models. It is network architects' job to decide configuration models. It is network architects' job to decide
which configuration model is employed. But it should be noticed which configuration model is employed. But it should be noticed
that using DHCPv6 and ND together within one network, especially that using DHCPv6 and ND together within one network, especially
in one subnet, may cause operational issues. For example, some in one subnet, might cause operational issues. For example, some
hosts use DHCPv6 as the default configuration model while some use hosts use DHCPv6 as the default configuration model while some use
ND. Then the hosts' address configuration model depends on the ND. Then the hosts' address configuration model depends on the
policies of operating systems and cannot be controlled by the policies of operating systems and cannot be controlled by the
network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses network. Section 5.1 of [I-D.ietf-6renum-gap-analysis] discusses
more details on this topic. So, in general, this document more details on this topic. So, in general, this document
recommends using DHCPv6/SLAAC independently in different subnets. recommends using DHCPv6/SLAAC independently in different subnets.
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 might coexist within
single enterprise network. [I-D.ietf-savi-mix] provides a 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/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.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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
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 may 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.
[RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and [RFC4704] defined a DHCPv6 option to be used by DHCPv6 clients and
servers to exchange information about the client's FQDN and about servers to exchange information about the client's FQDN and about
who has the responsibility for updating the DNS with the who has the responsibility for updating the DNS with the
associated AAAA and PTR RRs. For example, if a client wants the associated AAAA and PTR (Pointer Record) RRs (Resource Records).
server to update the FQDN-address mapping in the DNS server, it
can include the Client FQDN option with proper settings in the For example, if a client wants the server to update the FQDN-
SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message address mapping in the DNS server, it can include the Client FQDN
originated by the client. When DHCPv6 server gets this option, it option with proper settings in the SOLICIT with Rapid Commit,
can use the dynamic DNS update on behalf of the client. In this REQUEST, RENEW, and REBIND message originated by the client. When
document, we promote to support this FQDN option. But since it's a DHCPv6 server gets this option, it can use the dynamic DNS update
DHCPv6 option, it implies that only the DHCP-managed networks are on behalf of the client. In this document, we promote to support
suitable for this operation. In SLAAC mode, sometimes hosts also this FQDN option. But since it's a DHCPv6 option, it implies that
need to register addresses on a registration server, which could only the DHCP-managed networks are suitable for this operation. In
in fact be a DHCPv6 server (as described in SLAAC mode, sometimes hosts also need to register addresses on a
registration server, which could in fact be a DHCPv6 server (as
described in
[I-D.ietf-dhc-addr-registration]); then the server would update [I-D.ietf-dhc-addr-registration]); then the server 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.
skipping to change at page 10, line 10 skipping to change at page 10, line 17
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
might increase the daily traffic, server load, or 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 renumbered soon or very frequently should adopt these recommendations,
recommendations, with balanced consideration between daily cost and 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 may cause issues for renumbering events. Long-lifetime addresses might cause issues for renumbering events.
Particularly, some offline hosts may 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 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.
Recent research [BA2011] [JSBM2002] indicates that it is both
practical and reasonable for A, AAAA, and PTR records that belong
to leaf nodes of the DNS (i.e. not including the DNS root or DNS
top-level domains) to be configured with very short DNS TTL values,
not only during renumbering events, but also for longer-term
operation.
- 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. In ND, The DNS configuration can renumbering events are expected. In ND, The DNS configuration can
be done through reducing the lifetime value in RDNSS option be done through reducing the lifetime value in RDNSS option
[RFC6106]. In DHCPv6, the DNS configuration option specified in [RFC6106]. In DHCPv6, the DNS configuration option specified in
[RFC3646] doesn't provide lifetime attribute, but we can reduce [RFC3646] doesn't provide lifetime attribute, but we can reduce
the DHCPv6 client lease time to achieve similar effect. the DHCPv6 client lease time to achieve similar effect.
skipping to change at page 11, line 47 skipping to change at page 12, line 11
If the network has to enforce renumbering before address leases If the network has to enforce renumbering before address leases
expire, the network should initiate DHCPv6 RECONFIGURE messages. expire, the network should initiate DHCPv6 RECONFIGURE messages.
For some operating systems such as Windows 7, if the hosts receive For some operating systems such as Windows 7, if the hosts receive
RA messages with ManagedFlag=0, they'll release the DHCPv6 RA messages with ManagedFlag=0, they'll release the DHCPv6
addresses and do SLAAC according to the prefix information in the addresses and do SLAAC according to the prefix information in the
RA messages, so this could be another enforcement method for some RA messages, so this could be another enforcement method for some
specific scenarios. specific scenarios.
- Impact to branch/main sites - Impact to branch/main sites
Renumbering in main/branch site may cause impact on branch/main Renumbering in main/branch site might cause impact on branch/main
site communication. The routes, ingress filtering of site's site communication. The routes, ingress filtering of site's
gateways, and DNS may need to be updated. This needs careful gateways, and DNS might need to be updated. This needs careful
planning and organizing. planning and organizing.
- DNS record update and DNS configuration on hosts - DNS record update and DNS configuration on hosts
DNS records on the local DNS server should be updated if hosts are DNS records on the local DNS server should be updated if hosts are
renumbered. If the site depends on ISP's DNS system, it should renumbered. If the site depends on ISP's DNS system, it should
report the new host's DNS records to its ISP. During the report the new host's DNS records to its ISP. During the
transition period, both old and new DNS records are valid. If the transition period, both old and new DNS records are valid. If the
TTLs of DNS records are shorter than the transition period, an TTLs of DNS records are shorter than the transition period, an
administrative operation may not be necessary. administrative operation might not be necessary.
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 might 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.
notification mechanism may be needed to indicate to the hosts that
a renumbering event of local recursive DNS happens or is going to
take place.
- 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. However, configuration of tunnel concentrator was based on FQDN.
even if FQDN is used, some other tunnel-relevant configuration may
still exist, for example IPSec, so fail in renumbering. For IPSec, [RFC2230] defines the KX (Key eXchange) record, which
could be used to help locate the domain-name for an IPsec VPN
concentrator associated with a site's domain name. For current
practice, the community needs to change its bad habit of using
IPsec in an address-oriented way, and renumbering is one of the
main reasons for that.
- 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 can 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.
5. Security Considerations 5. Security Considerations
As noted, a site that is listed by IP address in a black list can As noted, a site that is listed by IP address in a black list can
escape that list by renumbering itself. escape that list by renumbering itself.
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking. Proper network security mechanisms are needed. Although hijacking. Proper network security mechanisms are needed. Although
skipping to change at page 12, line 47 skipping to change at page 13, line 15
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.
5. Security Considerations 5. Security Considerations
As noted, a site that is listed by IP address in a black list can As noted, a site that is listed by IP address in a black list can
escape that list by renumbering itself. escape that list by renumbering itself.
Any automatic renumbering scheme has a potential exposure to Any automatic renumbering scheme has a potential exposure to
hijacking. Proper network security mechanisms are needed. Although hijacking. Proper network security mechanisms are needed. Although
there are existing security mechanisms such as SEND, RA guard, secure there are some existing security mechanisms such as SEND, RA guard,
DHCPv6 etc., they haven't been widely deployed and haven't been secure DHCPv6 etc., they haven't been widely deployed and haven't
verified whether they are suitable for ensuring security while not been verified whether they are not bringing too much operational
bringing too much operational complexity and cost. complexity and cost.
Dynamic DNS update may bring risk of DoS attack to the DNS server. So Dynamic DNS update might bring risk of DoS attack to the DNS server.
along with the update authentication, session filtering/limitation So along with the update authentication, session filtering/limitation
may also be needed. 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 new
prefixes may cause potential risk to the enterprise routing system prefixes might cause potential risk to the enterprise routing
since the old address relevant route path may already invalid and the system since the old address relevant route path might already
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 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
skipping to change at page 14, line 5 skipping to change at page 14, line 20
(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 32 skipping to change at page 15, line 7
[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.
8.2. Informative References 8.2. Informative References
[RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997.
[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.
[RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix
Exclude Option for DHCPv6-based Prefix Delegation", RFC
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", working
in progress, March 2012. 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.
[RFC6603] J. Korhonen, T. Savolainen, S. Krishnan, O. Troan, "Prefix
Exclude Option for DHCPv6-based Prefix Delegation", RFC
6603, May 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 Registration
Solution Using DHCPv6", working in progress, May 2012. 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.
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery",
draft-cheshire-dnsext-dns-sd-11 (work in progress),
December 2011.
[I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS", draft-
cheshire-dnsext-multicastdns-15 (work in progress),
December 2011.
[BA2011] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proc.
14th IEEE Global Internet Symposium (GI2011), Shanghai,
China. 15 April 2011.
[JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris, "DNS
Performance and the Effectiveness of Caching", IEEE/ACM
Transactions on Networking, 10(5):589-603, 2002.
Author's Addresses Author's Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus Q14, Huawei Campus
No.156 Beiqing Rd. No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
P.R. China P.R. China
EMail: jiangsheng@huawei.com EMail: jiangsheng@huawei.com
 End of changes. 48 change blocks. 
95 lines changed or deleted 135 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/