draft-ietf-v6ops-nap-03.txt   draft-ietf-v6ops-nap-04.txt 
Network Working Group G. Van de Velde Network Working Group G. Van de Velde
Internet-Draft T. Hain Internet-Draft T. Hain
Expires: January 1, 2007 R. Droms Intended status: Informational R. Droms
Cisco Systems Expires: April 16, 2007 Cisco Systems
B. Carpenter B. Carpenter
IBM Corporation IBM
E. Klein E. Klein
Tel Aviv University Tel Aviv University
June 30, 2006 October 13, 2006
IPv6 Network Architecture Protection Network Architecture Protection for IPv6
<draft-ietf-v6ops-nap-03.txt> <draft-ietf-v6ops-nap-04.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 January 1, 2007. This Internet-Draft will expire on April 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Although there are many perceived benefits to Network Address Although there are many perceived benefits to Network Address
Translation (NAT), its primary benefit of "amplifying" available Translation (NAT), its primary benefit of "amplifying" available
address space is not needed in IPv6. In addition to NAT's many address space is not needed in IPv6. In addition to NAT's many
serious disadvantages, there is a perception that other benefits serious disadvantages, there is a perception that other benefits
exist, such as a variety of management and security attributes that exist, such as a variety of management and security attributes that
could be useful for an Internet Protocol site. IPv6 does not support could be useful for an Internet Protocol site. IPv6 does not support
NAT by design and this document shows how Network Architecture NAT by design and this document shows how Network Architecture
Protection (NAP) using IPv6 can provide the same or more benefits Protection (NAP6) using IPv6 can provide the same or more benefits
without the need for address translation. without the need for address translation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7
2.1. Simple Gateway between Internet and Private Network . . . 7 2.1. Simple Gateway between Internet and Private Network . . . 7
2.2. Simple Security due to Stateful Filter Implementation . . 7 2.2. Simple Security due to Stateful Filter Implementation . . 7
2.3. User/Application tracking . . . . . . . . . . . . . . . . 8 2.3. User/Application tracking . . . . . . . . . . . . . . . . 8
2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9
2.5. Independent Control of Addressing in a Private Network . 10 2.5. Independent Control of Addressing in a Private Network . . 10
2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10
2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11
3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 12 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 12
3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12
3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13
3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14
3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14
4. Using IPv6 Technology to Provide the Market Perceived 4. Using IPv6 Technology to Provide the Market Perceived
Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14 Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Simple Gateway between Internet and Internal Network . . . 14 4.1. Simple Gateway between Internet and Internal Network . . . 15
4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 18
4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 18
4.5. Independent Control of Addressing in a Private Network . 20 4.5. Independent Control of Addressing in a Private Network . . 21
4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 21
4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 22
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Medium/large private networks . . . . . . . . . . . . . . 22 5.1. Medium/large private networks . . . . . . . . . . . . . . 23
5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 24
5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 26
5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 27
6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27 6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 28
6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 27 6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 28
6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 27 6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 28
6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Additional Benefits due to Native IPv6 and Appendix A. Additional Benefits due to Native IPv6 and
Universal Unique Addressing . . . . . . . . . . . . 31 Universal Unique Addressing . . . . . . . . . . . . . 32
A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 31 A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 32
A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 31 A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 33
A.3. Native Multicast Services . . . . . . . . . . . . . . . . 32 A.3. Native Multicast Services . . . . . . . . . . . . . . . . 33
A.4. Increased Security Protection . . . . . . . . . . . . . . 32 A.4. Increased Security Protection . . . . . . . . . . . . . . 33
A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 33 A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 34
A.7. Community of interest . . . . . . . . . . . . . . . . . . 33 Appendix B. Revision history . . . . . . . . . . . . . . . . . . 35
Appendix B. Revision history . . . . . . . . . . . . . . . . . . 34
B.1. Changes from *-vandevelde-v6ops-nap-00 to B.1. Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 34 *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 35
B.2. Changes from *-vandevelde-v6ops-nap-01 to B.2. Changes from *-vandevelde-v6ops-nap-01 to
*-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 34 *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 35
B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 34 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 35
B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 34 B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 35
B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38 B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 B.6. Changes from *-ietf-v6ops-nap-03 to *-ietf-v6ops-nap-04 . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
There have been periodic claims that IPv6 will require a Network There have been periodic claims that IPv6 will require a Network
Address Translation (NAT), because in IPv4 people use NAT to Address Translation (NAT), because with IPv4 people use NAT to
accomplish that person's preferred task. This document will explain accomplish that person's preferred task. This document will explain
why those pronouncements are false by showing how to accomplish the why those pronouncements are false by showing how to accomplish the
task goal without address translation. Although there are many task goal without address translation. Although there are many
perceived benefits to NAT, its primary benefit of "amplifying" perceived benefits to NAT, its primary benefit of "amplifying"
available address space is not needed in IPv6. The serious available address space is not needed in IPv6. The serious
disadvantages and impact on applications by ambiguous address space disadvantages and impact on applications by ambiguous address space
and Network Address Translation [1] [5] have been well documented [4] and Network Address Translation [1] [5] have been well documented [4]
[6] so there will not be much additional discussion here. However, [6] so there will not be much additional discussion here. However,
given its wide deployment NAT undoubtedly has some perceived given its wide deployment NAT undoubtedly has some perceived
benefits, though the bulk of those using it have not evaluated the benefits, though the bulk of those using it have not evaluated the
technical trade-offs. Indeed, product marketing departments have technical trade-offs. Indeed, it is often claimed that some
effectively driven a perception that some connectivity and security connectivity and security concerns can only be solved by using a NAT
concerns can only be solved by using a NAT device, without any device, without any mention of the negative impacts on applications.
mention of the negative impacts on applications. This is amplified This is amplified through the widespread sharing of vendor best
through the widespread sharing of vendor best practice documents and practice documents and sample configurations that do not
sample configurations that do not differentiate the translation differentiate the translation function of address expansion from the
function of address expansion from the state function of limiting state function of limiting connectivity.
connectivity.
This document describes the goals for utilizing a NAT device in an This document describes the goals for utilizing a NAT device in an
IPv4 environment that are regularly cited as solutions for perceived IPv4 environment that are regularly cited as solutions for perceived
problems. It then shows how these needs can be met without using the problems. It then shows how these needs can be met without using the
header modification feature of NAT in an IPv6 network. It should be header modification feature of NAT in an IPv6 network. It should be
noted that this document is 'informational', as it discusses noted that this document is 'informational', as it discusses
approaches that will work to accomplish the goals. It is approaches that will work to accomplish the goals. It is
specifically not a BCP that is recommending any one approach. specifically not a BCP that is recommending any one approach.
As far as security and privacy are concerned, this document considers As far as security and privacy are concerned, this document considers
skipping to change at page 5, line 20 skipping to change at page 5, line 20
solves a set of problems solves a set of problems
4. and the ability to have addresses that are not publicly routed 4. and the ability to have addresses that are not publicly routed
solves yet another set (mostly changes where the state is and solves yet another set (mostly changes where the state is and
scale requirements for the first one). scale requirements for the first one).
This document describes several techniques that may be combined in an This document describes several techniques that may be combined in an
IPv6 deployment to protect the integrity of its network architecture. IPv6 deployment to protect the integrity of its network architecture.
It will focus on the 'how to accomplish a goal' perspective, leaving It will focus on the 'how to accomplish a goal' perspective, leaving
most of the 'why that goal' perspective for other documents. These most of the 'why that goal' perspective for other documents. These
techniques, known collectively as Network Architecture Protection techniques, known collectively as Network Architecture Protection
(NAP), retain the concept of a well defined boundary between "inside" (NAP6), retain the concept of a well defined boundary between
and "outside" the private network, and allow firewalling, topology "inside" and "outside" the private network, and allow firewalling,
hiding, and privacy. NAP will achieve these security goals without topology hiding, and privacy. NAP6 will achieve these security goals
address translation whilst regaining the ability for arbitrary any- without address translation whilst regaining the ability for
to-any connectivity. arbitrary any-to-any connectivity.
IPv6 Network Architecture Protection can be summarized in the IPv6 Network Architecture Protection can be summarized in the
following table. It presents the marketed "benefits" of IPv4+NAT following table. It presents the marketed "benefits" of IPv4+NAT
with a cross-reference of how those are delivered in both the IPv4 with a cross-reference of how those are delivered in both the IPv4
and IPv6 environments. and IPv6 environments.
Goal IPv4 IPv6 Goal IPv4 IPv6
+------------------+-----------------------+-----------------------+ +------------------+-----------------------+-----------------------+
| Simple Gateway | DHCP - single | DHCP-PD - arbitrary | | Simple Gateway | DHCP - single | DHCP-PD - arbitrary |
| as default router| address upstream | length customer | | as default router| address upstream | length customer |
skipping to change at page 6, line 50 skipping to change at page 6, line 50
| | see section 2.6 | see section 4.6 | | | see section 2.6 | see section 4.6 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Renumbering and | Address translation | Preferred lifetime | | Renumbering and | Address translation | Preferred lifetime |
| Multi-homing | at border | per prefix & Multiple| | Multi-homing | at border | per prefix & Multiple|
| | | addresses per | | | | addresses per |
| | | interface | | | | interface |
| | see section 2.7 | see section 4.7 | | | see section 2.7 | see section 4.7 |
+------------------+-----------------------+-----------------------+ +------------------+-----------------------+-----------------------+
This document first identifies the perceived benefits of NAT in more This document first identifies the perceived benefits of NAT in more
detail, and then shows how IPv6 NAP can provide each of them. It detail, and then shows how IPv6 NAP6 can provide each of them. It
concludes with a IPv6 NAP case study and a gap analysis of work that concludes with a IPv6 NAP6 case study and a gap analysis of work that
remains to be done for a complete NAP solution. remains to be done for a complete NAP6 solution.
2. Perceived Benefits of NAT and its Impact on IPv4 2. Perceived Benefits of NAT and its Impact on IPv4
This section provides insight into the generally perceived benefits This section provides insight into the generally perceived benefits
of the use of IPv4 NAT. The goal of this description is not to of the use of IPv4 NAT. The goal of this description is not to
analyze these benefits or the accuracy of the perception (detailed analyze these benefits or the accuracy of the perception (detailed
discussions in [4]), but to describe the deployment requirements and discussions in [4]), but to describe the deployment requirements and
set a context for the later descriptions of the IPv6 approaches for set a context for the later descriptions of the IPv6 approaches for
dealing with those requirements. dealing with those requirements.
2.1. Simple Gateway between Internet and Private Network 2.1. Simple Gateway between Internet and Private Network
A NAT device can connect a private network with addresses allocated A NAT device can connect a private network with addresses allocated
from any part of the space (ambiguous [RFC 1918] or global registered from any part of the space (ambiguous [1] or global registered &
& unregistered address) towards the Internet, though extra effort is unregistered address) towards the Internet, though extra effort is
needed when the same range exists on both sides of the NAT. The needed when the same range exists on both sides of the NAT. The
address space of the private network can be built from globally address space of the private network can be built from globally
unique addresses, from ambiguous address space or from both unique addresses, from ambiguous address space or from both
simultaneously. In the simple case of private use addresses, without simultaneously. In the simple case of private use addresses, without
needing specific configuration the NAT device enables access between needing specific configuration the NAT device enables access between
the client side of a distributed client-server application in the the client side of a distributed client-server application in the
private network and the server side located in the public Internet. private network and the server side located in the public Internet.
Wide-scale deployments have shown that using NAT to act as a simple Wide-scale deployments have shown that using NAT to act as a simple
gateway attaching a private IPv4 network to the Internet is simple gateway attaching a private IPv4 network to the Internet is simple
skipping to change at page 10, line 25 skipping to change at page 10, line 25
their private network, and at the same time reduce their need for their private network, and at the same time reduce their need for
globally routable addresses. This type of local control of address globally routable addresses. This type of local control of address
resources allows a sufficiently large pool for a clean and resources allows a sufficiently large pool for a clean and
hierarchical addressing structure in the local network. hierarchical addressing structure in the local network.
Another benefit is due to the usage of independent addresses on Another benefit is due to the usage of independent addresses on
majority of the network infrastructure there is an increased ability majority of the network infrastructure there is an increased ability
to change provider with less operational difficulties. to change provider with less operational difficulties.
Section 2.7 describes some disadvantages that appear if independent Section 2.7 describes some disadvantages that appear if independent
networks using [RFC1918] addresses have to be merged. networks using ambiguous addresses [1]have to be merged.
2.6. Global Address Pool Conservation 2.6. Global Address Pool Conservation
While the widespread use of IPv4+NAT has reduced the potential While the widespread use of IPv4+NAT has reduced the potential
consumption rate, the ongoing depletion of the IPv4 address range has consumption rate, the ongoing depletion of the IPv4 address range has
already taken the remaining pool of unallocated IPv4 addresses below already taken the remaining pool of unallocated IPv4 addresses below
25%. While mathematical models based on historical IPv4 prefix 25%. While mathematical models based on historical IPv4 prefix
consumption periodically attempt to predict the future exhaustion consumption periodically attempt to predict the future exhaustion
date of the IPv4 address pool, a direct result of this continuous date of the IPv4 address pool, a direct result of this continuous
resource consumption is that the administrative overhead for resource consumption is that the administrative overhead for
skipping to change at page 11, line 32 skipping to change at page 11, line 32
Allowing a network to be multihomed and renumbering a network are Allowing a network to be multihomed and renumbering a network are
quite different functions. However these are argued together as quite different functions. However these are argued together as
reasons for using NAT, because making a network multihomed is often a reasons for using NAT, because making a network multihomed is often a
transitional state required as part of network renumbering, and NAT transitional state required as part of network renumbering, and NAT
interacts with both in the same way. interacts with both in the same way.
For enterprise networks, it is highly desirable to provide resiliency For enterprise networks, it is highly desirable to provide resiliency
and load-balancing to be connected to more than one Internet Service and load-balancing to be connected to more than one Internet Service
Provider (ISP) and to be able to change ISPs at will. This means Provider (ISP) and to be able to change ISPs at will. This means
that a site must be able to operate under more than one CIDR prefix that a site must be able to operate under more than one CIDR prefix
[15] and/or readily change its CIDR prefix. Unfortunately, IPv4 was [16]and/or readily change its CIDR prefix. Unfortunately, IPv4 was
not designed to facilitate either of these maneuvers. However, if a not designed to facilitate either of these maneuvers. However, if a
site is connected to its ISPs via NAT boxes, only those boxes need to site is connected to its ISPs via NAT boxes, only those boxes need to
deal with multihoming and renumbering issues. deal with multihoming and renumbering issues.
Similarly, if two enterprise IPv4 networks need to be merged and Similarly, if two enterprise IPv4 networks need to be merged and
RFC1918 addresses are used, there is a high probability of address RFC1918 addresses are used, there is a high probability of address
overlaps. In those situations it may well be that installing a NAT overlaps. In those situations it may well be that installing a NAT
box between them will avoid the need to renumber one or both. For box between them will avoid the need to renumber one or both. For
any enterprise, this can be a short term financial saving, and allow any enterprise, this can be a short term financial saving, and allow
more time to renumber the network components. The long term solution more time to renumber the network components. The long term solution
is a single network without usage of NAT to avoid the ongoing is a single network without usage of NAT to avoid the ongoing
operational complexity of overlapping addresses. operational complexity of overlapping addresses.
The addition of an extra NAT as a solution may be sufficient for some The addition of an extra NAT as a solution may be sufficient for some
networks; however when the merging networks were already using networks; however when the merging networks were already using
address translation it will create huge problems due to address translation it will create major problems due to
administrative difficulties of overlapping address spaces in the administrative difficulties of overlapping address spaces in the
merged networks. merged networks.
3. Description of the IPv6 Tools 3. Description of the IPv6 Tools
This section describes several features that can be used as part of This section describes several features that can be used as part of
the NAP solution to replace the protection features associated with the NAP6 solution to replace the protection features associated with
IPv4 NAT. IPv4 NAT.
The reader must clearly distinguish between features of IPv6 that The reader must clearly distinguish between features of IPv6 that
were fully defined when this document was drafted and those that were were fully defined when this document was drafted and those that were
potential features that still required more work to define them. The potential features that still required more work to define them. The
latter are summarized later in the 'Gap Analysis' section of this latter are summarized later in the 'Gap Analysis' section of this
document. However, we do not distinguish in this document between document. However, we do not distinguish in this document between
fully defined features of IPv6 and those that were already widely fully defined features of IPv6 and those that were already widely
implemented at the time of writing. implemented at the time of writing.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
minimizes DNS churn. A DHCP based deployment would also allow for minimizes DNS churn. A DHCP based deployment would also allow for
local policy to periodically change the entire collection of end local policy to periodically change the entire collection of end
device addresses while maintaining some degree of central knowledge device addresses while maintaining some degree of central knowledge
and control over which addresses should be in use at any point in and control over which addresses should be in use at any point in
time. time.
Randomizing the IID, as defined in RFC 3041, is effectively a sparse Randomizing the IID, as defined in RFC 3041, is effectively a sparse
allocation technique which only precludes tracking of the lower 64 allocation technique which only precludes tracking of the lower 64
bits of the IPv6 address. Masking of the subnet ID will require bits of the IPv6 address. Masking of the subnet ID will require
additional approaches as discussed below in 3.4. Additional additional approaches as discussed below in 3.4. Additional
considerations are discussed in [18]. considerations are discussed in [19].
3.2. Unique Local Addresses 3.2. Unique Local Addresses
Achieving the goal of autonomy, that many perceive as a value of NAT, Achieving the goal of autonomy, that many perceive as a value of NAT,
is required for local network and application services stability is required for local network and application services stability
during periods of intermittent connectivity or moving between one or during periods of intermittent connectivity or moving between one or
more providers. Such autonomy in a single routing prefix environment more providers. Such autonomy in a single routing prefix environment
would lead to massive expansion of the global routing tables (as seen would lead to massive expansion of the global routing tables (as seen
in IPv4), so IPv6 provides for simultaneous use of multiple prefixes. in IPv4), so IPv6 provides for simultaneous use of multiple prefixes.
The Unique Local Address prefix (ULA) [14] has been set aside for use The Unique Local Address prefix (ULA) [15]has been set aside for use
in local communications. The ULA address prefix for any network is in local communications. The ULA address prefix for any network is
routable over a locally defined collection of routers. These routable over a locally defined collection of routers. These
prefixes are not intended to be routed on the public global Internet prefixes are not intended to be routed on the public global Internet
as large scale inter-domain distribution of routes for ULA prefixes as large scale inter-domain distribution of routes for ULA prefixes
would have a negative impact on global route aggregation. would have a negative impact on global route aggregation.
ULAs have the following characteristics: ULAs have the following characteristics:
o For all practical purposes a globally unique prefix o For all practical purposes a globally unique prefix
* Allows networks to be combined or privately interconnected * Allows networks to be combined or privately interconnected
without creating address conflicts or requiring renumbering of without creating address conflicts or requiring renumbering of
skipping to change at page 14, line 4 skipping to change at page 13, line 49
boundaries preventing leakage of local routes and packets. boundaries preventing leakage of local routes and packets.
o In practice, applications may treat these addresses like global o In practice, applications may treat these addresses like global
scoped addresses but address selection algorithms may need to scoped addresses but address selection algorithms may need to
distinguish between ULAs and ordinary global scope unicast distinguish between ULAs and ordinary global scope unicast
addresses to assure stability. The policy table defined in [10] addresses to assure stability. The policy table defined in [10]
is one way to bias this selection, by giving higher preference to is one way to bias this selection, by giving higher preference to
FC00::/7 over 2001::/3. Mixing the two kinds of addresses may FC00::/7 over 2001::/3. Mixing the two kinds of addresses may
lead to undeliverable packets during times of instability, but lead to undeliverable packets during times of instability, but
that mixing is not likely to happen when the rules of RFC 3484 are that mixing is not likely to happen when the rules of RFC 3484 are
followed. followed.
o ULAs have no intrinsic security properties. However, they have
the useful property that their routing scope is limited by default
within an administrative boundary. Their usage is suggested at
several points in this document, as a matter of administrative
convenience.
3.3. DHCPv6 Prefix Delegation 3.3. DHCPv6 Prefix Delegation
One of the functions of a simple gateway is managing the local use One of the functions of a simple gateway is managing the local use
address range. The Prefix Delegation (DHCP-PD) options [11] provide address range. The Prefix Delegation (DHCP-PD) options [11] provide
a mechanism for automated delegation of IPv6 prefixes using the a mechanism for automated delegation of IPv6 prefixes using the
Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism
(DHCP-PD) is intended for delegating a long-lived prefix from a (DHCP-PD) is intended for delegating a long-lived prefix from a
delegating router (possibly incorporating a DHCPv6 server) to a delegating router (possibly incorporating a DHCPv6 server) to a
requesting router, possibly across an administrative boundary, where requesting router, possibly across an administrative boundary, where
skipping to change at page 14, line 29 skipping to change at page 14, line 31
The main goal of untraceable IPv6 addresses is to create an The main goal of untraceable IPv6 addresses is to create an
apparently amorphous network infrastructure as seen from external apparently amorphous network infrastructure as seen from external
networks to protect the local infrastructure from malicious outside networks to protect the local infrastructure from malicious outside
influences and from mapping of any correlation between the network influences and from mapping of any correlation between the network
activities of multiple devices from external networks. When using activities of multiple devices from external networks. When using
untraceable IPv6 addresses, it could be that two apparently untraceable IPv6 addresses, it could be that two apparently
sequential addresses are allocated to devices on very different parts sequential addresses are allocated to devices on very different parts
of the local network instead of belonging to devices adjacent to each of the local network instead of belonging to devices adjacent to each
other on the same subnet. other on the same subnet.
These should be globally routable IPv6 addresses which can be Since IPv6 addresses will not be in short supply even within a single
/64 (or shorter) prefix, it is possible to generate them effectively
at random when untraceability is required. They will be globally
routable IPv6 addresses under the site's prefix, which can be
randomly and independently assigned to IPv6 devices. The random randomly and independently assigned to IPv6 devices. The random
assignment is intended to mislead the outside world about the assignment is intended to mislead the outside world about the
structure of the local network. However the local network needs to structure of the local network. In particular the subnet structure
maintain a correlation between the location of the device and the may be invisible in the address. Thus a flat routing mechanism will
be needed within the site. The local routers need to maintain a
correlation between the topological location of the device and the
untraceable IPv6 address. For smaller deployments this correlation untraceable IPv6 address. For smaller deployments this correlation
could be done by generating IPv6 host route entries, or for larger could be done by generating IPv6 host route entries, or for larger
ones by utilizing an indirection device such as a Mobile IPv6 Home ones by utilizing an indirection device such as a Mobile IPv6 Home
Agent. Additional details are in section 4.7. Agent. Additional details are in section 4.7.
4. Using IPv6 Technology to Provide the Market Perceived Benefits of 4. Using IPv6 Technology to Provide the Market Perceived Benefits of
NAT NAT
The facilities in IPv6 described in Section 3 can be used to provide The facilities in IPv6 described in Section 3 can be used to provide
the protection perceived to be associated with IPv4 NAT. This the protection perceived to be associated with IPv4 NAT. This
section gives some examples of how IPv6 can be used securely. section gives some examples of how IPv6 can be used securely.
4.1. Simple Gateway between Internet and Internal Network 4.1. Simple Gateway between Internet and Internal Network
As a simple gateway, the device manages both packet routing and local As a simple gateway, the device manages both packet routing and local
address management. A basic IPv6 router should have a default address management. A basic IPv6 router should have a default
configuration to advertise inside the site a locally generated random configuration to advertise inside the site a locally generated random
ULA prefix, independently from the state of any external ULA prefix, independently from the state of any external
connectivity. This would allow local nodes to communicate amongst connectivity. This would allow local nodes in a topology more
themselves independent of the state of a global connection. If the complex than a single link to communicate amongst themselves
network happened to concatenate with another local network, the independent of the state of a global connection. If the network
randomness in ULA creation is highly unlikely to result in address happened to concatenate with another local network, the randomness in
collisions. ULA creation is highly unlikely to result in address collisions.
With external connectivity the simple gateway should use DHCP-PD to With external connectivity the simple gateway should use DHCP-PD to
acquire a routing prefix from the service provider for use when acquire a routing prefix from the service provider for use when
connecting to the global Internet. End-system connections involving connecting to the global Internet. End-system connections involving
other nodes on the global Internet will always use the global IPv6 other nodes on the global Internet will always use the global IPv6
addresses derived from this prefix delegation. It should be noted addresses derived from this prefix delegation. It should be noted
that the address selection policy table in end-systems defined in RFC that the address selection policy table in end-systems defined in RFC
3484 should be configured to prefer the ULA prefix range over the 3484 should be configured to prefer the ULA prefix range over the
DHCP-PD prefix range when the goal is to keep local communications DHCP-PD prefix range when the goal is to keep local communications
stable during periods of transient external connectivity. stable during periods of transient external connectivity.
skipping to change at page 15, line 42 skipping to change at page 16, line 4
directly connected towards the Internet. The use of firewall and directly connected towards the Internet. The use of firewall and
Intrusion Detection Systems (IDS) is recommended for those that want Intrusion Detection Systems (IDS) is recommended for those that want
boundary protection in addition to host defenses. A proxy may be boundary protection in addition to host defenses. A proxy may be
used for certain applications, but with the caveat that the end to used for certain applications, but with the caveat that the end to
end transparency is broken. However, with IPv6, the following end transparency is broken. However, with IPv6, the following
protections are available without the use of NAT while maintaining protections are available without the use of NAT while maintaining
end-to-end reachability: end-to-end reachability:
1. Short lifetimes on privacy extension suffixes reduce the attack 1. Short lifetimes on privacy extension suffixes reduce the attack
profile since the node will not respond to the address once its profile since the node will not respond to the address once its
lifetime becomes invalid. lifetime becomes invalid.
2. IPsec is a mandatory service for IPv6 implementations. IPsec 2. IPsec is a mandatory service for IPv6 implementations. IPsec
functions to authenticate the correspondent, prevent session functions to authenticate the correspondent, prevent session
hijacking, prevent content tampering, and optionally masks the hijacking, prevent content tampering, and optionally masks the
packet contents. While IPsec might be available in IPv4 packet contents. While IPsec is commonly available in some IPv4
implementations and works the same way, deployment in NAT implementations and can support NATs, NAT support has limitations
environments either breaks the protocol or requires complex and does not work in all situations. In addition, the use of
helper services with limited functionality or efficiency. IPsec with NATs consumes extra bandwidth for UDP encapsulation
and keepalive overhead [12]. In the IPv4/NAT environment, the
usage of IPSec has been largely limited to edge-to-edge VPN
deployments, its potential for end-to-end deployment is
significantly enhanced in an IPv6 network. It should be noted
that encrypted IPsec traffic will bypass content-aware firewalls,
which is presumed to be acceptable for parties with whom the site
has established a security association.
3. The size of the address space of a typical subnet (64 bits of 3. The size of the address space of a typical subnet (64 bits of
IID) will make a complete subnet ping sweep virtually impossible IID) will make a complete subnet ping sweep virtually impossible
due to the potential number of combinations available. Reducing due to the potential number of combinations available. Reducing
the security threat of port scans on identified nodes requires the security threat of port scans on identified nodes requires
sparse distribution within the subnet to minimize the probability sparse distribution within the subnet to minimize the probability
of scans finding adjacent nodes. Provided that IIDs are of scans finding adjacent nodes. This scanning protection will
essentially randomly distributed across the available space, be nullified if IIDs are configured in any structured groupings
address scanning based attacks will effectively fail. This within the IID space. Provided that IIDs are essentially
protection exists if the attacker has no direct access to the randomly distributed across the available space, address scanning
specific subnet and therefore is trying to scan it remotely. If based attacks will effectively fail. This protection exists if
an attacker has local access then he could use ND [3] and ping6 the attacker has no direct access to the specific subnet and
to the link-scope multicast ff02::1 to detect the IEEE based therefore is trying to scan it remotely. If an attacker has
address of local neighbors, then apply the global prefix to those local access then he could use ND [3]and ping6 to the link-scope
to simplify its search (of course, a locally connected attacker multicast ff02::1 to detect the IEEE based address of local
has many scanning options with IPv4 as well). This scanning neighbors, then apply the global prefix to those to simplify its
protection will be nullified if IIDs are configured in any search (of course, a locally connected attacker has many scanning
structured groupings within the IID space. options with IPv4 as well).
Assuming the network administrator is aware of [19] the increased Assuming the network administrator is aware of [20]the increased size
size of the IPv6 address will make topology probing much harder, and of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices. The intention of topology almost impossible for IPv6 devices. The intention of topology
probing is to identify a selection of the available hosts inside an probing is to identify a selection of the available hosts inside an
enterprise. This mostly starts with a ping-sweep. Since the IPv6 enterprise. This mostly starts with a ping-sweep. Since the IPv6
subnets are 64 bits worth of address space, this means that an subnets are 64 bits worth of address space, this means that an
attacker has to send out a simply unrealistic number of pings to map attacker has to send out a simply unrealistic number of pings to map
the network, and virus/worm propagation will be thwarted in the the network, and virus/worm propagation will be thwarted in the
process. At full-rate full-duplex 40Gbps (400 times the typical process. At full-rate full-duplex 40Gbps (400 times the typical
100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it
takes over 5000 years to scan the entirety of a single 64 bit subnet. takes over 5000 years to scan the entirety of a single 64 bit subnet.
skipping to change at page 17, line 32 skipping to change at page 18, line 11
be to make use of the IPv6 Internet more secure without increasing be to make use of the IPv6 Internet more secure without increasing
the perceived complexity for users who just want to accomplish a the perceived complexity for users who just want to accomplish a
task. task.
4.3. User/Application Tracking 4.3. User/Application Tracking
IPv6 enables the collection of information about data flows. Due to IPv6 enables the collection of information about data flows. Due to
the fact that all addresses used for Internet and intra-/inter- site the fact that all addresses used for Internet and intra-/inter- site
communication are unique, it is possible for an enterprise or ISP to communication are unique, it is possible for an enterprise or ISP to
get very detailed information on any communication exchange between get very detailed information on any communication exchange between
two or more devices. This enhances the capability of data- flow two or more devices. Unless privacy addresses [7] are in use, this
tracking for security audits compared with IPv4 NAT, because in IPv6 enhances the capability of data- flow tracking for security audits
a flow between a sender and receiver will always be uniquely compared with IPv4 NAT, because in IPv6 a flow between a sender and
identified due to the unique IPv6 source and destination addresses. receiver will always be uniquely identified due to the unique IPv6
source and destination addresses.
At the same time, this tracking is per address. In environments At the same time, this tracking is per address. In environments
where the goal is tracking back to the user, additional external where the goal is tracking back to the user, additional external
information will be necessary correlating a user with an address. In information will be necessary correlating a user with an address. In
the case of short lifetime privacy address usage, this external the case of short lifetime privacy address usage, this external
information will need to be based on more stable information such as information will need to be based on more stable information such as
the layer 2 media address. the layer 2 media address.
4.4. Privacy and Topology Hiding using IPv6 4.4. Privacy and Topology Hiding using IPv6
Partial host privacy is achieved in IPv6 using pseudo-random privacy Partial host privacy is achieved in IPv6 using pseudo-random privacy
addresses [RFC 3041] which are generated as required, so that a addresses RFC 3041 which are generated as required, so that a session
session can use an address that is valid only for a limited time. can use an address that is valid only for a limited time. This only
This only allows such a session to be traced back to the subnet that allows such a session to be traced back to the subnet that originates
originates it, but not immediately to the actual host, where IPv4 NAT it, but not immediately to the actual host, where IPv4 NAT is only
is only traceable to the most public NAT interface. traceable to the most public NAT interface.
Due to the large IPv6 address space available there is plenty of Due to the large IPv6 address space available there is plenty of
freedom to randomize subnet allocations. By doing this, it is freedom to randomize subnet allocations. By doing this, it is
possible to reduce the correlation between a subnet and its location. possible to reduce the correlation between a subnet and its location.
When doing both subnet and IID randomization [RFC 3041] a casual When doing both subnet and IID randomization [7]a casual snooper
snooper won't be able to deduce much about the networks topology. won't be able to deduce much about the networks topology. The
The obtaining of a single address will tell the snooper very little obtaining of a single address will tell the snooper very little about
about other addresses. This is different from IPv4 where address other addresses. This is different from IPv4 where address space
space limitations cause this to be not true. In most usage cases limitations cause this to be not true. In most usage cases this
this concept should be sufficient for address privacy and topology concept should be sufficient for address privacy and topology hiding,
hiding, with the cost being a more complex internal routing with the cost being a more complex internal routing configuration.
configuration.
As discussed in Section 3.1, there are multiple parts to the IPv6 As discussed in Section 3.1, there are multiple parts to the IPv6
address, and different techniques to manage privacy for each which address, and different techniques to manage privacy for each which
may be combined to protect the entire address. In the case where a may be combined to protect the entire address. In the case where a
network administrator wishes to fully isolate the internal IPv6 network administrator wishes to fully isolate the internal IPv6
topology, and the majority of its internal use addresses, one option topology, and the majority of its internal use addresses, one option
is to run all internal traffic using Unique Local Addresses (ULA). is to run all internal traffic using Unique Local Addresses (ULA).
By definition this prefix block is not to be advertised into the By definition this prefix block is not to be advertised into the
public routing system, so without a routing path external traffic public routing system, so without a routing path external traffic
will never reach the site. For the set of hosts that do in fact need will never reach the site. For the set of hosts that do in fact need
skipping to change at page 18, line 47 skipping to change at page 19, line 25
all of the topology hidden nodes appear from the outside to logically all of the topology hidden nodes appear from the outside to logically
exist at the edge of the network, just as they would when behind a exist at the edge of the network, just as they would when behind a
NAT. NAT.
o One approach uses explicit host routes in the IGP to remove the o One approach uses explicit host routes in the IGP to remove the
external correlation between physical topology attachment point external correlation between physical topology attachment point
and end-to-end IPv6 address. In the figure below the hosts would and end-to-end IPv6 address. In the figure below the hosts would
be allocated prefixes from one or more logical subnets, and would be allocated prefixes from one or more logical subnets, and would
inject host routes to internally identify their real attachment inject host routes to internally identify their real attachment
point. This solution does however show severe scalability issues point. This solution does however show severe scalability issues
and requires hosts to participate in the IGP, as well as having and requires hosts to securely participate in the IGP, as well as
the firewall block all external to internal traceroute for the having the firewall block all external to internal traceroute for
logical subnet. The specific limitations are dependent on the IGP the logical subnet. The specific limitations are dependent on the
protocol, the physical topology, and the stability of the system. IGP protocol, the physical topology, and the stability of the
In any case the approach should be limited to uses with system. In any case the approach should be limited to uses with
substantially fewer than the maximum number of routes that the IGP substantially fewer than the maximum number of routes that the IGP
can support (generally between 5,000 and 50,000 total entries can support (generally between 5,000 and 50,000 total entries
including subnet routes). including subnet routes). Hosts should also listen to the IGP for
duplicate use before finalizing an interface address assignment as
the duplicate address detection will only check for use on the
attached segment, not the logical subnet.
o Another technical approach to fully hide the internal topology is o Another technical approach to fully hide the internal topology is
use of a tunneling mechanism. Mobile IPv6 without route use of a tunneling mechanism. Mobile IPv6 without route
optimization is one approach for using an automated tunnel, as it optimization is one approach for using an automated tunnel, as it
always starts in tunnel mode via the Home Agent (HA). In this always starts in tunnel mode via the Home Agent (HA). In this
deployment model the application perceived addresses of the nodes deployment model the application perceived addresses of the nodes
are routed via the edge HA. This indirection method truly masks are routed via the edge HA. This indirection method truly masks
the internal topology, as from outside the local network all nodes the internal topology, as from outside the local network all nodes
with global access appear to share the prefix of one or more with global access appear to share the prefix of one or more
logical subnets attached to the HA rather than their real logical subnets attached to the HA rather than their real
attachment point. While turning off all binding updates would attachment point. Duplicate address detection is handled as a
appear to be necessary to prevent leakage of topology information, normal process of the HA binding update. While turning off all
that approach would also force all internal traffic using the home binding updates with the coorespondent node would appear to be
necessary to prevent leakage of topology information, that
approach would also force all internal traffic using the home
address to route via the HA tunnel, which may be undesirable. A address to route via the HA tunnel, which may be undesirable. A
more efficient method would be to allow internal route more efficient method would be to allow internal route
optimizations while dropping outbound binding updates at the optimizations while dropping outbound binding update messages at
firewall. Another approach for the internal routes would be to the firewall. Another approach for the internal traffic would be
use the policy table of RFC 3484 to bias a ULA prefix as preferred to use the policy table of RFC 3484 to bias a ULA prefix as
internally, leaving the Home Address external for use. The preferred internally, leaving the logical subnet Home Address
downsides of using the MIPv6 tunneling method is that it makes external for use. The downsides with a Mobile IPv6 based solution
usage of middleware like a Home Agent (HA) and consumes slightly is that it requires a home agent in the network, the configuration
more bandwidth for the tunnel overhead. of a security association with the HA for each hidden node, and
consumes some amount of bandwidth for tunnel overhead.
o Another method (where the layer 2 topology allows) uses a virtual o Another method (where the layer 2 topology allows) uses a virtual
lan approach to logically attach the devices to one or more lan approach to logically attach the devices to one or more
subnets on the edge router. The downsides of this approach is subnets on the edge router. This approach leads the end nodes to
that all internal traffic would be directed over sub-optimal paths believe they actually share a common segment. The downsides of
via the edge router, as well as the complexity of managing a this approach is that all internal traffic would be directed over
distributed logical lan. sub-optimal paths via the edge router, as well as the complexity
of managing a distributed logical lan.
Internet Internet
| |
\ \
| |
+------------------+ +------------------+
| Simple Gateway |-+-+-+-+-+-+-+-+-- | topology |-+-+-+-+-+-+-+-+--
| or Home Agent | Logical subnets | masking | Logical subnets
| |-+-+-+-+-+-+-+-+-- | router |-+-+-+-+-+-+-+-+--
+------------------+ for topology +------------------+ for topology
| hidden nodes | hidden nodes
| |
Real internal -------------+- Real internal -------------+-
topology | | topology | |
| -+---------- | -+----------
-----------+--------+ -----------+--------+
| |
| |
| |
One issue to be aware of is that subnet scope multicast will not work
for the logical hidden subnets, except in the vlan case. While a
limited scope multicast to a collection of nodes that are arbitrarily
scattered makes no technical sense, care should be exercised to avoid
deploying applications that expect limited scope multicast in
conjunction with topology hiding.
Another issue that this document will not define is the mechanism for
a topology hidden node to learn its logical subnet. While manual
configuration would clearly be sufficient, DHCP could be used for
address assignment, with the recipient node discovering it is in a
hidden mode when the attached subnet prefix doesn't match the one
assigned.
4.5. Independent Control of Addressing in a Private Network 4.5. Independent Control of Addressing in a Private Network
IPv6 provides for autonomy in local use addresses through ULAs. At IPv6 provides for autonomy in local use addresses through ULAs. At
the same time IPv6 simplifies simultaneous use of multiple addresses the same time IPv6 simplifies simultaneous use of multiple addresses
per interface so that an IPv6 NAT is not required between the ULA and per interface so that an IPv6 NAT is not required between the ULA and
the public Internet because nodes that need access to the public the public Internet because nodes that need access to the public
Internet will have a global use address as well. When using IPv6, Internet will have a global use address as well. When using IPv6,
the need to ask for more address space will become far less likely the need to ask for more address space will become far less likely
due to the increased size of the subnets, along with an allocation due to the increased size of the subnets, along with an allocation
policy that recognizes table fragmentation is also an important policy that recognizes table fragmentation is also an important
skipping to change at page 20, line 40 skipping to change at page 21, line 50
prefixes which will reduce the operational and configuration prefixes which will reduce the operational and configuration
overhead. overhead.
4.6. Global Address Pool Conservation 4.6. Global Address Pool Conservation
IPv6 provides sufficient space to completely avoid the need for IPv6 provides sufficient space to completely avoid the need for
overlapping address space. Since allocations in IPv6 are based on overlapping address space. Since allocations in IPv6 are based on
subnets rather than hosts a reasonable way to look at the pool is subnets rather than hosts a reasonable way to look at the pool is
that there are about 17*10^18 unique subnet values where sparse that there are about 17*10^18 unique subnet values where sparse
allocation practice within those provides for new opportunities such allocation practice within those provides for new opportunities such
as SEND 3971 [12]. As previously discussed, the serious as SEND 3971 [13]. As previously discussed, the serious
disadvantages of ambiguous address space have been well documented, disadvantages of ambiguous address space have been well documented,
and with sufficient space there is no need to continue the and with sufficient space there is no need to continue the
increasingly aggressive conservation practices that are necessary increasingly aggressive conservation practices that are necessary
with IPv4. While IPv6 allocation policies and ISP business practice with IPv4. While IPv6 allocation policies and ISP business practice
will continue to evolve, the recommendations in RFC 3177 are based on will continue to evolve, the recommendations in RFC 3177 are based on
the technical potential of the vast IPv6 address space. That the technical potential of the vast IPv6 address space. That
document demonstrates that there is no resource limitation which will document demonstrates that there is no resource limitation which will
require the adoption of the IPv4 workaround of ambiguous space behind require the adoption of the IPv4 workaround of ambiguous space behind
a NAT. As an example of the direct contrast, many expansion oriented a NAT. As an example of the direct contrast, many expansion oriented
IPv6 deployment scenarios result in multiple IPv6 addresses per IPv6 deployment scenarios result in multiple IPv6 addresses per
device, as opposed to the constriction of IPv4 scenarios where device, as opposed to the constriction of IPv4 scenarios where
multiple devices are forced to share a scarce global address through multiple devices are forced to share a scarce global address through
a NAT. a NAT.
4.7. Multihoming and Renumbering 4.7. Multihoming and Renumbering
Multihoming and renumbering remain technically challenging with IPv6 IPv6 was designed to allow sites and hosts to run with several
(see the Gap Analysis below). However, IPv6 was designed to allow simultaneous CIDR allocated prefixes, and thus with several
sites and hosts to run with several simultaneous CIDR allocated simultaneous ISPs. An address selection mechanism [10] is specified
prefixes, and thus with several simultaneous ISPs. An address so that hosts will behave consistently when several addresses are
selection mechanism [10] is specified so that hosts will behave simultaneously valid. The fundamental difficulty that IPv4 has in
consistently when several addresses are simultaneously valid. The regard to multiple addresses therefore does not apply to IPv6. IPv6
fundamental difficulty that IPv4 has in regard to multiple addresses sites can and do run today with multiple ISPs active, and the
therefore does not apply to IPv6. IPv6 sites can and do run today processes for adding, removing, and renumbering active prefixes at a
with multiple ISPs active, and the processes for adding, removing, site have been documented in [14] and [21]. However, multihoming and
and renumbering active prefixes at a site have been documented in renumbering remain technically challenging even with IPv6 with
[13] and [20]. regards to, for instance, session continuity across multihoming
events or interactions with ingress filtering (but see the Gap
Analysis below).
The IPv6 address space allocated by the ISP will be dependent upon The IPv6 address space allocated by the ISP will be dependent upon
the connecting Service provider. This will likely result in a the connecting Service provider. This will likely result in a
renumbering effort when the network changes between service renumbering effort when the network changes between service
providers. When changing ISPs or ISPs readjusting their addressing providers. When changing ISPs or ISPs readjusting their addressing
pool, DHCP-PD [11] can be used as an almost zero- touch external pool, DHCP-PD [11] can be used as an almost zero- touch external
mechanism for prefix change in conjunction with a ULA prefix for mechanism for prefix change in conjunction with a ULA prefix for
internal connection stability. With appropriate management of the internal connection stability. With appropriate management of the
lifetime values and overlap of the external prefixes, a smooth make- lifetime values and overlap of the external prefixes, a smooth make-
before-break transition is possible as existing communications will before-break transition is possible as existing communications will
skipping to change at page 24, line 30 skipping to change at page 25, line 36
become a world wide Internet server (i.e. HTTP, FTP, etc.) due to become a world wide Internet server (i.e. HTTP, FTP, etc.) due to
the stateful operation of the NAT equipment. Even when there is the stateful operation of the NAT equipment. Even when there is
sufficient technical knowledge to manage the NAT to enable external sufficient technical knowledge to manage the NAT to enable external
access to a server, only one server can be mapped per protocol/ access to a server, only one server can be mapped per protocol/
port-number per address, and then only when the address from the ISP port-number per address, and then only when the address from the ISP
is publicly routed. When there is an upstream NAT providing private is publicly routed. When there is an upstream NAT providing private
address space to the ISP side of the private NAT, additional address space to the ISP side of the private NAT, additional
negotiation with the ISP will be necessary to provide an inbound negotiation with the ISP will be necessary to provide an inbound
mapping, if that is even possible. mapping, if that is even possible.
When deploying IPv6 NAP in this environment, there are two approaches When deploying IPv6 NAP6 in this environment, there are two
possible with respect to IPv6 addressing. approaches possible with respect to IPv6 addressing.
o DHCPv6 Prefix-Delegation o DHCPv6 Prefix-Delegation
o ISP provides a static IPv6 address-range o ISP provides a static IPv6 address-range
For the DHCPv6-PD solution, a dynamic address allocation approach is For the DHCPv6-PD solution, a dynamic address allocation approach is
chosen. By means of the enhanced DHCPv6 protocol it is possible to chosen. By means of the enhanced DHCPv6 protocol it is possible to
have the ISP push down an IPv6 prefix range automatically towards the have the ISP push down an IPv6 prefix range automatically towards the
small private network and populate all interfaces in that small small private network and populate all interfaces in that small
private network dynamically. This reduces the burden for private network dynamically. This reduces the burden for
administrative overhead because everything happens automatically. administrative overhead because everything happens automatically.
skipping to change at page 25, line 35 skipping to change at page 26, line 41
address and use a single piece of equipment (PC, PDA, etc.). This address and use a single piece of equipment (PC, PDA, etc.). This
user may get an ambiguous IPv4 address (frequently imposed by the user may get an ambiguous IPv4 address (frequently imposed by the
ISP) from the service provider which is based on RFC 1918. If ISP) from the service provider which is based on RFC 1918. If
ambiguous addressing is utilized, the service provider will execute ambiguous addressing is utilized, the service provider will execute
NAT on the allocated IPv4 address for global Internet connectivity. NAT on the allocated IPv4 address for global Internet connectivity.
This also limits the Internet capability of the equipment to being This also limits the Internet capability of the equipment to being
mainly a receiver of Internet data, and makes it quite hard for the mainly a receiver of Internet data, and makes it quite hard for the
equipment to become a world wide Internet server (i.e. HTTP, FTP, equipment to become a world wide Internet server (i.e. HTTP, FTP,
etc.) due to the stateful operation of the NAT equipment. etc.) due to the stateful operation of the NAT equipment.
When using IPv6 NAP, this group will identify the users which are When using IPv6 NAP6, this group will identify the users which are
connected via a single IPv6 address and use a single piece of connected via a single IPv6 address and use a single piece of
equipment (PC, PDA, etc.). equipment (PC, PDA, etc.).
In IPv6 world the assumption is that there is unrestricted In IPv6 world the assumption is that there is unrestricted
availability of a large amount of globally routable and unique IPv6 availability of a large amount of globally routable and unique IPv6
addresses. The ISP will not be motivated to allocate private addresses. The ISP will not be motivated to allocate private
addresses towards the single user connection because he has enough addresses towards the single user connection because he has enough
global addresses available, if scarcity was the motivation with IPv4 global addresses available, if scarcity was the motivation with IPv4
to provide RFC 1918 addresses. If the single user wants to mask his to provide RFC 1918 addresses. If the single user wants to mask his
identity, he may choose to enable IPv6 privacy extensions. identity, he may choose to enable IPv6 privacy extensions.
skipping to change at page 26, line 18 skipping to change at page 27, line 23
backbone and access switches, and other hardware, this is separate backbone and access switches, and other hardware, this is separate
for both engineering reasons as well as simplicity in managing the for both engineering reasons as well as simplicity in managing the
security of the backbone. security of the backbone.
o The third is the IP addresses (single or blocks) that they assign o The third is the IP addresses (single or blocks) that they assign
to customers. These can be registered addresses (usually given to to customers. These can be registered addresses (usually given to
category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of
RFC 1918 addresses used with IPv4 NAT for single user connections. RFC 1918 addresses used with IPv4 NAT for single user connections.
Therefore they can actually have two different NAT domains that Therefore they can actually have two different NAT domains that
are not connected (internal LAN and single user customers). are not connected (internal LAN and single user customers).
When IPv6 NAP is utilized in these three domains then for the first When IPv6 NAP6 is utilized in these three domains then for the first
category it will be possible to use the same solutions as described category it will be possible to use the same solutions as described
in Section 5.1. The second domain of the ISP/carrier is the in Section 5.1. The second domain of the ISP/carrier is the
Operations network. This environment tends to be a closed Operations network. This environment tends to be a closed
environment, and consequently communication can be done based on ULA environment, and consequently communication can be done based on ULA
addresses, however, in this environment, stable IPv6 Provider addresses, however, in this environment, stable IPv6 Provider
Independent addresses can be used. This would give a solid and Independent addresses can be used. This would give a solid and
scalable configuration with respect to a local IPv6 address plan. By scalable configuration with respect to a local IPv6 address plan. By
the usage of proper network edge filters, outside access to the the usage of proper network edge filters, outside access to the
closed environment can be avoided. The third is the IPv6 addresses closed environment can be avoided. The third is the IPv6 addresses
that ISP/carrier network assign to customers. These will typically that ISP/carrier network assign to customers. These will typically
skipping to change at page 26, line 40 skipping to change at page 27, line 45
be consistent with the DNS PTR records. As scarcity of IPv6 be consistent with the DNS PTR records. As scarcity of IPv6
addresses is not a concern, it will be possible for the ISP to addresses is not a concern, it will be possible for the ISP to
provide global routable IPv6 prefixes without a requirement for provide global routable IPv6 prefixes without a requirement for
address translation. An ISP may for commercial reasons still decide address translation. An ISP may for commercial reasons still decide
to restrict the capabilities of the end users by other means like to restrict the capabilities of the end users by other means like
traffic and/or route filtering etc. traffic and/or route filtering etc.
If the carrier network is a mobile provider, then IPv6 is encouraged If the carrier network is a mobile provider, then IPv6 is encouraged
in comparison with the combination of IPv4+NAT for 3GPP attached in comparison with the combination of IPv4+NAT for 3GPP attached
devices. When looking in chapter 2.3 of RFC3314 'Recommendations for devices. When looking in chapter 2.3 of RFC3314 'Recommendations for
IPv6 in 3GPP Standards' [16] it is found that the IPv6 WG recommends IPv6 in 3GPP Standards' [17]it is found that the IPv6 WG recommends
that one or more /64 prefixes should be assigned to each primary PDP that one or more /64 prefixes should be assigned to each primary PDP
context. This will allow sufficient address space for a 3GPP- context. This will allow sufficient address space for a 3GPP-
attached node to allocate privacy addresses and/or route to a multi- attached node to allocate privacy addresses and/or route to a multi-
link subnet, and will discourage the use of NAT within 3GPP-attached link subnet, and will discourage the use of NAT within 3GPP-attached
devices. devices.
6. IPv6 Gap Analysis 6. IPv6 Gap Analysis
Like IPv4 and any major standards effort, IPv6 standardization work Like IPv4 and any major standards effort, IPv6 standardization work
continues as deployments are ongoing. This section discusses several continues as deployments are ongoing. This section discusses several
topics for which additional standardization, or documentation of best topics for which additional standardization, or documentation of best
practice, is required to fully realize the benefits of NAP. None of practice, is required to fully realize the benefits of NAP6. None of
these items are show-stoppers for immediate usage of NAP in roles these items are show-stoppers for immediate usage of NAP6 in
where there are no current gaps. scenarios where there are no current gaps.
6.1. Simple Security 6.1. Simple Security
Dynamic pinhole management is an area for further study. Several Firewall traversal by dynamic pinhole management requires further
partial solutions exist including ICE, UPNP, as well as alternative study. Several partial solutions exist including ICE [23], UPNP
proposals for Service Provider based control. The 'simple' aspect of [24], as well as alternative proposals for Service Provider based
the security provided by a stateful firewall will require some degree control. The basic security provided by a stateful firewall will
of automation to mask the technical complexity from the consumer that require some degree of default configuration and automation to mask
only wants a secure environment with working applications. the technical complexity from a consumer who merely wants a secure
environment with working applications. There is no reason a stateful
IPv6 firewall product cannot be shipped with the equivalent default
protection that is offered by today's IPv4/NAT products.
6.2. Subnet Topology Masking 6.2. Subnet Topology Masking
There really is no functional gap here as a centrally assigned pool There really is no functional gap here as a centrally assigned pool
of addresses in combination with host routes in the IGP is an of addresses in combination with host routes in the IGP is an
effective way to mask topology for smaller deployments. If necessary effective way to mask topology for smaller deployments. If necessary
a best practice document could be developed describing the a best practice document could be developed describing the
interaction between DHCP and various IGPs which would in effect interaction between DHCP and various IGPs which would in effect
define Untraceable Addresses. define Untraceable Addresses.
skipping to change at page 27, line 42 skipping to change at page 28, line 51
could be done in Mobile IP to define a policy message where a mobile could be done in Mobile IP to define a policy message where a mobile
node would learn from the Home Agent that it should not try to inform node would learn from the Home Agent that it should not try to inform
its correspondent about route optimization and thereby expose its its correspondent about route optimization and thereby expose its
real location. This optimization which reduces the load on the real location. This optimization which reduces the load on the
firewall would result in less optimal internal traffic routing as firewall would result in less optimal internal traffic routing as
that would also transit the HA. Trade-off's for this optimization that would also transit the HA. Trade-off's for this optimization
work should be investigated in the IETF. work should be investigated in the IETF.
6.3. Minimal Traceability of Privacy Addresses 6.3. Minimal Traceability of Privacy Addresses
Privacy addresses (RFC 3041) may certainly be used to limit the Privacy addresses [7] may certainly be used to limit the traceability
traceability of external traffic flows back to specific hosts, but of external traffic flows back to specific hosts, but lacking a
lacking a topology masking component above they would still reveal topology masking component above they would still reveal the subnet
the subnet address bits. For complete privacy a best practice address bits. For complete privacy a best practice document
document describing the combination of privacy addresses with describing the combination of privacy addresses with topology masking
topology masking may be required. This work remains to be done, and may be required. This work remains to be done, and should be pursued
should be pursued by the IETF. by the IETF.
6.4. Site Multihoming 6.4. Site Multihoming
This complex problem has never been completely solved for IPv4, which This complex problem has never been completely solved for IPv4, which
is exactly why NAT has been used as a partial solution. For IPv6, is exactly why NAT has been used as a partial solution. For IPv6,
after several years of work, the IETF has converged on an after several years of work, the IETF has converged on an
architectural approach intended with service restoration as initial architectural approach intended with service restoration as initial
aim [21]. When this document was drafted, the IETF was actively aim [22]. When this document was drafted, the IETF was actively
defining the details of this approach to the multihoming problem. defining the details of this approach to the multihoming problem.
The approach appears to be most suitable for small and medium sites, The approach appears to be most suitable for small and medium sites,
though it will conflict with firewall state procedures. At this time though it will conflict with existing firewall state procedures. At
there are also active discussions in the address registries this time there are also active discussions in the address registries
investigating the possibility of assigning provider-independent investigating the possibility of assigning provider-independent
address space. Their challenge is finding a reasonable metric for address space. Their challenge is finding a reasonable metric for
limiting the number of organizations that would qualify for a global limiting the number of organizations that would qualify for a global
routing entry. Additional work appears to be necessary to satisfy routing entry. Additional work appears to be necessary to satisfy
the entire range of requirements. the entire range of requirements.
7. IANA Considerations 7. IANA Considerations
This document requests no action by IANA This document requests no action by IANA
skipping to change at page 28, line 42 skipping to change at page 29, line 47
address translation functionality in their firewalls, though the address translation functionality in their firewalls, though the
misleading nature of those claims has been previously documented in misleading nature of those claims has been previously documented in
[2] and [4]. [2] and [4].
This document defines IPv6 approaches which collectively achieve the This document defines IPv6 approaches which collectively achieve the
goals of the network manager without the negative impact on goals of the network manager without the negative impact on
applications or security that are inherent in a NAT approach. To the applications or security that are inherent in a NAT approach. To the
degree that these techniques improve a network manager's ability to degree that these techniques improve a network manager's ability to
explicitly audit or control access, and thereby manage the overall explicitly audit or control access, and thereby manage the overall
attack exposure of local resources, they act to improve local network attack exposure of local resources, they act to improve local network
security. In particular the explicit nature of a content aware security.
firewall in NAP will be a vast security improvement over the NAT
artifact where lack of translation state has been widely sold as a
form of protection.
9. Conclusion 9. Conclusion
This document has described a number of techniques that may be This document has described a number of techniques that may be
combined on an IPv6 site to protect the integrity of its network combined on an IPv6 site to protect the integrity of its network
architecture. These techniques, known collectively as Network architecture. These techniques, known collectively as Network
Architecture Protection, retain the concept of a well defined Architecture Protection, retain the concept of a well defined
boundary between "inside" and "outside" the private network, and boundary between "inside" and "outside" the private network, and
allow firewalling, topology hiding, and privacy. However, because allow firewalling, topology hiding, and privacy. However, because
they preserve address transparency where it is needed, they achieve they preserve address transparency where it is needed, they achieve
these goals without the disadvantage of address translation. Thus, these goals without the disadvantage of address translation. Thus,
Network Architecture Protection in IPv6 can provide the benefits of Network Architecture Protection in IPv6 can provide the benefits of
IPv4 Network Address Translation without the corresponding IPv4 Network Address Translation without the corresponding
disadvantages. disadvantages.
The document has also identified a few ongoing IETF work items that The document has also identified a few ongoing IETF work items that
are needed to realize 100% of the benefits of NAP. are needed to realize 100% of the benefits of NAP6.
10. Acknowledgements 10. Acknowledgements
Christian Huitema has contributed during the initial round table to Christian Huitema has contributed during the initial round table to
discuss the scope and goal of the document, while the European Union discuss the scope and goal of the document, while the European Union
IST 6NET project acted as a catalyst for the work documented in this IST 6NET project acted as a catalyst for the work documented in this
note. Editorial comments and contributions have been received from: note. Editorial comments and contributions have been received from:
Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar,
Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark
Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith, Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith,
skipping to change at page 30, line 25 skipping to change at page 31, line 28
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[10] Draves, R., "Default Address Selection for Internet Protocol [10] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [12] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948,
January 2005.
[13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[13] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering [14] 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.
[14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [15] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
11.2. Informative References 11.2. Informative References
[15] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- [16] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, September 1993. Strategy", RFC 1519, September 1993.
[16] Wasserman, M., "Recommendations for IPv6 in Third Generation [17] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, Partnership Project (3GPP) Standards", RFC 3314,
September 2002. September 2002.
[17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point [18] 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.
[18] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful [19] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful
(draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004. (draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004.
[19] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning [20] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown-
(chown-v6ops-port-scanning-implications-01.txt)", July 2004. v6ops-port-scanning-implications-01.txt)", July 2004.
[20] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to [21] Chown, T., Tompson, 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-03)", October 2004. (draft-chown-v6ops-renumber-thinkabout-03)", October 2004.
[21] Huston, G., "Architectural Commentary on Site Multi-homing [22] Huston, G., "Architectural Commentary on Site Multi-homing
using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)", using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)",
July 2004. July 2004.
Appendix A. Additional Benefits due to Native IPv6 and Universal [23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Unique Addressing Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols (draft-ietf-mmusic-ice-11)",
October 2006.
[24] "UPNP Web Site, "Universal Plug and Play Web Site", Web Site
http://www.upnp.org/", July 2005.
Appendix A. Additional Benefits due to Native IPv6 and Universal Unique
Addressing
The users of native IPv6 technology and global unique IPv6 addresses The users of native IPv6 technology and global unique IPv6 addresses
have the potential to make use of the enhanced IPv6 capabilities, in have the potential to make use of the enhanced IPv6 capabilities, in
addition to the benefits offered by the IPv4 technology. addition to the benefits offered by the IPv4 technology.
A.1. Universal Any-to-Any Connectivity A.1. Universal Any-to-Any Connectivity
One of the original design points of the Internet was any-to-any One of the original design points of the Internet was any-to-any
connectivity. The dramatic growth of Internet connected systems connectivity. The dramatic growth of Internet connected systems
coupled with the limited address space of the IPv4 protocol spawned coupled with the limited address space of the IPv4 protocol spawned
skipping to change at page 32, line 23 skipping to change at page 33, line 39
address space available to use for group assignments and an implicit address space available to use for group assignments and an implicit
locally defined range for group membership. IPv6 multicast corrects locally defined range for group membership. IPv6 multicast corrects
this situation by embedding explicit scope indications as well as this situation by embedding explicit scope indications as well as
expanding to 4 billion groups per scope. In the source specific expanding to 4 billion groups per scope. In the source specific
multicast case, this is further expanded to 4 billion groups per multicast case, this is further expanded to 4 billion groups per
scope per subnet by embedding the 64 bits of subnet identifier into scope per subnet by embedding the 64 bits of subnet identifier into
the multicast address. the multicast address.
IPv6 allows also for innovative usage of the IPv6 address length, and IPv6 allows also for innovative usage of the IPv6 address length, and
makes it possible to embed the multicast 'Rendezvous Point' (or RP) makes it possible to embed the multicast 'Rendezvous Point' (or RP)
[17] directly in the IPv6 multicast address when using ASM multicast. [18] directly in the IPv6 multicast address when using ASM multicast.
This is not possible with limited size of the IPv4 address. This This is not possible with limited size of the IPv4 address. This
approach also simplifies the multicast model considerably, making it approach also simplifies the multicast model considerably, making it
easier to understand and deploy. easier to understand and deploy.
A.4. Increased Security Protection A.4. Increased Security Protection
The security protection offered by native IPv6 technology is more The security protection offered by native IPv6 technology is more
advanced than IPv4 technology. There are various transport advanced than IPv4 technology. There are various transport
mechanisms enhanced to allow a network to operate more securely with mechanisms enhanced to allow a network to operate more securely with
less performance impact: less performance impact:
skipping to change at page 33, line 41 skipping to change at page 35, line 11
merge of two and more networks dramatically due to the additional merge of two and more networks dramatically due to the additional
IPv4 renumbering effort. i.e. when the first network has a service IPv4 renumbering effort. i.e. when the first network has a service
running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by
the 2nd merging network. Similar address conflicts can happen when the 2nd merging network. Similar address conflicts can happen when
two network devices from these merging networks want to communicate. two network devices from these merging networks want to communicate.
With the usage of IPv6 the addressing overlap will not exist because With the usage of IPv6 the addressing overlap will not exist because
of the existence of the Unique Local Address usage for private and of the existence of the Unique Local Address usage for private and
local addressing. local addressing.
A.7. Community of interest
Although some Internet-enabled devices will function as fully-
fledged Internet hosts, it is believed that many will be operated in
a highly restricted manner functioning largely or entirely within a
Community of Interest. By Community of Interest we mean a collection
of hosts that are logically part of a group reflecting their
ownership or function. Typically, members of a Community of Interest
need to communicate within the community but should not be generally
accessible from the public Internet. They want the benefits of the
connectivity provided by the Internet, but do not want to be exposed
to the rest of the world. The ability in NAP to virtualize the
topology and mask portions of it is applied to the community,
creating arbitrary groupings. It will also allow building virtual
organization networks on the fly, which is very difficult to do in
IPv4+NAT scenarios.
Appendix B. Revision history Appendix B. Revision history
B.1. Changes from *-vandevelde-v6ops-nap-00 to B.1. Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 *-vandevelde-v6ops-nap-01
o Document introduction has been revised and overview table added o Document introduction has been revised and overview table added
o Comments and suggestions from nap-00 draft have been included. o Comments and suggestions from nap-00 draft have been included.
o Initial section of -00 draft 2.6 and 4.6 have been aggregated into o Initial section of -00 draft 2.6 and 4.6 have been aggregated into
a new case study section 5. a new case study section 5.
o The list of additional IPv6 benefits has been placed into o The list of additional IPv6 benefits has been placed into
appendix. appendix.
skipping to change at page 41, line 5 skipping to change at page 41, line 35
o Section 6.2: (topology mask) added comment about deployment scale o Section 6.2: (topology mask) added comment about deployment scale
/ added comment about firewall blocking BU / clarified point about / added comment about firewall blocking BU / clarified point about
future work being an optimization to reduce firewall load future work being an optimization to reduce firewall load
o Section 6.3: (tracability) grammar cleanup o Section 6.3: (tracability) grammar cleanup
o Section 6.4: (renumbering) Cut section since it is no longer a gap o Section 6.4: (renumbering) Cut section since it is no longer a gap
o Section A.2: word order - moved 'only' o Section A.2: word order - moved 'only'
o Section A.6: deleted 'legitimate' o Section A.6: deleted 'legitimate'
o Section A.7: clarified how NAP delivers community of interest o Section A.7: clarified how NAP delivers community of interest
o Spell check o Spell check
B.6. Changes from *-ietf-v6ops-nap-03 to *-ietf-v6ops-nap-04
o Editorial changes in response to IESG review comments and
questions, as well as I-D nits.
o Changed the abreviation to NAP6 and the title from 'IPv6 Network
Address Protection' to 'Network Architecture Protection for IPv6'
o Introduction s/in/with
o Introduction s/Indeed, product marketing departments have
effectively driven a perception that some connectivity/ Indeed, it
is often claimed that some connectivity and .../
o Section 2.1 s/[RFC 1918]/xref...
o Section 2.5 s/[RFC1918]/xref...
o Section 2.7 s/huge/major/
o Section 3.2 Added additional paragraph at the end of section to
address ULA comment from Cullen J.
o Section 3.2 last bullet - should qualify 'scope' as 'routing
scope'
o Section 3.4 Rewrote the section for clarity sake to address
consern from Cullen J.
o Section 4.1 para 1 - s/ This would allow local nodes to
communicate amongst themselves independent of the state of a
global connection. /This would allow local nodes in a topology
more complex than a single link to communicate amongst themselves
independent of the state of a global connection.
o Section 4.2 s/efficiency/efficiency, and even these helpers do not
work in all situations.
o Section 4.2 added reference to [RFC3948] and added more
contexttext around IPsec/NAT and IPv6
o Section 4.2 moved comment about nullifying earlier in para
o Section 4.3 added privacy addresses consideration by adding
"Unless privacy addresses [RFC3041] are in use,"
o Section 4.4 last para - typo s/ DHCP could be use / DHCP could be
used
o Section 4.4 removed brackets from 3041
o Section 4.4 s/requires hosts to participate/ requires hosts to
securely participate
o Section 4.4 added note that hosts should listen to IGP because DAD
does not work for virutal subnet
o Section 4.4 added note that DAD is a normal part of HA
o Section 4.4 s/updates/update messages
o Section 4.4 s/routes/traffic
o Section 4.4 s/leaving the Home Address/ leaving the logical subnet
Home Address
o Section 4.4 replaced MIPv6 downsides sentence with text J.Arkko
sent to the list
o Section 4.4 added comment in vlan about host perception of a
shared common segment
o Section 4.4 diagram s/simple gateway home agent/ topology masking
router
o Section 4.4 added comment about subnet scope multicast restriction
for logical subnet
o Section 4.4 added comment about how a topology hidden node learns
its home address
o Section 4.7 Rephrased section based on J. Arkko suggestion
o Section 6. s/roles/scenarios/
o Section 6.1 rewritten section
o Section 6.4 s/with firewall/with existing firewall
o Section 8. removed last line of section
o Section A.7 Removed section to address suggestion from Cullen J.
o Author details: modified Brian Carpenter's address details
Authors' Addresses Authors' Addresses
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2704 5473 Phone: +32 2704 5473
Email: gunter@cisco.com Email: gunter@cisco.com
skipping to change at page 41, line 33 skipping to change at page 43, line 33
Ralph Droms Ralph Droms
Cisco Systems Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: rdroms@cisco.com Email: rdroms@cisco.com
Brian Carpenter Brian Carpenter
IBM Corporation IBM
Sauemerstrasse 4 8 Chemin de Blandonnet
Rueschlikon, 8803 1214 Vernier,
Switzerland CH
Email: brc@zurich.ibm.com Email: brc@zurich.ibm.com
Eric Klein Eric Klein
Tel Aviv University Tel Aviv University
Tel Aviv, Tel Aviv,
Israel Israel
Phone: Phone:
Email: ericlklein@softhome.net Email: ericlklein@softhome.net
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 42, line 29 skipping to change at page 44, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 72 change blocks. 
232 lines changed or deleted 327 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/