Network Working Group G. Van de Velde Request for Comments: 5375 C. Popoviciu Category: Informational Cisco Systems T. Chown University of Southampton O. Bonness C. Hahn T-Systems Enterpri Services GmbH December 2008 IPv6 Unicast Address Assignment Considerations
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights rerved.
This document is subject to BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents (trustee.ietf/
licen-info) in effect on the date of publication of this document. Plea review the documents carefully, as they describe your rights and restrictions with respect to this document.
Abstract
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of
IPv6. This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6
deployments. The document also provides IPv6 addressing ca studies for both an enterpri and an ISP network.
Van de Velde, et al. Informational [Page 1]
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network-Level Addressing Design Considerations . . . . . . . . 4 2.1. Globally Unique Address . . . . . . . . . . . . . . . . 4 2.2. Unique Local IPv6 Address . . . . . . . . . . . . . . . 5 2.
3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6 2.
4. Network-Level Design Considerations . . . . . . . . . . . 6 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conrvation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Ca Studies . . . . . . . . . . . . . . . . . . . . 16 A.1. Enterpri Considerations . . . . . . . . . . . . . . . . 16 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16 A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18 A.1.4. Node Configuration Considerations . . . . . . . . . . 18 A.2. Service Provider Considerations . . . . . . . . . . . . . 19 A.2.1. Investigation of Objective Requirements for an
IPv6 Addressing Schema of a Service Provider . . . . . 19 A.2.2. Exemplary IPv6 Address Allocation Plan for a
梦见别人杀蛇Service Provider . . . . . . . . . . . . . . . . . . . 23 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28 Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30 B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31 B.2.1. /126 Address . . . . . . . . . . . . . . . . . . . . 31 B.2.2. /127 Address . . . . . . . . . . . . . . . . . . . . 31 B.2.3. /128 Address . . . . . . . . . . . . . . . . . . . . 31 B.2.4. EUI-64 ’u’ and ’g’ Bits . . . . . . . . . . . . . . . 31 B.2.5. Anycast Address . . . . . . . . . . . . . . . . . . 32 B.2.6. Address Ud by Embedded-RP (RFC 3956) . . . . . . . 33 B.2.7. ISATAP Address . . . . . . . . . . . . . . . . . . . 34 Van de Velde, et al. Informational [Page 2]
1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture
[RFC4291] defines three main types of address: unicast, anycast,
and multicast. This document focus on unicast address, for which there are currently two principal allocated types: Globally Unique
Address (’globals’) [RFC3587] and Unique Local IPv6 Address
(ULAs) [RFC4193]. In addition, until recently there has been the
’experimental’ 6bone address space [RFC3701], though its u has been deprecated since June 2006 [RFC3701].
The document covers aspects that should be considered during IPv6
deployment for the design and planning of an addressing scheme for an IPv6 network. The network’s IPv6 addressing plan may be for an IPv6- only network, or for a dual-stack infrastructure where some or all
devices have address in both protocols. The considerations will help an IPv6 network designer to efficiently and prudently assign the IPv6 address space that has been allocated to their organization.
The address assignment considerations are analyzed parately for the two major components of the IPv6 unicast address -- namely,
’Network-Level Addressing’ (the allocation of subnets) and the
’interface-id’ (the identification of the interface within a subnet). Thus, the document includes a discussion of aspects of address
assignment to nodes and interfaces in an IPv6 network. Finally, the document provides two examples of deployed addressing plans in a
rvice provider (ISP) and an enterpri network.
Parts of this document highlight the differences that an experienced IPv4 network designer should consider when planning an IPv6
deployment, for example:
o IPv6 devices will more likely be multi-addresd in comparison
with their IPv4 counterparts.
o The practically unlimited size of an IPv6 subnet (2^64 bits)
毛巾降温的正确方法reduces the requirement to size subnets to device counts for the
purpos of (IPv4) address conrvation.
o The vastly incread subnet size has implications on the threat of address-bad host scanning and other scanning techniques, as
discusd in [RFC5157].
We do not discuss here how a site or ISP should proceed with
acquiring its globally routable IPv6 address prefix. In each ca,
the prefix received is either provider assigned (PA) or provider
independent (PI).
Van de Velde, et al. Informational [Page 3]
We do not discuss PI policy here. The obrvations and
recommendations of this text are largely independent of the PA or PI nature of the address block being ud. At this time, we assume that when an IPv6 network changes provider, typically it will n
eed to
undergo a renumbering process, as described in [RFC4192]. A parate document [THINKABOUT] makes recommendations to ea the IPv6
renumbering process.
This document does not discuss implementation aspects related to the transition from the now obsoleted site-local address to ULAs. Some implementations know about site-local address even though they are deprecated, and do not know about ULAs even though they reprent
current specification. As a result, transitioning between the
types of address may cau difficulties.
2. Network-Level Addressing Design Considerations
This ction discuss the kind of IPv6 address ud at the network level for the IPv6 infrastructure. The kind of address that can be considered are Globally Unique Address and ULAs. We also comment
here on the deprecated 6bone address space.
2.1. Globally Unique Address
The most commonly ud unicast address will be Globally Unique
Address (’globals’). No significant considerations are necessary
if the organization has an address space assignment and a single
人生价值观prefix is deployed through a single upstream provider.
However, a multihomed site may deploy address from two or more
rvice-provider-assigned IPv6 address ranges. Here, the network
administrator must have awareness on where and how the ranges are
ud on the multihomed infrastructure environment. The nature of the usage of multiple prefixes may depend on the reason for multihoming
(e.g., resilience failover, load balancing, policy-bad routing, or multihoming during an IPv6 renumbering event). IPv6 introduces
improved support for multi-addresd hosts through the IPv6 default
address lection methods described in RFC 3484 [RFC3484]. A
multihomed host may thus have two or more address, one per prefix
(provider), and lect source and destination address to u as东北大秧歌曲
described in that RFC. However, multihoming also has some
睫毛膏怎么用
operational and administrative burdens besides choosing multiple
address per interface [RFC4218] [RFC4219].
Van de Velde, et al. Informational [Page 4]
2.2. Unique Local IPv6 Address
ULAs have replaced the originally conceived site-local address in
the IPv6 addressing architecture, for reasons described in [RFC3879]. ULAs improve on site-locals by offering a high probability of the
global uniqueness of the prefix ud, which can be beneficial when
there is (deliberate or accidental) leakage or when networks are
merged. ULAs are akin to the private address space [RFC1918]
assigned for IPv4 networks, except that in IPv6 networks we may
expect to e ULAs ud alongside global address, with ULAs ud
internally and globals ud externally. Thus, u of ULAs does not
imply u of NAT for IPv6.
The ULA address range allows network administrators to deploy IPv6
address on their network without asking for a globally unique
粉蔷薇registered IPv6 address range. A ULA prefix is 48 bits, i.e., a /48, the same as the currently recommended allocation for a site from the globally routable IPv6 address space [RFC3177].
A site that wishes to u ULAs can have (a) multiple /48 prefixes
(e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56 or /64). In all of the above cas, the ULAs can be randomly chon according to the principles specified in [RFC4193]. However, in ca (a) the u of randomly chon ULAs will provide suboptimal
aggregation capabilities.
ULAs provide the means to deploy a fixed addressing scheme that is
not affected by a change in rvice provider and the corresponding PA global address. Internal operation of the network is thus
unaffected during renumbering events. Nevertheless, this type of
address must be ud with caution.
A site using ULAs may or may not also deploy global address. In an isolated network, ULAs may be deployed on their own. In a connected network that also deploys global address, both may be deployed,
问候英语
such that hosts become multi-addresd (one global and one ULA), and the IPv6 default address lection algorithm will pick the
appropriate source and destination address to u, e.g., ULAs will be lected where both the source and destination hosts have ULAs.
Becau a ULA and a global site prefix are both /48 length, an
小白撑administrator can choo to u the same subnetting (and host
addressing) plan for both prefixes.
As an example of the problems ULAs may cau, when using IPv6
multicast within the network, the IPv6 default address lection
algorithm prefers the ULA as the source address for the IPv6
multicast streams. This is NOT a valid option when nding an IPv6
multicast stream to the IPv6 Internet for two reasons. For one,
Van de Velde, et al. Informational [Page 5]
