idnits 2.17.1
draft-chown-v6ops-renumber-thinkabout-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 2052.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2029.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2036.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2042.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 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 (September 18, 2006) is 6430 days in the past. Is
this intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Informational draft:
draft-ietf-v6ops-renumbering-procedure (ref. '1')
** Downref: Normative reference to an Informational RFC: RFC 1916 (ref. '2')
** Downref: Normative reference to an Informational RFC: RFC 2071 (ref. '3')
** Downref: Normative reference to an Informational RFC: RFC 2072 (ref. '4')
** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724)
** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862)
** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861)
-- Obsolete informational reference (is this intentional?): RFC 3177 (ref.
'10') (Obsoleted by RFC 6177)
-- Obsolete informational reference (is this intentional?): RFC 3041 (ref.
'13') (Obsoleted by RFC 4941)
== Outdated reference: A later version (-06) exists of
draft-ietf-nemo-terminology-05
-- Obsolete informational reference (is this intentional?): RFC 2960 (ref.
'15') (Obsoleted by RFC 4960)
== Outdated reference: A later version (-22) exists of
draft-ietf-tsvwg-addip-sctp-15
-- Obsolete informational reference (is this intentional?): RFC 3513 (ref.
'17') (Obsoleted by RFC 4291)
-- Obsolete informational reference (is this intentional?): RFC 3775 (ref.
'18') (Obsoleted by RFC 6275)
== Outdated reference: A later version (-02) exists of
draft-ietf-ipv6-ula-central-01
-- Obsolete informational reference (is this intentional?): RFC 3315 (ref.
'30') (Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 3633 (ref.
'31') (Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 3627 (ref.
'33') (Obsoleted by RFC 6547)
== Outdated reference: A later version (-06) exists of
draft-ietf-v6ops-nap-03
Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group T. Chown
3 Internet-Draft M. Thompson
4 Expires: March 22, 2007 A. Ford
5 S. Venaas
6 University of Southampton, UK
7 September 18, 2006
9 Things to think about when Renumbering an IPv6 network
10 draft-chown-v6ops-renumber-thinkabout-05
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on March 22, 2007.
37 Copyright Notice
39 Copyright (C) The Internet Society (2006).
41 Abstract
43 This memo presents a summary of scenarios, issues for consideration
44 and protocol features for IPv6 network renumbering, i.e. achieving
45 the transition from the use of an existing network prefix to a new
46 prefix in an IPv6 network. Its focus lies not in the procedure for
47 renumbering, but as a set of "things to think about" when undertaking
48 such a renumbering exercise.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
53 1.1. Structure of Document . . . . . . . . . . . . . . . . . . 4
54 1.2. Past IPv4 Renumbering studies in the PIER WG . . . . . . . 4
55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
56 3. Renumbering Event Triggers . . . . . . . . . . . . . . . . . . 5
57 3.1. Change of uplink prefix . . . . . . . . . . . . . . . . . 6
58 3.1.1. Migration to new provider . . . . . . . . . . . . . . 6
59 3.1.2. Dial on Demand . . . . . . . . . . . . . . . . . . . . 6
60 3.1.3. Provider migration and upstream renumbering . . . . . 7
61 3.1.4. IPv6 transition . . . . . . . . . . . . . . . . . . . 7
62 3.2. Change of internal topology . . . . . . . . . . . . . . . 8
63 3.3. Acquisition or merger . . . . . . . . . . . . . . . . . . 8
64 3.4. Network growth . . . . . . . . . . . . . . . . . . . . . . 8
65 3.5. Network mobility . . . . . . . . . . . . . . . . . . . . . 8
66 4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 9
67 4.1. Minimal disruption . . . . . . . . . . . . . . . . . . . . 9
68 4.2. Session survivability . . . . . . . . . . . . . . . . . . 9
69 4.2.1. Short-term session survivability . . . . . . . . . . . 10
70 4.2.2. Medium-term session survivability . . . . . . . . . . 10
71 4.2.3. Long-term session survivability . . . . . . . . . . . 10
72 4.2.4. "Sessions" in non-session based transports . . . . . . 11
73 5. IPv6 Protocol Features and their Effects on Renumbering . . . 11
74 5.1. Multi-addressing . . . . . . . . . . . . . . . . . . . . . 11
75 5.2. Multi-homing techniques . . . . . . . . . . . . . . . . . 12
76 5.2.1. Relevance of multi-homing to renumbering . . . . . . . 12
77 5.2.2. Current situation with IPv6 multi-homing . . . . . . . 13
78 5.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13
79 5.3.1. Visited site renumbers when mobile . . . . . . . . . . 14
80 5.3.2. Home site renumbers when mobile . . . . . . . . . . . 14
81 5.3.3. Home site renumbers when disconnected . . . . . . . . 14
82 5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15
83 5.5. Unique Local Addressing . . . . . . . . . . . . . . . . . 16
84 5.5.1. ULAs, Multicast and Address Selection . . . . . . . . 17
85 5.5.2. ULAs with application-layer gateways . . . . . . . . . 18
86 5.6. Anycast addressing . . . . . . . . . . . . . . . . . . . . 18
87 6. Node Configuration Issues . . . . . . . . . . . . . . . . . . 19
88 6.1. Stateless Address Autoconfiguration . . . . . . . . . . . 19
89 6.1.1. Router Advertisement Lifetimes . . . . . . . . . . . . 20
90 6.1.2. Stateless Configuration with DHCPv6 . . . . . . . . . 20
91 6.1.3. Tokenised Interface Identifiers . . . . . . . . . . . 20
92 6.2. Stateful Configuration with DHCPv6 . . . . . . . . . . . . 21
93 6.2.1. Prefix Delegation . . . . . . . . . . . . . . . . . . 22
94 6.2.2. Source Address Selection Policy distribution . . . . . 22
95 6.3. Router Renumbering . . . . . . . . . . . . . . . . . . . . 22
96 7. Administrative Considerations for Renumbering . . . . . . . . 23
97 7.1. Router Advertisement Lifetimes . . . . . . . . . . . . . . 23
98 7.2. Border filtering . . . . . . . . . . . . . . . . . . . . . 24
99 7.3. Frequency of renumbering episodes . . . . . . . . . . . . 24
100 7.4. Delay-related Considerations . . . . . . . . . . . . . . . 25
101 7.4.1. With or without a flag day . . . . . . . . . . . . . . 25
102 7.4.2. Freshness of service data . . . . . . . . . . . . . . 25
103 7.4.3. Availability of old prefix . . . . . . . . . . . . . . 26
104 7.4.4. Duration of overlap . . . . . . . . . . . . . . . . . 27
105 7.5. Scalability issues . . . . . . . . . . . . . . . . . . . . 27
106 7.5.1. Packet filters, Firewalls and ACLs . . . . . . . . . . 28
107 7.5.2. Monitoring tools . . . . . . . . . . . . . . . . . . . 30
108 7.6. Considerations with a Dual-Stack Network . . . . . . . . . 30
109 7.7. Equipment administrative ownership . . . . . . . . . . . . 31
110 8. Impact of Topology Design on Renumbering . . . . . . . . . . . 31
111 8.1. Merging networks . . . . . . . . . . . . . . . . . . . . . 31
112 8.2. Fixed length subnets . . . . . . . . . . . . . . . . . . . 32
113 8.3. Use 112-bit prefixes for point-to-point links . . . . . . 32
114 8.4. Plan for growth where possible . . . . . . . . . . . . . . 33
115 8.5. IPv6 NAT Avoidance . . . . . . . . . . . . . . . . . . . . 33
116 9. Application and service-oriented Issues . . . . . . . . . . . 34
117 9.1. Shims and sockets . . . . . . . . . . . . . . . . . . . . 34
118 9.2. Explicitly named IP addresses . . . . . . . . . . . . . . 35
119 9.3. API dilemma . . . . . . . . . . . . . . . . . . . . . . . 36
120 9.4. Server Sockets . . . . . . . . . . . . . . . . . . . . . . 37
121 9.5. Sockets surviving invalidity . . . . . . . . . . . . . . . 37
122 9.6. DNS Authority . . . . . . . . . . . . . . . . . . . . . . 38
123 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
124 10.1. IETF Call to Arms . . . . . . . . . . . . . . . . . . . . 38
125 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
126 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39
127 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
128 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
129 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40
130 14.2. Informative References . . . . . . . . . . . . . . . . . . 40
131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
132 Intellectual Property and Copyright Statements . . . . . . . . . . 44
134 1. Introduction
136 This memo presents a summary of scenarios, issues for consideration
137 and protocol features for IPv6 network renumbering, i.e. achieving
138 the transition from the use of an existing network prefix to a new
139 prefix in an IPv6 network. This document does not relate the
140 procedures for IPv6 renumbering; for such a procedure the reader is
141 referred to [1]. The authors plan to use this document, together
142 with ongoing operational experience, to refine [1] where necessary,
143 to promote that guide from Informational to BCP. The focus is on
144 renumbering site networks, though many of the principles apply to
145 renumbering other (ISP) networks.
147 1.1. Structure of Document
149 This document is split into a number of sections that discuss various
150 aspects of network renumbering that should be considered when
151 undertaking such an event. This document begins with a discussion of
152 the various reasons behind renumbering events, and the requirements
153 to ensure the event goes smoothly. The following sections then
154 discuss a selection of factors that can both help and hinder the
155 renumbering procedure, and as such should be taken into account when
156 planning the event. Finally, this document summarises issues with
157 applications and services, and attempts to identify places where IP
158 addresses may be hard-coded and thus require reconfiguration during a
159 renumbering event.
161 1.2. Past IPv4 Renumbering studies in the PIER WG
163 A number of years ago (1996-1997), the Procedures for Internet/
164 Enterprise Renumbering (PIER) WG spent time considering the issues
165 for IPv4 renumbering. The WG produced three RFC documents. In
166 RFC1916 [2], a "call to arms" for input on renumbering techniques was
167 made. RFC2071 [3] documents why IPv4 renumbering is required.
168 Interestingly, many, but not all, of the drivers have changed with
169 respect to IPv6. In RFC2072 [4], a Router Renumbering Guide, some
170 operational procedures are given, much as they are in Baker [1] for
171 IPv6.
173 Reflection on RFC2071 is interesting, witness the quote: "It is also
174 envisioned that Network Address Translation (NAT) devices will be
175 developed to assist in the IPv4 to IPv6 transition, or perhaps
176 supplant the need to renumber the majority of interior networks
177 altogether, but that is beyond the scope of this document." That
178 need however is still very strong, particularly given the lack of
179 Provider Independent (PI) address space in IPv6 (in IPv4, PI address
180 space exists mainly for historical, pre-CIDR reasons).
182 RFC2072 is more interesting in the context of this document. Some is
183 certainly relevant, though much is not, due to the inherent changes
184 in IPv6. For example, there is no CIDR and address aggregation is
185 given as mandate. Also, IPv6 subnets are in effect fixed length
186 (/64), so local administrators do not need to resize subnets to
187 maximise efficient use of address space as they do in IPv4.
189 One core message from RFC2072 that holds true today is that of
190 section 4 where the observation is made that renumbering networks
191 whilst remaining the same hierarchy of subnets (i.e. the cardinality
192 of the set of prefixes to renumber remains constant) is the 'easiest'
193 scenario to renumber; when each "old" prefix can be mapped to a
194 single "new" prefix.
196 A distinction of this work is that, where the PIER working group
197 consider the transition from IPv4 to IPv6 addressing as a renumbering
198 scenario, we strictly consider only the renumbering from IPv6
199 prefixes to other IPv6 prefixes and leave transition to well
200 documented techniques such as those from the PIER working group.
202 2. Terminology
204 The following terminology is used in this document (to be expanded in
205 future revisions):
207 o Site: An organisationally distinct network, ranging from SOHO
208 through to enterprise.
210 o Flag day: A planned service outage.
212 o Node: A device on the network that is being renumbered, or that is
213 involved in communication with the network being renumbered.
215 3. Renumbering Event Triggers
217 This section details typical actions that result in the need for a
218 renumbering event, and thus define the scenarios for renumbering.
220 In many instances, in particular those where no "flag day" is
221 involved, the process of renumbering will inevitably lead to a
222 scenario where hosts are multi-addressed or multi-homed as one phase
223 of the renumbering procedure. The relationship between renumbering
224 and multi-homing is discussed later in this document.
226 In other instances, e.g. a change in the IPv4 address offered by a
227 provider to a site using 6to4 [9], the change offers no overlap in
228 external connectivity or addressing, and thus there is no multi-
229 homing overlap.
231 Triggers may be provider-initiated or customer-initiated.
233 Triggers and scenarios for IPv4 renumbering are discussed in RFC2071,
234 but many of these are no longer relevant, and in IPv6 some new
235 triggers exist, e.g. those related to network mobility or IPv6
236 transition tools.
238 3.1. Change of uplink prefix
240 One of the most common causes for renumbering will be a change in the
241 site's upstream provider. As per RFC3177 [10], the typical
242 allocation for an IPv6 site is a /48 size prefix taken from the
243 globally aggregated address space of the site's provider. With IPv6,
244 sites are highly unlikely to be able to obtain provider independent
245 (PI) address space, as have in some cases been obtained in the past
246 with IPv4. Rather, sites use provider assigned (PA) addressing. As
247 a result, if a site changes provider, it must also change its IPv6 PA
248 prefix.
250 3.1.1. Migration to new provider
252 In the simplest case, the customer is triggering the renumbering by
253 choosing to change the site's upstream provider to a new ISP and thus
254 a new PA IPv6 prefix range. This may simply be in the form of
255 selecting a new commercial provider, although there are several other
256 possible scenarios, such as changing from a dial-up to a broadband
257 connection, or moving from a community wireless connection to a fixed
258 broadband connection.
260 A similar scenario exists when a customer migrates to a different
261 service from the same provider. For example, if a customer changes
262 from a dialup to a broadband connection, they will likely be
263 connecting to a different part of the provider's topology, and
264 therefore receive a different address allocation.
266 3.1.2. Dial on Demand
268 A site may connect intermittently to its upstream provider. In such
269 cases the prefix allocated by the provider may change with each
270 connection, as it often does in the case of single IPv4 address
271 allocations to SOHO customers today. Thus the site may receive a
272 prefix still in its provider PA range, but the prefix may vary with
273 each connection, causing a renumbering event.
275 Dynamically assigned IP addresses are common today with dial-up and
276 ISDN Internet connections, and to a lesser extent some broadband
277 products, particularly cable modems. Usually with dynamically
278 assigned IP addresses on broadband products, the address is only
279 likely to change when the customer reconnects, which could be very
280 infrequently.
282 This case can be mitigated by encouraging ISPs to offer static IPv6
283 prefixes to customers. Where /48 prefixes are provided, a large ISP
284 may be forced to require significantly more than the "default" /32
285 allocation from an RIR to an ISP to be able to service its present
286 and future customer base. With always-on more common in new
287 deployments, provider re-allocation should be less common; however
288 the practice of reallocating IPv4 addresses in SOHO broadband
289 networks is not uncommon in current broadband ISPs.
291 3.1.3. Provider migration and upstream renumbering
293 A site's upstream provider may need to renumber, due for example to a
294 change in its network topology or the need to migrate to a different
295 or additional prefix from its Regional Internet Registry (RIR). This
296 will in turn trigger the renumbering of the end site.
298 Such renumbering events would be expected to be rare, but it should
299 be noted that RIR-assigned IPv6 address space is not owned by an ISP.
301 3.1.4. IPv6 transition
303 During transition to IPv6, there are several scenarios where a site
304 may have to renumber. For example, if the site uses 6to4 for access
305 and its IPv4 address is dynamically assigned, an IPv6 renumbering
306 event will be triggered when the site's IPv4 address changes.
308 Another likely renumbering event would be the change of transition
309 mechanism, such as from 6to4 to a static IPv6-in-IPv4 tunnel, or from
310 any one of those mechanisms to a native IPv6 link. When changing
311 from 6to4 (2002::/16) addresses to native global aggregatable unicast
312 addresses, renumbering would be unavoidable. When migrating from a
313 tunnelled to a native connection, renumbering may not be necessary if
314 the same prefix can be routed natively, however this would be
315 provider-dependent.
317 In addition, there are likely to be many cases of network renumbering
318 occurring when the old 6bone prefix (3FFE::/16) is phased out as per
319 RFC3701 [11], and networks still using it will have to renumber.
321 Finally, there is at least one transition mechanism, ISATAP [12],
322 that uses specially crafted host EUI-64 format addresses. Should a
323 site migrate from ISATAP to use either conventional EUI-64 addressing
324 (via stateless address autoconfiguration or perhaps DHCPv6), then
325 renumbering would be required at least in the host part of addresses.
327 It is also worth noting that nodes that use IPv6 Privacy Extensions
328 [13] will in effect renumber the host part of their address on a
329 frequent basis, in the case of one popular implementation on a daily
330 basis if the node remains on-link on the same network.
332 3.2. Change of internal topology
334 A site may need to renumber all or part of its internal network due
335 to a change of topology, such as creating more or less specific
336 subnets, or acquiring a larger IPv6 address allocation. Motivations
337 for splitting a link into separate subnets may be to meet security
338 demands on a particular link (policy for link-based access control
339 rules), or for link load management by shuffling popular services to
340 more appropriate locations in the local topology. Link-merging may
341 be due to department restructuring within the hosting organisation,
342 for example.
344 3.3. Acquisition or merger
346 Two networks may need to merge to one due to the acquisition or
347 merger of two organisations or companies. Such a reorganisation may
348 require one or more parts of the new network to renumber to the
349 primary PA IPv6 prefix.
351 3.4. Network growth
353 A site that is allocated a /48 prefix may grow to a size where it
354 needs to use a larger prefix for internal networking. Sites in the
355 early stages of IPv6 deployment may only request a /48, even if they
356 are likely to outgrow such a prefix in time. In such a case site-
357 wide renumbering may be required to utilise the new prefix if
358 organisational restructuring also happens due to the growth.
360 3.5. Network mobility
362 This covers various cases of network mobility, where a static or
363 nomadic network may obtain different uplink connectivity over time,
364 and thus be assigned different IPv6 PA prefixes as the topology
365 changes. One example is the "traditional" NEMO network [14], another
366 may be a community wireless network where different sets of nodes
367 gain uplink connectivity - typically to the same provider - at
368 different times.
370 4. Renumbering Requirements
372 In this section we enumerate potential specific goals or requirements
373 for sites or users undergoing an IPv6 renumbering event.
375 4.1. Minimal disruption
377 The renumbering event should cause minimal disruption to the routine
378 operation of the network being renumbered, and the users of that
379 network.
381 Disruption is a difficult term to quantify in a generic way, but it
382 can be expressed by factors such as:
384 o Application sessions being terminated
386 o Security controls (e.g. ACLs) blocking access to legitimate
387 resources
389 o Unreachability of nodes or networks
391 o Name resolution, directory and configuration services providing
392 invalid (out-of-date) address data
394 o Limitation of network management visibility
396 These disruptive elements will be covered in situ as we discuss
397 protocol features and other renumbering considerations later in this
398 memo.
400 4.2. Session survivability
402 The concept of session survivability is catered for by [1] in that
403 new sessions adopt either old or new prefix based on the state of the
404 renumbering process, as discussed in Section 5.1. However, other
405 approaches to renumbering networks may be appropriate in certain
406 deployments, such as where "flag days" are unavoidable, such as where
407 two live prefixes are being "swapped". In these cases, further
408 consideration for existing sessions (their longevity, frequency,
409 independence across interactions, etc.) is required.
411 Some protocols are specifically geared to aid session survivability,
412 e.g. the Stream Control Transmission Protocol (SCTP) [15], and may
413 prove valuable in mission-critical renumbering scenarios, in
414 particular the extension that enables the dynamic addition and
415 removal of IP addresses from an SCTP endpoint association [16].
417 Sessions may be administratively maintained, such as NFS mounts for
418 user filestore, or they may be user-driven, e.g. long-running ssh
419 sessions.
421 In general, it is important to consider how TCP and the applications
422 above it handle the connection failures that may result from a change
423 in address.
425 There are different classes of session duration, as described in the
426 following sections.
428 4.2.1. Short-term session survivability
430 A typical short-term session would involve a request-response
431 protocol, such as HTTP, where a new network connection is initiated
432 per transaction, or at worst for a small transaction set. In such
433 cases the migration to a new network prefix is transparent: the
434 client can use the new prefix in new transactions without
435 consequence. Some applications, however, may be skewed by such a
436 shift in connection source for the same entity 'user', for example
437 applications that use recent connection history as a cue to identity
438 (e.g. POP-before-SMTP as used by many dial-on-demand ISP customers
439 ), or for applications that care
440 about connection statistics (the same user web-browsing "session" may
441 be split into two where a renumbering event occurs in-between client
442 transactions).
444 4.2.2. Medium-term session survivability
446 A medium-term session is typified by an application or service that
447 may persist for perhaps a period of a few minutes up to a period of a
448 day or so. This might involve a TCP-based application that is left
449 running during a working day, such as an interactive shell (SSH) or a
450 large file download.
452 4.2.3. Long-term session survivability
454 Long term sessions may typically run for several days, if not weeks
455 or months. These might typically include TCP-based NFS mounts, or
456 long-running TCP applications. Sessions in this context may also
457 include those applications that, once started, do not re-resolve
458 names and so repeatedly open new connections or send new datagrams to
459 the same (as bound at time of initialisation) address throughout
460 their execution lifetime. Even if at API-level applications do
461 attempt to re-resolve the symbol to which they desire to connect, the
462 behaviour of the resolvers is unclear as to whether mappings are
463 refreshed from the naming service, and as such even if the
464 renumbering site does update its DNS (or NIS, LDAP database etc.),
465 the local result may indeed be cached without any indication passed
466 back up to the application as to how 'old' said binding information
467 is.
469 4.2.4. "Sessions" in non-session based transports
471 UDP transport protocols, such as UDP-based NFS mounts, maintain the
472 status of a 'session' by keeping state at one or both ends of the
473 communication, but without a persistent open socket connection at the
474 network layer. If, due to node renumbering, one endpoint changes
475 address then that state becomes invalid and the 'session'
476 interrupted.
478 Note that some stack implementations do not correctly flag an error
479 to applications that attempt to send packets with an invalidated
480 source address, see section Section 9.5
482 IP addresses are also seen carried in higher-layer protocols, e.g.
483 application sessions, such as with FTP. Any application that makes
484 use of layer-3 address data as a unique end-point identifying token
485 may be disrupted by the address of the node changing to which that
486 token relates. This may not be an issue in cases where the token is
487 treated as abstract (i.e. literally just a token), however where
488 locator semantics are inferred, subsequent attempts to 'resolve' the
489 token to an address endpoint for communication, for example, will
490 fail.
492 5. IPv6 Protocol Features and their Effects on Renumbering
494 IPv6 includes a number of notable features that can help or hinder -
495 and sometimes both - renumbering episodes. This section discusses
496 these features and their associated effects for consideration when
497 undertaking network renumbering, both in terms of how they can be
498 used to ease the process, as well as potential pitfalls that should
499 be considered.
501 5.1. Multi-addressing
503 As per RFC3513 [17], IPv6 hosts may be multi-addressed. This means
504 that multiple unicast addresses can be assigned and active on the
505 same interface. These addresses can have different reachabilities
506 ('scopes' such as link-local or global), different statuses including
507 'preferred' and 'deprecated', and may be ephemeral in nature (such as
508 care-of addresses when attached to a foreign network [18] or IPv6
509 Privacy addresses [13]). RFC3484 address selection semantics [5]
510 determine which of the "MxN" address pairs to use for communication
511 in the general case.
513 During a renumbering episode, the addition of an extra address for an
514 endpoint increases the number of possible source-destination address
515 pairs for communications between nodes to use. The address selection
516 mechanisms specified by RFC3484 are currently at varying stages of
517 implementation in operating systems.
519 RFC3484 also specifies policy hooks to allow administrative override
520 of the default address selection behaviour, for example to
521 specifically prefer a source prefix for use with a set of particular
522 destinations. It is thought that this policy-based address selection
523 may be of benefit in renumbering events, or used in the development
524 of bespoke renumbering tools.
526 Multi-addressing also creates various issues with border filtering,
527 discussed in detail in Section 7.2.
529 5.2. Multi-homing techniques
531 A multi-homed site is a site which has multiple upstream providers.
532 A site may be multi-homed for various reasons, however the most
533 common are to provide redundancy in case of failure, to increase
534 bandwidth, and to provide more varied, optimal routes for certain
535 destinations.
537 In renumbering, multi-homing will either be a temporary state, during
538 the transition, or be a permanent feature of the network
539 configuration, which may be being altered during the renumbering.
541 5.2.1. Relevance of multi-homing to renumbering
543 As discussed in section 2, and in particular section 2.5, of [1],
544 during the 'without a flag day' renumbering procedure there will be a
545 period where both the old and the new prefixes are stable and valid
546 for the network. During such a period, the network may be multi-
547 homed, and as such many of the issues relating to multi-homing in
548 IPv6 are also relevant, albeit in a small capacity, to the
549 renumbering procedure. A stable multi-homed situation must therefore
550 be a requirement for renumbering without a 'flag day'.
552 In such a situation, however, the multi-homed state will not be
553 permanent, and will only exist for the duration for which it is
554 required, i.e. for the period during the renumbering procedure when
555 both prefixes should be valid.
557 Renumbering can also occur, however, in a network that is already
558 multi-homed, for example with redundant links to multiple providers.
559 Such a site may wish to renumber for any of the situations given in
560 the earlier section, as well as renumbering because of changes in the
561 number of upstream providers. If at least one of the upstream links
562 remains unchanged during the renumbering, however, then these links
563 could be used exclusively for that period, alleviating some of the
564 issues with prefix changes. The stable link(s) could therefore be
565 the only prefixes advertised as valid for the 'stable state', with
566 the removal of the old prefix and introduction of the new prefix
567 being separate events.
569 Until the best practice for the multi-homing situation is defined,
570 however, its effect on renumbering is not a focus of this document.
572 5.2.2. Current situation with IPv6 multi-homing
574 Unlike IPv4 multi-homing, where PI address space is relatively easy
575 to obtain and thus a site can broadcast its own routing information,
576 most IPv6 addresses will be PA addresses and thus the site will have
577 no control over routing information. Multi-homing in IPv6 therefore
578 does not necessarily exist in the same way as in IPv4 and the
579 multi6 [38] working group was chartered to try to find a solution.
581 Most IPv6 multi-homing solutions fall into the categories of either
582 being host-centric, where it is the hosts that are multi-addressed,
583 and choose which addresses to use, or site-based, where it is the
584 site exit routers that decide which connections to use. The simplest
585 solutions are extensions of the current multi-addressing techniques,
586 but these suffer from the problem that, at some point, connections
587 using the old addresses will be broken.
589 The more advanced solutions [19], and in particular the solution
590 taken forward into the shim6 [39] working group, examine the
591 potential for splitting the 'identity' and 'location' features of IP,
592 currently both represented by the IP address, and connecting to a
593 host's identity, rather than its address, so that connections can
594 continue unhindered across renumbering events. Such solutions are,
595 however, very much in their infancy and as yet do not provide a
596 stable solution to this problem.
598 Support for the level of multi-homing required during a renumbering
599 exercise is, however, mostly provided by multi-addressing
600 (Section 5.1), since all that is primarily required is stable use of
601 either prefix for a given period. The core issue remains, however,
602 that at some point the connections using the old address will be
603 broken when the addresses are removed. The impact of this can be
604 limited as best as possible during the renumbering procedure.
606 5.3. Mobile IPv6
608 Mobile IPv6 (MIPv6) [18] specifies routing support to permit an IPv6
609 host to continue using its "permanent" home address as it moves
610 around the Internet. Mobile IPv6 supports transparency above the IP
611 layer, including maintenance of active TCP connections and UDP port
612 bindings. There are a number of issues to take into account when
613 renumbering episodes occur where Mobile IPv6 is deployed:
615 Renumbering a network which has mobile IPv6 active is a potentially
616 complex issue to think about. In particular, can changed router
617 advertisements correctly reach the mobile nodes, and can they be
618 correctly renumbered, like a node on the local network? In addition,
619 an even more complex issue is what happens when the home agent
620 renumbers? Is it possible for the mobile nodes to be informed and
621 correctly renumber and continue, or will the link be irretrievably
622 broken?
624 5.3.1. Visited site renumbers when mobile
626 When a node is mobile and attached to a foreign network it, like any
627 other node on the link, is subject to prefix renumbering at that
628 site. Detecting a new prefix through the receipt of router
629 advertisements, the mobile node can then re-bind with its home agent
630 informing it of its care-of address - just as if it had detached from
631 the foreign network and migrated elsewhere. Where the node receives
632 forewarning of the renumbering episode, the Mobility specification
633 suggests that the node explicitly solicits an update of the prefix
634 information on its home network
636 5.3.2. Home site renumbers when mobile
638 When mobile, a host can still be contacted at its original (home)
639 address. Should the home network renumber whilst the node is away
640 but active (i.e. having bound to the home agent and registered a live
641 care-of address), then it can be informed of the new global routing
642 prefix used at the home site through the Mobile Prefix Solicitation
643 and Mobile Prefix Advertisement ICMPv6 messages (sections 6.7 and 6.8
644 of RFC3775 [18] respectively).
646 5.3.3. Home site renumbers when disconnected
648 Finally, if a mobile node is detached (i.e. no binding with the home
649 agent exists with the node present on a foreign network) and the home
650 network renumbers, the recommended procedure - documented as an
651 appendix to the mobility specification and therefore not necessarily
652 proven - is to fall back to alternative methods of 'rediscovering'
653 its home network, using the DNS to find the new global routing prefix
654 for the home network and therefore the Home Agent's subnet anycast
655 address, 'guessing' at what the node's new home address would be on
656 the basis of a 64 bit prefix and 64 bit interface identifier, and
657 then attempting to perform registration to bind its new location.
659 5.4. Multicast
661 IPv6 supports an enriched model of multicast compared to IPv4 in that
662 there are well-defined scopes for multicast communication that are
663 readily expressed in the protocol's addressing architecture.
664 Multicast features much more prominently in the core specification,
665 for example it is the enabling technology for the Neighbour Discovery
666 protocol (a much more efficient approach to layer 2 address discovery
667 than compared to ARP with IPv4).
669 Where multicast is used to discover the availability of core services
670 (e.g. all DHCPv6 servers in a site will join FF05::1:3), the effect
671 of renumbering the unicast address of those services will mean that
672 the services are still readily discoverable without resorting to a
673 (bespoke or otherwise) service location protocol to continue to
674 function - particularly if (unicast) ULAs are not deployed locally as
675 per Section 5.5.
677 One issue related to IPv6 multicast and renumbering is the embedding
678 of unicast addresses into multicast addresses specified in RFC3306
679 [20] and the embedded-RP (Rendezvous Point) in RFC3956 [21].
681 The former is purely a way of assigning addresses that helps with
682 multicast address assignment, avoiding different sites from using the
683 same multicast addresses. If a site's unicast prefix changes, then
684 one will also need to change the multicast addresses. By way of
685 example, a site renumbering away from prefix 2001:DB8:BEEF::/48"
686 might have globally-scoped multicast addresses in use under the
687 prefix "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old
688 addresses for a while, but this should be avoided since another site
689 may inherit the prefix and they may end up using the same multicast
690 addresses.
692 The issue with embedded-RP is that, by definition, the RP address is
693 embedded. So if the RP address changes, then the group addresses
694 must also be changed. This may happen not only when a site is
695 renumbered, but also if a site is restructured or the RP is moved
696 within the site. The embedded address is used by routers to
697 determine the RP address. Applications must use new group addresses
698 once the RP is not available on the old address.
700 Another interesting topic is multicast source renumbering. With
701 traditional multicast a source should be able to start streaming from
702 a new address, and nodes belonging to the multicast group will
703 immediately start receiving. There might be some application issues
704 though. If sources are identified by the source address only, then
705 this might appear as a new source to the receivers (as they would
706 where IPv6 Privacy addresses are used). Using RTP a receiver may
707 determine it's the same source.
709 With Source Specific Multicast (SSM), source renumbering is more
710 complicated since receivers must specify exactly which sources they
711 want to to receive from. This means that receivers must somehow be
712 told to join the new source addresses, and must be able to discover
713 those addresses.
715 5.5. Unique Local Addressing
717 Section 5 of [22] suggests that the use of Local IPv6 addresses in a
718 site results in making communication using these addresses
719 independent of renumbering a site's provider based global addresses.
720 It also points out that a renumbering episode is not triggered when
721 merging multiple sites that have deployed centrally assigned unique
722 local addresses[23] because the FC00::/7 ULA prefix assures global
723 uniqueness. The use of ULAs internally should ideally mitigate
724 against global address renumbering of nodes, particularly as intra-
725 site communication can continue unhindered by the change in global
726 address prefixes due to provider migration or re-assignment of prefix
727 from an upstream.
729 ULAs appear to lend themselves particularly well for long-lived
730 sessions (from the categorisation Section 4.2.3) whose nature is
731 intra-site, for example local filestore mounts over TCP-mounted NFS:
732 With clients using ULA source addresses to mount filestore using the
733 ULA of an NFS server, both client and server can have their global
734 routing prefix renumbered without consequence to ongoing local
735 connections.
737 When merging two sites that have both deployed FC00::/7 locally-
738 assigned ULA prefixes, the chance of collision is inherently small
739 given the pseudo-random global-ID determination algorithm of [22].
740 Consideration of possible collisions may be prudent however unlikely
741 the occurrence may be.
743 With reference to section 2 of [1], the adoption of ULA to assist in
744 network renumbering can be considered a 'seasoning' of Baker's
745 renumbering procedure: where interaction between local nodes and
746 their services cannot suffer the inherent issues observed when
747 migrating to a new aggregatable global unicast prefix, the use of
748 FC00::/7 unique local addresses may offer an appropriately stable and
749 reliable solution. Whilst on the surface, the use of ULAs in
750 networks that also have global connectivity appears straightforward
751 and of immediate benefit as regards provider migration, they
752 currently suffer significant operational issues including address
753 selection, border filtering, name service provision and routing.
755 If addresses under a global routing prefix are deployed alongside
756 ULAs, then nodes will need to cater for being multi-addressed with
757 multiple addresses of the same (global) syntactic scope, e.g. follow
758 the principles laid out in RFC3484 [5]. The administrator should
759 ideally be able to set local policy such that nodes use ULAs for
760 intranet communications and global addresses for global Internet
761 communications. Note in particular that address selection policy
762 different from the defaults of RFC3484 are required for sites that
763 have deployed ULAs whilst making use of multicast in scopes greater
764 than link-scope (i.e. FFx3 and higher).
766 5.5.1. ULAs, Multicast and Address Selection
768 For ordinary unicast traffic, the address selection rules of RFC3484
769 will function correctly. Assuming no higher-precedence rules are
770 matched, a multi-addressed host will choose its source address
771 through finding the address with the longest matching prefix compared
772 with the destination address. This will pick global unicast
773 addresses (i.e. within 2000::/3) for communication with other such
774 addresses, and pick ULAs for other ULAs. This correct behaviour is
775 dependent on sites running two-face DNS, however, and therefore
776 ensuring remote sites do not know of non-routable ULAs.
778 The key problem with ULAs and source address selection occurs,
779 however, when sending to multicast addresses. When it falls to the
780 longest matching prefix tests, a ULA will always come out as
781 preferable to a global unicast address for matching a multicast
782 (FF00::/8) address.
784 This does not affect link-local multicast, however, as the preference
785 for the appropriate scope will choose the unicast link-local address
786 before looking at the longest prefix match (see Section 3.1 of
787 RFC3484). For scopes wider than link-local, however, the ULA will by
788 default always be chosen.
790 Local policy needs to be implemented such that, e.g., global-scope
791 multicast addresses have the same `label' as global aggregatable
792 unicast addresses in RFC3484 parlance. Additional rules could also
793 be added such that site- and organisational-scope multicast addresses
794 prefer ULAs as source addresses, again by defining an appropriate
795 label.
797 Whilst no standard policy distribution mechanism exists for
798 overriding default RFC3484 preference rules, [24] proposes the use of
799 a DHCPv6 option in sites where stateful configuration is available.
801 5.5.2. ULAs with application-layer gateways
803 The use of ULAs may not necessarily be accompanied by provider-
804 assigned (PA) addresses in connected networks. If addresses under a
805 PA global routing prefix are not used, application layer gateway
806 deployment will be required for ULA-only nodes internal to the
807 network to communicate with external nodes that are not part of the
808 same ULA topology.
810 Destination nodes that are addressed under FC00::/7 which are not
811 part of the same administrative domain from which the ULA allocation
812 of the local node is made, nor part of a predetermined routing
813 agreement between two organisations utilising different ULAs for
814 nodes within their own sites, would be filtered at the site border as
815 usual.
817 Typical deployments utilising this technique would include those
818 networks where an administrative policy decision has been made to
819 restrict those services available to the users, or where connectivity
820 is sufficeintly intermittent that as few nodes as possible are
821 exposed to the issues of ephemeral connectivity.
823 5.6. Anycast addressing
825 Syntactically indistinguishable from unicast addresses, 'anycast'
826 offers nodes a mean to route traffic toward the topologically nearest
827 instance of a service (as represented by an IP address), relying on
828 the routing infrastructure to deliver appropriately. RFC2526 [25]
829 defines a set of reserved subnet anycast addresses within the highest
830 128 values of the 64 bit IID space. Of that space, currently only
831 three are used, of which one is actively used and is for discovery of
832 Mobile IPv6 Home-Agents. At the current time there are no 'global'
833 well-known anycast addresses assigned by IANA.
835 In order to participate using anycast, nodes need to be configured as
836 routers (to comply with RFC3513 [17]) and exchange routing
837 information about the reachability of the specific anycast address.
838 This extra level of administration requirement is negligible in the
839 context of services as the services themselves would need
840 configuration anyway.
842 There have been proposals to define globally well-known anycast
843 addresses for core services, such as the DNS [26]. Anycast scales
844 with regard subnet-anycast in the sense that the global routing
845 prefix used to direct packets to an anycast node within a site is no
846 different from any other host, and therefore nothing 'special' in the
847 global routing architecture is required - only locally within the
848 site does the multi-node nature of anycast need to be considered.
850 However, for global well-known anycast addresses to be defined, host-
851 specific routes will need to be advertised and distributed throughout
852 the entire Internet. As acknowledged by section 2.6 of [17], this
853 presents a severe scaling limit and it is expected that support for
854 global anycast sets may be unavailable or very restricted. A good
855 discussion of best current practice for service provision using
856 anycast addressing can be found in [27].
858 The use of well-known anycast addresses would assist the renumbering
859 exercise by removing the requirement to change the addresses in the
860 configuration of such services. The use of anycast DNS would
861 alleviate concerns with ensuring node reconfiguration, for example
862 when using Stateless DHCPv6 (Section 6.1.2). While anycasting
863 datagram-based services such as DNS pose little problems, anycast
864 does not maintain state, and so it would not be guaranteed that
865 sequential TCP packets were to go to the same host. As discussed in
866 [28], responses from TCP sessions begun to an anycast address should
867 be sent from the unicast address, and future communication should
868 continue with this address. While this means that communication will
869 continue with the same unicast address, that address is subject to
870 the standard address deprecation and validity. Note that anycasting
871 of this form can be an alternative to site or organisational scope
872 multicast service discovery as described in Section 5.4.
874 6. Node Configuration Issues
876 This section discusses how IPv6 node configuration protocols (both
877 stateless and stateful, including DHCPv6, as well as ICMP router
878 renumbering messages) can be used to facilitate a renumbering event,
879 plus any complications caused by these processes, to which
880 consideration should be given.
882 6.1. Stateless Address Autoconfiguration
884 Many IPv6 networks are likely to be configured using Stateless
885 Address AutoConfiguration [6] (SLAAC), and in order to work through
886 the multi-staged process as documented by Baker [1], the new prefix
887 is introduced via router advertisements, and then the old prefix is
888 deprecated, and finally removed.
890 Initially the router advertisements will contain only the prefix of
891 the old network, then for a time they will contain both the old and
892 the new, but with a shorter (zero) lifetime on the old prefix to
893 indicate that it is deprecated. Finally the router advertisements
894 will contain only the new prefix.
896 6.1.1. Router Advertisement Lifetimes
898 RFC2462 (IPv6 Stateless Autoconfiguration) [6] specifies the
899 technique for expiring assigned prefixes and then invalidating them,
900 such that a network has opportunity to gracefully withdraw a prefix
901 from service whilst not terminally disrupting on-going applications
902 that use addresses under it. Section 5.5.4 of RFC2462 in particular
903 details the procedure for deprecation and subsequent invalidation.
905 By mandating as a node requirement the ability to phase out addresses
906 assigned to an interface, network renumbering is readily facilitated:
907 subnet routers update the pre-existing prefix and mark them as
908 'deprecated' with a scheduled time for expiration and then advertise
909 (when appropriate) the new prefix that should be chosen for all
910 outgoing communications.
912 6.1.2. Stateless Configuration with DHCPv6
914 Sometimes, DHCPv6 will be used alongside SLAAC. SLAAC will provide
915 the address assignment, and DHCPv6 will provide additional host
916 configuration options, such as DNS servers. If any of the DHCPv6
917 options are directly related to the IPv6 addresses being renumbered,
918 then the configuration must be changed at the appropriate time during
919 the renumbering event, even though it itself does not handle the
920 address assignments.
922 Since the configuration is stateless, the DHCPv6 server will not know
923 which clients to contact to inform them to refresh. Clients of the
924 configuration protocol should poll the service to obtain potentially
925 updated ancillary data, such as suggested by [29]. It is proposed
926 that a new DHCPv6 service option is added to inform clients of an
927 upper bound for how long they should wait before re-requesting
928 service information.
930 6.1.3. Tokenised Interface Identifiers
932 IPv6 Stateless Address Auto-configuration (SLAAC) enables network
933 administrators to deploy devices in a network and have those devices
934 automatically generate global addresses without any administrative
935 intervention, and without the need for any stateful configuration
936 service such as DHCPv6.
938 However, certain services - such as HTTP, SMTP and IMAP - may better
939 benefit from having 'well known' identifiers that do not depend on
940 the physical hardware address of the server's network interface card,
941 e.g. ::53 for name servers.
943 Tokenised addresses offer a facility for administrators to specify
944 the bottom 64 bits of an IPv6 address for a node whilst allowing the
945 top 64 bits (the network prefix) to be automatically configured from
946 router advertisements.
948 Currently, only more recent versions of Sun Microsytems' Solaris
949 operating system features ioctl-configured support for tokenised
950 interface identifiers, although recent work at Southampton has
951 demonstrated that the configuration technique can be introduced
952 trivially through simple kernel extensions in Linux.
954 As regards renumbering, automatically configured tokenised addresses,
955 where the network prefix component is learnt through router
956 advertisements, ease the renumbering process where administrators
957 have elected to use well known interface identifiers. Rather than
958 having to manually reconfigure the nodes with the new addresses, the
959 nodes can rely on automatic configuration techniques to pick up the
960 new prefix.
962 6.2. Stateful Configuration with DHCPv6
964 As opposed to stateless autoconfiguration, IPv6 stateful or managed
965 configuration can be achieved through the deployment of DHCPv6.
966 Section 18.1.8 of [30] details how a node should respond to the
967 receipt of stateful configuration data from a DHCPv6 server where the
968 lifetime indicated has expired (is zero). Section 19.4.1 details how
969 clients should respond to being instructed by DHCPv6 servers to
970 reconfigure (potentially forceful renumbering). Section 22.6 details
971 how prefix validity time is conveyed (c.f. the equivalent data in
972 SLAAC's Router Advertisement).
974 In order to renumber such a network, the DHCPv6 server should send
975 reconfigure messages to inform the clients that the configuration has
976 changed, and the clients should re-request configuration details from
977 the DHCPv6 server. This, of course, relies on the clients correctly
978 responding to such messages.
980 Where DHCPv6 has been employed, careful consideration about the
981 configuration of the service is required such that administrators can
982 be confident that clients will re-contact the service to refresh
983 their configuration data. As alluded to in sections 22.4 and 22.5 of
984 [30], the configurable timers that offer servers the ability to
985 control when clients re-contacts the server about its configuration
986 can be set such that clients rarely (if ever) connect to validate
987 their configuration set.
989 The approach described in [29] allows the lifetime of other
990 configuration information supplied by DHCPv6 to be ramped down in
991 preparation for a planned renumbering event.
993 6.2.1. Prefix Delegation
995 Where stateless autoconfiguration enables hosts to request prefixes
996 from link-attached routers, prefix delegation enables routers to
997 request a prefix for advertising from superior routers, i.e. routers
998 closer to the top of the prefix hierarchy - typically topologically
999 closer, therefore, to the provider. Once the router has been
1000 delegated prefix(es), it can begin advertising it to the connected
1001 subnet (perhaps even multi-link) with indicators for hosts to use
1002 stateful (DHCPv6) or stateless address autoconfiguration as per
1003 RFC2461.
1005 There have been two principal approaches to prefix delegation
1006 proposed: HPD (Hierarchical Prefix Delegation for IPv6), which
1007 proposed the use of bespoke ICMPv6 messages for prefix delegation,
1008 and IPv6 Prefix Options for Dynamic Host Configuration Protocol [31],
1009 which defines a DHCPv6 option type. Of the two approaches, the
1010 DHCPv6-based approach has received wide support and is on the
1011 standards track.
1013 6.2.2. Source Address Selection Policy distribution
1015 It has been proposed that DHCPv6 could also be used to distribute
1016 source address selection policy to nodes [24]. The model proposes
1017 that consumer edge router receives policies (e.g. from multiple ISPs
1018 in the case of multi-homed networks) and re-distributes them to end
1019 nodes. The end nodes then put them into their local policy table,
1020 which leads to appropriate source address selection. Where the
1021 design goal was a distribution mechanism in light of multi-homed
1022 networks, the adoption of the technique for the multi-prefix states
1023 of [1] during renumbering appears appropriate.
1025 6.3. Router Renumbering
1027 RFC2894 [7] defines a mechanism for renumbering IPv6 routers
1028 throughout a network using a bespoke ICMP message type for
1029 manipulating the set of prefixes deployed throughout subnets.
1030 Through the use of prefix matching and a rudimentary algebra for bit-
1031 wise manipulation of prefix data bound to router interfaces, the
1032 mechanism enables administrators to affect every router within a
1033 scope from a single administration workstation. One drawback of
1034 RFC2894 is that it requires an enterprise-wide IPsec infrastructure
1035 to be deployed to secure the ICMP messages in order to be compliant.
1037 The approach utilises multicast communication to the all-routers
1038 address, FF05::2, scoped to the entire 'site' as determined by router
1039 filter policy to distribute configuration updates to all (compliant)
1040 routers. The mechanism also works with more specific addressing
1041 modalities, such as link-local multicast (FF02::2) to reach all
1042 routers on a specific link, or directed unicast to affect a specific
1043 router instance. When surveying current implementations very few
1044 IPv6 implementations bound their interfaces to the Site-wide All-
1045 Routers multicast address (FF05::2), and fewer still have
1046 implementations of RFC2894.
1048 Example use cases cited in RFC2894 are for deploying global routing
1049 prefixes across a hierarchical network where site-locals already
1050 exist (presumably updated now to Unique Local Addresses), and for
1051 renumbering from an existing prefix to another in a similar manner to
1052 that proposed by Baker (i.e. the deployment of a new prefix alongside
1053 the existing one, which is deprecated and subsequently expired and
1054 removed - using the same mechanism described).
1056 The specification was developed before the shift in recommendation
1057 away from the Top-, Next- at Site-Level Aggregation Identifier
1058 address allocation hierarchy of RFC3513, although the techniques
1059 documented for renumbering the global routing prefix and subnet ID
1060 components in the updated address allocation recommendations [17] are
1061 not affected by the architectural change.
1063 As with other prefix assignment techniques, it is the responsibility
1064 of the node to correctly deprecate and then expire the use of a
1065 previously assigned prefix as defined by the IPv6 Neighbour Discovery
1066 protocol, RFC2461 [8], section 4.6.2 describing the Prefix
1067 Information option in particular.
1069 7. Administrative Considerations for Renumbering
1071 This section is concerned with factors that affect the renumbering
1072 procedure, from a network administration viewpoint. In particular,
1073 this section discusses areas that a network administrator should
1074 consider before undertaking a renumbering event, to ensure that it
1075 proceeds smoothly. This includes considerations of event frequency,
1076 scalability, and those relating to delays in information propagation.
1078 7.1. Router Advertisement Lifetimes
1080 As discussed in Section 6.1.1, IPv6 Stateless Autoconfiguration
1081 allows the expiration of assigned prefixes. This process permits
1082 existing sessions to continue while preferring a new prefix. It
1083 should be noted, however, that there are some limitations in the
1084 specification that have an impact in renumbering. In particular, it
1085 is not possible to reduce a prefix's lifetime to below two hours if
1086 it has previously been available at a longer validity. This
1087 therefore emphasises the need to plan renumbering events in advance
1088 if at all possible, to reduce the lifetime as required, within these
1089 limitations.
1091 7.2. Border filtering
1093 Multi-addressing (Section 5.1) allows multiple globally reachable
1094 addresses to be assigned to node interfaces, but one administrative
1095 caveat that arises is that of site border filtering. Not only is it
1096 the norm for sites to filter at their border router traffic that is
1097 not destined to local subnets, but it is also increasingly common for
1098 sites to undertake egress filtering. This is often used to prevent
1099 administratively local addresses (such as the, now deprecated, site-
1100 local prefix) 'leaking' traffic, or for mis-configured hosts (e.g.
1101 visitors with manually configured stacks without Mobile IPv6) from
1102 sourcing traffic that cannot be routed back (cases of which may
1103 include deliberate IP spoofing or DDoS attempts).
1105 Providers often use ingress filtering so that the provider only
1106 accepts packets from customers that have source addresses inside the
1107 address space the provider has delegated to the customer. With
1108 multi-addressing, hosts in the site may send packets with source
1109 addresses from either provider's address space. If the providers do
1110 ingress filtering, a packet must then be forwarded out on the correct
1111 uplink, based on which source address the packet has. If the site
1112 has a common exit router for the two uplinks, that router will need
1113 to route the packets based on the source address. If the site has
1114 two different exit routers, the entire site backbone may need to
1115 route based on source addresses in order to forward the packets to
1116 the correct exit router.
1118 7.3. Frequency of renumbering episodes
1120 The many different renumbering scenarios, discussed in Section 3, can
1121 have vastly different frequencies of renumbering events. In the case
1122 of a provider offering only dynamically assigned IP addresses, it
1123 could be very frequent, for example as frequent as 'per-connection'
1124 for dial-on-demand services, or weekly for some broadband services.
1125 Such renumbering events usually only occur when a customer reconnects
1126 to such services or are explicitly cited in a subscription agreement
1127 and as such are often pre-determined.
1129 The renumbering of a site due to upstream renumbering is relevant to
1130 all connections from a small dial-up link to a large enterprise. It
1131 is of particular interest since the end user has no control over the
1132 timing or frequency of the renumbering events. It is expected,
1133 however, that such events are likely to be very infrequent.
1135 The other irregular renumbering events are those that occur due to
1136 end user migrating, either to a new provider, or to a new address
1137 allocation of their choosing. The timing of such an event is
1138 therefore often within the control of the end user (within reason),
1139 and are also likely to be one-off events, or at the very least,
1140 highly infrequent.
1142 7.4. Delay-related Considerations
1144 When considering a renumbering event, both the planning of, and
1145 responses to the event are affected by temporal factors. The amount
1146 of time available in which to undertake the operation can change the
1147 administrative actions required, and this section aims to discuss
1148 some of these issues.
1150 7.4.1. With or without a flag day
1152 A network may be renumbered with or without a flag day. In the
1153 context of this document we are focusing on without a flag day,
1154 although many of the issues will still apply when renumbering is
1155 effected with a flag day.
1157 Despite the similarities, because there is an outage of services when
1158 renumbering with a flag day, it is not necessary to ensure continuity
1159 of network connections, and almost all reconfiguration can be done
1160 during the outage, thus greatly simplifying the task of renumbering.
1162 7.4.2. Freshness of service data
1164 One of the largest issues when renumbering a network will be the
1165 effect on applications that are already running. In particular,
1166 applications that periodically contact a particular host may do an
1167 initial hostname lookup, and cache the result for use throughout the
1168 lifetime of the program. In such a situation, there is no way for
1169 the application to find out that the host in question has been
1170 renumbered, and it should stop using its already cached address. It
1171 is therefore recommended that applications should regularly request
1172 hostname lookups for the desired hosts, leaving the caching to the
1173 resolver. It is then up to the resolver to ensure that resource
1174 record TTLs are observed, and its cached response is updated as
1175 necessary.
1177 Despite this, there is still a serious issue in that there is no
1178 method of caching resolvers knowing when a renumbering event is going
1179 to take place. If a typical RR's TTL is one day, then that should be
1180 reduced not less than a day before the renumbering event, so that
1181 resolvers will more frequently check for changed records. This will
1182 work successfully for a pre-planned renumbering event, but problems
1183 of stale, cached records will exist if the renumbering event is
1184 unplanned (e.g. by receiving a new router advertisement from
1185 upstream).
1187 There are also cases where the use of a resolver is not practical,
1188 such as with packet filter rules. If a packet filter has been
1189 configured with explicit hostnames, these are translated to IP
1190 addresses for fast packet matching. The per-packet resolver function
1191 is highly undesirable from a pure performance perspective. Such a
1192 packet filter is likely to need to be reloaded for the DNS changes to
1193 be recognised.
1195 A similar problem exists when a nameserver is renumbered. If the
1196 operating system's resolver has cached the nameserver address, it
1197 will at some point find it unavailable. To mitigate this problem, it
1198 is suggested that at least one off-site nameserver is included in the
1199 configuration. In addition, well-known anycast addresses (see
1200 Section 5.6) could be used, so that the client's DNS configuration
1201 does not need to be changed at all during the renumbering event.
1203 The basic process of renumbering, involving the introduction of a new
1204 prefix and the deprecation and eventual removal of the old prefix,
1205 could be hypothetically handled by a special tool, with no manual
1206 intervention. Such a tool would have to become significantly more
1207 complex in order to handle all the cases where IP addresses are
1208 explicitly specified (a comprehensive list is given in Section 9.2).
1209 Other particularly notable cases that could be changed with a tool,
1210 were it to be developed, include DNS zone files and DHCPv6
1211 configuration. Deployment of such a tool, even if possible, would be
1212 made complex through the requirement to authenticate the updates to
1213 each instance of the deployed literals.
1215 7.4.3. Availability of old prefix
1217 The duration of the period where the old prefix remains available
1218 affects the length of time that can be allowed for the renumbering
1219 procedure, and the maximum time for which existing sessions could
1220 continue. If end users have control over the renumbering procedure
1221 (such as when changing provider), then they can continue providing
1222 the old prefix for as long as required, within reason (such as cost
1223 aspects). This heavily mitigates the issues of session
1224 survivability, and relaxes the speed at which hosts must be
1225 reconfigured.
1227 If the end users do not have such control, such as when the upstream
1228 provider forces the renumbering, the availability of the old prefix
1229 is determined entirely by the upstream provider's willingness to
1230 continue providing it, which is likely to be based on the
1231 technicalities of their own renumbering situation. The end user
1232 should therefore not rely on retaining the old prefix for a
1233 relatively long period of time. In addition, many situations, such
1234 as dial-on-demand with dynamic IP addresses, and nomadic networks,
1235 will lose their old prefix quickly, if not almost instantaneously.
1237 It would be possible to continue using the old prefix internally,
1238 even when the external connectivity for that prefix is no longer
1239 active, for example to keep access to core services such as DNS
1240 servers while the transition is taking place. This should, however,
1241 be considered bad practice in case of route leaking and application
1242 confusion, as well as preventing access to the addresses if they have
1243 been reassigned, and as such this should only be used as a last
1244 resort to ensure internal continuity of service, if the availability
1245 of the old prefix is too short to allow a full transition to take
1246 place.
1248 7.4.4. Duration of overlap
1250 A key operational decision when renumbering is enforced due to a
1251 change in connectivity provider is how long to sustain the overlap of
1252 two live prefixes. The trade-off to be made is the cost of
1253 maintaining two contracts with separate providers against the
1254 'smoothness' of the transition to the new prefix as regards local
1255 administration overheads, service migration, etc. Where larger
1256 corporations can likely suffer the increased financial costs, SMEs
1257 and SOHOs might consider as little as one month's overlap too
1258 expensive, and so Baker's State 5 (Stable use of either prefix) [1]
1259 is unattainable in such scenarios.
1261 In some cases, there may be technical reasons for the overlap to not
1262 be feasible, such as with xDSL provision where the new service is a
1263 drop-in replacement for the old and the two cannot co-exist (for
1264 example, because the provision of the service requires the whole
1265 circuit resource from exchange to customer).
1267 7.5. Scalability issues
1269 During the renumbering transition, there will be a time when two
1270 prefixes are valid for use. At this point, there will be a
1271 considerable amount of configuration that will have to be
1272 (temporarily) duplicated. In particular, routing entries on the
1273 hosts will be doubled, and there will, for a short period, be two
1274 forward DNS records for every hostname. Security is another key
1275 scalability issue. All access control lists, packet filters, etc,
1276 will need to be updated to cope with the multiple addresses that each
1277 host will have. This could have a noticeable impact on packet filter
1278 performance, especially if it lead to, for example, the doubling of
1279 several hundred firewall rules.
1281 The scalability issues created by the increase in configuration to
1282 cope with the temporary existence of multiple addresses per host adds
1283 a complexity in management, but how much so is up to the end-users
1284 themselves. A user may choose to do direct transitions of some
1285 services (such as web servers) from one IP address to another,
1286 without going through a stage where the service is available on all
1287 addresses. While that is not strictly providing a fully seamless
1288 transition, it could significantly reduce the management complexity,
1289 without a significant impact on service, especially if the DNS
1290 updates are rapid.
1292 It should also be noted that during a renumbering event, since the
1293 DNS resource record TTLs are significantly shorter, the primary DNS
1294 servers for the domains will receive significantly more queries, as
1295 resolvers should not cache the responses for so long, and will
1296 regularly check back with the master. The likelihood of this having
1297 any significant impact is, however, fairly minimal, at least in a
1298 typical small to medium site.
1300 Section 3.1 of Baker [1] is aptly titled "Find all the places", and
1301 serves as a gentle reminder to application developers that embedding
1302 addresses is bad at best. Where common UNIX tools such as "grep"
1303 allow administrators to crawl the file systems of servers for places
1304 where address information is hard-coded, the proliferation of
1305 technologies such as NetInfo and other directory- or hive-based
1306 configuration schemes makes the job of finding all the places that
1307 addresses are hard-coded intractable.
1309 Beyond the call to arms for application and services developers made
1310 by Baker et al. [1], and specific to the challenges of renumbering,
1311 the following security and policy-related services that initial
1312 research has flagged as particularly troublesome:
1314 7.5.1. Packet filters, Firewalls and ACLs
1316 Throughout the transition from the old address set to the new, all
1317 packet filters and firewalls will need to adapt to map policy to both
1318 prefixes (sets of addresses) - perhaps even selectively as the old
1319 addresses become deprecated. Whilst technologies such as Router
1320 Renumbering and Neighbour Discovery automate to a large extent the
1321 transition of router and node configurations, and dynamic DNS update
1322 for the re-mapping of resource records to reflect the new addresses
1323 [32], no such mechanism exists at present for mechanising the
1324 adaption of security policy.
1326 Particularly troublesome policies to administer include egress
1327 filtering, where packet filters discard outbound packets that have
1328 source addresses that should not exist within the site, and filtering
1329 inbound site-local addresses in cases where two organisations are
1330 renumbering as a step toward merging their networks together
1331 (although the use of site-local addressing is now deprecated).
1333 Where renumbering is due to a 'clean break' from previous
1334 connectivity provider, another consideration is for the ingress
1335 filtering performed by the provider. For instance, the new provider
1336 may refuse to receive into their routing topology those packets whose
1337 source address is under the old prefix, and likewise for the old
1338 provider and new prefix. Whilst it is not the business of the IETF
1339 to mandate business practice, it is likely that the provision of out-
1340 of-allocation prefix routing as part of a multi-homing service
1341 contract would be a chargeable service and not one that an enterprise
1342 trying to make a clean break away would likely be willing to pay just
1343 for the duration of transition to their new prefix.
1345 Beyond the immediate up-stream provider, there are other policy-based
1346 considerations to take into account when renumbering. Some
1347 rudimentary authenticated access mechanisms rely on access queries
1348 coming from a particular IP network, for example, and so those
1349 application service providers will need to update their access
1350 control lists. Likewise all the internal applications (possibly
1351 meant for 'internal' eyes only) will have to have their access
1352 controls updated to reflect the change. The use of symbolic access
1353 controls (i.e. DNS domain names) rather than embedded addresses may
1354 serve to mitigate much of the distributed administrative load here,
1355 at least if such symbols are re-resolved, especially during the mid-
1356 renumbering states where both sets of addresses are still live and
1357 valid.
1359 7.5.1.1. Policy rule replication where both prefixes valid
1361 One key caveat with policy application during a renumbering prefix
1362 concerns rules that are 'tied down' at both ends to (sets of)
1363 addresses under the prefix to be renumbered, i.e. those that detail
1364 specific nodes or subnets in both source and destination elements of
1365 the policy rule as opposed to source 'any' or destination 'any'.
1367 Examples of where this approach apply include specific holes punched
1368 through a packet filter between a DMZ and the internal network, e.g.
1369 for staged access to compute servers from off-site.
1371 A dilemma here is that the otherwise 'ideal practice' use of symbolic
1372 names to identify elements in the network may not be appropriate in
1373 policy rules. This is particularly the case where resolver libraries
1374 do not return all bound resource data for symbols (i.e. old and new
1375 AAAA records for www.example.com), or where policy applications do
1376 not iterate across all returned resource record data in resolvers
1377 that are well behaved. It also assumes that name service data is
1378 updated ahead of policy application, which is ill-advised given that
1379 the instant name servers start serving data regarding new, yet to be
1380 configured, addresses for nodes.
1382 7.5.2. Monitoring tools
1384 Network monitoring and supervisory utilities such as RMON probes,
1385 etc., are often deployed to monitor network status based on IP
1386 traffic. During a renumbering episode, the addresses for which the
1387 probes should monitoring and the addresses of logging services to
1388 which the probes report (e.g. in the case of remote SNMP logging)
1389 need to be tracked.
1391 "Helpdesk ops" service liveness monitoring software also poses a
1392 particular problem where liveness is determined, for example, by a
1393 null transaction (e.g. for POP3 mail server, authenticating and
1394 performing a NOOP) made against a named service instance, if the name
1395 is by IP then two instances of the liveness test will be required:
1396 one on the old address to cater for those remote parties that are not
1397 yet aware of the new address, and one test against the new.
1399 As part of the renumbering process, it may be advantageous to deploy
1400 flow analysis tools that can be scripted to alert administrators on
1401 observation of particular traffic patterns, e.g. flows to a service
1402 under a deprecated prefix during transitions where both old and new
1403 prefixes are live and routed to the site concurrently. This can
1404 highlight, for example, mis-cached DNS resource records, sources of
1405 manually configured service location data, etc.
1407 When relying on DNS labels for identifying nodes to administer, care
1408 must be taken to ensure that the complete set of nodes administered
1409 are caught. For instance, a set of application servers may share the
1410 same DNS label and rely on DNS round-robin for rudimentary load
1411 balancing (a modality at odds with the notion of maintaining resource
1412 records for both old and new prefixes during renumbering episodes).
1413 A network monitoring tool that was configured to monitor just that
1414 service that was resolved by address lookup might only capture one of
1415 that set of nodes.
1417 7.6. Considerations with a Dual-Stack Network
1419 There are several issues to consider when renumbering a dual-stacked
1420 network. In the simplest case, the IPv4 addresses will be remaining
1421 the same while the IPv6 addresses are renumbered. This could, for
1422 example, be due to an upstream renumbering, a change of IPv6
1423 transition method (such as a tunnel), or a topology change. In such
1424 a case, the IPv4 connectivity remains unchanged, and as such can be
1425 used as a fallback during the renumbering to assist with session
1426 continuity, DNS services, etc.
1428 The other case is when the IPv4 network is being renumbered along
1429 with the IPv6 network. Again this could be due to an upstream
1430 change, a network reconfiguration, or because the two are inter-
1431 linked - such as with the 6to4 transition mechanism. In this case,
1432 it is unlikely that the existence of IPv4 on the network can be used
1433 for any advantage, and instead many of the same issues are likely to
1434 be found when renumbering the IPv4 network as for the IPv6 network,
1435 except for the fact that more of the renumbering must be manually
1436 configured, for example by reconfiguring the stateful IPv4 DHCP
1437 configuration, or even manually configuring IPv4 addresses.
1439 A hybrid case is also possible, where IPv4 NAT is used on the
1440 internal network, but with globally routable IPv6 addresses. In this
1441 case, if both networks' external connectivity is being renumbered,
1442 the internal network will only see the effect of the IPv6
1443 renumbering, while keeping the IPv4 addresses the same. The
1444 renumbering procedure will still have an impact on the IPv4
1445 connectivity and its session survivability, however. It may also be
1446 possible that the site uses both global and ULA IPv6 prefixes, the
1447 ULA prefix being deployed to avoid impact to long-running IPv6
1448 sessions.
1450 7.7. Equipment administrative ownership
1452 The question of who owns and administers (also, who is authorised to
1453 administer) the site's access router is an issue in some renumbering
1454 situations. In the enterprise scenarios, the liaison between the end
1455 users and remote administrators is likely to be relatively easy; this
1456 is less likely to be the case for a SOHO scenario. This is not
1457 likely to be a major issue, however, since SOHO renumbering is likely
1458 to only be required if the remote administrators deem it necessary,
1459 or if the end user is sufficiently technically competent and decides
1460 to renumber their own network.
1462 8. Impact of Topology Design on Renumbering
1464 This section looks at considerations regarding network design, such
1465 as network merging, and design-time recommendations that can help
1466 avoid the need for a network renumbering event.
1468 8.1. Merging networks
1470 Renumbering of all or part of a network due to merging two or more
1471 smaller networks has many of the concerns already discussed, but it
1472 may not affect the whole network. For example, multiple disparate
1473 networks may be merged together as one entirely new subnet, and thus
1474 all hosts must be renumbered; but it is also possible that one of the
1475 networks in the merger retains its prefix, and the other network(s)
1476 merge with it.
1478 When the networks merge, the router advertises itself, and the new
1479 prefix if appropriate, to the new hosts, and Duplicate Address
1480 Detection (DAD, see Section 5.4 of [6]) must be applied by the new
1481 hosts to ensure they are not taking addresses already assigned to the
1482 existing hosts. It is implementation-dependent, however, as to
1483 whether the DAD algorithm will be re-run on link-local addresses if
1484 the network configuration is changed, so there is the possibility of
1485 an address conflict. However, as is noted in RFC2462, DAD is not
1486 completely reliable, and as such it cannot be assumed that initially
1487 after a network merge all link-local addresses will be unique.
1489 8.2. Fixed length subnets
1491 The IAB/IESG recommendations for IPv6 address allocations [10]
1492 details some of the motivations behind the change in the addressing
1493 architecture of IPv6 since its inception, and asserts the current
1494 state of a 64-bit 'network' part (the prefix) and a 64-bit 'host'
1495 part (the interface identifier). Fixing the lower 64 bits to be
1496 exclusive of routing topology significantly reduces the
1497 administrative load associated with renumbering and re-subnetting as
1498 experienced with IPv4 networks previously, for example, to get better
1499 address utilisation efficiency as networks evolve and provider
1500 address allocations changed.
1502 The recommendations also discuss what length of network prefix should
1503 be allocated to sites, typically provisioning for 16-bits of subnet
1504 space in which sites can build their topology. Having such a large
1505 address space for sites to divide up at their discretion alleviates
1506 many of the drivers for renumbering discussed during the PIER working
1507 group's lifetime [3].
1509 8.3. Use 112-bit prefixes for point-to-point links
1511 It is recommended that point-to-point links, such as tunnel endpoints
1512 or router-router links, are allocated /112 subnets from a single /64
1513 within the site's allocation. This simplifies policy-based filtering
1514 and is less wasteful of address space than using /64s everywhere,
1515 improving the address utilisation ratio for the site that would in
1516 extreme cases lead to a larger prefix becoming required.
1518 The 112-bit prefix length is preferred to 127-bit on the advice of
1519 RFC3627[33], which suggests that such allocations can lead to end-
1520 point address starvation where one router elects to take both the
1521 zeroth address in the /127 as a subnet router anycast address and the
1522 first address for its endpoint, leaving no address for the remote end
1523 of the link.
1525 8.4. Plan for growth where possible
1527 When designing address topology - particularly in ISP and larger-
1528 scale Enterprise sites - it is recommended that network designers
1529 plan for growth of lower hierarchies under their provision (e.g. a
1530 /60 satellite site becoming big enough for a /56; a /48 customer
1531 getting sufficiently large as to warrant a shorter prefix).
1533 Techniques for such allocations include centre-most bitset growth as
1534 described in Section 3.3 of RFC3531 [17], which leave the bits nearer
1535 upstream and downstream bit-boundaries until much later in the
1536 allocation selection set, meaning that a boundary shift has minimal
1537 impact on existing deployed allocations. However the overheads and
1538 non-contiguous nature of successive allocations may not suit
1539 Enterprise sites, meaning that other allocation strategies are
1540 required, contextually sensitive to the demands of the site in which
1541 the prefixes are being deployed.
1543 In enterprise networks where satellite sites participate, it is
1544 recommended that single-subnet blocks are skipped in the allocation
1545 such that remote satellites can grow (double) without requiring those
1546 `nearby' in the address block to renumber.
1548 For example, the strategy taken in an enterprise with 56-bit prefixes
1549 allocated to satellites is to leave subsequent /56s for future
1550 expansion of each sub-tier to a /55.
1552 Note that strictly adopting RFC3531 may be insufficient in
1553 enterprises where, for example, there is a mix of subnet provision
1554 (e.g. for satellite sites) and end-user subnets.
1556 8.5. IPv6 NAT Avoidance
1558 RFC2072 stated: "Network address translation (NAT) is a valuable
1559 technique for renumbering, or even for avoiding the need to renumber
1560 significant parts of an enterprise." That is, by 'hiding' the subnet
1561 topology and making independent of any connectivity provider the
1562 addressing model used within a site, NATs enable renumbering of
1563 entire networks because the only device that is renumbered when
1564 global addressing changes is the outside edge of the NAT devices.
1566 However, NAT is strongly discouraged in IPv6, not least because it
1567 breaks end-to-end transparency (as described in [34]) and obscures
1568 identity - including the basis for permission, authorisation,
1569 verification and validation - and thus should not be considered as
1570 being available as a solution. A significant reason to deploy IPv6
1571 is to simplify network and application operation by (IPv4) NAT
1572 removal, for example to provide true end-to-end connectivity, to make
1573 simple the gateway between site and Internet, to encourage
1574 'considered' policy for secure access rather than rely on the
1575 (relatively) dangerous defence of 'hiding' behind a NAT. A more
1576 detailed discussion of the motivations for 'protecting' the network
1577 architecture from NATs can be found in [35].
1579 9. Application and service-oriented Issues
1581 In this section we highlight issues and common approaches to software
1582 development that 'disrupt' protocol layering to the extent that
1583 applications become aware of renumbering episodes, even if
1584 catastrophic and without knowing how to recover without failing.
1586 NOTE: This section, like the discussion sections before it, will
1587 evolve as experience grows researching the various renumbering
1588 strategies in controlled experiments - particularly in light of
1589 Section 10.1.
1591 9.1. Shims and sockets
1593 As discussed in Section 7.5, Baker's draft calls for application
1594 developers to consider the effects of renumbering whilst applications
1595 are 'live', particularly as regards caching the results of symbol
1596 resolution. Where applications maintain open connections to services
1597 over a sustained period of time (as opposed to the ephemeral nature
1598 of protocol interactions such as with HTTP), any change in either
1599 end's addressing may intrude on the application's execution -
1600 particularly if the change is abrupt or the session longer than the
1601 expiry and withdrawal time of the old addresses.
1603 Various options may be available to minimise the risk of application
1604 disruption in this instance. A HIP-like 'shim' [36], as is being
1605 developed as a candidate solution to the general multi-homing
1606 problem, removes the tight coupling between a connection and a
1607 service's topological location: as the renumbering event takes place,
1608 the locator is updated to reflect the new address topology, and the
1609 application remains blissfully unaware - a form of layer 3.5
1610 mobility.
1612 Alternatively, should the old address space be available such that a
1613 single (or subnet of) Mobile IPv6 Home Agents be deployed in the
1614 routing path of the to-be-otherwise-interrupted connection, then the
1615 endpoint being renumbered could utilise layer 3 mobility once the old
1616 prefix is removed from its link, i.e. register with the Home Agent in
1617 the old prefix topology - presumably in the provider's network,
1618 formerly upstream from the site - and rely on Mobile IPv6 route
1619 optimisation to make good the additional overhead imposed by the
1620 reverse tunnelling to the new prefix.
1622 Applications that employ SCTP as opposed to TCP or UDP for
1623 communication avoid all of the issues highlighted in this sub-section
1624 due to the provision of dynamic endpoint reconfiguration in the
1625 protocol (see Section 4.2).
1627 9.2. Explicitly named IP addresses
1629 There are many places in the network where IP addresses are embedded
1630 as opposed to symbolic names, and finding them all to be updated
1631 during a renumbering episode is not a trivial task. This section
1632 details an evolving list of such places as surveyed as common.
1634 Addresses may be hard-coded in software configuration files or
1635 services, in software source-code itself (which is particularly
1636 cumbersome if no source is available, e.g. a bespoke utility built to
1637 order), in firmware (for example, an access-controlling hardware
1638 dongle), or even in hardware, e.g. fixed by DIP switches.
1640 A non-exhaustive list of instances of such addresses includes:
1642 o Provider based prefix(es)
1644 o Names resolved to IP addresses in firewall at startup time
1646 o IP addresses in remote firewalls allowing access to remote
1647 services
1649 o IP-based authentication in remote systems allowing access to
1650 online bibliographic resources
1652 o IP address of both tunnel end points for IPv6 in IPv4 tunnel
1654 o Hard-coded IP subnet configuration information
1656 o IP addresses for static route targets
1658 o Blocked SMTP server IP list (spam sources)
1660 o Web .htaccess and remote access controls
1661 o Apache .Listen. directive on given IP address
1663 o Configured multicast rendezvous point
1665 o TCP wrapper files
1667 o Samba configuration files
1669 o DNS resolv.conf on Unix
1671 o Any network traffic monitoring tool
1673 o NIS/ypbind via the hosts file
1675 o Some interface configurations
1677 o Unix portmap security masks
1679 o NIS security masks
1681 o PIM-SM Rendezvous Point address on multicast routers
1683 Some hard-coded IP address information will be held in remote
1684 locations, e.g. remote firewalls, DNS glue, etc. adding to the
1685 complexity of the search for all instances of the old prefix. Should
1686 symbols be used rather than addresses, administrative ownership of
1687 DNS - with due consideration for the TTL of resource records - and
1688 other naming services ease this particularly problematic issue of
1689 data ownership and validity.
1691 There are also cases when IP addresses are embedded into payload
1692 data, such as with UDP-based NFS mounts and FTP sessions. These
1693 cases were discussed in more detail in Section 4.2.4.
1695 9.3. API dilemma
1697 In light of Section 7.4.2, there is an open question as to whether we
1698 need an extension to the sockets API that would allow applications
1699 resolving addresses to be able to determine the freshness of the
1700 resolved data. A straw poll of networking applications demonstrated
1701 that common programming practise is to 'resolve once, bind many'
1702 during the lifetime of an application, caching the initial lookup
1703 result and assuming that it is still valid throughout. Whilst this
1704 is a perfectly valid approach for short-lived applications, where the
1705 chance of renumbering - site or the single node - increases with
1706 regards the longevity of the application, the likelihood of the
1707 resolved data being intrusively inaccurate also increases.
1709 Application programmers should therefore consider the possibility of
1710 network renumbering when writing socket software. The best behaviour
1711 is probably to freshly resolve for any socket binding, and let the
1712 resolver handle the caching, based on the DNS TTL. Only when there
1713 are a significant number of connections within a short timeframe
1714 should application-level caching be considered.
1716 9.4. Server Sockets
1718 Certain applications create a server socket and bind the socket so
1719 that they only receive connections or datagrams at one specific
1720 address. These services typically keep the socket bound to that
1721 address until they are shut-down or restarted. This means that if
1722 the host is configured with a new address, these applications would
1723 not respond to that address.
1725 If the applications were listening to the wildcard address, they
1726 would also accept connections and datagrams on new addresses as they
1727 become configured on a node.
1729 An example would be a webserver, which may in fact bind to multiple
1730 different IP addresses to serve content for different domains where
1731 the particular business case is for customers to be allocated their
1732 'own' IP address (e.g. for reverse DNS to reflect their branded
1733 domain name).
1735 A typical work-around would be to schedule a restart of all such
1736 services having first identified whether they can operate on both
1737 address prefixes (to satisfy the middle states of Baker [1]), or at
1738 least to schedule their migration to the new address configuration in
1739 light of the DNS name bindings (considering caches and TTL), and the
1740 nature of existing clients that may still be bound to the old service
1741 (consider graceful migration).
1743 One possible solution, not implemented in existing socket APIs, would
1744 be to allow servers to bind to just the lowest 64 bits of an address,
1745 allowing the network identifier to change without the server knowing.
1746 This is a purely hypothetical solution, however, and has numerous
1747 issues, not least regarding requirements of some server software to
1748 know its current globally routable IP address.
1750 9.5. Sockets surviving invalidity
1752 When an address expires (validity lifetime falls to zero), addresses
1753 are to be removed from interfaces, and the expired address is not to
1754 be used as a source address for further packets (see RFC2462 section
1755 5.5.4 and RFC2215 secion 10).
1757 However, it appears that for an established TCP session or for UDP
1758 where the application has bound to a specific address, many stack
1759 implementations keep using the same source address blindly putting
1760 packets onto the wire, even if the address is removed from the
1761 interface.
1763 It appears that these stack implementations make sure the address is
1764 valid when the TCP session is created or when an application binds to
1765 an address on a datagram socket, but once the socket is bound to that
1766 address there are no more checks.
1768 Whilst this is not a serious issue - certainly, no reply packets
1769 could be received as the interface will not listen for them, and it
1770 is likely that the prefix would no longer be routable at the next-hop
1771 router beyond the point of invalidation - it does mean that
1772 application data will be lost up until that point where the transport
1773 layer determines that the packets are not being received (e.g. TCP
1774 ACKs).
1776 9.6. DNS Authority
1778 It is often the case in enterprises that host web servers and
1779 application servers on behalf of collaborators and customers that DNS
1780 zones out of the administrative control of the host maintain resource
1781 records concerning addresses for nodes out of their control.
1783 The upshot here is that when the service host renumbers, they do not
1784 have sufficient authority to change the AAAA records, etc., that
1785 refer to newly renumbered addresses.
1787 It is recommended that remote DNSes maintain CNAME records to labels
1788 in a zone that is under the authoritative control of the enterprise
1789 whose addresses are referenced.
1791 10. Summary
1793 This memo has further motivated the issue of network renumbering,
1794 highlighted important requirements to ensure that episodes can pass
1795 smoothly with a minimum of disruption to users, and indicated a
1796 number of protocol features and technologies that assist network
1797 designers and operators in the smooth transition from one prefix to
1798 another, all in the context of [1].
1800 10.1. IETF Call to Arms
1802 Validation surveys of address selection implementations per RFC3484,
1803 of address expiry per RFC2462 and RFC3315, and operational experience
1804 validating the Baker et al. procedure have been carried out and
1805 reported on in other fora (e.g. in D3.6.1 of the 6NET project).
1806 However, in the above considerations, a number of actions would be
1807 most helpful in advancing the understanding of the practical
1808 implications and robustness of IPv6 renumbering. These include:
1810 o Survey of the pervasiveness of address literals and steps to avoid
1811 their use
1813 o Validation of address selection at source and destination during
1814 various stages of Baker's renumbering procedure in implementations
1815 other than Cisco IOS, FreeBSD 5.9, Linux 2.6, Macintosh OS/X 10.4,
1816 Sun Solaris 8-10, Microsoft Windows XP SP2
1818 o Validation of RA lifetime expiry and confirmation of prefix
1819 removal and effects on existing sessions in other implementations
1821 o Validation of IPv6 Prefix Delegation by DHCP, and of IPv6 Router
1822 Renumbering
1824 o Better understanding of the commonalities and differences between
1825 renumbering and multi-homing
1827 o Anecdotal experience of IETF members that have undertaken an IPv6
1828 renumbering exercise, e.g. in the transition from 3FFE::/16 6Bone
1829 addresses to production GAU
1831 Given that this memo is dressed as a set of "things to think about",
1832 there is no conclusion other than a call for input from the IETF
1833 community.
1835 There may be a case to be made to reopen the PIER WG in the new
1836 context of IPv6, although that group has not been active since 1997.
1838 11. IANA Considerations
1840 This document makes no request of IANA.
1842 12. Security Considerations
1844 The security considerations as outlined in [1] still hold, with the
1845 following supporting comments... (tbd)
1847 13. Acknowledgements
1848 The authors gratefully acknowledge the many helpful discussions and
1849 suggestions of their colleagues from the 6NET consortium,
1850 particularly Fred Baker, Graca Carvalho, Ralph Droms, David Mills,
1851 Thorsten Kuefer, Eliot Lear, Christian Schild, Andre Stolze, Tina
1852 Strauf, Bernard Tuy, and Gunter Van de Velde.
1854 14. References
1856 14.1. Normative References
1858 [1] Baker, F., "Procedures for Renumbering an IPv6 Network without a
1859 Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in
1860 progress), March 2005.
1862 [2] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser,
1863 "Enterprise Renumbering: Experience and Information
1864 Solicitation", RFC 1916, February 1996.
1866 [3] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
1867 Why would I want it and what is it anyway?", RFC 2071,
1868 January 1997.
1870 [4] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
1871 January 1997.
1873 [5] Draves, R., "Default Address Selection for Internet Protocol
1874 version 6 (IPv6)", RFC 3484, February 2003.
1876 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address
1877 Autoconfiguration", RFC 2462, December 1998.
1879 [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894,
1880 August 2000.
1882 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
1883 for IP Version 6 (IPv6)", RFC 2461, December 1998.
1885 14.2. Informative References
1887 [9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
1888 IPv4 Clouds", RFC 3056, February 2001.
1890 [10] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
1891 Allocations to Sites", RFC 3177, September 2001.
1893 [11] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
1894 Allocation) Phaseout", RFC 3701, March 2004.
1896 [12] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
1897 Site Automatic Tunnel Addressing Protocol (ISATAP)",
1898 draft-ietf-ngtrans-isatap-24 (work in progress), January 2005.
1900 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless
1901 Address Autoconfiguration in IPv6", RFC 3041, January 2001.
1903 [14] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
1904 draft-ietf-nemo-terminology-05 (work in progress), March 2006.
1906 [15] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
1907 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
1908 Paxson, "Stream Control Transmission Protocol", RFC 2960,
1909 October 2000.
1911 [16] Stewart, R., "Stream Control Transmission Protocol (SCTP)
1912 Dynamic Address Reconfiguration",
1913 draft-ietf-tsvwg-addip-sctp-15 (work in progress), June 2006.
1915 [17] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
1916 Addressing Architecture", RFC 3513, April 2003.
1918 [18] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
1919 IPv6", RFC 3775, June 2004.
1921 [19] Huston, G., "Architectural Approaches to Multi-Homing for
1922 IPv6", draft-ietf-multi6-architecture-04 (work in progress),
1923 February 2005.
1925 [20] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
1926 Multicast Addresses", RFC 3306, August 2002.
1928 [21] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
1929 (RP) Address in an IPv6 Multicast Address", RFC 3956,
1930 November 2004.
1932 [22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
1933 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
1934 progress), January 2005.
1936 [23] Hinden, R. and B. Haberman, "Centrally Assigned Unique Local
1937 IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-01 (work
1938 in progress), February 2005.
1940 [24] Matsumoto, A., "Source Address Selection Policy Distribution
1941 for Multihoming", draft-arifumi-multi6-sas-policy-dist-00 (work
1942 in progress), October 2004.
1944 [25] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
1945 Addresses", RFC 2526, March 1999.
1947 [26] Jeong, J., "IPv6 Host Configuration of DNS Server Information
1948 Approaches", draft-ietf-dnsop-ipv6-dns-configuration-06 (work
1949 in progress), May 2005.
1951 [27] Abley, J. and K. Lindqvist, "Operation of Anycast Services",
1952 draft-ietf-grow-anycast-04 (work in progress), July 2006.
1954 [28] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
1955 Service", RFC 1546, November 1993.
1957 [29] Venaas, S. and T. Chown, "Information Refresh Time Option for
1958 DHCPv6", draft-ietf-dhc-lifetime-03 (work in progress),
1959 January 2005.
1961 [30] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
1962 Carney, "Dynamic Host Configuration Protocol for IPv6
1963 (DHCPv6)", RFC 3315, July 2003.
1965 [31] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
1966 Configuration Protocol (DHCP) version 6", RFC 3633,
1967 December 2003.
1969 [32] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
1970 Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
1971 April 1997.
1973 [33] Savola, P., "Use of /127 Prefix Length Between Routers
1974 Considered Harmful", RFC 3627, September 2003.
1976 [34] Carpenter, B., "Internet Transparency", RFC 2775,
1977 February 2000.
1979 [35] Velde, G., "IPv6 Network Architecture Protection",
1980 draft-ietf-v6ops-nap-03 (work in progress), July 2006.
1982 [36] Moskowitz, R. and P. Nikander, "Host Identity Protocol
1983 Architecture", draft-ietf-hip-arch-03 (work in progress),
1984 August 2005.
1986 URIs
1988 [38]
1990 [39]
1992 Authors' Addresses
1994 Tim J. Chown
1995 University of Southampton, UK
1996 Electronics and Computer Science
1997 University of Southampton
1998 Southampton SO17 1BJ
1999 UK
2001 Phone: +44 23 8059 5415
2002 Fax: +44 23 8059 2865
2003 Email: tjc@ecs.soton.ac.uk
2005 Mark K. Thompson
2006 University of Southampton, UK
2008 Email: mkt@ecs.soton.ac.uk
2010 Alan Ford
2011 University of Southampton, UK
2013 Email: ajf101@ecs.soton.ac.uk
2015 Stig Venaas
2016 University of Southampton, UK
2018 Email: sv@ecs.soton.ac.uk
2020 Intellectual Property Statement
2022 The IETF takes no position regarding the validity or scope of any
2023 Intellectual Property Rights or other rights that might be claimed to
2024 pertain to the implementation or use of the technology described in
2025 this document or the extent to which any license under such rights
2026 might or might not be available; nor does it represent that it has
2027 made any independent effort to identify any such rights. Information
2028 on the procedures with respect to rights in RFC documents can be
2029 found in BCP 78 and BCP 79.
2031 Copies of IPR disclosures made to the IETF Secretariat and any
2032 assurances of licenses to be made available, or the result of an
2033 attempt made to obtain a general license or permission for the use of
2034 such proprietary rights by implementers or users of this
2035 specification can be obtained from the IETF on-line IPR repository at
2036 http://www.ietf.org/ipr.
2038 The IETF invites any interested party to bring to its attention any
2039 copyrights, patents or patent applications, or other proprietary
2040 rights that may cover technology that may be required to implement
2041 this standard. Please address the information to the IETF at
2042 ietf-ipr@ietf.org.
2044 Disclaimer of Validity
2046 This document and the information contained herein are provided on an
2047 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2048 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2049 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2050 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2051 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2052 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2054 Copyright Statement
2056 Copyright (C) The Internet Society (2006). This document is subject
2057 to the rights, licenses and restrictions contained in BCP 78, and
2058 except as set forth therein, the authors retain all their rights.
2060 Acknowledgment
2062 Funding for the RFC Editor function is currently provided by the
2063 Internet Society.