Internet DRAFT - draft-liu-opsarea-ipv6-renumbering-guidelines
draft-liu-opsarea-ipv6-renumbering-guidelines
Network Working Group B. Liu
Internet Draft Huawei Technologies Co., Ltd
Intended status: Informational June 29, 2013
Expires: December 31, 2013
IPv6 Site Renumbering Operational Guidelines
draft-liu-opsarea-ipv6-renumbering-guidelines-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bing Liu Expires December 31, 2013 [Page 1]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
Abstract
This document gives some basic operational guidelines for an IPv6
site renumbering event. This document considers an renumbering event
as several basic operational stages as numbering, adding a new prefix,
and deprecating old prefix(es) and guidelines are given according to
each stage. Besides the general guidelines, this document also gives
some considerations on some specific operations such as ND/DHCPv6
collaboration, DHCPv6 reconfiguration, secure dynamic DNS update and
multicast.
Table of Contents
1. Introduction ................................................. 3
2. Numbering Operations.......................................... 3
2.1. Using FQDN (Fully Qualified Domain Names) ............... 3
2.2. Using ULAs (Unique Local Addresses) ..................... 4
2.3. Leveraging the loopback interface ....................... 4
2.4. Router numbering ........................................ 4
2.5. Static addresses ........................................ 5
3. Adding a new prefix .......................................... 5
4. Deprecating old prefix(es) ................................... 6
4.1. Deprecating SLAAC prefix ................................ 6
4.2. Deprecating DHCPv6 old addresses ........................ 6
5. ND/DHCPv6 Collaboration ...................................... 6
5.1. Host Numbering .......................................... 6
5.1.1. Address Provisioning ............................... 6
5.1.2. Information Provisioning ........................... 7
5.2. Adding a new prefix ..................................... 7
5.3. Deprecating a prefix .................................... 8
6. DHCPv6 reconfiguration ....................................... 8
7. Secure Dynamic DNS Update .................................... 8
8. Other Operational Considerations ............................. 9
9. Security Considerations ...................................... 9
10. IANA Considerations.......................................... 9
11. Acknowledgments ............................................. 9
12. References .................................................. 9
12.1. Normative References ................................... 9
12.2. Informative References ................................ 10
Bing Liu Expires December 31, 2013 [Page 2]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
1. Introduction
For IPv6 renumbering, there have been several works addressing on it.
[RFC4192] describes a procedure that can be used to renumber a
network from one prefix to another smoothly through a "make-before-
break" transition. [RFC5887] makes a comprehensive analysis and
pointed out there are still some work to do in the future. Making
[RFC5887] as a starting point, [RFC6879] illustrates IPv6 enterprise
renumbering scenarios and gives some considerations to ease
renumbering while [I.D-ietf-6renum-gap-analysis](to be a RFC soon)
identifies gaps in the scenarios.
In general, this draft considers the make-before-break approach in
[RFC4192] as a basic method of IPv6 enterprise renumbering. Since
[RFC4192] already includes some basic operational approaches, this
document focusing on operational guidelines which reflex the new
learning from [RFC5887], [RFC6879], and [I.D-ietf-6renum-gap-
analysis].
This document considers a renumbering event as several basic
operational stages which are numbering, adding a new prefix, and
deprecating old prefix(es). Guidelines are given according to each
stage. Besides the general operations, this document also gives some
considerations on specific operations including ND/DHCPv6
collaboration, DHCPv6 reconfiguration, secure dynamic DNS update and
multicast.
2. Numbering Operations
Operations in numbering stage is important for future renumbering,
since it might impact the renumbering operations/mechanisms selection
or even causes some troubles if not operated properly. Generally,
this section complies the considerations in [RFC6879] section 4.1
(considerations and current methods during network design). Some
topics are briefly re-generated from [RFC6879] or other documents to
make this section as stand-alone complete guidelines.
2.1. Using FQDN (Fully Qualified Domain Names)
If a node using FQDN, when renumbering, the address only need to be
updated once in the node and in the correspond DNS record(s), then
every places using the FQDN could learn the new address through DNS
queries. This is a significant benefit for easing renumbering and is
usually very suitable for servers, tunnels etc. However, this good
feature seems not been widely used in real network deployment.
Bing Liu Expires December 31, 2013 [Page 3]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
Since FQDN relies on DNS, the administrators need to know it has all
the limitations of DNS systems.
2.2. Using ULAs (Unique Local Addresses)
For some internal-only nodes, it is practical to number them with
ULAs, then renumbering events caused by external factors (ISP change,
ISP renumbering .etc) could be avoided.
ULAs could also co-exist with PA (Provider Aggregated) GUAs (Global
Unicast Addresses). The benefit is to ensure stable and specific
local communications regardless of any ISP failure.
It should be noticed that, if ULAs are co-exist with PA addresses,
the administrators need to carefully handle the address selection
policies in the nodes to make sure a ULA-ULA address pair, since a
ULA-PA address pair might cause connection failure. This issue could
be silently solved in the future, since the revised address selection
algorithm standard (RFC6724) has enable ULA-ULA pair selection as
default.
Another operational concern is to make sure the ULA correspond DNS
records should not be propagated outside the local recruit DNS
servers.
2.3. Leveraging the loopback interface
Some current routers support defining multiple loopback interfaces
that can be called in other configurations. For example, when
defining a tunnel, it can call the defined loopback interface to use
its address as the local address of the tunnel.
This feature makes renumbering easier by reducing the number of
places where a device's address configuration must be updated.
2.4. Router numbering
[RFC2894] defined standard ICMPv6 messages for router
numbering/renumbering. This is a dedicated protocol, but we are not
aware of it being used in real network deployment. So in real
networks, routers are basically numbered though human intervene.
For routers, an OAM (Operations Administration and Management) plane
is usually needed. The administrators could also leverage ULAs to
number the router loopback interfaces so that the OAM plane is
logically separated from the data forwarding plane so that the OAM
connectivity could be immune of the data plane impact.
Bing Liu Expires December 31, 2013 [Page 4]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
2.5. Static addresses
As analyzed in [RFC6866], Static address configurations might not be
avoided in some situations, for example, the address-based software
licensing.
However, the administrators should note that "static" doesn't
necessarily mean "manual". Manual configurations should be avoided as
much as possible since it would be highly burdensome and error prone
to type/remeber the IPv6 addresses. Administrators should leverage
tools to configure/manage the static addresses.
3. Adding a new prefix
o Add a prefix to the network infrastructure
The operations of adding a new prefix in a network infrastructure has
been well addressed in section 2.3 and 2.4 in [RFC4192]. To briefly
summarize it, there are several main procedures as the following:
- The new prefix is added to the routing infrastructure, firewall
filters, ingress/egress filters, and other forwarding and filtering
functions
- Routes for the new link prefixes may be injected by routing
protocols into the routing subsystem
- The RA (Router Advertisement) messages should not cause hosts to
perform SLAAC on the new link prefixes since the new prefix might has
not been stable
- Once the new prefix in network infrastructure is in place and
tested, then assign the new addresses to the hosts
- The new addresses will not be used until they are inserted into the
DNS
o A temporary multihoming environment
Add a new prefix usually meaning add a new ISP uplink. So when the
new prefix has been added into the network, then it became a
temporary multihoming environment with multiple PA prefixes.
If the ISPs enable ingress filtering at the edge, then the
administrators need to deal with the source address selection and the
exit router selection issues. For the latter, currently there is no
Bing Liu Expires December 31, 2013 [Page 5]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
well-used solution, so the administrator might need to communicate
with the ISP for not filtering the prefixes.
o Making the new prefix higher priority
When the new prefix is stable, the new sessions should always choose
the new address as the source address. This consideration is to avoid
the new sessions might be long enough to exceed the old/new address
overlap period so that the session survivability would be broken. The
probability is especially high at the end of overlap period.
To achieve this effort, the administrators could advertise the old
prefix as deprecated through RA messages for the SLAAC hosts; for
DHCPv6 hosts, the administrators need to deal with the address
selection policy tables in the hosts.
4. Deprecating old prefix(es)
4.1. Deprecating SLAAC prefix
For the SLAAC-configured hosts, the prefix deprecation operation
could be done through standard RA messages. First, the administrators
could make the router to deprecate the prefix, and at the end of the
overlap period, the administrators could advertise the prefix with
very short lifetime so that the old prefix would be invalid soon.
4.2. Deprecating DHCPv6 old addresses
For DHCPv6-configured hosts, the T1 time has to be short enough that
the addresses could expire before they are deprecated. Then the hosts
could get the new addresses through renew hebaviour.
5. ND/DHCPv6 Collaboration
5.1. Host Numbering
IPv6 has overlapped functions between ND and DHCPv6, they fit in
different scenarios. [I-D.liu-bonica-dhcpv6-slaac-problem] identified
some operational problems of the protocol interactions, so the
administrators need careful plan and cooperation of these two
mechanisms.
5.1.1. Address Provisioning
There could be three kind of possible address provisioning models,
which are discussed as the following.
Bing Liu Expires December 31, 2013 [Page 6]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
o SLAAC-only prefix provisioning
It's efficient to run DHCP-PD between routers and DHCPv6 server, and
SLACC on the downlinks. This combination could leverage the
numbering/renumbering operations the maxim automation.
o DHCPv6-only address provisioning
If administrators want a DHCPv6-only managed network, then it is
recommended to turn SLAAC off through A=0 (the Autonomous flag) and
keep RA working with M flag set (the Managed flag). Because as
identified in [I-D.liu-bonica-dhcpv6-slaac-problem], some operation
systems would not initiate DHCPv6 session until they received the M
flag set in RA messages.
o SLAAC/DHCPv6 co-existence prefix/address provisioning
In normal cases, it is recommended to use only one address
provisioning model for a host. But there might be some special
situations in which both the two models are needed simultaneously.
For example, the network need to be multihomed, and one uplink uses
DHCPv6 for management while the other uses SLAAC. Then the SLAAC link
need always keeping the M flag set to make sure all the host would
initiate DHCPv6 sessions beside the SLAAC configuration.
5.1.2. Information Provisioning
- Currently only ND could provide routing information to hosts, RA
should be always on
- Using stateful DHCPv6 for info provisioning as well as addresses
- Using stateless DHCPv6 for info provisioning and SLAAC for
address provisioning
- Using ND for both address and info (currently only support
routing and DNS)
5.2. Adding a new prefix
- The new prefix might use different address provisioning
- For already DHCPv6-configured hosts, it is not applicable to add
another DHCPv6 session parall, DHCPv6's architecture is not well
supporting multiple provisioning domains yet, the administrators
need to avoid this kind of use cases.
Bing Liu Expires December 31, 2013 [Page 7]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
- For already SLAAC-configured hosts, they might ignore the M
transitioning from 0 to 1, so still using SLAAC for adding a new
prefix is better than adding a DHCPv6 address provisioning
5.3. Deprecating a prefix
TBD.
6. DHCPv6 reconfiguration
DHCPv6 reconfiguration is a standard function defined in [RFC3315].
This function is quite practical for bulk renumbering triggered by
the servers. It is very suitable for DHCPv6-only managed networks.
There is no significant additional burden to maintaining the state
required to send Reconfigures to every client. A power outage restart
scenario takes similar burden for the DHCP systems comparing to bulk
reconfiguration. As the authors learned, mainstream commercial DHCP
servers that could handle a typical enterprise power outage restart.
If the administrators want the reconfiguration be effective, they
need to group the DHCP clients based on prefix in the server, so that
the reconfiguration could be triggered by prefix change.
However, the reconfiguration has not been widely used since it has
not been widely supported yet, but as the author investigated, it is
already on some DHCP implementations' feature list in the near future.
So it is foreseeable that DHCPv6 reconfiguration could be a effective
tool for renumbering.
7. Secure Dynamic DNS Update
Using dynamic DNS update could significantly improve the efficiency
and automation of renumbering. DDNS has vital security threats, so in
real deployment, Secure Dynamic DNS Update [RFC3007] is always needed
and already has been widely supported by the major DNS
implementations.
However, normal hosts are not suitable to do the update mainly
because of the complexity of key management issues inherited from
secure DNS mechanisms, so current practices usually assign the DHCP
servers to act as DNS clients to request the DNS server updating
relevant records [RFC4704]. The key management problem is tractable
in the case of updates for a limited number of servers, so Dynamic
DNS updates could serve as a suitable solution for keeping server DNS
records up to date on a typical enterprise network. However, this
solution is not easily applicable to hosts in general.
Bing Liu Expires December 31, 2013 [Page 8]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
To address the larger use case of arbitrary non-server hosts being
renumbered, DHCP servers have to learn the relevant hosts have
changed their addresses and thus trigger the DDNS update. If the
hosts were numbered and also renumbered by DHCP, then it is easy for
the DHCP servers to learn the address changes; but if the hosts were
numbered by SLAAC, then there could be trouble.
The key distribution could be much easier on DHCP servers, but then
stronger security protection between hosts and DHCP servers is needed.
Generally, this could be considered as an operational issue. One
possible way is to put all the regular hosts in their own zone, e.g.
ddns.sample.com. So when a host registers with DHCP, it gets a PTR
record for its IP address, and an A record with its name. For an
instance, there is one node whose name is EXAPLE, so it is registered
automatically by the DHCP server as EXAPLE.ddns.sample.com.
Additionally, DHCP clients can't overwrite existing non-DHCP names in
the DNS, because DHCP servers follow RFC 4703, which prevents this.
So even if the network doesn't use a separate zone, a DHCP server
won't honor a client's update if it presents a un-matching name (e.g.
"www" name).
8. Other Operational Considerations
TBD (if there would be).
9. Security Considerations
TBD.
10. IANA Considerations
This draft does not request any IANA actions.
11. Acknowledgments
Many useful comments and contributions were made by Sheng Jiang,
Brian Carpenter, Ted Lemon, Joel Jaeggli .etc.
This document was prepared using 2-Word-v2.0.template.dot.
12. References
12.1. Normative References
[RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Bing Liu Expires December 31, 2013 [Page 9]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
[RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC
4861,September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
12.2. Informative References
[RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January
1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2267, January 1998.
[RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894,
August 2000.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option",
RFC 4704, October 2006.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses in Enterprise
Networks", RFC 6866, February 2013.
Bing Liu Expires December 31, 2013 [Page 10]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and Methods",
RFC 6879, February 2013.
[I-D.ietf-6man-addr-select-opt]
Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing
Address Selection Policy using DHCPv6", Working in Progress,
April 2013.
[I-D.liu-bonica-dhcpv6-slaac-problem]
Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", Working in Progress,
February 2013.
Bing Liu Expires December 31, 2013 [Page 11]
Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013
Author's Addresses
Bing Liu
Huawei Technologies Co., Ltd
Huawei Building, 156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
Email: leo.liubing@huawei.com