draft-ietf-v6ops-addcon-04.txt   draft-ietf-v6ops-addcon-05.txt 
Network Working Group G. Van de Velde IPv6 Operations G. Van de Velde
Internet-Draft C. Popoviciu Internet-Draft C. Popoviciu
Expires: December 22, 2007 Cisco Systems Intended status: Informational Cisco Systems
T. Chown Expires: December 24, 2007 T. Chown
University of Southampton University of Southampton
O. Bonness O. Bonness
C. Hahn C. Hahn
T-Systems Enterprise Services GmbH T-Systems Enterprise Services GmbH
June 20, 2007 June 22, 2007
IPv6 Unicast Address Assignment Considerations IPv6 Unicast Address Assignment Considerations
<draft-ietf-v6ops-addcon-04.txt> <draft-ietf-v6ops-addcon-05.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2007. This Internet-Draft will expire on December 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
One fundamental aspect of any IP communications infrastructure is its One fundamental aspect of any IP communications infrastructure is its
addressing plan. With its new address architecture and allocation addressing plan. With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network policies, the introduction of IPv6 into a network means that network
skipping to change at page 3, line 36 skipping to change at page 3, line 36
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 14 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 14
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 14 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 14
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14 4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 17
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 18 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 17
A.1.1. Obtaining general IPv6 network prefixes . . . . . . . 18 A.1.1. Obtaining general IPv6 network prefixes . . . . . . . 18
A.1.2. Forming an address (subnet) allocation plan . . . . . 19 A.1.2. Forming an address (subnet) allocation plan . . . . . 18
A.1.3. Other considerations . . . . . . . . . . . . . . . . . 19 A.1.3. Other considerations . . . . . . . . . . . . . . . . . 19
A.1.4. Node configuration considerations . . . . . . . . . . 20 A.1.4. Node configuration considerations . . . . . . . . . . 20
A.2. Service Provider Considerations . . . . . . . . . . . . . 21 A.2. Service Provider Considerations . . . . . . . . . . . . . 20
A.2.1. Investigation of objective Requirements for an A.2.1. Investigation of objective Requirements for an
IPv6 addressing schema of a Service Provider . . . . 21 IPv6 addressing schema of a Service Provider . . . . 21
A.2.2. Exemplary IPv6 address allocation plan for a A.2.2. Exemplary IPv6 address allocation plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 24 Service Provider . . . . . . . . . . . . . . . . . . . 24
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
The Internet Protocol Version 6 (IPv6) Addressing Architecture [26] The Internet Protocol Version 6 (IPv6) Addressing Architecture [26]
defines three main types of addresses: unicast, anycast and defines three main types of addresses: unicast, anycast and
multicast. This document focuses on unicast addresses, for which multicast. This document focuses on unicast addresses, for which
there are currently two principal allocated types: Global Unique there are currently two principal allocated types: Global Unique
Addresses [14] ('globals') and Unique Local IPv6 Addresses [24] Addresses [14] ('globals') and Unique Local IPv6 Addresses [22]
(ULAs). In addition until recently there has been 'experimental' (ULAs). In addition until recently there has been 'experimental'
6bone address space [3], though its use has been deprecated since 6bone address space [3], though its use has been deprecated since
June 2006 [17]. June 2006 [17].
The document covers aspects that should be considered during IPv6 The document covers aspects that should be considered during IPv6
deployment for the design and planning of an addressing scheme for an 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- 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 only network, or for a dual-stack infrastructure where some or all
devices have addresses in both protocols. These considerations will devices have addresses in both protocols. These considerations will
help an IPv6 network designer to efficiently and prudently assign the help an IPv6 network designer to efficiently and prudently assign the
skipping to change at page 5, line 9 skipping to change at page 5, line 9
We do not discuss here how a site or ISP should proceed with We do not discuss here how a site or ISP should proceed with
acquiring its globally routable IPv6 address prefix. In each case acquiring its globally routable IPv6 address prefix. In each case
the prefix received is provider assigned (PA) or provider independent the prefix received is provider assigned (PA) or provider independent
(PI). (PI).
We do not discuss PI policy here. The observations and We do not discuss PI policy here. The observations and
recommendations of this text are largely independent of the PA or PI recommendations of this text are largely independent of the PA or PI
nature of the address block being used. At this time we assume that nature of the address block being used. At this time we assume that
most commonly an IPv6 network which changes provider will need to most commonly an IPv6 network which changes provider will need to
undergo a renumbering process, as described in [23]. A separate undergo a renumbering process, as described in [21]. A separate
document [32] makes recommendations to ease the IPv6 renumbering document [32] makes recommendations to ease the IPv6 renumbering
process. process.
This document does not discuss implementation aspects related to the This document does not discuss implementation aspects related to the
transition between the ULA addresses and the now obsoleted site-local transition between the ULA addresses and the now obsoleted site-local
addresses. Most implementations know about Site-local addresses even addresses. Most implementations know about Site-local addresses even
though they are deprecated, and do not know about ULAs - even though though they are deprecated, and do not know about ULAs - even though
they represent current specification. As result transitioning they represent current specification. As result transitioning
between these types of addresses may cause difficulties. between these types of addresses may cause difficulties.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
used on the multihomed infrastructure environment. The nature of the used on the multihomed infrastructure environment. The nature of the
usage of multiple prefixes may depend on the reason for multihoming usage of multiple prefixes may depend on the reason for multihoming
(e.g. resilience failover, load balancing, policy-based routing, or (e.g. resilience failover, load balancing, policy-based routing, or
multihoming during an IPv6 renumbering event). IPv6 introduces multihoming during an IPv6 renumbering event). IPv6 introduces
improved support for multi-addressed hosts through the IPv6 default improved support for multi-addressed hosts through the IPv6 default
address selection methods described in RFC3484 [12]. A multihomed address selection methods described in RFC3484 [12]. A multihomed
host may thus have two addresses, one per prefix (provider), and host may thus have two addresses, one per prefix (provider), and
select source and destination addresses to use as described in that select source and destination addresses to use as described in that
RFC. However multihoming also has some operative and administrative RFC. However multihoming also has some operative and administrative
burdens besides chosing multiple addresses per interface [33] burdens besides chosing multiple addresses per interface [33]
[34][35]. [25][24].
2.2. Unique Local IPv6 Addresses 2.2. Unique Local IPv6 Addresses
ULAs have replaced the originally conceived Site Local addresses in ULAs have replaced the originally conceived Site Local addresses in
the IPv6 addressing architecture, for reasons described in [19]. the IPv6 addressing architecture, for reasons described in [19].
ULAs improve on site locals by offering a high probability of the ULAs improve on site locals by offering a high probability of the
global uniqueness of the prefix used, which can be beneficial in the global uniqueness of the prefix used, which can be beneficial in the
case of (deliberate or accidental) leakage, or where networks are case of (deliberate or accidental) leakage, or where networks are
merged. ULAs are akin to the private address space [1] assigned for merged. ULAs are akin to the private address space [1] assigned for
IPv4 networks, except that in IPv6 networks we may expect to see ULAs IPv4 networks, except that in IPv6 networks we may expect to see ULAs
skipping to change at page 7, line 27 skipping to change at page 7, line 27
created before the existence of ULA addresses. created before the existence of ULA addresses.
2.3. 6Bone Address Space 2.3. 6Bone Address Space
The 6Bone address space was used before the RIRs started to The 6Bone address space was used before the RIRs started to
distribute 'production' IPv6 prefixes. The 6Bone prefixes have a distribute 'production' IPv6 prefixes. The 6Bone prefixes have a
common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address
range is deprecated as of 6th June 2006 [17] and must not be used on range is deprecated as of 6th June 2006 [17] and must not be used on
any new IPv6 network deployments. Sites using 6bone address space any new IPv6 network deployments. Sites using 6bone address space
should renumber to production address space using procedures as should renumber to production address space using procedures as
defined in [23]. defined in [21].
2.4. Network Level Design Considerations 2.4. Network Level Design Considerations
IPv6 provides network administrators with a significantly larger IPv6 provides network administrators with a significantly larger
address space, enabling them to be very creative in how they can address space, enabling them to be very creative in how they can
define logical and practical address plans. The subnetting of define logical and practical address plans. The subnetting of
assigned prefixes can be done based on various logical schemes that assigned prefixes can be done based on various logical schemes that
involve factors such as: involve factors such as:
o Using existing systems o Using existing systems
* translate the existing subnet number into IPv6 subnet id * translate the existing subnet number into IPv6 subnet id
skipping to change at page 8, line 48 skipping to change at page 8, line 48
if a /48 is allocated, act as though only a /56 is available. if a /48 is allocated, act as though only a /56 is available.
Clearly, this advice does not apply to large sites and enterprises Clearly, this advice does not apply to large sites and enterprises
that have an intrinsic need for a /48 prefix. that have an intrinsic need for a /48 prefix.
2.4.1. Sizing the Network Allocation 2.4.1. Sizing the Network Allocation
We do not discuss here how a network designer sizes their application We do not discuss here how a network designer sizes their application
for address space. By default a site will receive a /48 prefix [9] , for address space. By default a site will receive a /48 prefix [9] ,
however different RIR service regions policies may suggest however different RIR service regions policies may suggest
alternative default assignments or let the ISPs to decide on what alternative default assignments or let the ISPs to decide on what
they believe is more appropriate for their specific case [28]. The they believe is more appropriate for their specific case [29]. The
default provider allocation via the RIRs is currently a /32 [31]. default provider allocation via the RIRs is currently a /32 [31].
These allocations are indicators for a first allocation for a These allocations are indicators for a first allocation for a
network. Different sizes may be obtained based on the anticipated network. Different sizes may be obtained based on the anticipated
address usage [31]. There are examples of allocations as large as address usage [31]. There are examples of allocations as large as
/19 having been made from RIRs to providers at the time of writing. /19 having been made from RIRs to providers at the time of writing.
2.4.2. Address Space Conservation 2.4.2. Address Space Conservation
Despite the large IPv6 address space which enables easier subnetting, Despite the large IPv6 address space which enables easier subnetting,
it still is important to ensure an efficient use of this resource. it still is important to ensure an efficient use of this resource.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
Embedded-RP [20] reflects the concept of integrating the Rendezvous Embedded-RP [20] reflects the concept of integrating the Rendezvous
Point (RP) IPv6 address into the IPv6 multicast group address. Due Point (RP) IPv6 address into the IPv6 multicast group address. Due
to this embedding and the fact that the length of the IPv6 address to this embedding and the fact that the length of the IPv6 address
AND the IPv6 multicast address are 128 bits, it is not possible to AND the IPv6 multicast address are 128 bits, it is not possible to
have the complete IPv6 address of the multicast RP embedded as such. have the complete IPv6 address of the multicast RP embedded as such.
This resulted in a restriction of 15 possible RP-addresses per prefix This resulted in a restriction of 15 possible RP-addresses per prefix
that can be used with embedded-RP. The space assigned for the that can be used with embedded-RP. The space assigned for the
embedded-RP is based on the 4 low order bits, while the remainder of embedded-RP is based on the 4 low order bits, while the remainder of
the Interface ID is set to all '0'. the Interface ID [RIID] is set to all '0'.
[IPv6-prefix (64 bits)][60 bits all '0'][RIID] [IPv6-prefix (64 bits)][60 bits all '0'][RIID]
Where: [RIID] = 4 bit. Where: [RIID] = 4 bit.
This format implies that when selecting subnet prefixes longer then This format implies that when selecting subnet prefixes longer then
64, and the bits beyond the 64th one are non-zero, the subnet can not 64, and the bits beyond the 64th one are non-zero, the subnet can not
use embedded-RP. use embedded-RP.
In addition it is discouraged to assign a matching embedded-RP IPv6 In addition it is discouraged to assign a matching embedded-RP IPv6
address to a device that is not a real Multicast Rendezvous Point, address to a device that is not a real Multicast Rendezvous Point,
eventhough it would not generate major problems. eventhough it would not generate major problems.
3.3.3. ISATAP addresses 3.3.3. ISATAP addresses
ISATAP [25] is an experimental automatic tunneling protocol used to ISATAP [23] is an experimental automatic tunneling protocol used to
provide IPv6 connectivity over an IPv4 campus or enterprise provide IPv6 connectivity over an IPv4 campus or enterprise
environment. In order to leverage the underlying IPv4 environment. In order to leverage the underlying IPv4
infrastructure, the IPv6 addresses are constructed in a special infrastructure, the IPv6 addresses are constructed in a special
format. format.
An IPv6 ISATAP address has the IPv4 address embedded, based on a An IPv6 ISATAP address has the IPv4 address embedded, based on a
predefined structure policy that identifies them as an ISATAP predefined structure policy that identifies them as an ISATAP
address. address.
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
skipping to change at page 13, line 23 skipping to change at page 13, line 23
The 126 bit subnet prefixes are typically used for point-to-point The 126 bit subnet prefixes are typically used for point-to-point
links similar to a the IPv4 address conservative /30 allocation for links similar to a the IPv4 address conservative /30 allocation for
point-to-point links. The usage of this subnet address length does point-to-point links. The usage of this subnet address length does
not lead to any additional considerations other than the ones not lead to any additional considerations other than the ones
discussed earlier in this section, particularly those related to the discussed earlier in this section, particularly those related to the
"u" and "g" bits. "u" and "g" bits.
3.3.5. /127 addresses 3.3.5. /127 addresses
The usage of the /127 addresses is not valid and should be strongly The usage of the /127 addresses, the equivalent of IPv4's RFC3021 [5]
discouraged as documented in RFC3627 [15]. is not valid and should be strongly discouraged as documented in
RFC3627 [15].
3.3.6. /128 addresses 3.3.6. /128 addresses
The 128 bit address prefix may be used in those situations where we The 128 bit address prefix may be used in those situations where we
know that one, and only one address is sufficient. Example usage know that one, and only one address is sufficient. Example usage
would be the off-link loopback address of a network device. would be the off-link loopback address of a network device.
When choosing a 128 bit prefix, it is recommended to take the "u" and When choosing a 128 bit prefix, it is recommended to take the "u" and
"g" bits into consideration and to make sure that there is no overlap "g" bits into consideration and to make sure that there is no overlap
with either the following well-known addresses: with either the following well-known addresses:
skipping to change at page 16, line 42 skipping to change at page 16, line 42
[18] Droms, R., "Stateless Dynamic Host Configuration Protocol [18] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[19] Huitema, C. and B. Carpenter, "Deprecating Site Local [19] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[20] Savola, P. and B. Haberman, "Embedding the Rendezvous Point [20] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956, (RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004. November 2004.
[21] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [21] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[22] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[23] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day", RFC 4192, September 2005. an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[24] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[25] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- [23] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
October 2005. October 2005.
[24] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
Solutions", RFC 4218, October 2005.
[25] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
Should Think About", RFC 4219, October 2005.
[26] Hinden, R. and S. Deering, "IP Version 6 Addressing [26] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[27] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host [27] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
Issues", RFC 4477, May 2006. Issues", RFC 4477, May 2006.
[28] ARIN, "http://www.arin.net/policy/nrpm.html#six54". [28] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
Edge Routers (6PE)", RFC 4798, February 2007.
[29] De Clerq, J., Ooms, D., Prevost, S., and F. Le Faucheur, [29] ARIN, "http://www.arin.net/policy/nrpm.html#six54".
"Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider
Edge Routers (6PE) (draft-ooms-v6ops-bgp-tunnel-06.txt)",
June 2006.
[30] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning [30] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning
(draft-ietf-v6ops-scanning-implications-00.txt)", June 2006. (draft-ietf-v6ops-scanning-implications-03.txt)", March 2007.
[31] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment [31] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment
Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003. Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003.
[32] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to [32] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to
think about when Renumbering an IPv6 network think about when Renumbering an IPv6 network
(draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007. (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007.
[33] "List of Internet-Drafts relevant to the Multi6-WG [33] "List of Internet-Drafts relevant to the Multi6-WG
(http://ops.ietf.org/multi6/draft-list.html )". (http://ops.ietf.org/multi6/draft-list.html )".
[34] Lear, E., "Things MULTI6 Developers should think about
(draft-ietf-multi6-things-to-think-about-01)", January 2005.
[35] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
solutions (draft-ietf-multi6-multihoming-threats-03)",
January 2005.
Appendix A. Case Studies Appendix A. Case Studies
This appendix contains two case studies for IPv6 addressing schemas This appendix contains two case studies for IPv6 addressing schemas
that have been based on the statements and considerations of this that have been based on the statements and considerations of this
draft. These case studies illustrate how this draft has been used in draft. These case studies illustrate how this draft has been used in
two specific network scenarios. The case studies may serve as basic two specific network scenarios. The case studies may serve as basic
considerations for an administrator who designs the IPv6 addressing considerations for an administrator who designs the IPv6 addressing
schema for an enterprise or ISP network, but are not intended to schema for an enterprise or ISP network, but are not intended to
serve as general design proposal for every kind of IPv6 network. serve as general design proposal for every kind of IPv6 network.
skipping to change at page 18, line 11 skipping to change at page 18, line 4
considerations for an administrator who designs the IPv6 addressing considerations for an administrator who designs the IPv6 addressing
schema for an enterprise or ISP network, but are not intended to schema for an enterprise or ISP network, but are not intended to
serve as general design proposal for every kind of IPv6 network. serve as general design proposal for every kind of IPv6 network.
A.1. Enterprise Considerations A.1. Enterprise Considerations
In this section we consider a case study of a campus network that is In this section we consider a case study of a campus network that is
deploying IPv6 in parallel with existing IPv4 protocols in a dual- deploying IPv6 in parallel with existing IPv4 protocols in a dual-
stack environment. The specific example is the University of stack environment. The specific example is the University of
Southampton (UK), focusing on a large department within that network. Southampton (UK), focusing on a large department within that network.
The deployment currently spans around 1,000 hosts and over 1,500 The deployment currently spans around 1,000 hosts and over 1,500
users. users.
A.1.1. Obtaining general IPv6 network prefixes A.1.1. Obtaining general IPv6 network prefixes
In the case of a campus network, the site will typically take its In the case of a campus network, the site will typically take its
connectivity from its National Research and Education Network (NREN). connectivity from its National Research and Education Network (NREN).
Southampton connects to JANET, the UK academic network, via its local Southampton connects to JANET, the UK academic network, via its local
regional network LeNSE. JANET currently has a /32 allocation from regional network LeNSE. JANET currently has a /32 allocation from
RIPE of 2001:630::/32. The current recommended practice is for sites RIPE NCC. The current recommended practice is for sites to receive a
to receive a /48 allocation, and on this basis Southampton has /48 allocation, and on this basis Southampton has received such a
received such a prefix for its own use, specifically 2001:630: prefix for its own use. The regional network also uses its own
d0::/48. The regional network also uses its own allocation from the allocation from the NREN provider.
NREN provider.
No ULA addressing is used on site. The campus is not multihomed No ULA addressing is used on site. The campus is not multihomed
(JANET is the sole provider), nor does it expect to change service (JANET is the sole provider), nor does it expect to change service
provider, and thus does not plan to use ULAs for the (perceived) provider, and thus does not plan to use ULAs for the (perceived)
benefit of easing network renumbering. Indeed, the campus has benefit of easing network renumbering. Indeed, the campus has
renumbered following the aforementioned renumbering procedure [23] on renumbered following the aforementioned renumbering procedure [21] on
two occasions, and this has proven adequate (with provisos documented two occasions, and this has proven adequate (with provisos documented
in [32]. We also do not see any need to deploy ULAs for in or out of in [32]. We also do not see any need to deploy ULAs for in or out of
band network management; there are enough IPv6 prefixes available in band network management; there are enough IPv6 prefixes available in
the site allocation for the infrastructure. In some cases, use of the site allocation for the infrastructure. In some cases, use of
private IP address space in IPv4 creates problems, so we believe that private IP address space in IPv4 creates problems, so we believe that
the availability of ample global IPv6 address space for the availability of ample global IPv6 address space for
infrastructure may be a benefit for many sites. infrastructure may be a benefit for many sites.
No 6bone addressing is used on site any more. We note that since the No 6bone addressing is used on site any more. We note that since the
6bone phaseout of June 2006 [17] most transit ISPs have begun 6bone phaseout of June 2006 [17] most transit ISPs have begun
skipping to change at page 20, line 5 skipping to change at page 19, line 46
the network infrastructure and the server side systems. the network infrastructure and the server side systems.
A.1.3. Other considerations A.1.3. Other considerations
The network uses a Demilitarized Zone (DMZ) topology for some level The network uses a Demilitarized Zone (DMZ) topology for some level
of protection of 'public' systems. Again, this topology is congruent of protection of 'public' systems. Again, this topology is congruent
with the IPv4 network. with the IPv4 network.
There are no specific transition methods deployed internally to the There are no specific transition methods deployed internally to the
campus; everything is using the conventional dual-stack approach. campus; everything is using the conventional dual-stack approach.
There is no use of ISATAP [25] for example. There is no use of ISATAP [23] for example.
For the Mobile IPv6 early trials, we have allocated one prefix for For the Mobile IPv6 early trials, we have allocated one prefix for
Home Agent (HA) use. We have not yet considered in detail how Mobile Home Agent (HA) use. We have not yet considered in detail how Mobile
IPv6 usage may grow, and whether more or even every subnet will IPv6 usage may grow, and whether more or even every subnet will
require HA support. require HA support.
The university operates a tunnel broker [7] service on behalf of The university operates a tunnel broker [7] service on behalf of
UKERNA for JANET sites. This uses separate address space from JANET, UKERNA for JANET sites. This uses separate address space from JANET,
not our university site allocation. not our university site allocation.
skipping to change at page 24, line 25 skipping to change at page 24, line 20
well as to allow future growing rates (e.g. of customer well as to allow future growing rates (e.g. of customer
aggregates) and possible topological or infrastructural changes. aggregates) and possible topological or infrastructural changes.
o A limited number of aggregation levels and sizes of customer o A limited number of aggregation levels and sizes of customer
aggregates will ease the management of the addressing schema. aggregates will ease the management of the addressing schema.
This has to be weighed against the previous "thumb rule" - This has to be weighed against the previous "thumb rule" -
flexibility. flexibility.
A.2.2. Exemplary IPv6 address allocation plan for a Service Provider A.2.2. Exemplary IPv6 address allocation plan for a Service Provider
In this example, the Service Provider is assumed to operate an MPLS In this example, the Service Provider is assumed to operate an MPLS
based backbone and implements 6PE [29] to provide IPv6 backbone based backbone and implements 6PE [28] to provide IPv6 backbone
transport between the different locations (POPs) of a fully dual- transport between the different locations (POPs) of a fully dual-
stacked network access and aggregation area. stacked network access and aggregation area.
Besides that it is assumed that the Service Provider: Besides that it is assumed that the Service Provider:
o has received a /20 from its RIR o has received a /20 from its RIR
o operates its own LIR o operates its own LIR
o has to address its own IPv6 infrastructure o has to address its own IPv6 infrastructure
o delegates prefixes from this aggregate to its customers o delegates prefixes from this aggregate to its customers
This addressing schema should illustrate how the /20 IPv6 prefix of This addressing schema should illustrate how the /20 IPv6 prefix of
 End of changes. 29 change blocks. 
48 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/