idnits 2.17.1
draft-carpenter-renum-needs-work-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
https://trustee.ietf.org/license-info/)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (January 19, 2010) is 5205 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-05) exists of
draft-bernardos-manet-autoconf-survey-04
== Outdated reference: A later version (-11) exists of
draft-cheshire-dnsext-dns-sd-05
== Outdated reference: A later version (-15) exists of
draft-cheshire-dnsext-multicastdns-08
== Outdated reference: A later version (-05) exists of
draft-dec-dhcpv6-route-option-02
== Outdated reference: A later version (-02) exists of
draft-dickinson-dnsop-nameserver-control-00
== Outdated reference: A later version (-13) exists of
draft-ietf-dhc-subnet-alloc-10
== Outdated reference: A later version (-24) exists of draft-ietf-lisp-05
== Outdated reference: A later version (-09) exists of
draft-ietf-v6ops-ipv6-cpe-router-03
== Outdated reference: A later version (-11) exists of
draft-rja-ilnp-intro-02
== Outdated reference: A later version (-03) exists of
draft-sun-mif-route-config-dhcp6-01
-- Obsolete informational reference (is this intentional?): RFC 2407
(Obsoleted by RFC 4306)
-- Obsolete informational reference (is this intentional?): RFC 2629
(Obsoleted by RFC 7749)
-- Obsolete informational reference (is this intentional?): RFC 3315
(Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 3633
(Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 3736
(Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 3775
(Obsoleted by RFC 6275)
-- Obsolete informational reference (is this intentional?): RFC 4306
(Obsoleted by RFC 5996)
-- Obsolete informational reference (is this intentional?): RFC 4741
(Obsoleted by RFC 6241)
-- Obsolete informational reference (is this intentional?): RFC 4941
(Obsoleted by RFC 8981)
-- Obsolete informational reference (is this intentional?): RFC 4960
(Obsoleted by RFC 9260)
Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IETF Operations Area B. Carpenter
3 Internet-Draft Univ. of Auckland
4 Intended status: Informational R. Atkinson
5 Expires: July 23, 2010 Extreme Networks
6 H. Flinck
7 Nokia Siemens Networks
8 January 19, 2010
10 Renumbering still needs work
11 draft-carpenter-renum-needs-work-05
13 Abstract
15 This document reviews the existing mechanisms for site renumbering
16 for both IPv4 and IPv6, and identifies operational issues with those
17 mechanisms. It also summarises current technical proposals for
18 additional mechanisms. Finally there is a gap analysis identifying
19 possible areas for future work.
21 Status of this Memo
23 This Internet-Draft is submitted to IETF in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
29 Drafts.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/ietf/1id-abstracts.txt.
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html.
42 This Internet-Draft will expire on July 23, 2010.
44 Copyright Notice
46 Copyright (c) 2010 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 2. Existing Host-related Mechanisms . . . . . . . . . . . . . . . 6
63 2.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
64 2.2. IPv6 Stateless Address Auto-configuration . . . . . . . . 7
65 2.3. IPv6 ND Router/Prefix advertisements . . . . . . . . . . . 8
66 2.4. PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
67 2.5. DNS configuration . . . . . . . . . . . . . . . . . . . . 9
68 2.6. Dynamic Service Discovery . . . . . . . . . . . . . . . . 10
69 3. Existing Router-related Mechanisms . . . . . . . . . . . . . . 10
70 3.1. Router renumbering . . . . . . . . . . . . . . . . . . . . 10
71 4. Existing Multi-addressing Mechanism for IPv6 . . . . . . . . . 11
72 5. Operational Issues with Renumbering Today . . . . . . . . . . 11
73 5.1. Host-related issues . . . . . . . . . . . . . . . . . . . 12
74 5.1.1. Network layer issues . . . . . . . . . . . . . . . . . 12
75 5.1.2. Transport layer issues . . . . . . . . . . . . . . . . 14
76 5.1.3. DNS issues . . . . . . . . . . . . . . . . . . . . . . 14
77 5.1.4. Application layer issues . . . . . . . . . . . . . . . 15
78 5.2. Router-related issues . . . . . . . . . . . . . . . . . . 17
79 5.3. Other issues . . . . . . . . . . . . . . . . . . . . . . . 18
80 5.3.1. NAT state issues . . . . . . . . . . . . . . . . . . . 18
81 5.3.2. Mobility issues . . . . . . . . . . . . . . . . . . . 18
82 5.3.3. Multicast issues . . . . . . . . . . . . . . . . . . . 19
83 5.3.4. Management issues . . . . . . . . . . . . . . . . . . 19
84 5.3.5. Security issues . . . . . . . . . . . . . . . . . . . 22
85 6. Proposed Mechanisms . . . . . . . . . . . . . . . . . . . . . 23
86 6.1. SHIM6 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
87 6.2. MANET proposals . . . . . . . . . . . . . . . . . . . . . 23
88 6.3. Other IETF work . . . . . . . . . . . . . . . . . . . . . 24
89 6.4. Other Proposals . . . . . . . . . . . . . . . . . . . . . 24
90 7. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
91 7.1. Host-related gaps . . . . . . . . . . . . . . . . . . . . 24
92 7.2. Router-related gaps . . . . . . . . . . . . . . . . . . . 25
93 7.3. Operational gaps . . . . . . . . . . . . . . . . . . . . . 26
94 7.4. Other gaps . . . . . . . . . . . . . . . . . . . . . . . . 27
95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
98 11. Change log [RFC Editor to remove] . . . . . . . . . . . . . . 28
99 12. Informative References . . . . . . . . . . . . . . . . . . . . 28
100 Appendix A. Embedded IP addresses . . . . . . . . . . . . . . . . 35
101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
103 1. Introduction
105 In early 1996, the IAB published a short RFC entitled "Renumbering
106 Needs Work" [RFC1900], which the reader is urged to review before
107 continuing. Almost ten years later, the IETF published "Procedures
108 for Renumbering an IPv6 Network without a Flag Day" [RFC4192]. A few
109 other RFCs have touched on router or host renumbering: [RFC1916],
110 [RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076].
112 In fact, since 1996, a number of individual mechanisms have become
113 available to simplify some aspects of renumbering. The Dynamic Host
114 Configuration Protocol (DHCP) is available for IPv4 [RFC2131] and
115 IPv6 [RFC3315]. IPv6 includes Stateless Address Autoconfiguration
116 (SLAAC) [RFC4862], and this includes Router Advertisements (RAs) that
117 include options listing the set of active prefixes on a link. The
118 Point-to-Point Protocol (PPP) [RFC1661] also allows for automated
119 address assignment for both versions of IP.
121 Despite these efforts, renumbering, especially for medium to large
122 sites and networks, is widely viewed as an expensive, painful and
123 error-prone process, and is therefore avoided by network managers as
124 much as possible. Some would argue that the very design of IP
125 addressing and routing makes automatic renumbering intrinsically
126 impossible. In fact, managers have an economic incentive to avoid
127 having to renumber, and many have resorted to private addressing and
128 NAT as a result. This has the highly unfortunate consequence that
129 any mechanisms for managing the scaling problems of wide-area (BGP4)
130 routing that require occasional or frequent site renumbering have
131 been consistently dismissed as unacceptable. But none of this means
132 that we can duck the problem, because as explained below, renumbering
133 is sometimes unavoidable. This document aims to explore the issues
134 behind this problem statement, especially with a view to identifying
135 the gaps and known operational issues.
137 It is worth noting that for a very large class of users, renumbering
138 is not in fact a problem of any significance. A domestic or small
139 office user whose device operates purely as a client or peer-to-peer
140 node is in practice renumbered at every restart (even if the address
141 assigned is often the same). A user who roams widely with a laptop
142 or pocket device is also renumbered frequently. Such users are not
143 concerned with the survival of very long term application sessions
144 and are in practice indifferent to renumbering. Thus, this document
145 is mainly concerned with issues affecting medium to large sites.
147 There are numerous reasons why such sites might need to renumber in a
148 planned fashion, including:
150 o Change of service provider, or addition of a new service provider,
151 when provider-independent addressing is not an option.
152 o A service provider itself has to renumber.
153 o Change of site topology (i.e., subnet reorganization).
154 o Merger of two site networks into one, or split of one network into
155 two or more parts.
156 o During IPv6 deployment, change of IPv6 access method (e.g., from
157 tunneled to native).
159 The most demanding case would be unplanned automatic renumbering,
160 presumably initiated by a site border router, for reasons connected
161 with wide-area routing. There is already a degree of automatic
162 renumbering for some hosts, e.g., IPv6 "privacy" addresses [RFC4941].
164 It is certainly to be expected that as the pressure on IPv4 address
165 space intensifies in the next few years, there will be many attempts
166 to consolidate usage of addresses so as to avoid wastage, as part of
167 the "end game" for IPv4, which necessarily requires renumbering of
168 the sites involved. However, strategically, it is more important to
169 implement and deploy techniques for IPv6 renumbering, so that as IPv6
170 becomes universally deployed, renumbering becomes viewed as a
171 relatively routine event. In particular, some mechanisms being
172 considered to allow indefinite scaling of the wide-area routing
173 system might assume site renumbering to be a straightforward matter.
175 There is work in progress that, if successful, would eliminate some
176 of the motivations for renumbering. In particular, some types of
177 solution to the problem of scalable routing for multihomed sites
178 would likely eliminate both multihoming, and switching to another
179 ISP, as reasons for site renumbering.
181 Several proposed identifier/locator split schemes provide good
182 examples, including at least Identifier Locator Network Protocol
183 (ILNP) [I-D.rja-ilnp-intro], Locator/ID Separation Protocol (LISP)
184 [I-D.ietf-lisp], and Six/One [I-D.vogt-rrg-six-one] (in alphabetical
185 order). The recent discussion about IPv6 Network Address Translation
186 (IPv6 NAT) provides a separate example[I-D.mrw-behave-nat66]. While
187 remaining highly contentious, this approach, coupled with unique
188 local addresses or a provider-independent address prefix, would
189 appear to eliminate some reasons for renumbering in IPv6. However,
190 even if successful, such solutions will not eliminate all of the
191 reasons for renumbering. This document does not take any position
192 about development or deployment of protocols or technologies that
193 would make long-term renumbering unnecessary, but rather deals with
194 practical cases where partial or complete renumbering is necessary in
195 today's Internet.
197 IP addresses do not have a built-in lifetime. Even when an address
198 is leased for a finite time by DHCP or SLAAC, or when it is derived
199 from a DNS record with a finite time to live, this information is
200 unavailable to applications once the address has been passed to an
201 upper layer by the socket interface. Thus, a renumbering event is
202 almost certain to be an unpredictable surprise from the point of view
203 of any application software using the address. Many of the issues
204 listed below derive from this fact.
206 2. Existing Host-related Mechanisms
208 2.1. DHCP
210 At high level, DHCP [RFC2131] [RFC3315] offers similar support for
211 renumbering for both versions of IP. A host requests an address when
212 it starts up, the request might be delivered to a local DHCP server
213 or via a relay to a central server, and if all local policy
214 requirements are met, the server will provide an address with an
215 associated lifetime, and various other network-layer parameters (in
216 particular, the subnet mask and the default router address).
218 From an operational viewpoint, the interesting aspect is the local
219 policy. Some sites require pre-registration of MAC addresses as a
220 security measure, while other sites permit any MAC address to obtain
221 an IP address. Similarly, some sites use DHCP to provide the same IP
222 address to a given MAC address each time (this is sometimes called
223 "Static DHCP"), while other sites do not (this is sometimes called
224 "Dynamic DHCP"), and yet other sites use a combination of these two
225 modes where some devices (e.g. servers, VoIP handsets) have a
226 relatively static IP address that is provisioned via DHCP while other
227 devices (e.g. portable computers) have a different IP address each
228 time they connect to the network. As an example, many US and UK
229 universities require MAC address registration of faculty, staff, and
230 student devices (including hand-held computers connected via
231 wireless).
233 These policy choices interact strongly with whether the site has what
234 might be called "strong" or "weak" asset management. At the strong
235 extreme, a site has a complete database of all equipment allowed to
236 be connected, certainly containing the MAC address(es) for each host,
237 as well as other administrative information of various kinds. Such a
238 database can be used to generate configuration files for DHCP, DNS,
239 and any access control mechanisms that might be in use. For example,
240 only certain MAC addresses might be allowed to get an IP address on
241 certain subnets. At the weak extreme, a site has no asset
242 management, any MAC address may get a first-come first-served IP
243 address on any subnet, and there is no network layer access control.
245 The IEEE 802.1X standard [IEEE.802-1X], [IEEE.802-1X-REV] specifies a
246 connection mechanism for wired/wireless Ethernet that is often
247 combined with DHCP and other mechanisms to form, in effect, a network
248 login. Using such a network login, the user of a device newly
249 connecting to the network must provide both identity and
250 authentication before being granted access to the network. As part
251 of this process, the network control point will often configure the
252 point of network connection for that specific user with a range of
253 parameters -- such as Virtual LAN (VLAN), Access Control Lists
254 (ACLs), and Quality-of-Service (QoS) profiles. Other forms of
255 Network Login also exist, often using an initial web page for user
256 identification and authentication. The latter approach is commonly
257 used in hotels or cafes.
259 In principle, a site that uses DHCP can renumber its hosts by
260 reconfiguring DHCP for the new address range. The issues with this
261 are discussed below.
263 2.2. IPv6 Stateless Address Auto-configuration
265 SLAAC, although updated recently [RFC4862], was designed prior to
266 DHCPv6, intended for networks where unattended automatic
267 configuration was preferred. Ignoring the case of an isolated
268 network with no router, which will use link-local addresses
269 indefinitely, SLAAC follows a bootstrap process. Each host first
270 gives itself a link-local address, and then needs to receive a link-
271 local multicast Router Advertisement (RA) [RFC4861] which tells it
272 the routeable subnet prefix and the address(es) of the default
273 router(s). A node may either wait for the next regular RA, or
274 solicit one by sending a link-local multicast Router Solicitation.
275 Knowing the link prefix from the RA, the node may now configure its
276 own address. There are various methods for this, of which the basic
277 one is to construct a unique 64 bit identifier from the interface's
278 MAC address.
280 We will not describe here the IPv6 processes for Duplicate Address
281 Detection (DAD), Neighbor Discovery (ND), and Neighbor Unreachability
282 Discovery (NUD). Suffice it to say that they work, once the initial
283 address assignment based on the RA has taken place.
285 The contents of the RA message are clearly critical to this process
286 and its use during renumbering. An RA can indicate more than one
287 prefix, and more than one router can send RAs on the same link. For
288 each prefix, the RA indicates two lifetimes: "preferred" and "valid".
289 Addresses derived from this prefix must inherit its lifetimes. When
290 the valid lifetime expires, the prefix is dead and the derived
291 address must not be used any more. When the preferred lifetime is
292 expired (or set to zero) the prefix is deprecated, and must not be
293 used for any new sessions. Thus, setting a finite or zero preferred
294 lifetime is SLAAC's warning that renumbering will occur. SLAAC
295 assumes that the new prefix will be advertised in parallel with the
296 deprecated one, so that new sessions will use addresses configured
297 under the new prefix.
299 2.3. IPv6 ND Router/Prefix advertisements
301 With IPv6, a Router Advertisement not only advertises the
302 availability of an upstream router, but also advertises routing
303 prefix(es) valid on that link (subnetwork). Also, the IPv6 RA
304 message contains a flag indicating whether the host should use DHCPv6
305 to configure or not. If that flag indicates the host should use
306 DHCPv6, then the host is not supposed to auto-configure itself as
307 outlined in Section 2.2. However, there are some issues in this
308 area, described in Section 5.1.1.
310 In an environment where a site has more than one upstream link to the
311 outside world, the site might have more than one valid routing
312 prefix. In such cases, typically all valid routing prefixes within a
313 site will have the same prefix length. Also in such cases, it might
314 be desirable for hosts that obtain their addresses using DHCPv6 to
315 learn about the availability of upstream links dynamically, by
316 deducing from periodic IPv6 RA messages which routing prefixes are
317 currently valid. This application seems possible within the IPv6
318 Neighbour Discovery architecture, but does not appear to be clearly
319 specified anywhere. So at present this approach for hosts to learn
320 about availability of new upstream links or loss of prior upstream
321 links is unlikely to work with currently shipping hosts or routers.
323 2.4. PPP
325 The Point-to-Point Protocol [RFC1661] includes support for a Network
326 Control Protocol (NCP) for both IPv4 and IPv6.
328 For IPv4, the NCP is known as IPCP [RFC1332] and allows explicit
329 negotiation of an IP address for each end. PPP endpoints acquire
330 (during IPCP negotiation) both their own address and the address of
331 their peer, which may be assumed to be the default router if no
332 routing protocol is operating. Renumbering events arise when IPCP
333 negotiation is restarted on an existing link, when the PPP connection
334 is terminated and restarted, or when the point-to-point medium is
335 reconnected. Peers may propose either the local or remote address or
336 require the other peer to do so. Negotiation is complete when both
337 peers are in agreement. In practice, if no routing protocol is used,
338 as in a subscriber/provider environment, then the provider proposes
339 both addresses and requires the subscriber either to accept the
340 connection or abort. Effectively, the subscriber device is
341 renumbered each time it connects for a new session.
343 For IPv6, the NCP is IP6CP [RFC5072] and is used to configure an
344 interface identifier for each end, after which link-local addresses
345 may be created in the normal way. In practice, each side can propose
346 its own identifier and renegotiation is only necessary when there is
347 a collision, or when a provider wishes to force a subscriber to use a
348 specific interface identifier. Once link-local addresses are
349 assigned and IP6CP is complete, automatic assignment of global scope
350 addresses is performed by the same methods as with multipoint links,
351 i.e., either SLAAC or DHCPv6. Again, in a subscriber/provider
352 environment, this allows renumbering per PPP session.
354 2.5. DNS configuration
356 A site must provide DNS records for some or all of its hosts, and of
357 course these DNS records must be updated when hosts are renumbered.
358 Most sites will achieve this by maintaining a DNS zone file (or a
359 database from which it can be generated) and loading this file into
360 the site's DNS server(s) whenever it is updated. As a renumbering
361 tool, this is clumsy but effective. Clearly perfect synchronisation
362 between the renumbering of the host and the updating of its A or AAAA
363 record is impossible. An alternative is to use Secure Dynamic DNS
364 Update [RFC3007], in which a host informs its own DNS server when it
365 receives a new address.
367 There are widespread reports that the freely available BIND DNS
368 software (which is what most UNIX hosts use), Microsoft Windows (XP
369 and later), and MacOS X all include support for Secure Dynamic DNS
370 Update. So do many home gateways. Further, there are credible
371 reports that these implementations are interoperable when configured
372 properly ([dnsbook] p. 228 and p. 506).
374 Commonly used commercial DNS and DHCP servers (e.g., Windows Server)
375 often are deployed with Secure Dynamic DNS Update also enabled. In
376 some cases, merely enabling both the DNS server and the DHCP server
377 might enable Secure Dynamic DNS Update as an automatic side-effect
378 ([dnsbook] p. 506). So in some cases, sites might have deployed
379 Secure Dynamic DNS Update already, without realising it. An
380 additional enhancement would be for DHCP clients to implement support
381 for the "Client FQDN" option (Option 81).
383 Since address changes are usually communicated to other sites via the
384 DNS, the latter's security is essential for secure renumbering. The
385 Internet security community believes that the current DNS Security
386 and Secure Dynamic DNS Update specifications are sufficiently secure
387 and has been encouraging DNSsec deployment, [RFC3007], [RFC4033],
388 [RFC4034], [RFC4035].
390 As of this writing there appears to be significantly more momentum
391 towards rapid deployment of DNS Security standards in the global
392 public Internet than previously. Several country-code Top-Level-
393 Domains (ccTLDs) have already deployed signed TLD root zones (e.g.
394 Sweden's .SE). Several other TLDs are working to deploy signed TLD
395 root zones by published near-term deadlines (e.g. .GOV, .MIL). In
396 fact it is reported that .GOV has been signed operationally since
397 early February 2009. It appears likely that the DNS-wide root zone
398 will be signed in the very near future. See, for example,
399 and
400 .
402 2.6. Dynamic Service Discovery
404 The need for hosts to contain pre-configured addresses for servers
405 can be reduced by deploying the Service Location Protocol (SLP). For
406 some common services, such as network printing, SLP can therefore be
407 an important tool for facilitating site renumbering. See [RFC2608],
408 [RFC2610], [RFC3059], [RFC3224], [RFC3421] and [RFC3832].
410 Multicast DNS (mDNS) and DNS Service Discovery are already widely
411 deployed in BSD, Linux, MacOS X, UNIX, and Windows systems, and are
412 also widely used for both link-local name resolution and for DNS-
413 based dynamic service discovery [I-D.cheshire-dnsext-multicastdns],
414 [I-D.cheshire-dnsext-dns-sd]. In many environments, the combination
415 of mDNS and DNS Service Discovery (e.g. using SRV records [RFC3958])
416 can be important tools for reducing dependency on configured
417 addresses.
419 3. Existing Router-related Mechanisms
421 3.1. Router renumbering
423 Although DHCP was originally conceived for host configuration, it can
424 also be used for some aspects of router configuration. The DHCPv6
425 Prefix Delegation options [RFC3633] are intended for this. For
426 example, DHCPv6 can be used by an ISP to delegate or withdraw a
427 prefix for a customer's router, and this can be cascaded throughout a
428 site to achieve router renumbering.
430 An ICMPv6 extension to allow router renumbering for IPv6 is specified
431 in [RFC2894], but there appears to be little experience with it. It
432 is not mentioned as a useful mechanism by [RFC4192].
434 [RFC4191] extends IPv6 router advertisements to convey default router
435 preferences and more-specific routes from routers to hosts. This
436 could be used as an additional tool to convey information during
437 renumbering, but does not appear to be used in practice.
439 [I-D.ietf-v6ops-ipv6-cpe-router] requires that a customer premises
440 router use DHCPv6 to obtain an address prefix from its upstream ISP,
441 as well as using IPv6 RA messages to establish a default IPv6 route
442 (when IPv6 is in use).
444 4. Existing Multi-addressing Mechanism for IPv6
446 IPv6 was designed to support multiple addresses per interface and
447 multiple prefixes per subnet. As described in [RFC4192], this allows
448 for a phased approach to renumbering (adding the new prefix and
449 addresses before removing the old ones).
451 As an additional result of the multi-addressing mechanism, a site
452 might choose to use Unique Local Addressing (ULA) [RFC4193] for all
453 on-site communication, or at least for all communication with on-site
454 servers, while using globally routeable IPv6 addresses for all off-
455 site communications. It would also be possible to use ULAs for all
456 on-site network management purposes, by assigning ULAs to all
457 devices. This would make these on-site activities immune to
458 renumbering of the prefix(es) used for off-site communication.
459 Finally, ULAs can be safely shared with peer sites with which there
460 is a VPN connection, which cannot be done with ambiguous IPv4
461 addresses [RFC1918]; such VPNs would not be affected by renumbering.
463 The IPv6 model also includes "privacy" addresses which are
464 constructed with pseudo-random interface identifiers to conceal
465 actual MAC addresses [RFC4941]. This means that IPv6 stacks and
466 client applications already need to be agile enough to handle
467 frequent IP address changes (e.g. in the privacy address), since in a
468 privacy-sensitive environment the address lifetime likely will be
469 rather short.
471 5. Operational Issues with Renumbering Today
473 For IPv6, a useful description of practical aspects was drafted in
474 [I-D.chown-v6ops-renumber-thinkabout], as a complement to [RFC4192].
475 As indicated there, a primary requirement is to minimize the
476 disruption caused by renumbering. This applies at two levels:
477 disruption to site operations in general, and disruption to
478 individual application sessions in progress at the moment of
479 renumbering. In the IPv6 case, the intrinsic ability to overlap
480 usage of the old and new prefixes greatly mitigates disruption to
481 ongoing sessions, as explained in [RFC4192]. This approach is in
482 practice excluded for IPv4, largely because IPv4 lacks a State-Less
483 Address Auto-Configuration (SLAAC) mechanism.
485 5.1. Host-related issues
487 5.1.1. Network layer issues
489 For IPv4, the vast majority of client systems (PCs, workstations, and
490 hand-held computers) today use DHCP to obtain their addresses and
491 other network layer parameters. DHCP provides for lifetimes after
492 which the address lease expires. So it should be possible to devise
493 an operational procedure in which lease expiry coincides with the
494 moment of renumbering (within some margin of error). In the simplest
495 case, the network administrator just lowers all DHCP address lease
496 lifetimes to a very short value (e.g. a few minutes) far enough
497 before a site-wide change that each node will automatically pick up
498 its new IP address within a few minutes of the renumbering event. In
499 this case it would be the DHCP server itself that automatically
500 accomplishes client renumbering, although this would cause a peak of
501 DHCP traffic and therefore would not be instantaneous. DHCPv6 could
502 accomplish a similar result.
504 The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
505 This is specifically unicast-only; a DHCP client must discard a
506 multicast FORCERENEW. This could nevertheless be used to trigger the
507 renumbering process, with the DHCP server cycling through all its
508 clients issuing a FORCERENEW to each one. DHCPv6 has a similar
509 feature, i.e., a unicast RECONFIGURE message, that can be sent to
510 each host to inform it to check its DHCPv6 server for an update.
511 These two features do not appear to be widely used for bulk
512 renumbering purposes.
514 Procedures for using a DHCP approach to site renumbering will be very
515 different depending whether the site uses strong or weak asset
516 management. With strong asset management, and careful operational
517 planning, the subnet addresses and masks will be updated in the
518 database, and a script will be run to regenerate the DHCP MAC-to-IP
519 address tables and the DNS zone file. DHCP and DNS timers will be
520 set temporarily to small values. The DHCP and DNS servers will be
521 fed the new files, and as soon as the previous DHCP leases and DNS
522 TTLs expire, everything will follow automatically, as far as the host
523 IP layer is concerned. In contrast, with weak asset management, and
524 a casual operational approach, the DHCP table will be reconfigured by
525 hand, the DNS zone file will be edited by hand, and when these
526 configurations are installed, there will be a period of confusion
527 until the old leases and TTLs expire. The DHCP FORCERENEW or
528 RECONFIGURE messages could shorten this confusion to some extent.
530 DHCP, particularly for IPv4, has acquired a very large number of
531 additional capabilities, with approximately 170 options defined at
532 the time of this writing. Although most of these do not carry IP
533 address information, some do (for example, options 68 through 76 all
534 carry various IP addresses). Thus, renumbering mechanisms involving
535 DHCP have to take into account more than the basic DHCP job of
536 leasing an address to each host.
538 SLAAC is much less overloaded with options than DHCP; in fact its
539 only extraneous capability is the ability to convey a DNS server
540 address. Using SLAAC to force all hosts on a site to renumber is
541 therefore less complex than DHCP, and the difference between strong
542 and weak asset management is less marked. The principle of
543 synchronising the SLAAC and DNS updates, and of reducing the SLAAC
544 lease time and DNS TTL, does not change.
546 We should note a currently unresolved ambiguity in the interaction
547 between DHCPv6 and SLAAC from the host's point of view. RA messages
548 include a 'Managed Configuration' flag known as the M bit, which is
549 supposed to indicate that DHCPv6 is in use. However, it is
550 unspecified whether hosts must interpret this flag rigidly (i.e., may
551 or must only start DHCPv6 if it is set, or if no RAs are received) or
552 whether hosts are allowed or are recommended to start DHCPv6 by
553 default. An added complexity is that DHCPv6 has a 'stateless' mode
554 [RFC3736] in which SLAAC is used to obtain an address but DHCPv6 is
555 used to obtain other parameters. Another flag in RA messages, the
556 'Other configuration' or O bit, indicates this.
558 Until this ambiguous behaviour is clearly resolved by the IETF,
559 operational problems are to be expected, since different host
560 operating systems have taken different approaches. This makes it
561 difficult for a site network manager to configure systems in such a
562 way that all hosts boot in a consistent way. Hosts will start SLAAC
563 if so directed by appropriately configured RA messages. However, if
564 one operating system also starts a DHCPv6 client by default, and
565 another one starts it only when it receives the M bit, systematic
566 address management is impeded.
568 Also, it should be noted that on an isolated LAN, neither RA nor
569 DHCPv6 responses will be received, and the host will remain with only
570 its self-assigned link-local address. One could also have a
571 situation where a multihomed network uses SLAAC for one address
572 prefix and DHCPv6 for another, which would clearly create a risk of
573 inconsistent host behavior and operational confusion.
575 Neither the SLAAC approach, nor DHCP without pre-registered MAC
576 addresses, will work reliably in all cases of systems that are
577 assigned fixed IP addresses for practical reasons. Of course, even
578 systems with static addressing can be configured to use DHCP to
579 obtain their IP address(es). Such use of "Static DHCP" usually will
580 ease site renumbering when it does become necessary. However, in
581 other cases, manual or script-driven procedures, likely to be site-
582 specific and definitely prone to human error, are needed. If a site
583 has even one host with a fixed, manually configured address,
584 completely automatic host renumbering is very likely to be
585 impossible.
587 The above assumes the use of typical off-the-shelf hardware and
588 software. There are other environments, often referred to as
589 embedded systems, where DHCP or SLAAC might not be used and even
590 configuration scripts might not be an option; for example, fixed IP
591 addresses might be stored in read-only memory, or even set up using
592 DIP switches. Such systems create special problems that no general-
593 purpose solution is likely to address.
595 5.1.2. Transport layer issues
597 TCP connections and UDP flows are rigidly bound to a given pair of IP
598 addresses. These are included in the checksum calculation and there
599 is no provision at present for the endpoint IP addresses to change.
600 It is therefore fundamentally impossible for the flows to survive a
601 renumbering event at either end. From an operational viewpoint, this
602 means that a site that plans to renumber itself is obliged either to
603 follow the overlapped procedure described in [RFC4192], or to
604 announce a site-wide outage for the renumbering process, during which
605 all user sessions will fail. In the case of IPv4, overlapping of the
606 old and new addresses is unlikely to be an option, and in any case is
607 not commonly supported by software. Therefore, absent enhancements
608 to TCP and UDP to enable dynamic endpoint address changes (for
609 example, [handley]), interruptions to TCP and UDP sessions seem
610 inevitable if renumbering occurs at either session endpoint. The
611 same appears to be true of DCCP [RFC4340].
613 In contrast, SCTP already supports dynamic multi-homing of session
614 end-points, so SCTP sessions ought not be adversely impacted by
615 renumbering the SCTP session end-points [RFC4960], [RFC5061].
617 5.1.3. DNS issues
619 The main issue is whether the site in question has a systematic
620 procedure for updating its DNS configuration. If it does, updating
621 the DNS for a renumbering event is essentially a clerical issue that
622 must be coordinated as part of a complete plan, including both
623 forward and reverse mapping. As mentioned in [RFC4192], the DNS TTL
624 will be manipulated to ensure that stale addresses are not cached.
625 However, if the site uses a weak asset management model in which DNS
626 updates are made manually on demand, there will be a substantial
627 period of confusion and errors will be made.
629 There are anecdotal reports that many small user sites do not even
630 maintain their own DNS configuration, despite running their own web
631 and email servers. They point to their ISP's resolver, request the
632 ISP to install DNS entries for their servers, but operate internally
633 mainly by IP address. Thus, renumbering for such sites will require
634 administrative coordination between the site and its ISP(s), unless
635 the DNS servers in use have Secure Dynamic DNS Update enabled. Some
636 commercial DNS service firms include Secure Dynamic DNS Update as
637 part of their DNS service offering.
639 It should be noted that DNS entries commonly have matching Reverse
640 DNS entries. When a site renumbers, these reverse entries will also
641 need to be updated. Depending on a site's operational arrangements
642 for DNS support, it might or might not be possible to combine forward
643 and reverse DNS updates in a single procedure.
645 5.1.4. Application layer issues
647 Ideally, we would carry out a renumbering analysis for each
648 application protocol. To some extent, this has been done, in
649 [RFC3795]. This found that 34 out of 257 standards-track or
650 experimental application layer RFCs had explicit address
651 dependencies. Although this study was made in the context of IPv4 to
652 IPv6 transition, it is clear that all these protocols might be
653 sensitive to renumbering. However, the situation is worse, in that
654 there is no way to discover by analysing specifications whether an
655 actual implementation is sensitive to renumbering. Indeed, such
656 analysis might be quite impossible in the case of proprietary
657 applications.
659 The sensitivity depends on whether the implementation stores IP
660 addresses in such a way that it might refer back to them later,
661 without allowing for the fact that they might no longer be valid. In
662 general, we can assert that any implementation is at risk from
663 renumbering if it does not check that an address is valid each time
664 it opens a new communications session. This could be done, for
665 example, by knowing and respecting the relevant DNS time-to-live, or
666 by resolving relevant Fully-Qualified Domain Names (FQDNs) again. A
667 common experience is that even when FQDNs are stored in configuration
668 files, they are resolved only once, when the application starts, and
669 they are cached indefinitely thereafter. This is insufficient. Of
670 course, this does not apply to all application software; for example,
671 several well-known web browsers have short default cache lifetimes.
673 There are even more egregious breaches of this principle, for example
674 software license systems that depend on the licensed host computer
675 having a particular IP address. Other examples are the use of
676 literal IP addresses in URLs, HTTP cookies, or application proxy
677 configurations. (Also see Appendix A.)
679 In contrast, there are also many application suites that actively
680 deal with connectivity failures by retrying with alternative
681 addresses or by repeating DNS lookups. This places a considerable
682 burden of complexity on application developers.
684 It should be noted that applications are in effect encouraged to be
685 aware of and to store IP addresses by the very nature of the socket
686 API calls gethostbyname() and getaddrinfo(). It is highly
687 unfortunate that many applications use APIs that require the
688 application to see and use lower layer objects, such as network-layer
689 addresses. However, the BSD Sockets API was designed and deployed
690 before the Domain Name System (DNS) was created, so there were few
691 good options at the time. This issue is made worse by the fact that
692 these functions do not return an address lifetime, so that
693 applications have no way to know when an address is no longer valid.
694 The extension of the same model to cover IPv6 has complicated this
695 problem somewhat. An application using the socket API is obliged to
696 contain explicit logic if it wishes to benefit from the availability
697 of multiple addresses for a given remote host. If a programming
698 model were adopted in which only FQDNs were exposed to applications,
699 and addresses were cached with appropriate lifetimes within the API,
700 most of these problems would disappear. It should be noted that at
701 least the first part of this is already available for some
702 programming environments. A common example is Java, where only FQDNs
703 need to be handled by application code in normal circumstances, and
704 no additional application logic is needed to deal with multiple
705 addresses, which are handled by the run-time system. This is highly
706 beneficial for programmers who are not networking experts, and
707 insulates applications software from many aspects of renumbering. It
708 would be helfpul to have similarly abstract, DNS oriented, Networking
709 APIs openly specified and widely available for C and C++.
711 Some web browsers intentionally violate the DNS TTL with a technique
712 called "DNS Pinning." DNS Pinning limits acceptance of server IP
713 address changes, due to a javascript issue where repeated address
714 changes can be used to induce a browser to scan the inside of a
715 firewalled network and report the results to an outside attacker.
716 Pinning can persist as long as the browser is running, in extreme
717 cases perhaps months at a time. Thus, we can see that security
718 considerations may directly damage the ability of applications to
719 deal with renumbering.
721 Server applications might need to be restarted when the host they
722 contain is renumbered, to ensure that they are listening on a port
723 and socket bound to the new address. In an IPv6 multi-addressed
724 host, server applications need to be able to listen on more than one
725 address simultaneously, in order to cover an overlap during
726 renumbering. Not all server applications are written to do this, and
727 a name-based API as just mentioned would have to provide for this
728 case invisibly to the server code.
730 As noted in Section 2.6, the Service Location Protocol (SLP), and
731 multicast DNS with SRV records for service discovery, have been
732 available for some years. For example, many printers deployed in
733 recent years automatically advertise themselves to potential clients
734 via SLP. Many modern client operating systems automatically
735 participate in SLP without requiring users to enable it. These tools
736 appear not to be widely known, although they can be used to reduce
737 the number of places that IP addresses need to be configured.
739 5.2. Router-related issues
741 [RFC2072] gives a detailed review of the operational realities in
742 1997. A number of the issues discussed in that document were the
743 result of the relatively recent adoption of classless addressing;
744 those issues can be assumed to have vanished by now. Also, DHCP was
745 a relative newcomer at that time, and can now be assumed to be
746 generally available. Above all, the document underlines that
747 systematic planning and administrative preparation is needed, and
748 that all forms of configuration file and script must be reviewed and
749 updated. Clearly this includes filtering and routing rules (e.g.,
750 when peering with BGP, but also with intradomain routing as well).
751 Two particular issues mentioned in [RFC2072] are:
752 o Some routers cache IP addresses in some situations. So routers
753 might need to be restarted as a result of site renumbering.
754 o Addresses might be used by configured tunnels, including VPN
755 tunnels, although at least the Internet Key Exchange (IKE)
756 supports the use of Fully-Qualified Domain Names instead.
758 On the latter point, the capability to use FQDNs as endpoint names in
759 IPsec VPNs is not new and is standard (see [RFC2407] Section 4.6.2.3
760 and [RFC4306] Section 3.5). This capability is present in most IPsec
761 VPN implementations. There does seem to be an "educational" or
762 "awareness" issue that many system/network administrators do not
763 realise that it is there and works well as a way to avoid manual
764 modification during renumbering. (Of course, even in this case, a
765 VPN may need to be reconnected after a renumbering event, but most
766 products appear to handle this automatically.)
768 In IPv6, if a site wanted to be multi-homed using multiple provider-
769 aggregated (PA) routing prefixes with one prefix per upstream
770 provider, then the interior routers would need a mechanism to learn
771 which upstream providers and prefixes were currently reachable (and
772 valid). In this case their Router Advertisement messages could be
773 updated dynamically to only advertise currently valid routing
774 prefixes to hosts. This would be significantly more complicated if
775 the various provider prefixes were of different lengths or if the
776 site had non-uniform subnet prefix lengths.
778 5.3. Other issues
780 5.3.1. NAT state issues
782 When a renumbering event takes place, entries in the state table of
783 any Network Address Translator that happen to contain the affected
784 addresses will become invalid and will eventually time out. Since
785 TCP and UDP sessions are unlikely to survive renumbering anyway, the
786 hosts involved will not be additionally affected. The situation is
787 more complex for multihomed SCTP [I-D.xie-behave-sctp-nat-cons],
788 depending whether a single or multiple NATs are involved.
790 A NAT itself might be renumbered and might need a configuration
791 change during a renumbering event. One of the authors has a NAT-
792 enabled home gateway that obtains its exterior address from the
793 residential Internet service provider by acting as a DHCP Client.
794 That deployment has not suffered operational problems when the ISP
795 uses DHCP to renumber the gateway's exterior IP address. A critical
796 part of that success has been configuring IKE on the home gateway to
797 use a "mailbox name" for the user's identity type (rather than using
798 the exterior IP address of the home gateway) when creating or
799 managing the IP Security Associations.
801 5.3.2. Mobility issues
803 A mobile node using Mobile IP that is not currently in its home
804 network will be adversely affected if either its current care-of
805 address or its home address is renumbered. For IPv6, if the care-of
806 address changes, this will be exactly like moving from one foreign
807 network to another, and Mobile IP will re-bind with its home agent in
808 the normal way. If its home address changes unexpectedly, it can be
809 informed of the new global routing prefix used at the home site
810 through the Mobile Prefix Solicitation and Mobile Prefix
811 Advertisement ICMPv6 messages [RFC3775]. The situation is more
812 tricky if the mobile node is detached at the time of the renumbering
813 event, since it will no longer know a valid subnet anycast address
814 for its home agent, leaving it to deduce a valid address on the basis
815 of DNS information.
817 By contrast to Mobile IPv6, Mobile IPv4 does not support prefix
818 solicitation and prefix advertisement messages, limiting its
819 renumbering capability to well scheduled renumbering events when the
820 mobile node is connected to its home agent and managed by the home
821 network administration. Unexpected home network renumbering events
822 when the mobile node is away from its home network and not connected
823 to the home agent are supported only if a relevant AAA system is able
824 to allocate dynamically a home address and home agent for the mobile
825 node.
827 5.3.3. Multicast issues
829 As discussed in [I-D.chown-v6ops-renumber-thinkabout], IPv6 multicast
830 can be used to help rather than hinder renumbering, for example by
831 using multicast as a discovery protocol (as in IPv6 Neighbor
832 Discovery). On the other hand, the embedding of IPv6 unicast
833 addresses into multicast addresses specified in [RFC3306] and the
834 embedded-RP (Rendezvous Point) in [RFC3956] will cause issues when
835 renumbering.
837 For both IPv4 and IPv6, changing the unicast source address of a
838 multicast sender might also be an issue for receivers, especially for
839 Source-Specific Multicast (SSM). Applications need to learn the new
840 source addresses, and new multicast trees need to be built
842 For IPv4 or IPv6 with Any-Source Multicast (ASM), renumbering can be
843 easy. If sources are renumbered, from the routing perspective things
844 behave just as if there are new sources within the same multicast
845 group. There may be application issues though. Changing the RP
846 address is easy when using Bootstrap Router (BSR) [RFC5059] for
847 dynamic RP discovery. BSR is widely used, but it is also common to
848 use static config of RP addresses on routers. In that case router
849 configurations must be updated too.
851 If any multicast ACLs are configured, they raise the same issue as
852 unicast ACLs mentioned elsewhere.
854 5.3.4. Management issues
856 Today, static IP addresses are routinely embedded in numerous
857 configuration files and network management databases, including MIB
858 modules. Ideally, all these would be generated from a single central
859 asset management database for a given site, but this is far from
860 being universal practice. It should be noted that for IPv6, where
861 multiple routing prefixes per interface and multiple addresses per
862 interface are standard practice, the database and the configuration
863 files will need to allow for this (rather than for a single address
864 per host, as is normal practice for IPv4).
866 Furthermore, because of routing policies and VPNs, a site or network
867 might well embed addresses from other sites or networks in its own
868 configuration data. (It is preferable to embed FQDNs instead, of
869 course, whenever possible.) Thus renumbering will cause a ripple
870 effect of updates for a site and for its neighbours. To the extent
871 that these updates are manual, they will be costly and prone to
872 error. Synchronizing updates between independent sites can cause
873 unpredictable delays. Note that Section 4 suggests that IPv6 ULAs
874 can mitigate this problem, but of course only for VPNs and routes
875 which are suitable for ULAs rather than globally routeable addresses.
876 The majority of external adresses to be configured will not be ULAs.
878 See Appendix A for an extended list of possible static or embedded
879 addresses.
881 Some address configuration data are relatively easy to find (for
882 example, site firewall rules, ACLs in site border routers, and DNS).
883 Others might be widely dispersed and much harder to find (for
884 example, configurations for building routers, printer addresses
885 configured by individual users, and personal firewall
886 configurations). Some of these will inevitably be found only after
887 the renumbering event, when the users concerned encounter a problem.
889 The overlapped model for IPv6 renumbering, with old and new addresses
890 valid simultaneously, means that planned database and configuration
891 file updates will proceed in two stages - add the new information
892 some time before the renumbering event, and remove the old
893 information some time after. All policy rules must be configured to
894 behave correctly during this process (e.g., preferring the new
895 address as soon as possible). Similarly, monitoring tools must be
896 set up to monitor both old and new during the overlap.
898 However, it should be noted that the notion of simultaneously
899 operating multiple prefixes for the same network, although natural
900 for IPv6, is generally not supported by operational tools such as
901 address management software. It also increases the size of IGP
902 routing tables in proportion to the number of prefixes in use. For
903 these reasons, and due to its unfamiliarity to operational staff, the
904 use of multiple prefixes remains rare. Accordingly, the use of ULAs
905 to provide stable on-site addresses even if the off-site prefix
906 changes is also rare.
908 If both IPv4 and IPv6 are renumbered simultaneously in a dual-stack
909 network, additional complications could result, especially with
910 configured IP-in-IP tunnels. This scenario should probably be
911 avoided.
913 Use of FQDNs rather than raw IP addresses wherever possible in
914 configuration files and databases will reduce/mitigate the potential
915 issues arising from such configuration files or management databases
916 when renumbering is required or otherwise occurs. This is advocated
917 in [RFC1958] (point 4.1). Just as we noted in Section 5.1.4 for
918 applications, this is insufficient in itself; some devices such as
919 routers are known to only resolve FQDNs once, at start-up, and to
920 continue using the resulting addresses indefinitely. This may
921 require routers to be rebooted, when they should instead be resolving
922 the FQDN again after a given timeout.
924 By definition there is then at least one place (i.e., the DNS zone
925 file or the database that it is derived from) where address
926 information is nevertheless inevitable.
928 It is also possible that some operators may choose to configure
929 addresses rather than names, precisely to avoid a possible circular
930 dependency and the resulting failure modes. This is arguably even
931 advocated in [RFC1958] (point 3.11).
933 It should be noted that the management and administration issues
934 (i.e., tracking down, recording, and updating all instances where
935 addresses are stored rather than looked up dynamically) form the
936 dominant concern of managers considering the renumbering problem.
937 This has led many sites to continue the pre-CIDR approach of using a
938 provider-independent (PI) prefix. Some sites, including very large
939 corporate networks, combine PI addressing with NAT. Others have
940 adopted private addressing and NAT as a matter of choice rather than
941 obligation. This range of techniques allows for addressing plans
942 that are independent of the ISP(s) in use, and allows a
943 straightforward approach to multihoming. The direct cost of
944 renumbering is perceived to exceed the indirect costs of these
945 alternatives. Additionally, there is a risk element stemming from
946 the complex dependencies of renumbering: it is hard to be fully
947 certain that the renumbering will not cause unforeseen service
948 disruptions, leading to unknown additional costs.
950 A relevant example in a corporate context is VPN configuration data
951 held in every employee laptop, for use while on travel and connecting
952 securely from remote locations. Typically, such VPNs are statically
953 configured using numeric IP addresses for endpoints and even with
954 prefix lists for host routing tables. Use of VPN configurations with
955 FQDNs to name fixed endpoints, such as corporate VPN gateways, and
956 with non-address identity types would enable existing IP Security
957 with IKE to avoid address renumbering issues and work well for highly
958 mobile users. This is all possible today with standard IPsec and
959 standard IKE. It just requires VPN software to be configured with
960 names instead of addresses, and thoughtful network administration.
962 It should be noted that site and network operations managers are
963 often very conservative, and reluctant to change operational
964 procedures that are working reasonably well and are perceived as
965 reasonably secure. They quite logically argue that any change brings
966 with it an intrinsic risk of perturbation and insecurity. Thus, even
967 if procedural changes are recommended that will ultimately reduce the
968 risks and difficulties of renumbering (such as using FQDNs protected
969 by DNSSEC where addresses are used today), these changes might be
970 resisted.
972 5.3.5. Security issues
974 For IPv6, addresses are intended to be protected against forgery
975 during neighbor discovery by SEcure Neighbor Discovery (SEND)
976 [RFC3971]. This appears to be a very useful precaution during
977 dynamic renumbering, to prevent hijacking of the process by an
978 attacker. Any automatic renumbering scheme has a potential exposure
979 to such hijacking at the moment that a new address is announced.
980 However, at present it is unclear whether or when SEND might be
981 widely implemented or widely deployed.
983 Firewall rules will certainly need to be updated, and any other cases
984 where addresses or address prefixes are embedded in security
985 components (access control lists, AAA systems, intrusion detection
986 systems, etc.). If this is not done in advance, legitimate access to
987 resources might be blocked after the renumbering event. If the old
988 rules are not removed promptly, illegitimate access might be possible
989 after the renumbering event. Thus, the security updates will need to
990 be made in two stages (immediately before and immediately after the
991 event).
993 There will be operational and security issues if an X.509v3 PKI
994 Certificate includes a subjectAltName extension that contains an
995 iPAddress [RFC5280], and if the corresponding node then undergoes an
996 IP address change without a concurrent update to the node's PKI
997 Certificate. For these reasons, use of the dNSName rather than the
998 iPAddress is recommended for the subjectAltName extension. Any other
999 use of IP addresses in cryptographic material is likely to be
1000 similarly troublesome.
1002 If a site is for some reason listed by IP address in a white list
1003 (such as a spam white list) this will need to be updated.
1004 Conversely, a site which is listed in a black list can escape that
1005 list by renumbering itself.
1007 The use of IP addresses instead of FQDNs in configurations is
1008 sometimes driven by a perceived security need. Since the name
1009 resolution process has historically lacked authentication,
1010 administrators prefer to use raw IP addresses when the application is
1011 security-sensitive (firewalls and VPN are two typical examples). It
1012 might be possible to solve this issue in the next few years with
1013 DNSsec (see Section 2.5), now that there is strong DNS Security
1014 deployment momentum.
1016 6. Proposed Mechanisms
1018 6.1. SHIM6
1020 SHIM6, proposed as a host-based multihoming mechanism for IPv6, has
1021 the property of dynamically switching the addresses used for
1022 forwarding the actual packet stream while presenting a constant
1023 address as the upper layer identifier for the transport layer
1024 [RFC5533]. At least in principle, this property could be used during
1025 renumbering to alleviate the problem described in Section 5.1.2.
1027 SHIM6 is an example of a class of solutions with this or a similar
1028 property; others are HIP, MOBIKE, Mobile IPv6, SCTP and proposals for
1029 multipath TCP.
1031 6.2. MANET proposals
1033 The IETF working groups dealing with mobile ad-hoc networks have been
1034 working on a number of mechanisms for mobile routers to discover
1035 available border routers dynamically, and for those mobile routers to
1036 be able to communicate that information to hosts connected to those
1037 mobile routers.
1039 Recently, some MANET work has appeared on a "Border Router Discovery
1040 Protocol (BRDP)" that might be useful work towards a more dynamic
1041 mechanism for site interior router renumbering
1042 [I-D.boot-autoconf-brdp].
1044 At present, the IETF AutoConf WG
1045 [] is
1046 working on address auto-configuration mechanisms for MANET networks
1047 that also seem useful for ordinary non-mobile non-MANET networks
1048 [I-D.ietf-autoconf-manetarch]. This work is extensively surveyed in
1049 [I-D.bernardos-manet-autoconf-survey] and
1050 [I-D.bernardos-autoconf-solution-space]. Other work in the same
1051 area, e.g., [I-D.templin-autoconf-dhcp], might also be relevant.
1053 MANETs are of course unusual in that they must be able to reconfigure
1054 themselves at all times and without notice. Hence the type of hidden
1055 static configurations discussed above in Section 5.3.4 are simply
1056 intolerable in MANETs. Thus, it is possible that when a consensus is
1057 reached on autoconfiguration for MANETs, the selected solution(s)
1058 might not be suitable for the more general renumbering problem.
1059 However, it is certainly worthwhile to explore applying techniques
1060 that work for MANETs to conventional networks also.
1062 6.3. Other IETF work
1064 A DHCPv6 extension has been proposed which could convey alternative
1065 routes, in addition to the default router address, to IPv6 hosts
1066 [I-D.dec-dhcpv6-route-option]. Other DHCP options are also on the
1067 table that may offer information about address prefixes and routing
1068 to DHCP or DHCPv6 clients, such as [I-D.ietf-dhc-subnet-alloc] and
1069 [I-D.sun-mif-route-config-dhcp6]. It is conceivable that these might
1070 be extended as a way of informing hosts dynamically of prefix
1071 changes.
1073 In the area of management tools, NETCONF [RFC4741] is suitable for
1074 the configuration of any network element or server, so could in
1075 principle be used to support secure remote address renumbering.
1077 The DNSOP WG has considered a Name Server Control Protocol (NSCP)
1078 based on NETCONF that provides means for consistent DNS management
1079 including potential host renumbering events
1080 [I-D.dickinson-dnsop-nameserver-control].
1082 6.4. Other Proposals
1084 A proposal has been made to include an address lifetime as an
1085 embedded field in IPv6 addresses, with the idea that all prefixes
1086 would automatically expire after a certain period and become
1087 unrouteable [scrocker]. While this might be viewed as provocative,
1088 it would force the issue by making renumbering compulsory.
1090 7. Gaps
1092 This section seeks to identify technology gaps between what is
1093 available from existing open specifications and what appears to be
1094 needed for site renumbering to be tolerable.
1096 7.1. Host-related gaps
1098 It would be beneficial to expose address lifetimes in the socket API,
1099 or any low-level networking API. This would allow applications to
1100 avoid using stale addresses.
1102 The various current discussions of a name-based transport layer or a
1103 name-based network API also have potential to alleviate the
1104 application-layer issues noted in this document. Application
1105 development would be enhanced by the addition of a more abstract
1106 network API that supports the C and C++ programming languages. For
1107 example, it could use FQDNs and Service Names, rather than SockAddr,
1108 IP Address, protocol, and port number. This would be equivalent to
1109 similar interfaces already extant for Java programmers.
1111 Moving to a FQDN-based transport layer might enhance the ability to
1112 migrate the IP addresses of endpoints for TCP/UDP without having to
1113 interrupt a session, or at least in a way that allows a session to
1114 restart gracefully.
1116 Having a single registry per host for all address-based configuration
1117 (/etc/hosts, anyone?), with secure access for site network
1118 management, might be helpful. Ideally, this would be remotely
1119 configurable, for example leveraging the IETF's current work on
1120 networked-device configuration protocols (NetConf). While there are
1121 proprietary versions of this approach, sometimes based on LDAP, a
1122 fully standardized approach seems desirable.
1124 Do we really need more than DHCP or SLAAC for regular hosts? Do we
1125 need an IPv4 equivalent of SLAAC? How can the use of DHCP FORCERENEW
1126 and DHCPv6 RECONFIGURE for bulk renumbering be deployed? FORCERENEW
1127 in particular requires DHCP authentication [RFC3118] to be deployed.
1129 The IETF should resolve the 'IPv6 ND M/O flag debate' once and for
1130 all, with default, mandatory and optional behaviors of hosts being
1131 fully specified.
1133 The host behavior for upstream link learning suggested in Section 2.3
1134 should be documented.
1136 It would be helpful to have multi-path, survivable, extensions for
1137 both UDP and TCP (or institutionalise some aspects of SHIM6).
1139 7.2. Router-related gaps
1141 A non-proprietary secure mechanism to allow all address-based
1142 configuration to be driven by a central repository for site
1143 configuration data. NETCONF might be a good starting point.
1145 A MANET solution that's solid enough to apply to fully operational
1146 small to medium fixed sites for voluntary or involuntary renumbering.
1148 A MANET-style solution that can be applied convincingly to large or
1149 very large sites for voluntary renumbering.
1151 A useful short-term measure would be to ensure that [RFC2894] and
1152 [RFC3633] can be used in practice.
1154 7.3. Operational gaps
1156 Since address changes are usually communicated via the DNS, the
1157 latter's security is essential for secure renumbering. Thus we
1158 should continue existing efforts to deploy DNSSEC globally, including
1159 not only signing the DNS root, DNS TLDs, and subsidiary DNS zones,
1160 but also widely deploying the already available DNSsec-capable DNS
1161 resolvers.
1163 Similarly, we should document and encourage widespread deployment of
1164 Secure Dynamic DNS Update both in DNS servers and also in both client
1165 and server operating systems. This capability is already widely
1166 implemented and widely available, but it is not widely deployed at
1167 present.
1169 Deploy multi-prefix usage of IPv6, including ULAs to provide stable
1170 internal addresses. In particular, address management tools need to
1171 support the multi-prefix model and ULAs.
1173 Ensure that network monitoring systems will function during
1174 renumbering, in particular to confirm that renumbering has completed
1175 successfully or that some traffic is still using the old prefixes.
1177 Document and encourage systematic site databases and secure
1178 configuration protocols for network elements and servers (e.g.,
1179 NETCONF). The database should store all the information about the
1180 network; scripts and tools should derive all configurations from the
1181 database. An example of this approach to simplify renumbering is
1182 given at [dleroy].
1184 Document functional requirements for site renumbering tools or
1185 toolkits.
1187 Document operational procedures useful for site renumbering.
1189 In general, document renumbering instructions as part of every
1190 product manual.
1192 Recommend strongly that all IPv6 deployment plans, for all sizes of
1193 site or network, should include provision for future renumbering.
1194 Renumbering should be planned from day one when the first lines of
1195 the configuration of a network or network service are written. Every
1196 IPv6 operator should expect to have to renumber the network one day
1197 and should plan for this event.
1199 7.4. Other gaps
1201 Define a secure mechanism for announcing changes of site prefix to
1202 other sites (for example, those that configure routers or VPNs to
1203 point to the site in question).
1205 For Mobile IP, define a better mechanism to handle change of home
1206 agent address while mobile is disconnected.
1208 8. Security Considerations
1210 Known current issues are discussed in Section 5.3.5. Security issues
1211 related to SLAAC are discussed in [RFC3756]. DHCP authentication is
1212 defined in [RFC3118].
1214 For future mechanisms to assist and simplify renumbering, care must
1215 be taken to ensure that prefix or address changes (especially changes
1216 coming from another site or via public sources such as the DNS) are
1217 adequately authenticated at all points. Otherwise, misuse of
1218 renumbering mechanisms would become an attractive target for those
1219 wishing to divert traffic or to cause major disruption. As noted in
1220 Section 5.1.4, this may result in defensive techniques such as "DNS
1221 pinning" which create difficulty when renumbering.
1223 Whatever authentication method(s) are adopted, key distribution will
1224 be an important aspect. Most likely, public key cryptography will be
1225 needed to authenticate renumbering announcements passing from one
1226 site to another, since one cannot assume a pre-existing trust
1227 relationship between such sites.
1229 9. IANA Considerations
1231 This document requires no action by the IANA.
1233 10. Acknowledgements
1235 Significant amounts of text have been adapted from
1236 [I-D.chown-v6ops-renumber-thinkabout], which reflects work carried
1237 out during the 6NET project funded by the Information Society
1238 Technologies Programme of the European Commission. The authors of
1239 that draft have agreed to their text being submitted under the IETF's
1240 current copyright provisions. Helpful material about work following
1241 on from 6NET was also provided by Olivier Festor of INRIA.
1243 Useful comments and contributions were made (in alphabetical order)
1244 by Jari Arkko, Fred Baker, Olivier Bonaventure, Teco Boot, Stephane
1245 Bortzmeyer, Dale Carder, Gert Doering, Ralph Droms, Pasi Eronen,
1246 Vijay Gurbani, William Herrin, Cullen Jennings, Eliot Lear, Darrel
1247 Lewis, Masataka Ohta, Dan Romascanu, Dave Thaler, Iljitsch van
1248 Beijnum, Stig Venaas, Nathan Ward, James Woodyatt, and others.
1250 This document was produced using the xml2rfc tool [RFC2629].
1252 11. Change log [RFC Editor to remove]
1254 draft-carpenter-renum-needs-work-00: original version, 2008-10-23
1256 draft-carpenter-renum-needs-work-01: additional text in many places,
1257 started gap analysis, additional author, 2008-12-21
1259 draft-carpenter-renum-needs-work-02: added discussion of 802.1X, SLP,
1260 FORCERENEW, reverse DNS, FQDN-based configuration, DNS pinning, RA
1261 and DHCPv6 route preferences; minor edits, additional references,
1262 2009-02-18
1264 draft-carpenter-renum-needs-work-03: updated following IETF74
1265 feedback, expanded discussion of multicast, more discussion of multi-
1266 prefix issues, 2009-05-07
1268 draft-carpenter-renum-needs-work-04: updated following IETF Last Call
1269 comments, 2009-10-22
1271 draft-carpenter-renum-needs-work-05: updated following IESG comments,
1272 2009-12-19
1274 12. Informative References
1276 [I-D.bernardos-autoconf-solution-space]
1277 Bernardos, C., Calderon, M., and H. Moustafa, "Ad-Hoc IP
1278 Autoconfiguration Solution Space Analysis",
1279 draft-bernardos-autoconf-solution-space-02 (work in
1280 progress), November 2008.
1282 [I-D.bernardos-manet-autoconf-survey]
1283 Bernardos, C., Calderon, M., and H. Moustafa, "Survey of
1284 IP address autoconfiguration mechanisms for MANETs",
1285 draft-bernardos-manet-autoconf-survey-04 (work in
1286 progress), November 2008.
1288 [I-D.boot-autoconf-brdp]
1289 Boot, T. and A. Holtzer, "Border Router Discovery Protocol
1290 (BRDP) based Address Autoconfiguration",
1291 draft-boot-autoconf-brdp-02 (work in progress), July 2009.
1293 [I-D.cheshire-dnsext-dns-sd]
1294 Cheshire, S. and M. Krochmal, "DNS-Based Service
1295 Discovery", draft-cheshire-dnsext-dns-sd-05 (work in
1296 progress), September 2008.
1298 [I-D.cheshire-dnsext-multicastdns]
1299 Cheshire, S. and M. Krochmal, "Multicast DNS",
1300 draft-cheshire-dnsext-multicastdns-08 (work in progress),
1301 September 2009.
1303 [I-D.chown-v6ops-renumber-thinkabout]
1304 Chown, T., "Things to think about when Renumbering an IPv6
1305 network", draft-chown-v6ops-renumber-thinkabout-05 (work
1306 in progress), September 2006.
1308 [I-D.dec-dhcpv6-route-option]
1309 Dec, W. and R. Johnson, "DHCPv6 Route Option",
1310 draft-dec-dhcpv6-route-option-02 (work in progress),
1311 October 2009.
1313 [I-D.dickinson-dnsop-nameserver-control]
1314 Dickinson, J., Morris, S., and R. Arends, "Design for a
1315 Nameserver Control Protocol",
1316 draft-dickinson-dnsop-nameserver-control-00 (work in
1317 progress), October 2008.
1319 [I-D.ietf-autoconf-manetarch]
1320 Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc
1321 Network Architecture", draft-ietf-autoconf-manetarch-07
1322 (work in progress), November 2007.
1324 [I-D.ietf-dhc-subnet-alloc]
1325 Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
1326 "Subnet Allocation Option", draft-ietf-dhc-subnet-alloc-10
1327 (work in progress), November 2009.
1329 [I-D.ietf-lisp]
1330 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
1331 "Locator/ID Separation Protocol (LISP)",
1332 draft-ietf-lisp-05 (work in progress), September 2009.
1334 [I-D.ietf-v6ops-ipv6-cpe-router]
1335 Singh, H., Beebee, W., Donley, C., Stark, B., and O.
1336 Troan, "Basic Requirements for IPv6 Customer Edge
1337 Routers", draft-ietf-v6ops-ipv6-cpe-router-03 (work in
1338 progress), December 2009.
1340 [I-D.mrw-behave-nat66]
1341 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
1342 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in
1343 progress), March 2009.
1345 [I-D.rja-ilnp-intro]
1346 Atkinson, R., "ILNP Concept of Operations",
1347 draft-rja-ilnp-intro-02 (work in progress), December 2008.
1349 [I-D.sun-mif-route-config-dhcp6]
1350 Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option
1351 for Hosts with Multiple Interfaces",
1352 draft-sun-mif-route-config-dhcp6-01 (work in progress),
1353 March 2009.
1355 [I-D.templin-autoconf-dhcp]
1356 Templin, F., "Virtual Enterprise Traversal (VET)",
1357 draft-templin-autoconf-dhcp-38 (work in progress),
1358 April 2009.
1360 [I-D.vogt-rrg-six-one]
1361 Vogt, C., "Six/One: A Solution for Routing and Addressing
1362 in IPv6", draft-vogt-rrg-six-one-02 (work in progress),
1363 October 2009.
1365 [I-D.xie-behave-sctp-nat-cons]
1366 Xie, Q., Stewart, R., Holdrege, M., and M. Tuexen, "SCTP
1367 NAT Traversal Considerations",
1368 draft-xie-behave-sctp-nat-cons-03 (work in progress),
1369 November 2007.
1371 [IEEE.802-1X]
1372 Institute of Electrical and Electronics Engineers, "Port-
1373 Based Network Access Control: IEEE Standard for Local and
1374 Metropolitan Area Networks 802.1X-2004", December 2009.
1376 [IEEE.802-1X-REV]
1377 Institute of Electrical and Electronics Engineers,
1378 "802.1X-REV - Revision of 802.1X-2004 - Port Based Network
1379 Access Control: IEEE Standard for Local and Metropolitan
1380 Area Networks", 2009.
1382 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
1383 (IPCP)", RFC 1332, May 1992.
1385 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
1386 RFC 1661, July 1994.
1388 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
1389 RFC 1900, February 1996.
1391 [RFC1916] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser,
1392 "Enterprise Renumbering: Experience and Information
1393 Solicitation", RFC 1916, February 1996.
1395 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
1396 E. Lear, "Address Allocation for Private Internets",
1397 BCP 5, RFC 1918, February 1996.
1399 [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
1400 RFC 1958, June 1996.
1402 [RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering
1403 Overview: Why would I want it and what is it anyway?",
1404 RFC 2071, January 1997.
1406 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
1407 January 1997.
1409 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
1410 RFC 2131, March 1997.
1412 [RFC2407] Piper, D., "The Internet IP Security Domain of
1413 Interpretation for ISAKMP", RFC 2407, November 1998.
1415 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
1416 "Service Location Protocol, Version 2", RFC 2608,
1417 June 1999.
1419 [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service
1420 Location Protocol", RFC 2610, June 1999.
1422 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
1423 June 1999.
1425 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
1426 IPv6 Address Aggregation and Renumbering", RFC 2874,
1427 July 2000.
1429 [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894,
1430 August 2000.
1432 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
1433 Update", RFC 3007, November 2000.
1435 [RFC3059] Guttman, E., "Attribute List Extension for the Service
1436 Location Protocol", RFC 3059, February 2001.
1438 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
1439 Messages", RFC 3118, June 2001.
1441 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
1442 reconfigure extension", RFC 3203, December 2001.
1444 [RFC3224] Guttman, E., "Vendor Extensions for Service Location
1445 Protocol, Version 2", RFC 3224, January 2002.
1447 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
1448 Multicast Addresses", RFC 3306, August 2002.
1450 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
1451 and M. Carney, "Dynamic Host Configuration Protocol for
1452 IPv6 (DHCPv6)", RFC 3315, July 2003.
1454 [RFC3421] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and
1455 W. Jerome, "Select and Sort Extensions for the Service
1456 Location Protocol (SLP)", RFC 3421, November 2002.
1458 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
1459 Host Configuration Protocol (DHCP) version 6", RFC 3633,
1460 December 2003.
1462 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
1463 (DHCP) Service for IPv6", RFC 3736, April 2004.
1465 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
1466 Discovery (ND) Trust Models and Threats", RFC 3756,
1467 May 2004.
1469 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
1470 in IPv6", RFC 3775, June 2004.
1472 [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in
1473 Currently Deployed IETF Application Area Standards Track
1474 and Experimental Documents", RFC 3795, June 2004.
1476 [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and
1477 W. Jerome, "Remote Service Discovery in the Service
1478 Location Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
1480 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
1481 Point (RP) Address in an IPv6 Multicast Address",
1482 RFC 3956, November 2004.
1484 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
1485 Service Location Using SRV RRs and the Dynamic Delegation
1486 Discovery Service (DDDS)", RFC 3958, January 2005.
1488 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
1489 Neighbor Discovery (SEND)", RFC 3971, March 2005.
1491 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1492 Rose, "DNS Security Introduction and Requirements",
1493 RFC 4033, March 2005.
1495 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1496 Rose, "Resource Records for the DNS Security Extensions",
1497 RFC 4034, March 2005.
1499 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1500 Rose, "Protocol Modifications for the DNS Security
1501 Extensions", RFC 4035, March 2005.
1503 [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
1504 Requirements for Stateless Dynamic Host Configuration
1505 Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
1507 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
1508 More-Specific Routes", RFC 4191, November 2005.
1510 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
1511 Renumbering an IPv6 Network without a Flag Day", RFC 4192,
1512 September 2005.
1514 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
1515 Addresses", RFC 4193, October 2005.
1517 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
1518 RFC 4306, December 2005.
1520 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
1521 Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
1523 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
1524 December 2006.
1526 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
1527 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
1528 September 2007.
1530 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
1531 Address Autoconfiguration", RFC 4862, September 2007.
1533 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
1534 Extensions for Stateless Address Autoconfiguration in
1535 IPv6", RFC 4941, September 2007.
1537 [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
1538 RFC 4960, September 2007.
1540 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
1541 "Bootstrap Router (BSR) Mechanism for Protocol Independent
1542 Multicast (PIM)", RFC 5059, January 2008.
1544 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
1545 Kozuka, "Stream Control Transmission Protocol (SCTP)
1546 Dynamic Address Reconfiguration", RFC 5061,
1547 September 2007.
1549 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
1550 PPP", RFC 5072, September 2007.
1552 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1553 Housley, R., and W. Polk, "Internet X.509 Public Key
1554 Infrastructure Certificate and Certificate Revocation List
1555 (CRL) Profile", RFC 5280, May 2008.
1557 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
1558 Shim Protocol for IPv6", RFC 5533, June 2009.
1560 [dleroy] Leroy, D. and O. Bonaventure, "Preparing network
1561 configurations for IPv6 renumbering", International
1562 Journal of Network Management , 2009, .
1565 [dnsbook] Albitz, P. and C. Liu, "DNS and BIND (5th edition)",
1566 O'Reilly , 2006.
1568 [handley] Handley, M., Wischik, D., and M. Bagnulo, "Multipath
1569 Transport, Resource Pooling, and implications for
1570 Routing", 2008,
1571 .
1573 [scrocker]
1574 Crocker, S., "Renumbering Considered Normal", 2006, .
1578 Appendix A. Embedded IP addresses
1580 This Appendix lists common places where IP addresses might be
1581 embedded. The list was adapted from
1582 [I-D.chown-v6ops-renumber-thinkabout].
1583 Provider based prefix(es)
1584 Names resolved to IP addresses in firewall at startup time
1585 IP addresses in remote firewalls allowing access to remote
1586 services
1587 IP-based authentication in remote systems allowing access to
1588 online bibliographic resources
1589 IP address of both tunnel end points for IPv6 in IPv4 tunnel
1590 Hard-coded IP subnet configuration information
1591 IP addresses for static route targets
1592 Blocked SMTP server IP list (spam sources)
1593 Web .htaccess and remote access controls
1594 Apache .Listen. directive on given IP address
1595 Configured multicast rendezvous point
1596 TCP wrapper files
1597 Samba configuration files
1598 DNS resolv.conf on Unix
1599 Any network traffic monitoring tool
1600 NIS/ypbind via the hosts file
1601 Some interface configurations
1602 Unix portmap security masks
1603 NIS security masks
1604 PIM-SM Rendezvous Point address on multicast routers
1606 Authors' Addresses
1608 Brian Carpenter
1609 Department of Computer Science
1610 University of Auckland
1611 PB 92019
1612 Auckland, 1142
1613 New Zealand
1615 Email: brian.e.carpenter@gmail.com
1616 Randall Atkinson
1617 Extreme Networks
1618 PO Box 14129
1619 Suite 100, 3306 East NC Highway 54
1620 Research Triangle Park, NC 27709
1621 USA
1623 Email: rja@extremenetworks.com
1625 Hannu Flinck
1626 Nokia Siemens Networks
1627 Linnoitustie 6
1628 Espoo, 02600
1629 Finland
1631 Email: hannu.flinck@nsn.com