draft-ietf-v6ops-renumbering-procedure-02.txt		draft-ietf-v6ops-renumbering-procedure-03.txt
	IPv6 Operations Working Group F. Baker		IPv6 Operations Working Group F. Baker
	Internet-Draft E. Lear		Internet-Draft E. Lear
	Expires: May 20, 2005 R. Droms		Expires: May 23, 2005 R. Droms
	Cisco Systems		Cisco Systems
	November 19, 2004		November 22, 2004
	Procedures for Renumbering an IPv6 Network without a Flag Day		Procedures for Renumbering an IPv6 Network without a Flag Day
	draft-ietf-v6ops-renumbering-procedure-02		draft-ietf-v6ops-renumbering-procedure-03
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 20, 2005.		This Internet-Draft will expire on May 23, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document describes a procedure that can be used to renumber a		This document describes a procedure that can be used to renumber a
	network from one prefix to another. It uses IPv6's intrinsic ability		network from one prefix to another. It uses IPv6's intrinsic ability
	to assign multiple addresses to a network interface to provide		to assign multiple addresses to a network interface to provide
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11		2.7 Removing the old prefix . . . . . . . . . . . . . . . . . 11
	2.8 Final condition: stable using the new prefix . . . . . . . 12		2.8 Final condition: stable using the new prefix . . . . . . . 12
	3. How to avoid shooting yourself in the foot . . . . . . . . . . 13		3. How to avoid shooting yourself in the foot . . . . . . . . . . 13
	3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13		3.1 "Find all the places..." . . . . . . . . . . . . . . . . . 13
	3.2 Renumbering switch and router interfaces . . . . . . . . . 13		3.2 Renumbering switch and router interfaces . . . . . . . . . 13
	3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14		3.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 14
	4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15		4. Call to Action for the IETF . . . . . . . . . . . . . . . . . 15
	4.1 Dynamic updates to DNS across administrative domains . . . 15		4.1 Dynamic updates to DNS across administrative domains . . . 15
	4.2 Management of the inverse zone . . . . . . . . . . . . . . 15		4.2 Management of the reverse zone . . . . . . . . . . . . . . 15
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19		7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
	7.2 Informative References . . . . . . . . . . . . . . . . . . . 19		7.2 Informative References . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
	skipping to change at page 7, line 44		skipping to change at page 7, line 44
	The suggestions for reducing the delay in the transition to new IPv6		The suggestions for reducing the delay in the transition to new IPv6
	addresses applies when the DNS service can be given prior notice		addresses applies when the DNS service can be given prior notice
	about a renumbering event. However, the DNS service for a host may		about a renumbering event. However, the DNS service for a host may
	be in a different administrative domain than the network to which the		be in a different administrative domain than the network to which the
	host is attached. For example, a device from organization A that		host is attached. For example, a device from organization A that
	roams to a network belonging to organization B, the device's DNS A		roams to a network belonging to organization B, the device's DNS A
	record is still managed by organization A, where the DNS service		record is still managed by organization A, where the DNS service
	won't be given advance notice of a renumbering event in organization		won't be given advance notice of a renumbering event in organization
	B.		B.
	One strategy for updating the DNS is to allow each network device to		One strategy for updating the DNS is to allow each system to manage
	manage its own DNS information through Dynamic DNS (DDNS)		its own DNS information through Dynamic DNS (DDNS)
	[RFC2136][RFC3007]. Authentication of these DDNS updates is strongly		[RFC2136][RFC3007]. Authentication of these DDNS updates is strongly
	recommended, and can be accomplished through the use of either TSIG,		recommended, and can be accomplished through TSIG and SIG(0). Both
	and SIG(0). Both TSIG and SIG(0) require configuration and		TSIG and SIG(0) require configuration and distribution of keys to
	distribution of keys to end hosts and name servers in advance of the		hosts and name servers in advance of the renumbering event.
	renumbering event.
	2.2.2 Mechanisms for address assignment to interfaces		2.2.2 Mechanisms for address assignment to interfaces
	IPv6 addresses may be assigned through SLAC, DHCP, and manual		IPv6 addresses may be assigned through SLAC, DHCP, and manual
	processes. If DHCP is used for IPv6 address assignment, there may be		processes. If DHCP is used for IPv6 address assignment, there may be
	some delay in the assignment of IPv6 addresses from the new prefix		some delay in the assignment of IPv6 addresses from the new prefix
	because hosts using DHCP only contact the server periodically to		because hosts using DHCP only contact the server periodically to
	extend the lifetimes on assigned addresses. This delay can be		extend the lifetimes on assigned addresses. This delay can be
	reduced in two ways:		reduced in two ways:
	o Prior to the renumbering event, the T1 parameter (which controls		o Prior to the renumbering event, the T1 parameter (which controls
	the time at which a host using DHCP contacts the server) may be		the time at which a host using DHCP contacts the server) may be
	reduced.		reduced.
	o The DHCP Reconfigure message may also be sent from the server to		o The DHCP Reconfigure message may also be sent from the server to
	the hosts to trigger the hosts to immediately contact the server.		the hosts to trigger the hosts to contact the server immediately.
	2.3 Configuring switches and routers for the new prefix		2.3 Configuring switches and routers for the new prefix
	In this step, switches and routers and services are prepared for the		In this step, switches and routers and services are prepared for the
	new prefix but the new prefix is not used for any datagram		new prefix but the new prefix is not used for any datagram
	forwarding. Throughout this step, the new prefix is added to the		forwarding. Throughout this step, the new prefix is added to the
	network infrastructure in parallel with (and without interfering		network infrastructure in parallel with (and without interfering
	with) the old prefix. For example, addresses assigned from the new		with) the old prefix. For example, addresses assigned from the new
	prefix are configured in addition to any addresses from the old		prefix are configured in addition to any addresses from the old
	prefix assigned to interfaces on the switches and routers. Changes		prefix assigned to interfaces on the switches and routers. Changes
	skipping to change at page 11, line 45		skipping to change at page 11, line 45
	2.7 Removing the old prefix		2.7 Removing the old prefix
	Once all sessions are deemed to have completed, there will be no		Once all sessions are deemed to have completed, there will be no
	dependence on the old prefix. It may be removed from the		dependence on the old prefix. It may be removed from the
	configuration of the routing system, and from any static		configuration of the routing system, and from any static
	configurations that depend on it. If any configuration has been		configurations that depend on it. If any configuration has been
	created based on DNS information, the configuration should be		created based on DNS information, the configuration should be
	refreshed after the old prefixes have been removed from the DNS.		refreshed after the old prefixes have been removed from the DNS.
	During this phase the old prefix may be reclaimed by the provider or		During this phase the old prefix may be reclaimed by the provider or
	RIR that granted it, and addresses within that prefix are removed		Regional Internet Registry that granted it, and addresses within that
	DNS.		prefix are removed DNS.
	In addition, DNS reverse maps for the old prefix may be removed from		In addition, DNS reverse maps for the old prefix may be removed from
	the primary name server and the zone delegation may be removed from		the primary name server and the zone delegation may be removed from
	the parent zone. Any DNS, DHCP, or SLAC timers that were changed		the parent zone. Any DNS, DHCP, or SLAC timers that were changed
	should be reset to their original values (most notably the DNS		should be reset to their original values (most notably the DNS
	forward map TTL).		forward map TTL).
	2.8 Final condition: stable using the new prefix		2.8 Final condition: stable using the new prefix
	This is equivalent to the first state, but using the new prefix.		This is equivalent to the first state, but using the new prefix.
	skipping to change at page 15, line 22		skipping to change at page 15, line 22
	4.1 Dynamic updates to DNS across administrative domains		4.1 Dynamic updates to DNS across administrative domains
	The configuration files for a DNS server (such as named.conf) will		The configuration files for a DNS server (such as named.conf) will
	contain addresses that must be reconfigured manually during a		contain addresses that must be reconfigured manually during a
	renumbering event. There is currently no easy way to automate the		renumbering event. There is currently no easy way to automate the
	update of these addresses, as the updates require both complex trust		update of these addresses, as the updates require both complex trust
	relationships and automation to verify them. For instance, a reverse		relationships and automation to verify them. For instance, a reverse
	zone is delegated by an upstream ISP, but there is currently no		zone is delegated by an upstream ISP, but there is currently no
	mechanism to note additional delegations.		mechanism to note additional delegations.
	4.2 Management of the inverse zone		4.2 Management of the reverse zone
	In networks where hosts obtain IPv6 addresses through SLAC, updates		In networks where hosts obtain IPv6 addresses through SLAC, updates
	of reverse zone are problematic because of lack of trust relationship		of reverse zone are problematic because of lack of trust relationship
	between administrative domain owning the prefix and the host		between administrative domain owning the prefix and the host
	assigning the low 64 bits using SLAC. For example, suppose a host,		assigning the low 64 bits using SLAC. For example, suppose a host,
	H, from organization A is connected to a network owned by		H, from organization A is connected to a network owned by
	organization B. When H obtains a new address during a renumbering		organization B. When H obtains a new address during a renumbering
	event through SLAC, H will need to update its reverse entry in the		event through SLAC, H will need to update its reverse entry in the
	DNS through a DNS server from B that owns the reverse zone for the		DNS through a DNS server from B that owns the reverse zone for the
	new address. For H to update its reverse entry, the DNS server from		new address. For H to update its reverse entry, the DNS server from
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/