One document matched: draft-chown-v6ops-renumber-thinkabout-05.txt
Differences from draft-chown-v6ops-renumber-thinkabout-04.txt
Network Working Group T. Chown
Internet-Draft M. Thompson
Expires: March 22, 2007 A. Ford
S. Venaas
University of Southampton, UK
September 18, 2006
Things to think about when Renumbering an IPv6 network
draft-chown-v6ops-renumber-thinkabout-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 22, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo presents a summary of scenarios, issues for consideration
and protocol features for IPv6 network renumbering, i.e. achieving
the transition from the use of an existing network prefix to a new
prefix in an IPv6 network. Its focus lies not in the procedure for
renumbering, but as a set of "things to think about" when undertaking
such a renumbering exercise.
Chown, et al. Expires March 22, 2007 [Page 1]
Internet-Draft Renumbering an IPv6 network September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Structure of Document . . . . . . . . . . . . . . . . . . 4
1.2. Past IPv4 Renumbering studies in the PIER WG . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Renumbering Event Triggers . . . . . . . . . . . . . . . . . . 5
3.1. Change of uplink prefix . . . . . . . . . . . . . . . . . 6
3.1.1. Migration to new provider . . . . . . . . . . . . . . 6
3.1.2. Dial on Demand . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Provider migration and upstream renumbering . . . . . 7
3.1.4. IPv6 transition . . . . . . . . . . . . . . . . . . . 7
3.2. Change of internal topology . . . . . . . . . . . . . . . 8
3.3. Acquisition or merger . . . . . . . . . . . . . . . . . . 8
3.4. Network growth . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Network mobility . . . . . . . . . . . . . . . . . . . . . 8
4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 9
4.1. Minimal disruption . . . . . . . . . . . . . . . . . . . . 9
4.2. Session survivability . . . . . . . . . . . . . . . . . . 9
4.2.1. Short-term session survivability . . . . . . . . . . . 10
4.2.2. Medium-term session survivability . . . . . . . . . . 10
4.2.3. Long-term session survivability . . . . . . . . . . . 10
4.2.4. "Sessions" in non-session based transports . . . . . . 11
5. IPv6 Protocol Features and their Effects on Renumbering . . . 11
5.1. Multi-addressing . . . . . . . . . . . . . . . . . . . . . 11
5.2. Multi-homing techniques . . . . . . . . . . . . . . . . . 12
5.2.1. Relevance of multi-homing to renumbering . . . . . . . 12
5.2.2. Current situation with IPv6 multi-homing . . . . . . . 13
5.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Visited site renumbers when mobile . . . . . . . . . . 14
5.3.2. Home site renumbers when mobile . . . . . . . . . . . 14
5.3.3. Home site renumbers when disconnected . . . . . . . . 14
5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Unique Local Addressing . . . . . . . . . . . . . . . . . 16
5.5.1. ULAs, Multicast and Address Selection . . . . . . . . 17
5.5.2. ULAs with application-layer gateways . . . . . . . . . 18
5.6. Anycast addressing . . . . . . . . . . . . . . . . . . . . 18
6. Node Configuration Issues . . . . . . . . . . . . . . . . . . 19
6.1. Stateless Address Autoconfiguration . . . . . . . . . . . 19
6.1.1. Router Advertisement Lifetimes . . . . . . . . . . . . 20
6.1.2. Stateless Configuration with DHCPv6 . . . . . . . . . 20
6.1.3. Tokenised Interface Identifiers . . . . . . . . . . . 20
6.2. Stateful Configuration with DHCPv6 . . . . . . . . . . . . 21
6.2.1. Prefix Delegation . . . . . . . . . . . . . . . . . . 22
6.2.2. Source Address Selection Policy distribution . . . . . 22
6.3. Router Renumbering . . . . . . . . . . . . . . . . . . . . 22
7. Administrative Considerations for Renumbering . . . . . . . . 23
7.1. Router Advertisement Lifetimes . . . . . . . . . . . . . . 23
Chown, et al. Expires March 22, 2007 [Page 2]
Internet-Draft Renumbering an IPv6 network September 2006
7.2. Border filtering . . . . . . . . . . . . . . . . . . . . . 24
7.3. Frequency of renumbering episodes . . . . . . . . . . . . 24
7.4. Delay-related Considerations . . . . . . . . . . . . . . . 25
7.4.1. With or without a flag day . . . . . . . . . . . . . . 25
7.4.2. Freshness of service data . . . . . . . . . . . . . . 25
7.4.3. Availability of old prefix . . . . . . . . . . . . . . 26
7.4.4. Duration of overlap . . . . . . . . . . . . . . . . . 27
7.5. Scalability issues . . . . . . . . . . . . . . . . . . . . 27
7.5.1. Packet filters, Firewalls and ACLs . . . . . . . . . . 28
7.5.2. Monitoring tools . . . . . . . . . . . . . . . . . . . 30
7.6. Considerations with a Dual-Stack Network . . . . . . . . . 30
7.7. Equipment administrative ownership . . . . . . . . . . . . 31
8. Impact of Topology Design on Renumbering . . . . . . . . . . . 31
8.1. Merging networks . . . . . . . . . . . . . . . . . . . . . 31
8.2. Fixed length subnets . . . . . . . . . . . . . . . . . . . 32
8.3. Use 112-bit prefixes for point-to-point links . . . . . . 32
8.4. Plan for growth where possible . . . . . . . . . . . . . . 33
8.5. IPv6 NAT Avoidance . . . . . . . . . . . . . . . . . . . . 33
9. Application and service-oriented Issues . . . . . . . . . . . 34
9.1. Shims and sockets . . . . . . . . . . . . . . . . . . . . 34
9.2. Explicitly named IP addresses . . . . . . . . . . . . . . 35
9.3. API dilemma . . . . . . . . . . . . . . . . . . . . . . . 36
9.4. Server Sockets . . . . . . . . . . . . . . . . . . . . . . 37
9.5. Sockets surviving invalidity . . . . . . . . . . . . . . . 37
9.6. DNS Authority . . . . . . . . . . . . . . . . . . . . . . 38
10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. IETF Call to Arms . . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
12. Security Considerations . . . . . . . . . . . . . . . . . . . 39
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative References . . . . . . . . . . . . . . . . . . . 40
14.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
Chown, et al. Expires March 22, 2007 [Page 3]
Internet-Draft Renumbering an IPv6 network September 2006
1. Introduction
This memo presents a summary of scenarios, issues for consideration
and protocol features for IPv6 network renumbering, i.e. achieving
the transition from the use of an existing network prefix to a new
prefix in an IPv6 network. This document does not relate the
procedures for IPv6 renumbering; for such a procedure the reader is
referred to [1]. The authors plan to use this document, together
with ongoing operational experience, to refine [1] where necessary,
to promote that guide from Informational to BCP. The focus is on
renumbering site networks, though many of the principles apply to
renumbering other (ISP) networks.
1.1. Structure of Document
This document is split into a number of sections that discuss various
aspects of network renumbering that should be considered when
undertaking such an event. This document begins with a discussion of
the various reasons behind renumbering events, and the requirements
to ensure the event goes smoothly. The following sections then
discuss a selection of factors that can both help and hinder the
renumbering procedure, and as such should be taken into account when
planning the event. Finally, this document summarises issues with
applications and services, and attempts to identify places where IP
addresses may be hard-coded and thus require reconfiguration during a
renumbering event.
1.2. Past IPv4 Renumbering studies in the PIER WG
A number of years ago (1996-1997), the Procedures for Internet/
Enterprise Renumbering (PIER) WG spent time considering the issues
for IPv4 renumbering. The WG produced three RFC documents. In
RFC1916 [2], a "call to arms" for input on renumbering techniques was
made. RFC2071 [3] documents why IPv4 renumbering is required.
Interestingly, many, but not all, of the drivers have changed with
respect to IPv6. In RFC2072 [4], a Router Renumbering Guide, some
operational procedures are given, much as they are in Baker [1] for
IPv6.
Reflection on RFC2071 is interesting, witness the quote: "It is also
envisioned that Network Address Translation (NAT) devices will be
developed to assist in the IPv4 to IPv6 transition, or perhaps
supplant the need to renumber the majority of interior networks
altogether, but that is beyond the scope of this document." That
need however is still very strong, particularly given the lack of
Provider Independent (PI) address space in IPv6 (in IPv4, PI address
space exists mainly for historical, pre-CIDR reasons).
Chown, et al. Expires March 22, 2007 [Page 4]
Internet-Draft Renumbering an IPv6 network September 2006
RFC2072 is more interesting in the context of this document. Some is
certainly relevant, though much is not, due to the inherent changes
in IPv6. For example, there is no CIDR and address aggregation is
given as mandate. Also, IPv6 subnets are in effect fixed length
(/64), so local administrators do not need to resize subnets to
maximise efficient use of address space as they do in IPv4.
One core message from RFC2072 that holds true today is that of
section 4 where the observation is made that renumbering networks
whilst remaining the same hierarchy of subnets (i.e. the cardinality
of the set of prefixes to renumber remains constant) is the 'easiest'
scenario to renumber; when each "old" prefix can be mapped to a
single "new" prefix.
A distinction of this work is that, where the PIER working group
consider the transition from IPv4 to IPv6 addressing as a renumbering
scenario, we strictly consider only the renumbering from IPv6
prefixes to other IPv6 prefixes and leave transition to well
documented techniques such as those from the PIER working group.
2. Terminology
The following terminology is used in this document (to be expanded in
future revisions):
o Site: An organisationally distinct network, ranging from SOHO
through to enterprise.
o Flag day: A planned service outage.
o Node: A device on the network that is being renumbered, or that is
involved in communication with the network being renumbered.
3. Renumbering Event Triggers
This section details typical actions that result in the need for a
renumbering event, and thus define the scenarios for renumbering.
In many instances, in particular those where no "flag day" is
involved, the process of renumbering will inevitably lead to a
scenario where hosts are multi-addressed or multi-homed as one phase
of the renumbering procedure. The relationship between renumbering
and multi-homing is discussed later in this document.
In other instances, e.g. a change in the IPv4 address offered by a
provider to a site using 6to4 [9], the change offers no overlap in
Chown, et al. Expires March 22, 2007 [Page 5]
Internet-Draft Renumbering an IPv6 network September 2006
external connectivity or addressing, and thus there is no multi-
homing overlap.
Triggers may be provider-initiated or customer-initiated.
Triggers and scenarios for IPv4 renumbering are discussed in RFC2071,
but many of these are no longer relevant, and in IPv6 some new
triggers exist, e.g. those related to network mobility or IPv6
transition tools.
3.1. Change of uplink prefix
One of the most common causes for renumbering will be a change in the
site's upstream provider. As per RFC3177 [10], the typical
allocation for an IPv6 site is a /48 size prefix taken from the
globally aggregated address space of the site's provider. With IPv6,
sites are highly unlikely to be able to obtain provider independent
(PI) address space, as have in some cases been obtained in the past
with IPv4. Rather, sites use provider assigned (PA) addressing. As
a result, if a site changes provider, it must also change its IPv6 PA
prefix.
3.1.1. Migration to new provider
In the simplest case, the customer is triggering the renumbering by
choosing to change the site's upstream provider to a new ISP and thus
a new PA IPv6 prefix range. This may simply be in the form of
selecting a new commercial provider, although there are several other
possible scenarios, such as changing from a dial-up to a broadband
connection, or moving from a community wireless connection to a fixed
broadband connection.
A similar scenario exists when a customer migrates to a different
service from the same provider. For example, if a customer changes
from a dialup to a broadband connection, they will likely be
connecting to a different part of the provider's topology, and
therefore receive a different address allocation.
3.1.2. Dial on Demand
A site may connect intermittently to its upstream provider. In such
cases the prefix allocated by the provider may change with each
connection, as it often does in the case of single IPv4 address
allocations to SOHO customers today. Thus the site may receive a
prefix still in its provider PA range, but the prefix may vary with
each connection, causing a renumbering event.
Dynamically assigned IP addresses are common today with dial-up and
Chown, et al. Expires March 22, 2007 [Page 6]
Internet-Draft Renumbering an IPv6 network September 2006
ISDN Internet connections, and to a lesser extent some broadband
products, particularly cable modems. Usually with dynamically
assigned IP addresses on broadband products, the address is only
likely to change when the customer reconnects, which could be very
infrequently.
This case can be mitigated by encouraging ISPs to offer static IPv6
prefixes to customers. Where /48 prefixes are provided, a large ISP
may be forced to require significantly more than the "default" /32
allocation from an RIR to an ISP to be able to service its present
and future customer base. With always-on more common in new
deployments, provider re-allocation should be less common; however
the practice of reallocating IPv4 addresses in SOHO broadband
networks is not uncommon in current broadband ISPs.
3.1.3. Provider migration and upstream renumbering
A site's upstream provider may need to renumber, due for example to a
change in its network topology or the need to migrate to a different
or additional prefix from its Regional Internet Registry (RIR). This
will in turn trigger the renumbering of the end site.
Such renumbering events would be expected to be rare, but it should
be noted that RIR-assigned IPv6 address space is not owned by an ISP.
3.1.4. IPv6 transition
During transition to IPv6, there are several scenarios where a site
may have to renumber. For example, if the site uses 6to4 for access
and its IPv4 address is dynamically assigned, an IPv6 renumbering
event will be triggered when the site's IPv4 address changes.
Another likely renumbering event would be the change of transition
mechanism, such as from 6to4 to a static IPv6-in-IPv4 tunnel, or from
any one of those mechanisms to a native IPv6 link. When changing
from 6to4 (2002::/16) addresses to native global aggregatable unicast
addresses, renumbering would be unavoidable. When migrating from a
tunnelled to a native connection, renumbering may not be necessary if
the same prefix can be routed natively, however this would be
provider-dependent.
In addition, there are likely to be many cases of network renumbering
occurring when the old 6bone prefix (3FFE::/16) is phased out as per
RFC3701 [11], and networks still using it will have to renumber.
Finally, there is at least one transition mechanism, ISATAP [12],
that uses specially crafted host EUI-64 format addresses. Should a
site migrate from ISATAP to use either conventional EUI-64 addressing
Chown, et al. Expires March 22, 2007 [Page 7]
Internet-Draft Renumbering an IPv6 network September 2006
(via stateless address autoconfiguration or perhaps DHCPv6), then
renumbering would be required at least in the host part of addresses.
It is also worth noting that nodes that use IPv6 Privacy Extensions
[13] will in effect renumber the host part of their address on a
frequent basis, in the case of one popular implementation on a daily
basis if the node remains on-link on the same network.
3.2. Change of internal topology
A site may need to renumber all or part of its internal network due
to a change of topology, such as creating more or less specific
subnets, or acquiring a larger IPv6 address allocation. Motivations
for splitting a link into separate subnets may be to meet security
demands on a particular link (policy for link-based access control
rules), or for link load management by shuffling popular services to
more appropriate locations in the local topology. Link-merging may
be due to department restructuring within the hosting organisation,
for example.
3.3. Acquisition or merger
Two networks may need to merge to one due to the acquisition or
merger of two organisations or companies. Such a reorganisation may
require one or more parts of the new network to renumber to the
primary PA IPv6 prefix.
3.4. Network growth
A site that is allocated a /48 prefix may grow to a size where it
needs to use a larger prefix for internal networking. Sites in the
early stages of IPv6 deployment may only request a /48, even if they
are likely to outgrow such a prefix in time. In such a case site-
wide renumbering may be required to utilise the new prefix if
organisational restructuring also happens due to the growth.
3.5. Network mobility
This covers various cases of network mobility, where a static or
nomadic network may obtain different uplink connectivity over time,
and thus be assigned different IPv6 PA prefixes as the topology
changes. One example is the "traditional" NEMO network [14], another
may be a community wireless network where different sets of nodes
gain uplink connectivity - typically to the same provider - at
different times.
Chown, et al. Expires March 22, 2007 [Page 8]
Internet-Draft Renumbering an IPv6 network September 2006
4. Renumbering Requirements
In this section we enumerate potential specific goals or requirements
for sites or users undergoing an IPv6 renumbering event.
4.1. Minimal disruption
The renumbering event should cause minimal disruption to the routine
operation of the network being renumbered, and the users of that
network.
Disruption is a difficult term to quantify in a generic way, but it
can be expressed by factors such as:
o Application sessions being terminated
o Security controls (e.g. ACLs) blocking access to legitimate
resources
o Unreachability of nodes or networks
o Name resolution, directory and configuration services providing
invalid (out-of-date) address data
o Limitation of network management visibility
These disruptive elements will be covered in situ as we discuss
protocol features and other renumbering considerations later in this
memo.
4.2. Session survivability
The concept of session survivability is catered for by [1] in that
new sessions adopt either old or new prefix based on the state of the
renumbering process, as discussed in Section 5.1. However, other
approaches to renumbering networks may be appropriate in certain
deployments, such as where "flag days" are unavoidable, such as where
two live prefixes are being "swapped". In these cases, further
consideration for existing sessions (their longevity, frequency,
independence across interactions, etc.) is required.
Some protocols are specifically geared to aid session survivability,
e.g. the Stream Control Transmission Protocol (SCTP) [15], and may
prove valuable in mission-critical renumbering scenarios, in
particular the extension that enables the dynamic addition and
removal of IP addresses from an SCTP endpoint association [16].
Sessions may be administratively maintained, such as NFS mounts for
Chown, et al. Expires March 22, 2007 [Page 9]
Internet-Draft Renumbering an IPv6 network September 2006
user filestore, or they may be user-driven, e.g. long-running ssh
sessions.
In general, it is important to consider how TCP and the applications
above it handle the connection failures that may result from a change
in address.
There are different classes of session duration, as described in the
following sections.
4.2.1. Short-term session survivability
A typical short-term session would involve a request-response
protocol, such as HTTP, where a new network connection is initiated
per transaction, or at worst for a small transaction set. In such
cases the migration to a new network prefix is transparent: the
client can use the new prefix in new transactions without
consequence. Some applications, however, may be skewed by such a
shift in connection source for the same entity 'user', for example
applications that use recent connection history as a cue to identity
(e.g. POP-before-SMTP as used by many dial-on-demand ISP customers
<http://popbsmtp.sourceforge.net/>), or for applications that care
about connection statistics (the same user web-browsing "session" may
be split into two where a renumbering event occurs in-between client
transactions).
4.2.2. Medium-term session survivability
A medium-term session is typified by an application or service that
may persist for perhaps a period of a few minutes up to a period of a
day or so. This might involve a TCP-based application that is left
running during a working day, such as an interactive shell (SSH) or a
large file download.
4.2.3. Long-term session survivability
Long term sessions may typically run for several days, if not weeks
or months. These might typically include TCP-based NFS mounts, or
long-running TCP applications. Sessions in this context may also
include those applications that, once started, do not re-resolve
names and so repeatedly open new connections or send new datagrams to
the same (as bound at time of initialisation) address throughout
their execution lifetime. Even if at API-level applications do
attempt to re-resolve the symbol to which they desire to connect, the
behaviour of the resolvers is unclear as to whether mappings are
refreshed from the naming service, and as such even if the
renumbering site does update its DNS (or NIS, LDAP database etc.),
the local result may indeed be cached without any indication passed
Chown, et al. Expires March 22, 2007 [Page 10]
Internet-Draft Renumbering an IPv6 network September 2006
back up to the application as to how 'old' said binding information
is.
4.2.4. "Sessions" in non-session based transports
UDP transport protocols, such as UDP-based NFS mounts, maintain the
status of a 'session' by keeping state at one or both ends of the
communication, but without a persistent open socket connection at the
network layer. If, due to node renumbering, one endpoint changes
address then that state becomes invalid and the 'session'
interrupted.
Note that some stack implementations do not correctly flag an error
to applications that attempt to send packets with an invalidated
source address, see section Section 9.5
IP addresses are also seen carried in higher-layer protocols, e.g.
application sessions, such as with FTP. Any application that makes
use of layer-3 address data as a unique end-point identifying token
may be disrupted by the address of the node changing to which that
token relates. This may not be an issue in cases where the token is
treated as abstract (i.e. literally just a token), however where
locator semantics are inferred, subsequent attempts to 'resolve' the
token to an address endpoint for communication, for example, will
fail.
5. IPv6 Protocol Features and their Effects on Renumbering
IPv6 includes a number of notable features that can help or hinder -
and sometimes both - renumbering episodes. This section discusses
these features and their associated effects for consideration when
undertaking network renumbering, both in terms of how they can be
used to ease the process, as well as potential pitfalls that should
be considered.
5.1. Multi-addressing
As per RFC3513 [17], IPv6 hosts may be multi-addressed. This means
that multiple unicast addresses can be assigned and active on the
same interface. These addresses can have different reachabilities
('scopes' such as link-local or global), different statuses including
'preferred' and 'deprecated', and may be ephemeral in nature (such as
care-of addresses when attached to a foreign network [18] or IPv6
Privacy addresses [13]). RFC3484 address selection semantics [5]
determine which of the "MxN" address pairs to use for communication
in the general case.
Chown, et al. Expires March 22, 2007 [Page 11]
Internet-Draft Renumbering an IPv6 network September 2006
During a renumbering episode, the addition of an extra address for an
endpoint increases the number of possible source-destination address
pairs for communications between nodes to use. The address selection
mechanisms specified by RFC3484 are currently at varying stages of
implementation in operating systems.
RFC3484 also specifies policy hooks to allow administrative override
of the default address selection behaviour, for example to
specifically prefer a source prefix for use with a set of particular
destinations. It is thought that this policy-based address selection
may be of benefit in renumbering events, or used in the development
of bespoke renumbering tools.
Multi-addressing also creates various issues with border filtering,
discussed in detail in Section 7.2.
5.2. Multi-homing techniques
A multi-homed site is a site which has multiple upstream providers.
A site may be multi-homed for various reasons, however the most
common are to provide redundancy in case of failure, to increase
bandwidth, and to provide more varied, optimal routes for certain
destinations.
In renumbering, multi-homing will either be a temporary state, during
the transition, or be a permanent feature of the network
configuration, which may be being altered during the renumbering.
5.2.1. Relevance of multi-homing to renumbering
As discussed in section 2, and in particular section 2.5, of [1],
during the 'without a flag day' renumbering procedure there will be a
period where both the old and the new prefixes are stable and valid
for the network. During such a period, the network may be multi-
homed, and as such many of the issues relating to multi-homing in
IPv6 are also relevant, albeit in a small capacity, to the
renumbering procedure. A stable multi-homed situation must therefore
be a requirement for renumbering without a 'flag day'.
In such a situation, however, the multi-homed state will not be
permanent, and will only exist for the duration for which it is
required, i.e. for the period during the renumbering procedure when
both prefixes should be valid.
Renumbering can also occur, however, in a network that is already
multi-homed, for example with redundant links to multiple providers.
Such a site may wish to renumber for any of the situations given in
the earlier section, as well as renumbering because of changes in the
Chown, et al. Expires March 22, 2007 [Page 12]
Internet-Draft Renumbering an IPv6 network September 2006
number of upstream providers. If at least one of the upstream links
remains unchanged during the renumbering, however, then these links
could be used exclusively for that period, alleviating some of the
issues with prefix changes. The stable link(s) could therefore be
the only prefixes advertised as valid for the 'stable state', with
the removal of the old prefix and introduction of the new prefix
being separate events.
Until the best practice for the multi-homing situation is defined,
however, its effect on renumbering is not a focus of this document.
5.2.2. Current situation with IPv6 multi-homing
Unlike IPv4 multi-homing, where PI address space is relatively easy
to obtain and thus a site can broadcast its own routing information,
most IPv6 addresses will be PA addresses and thus the site will have
no control over routing information. Multi-homing in IPv6 therefore
does not necessarily exist in the same way as in IPv4 and the
multi6 [38] working group was chartered to try to find a solution.
Most IPv6 multi-homing solutions fall into the categories of either
being host-centric, where it is the hosts that are multi-addressed,
and choose which addresses to use, or site-based, where it is the
site exit routers that decide which connections to use. The simplest
solutions are extensions of the current multi-addressing techniques,
but these suffer from the problem that, at some point, connections
using the old addresses will be broken.
The more advanced solutions [19], and in particular the solution
taken forward into the shim6 [39] working group, examine the
potential for splitting the 'identity' and 'location' features of IP,
currently both represented by the IP address, and connecting to a
host's identity, rather than its address, so that connections can
continue unhindered across renumbering events. Such solutions are,
however, very much in their infancy and as yet do not provide a
stable solution to this problem.
Support for the level of multi-homing required during a renumbering
exercise is, however, mostly provided by multi-addressing
(Section 5.1), since all that is primarily required is stable use of
either prefix for a given period. The core issue remains, however,
that at some point the connections using the old address will be
broken when the addresses are removed. The impact of this can be
limited as best as possible during the renumbering procedure.
5.3. Mobile IPv6
Mobile IPv6 (MIPv6) [18] specifies routing support to permit an IPv6
Chown, et al. Expires March 22, 2007 [Page 13]
Internet-Draft Renumbering an IPv6 network September 2006
host to continue using its "permanent" home address as it moves
around the Internet. Mobile IPv6 supports transparency above the IP
layer, including maintenance of active TCP connections and UDP port
bindings. There are a number of issues to take into account when
renumbering episodes occur where Mobile IPv6 is deployed:
Renumbering a network which has mobile IPv6 active is a potentially
complex issue to think about. In particular, can changed router
advertisements correctly reach the mobile nodes, and can they be
correctly renumbered, like a node on the local network? In addition,
an even more complex issue is what happens when the home agent
renumbers? Is it possible for the mobile nodes to be informed and
correctly renumber and continue, or will the link be irretrievably
broken?
5.3.1. Visited site renumbers when mobile
When a node is mobile and attached to a foreign network it, like any
other node on the link, is subject to prefix renumbering at that
site. Detecting a new prefix through the receipt of router
advertisements, the mobile node can then re-bind with its home agent
informing it of its care-of address - just as if it had detached from
the foreign network and migrated elsewhere. Where the node receives
forewarning of the renumbering episode, the Mobility specification
suggests that the node explicitly solicits an update of the prefix
information on its home network
5.3.2. Home site renumbers when mobile
When mobile, a host can still be contacted at its original (home)
address. Should the home network renumber whilst the node is away
but active (i.e. having bound to the home agent and registered a live
care-of address), then it can be informed of the new global routing
prefix used at the home site through the Mobile Prefix Solicitation
and Mobile Prefix Advertisement ICMPv6 messages (sections 6.7 and 6.8
of RFC3775 [18] respectively).
5.3.3. Home site renumbers when disconnected
Finally, if a mobile node is detached (i.e. no binding with the home
agent exists with the node present on a foreign network) and the home
network renumbers, the recommended procedure - documented as an
appendix to the mobility specification and therefore not necessarily
proven - is to fall back to alternative methods of 'rediscovering'
its home network, using the DNS to find the new global routing prefix
for the home network and therefore the Home Agent's subnet anycast
address, 'guessing' at what the node's new home address would be on
the basis of a 64 bit prefix and 64 bit interface identifier, and
Chown, et al. Expires March 22, 2007 [Page 14]
Internet-Draft Renumbering an IPv6 network September 2006
then attempting to perform registration to bind its new location.
5.4. Multicast
IPv6 supports an enriched model of multicast compared to IPv4 in that
there are well-defined scopes for multicast communication that are
readily expressed in the protocol's addressing architecture.
Multicast features much more prominently in the core specification,
for example it is the enabling technology for the Neighbour Discovery
protocol (a much more efficient approach to layer 2 address discovery
than compared to ARP with IPv4).
Where multicast is used to discover the availability of core services
(e.g. all DHCPv6 servers in a site will join FF05::1:3), the effect
of renumbering the unicast address of those services will mean that
the services are still readily discoverable without resorting to a
(bespoke or otherwise) service location protocol to continue to
function - particularly if (unicast) ULAs are not deployed locally as
per Section 5.5.
One issue related to IPv6 multicast and renumbering is the embedding
of unicast addresses into multicast addresses specified in RFC3306
[20] and the embedded-RP (Rendezvous Point) in RFC3956 [21].
The former is purely a way of assigning addresses that helps with
multicast address assignment, avoiding different sites from using the
same multicast addresses. If a site's unicast prefix changes, then
one will also need to change the multicast addresses. By way of
example, a site renumbering away from prefix 2001:DB8:BEEF::/48"
might have globally-scoped multicast addresses in use under the
prefix "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old
addresses for a while, but this should be avoided since another site
may inherit the prefix and they may end up using the same multicast
addresses.
The issue with embedded-RP is that, by definition, the RP address is
embedded. So if the RP address changes, then the group addresses
must also be changed. This may happen not only when a site is
renumbered, but also if a site is restructured or the RP is moved
within the site. The embedded address is used by routers to
determine the RP address. Applications must use new group addresses
once the RP is not available on the old address.
Another interesting topic is multicast source renumbering. With
traditional multicast a source should be able to start streaming from
a new address, and nodes belonging to the multicast group will
immediately start receiving. There might be some application issues
though. If sources are identified by the source address only, then
Chown, et al. Expires March 22, 2007 [Page 15]
Internet-Draft Renumbering an IPv6 network September 2006
this might appear as a new source to the receivers (as they would
where IPv6 Privacy addresses are used). Using RTP a receiver may
determine it's the same source.
With Source Specific Multicast (SSM), source renumbering is more
complicated since receivers must specify exactly which sources they
want to to receive from. This means that receivers must somehow be
told to join the new source addresses, and must be able to discover
those addresses.
5.5. Unique Local Addressing
Section 5 of [22] suggests that the use of Local IPv6 addresses in a
site results in making communication using these addresses
independent of renumbering a site's provider based global addresses.
It also points out that a renumbering episode is not triggered when
merging multiple sites that have deployed centrally assigned unique
local addresses[23] because the FC00::/7 ULA prefix assures global
uniqueness. The use of ULAs internally should ideally mitigate
against global address renumbering of nodes, particularly as intra-
site communication can continue unhindered by the change in global
address prefixes due to provider migration or re-assignment of prefix
from an upstream.
ULAs appear to lend themselves particularly well for long-lived
sessions (from the categorisation Section 4.2.3) whose nature is
intra-site, for example local filestore mounts over TCP-mounted NFS:
With clients using ULA source addresses to mount filestore using the
ULA of an NFS server, both client and server can have their global
routing prefix renumbered without consequence to ongoing local
connections.
When merging two sites that have both deployed FC00::/7 locally-
assigned ULA prefixes, the chance of collision is inherently small
given the pseudo-random global-ID determination algorithm of [22].
Consideration of possible collisions may be prudent however unlikely
the occurrence may be.
With reference to section 2 of [1], the adoption of ULA to assist in
network renumbering can be considered a 'seasoning' of Baker's
renumbering procedure: where interaction between local nodes and
their services cannot suffer the inherent issues observed when
migrating to a new aggregatable global unicast prefix, the use of
FC00::/7 unique local addresses may offer an appropriately stable and
reliable solution. Whilst on the surface, the use of ULAs in
networks that also have global connectivity appears straightforward
and of immediate benefit as regards provider migration, they
currently suffer significant operational issues including address
Chown, et al. Expires March 22, 2007 [Page 16]
Internet-Draft Renumbering an IPv6 network September 2006
selection, border filtering, name service provision and routing.
If addresses under a global routing prefix are deployed alongside
ULAs, then nodes will need to cater for being multi-addressed with
multiple addresses of the same (global) syntactic scope, e.g. follow
the principles laid out in RFC3484 [5]. The administrator should
ideally be able to set local policy such that nodes use ULAs for
intranet communications and global addresses for global Internet
communications. Note in particular that address selection policy
different from the defaults of RFC3484 are required for sites that
have deployed ULAs whilst making use of multicast in scopes greater
than link-scope (i.e. FFx3 and higher).
5.5.1. ULAs, Multicast and Address Selection
For ordinary unicast traffic, the address selection rules of RFC3484
will function correctly. Assuming no higher-precedence rules are
matched, a multi-addressed host will choose its source address
through finding the address with the longest matching prefix compared
with the destination address. This will pick global unicast
addresses (i.e. within 2000::/3) for communication with other such
addresses, and pick ULAs for other ULAs. This correct behaviour is
dependent on sites running two-face DNS, however, and therefore
ensuring remote sites do not know of non-routable ULAs.
The key problem with ULAs and source address selection occurs,
however, when sending to multicast addresses. When it falls to the
longest matching prefix tests, a ULA will always come out as
preferable to a global unicast address for matching a multicast
(FF00::/8) address.
This does not affect link-local multicast, however, as the preference
for the appropriate scope will choose the unicast link-local address
before looking at the longest prefix match (see Section 3.1 of
RFC3484). For scopes wider than link-local, however, the ULA will by
default always be chosen.
Local policy needs to be implemented such that, e.g., global-scope
multicast addresses have the same `label' as global aggregatable
unicast addresses in RFC3484 parlance. Additional rules could also
be added such that site- and organisational-scope multicast addresses
prefer ULAs as source addresses, again by defining an appropriate
label.
Whilst no standard policy distribution mechanism exists for
overriding default RFC3484 preference rules, [24] proposes the use of
a DHCPv6 option in sites where stateful configuration is available.
Chown, et al. Expires March 22, 2007 [Page 17]
Internet-Draft Renumbering an IPv6 network September 2006
5.5.2. ULAs with application-layer gateways
The use of ULAs may not necessarily be accompanied by provider-
assigned (PA) addresses in connected networks. If addresses under a
PA global routing prefix are not used, application layer gateway
deployment will be required for ULA-only nodes internal to the
network to communicate with external nodes that are not part of the
same ULA topology.
Destination nodes that are addressed under FC00::/7 which are not
part of the same administrative domain from which the ULA allocation
of the local node is made, nor part of a predetermined routing
agreement between two organisations utilising different ULAs for
nodes within their own sites, would be filtered at the site border as
usual.
Typical deployments utilising this technique would include those
networks where an administrative policy decision has been made to
restrict those services available to the users, or where connectivity
is sufficeintly intermittent that as few nodes as possible are
exposed to the issues of ephemeral connectivity.
5.6. Anycast addressing
Syntactically indistinguishable from unicast addresses, 'anycast'
offers nodes a mean to route traffic toward the topologically nearest
instance of a service (as represented by an IP address), relying on
the routing infrastructure to deliver appropriately. RFC2526 [25]
defines a set of reserved subnet anycast addresses within the highest
128 values of the 64 bit IID space. Of that space, currently only
three are used, of which one is actively used and is for discovery of
Mobile IPv6 Home-Agents. At the current time there are no 'global'
well-known anycast addresses assigned by IANA.
In order to participate using anycast, nodes need to be configured as
routers (to comply with RFC3513 [17]) and exchange routing
information about the reachability of the specific anycast address.
This extra level of administration requirement is negligible in the
context of services as the services themselves would need
configuration anyway.
There have been proposals to define globally well-known anycast
addresses for core services, such as the DNS [26]. Anycast scales
with regard subnet-anycast in the sense that the global routing
prefix used to direct packets to an anycast node within a site is no
different from any other host, and therefore nothing 'special' in the
global routing architecture is required - only locally within the
site does the multi-node nature of anycast need to be considered.
Chown, et al. Expires March 22, 2007 [Page 18]
Internet-Draft Renumbering an IPv6 network September 2006
However, for global well-known anycast addresses to be defined, host-
specific routes will need to be advertised and distributed throughout
the entire Internet. As acknowledged by section 2.6 of [17], this
presents a severe scaling limit and it is expected that support for
global anycast sets may be unavailable or very restricted. A good
discussion of best current practice for service provision using
anycast addressing can be found in [27].
The use of well-known anycast addresses would assist the renumbering
exercise by removing the requirement to change the addresses in the
configuration of such services. The use of anycast DNS would
alleviate concerns with ensuring node reconfiguration, for example
when using Stateless DHCPv6 (Section 6.1.2). While anycasting
datagram-based services such as DNS pose little problems, anycast
does not maintain state, and so it would not be guaranteed that
sequential TCP packets were to go to the same host. As discussed in
[28], responses from TCP sessions begun to an anycast address should
be sent from the unicast address, and future communication should
continue with this address. While this means that communication will
continue with the same unicast address, that address is subject to
the standard address deprecation and validity. Note that anycasting
of this form can be an alternative to site or organisational scope
multicast service discovery as described in Section 5.4.
6. Node Configuration Issues
This section discusses how IPv6 node configuration protocols (both
stateless and stateful, including DHCPv6, as well as ICMP router
renumbering messages) can be used to facilitate a renumbering event,
plus any complications caused by these processes, to which
consideration should be given.
6.1. Stateless Address Autoconfiguration
Many IPv6 networks are likely to be configured using Stateless
Address AutoConfiguration [6] (SLAAC), and in order to work through
the multi-staged process as documented by Baker [1], the new prefix
is introduced via router advertisements, and then the old prefix is
deprecated, and finally removed.
Initially the router advertisements will contain only the prefix of
the old network, then for a time they will contain both the old and
the new, but with a shorter (zero) lifetime on the old prefix to
indicate that it is deprecated. Finally the router advertisements
will contain only the new prefix.
Chown, et al. Expires March 22, 2007 [Page 19]
Internet-Draft Renumbering an IPv6 network September 2006
6.1.1. Router Advertisement Lifetimes
RFC2462 (IPv6 Stateless Autoconfiguration) [6] specifies the
technique for expiring assigned prefixes and then invalidating them,
such that a network has opportunity to gracefully withdraw a prefix
from service whilst not terminally disrupting on-going applications
that use addresses under it. Section 5.5.4 of RFC2462 in particular
details the procedure for deprecation and subsequent invalidation.
By mandating as a node requirement the ability to phase out addresses
assigned to an interface, network renumbering is readily facilitated:
subnet routers update the pre-existing prefix and mark them as
'deprecated' with a scheduled time for expiration and then advertise
(when appropriate) the new prefix that should be chosen for all
outgoing communications.
6.1.2. Stateless Configuration with DHCPv6
Sometimes, DHCPv6 will be used alongside SLAAC. SLAAC will provide
the address assignment, and DHCPv6 will provide additional host
configuration options, such as DNS servers. If any of the DHCPv6
options are directly related to the IPv6 addresses being renumbered,
then the configuration must be changed at the appropriate time during
the renumbering event, even though it itself does not handle the
address assignments.
Since the configuration is stateless, the DHCPv6 server will not know
which clients to contact to inform them to refresh. Clients of the
configuration protocol should poll the service to obtain potentially
updated ancillary data, such as suggested by [29]. It is proposed
that a new DHCPv6 service option is added to inform clients of an
upper bound for how long they should wait before re-requesting
service information.
6.1.3. Tokenised Interface Identifiers
IPv6 Stateless Address Auto-configuration (SLAAC) enables network
administrators to deploy devices in a network and have those devices
automatically generate global addresses without any administrative
intervention, and without the need for any stateful configuration
service such as DHCPv6.
However, certain services - such as HTTP, SMTP and IMAP - may better
benefit from having 'well known' identifiers that do not depend on
the physical hardware address of the server's network interface card,
e.g. <prefix>::53 for name servers.
Tokenised addresses offer a facility for administrators to specify
Chown, et al. Expires March 22, 2007 [Page 20]
Internet-Draft Renumbering an IPv6 network September 2006
the bottom 64 bits of an IPv6 address for a node whilst allowing the
top 64 bits (the network prefix) to be automatically configured from
router advertisements.
Currently, only more recent versions of Sun Microsytems' Solaris
operating system features ioctl-configured support for tokenised
interface identifiers, although recent work at Southampton has
demonstrated that the configuration technique can be introduced
trivially through simple kernel extensions in Linux.
As regards renumbering, automatically configured tokenised addresses,
where the network prefix component is learnt through router
advertisements, ease the renumbering process where administrators
have elected to use well known interface identifiers. Rather than
having to manually reconfigure the nodes with the new addresses, the
nodes can rely on automatic configuration techniques to pick up the
new prefix.
6.2. Stateful Configuration with DHCPv6
As opposed to stateless autoconfiguration, IPv6 stateful or managed
configuration can be achieved through the deployment of DHCPv6.
Section 18.1.8 of [30] details how a node should respond to the
receipt of stateful configuration data from a DHCPv6 server where the
lifetime indicated has expired (is zero). Section 19.4.1 details how
clients should respond to being instructed by DHCPv6 servers to
reconfigure (potentially forceful renumbering). Section 22.6 details
how prefix validity time is conveyed (c.f. the equivalent data in
SLAAC's Router Advertisement).
In order to renumber such a network, the DHCPv6 server should send
reconfigure messages to inform the clients that the configuration has
changed, and the clients should re-request configuration details from
the DHCPv6 server. This, of course, relies on the clients correctly
responding to such messages.
Where DHCPv6 has been employed, careful consideration about the
configuration of the service is required such that administrators can
be confident that clients will re-contact the service to refresh
their configuration data. As alluded to in sections 22.4 and 22.5 of
[30], the configurable timers that offer servers the ability to
control when clients re-contacts the server about its configuration
can be set such that clients rarely (if ever) connect to validate
their configuration set.
The approach described in [29] allows the lifetime of other
configuration information supplied by DHCPv6 to be ramped down in
preparation for a planned renumbering event.
Chown, et al. Expires March 22, 2007 [Page 21]
Internet-Draft Renumbering an IPv6 network September 2006
6.2.1. Prefix Delegation
Where stateless autoconfiguration enables hosts to request prefixes
from link-attached routers, prefix delegation enables routers to
request a prefix for advertising from superior routers, i.e. routers
closer to the top of the prefix hierarchy - typically topologically
closer, therefore, to the provider. Once the router has been
delegated prefix(es), it can begin advertising it to the connected
subnet (perhaps even multi-link) with indicators for hosts to use
stateful (DHCPv6) or stateless address autoconfiguration as per
RFC2461.
There have been two principal approaches to prefix delegation
proposed: HPD (Hierarchical Prefix Delegation for IPv6), which
proposed the use of bespoke ICMPv6 messages for prefix delegation,
and IPv6 Prefix Options for Dynamic Host Configuration Protocol [31],
which defines a DHCPv6 option type. Of the two approaches, the
DHCPv6-based approach has received wide support and is on the
standards track.
6.2.2. Source Address Selection Policy distribution
It has been proposed that DHCPv6 could also be used to distribute
source address selection policy to nodes [24]. The model proposes
that consumer edge router receives policies (e.g. from multiple ISPs
in the case of multi-homed networks) and re-distributes them to end
nodes. The end nodes then put them into their local policy table,
which leads to appropriate source address selection. Where the
design goal was a distribution mechanism in light of multi-homed
networks, the adoption of the technique for the multi-prefix states
of [1] during renumbering appears appropriate.
6.3. Router Renumbering
RFC2894 [7] defines a mechanism for renumbering IPv6 routers
throughout a network using a bespoke ICMP message type for
manipulating the set of prefixes deployed throughout subnets.
Through the use of prefix matching and a rudimentary algebra for bit-
wise manipulation of prefix data bound to router interfaces, the
mechanism enables administrators to affect every router within a
scope from a single administration workstation. One drawback of
RFC2894 is that it requires an enterprise-wide IPsec infrastructure
to be deployed to secure the ICMP messages in order to be compliant.
The approach utilises multicast communication to the all-routers
address, FF05::2, scoped to the entire 'site' as determined by router
filter policy to distribute configuration updates to all (compliant)
routers. The mechanism also works with more specific addressing
Chown, et al. Expires March 22, 2007 [Page 22]
Internet-Draft Renumbering an IPv6 network September 2006
modalities, such as link-local multicast (FF02::2) to reach all
routers on a specific link, or directed unicast to affect a specific
router instance. When surveying current implementations very few
IPv6 implementations bound their interfaces to the Site-wide All-
Routers multicast address (FF05::2), and fewer still have
implementations of RFC2894.
Example use cases cited in RFC2894 are for deploying global routing
prefixes across a hierarchical network where site-locals already
exist (presumably updated now to Unique Local Addresses), and for
renumbering from an existing prefix to another in a similar manner to
that proposed by Baker (i.e. the deployment of a new prefix alongside
the existing one, which is deprecated and subsequently expired and
removed - using the same mechanism described).
The specification was developed before the shift in recommendation
away from the Top-, Next- at Site-Level Aggregation Identifier
address allocation hierarchy of RFC3513, although the techniques
documented for renumbering the global routing prefix and subnet ID
components in the updated address allocation recommendations [17] are
not affected by the architectural change.
As with other prefix assignment techniques, it is the responsibility
of the node to correctly deprecate and then expire the use of a
previously assigned prefix as defined by the IPv6 Neighbour Discovery
protocol, RFC2461 [8], section 4.6.2 describing the Prefix
Information option in particular.
7. Administrative Considerations for Renumbering
This section is concerned with factors that affect the renumbering
procedure, from a network administration viewpoint. In particular,
this section discusses areas that a network administrator should
consider before undertaking a renumbering event, to ensure that it
proceeds smoothly. This includes considerations of event frequency,
scalability, and those relating to delays in information propagation.
7.1. Router Advertisement Lifetimes
As discussed in Section 6.1.1, IPv6 Stateless Autoconfiguration
allows the expiration of assigned prefixes. This process permits
existing sessions to continue while preferring a new prefix. It
should be noted, however, that there are some limitations in the
specification that have an impact in renumbering. In particular, it
is not possible to reduce a prefix's lifetime to below two hours if
it has previously been available at a longer validity. This
therefore emphasises the need to plan renumbering events in advance
Chown, et al. Expires March 22, 2007 [Page 23]
Internet-Draft Renumbering an IPv6 network September 2006
if at all possible, to reduce the lifetime as required, within these
limitations.
7.2. Border filtering
Multi-addressing (Section 5.1) allows multiple globally reachable
addresses to be assigned to node interfaces, but one administrative
caveat that arises is that of site border filtering. Not only is it
the norm for sites to filter at their border router traffic that is
not destined t | PAFTECH AB 2003-2026 | 2026-04-24 02:32:53 |