draft-ietf-v6ops-nap-01.txt   draft-ietf-v6ops-nap-02.txt 
Network Working Group G. Van de Velde Network Working Group G. Van de Velde
Internet-Draft T. Hain Internet-Draft T. Hain
Expires: December 3, 2005 R. Droms Expires: April 25, 2006 R. Droms
Cisco Systems Cisco Systems
B. Carpenter B. Carpenter
IBM Corporation IBM Corporation
E. Klein E. Klein
Tel Aviv University Tel Aviv University
june 2005 October 22, 2005
IPv6 Network Architecture Protection IPv6 Network Architecture Protection
<draft-ietf-v6ops-nap-01.txt> <draft-ietf-v6ops-nap-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2005. This Internet-Draft will expire on April 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 (NAP) using IPv6 can provide the same or more benefits
without the need for NAT. without the need for NAT.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Perceived benefits of NAT and its impact on IPv4 . . . . . . 6 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 6
2.1 Simple gateway between Internet and internal network . . . 6 2.1. Simple Gateway between Internet and Private Network . . . 6
2.2 Simple security due to stateful filter implementation . . 6 2.2. Simple Security due to Stateful Filter Implementation . . 6
2.3 User/Application tracking . . . . . . . . . . . . . . . . 7 2.3. User/Application tracking . . . . . . . . . . . . . . . . 7
2.4 Privacy and topology hiding . . . . . . . . . . . . . . . 8 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8
2.5 Independent control of addressing in a private network . . 9 2.5. Independent Control of Addressing in a Private Network . . 9
2.6 Global address pool conservation . . . . . . . . . . . . . 9 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9
2.7 Multihoming and renumbering with NAT . . . . . . . . . . . 9 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10
3. Description of the IPv6 tools . . . . . . . . . . . . . . . 10 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 10
3.1 Privacy addresses (RFC 3041) . . . . . . . . . . . . . . . 10 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 10
3.2 Unique Local Addresses . . . . . . . . . . . . . . . . . . 11 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 11
3.3 DHCPv6 prefix delegation . . . . . . . . . . . . . . . . . 11 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 12
3.4 Untraceable IPv6 addresses . . . . . . . . . . . . . . . . 12 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 12
4. Using IPv6 technology to provide the market perceived 4. Using IPv6 Technology to Provide the Market Perceived
benefits of NAT . . . . . . . . . . . . . . . . . . . . . . 12 Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Simple gateway between Internet and internal network . . . 12 4.1. Simple Gateway between Internet and Internal Network . . . 13
4.2 IPv6 and Simple security . . . . . . . . . . . . . . . . . 13 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 13
4.3 User/Application tracking . . . . . . . . . . . . . . . . 14 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 15
4.4 Privacy and topology hiding using IPv6 . . . . . . . . . . 15 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 15
4.5 Independent control of addressing in a private network . . 15 4.5. Independent Control of Addressing in a Private Network . . 16
4.6 Global address pool conservation . . . . . . . . . . . . . 16 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 17
4.7 Multihoming and renumbering . . . . . . . . . . . . . . . 16 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 17
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1 Medium/large private networks . . . . . . . . . . . . . . 17 5.1. Medium/large private networks . . . . . . . . . . . . . . 18
5.2 Small private networks . . . . . . . . . . . . . . . . . . 19 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 20
5.3 Single user connection . . . . . . . . . . . . . . . . . . 20 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 21
5.4 ISP/Carrier customer networks . . . . . . . . . . . . . . 21 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 22
6. IPv6 gap analysis . . . . . . . . . . . . . . . . . . . . . 22 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 23
6.1 Completion of work on ULAs . . . . . . . . . . . . . . . . 22 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 23
6.2 Subnet topology masking . . . . . . . . . . . . . . . . . 22 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 23
6.3 Minimal traceability of privacy addresses . . . . . . . . 23 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 23
6.4 Renumbering procedure . . . . . . . . . . . . . . . . . . 23 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 24
6.5 Site multihoming . . . . . . . . . . . . . . . . . . . . . 23 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 24
6.6 Untraceable addresses . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . 23 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.1 Normative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
11.2 Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Additional Benefits due to Native IPv6 and
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Universal Unique Addressing . . . . . . . . . . . . . 27
A. Additional benefits due to Native IPv6 and universal A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 27
unique addressing . . . . . . . . . . . . . . . . . . . . . 27 A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 27
A.1 Universal any-to-any connectivity . . . . . . . . . . . . 27 A.3. Native Multicast Services . . . . . . . . . . . . . . . . 28
A.2 Auto-configuration . . . . . . . . . . . . . . . . . . . . 27 A.4. Increased Security Protection . . . . . . . . . . . . . . 28
A.3 Native Multicast services . . . . . . . . . . . . . . . . 28 A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.4 Increased security protection . . . . . . . . . . . . . . 28 A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 29
A.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.7. Community of interest . . . . . . . . . . . . . . . . . . 29
A.6 Merging networks . . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Revision history . . . . . . . . . . . . . . . . . . 30
A.7 Community of interest . . . . . . . . . . . . . . . . . . 29 B.1. Changes from *-vandevelde-v6ops-nap-00 to
B. Revision history . . . . . . . . . . . . . . . . . . . . . . 30
B.1 Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 30 *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 30
B.2 Changes from *-vandevelde-v6ops-nap-01 to B.2. Changes from *-vandevelde-v6ops-nap-01 to
*-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30 *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30
B.3 Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30
Intellectual Property and Copyright Statements . . . . . . . 31 B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
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. The serious disadvantages of address space is not needed in IPv6. The serious disadvantages of
ambiguous "private" address space and of Network Address Translation ambiguous "private" address space and of Network Address Translation
(NAT) [1][5] have been well documented [4][6]. However, given its (NAT) [1][5] have been well documented [4][6]. However, given its
wide market acceptance NAT undoubtedly has some perceived benefits. wide market acceptance NAT undoubtedly has some perceived benefits.
Indeed, in an Internet model based on universal any-to-any Indeed, in an Internet model based on universal any-to-any
connectivity, product marketing departments have driven a perception connectivity, product marketing departments have driven a perception
that some connectivity and security concerns can only be solved by hat some connectivity and security concerns can only be solved by
using a NAT device or by using logically separated LAN address using a NAT device or by using logically separated Local Area Network
spaces. This document describes the market-perceived reasons to (LAN) address spaces. This document describes the reasons for
utilize a NAT device in an IPv4 environment and shows how these needs utilizing a NAT device in an IPv4 environment that are regularly
can be met and even exceeded with IPv6. The use of the facilities cited in marketing pronouncements. It then shows how these needs can
from IPv6 described in this document avoids the negative impacts of be met without using NAT in an IPv6 network. Some of the IPv6
translation and may be described as Network Architecture Protection solutions offer advantages beyond the equivalent IPv4 NAT solution.
(NAP). The use of the facilities from IPv6 described in this document avoids
the negative impacts of address translation.
As far as security and privacy is concerned, this document considers As far as security and privacy is concerned, this document considers
how to mitigate a number of threats. Some are obviously external, how to mitigate a number of threats. Some are obviously external,
such as having a hacker trying to penetrate your network, or having a such as having a hacker trying to penetrate your network, or having a
worm infected machine outside your network trying to attack it. Some worm infected machine outside your network trying to attack it. Some
are local such as a disgruntled employee disrupting business are local such as a disgruntled employee disrupting business
operations, or the unintentional negligence of a user downloading operations, or the unintentional negligence of a user downloading
some malware which then proceeds to attack any device on the LAN. some malware which then proceeds to attack any device on the LAN.
Some may be embedded such as having some firmware in a domestic Some may be inherent in the device hardware ("embedded") such as
appliance "call home" to its manufacturer without the user's consent. having some firmware in a domestic appliance "call home" to its
manufacturer without the user's consent.
This document describes several techniques that may be combined on an This document describes several techniques that may be combined on an
IPv6 site to protect the integrity of its network architecture. IPv6 site to protect the integrity of its network architecture.
These techniques, known collectively as NAP, retain the concept of a These techniques, known collectively as Network Architecture
well defined boundary between "inside" and "outside" the private Protection (NAP), retain the concept of a well defined boundary
network, and allow firewalling, topology hiding, and privacy and will between "inside" and "outside" the private network, and allow
achieve these goals without address translation. firewalling, topology hiding, and privacy. NAP will achieve these
security goals without address translation whilst maintaining 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 functions of NAT with a following table. It presents the marketed "benefits" of NAT with a
cross-reference of how those are delivered in both the IPv4 and IPv6 cross-reference of how those are delivered in both the IPv4 and IPv6
environments. environments.
Function IPv4 IPv6 benefit 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 |
| and address pool | DHCP - limited | prefix upstream | | and address pool | DHCP - limited | prefix upstream |
| manager | number of individual | SLAAC via RA | | manager | number of individual | SLAAC via RA |
| | devices downstream | downstream | | | devices downstream | downstream |
| | see section 2.1 | see section 4.1 | | | see section 2.1 | see section 4.1 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Simple Security | Filtering side | Explicit Context | | Simple Security | Filtering side | Explicit Context |
| | effect due to lack | Based Access Control | | | effect due to lack | Based Access Control |
| | of translation state | (Reflexive ACL) | | | of translation state | (Reflexive ACL) |
| | see section 2.2 | see section 4.2 | | | see section 2.2 | see section 4.2 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Local usage | NAT state table | Address uniqueness | | Local usage | NAT state table | Address uniqueness |
| tracking | | | | tracking | | |
| | see section 2.3 | see section 4.3 | | | see section 2.3 | see section 4.3 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| End system | NAT transforms | Temporary use | | End-system | NAT transforms | Temporary use |
| privacy | device ID bits in | privacy addresses | | privacy | device ID bits in | privacy addresses |
| | the address | | | | the address | |
| | see section 2.4 | see section 4.4 | | | see section 2.4 | see section 4.4 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Topology hiding | NAT transforms | Untraceable addresses| | Topology hiding | NAT transforms | Untraceable addresses|
| | subnet bits in the | using IGP host routes| | | subnet bits in the | using IGP host routes|
| | address | /or MIPv6 tunnels for| | | address | /or MIPv6 tunnels for|
| | | stationary systems | | | | stationary systems |
| | see section 2.4 | see section 4.4 | | | see section 2.4 | see section 4.4 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
skipping to change at page 6, line 7 skipping to change at page 6, line 7
| | | 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 NAP can provide each of them. It
concludes with a IPv6 NAP case study and a gap analysis of work that concludes with a IPv6 NAP 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 NAP solution.
2. Perceived benefits of NAT and its impact on IPv4 2. Perceived Benefits of NAT and its Impact on IPv4
This section provides visibility into the generally perceived This section provides insight into the generally perceived benefits
benefits of the use of IPv4 NAT. The goal of this description is not of the use of IPv4 NAT as extolled by product marketing. The goal of
to analyze these benefits or discuss the accuracy of the perception this description is not to analyze these benefits or discuss the
(detailed discussions in [4]) , but to describe the deployment accuracy of the perception (detailed discussions in [4]), but to
requirements and set a context for the later descriptions of the IPv6 describe the deployment requirements and set a context for the later
approaches for dealing with those requirements. descriptions of the IPv6 approaches for dealing with those
requirements.
2.1 Simple gateway between Internet and internal network 2.1. Simple Gateway between Internet and Private Network
A NAT device can connect a private network with any kind of address A NAT device can connect a private network with any kind of address
(ambiguous [RFC 1918] or global registered address) towards the (ambiguous [RFC 1918] or global registered address) towards the
Internet. The address space of the private network can be built from Internet. The address space of the private network can be built from
globally unique addresses, from ambiguous address space or from both globally unique addresses, from ambiguous address space or from both
simultaneously. Without specific configuration from public to simultaneously. Without needing specific configuration, the NAT
private, the NAT device enables access between the client side of an device enables access between the client side of a distributed
application in the private network with the server side in the public client-server application in the private network and the server side
Internet. in the public Internet.
Wide-scale deployments have shown that using NAT to attach a private Wide-scale deployments have shown that using NAT to attach a private
IPv4 network to the Internet is simple and practical for the non- IPv4 network to the Internet is simple and practical for the non-
technical end user. Frequently a simple user interface is sufficient technical end user. Frequently a simple user interface, or even a
for configuring both device and application access rights. default configuration is sufficient for configuring both device and
application access rights.
Additionally, thanks to successful marketing campaigns it is Additionally, thanks to successful marketing campaigns it is
perceived by end users that their equipment is protected from the bad perceived by end users that their equipment is protected from the
elements and attackers on the public IPv4 Internet. malicious entities and attackers on the public IPv4 Internet.
2.2 Simple security due to stateful filter implementation 2.2. Simple Security due to Stateful Filter Implementation
A firewall doesn't fully secure a network, because many attacks come A firewall doesn't fully secure a network, because many attacks come
from inside or are at a layer higher than the firewall can protect from inside or are at a layer higher than the firewall can protect
against. In the final analysis, every system has to be responsible against. In the final analysis, every system has to be responsible
for its own security, and every process running on a system has to be for its own security, and every process running on a system has to be
robust in the face of challenges like stack overflows etc. What a robust in the face of challenges like stack overflows etc. What a
firewall does is prevent a network administration from having to pay firewall does is prevent a network administration from having to pay
for bandwidth to carry unauthorized traffic, and in so doing reduce for bandwidth to carry unauthorized traffic, and in so doing reduce
the probability of certain kinds of attacks across the protected the probability of certain kinds of attacks across the protected
boundary. boundary.
A distributed security mechanism to protect the end-systems may help A distributed security mechanism to protect the end-systems may help
in the above situation; however, to deploy such a system is quite in the above situation; however, to deploy such a system is quite
complex and may depend upon behaviour per operating system and complex and may depend upon behaviour per operating system and
release version. As a result it will probably not be available in release version. Also it will only be reliable if a mechanism such
the next couple of years for end-user organizations. End-system-only as 'trusted computing' is implemented in the end-system; without this
security mechanisms don't protect the network infrastructure from enhancement administrators will be unwilling to trust the behavior of
being misused for transit, or against DDOS attacks against individual end-systems. As a result it will probably not be available in the
systems inside, and this is the area where a NAT device is perceived next couple of years for end-user organizations. End-system-only
to provide some relief. security mechanisms do not protect the network infrastructure from
being misused for transit, or against Distributed Denial of Service
(DDOS) attacks against individual systems inside: and this is the
area where a NAT device is perceived to provide some protection.
It is frequently believed that through its session-oriented It is frequently believed that through its session-oriented
operation, NAT puts in an extra barrier to keep the private network operation, NAT puts in an extra barrier to keep the private network
protected from evil outside influences. Since a NAT device typically protected from outside influences. Since a NAT device typically
keeps state only for individual sessions, attackers, worms, etc. keeps state only for individual sessions, attackers, worms, etc.
cannot exploit this state to attack a host in general and on any cannot exploit this state to attack a host in general and on any
port. This benefit may be partially real, however, experienced port. This benefit may be partially real, however, experienced
hackers are well aware of NAT devices and are very familiar with hackers are well aware of NAT devices and are very familiar with
private address space, and have devised methods of attack (such as private address space, and have devised methods of attack (such as
trojan horses) that readily penetrate NAT boundaries. For these trojan horses) that readily penetrate NAT boundaries. For these
reasons the sense of security provided by NAT are actually false. reasons the sense of security provided by NAT is actually an
illusion.
Address translation does not provide security in itself; for example, Address translation does not provide security in itself; for example,
consider a configuration with static NAT translation and all inbound consider a configuration with static NAT translation and all inbound
ports translating to a single machine. In such a scenario the ports translating to a single machine. In such a scenario the
security risk for that machine is identical to the case with no NAT security risk for that machine is identical to the case with no NAT
device in the communication path. As result there is no specific device in the communication path. As result there is no specific
security value in the address translation function. The perceived security value in the address translation function. The perceived
security comes from the lack of pre-established or permanent mapping security comes from the lack of pre-established or permanent mapping
state. Dynamically establishing state in response to internal state. Dynamically establishing state in response to internal
requests reduces the threat of unexpected external connections to requests reduces the threat of unexpected external connections to
internal devices. internal devices.
In some cases, NAT operators (including domestic users) may be In some cases, NAT operators (including domestic users) may be
obliged to configure quite complex port mapping rules to allow obliged to configure quite complex port mapping rules to allow
external access to local applications such as a multi-player game or external access to local applications such as a multi-player game or
web servers. In this case the NAT actually adds management web servers. In this case the NAT actually adds management
complexity compared to a simple router. In situations where 2 or complexity compared to a simple router. In situations where two or
more devices need to host the same application this complexity shifts more devices need to host the same application this complexity shifts
from difficult to impossible. from difficult to impossible.
2.3 User/Application tracking 2.3. User/Application tracking
Although NATs create temporary state for active sessions, in general Although NATs create temporary state for active sessions, in general
they provide limited capabilities for the administrator of the NAT to they provide limited capabilities for the administrator of the NAT to
gather information about who in the private network is requesting gather information about who in the private network is requesting
access to which Internet location. This could in theory be done by access to which Internet location. This could in theory be done by
logging the network address translation details of the private and logging the network address translation details of the private and
the public addresses of the NAT devices state database. the public addresses from the NAT device's state database.
The checking of this database is not always a simple task, especially The checking of this database is not always a simple task, especially
if Port Address Translation is used. It also has an unstated if Port Address Translation is used. It also has an unstated
assumption that the administrative instance has a mapping between an assumption that the administrative instance has a mapping between an
IPv4-address and a network element or user at all times, or the IPv4-address and a network element or user at all times, or the
administrator has a time-correlated list of the address/port administrator has a time-correlated list of the address/port
mappings. mappings.
2.4 Privacy and topology hiding 2.4. Privacy and Topology Hiding
The ability of NAT to provide internet access by the use of a single The goal of 'topology hiding' is to provide devices on the private
(or few) global IPv4 routable addresses to a large community of users network with an identifier (IPv4 address) which an entity outside the
offers a simple mechanism to hide the internal topology of a network. network can use to communicate with or to reference the private
In this scenario the large community will be reflected in the network devices in protocols but prevents the external entity making
internet by a single (or few) IPv4 address(es). a correlation between the topological location of the private device
and the address on the local network.
The ability of NAT to provide Internet access to a large community of
users by the use of a single (or a few) global IPv4 routable
addresses offers a simple mechanism to hide the internal topology of
a network. In this scenario the large community will be represented
in the Internet by a single (or a few) IPv4 address(es).
The use of NAT then results in a user behind a NAT gateway actually The use of NAT then results in a user behind a NAT gateway actually
appearing on the Internet as a user inside the NAT box itself; i.e., appearing on the Internet as a user inside the NAT box itself; i.e.,
the IPv4 address that appears on the Internet is only sufficient to the IPv4 address that appears on the Internet is only sufficient to
identify the NAT. When concealed behind a NAT it is impossible to identify the NAT. When concealed behind a NAT it is impossible to
tell from the outside which member of a family, which customer of an tell from the outside which member of a family, which customer of an
Internet cafe, or which employee of a company generated or received a Internet cafe, or which employee of a company generated or received a
particular packet. Thus, although NATs do nothing to provide particular packet. Thus, although NATs do nothing to provide
application level privacy, they do prevent the external tracking and application level privacy, they do prevent the external tracking and
profiling of individual host computers by means of their IP profiling of individual host computers by means of their IP
addresses. At the same time a NAT creates a smaller pool of addresses, usually known as 'device profiling'. At the same time a
addresses for a much more focused point of attack. NAT creates a smaller pool of addresses for a much more focused point
of attack.
There is a similarity with privacy based on application level There is a similarity with privacy based on application level
proxies. When using an application level gateway for browsing the proxies. When using an application level gateway for browsing the
web for example, the 'privacy' of a web user can be provided by web for example, the 'privacy' of a web user can be provided by
masking the true identity of the original web user towards the masking the true identity of the original web user towards the
outside world (although the details of what is - or is not - logged outside world (although the details of what is - or is not - logged
at the NAT/proxy will be different). at the NAT/proxy will be different).
Some enterprises prefer to hide as much as possible of their internal Some enterprises prefer to hide as much as possible of their internal
network topology from outsiders. Mostly this is achieved by blocking network topology from outsiders. Mostly this is achieved by blocking
"traceroute" etc., but NAT of course entirely hides the internal "traceroute" etc., but NAT of course entirely hides the internal
subnet topology, which some network managers believe is a useful subnet topology, which some network managers believe is a useful
precaution to mitigate scanning attacks. Scanning for IPv6 can be precaution to mitigate scanning attacks. Scanning for IPv6 can be
much harder in comparison with IPv4 as described in [17] much harder in comparison with IPv4 as described in [18].
Once a list of available devices and IP addresses has been mapped, a Once a list of available devices and IP addresses has been mapped, a
port-scan on these IP addresses can be performed. Scanning works by port-scan on these IP addresses can be performed. Scanning works by
tracking which ports do not receive unreachable errors from either tracking which ports do not receive unreachable errors from either
the firewall or host. With the list of open ports an attacker can the firewall or host. With the list of open ports an attacker can
optimize the time needed for a successful attack by correlating it optimize the time needed for a successful attack by correlating it
with known vulnerabilities to reduce the number of attempts. For with known vulnerabilities to reduce the number of attempts. For
example, FTP usually runs on port 21, and HTTP usually runs on port example, FTP usually runs on port 21, and HTTP usually runs on port
80. These open ports could be used for initiating attacks on an end 80. Any vulnerable open ports could be used for initiating attacks
system. on an end system.
2.5 Independent control of addressing in a private network 2.5. Independent Control of Addressing in a Private Network
Many private IPv4 networks take benefit from using the address space Many private IPv4 networks take benefit from using the address space
defined in RFC 1918 to enlarge the available addressing space for defined in RFC 1918 to enlarge the available addressing space for
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 clean and hierarchical addressing structure in the resources allows a clean and hierarchical addressing structure in the
network. 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.
2.6 Global address pool conservation Section 2.7 describes some disadvantages that appear if independent
networks using [RFC1918] addresses have to be merged.
2.6. Global Address Pool Conservation
Due to the ongoing depletion of the IPv4 address range, the remaining Due to the ongoing depletion of the IPv4 address range, the remaining
pool of unallocated IPv4 addresses is below 30%. While mathematical pool of unallocated IPv4 addresses is below 30%. While mathematical
models based on historical IPv4 prefix consumption periodically models based on historical IPv4 prefix consumption periodically
attempt to predict the future exhaustion date of the IPv4 address attempt to predict the future exhaustion date of the IPv4 address
pool, a direct result of this continuous resource consumption is that pool, a direct result of this continuous resource consumption is that
the administrative overhead for acquiring globally unique IPv4 the administrative overhead for acquiring globally unique IPv4
addresses will continue increasing in direct response to tightening addresses will continue increasing in direct response to tightening
allocation policies. In response to the increasing administrative allocation policies. In response to the increasing administrative
overhead many Internet Service Providers (ISPs) have already resorted overhead many Internet Service Providers (ISPs) have already resorted
to the ambiguous addresses defined in RFC 1918 behind a NAT for the to the ambiguous addresses defined in RFC 1918 behind a NAT for the
various services they provide as well as connections for their end various services they provide as well as connections for their end
customers. In turn this has restricted the number of and types of customers. This happens even though that private address-space is
applications that can be deployed by these ISPs and their customers. strictly limited in size. In turn this has restricted the number of
Forced into this limiting situation such customers can rightly claim and types of applications that can be deployed by these ISPs and
that despite the optimistic predictions of mathematical models the their customers. Forced into this limiting situation such customers
global pool of IPv4 addresses is effectively already exhausted. can rightly claim that despite the optimistic predictions of
mathematical models the global pool of IPv4 addresses is effectively
already exhausted, especially for larger enterprises.
2.7 Multihoming and renumbering with NAT 2.7. Multihoming and Renumbering with NAT
The elements of multihoming and renumbering are quite different. Allowing a network to be multihomed and renumbering a network are
However, multihoming is often a transitional state for renumbering, quite different functions. However, making a network multihomed is
often a transitional state required as part of network renumbering,
and NAT interacts with both in the same way. and NAT interacts with both in the same way.
For enterprise networks, it is highly desirable to be connected to For enterprise networks, it is highly desirable to provide resiliency
more than one Internet Service Provider (ISP) and to be able to and load-balancing to be connected to more than one Internet Service
change ISPs at will. This means that a site must be able to operate Provider (ISP) and to be able to change ISPs at will. This means
under more than one CIDR prefix [13] and/or readily change its CIDR that a site must be able to operate under more than one CIDR prefix
prefix. Unfortunately, IPv4 was not designed to facilitate either of [14] and/or readily change its CIDR prefix. Unfortunately, IPv4 was
these maneuvers. However, if a site is connected to its ISPs via NAT not designed to facilitate either of these maneuvers. However, if a
boxes, only those boxes need to deal with multihoming and renumbering site is connected to its ISPs via NAT boxes, only those boxes need to
issues. deal with multihoming and renumbering issues.
Similarly, if two enterprise IPv4 networks need to be merged, it may Similarly, if two enterprise IPv4 networks need to be merged and
well be that installing a NAT box between them will avoid the need to RFC1918 addresses are used, there is a high probability of address
renumber one or both. For any enterprise, this can be a short term overlaps. In those situations it may well be that installing a NAT
financial saving, and allow more time to renumber the network box between them will avoid the need to renumber one or both. For
components. The long term solution is a single network without usage any enterprise, this can be a short term financial saving, and allow
of NAT to avoid the ongoing operational complexity of overlapping more time to renumber the network components. The long term solution
addresses. is a single network without usage of NAT to avoid the ongoing
operational complexity of overlapping addresses.
This solution may be sufficient for some networks; however when the The addition of an extra NAT as a solution may be sufficient for some
merging networks were already using address translation it will networks; however when the merging networks were already using
create huge problems due to admistrative difficulties of the merged address translation it will create huge problems due to
address space. administrative difficulties of overlapping address speaces in the
merged networks.
3. Description of the IPv6 tools 3. Description of the IPv6 Tools
This section describes several features that can be used to provide This section describes several features that can be used as part of
the protection features associated with IPv4 NAT. the NAP solution to emulate the protection features associated with
IPv4 NAT.
3.1 Privacy addresses (RFC 3041) 3.1. Privacy Addresses (RFC 3041)
There are situations where it is desirable to prevent device There are situations where it is desirable to prevent device
profiling, such as by contacted web sites, so IPv6 privacy addresses profiling, for example by web sites that are accessed from the
were defined to provide that capability. IPv6 addresses consist of a device; IPv6 privacy addresses were defined to provide that
routing prefix, subnet-id part (SID) and an interface identifier part capability. IPv6 addresses consist of a routing prefix, subnet-id
(IID). For interfaces that contain embedded IEEE Link Identifiers part (SID) and an interface identifier part (IID). For interfaces
the interface identifier is typically derived from it, though this that contain embedded IEEE Link Identifiers the interface identifier
practice facilitates tracking and profiling of a device as it moves is typically derived from it, though this practice facilitates
around the Internet. RFC 3041 describes an extension to IPv6 tracking and profiling of a device as it moves around the Internet.
stateless address autoconfiguration for interfaces [7]. Use of the RFC 3041 describes an extension to IPv6 stateless address
privacy address extension causes nodes to generate global-scope autoconfiguration (SLAAC) for interfaces [7]. Use of the privacy
addresses from interface identifiers that change over time, even in address extension causes nodes to generate global-scope addresses
cases where the interface contains an embedded IEEE link identifier. from interface identifiers that change over time, even in cases where
Changing the interface identifier (thus the global-scope addresses the interface contains an embedded IEEE link identifier. Changing
generated from it) over time makes it more difficult for the interface identifier (thus the global-scope addresses generated
eavesdroppers and other information collectors to identify when from it) over time makes it more difficult for eavesdroppers and
addresses used in different transactions actually correspond to the other information collectors to identify when addresses used in
same node. A relatively short valid lifetime for the privacy address different transactions actually correspond to the same node. A
also has the side effect of reducing the attack profile of a device, relatively short valid lifetime for the privacy address also has the
as it is not directly attackable once it stops answering at the side effect of reducing the attack profile of a device, as it is not
temporary use address. directly attackable once it stops answering at the temporary use
address.
While the primary implementation and source of randomized RFC 3041 While the primary implementation and source of randomized RFC 3041
addresses is expected to be from end systems running stateless addresses is expected to be from end-systems running stateless
autoconfiguration, there is nothing that prevents a DHCP server from autoconfiguration, there is nothing that prevents a DHCP server from
running the RFC 3041 algorithm for any new IEEE identifier it hears, running the RFC 3041 algorithm for any new IEEE identifier it hears,
then remembering that for future queries. This would allow using then remembering that for future queries. This would allow using
them in DNS for registered services since the assumption of a server them in DNS for registered services since the assumption of a server
based deployment would be a persistent value that minimizes DNS based deployment would be a persistent value that minimizes DNS
churn. A DHCP based deployment would also allow for local policy to churn. A DHCP based deployment would also allow for local policy to
periodically change the entire collection of end device addresses periodically change the entire collection of end device addresses
while maintaining some degree of central knowledge and control over while maintaining some degree of central knowledge and control over
which addresses should be in use at any point in time. which addresses should be in use at any point in time.
Randomizing the IID, as defined in RFC 3041, only precludes tracking Randomizing the IID, as defined in RFC 3041, only precludes tracking
of the lower 64 bits of the IPv6 address. Masking of the subnet ID of the lower 64 bits of the IPv6 address. Masking of the subnet ID
will require additional approaches as discussed below in 3.4. will require additional approaches as discussed below in 3.4.
Additional considerations are discussed in [16]. Additional considerations are discussed in [17].
3.2 Unique Local Addresses 3.2. Unique Local Addresses
Local network and application services stability during periods of Local network and application services stability during periods of
intermittent connectivity between one or more providers requires intermittent connectivity between one or more providers requires
address management autonomy. Such autonomy in a single routing address management autonomy. Such autonomy in a single routing
prefix environment would lead to massive expansion of the global prefix environment would lead to massive expansion of the global
routing tables, so IPv6 provides for simultaneous use of multiple routing tables, so IPv6 provides for simultaneous use of multiple
prefixes. The Unique Local Address prefix (ULA) [12] has been set prefixes. The Unique Local Address prefix (ULA) [13] has been set
aside for use in local communications. The ULA address prefix for aside for use in local communications. The ULA address prefix for
any network is routable over a locally defined collection of routers. any network is routable over a locally defined collection of routers.
These prefixes are NOT to be routed on the public global Internet as These prefixes are not intended to be routed on the public global
that would have a serious negative impact on global routing. Internet; large scale inter-domain distribution of routes to ULA
prefixes would have a negative impact on global route aggregation.
ULAs have the following characteristics: ULAs have the following characteristics:
o Globally unique prefix o Globally unique prefix
* Allows networks to be combined or privately interconnected * Allows networks to be combined or privately interconnected
without creating any address conflicts or requiring renumbering without creating any address conflicts or requiring renumbering
of interfaces using these prefixes of interfaces using these prefixes
* If accidentally leaked outside of a network via routing or DNS, * If accidentally leaked outside of a network via routing or DNS,
there is no conflict with any other addresses it is highly unlikely that there will be a conflict with any
other addresses
o ISP independent and can be used for communications inside of a o ISP independent and can be used for communications inside of a
network without having any permanent or intermittent Internet network without having any permanent or intermittent Internet
connectivity connectivity
o Well known prefix to allow for easy filtering at network o Well-known prefix to allow for easy filtering at network
boundaries 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 scoped addresses but address selection algorithms need to
distinguish between ULAs and ordinary global scope unicast
addresses. Mixing the two kinds of addresses is likely to lead to
undeliverable packets.
3.3 DHCPv6 prefix delegation 3.3. DHCPv6 Prefix Delegation
The Prefix Delegation (DHCP-PD) options [10] provide a mechanism for The Prefix Delegation (DHCP-PD) options [11] provide a mechanism for
automated delegation of IPv6 prefixes using the Dynamic Host automated delegation of IPv6 prefixes using the Dynamic Host
Configuration Protocol (DHCP) [8]. This mechanism (DHCP-PD) is Configuration Protocol (DHCP) [9]. This mechanism (DHCP-PD) is
intended for delegating a long-lived prefix from a delegating router intended for delegating a long-lived prefix from a delegating router
to a requesting router, across an administrative boundary, where the (incorporating a DHCPv6 server) to a requesting router, possibly
delegating router does not require knowledge about the topology of across an administrative boundary, where the delegating router does
the links in the network to which the prefixes will be assigned. not require knowledge about the topology of the links in the network
to which the prefixes will be assigned.
3.4 Untraceable IPv6 addresses 3.4. Untraceable IPv6 Addresses
These should be globally routable IPv6 addresses which can be These should be globally routable IPv6 addresses which can be
randomly and independently assigned to IPv6 devices. randomly and independently assigned to IPv6 devices.
The random assignment has as purpose to confuse the outside world on The random assignment is intended to mislead the outside world about
the structure of the local network. However for the local network the structure of the local network. However the local network needs
there is a correlation between the location of the device and the to maintain a correlation between the location of the device and the
untraceable IPv6 address. This correlation could be done by untraceable IPv6 address. This correlation could be done by
generating IPv6 host route entries or by utilizing an aggregation generating IPv6 host route entries or by utilizing an indirection
device like a Mobile IPv6 Home Agent. device such as a Mobile IPv6 Home Agent.
The main goal of untraceable IPv6 addresses is to create an The main goal of untraceable IPv6 addresses is to create an
apparently unpredictable 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 or from mapping 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 reachable on very different parts of the sequential addresses are allocated to devices on very different parts
local network instead of belonging to the same subnet next to each of the local network instead of belonging to devices adjacent to each
other. other on the same subnet.
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 can be used to provide the protection The facilities in IPv6 described in Section 3 can be used to provide
perceived to be associated with IPv4 NAT. This section gives some the protection perceived to be associated with IPv4 NAT. This
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 has the role of managing both packet As a simple gateway, the device manages both packet routing and local
routing and local address management. A basic IPv6 router could have address management. A basic IPv6 router could have a default
a default configuration to advertize inside the site a locally configuration to advertise inside the site a locally generated random
generated random ULA prefix, independently from the state of any ULA prefix, independently from the state of any external
external connectivity. This would allow local nodes to communicate connectivity. This would allow local nodes to communicate amongst
amongst themselves prior to establishing a global connection. If the themselves prior to establishing a global connection. If the network
network happened to concatenate with another local network, this is happened to concatenate with another local network, this is highly
highly unlikely to result in address collisions. With external unlikely to result in address collisions. A more secure network
connectivity the simple gateway could also use DHCP-PD to acquire a environment can be established by having the referenced ULA addresses
routing prefix from the service provider for use when connecting to statically configured on the network devices as this decreases the
the global Internet. End node connections involving other nodes on dynamic aspects of the network, however the operational overhead is
the global Internet will always use the global IPv6 addresses [9] increased.
derived from this prefix delegation. In the very simple case there
is no explicit routing protocol and a single default route is used
out to the global Internet. A slightly more complex case might
involve local routing protocols, but with the entire local network
sharing a common global prefix there would still not be a need for an
external routing protocol as a default route would continue to be
consistent with the connectivity.
4.2 IPv6 and Simple security With external connectivity the simple gateway could also use DHCP-PD
to acquire a routing prefix from the service provider for use when
connecting to the global Internet. End-system connections involving
other nodes on the global Internet will always use the global IPv6
addresses [9] derived from this prefix delegation. It should be
noted that the address selection policy table in end-systems needs to
be correctly set up so that true global prefixes are distinguished
from ULAs and will be used for the source address in preference when
the destination is not a ULA.
The vulnerability of an IPv6 host is similar as for an IPv4 host In the very simple case there is no explicit routing protocol and a
directly connected towards the Internet, and firewall and IDS systems single default route is used out to the global Internet. A slightly
are recommended. A proxy may be used for certain applications, but more complex case might involve local routing protocols, but with the
has the caveat that the end to end transparancy is broken. However, entire local network sharing a common global prefix there would still
with IPv6, the following protections are available without the use of not be a need for an external routing protocol as a default route
NAT while maintaining end-to-end reachability: would continue to be consistent with the connectivity.
4.2. IPv6 and Simple Security
The vulnerability of an IPv6 host is similar to that of an IPv4 host
directly connected towards the Internet. The use of firewall and
Intrusion Detection Systems (IDS) is recommended. A proxy may be
used for certain applications, but with the caveat that the end to
end transparancy is broken. However, with IPv6, the following
protections are available without the use of NAT while maintaining
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 the profile since the node will not respond to the address once the
address is no longer valid. address is no longer valid.
2. IPsec is a mandatory service for IPv6 implementations. IPsec 2. IPsec is a mandatory service for IPv6 implementations. IPsec
functions to prevent session hijacking, prevent content functions to prevent session hijacking, prevent content
tampering, and optionally masks the packet contents. While IPsec tampering, and optionally masks the packet contents. While IPsec
might be available in IPv4 implementations, deployment in NAT might be available in IPv4 implementations, deployment in NAT
environments either breaks the protocol or requires complex environments either breaks the protocol or requires complex
helper services with limited functionality or efficiency. helper services with limited functionality or efficiency.
3. The size of the typical subnet ::/64 will make a network ping 3. The size of the address space of a typical subnet (64 bits of
sweep and resulting port-scan virtually impossible due to the IID) will make an effective network ping sweep and resulting
amount of possible combinations available. This goes from the port-scan virtually impossible due to the number of possible
assumption that the attacker has no access to a local connection. combinations available, provided that IIDs are essentially
randomly distributed across the available space. This protection
is nullified if the attacker has no access to a local connection.
If an attacker has local access then he could use ND [3] and If an attacker has local access then he could use ND [3] and
ping6 to ff02::1 to detect local neighbors. (Of course, a ping6 to ff02::1 to detect local neighbors. (Of course, a
locally connected attacker has many scanning options with IPv4 as locally connected attacker has many scanning options with IPv4 as
well.) It is recommended for site administrators to take [17] well.) It is recommended for site administrators to take [18]
into consideration to achieve the expected goal. into consideration to achieve the expected goal. This protection
will also be nullified if IIDs are configured in a group near the
start of the IID space.
IPv4 NAT was not developed as a security mechanism. Despite IPv4 NAT was not developed as a security mechanism. Despite
marketing messages to the contrary it is not a security mechanism, marketing messages to the contrary it is not a security mechanism,
and hence it will pose some security holes while many people assume and hence it will offer some security holes while many people assume
their network is secure due to the usage of NAT. This is directly their network is secure due to the usage of NAT. IPv6 security best
the opposite of what IPv6 security best-practices are trying to practices will avoid this kind of illusory security but can only do
achieve. this if correctly configured firewalls and IDS systems are used at
the perimeter where some IPv4 networks have relied on NATs.
An example of a potential set of firewall rules could be:
Source_A: IPv6 Home broadband user
located on the internal network
Destination_B: IPv6 HTTP server
located on the external network
On the edge broadband router a security rule could be:
Internal network -> external network:
Actions:
Allow all traffic
Create reflective session state (true) for the session
External network -> internal network
Actions: To implement simple security for IPv6 in, for example, a DSL
If the session had reflective 'true'-state, connected home network, the DSL broadband gateway/router should be
then allow the inbound traffic equipped with stateful firewall capabilities. These should provide a
If the session had reflective 'false' state, default configuration which provides a minimum set of connectivity
then drop the traffic for users in the home network (e.g., just to external HTTP servers)
with incoming traffic limited to return traffic resulting from
outgoing packets (sometimes known as reflective session state) with
an easy interface which allows users to create additional 'pinholes'
for specific purposes.
This simple rule would create similar protection and security holes Administrators and the designers of configuration interfaces for
the typical IPv4 NAT device will offer and may for example be enabled simple IPv6 Firewalls need to provide a means of documenting the
by a simple user-interface and should provide the facility with a security caveats that arise from a given set configuration rules so
simple mechanism to create holes in the rules to serve certain that users (who are normally oblivious to such things) can be made
applications on edge-routers, with that difference that the security aware of the risks. As rules are improved iteratively, the goal will
caveats will be documented, and may hence be removed with the next be to make use of the IPv6 Internet more secure for oblivious users.
revision of the rule. The goal is that at every iteration, the IPv6
internet will become more secure for the oblivious users.
Assuming the network administrator is aware of [17] the increased Assuming the network administrator is aware of [18] the increased
size of the IPv6 address will make topology probing much harder, and size of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices. What one does when topology almost impossible for IPv6 devices. The intention of topology
probing is to get an idea 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. This is an enterprise. This mostly starts with a ping-sweep. Since the IPv6
automated procedure of sending Internet Control Message Protocol subnets are 64 bits worth of address space, this means that an
(ICMP) echo requests (also known as PINGs) to a range of IP addresses attacker has to send out a simply unrealistic number of pings to map
and recording replies. This can enable an attacker to map the the network, and virus/worm propagation will be thwarted in the
network. Since the IPv6 subnets are 64 bits worth of address space, process. At full rate 40Gbps (400 times the typical 100Mbps LAN, and
this means that an attacker has to send out a simply unrealistic 13,000 times the typical DSL/Cable access link) it takes over 5000
number of pings to map the network, and virus/worm propagation will years to scan a single 64 bit space.
be thwarted in the process. At full rate 40Gbps (400 times the
typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access
link) it takes over 5000 years to scan a single 64 bit space.
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. This enhances the capability of data-flow
tracking for security audits compared with IPv4 NAT, because in IPv6 tracking for security audits compared with IPv4 NAT, because in IPv6
a flow between a sender and receiver will always be uniquely a flow between a sender and receiver will always be uniquely
identified due to the unique IPv6 source and destination addresses. identified due to the unique IPv6 source and destination addresses.
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 can use an address that is valid only for a limited time. session can use an address that is valid only for a limited time.
Exactly like IPv4 NAT, this only allows such a session to be traced Exactly as with IPv4 NAT, this only allows such a session to be
back to the subnet that originates it, but not immediately to the traced back to the subnet that originates it, but not immediately to
actual host. the actual host.
If a network manager wishes to conceal the internal IPv6 topology, Due to the large IPv6 address space available there is plenty of
and the majority of its host computer addresses, a good option will freedom to randomize subnet allocations. By doing this, it is
be to run all internal traffic using ULA since such packets can by possible to reduce the correlation between a subnet and its location.
definition never exit the site. For hosts that do in fact need to When doing both subnet and IID randomization [RFC 3041] a casual
generate external traffic, by using multiple IPv6 addresses (ULAs and snooper won't be able to deduce much about the networks topology.
one or more global addresses), it will be possible to hide and mask The obtaining of a single address will tell the snooper very little
some or all of the internal network. As discussed above, there are about other addresses. This is different from IPv4 where address
space limitations cause this to be not true. In most usage cases
this concept should be sufficient for address privacy and topology
hiding.
In the case where a network administrator wishes to fully conceal the
internal IPv6 topology, and the majority of its host computer
addresses, a possible option is to run all internal traffic using
Unique Local Addresses (ULA) since such packets can by definition
never exit the site. For hosts that do in fact need to generate
external traffic, by using multiple IPv6 addresses (ULAs and one or
more global addresses), it will be possible to hide and mask some or
all of the internal network. As discussed in Section 3.1, there are
multiple parts to the IPv6 address, and different techniques to multiple parts to the IPv6 address, and different techniques to
manage privacy for each. manage privacy for each.
When a network manager also wishes to conceal the internal IPv6 There are two possible scenarios for the extreme situation when a
topology, by using explicit host routes it is possible to locate network manager also wishes to fully conceal the internal IPv6
nodes on one segment while they appear externally to be on another. topology.
An alternative method to hide the internal topology would be to use
Mobile IPv6 internally without route optimization where the public
facing addresses are consolidated on an edge Home Agent (HA), then
use MIPv6 in bidirectional tunnel mode between the HA and topology
masked node using the ULA as a COA. This truly masks the internal
topology as all nodes with global access appear to share a common
subnet. There is no reason that rack mounted devices couldn't be
considered mobile nodes to mask the internal topology. It looks
equivalent to running a VPN to a central server, however it does not
involve any encryption or significant overhead.
4.5 Independent control of addressing in a private network o One could use explicit host routes and remove the correlation
between location and IPv6 address. This solution does however
show severe scalability issues.
o The other technology to fully hide the internal topology would be
to use a tunneling mechanism. Mobile IPv6 without route
optimization is one example. In this example the public facing
addresses are indirected via an edge Home Agent (HA). This
indirection method truly masks the internal topology as all nodes
with global access appear to share a common prefix. The downside
of using this method is that it makes usage of middleware like a
Home Agent (HA).
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 a NAT is not required (or even defined) between per interface so that an IPv6 NAT is not required between the ULA and
the ULA and the public Internet. Nodes that need access to the the public Internet. Nodes that need access to the public Internet
public Internet may have a ULA for local use, and will have a global may have a ULA for local use, and will have a global use address
use address because the global use IPv6 address space is not a scarce because the global use IPv6 address space is not a scarce resource
resource like the global use IPv4 space. While global IPv6 like the global use IPv4 space. While global IPv6 allocation policy
allocation policy is managed through the Regional Internet is managed through the Regional Internet Registries, it is expected
Registries, it is expected that they will continue with derivatives that they will continue with derivatives of [RFC 3177] for the
of RFC 3177 for the foreseeable future. foreseeable future.
When using IPv6, the need to ask for more address space will become When using IPv6, the need to ask for more address space will become
far less likely due to the increased size of the subnets. These far less likely due to the increased size of the subnets. These
subnets typically allow 2^64 hosts per subnet and an enterprise will subnets typically allow 2^64 addresses per subnet and an enterprise
typically receive a /48 which allows segmentation into at least 2^16 will typically receive a /48 which allows segmentation into at least
different subnets. 2^16 different subnets.
The ongoing subnet size maintenance may become simpler when IPv6 The ongoing subnet size maintenance may become simpler when IPv6
technology is utilised. If IPv4 address space is optimised one has technology is utilised. If IPv4 address space is optimised one has
periodically to look into the number of hosts on a segment and the to look periodically into the number of hosts on a segment and the
subnet size allocated to the segment; an enterprise today may have a subnet size allocated to the segment; an enterprise today may have a
mix of /28 - /23 size subnets for example, and may shrink/grow these mix of /28 - /23 size subnets for example, and may shrink/grow these
as their network user base/etc changes. In v6, it's all /64. as their network user base changes. For IPv6 all subnets have /64
prefixes.
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, overlapping address space,
340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total
possible addresses. As previously discussed, the serious possible addresses. 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
lead to the IPv4 practice of ambiguous space behind a NAT. As an require the adoption of the IPv4 workaround of ambiguous space behind
example of the direct contrast, many expansion oriented IPv6 a NAT. As an example of the direct contrast, many expansion oriented
deployment scenarios result in multiple IPv6 addresses per device, as IPv6 deployment scenarios result in multiple IPv6 addresses per
opposed to the IPv4 constricting scenarios of multiple devices device, as opposed to the constriction of IPv4 scenarios where
sharing a scarce global address. multiple devices are forced to share a scarce global address.
4.7 Multihoming and renumbering 4.7. Multihoming and Renumbering
Multihoming and renumbering remain technically challenging with IPv6 Multihoming and renumbering remain technically challenging with IPv6
(see the Gap Analysis below). However, IPv6 was designed to allow (see the Gap Analysis below). However, IPv6 was designed to allow
sites and hosts to run with several simultaneous CIDR-like prefixes sites and hosts to run with several simultaneous CIDR-like prefixes
and thus with several simultaneous ISPs. An address selection and thus with several simultaneous ISPs. An address selection
mechanism [9] is specified so that hosts will behave consistently mechanism [10] is specified so that hosts will behave consistently
when several addresses are simultaneously valid. The fundamental when several addresses are simultaneously valid. The fundamental
difficulty that IPv4 has in this regard therefore does not apply to difficulty that IPv4 has in this regard therefore does not apply to
IPv6. IPv6 sites can and do run today with multiple ISPs active, and IPv6. IPv6 sites can and do run today with multiple ISPs active, and
the processes for adding and removing active prefixes at a site have the processes for adding and removing active prefixes at a site have
been documented [11] and [18]. been documented [12] and [19].
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 may result in a renumbering the connecting Service provider. This may result in a renumbering
effort if the network changes from Service Provider. When changing effort if the network changes from Service Provider. When changing
ISPs or ISPs readjusting their addressing pool, DHCP-PD [10] can be ISPs or ISPs readjusting their addressing pool, DHCP-PD [11] can be
used as the zero-touch external mechanism for prefix change in used as an almost zero-touch external mechanism for prefix change in
conjunction with a ULA prefix for internal connection stability. conjunction with a ULA prefix for internal connection stability.
With appropriate management of the lifetime values and overlap of the With appropriate management of the lifetime values and overlap of the
external prefixes, a smooth make-before-break transition is possible external prefixes, a smooth make-before-break transition is possible
as existing communications will continue on the old prefix as long as as existing communications will continue on the old prefix as long as
it remains valid, while any new communications will use the new it remains valid, while any new communications will use the new
prefix. prefix.
5. Case Studies 5. Case Studies
It is possible to divide the type of networks in different In presenting these case studies we have chosen to consider
categories. This can be done on various criteria. The criteria used categories of network divided first according to their function
within this document are based on the number of components or either as carrier/ISP networks or end user (such as enterprise)
connections. For each of these category of networks we can use IPv6 networks with the latter category broken down according to the number
Network Architecture Protection to achieve a secure and flexible of connected end hosts. For each of these category of networks we
infrastructure, which provides an enhanced network functionality in can use IPv6 Network Architecture Protection to achieve a secure and
comparison with the usage of address translation. flexible infrastructure, which provides an enhanced network
functionality in comparison with the usage of address translation.
o Medium/large private networks (typically >10 connections) o Medium/Large Private Networks (typically >10 connections)
o Small private networks (typically 1 to 10 connections) o Small Private Networks (typically 1 to 10 connections)
o Single user connection (typically 1 connection) o Single User Connection (typically 1 connection)
o ISP/Carrier customer networks o ISP/Carrier Customer Networks
5.1 Medium/large private networks 5.1. Medium/large private networks
Under this category fall the majority of private enterprise networks. The majority of private enterprise networks fall into this category.
Many of these networks have one or more exit points to the Internet. Many of these networks have one or more exit points to the Internet.
Though these organizations have sufficient resources to acquire Though these organizations have sufficient resources to acquire
addressing independence there are several reasons why they might addressing independence when using IPv4 there are several reasons why
choose to use NAT in such a network. For the ISP there is no need to they might choose to use NAT in such a network. For the ISP there is
import the IPv4 address range from the remote end-customer, which no need to import the IPv4 address range from the remote end-
facilitates IPv4 address summarization. The customer can use a customer, which facilitates IPv4 route summarization. The customer
larger IPv4 address range (probably with less-administrative can use a larger IPv4 address range (probably with less-
overhead) by the use of RFC 1918 and NAT. The customer also reduces administrative overhead) by the use of RFC 1918 and NAT. The
the overhead in changing to a new ISP, because the addresses assigned customer also reduces the overhead in changing to a new ISP, because
to devices behind the NAT do not need to be changed when the customer the addresses assigned to devices behind the NAT do not need to be
is assigned a different address by a new ISP. By using address changed when the customer is assigned a different address by a new
translation one avoids the need for network renumbering. Finally, ISP. By using address translation one avoids the need for network
the customer can provide privacy about its hosts and the topology of renumbering. Finally, the customer can provide privacy for its hosts
its internal network if the internal addresses are mapped through and the topology of its internal network if the internal addresses
NAT. are mapped through NAT.
It is expected that there will be enough IPv6 addresses available for It is expected that there will be enough IPv6 addresses available for
all networks and appliances for the foreseeable future. The basic all networks and appliances for the foreseeable future. The basic
IPv6 address-range an ISP allocates for a private network is large IPv6 address range an ISP allocates for a private network is large
enough (currently /48) for most of the medium and large enterprises, enough (currently /48) for most of the medium and large enterprises,
while for the very large private enterprise networks address-ranges while for the very large private enterprise networks address-ranges
can be concatenated. A single /48 alloaction provides an enterprise can be concatenated. A single /48 allocation provides an enterprise
network with 65536 different /64 prefixes. network with 65536 different /64 prefixes.
The summarization benefit for the ISP is happening based on the IPv6 The summarization benefit for the ISP results from the IPv6
allocation rules. This means that the ISP will provide the allocation rules. This means that the ISP will provide the
enterprise with an IPv6 address-range (typically a one or multiple enterprise with an IPv6 address-range (typically one or multiple
range(s) of '/48') from its RIR assigned IPv6 address-space. The range(s) of '/48') from its RIR assigned IPv6 address-space. The
goal of this allocation mechanism is to decrease the total amount of goal of this assignment mechanism is to decrease the total amount of
entries in the internet routing table. entries in the internet routing table. If the ISP adopts appropriate
policies there is high probability that an enterprise requiring
additional space could acquire an adjacent address block.
To mask the identity of a user on a network of this type, the usage To mask the identity of a user on a network of this type, the usage
of IPv6 privacy extensions may be advised. This technique is useful of IPv6 privacy extensions may be advised. This technique is useful
when an external element wants to track and collect all information when an external element wants to track and collect all information
sent and received by a certain host with known IPv6 address. Privacy sent and received by a certain host with known IPv6 address. Privacy
extensions add a random factor to the host part of an IPv6 address extensions add a random factor to the host part of an IPv6 address
and will make it very hard for an external element to keep and will make it very hard for an external element to keep
correlating the IPv6 address to a host on the inside network. The correlating the IPv6 address to a host on the inside network. The
usage of IPv6 privacy extensions does not mask the internal network usage of IPv6 privacy extensions does not mask the internal network
structure of an enterprise network. structure of an enterprise network.
If there is need to mask the internal structure towards the external If there is need to mask the internal structure towards the external
IPv6 internet, then some form of 'Untraceable' addresses may be used. IPv6 internet, then some form of 'untraceable' addresses may be used.
These addresses will be derived from a local pool, and may be These addresses will be derived from a local pool, and may be
assigned to those hosts for which topology masking is required or assigned to those hosts for which topology masking is required or
which want to reach the IPv6 Internet or other external networks. which want to reach the IPv6 Internet or other external networks.
The technology to assign these addresses to the hosts could be based The technology to assign these addresses to the hosts could be based
on DHCPv6. To complement the 'Untraceable' addresses it is needed to on DHCPv6. To complement the 'Untraceable' addresses it is needed to
have at least awareness of the IPv6 address location when routing an have at least awareness of the IPv6 address location when routing an
IPv6 packet through the internal network. This could be achieved by IPv6 packet through the internal network. This could be achieved by
'route-injection' in the network infrastructure. This route- 'route-injection' in the network infrastructure. This route-
injection could be done based on /128 host-routes to each device that injection could be done based on /128 host-routes to each device that
wants to connect to the Internet using an untraceable address. This wants to connect to the Internet using an untraceable address. This
skipping to change at page 19, line 12 skipping to change at page 20, line 4
The dynamic allocation of 'Untraceable' addresses can also limit the The dynamic allocation of 'Untraceable' addresses can also limit the
IPv6 access between local and external hosts to those local hosts IPv6 access between local and external hosts to those local hosts
being authorized for this capability. Dynamically allocated being authorized for this capability. Dynamically allocated
'Untraceable' addresses may also facilitate and simplify the 'Untraceable' addresses may also facilitate and simplify the
connectivity to the outside networks during renumbering, because the connectivity to the outside networks during renumbering, because the
existing IPv6 central address pool could be swapped for the newly existing IPv6 central address pool could be swapped for the newly
allocated IPv6 address pool. allocated IPv6 address pool.
The use of permanent ULA addresses on a site provides the benefit The use of permanent ULA addresses on a site provides the benefit
that even if an enterprise would change its ISP, the renumbering is that even if an enterprise would change its ISP, the renumbering will
only affecting those devices that have a wish to connect beyond the only affect those devices that have a wish to connect beyond the
site. Internal servers and services would not change their allocated site. Internal servers and services would not change their allocated
IPv6 ULA address, and the service would remain available even during IPv6 ULA address, and the service would remain available even during
global address renumbering. global address renumbering.
5.2 Small private networks 5.2. Small Private Networks
Also known as SOHO (Small Office/Home Office) networks, this Also known as SOHO (Small Office/Home Office) networks, this category
category describes those networks which have few routers in the describes those networks which have few routers in the topology, and
topology, and usually have a single network egress point. Typically usually have a single network egress point. Typically these networks
these networks are connected via either a dial-up connection or are:
broadband access; don't have dedicated Network Operation Center
(NOC); and through economic pressure are typically forced today to o connected via either a dial-up connection or broadband access
use NAT. In most cases the received global IPv4 prefix is not fixed o don't have dedicated Network Operation Center (NOC)
over time and is too long to provide every node in the private o and through economic pressure are typically forced today to use
network with a unique globally usable address. Fixing either of NAT
those issues typically adds an administrative overhead for address
management to the user. This category may even be limited to In most cases the received global IPv4 prefix is not fixed over time
receiving ambiguous IPv4 addresses from the service provider based on and is too long (very often just a /32 just giving a single address)
RFC 1918. An ISP will typically pass along the higher administration to provide every node in the private network with a unique globally
cost attached to larger address blocks, or IPv4 prefixes that are usable address. Fixing either of those issues typically adds an
static over time, due to the larger public address pool each of those administrative overhead for address management to the user. This
requires. category may even be limited to receiving ambiguous IPv4 addresses
from the service provider based on RFC 1918. An ISP will typically
pass along the higher administration cost attached to larger address
blocks, or IPv4 prefixes that are static over time, due to the larger
public address pool each of those requires.
As a direct response to explicit charges per public address most of As a direct response to explicit charges per public address most of
this category has deployed NAPT (port demultiplexing NAT) to minimize this category has deployed NAPT (port demultiplexing NAT) to minimize
the number of addresses in use. Unfortunately this also limits the the number of addresses in use. Unfortunately this also limits the
Internet capability of the equipment to being mainly a receiver of Internet capability of the equipment to being mainly a receiver of
Internet data (client), and makes it quite hard for the equipment to Internet data (client), and makes it quite hard for the equipment to
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 a server, sufficient technical knowledge to manage the NAT to enable a server,
only one server of any given protocol type is possible per address, only one server of any given protocol type is possible per address,
skipping to change at page 20, line 4 skipping to change at page 20, line 46
Internet capability of the equipment to being mainly a receiver of Internet capability of the equipment to being mainly a receiver of
Internet data (client), and makes it quite hard for the equipment to Internet data (client), and makes it quite hard for the equipment to
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 a server, sufficient technical knowledge to manage the NAT to enable a server,
only one server of any given protocol type is possible per address, only one server of any given protocol type is possible per address,
and then only when the address from the ISP is public. and then only when the address from the ISP is public.
When deploying IPv6 NAP in this environment, there are two approaches When deploying IPv6 NAP in this environment, there are two approaches
possible with respect to IPv6 addressing. 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 For the DHCPv6-PD solution, a dynamic address allocation approach is
is chosen. By means of the enhanced DHCPv6 protocol it is possible chosen. By means of the enhanced DHCPv6 protocol it is possible to
to have the ISP push down an IPv6 prefix range automatically towards have the ISP push down an IPv6 prefix range automatically towards the
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.
For the static configuration the mechanisms used could be the For the static configuration the mechanisms used could be the same as
same as for the medium/large enterprises. Typically the need for for the medium/large enterprises. Typically the need for masking the
masking the topology will not be of high priority for these users, topology will not be of high priority for these users, and the usage
and the usage of IPv6 privacy extensions could be sufficient. of IPv6 privacy extensions could be sufficient.
For both alternatives the ISP has the unrestricted capability for For both alternatives the ISP has the unrestricted capability for
summarization of its RIR allocated IPv6 prefix, while the small summarization of its RIR allocated IPv6 prefix, while the small
private network administrator has all flexibility in using the private network administrator has all flexibility in using the
received IPv6 prefix to its advantage because it will be of received IPv6 prefix to its advantage because it will be of
sufficient size to allow all the local nodes to have a public address sufficient size to allow all the local nodes to have a public address
and full range of ports available whenever necessary. and full range of ports available whenever necessary.
While a full prefix is expected to be the primary deployment model While a full prefix is expected to be the primary deployment model
there may be cases where the ISP provides a single IPv6 address for there may be cases where the ISP provides a single IPv6 address for
skipping to change at page 20, line 42 skipping to change at page 21, line 35
routable and unique address space. If scarcity was the motivation routable and unique address space. If scarcity was the motivation
with IPv4 to provide RFC 1918 addresses, in this environment the ISP with IPv4 to provide RFC 1918 addresses, in this environment the ISP
will not be motivated to allocate private addresses towards the will not be motivated to allocate private addresses towards the
single user connection because there are enough global addresses single user connection because there are enough global addresses
available at essentially the same cost. Also if the single device available at essentially the same cost. Also if the single device
wants to mask its identity to the called party or its attack profile wants to mask its identity to the called party or its attack profile
over a short time window it will need to enable IPv6 privacy over a short time window it will need to enable IPv6 privacy
extensions, which in turn leads to the need for a minimum allocation extensions, which in turn leads to the need for a minimum allocation
of a /64 prefix rather than a single address. of a /64 prefix rather than a single address.
5.3 Single user connection 5.3. Single User Connection
This group identifies the users which are connected via a single IPv4 This group identifies the users which are connected via a single IPv4
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,
skipping to change at page 21, line 18 skipping to change at page 22, line 13
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.
5.4 ISP/Carrier customer networks 5.4. ISP/Carrier Customer Networks
This group refers to the actual service providers that are providing This group refers to the actual service providers that are providing
the IPv4 access and transport services. They tend to have three the IPv4 access and transport services. They tend to have three
separate IPv4 domains that they support: separate IPv4 domains that they support:
o For the first they fall into the Medium/large private networks o For the first they fall into the Medium/large private networks
category (above) for their own internal networks, LANs etc. category (above) for their own internal networks, LANs etc.
o The second is the Operations network which addresses their o The second is the Operations network which addresses their
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 NAT for single user connections. RFC 1918 addresses used with 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 NAP 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 chapter 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 intra- communication can be done based environment, and consequently communication can be done based on ULA
on ULA addresses. This would give a stable configuration with addresses, however, in this environment, stable IPv6 Provider
respect to a local IPv6 address plan. Using these local scope Independent addresses can be used in preference to ULA addresses.
addresses would also prevent from being accessed from the external This would give a solid and scalable configuration with respect to a
network. The third is the IPv6 addresses that ISP/carrier network local IPv6 address plan. By the usage of proper network edge
assign to customers. These will typically be assigned with prefix filters, outside access to the closed environment can be avoided.
lengths terminating on nibble boundaries to be consistent with the The third is the IPv6 addresses that ISP/carrier network assign to
DNS PTR records. As scarcity of IPv6 addresses is not a concern, it customers. These will typically be assigned with prefix lengths
will be possible for the ISP to provide global routable IPv6 prefixes terminating on nibble boundaries to be consistent with the DNS PTR
without a requirement for address translation. An ISP may for records. As scarcity of IPv6 addresses is not a concern, it will be
commercial reasons still decide to restrict the capabilities of the possible for the ISP to provide global routable IPv6 prefixes without
end users by other means like traffic and/or route filtering etc. a requirement for address translation. An ISP may for commercial
reasons still decide to restrict the capabilities of the end users by
other means like 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' [14] it is found that the IPv6 WG recommends IPv6 in 3GPP Standards' [15] 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 continues as deployments are ongoing. This section discusses
several topics for which additional standardization, or documentation
of best practice, is required to fully realize the benefits of NAP.
None of these items are show-stoppers for immediate usage of NAP in
roles where there are no current gaps.
6.1 Completion of work on ULAs
As noted above, a new form of Unique Local IPv6 Unicast Addresses Like IPv4 and any major standards effort, IPv6 standardization work
(ULAs) is being standardized by the IETF. Experience to date has continues as deployments are ongoing. This section discusses several
shown that most network managers want to gain some operational topics for which additional standardization, or documentation of best
familiarity with IPv6 in their local environment before exposing practice, is required to fully realize the benefits of NAP. None of
their network to the live global Internet. Since these addresses these items are show-stoppers for immediate usage of NAP in roles
allow autonomy for local deployment of IPv6 in private networks, this where there are no current gaps.
work should be completed as soon as possible. In addition to
autonomy the routing limitation of ULA addresses protects nodes that
are only for local use from global exposure.
6.2 Subnet topology masking 6.1. Subnet Topology Masking
There really is no functional gap here as a centrally assigned There really is no functional gap here as a centrally assigned pool
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. If necessary a best practice effective way to mask topology. If necessary a best practice
document could be developed describing the interaction between DHCP document could be developed describing the interaction between DHCP
and various IGPs which would in effect define Untraceable Addresses. and various IGPs which would in effect define Untraceable Addresses.
As an alternative, some work in Mobile IP to define a policy As an alternative, some work in Mobile IP to define a policy message
message where a mobile node would learn from the home agent. It where a mobile node would learn from the Home Agent. It should not
should not even try to inform its correspondent about route try to inform its correspondent about route optimization and thereby
optimization (and thereby expose its real location) would allow a expose its real location. A border Home Agent using internal
border home agent using internal tunneling to the logically mobile tunneling to the logical mobile node (potentially static) can
node (potentially rack mounted) to completely mask all internal completely mask all internal topology, while avoiding the strain from
topology, while avoiding the strain from a large number of host a large number of host routes in the IGP. This work should be
routes in the IGP. This work should be pursued in the IETF. pursued in the IETF.
6.3 Minimal traceability of privacy addresses 6.2. Minimal Traceability of Privacy Addresses
Privacy addresses (RFC 3041) may certainly be used to limit the Privacy addresses (RFC 3041) may certainly be used to limit the
traceability of external traffic flows back to specific hosts, but traceability of external traffic flows back to specific hosts, but
lacking a topology masking component above they would still reveal lacking a topology masking component above they would still reveal
the subnet address bits. For complete privacy a best practice the subnet address bits. For complete privacy a best practice
document describing the combination of privacy addresses with document describing the combination of privacy addresses with
topology masking is required. This work remains to be done, and topology masking may be required. This work remains to be done, and
should be pursued by the IETF. should be pursued by the IETF.
6.4 Renumbering procedure 6.3. Renumbering Procedure
Documentation of site renumbering procedures [11] should be Documentation of site renumbering procedures [12] is completed and is
completed. It should also be noticed that ULAs will help here too, in the RFC-editor's queue. It should also be noticed that ULAs may
since a change of ISP prefix will only affect hosts that need an help here too, since a change of ISP prefix will only affect hosts
externally routeable address as well as a ULA. that need an externally routeable address as well as an ULA.
6.5 Site multihoming 6.4. Site Multihoming
This complex problem has never been well solved for IPv4, which is This complex problem has never been completely solved for IPv4, which
exactly why NAT has been used as a partial solution. For IPv6, after is exactly why NAT has been used as a partial solution. For IPv6,
several years' work, the relevant IETF WG is finally converging on an after several years' work, the IETF has converged on an architectural
architectural approach intended to reconcile enterprise and ISP approach intended with service restoration as initial aim [20].
perspectives. Again, ULAs will help since they will provide stable Again, ULAs may help since they will provide stable addressing for
addressing for internal communications that are not affected by internal communications that are not affected by multihoming.
multihoming.
6.6 Untraceable addresses 6.5. Untraceable Addresses
The details of the untraceable addresses, along with any associated The details of the untraceable addresses, along with any associated
mechanisms such as route injection, must be worked out and specified. mechanisms such as route injection, must be worked out and specified.
7. IANA Considerations 7. IANA Considerations
This document requests no action by IANA This document requests no action by IANA
8. Security Considerations 8. Security Considerations
While issues which are potentially security related are discussed While issues which are potentially security related are discussed
throughout the document, the approaches herein do not introduce any throughout the document, the approaches herein do not introduce any
new security concerns. Product marketing departments have widely new security concerns. Product marketing departments have widely
sold IPv4 NAT as a security tool, though the misleading nature of sold IPv4 NAT as a security tool and suppliers have been implementing
those claims has been previously documented in RFC 2663 [2] and RFC address translation functionality in their firewalls, though the
2993 [4]. misleading nature of those claims has been previously documented in
RFC 2663 [2] and RFC 2993 [4].
This document defines IPv6 approaches which collectively achieve This document defines IPv6 approaches which collectively achieve the
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 know about or control access, and thereby manage the explicitly know about or control access, and thereby manage the
overall attack exposure of local resources, they act to improve local overall attack exposure of local resources, they act to improve local
network security. In particular the explicit nature of a content network security. In particular the explicit nature of a content
aware firewall in NAP will be a vast security improvement over the aware firewall in NAP will be a vast security improvement over the
NAT artifact where lack of translation state has been widely sold as NAT artifact where lack of translation state has been widely sold as
a form of protection. a form of protection.
9. Conclusion 9. Conclusion
skipping to change at page 24, line 34 skipping to change at page 25, line 23
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 NAP.
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
draft. 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 and other members Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith,
of the v6ops WG. Elwyn Davies, Daniel Senie, Soininen Jonne, Lindqvist Erik Kurt and
other members of the v6ops WG.
11. References 11. References
11.1 Normative References 11.1. Normative References
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
skipping to change at page 25, line 18 skipping to change at page 26, line 11
[5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the [6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001. IP Network Address Translator", RFC 3027, January 2001.
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[9] 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.
[10] 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.
[11] Baker, F., "Procedures for Renumbering an IPv6 Network without [12] Baker, F., "Procedures for Renumbering an IPv6 Network without
a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in
progress), March 2005. progress), March 2005.
[12] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
progress), January 2005. progress), January 2005.
11.2 Informative References 11.2. Informative References
[13] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- [14] 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.
[14] Wasserman, M., "Recommendations for IPv6 in Third Generation [15] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, Partnership Project (3GPP) Standards", RFC 3314,
September 2002. September 2002.
[15] Savola, P. and B. Haberman, "Embedding the Rendezvous Point [16] 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.
[16] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful [17] 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.
[17] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- [18] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown-
v6ops- port-scanning-implications-01.txt)", July 2004. v6ops- port-scanning-implications-01.txt)", July 2004.
[18] Chown, T., Tompson, M., and A. Ford, "Things to think about [19] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to
when Renumbering an IPv6 network think about when Renumbering an IPv6 network
(draft-chown-v6ops-renumber-thinkabout-00)", October 2004. (draft-chown-v6ops-renumber-thinkabout-03)", October 2004.
Authors' Addresses
Gunter Van de Velde
Cisco Systems
De Kleetlaan 6a
Diegem 1831
Belgium
Phone: +32 2704 5473
Email: gunter@cisco.com
Tony Hain
Cisco Systems
500 108th Ave. NE
Bellevue, Wa.
USA
Email: alh-ietf@tndh.net
Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: rdroms@cisco.com
Brian Carpenter
IBM Corporation
Sauemerstrasse 4
Rueschlikon, 8803
Switzerland
Email: brc@zurich.ibm.com
Eric Klein
Leon Recanati Graduate School of Business Administration at Tel
Aviv University
Tel Aviv,
Israel
Email: ericlklein@softhome.net [20] Huston, G., "Architectural Commentary on Site Multi-homing
using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)",
July 2004.
Appendix A. Additional benefits due to Native IPv6 and universal unique Appendix A. Additional Benefits due to Native IPv6 and Universal Unique
addressing 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 Aonnectivity
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
address conservation techniques. NAT was introduced as a tool to address conservation techniques. NAT was introduced as a tool to
reduce demand on the limited IPv4 address pool, but the side effect reduce demand on the limited IPv4 address pool, but the side effect
of the NAT technology was to remove the any-to-any connectivity of the NAT technology was to remove the any-to-any connectivity
capability. By removing the need for address conservation (and capability. By removing the need for address conservation (and
therefore NAT), IPv6 returns the any-to-any connectivity model and therefore NAT), IPv6 returns the any-to-any connectivity model and
removes the limitations on application developers. With the freedom removes the limitations on application developers. With the freedom
skipping to change at page 27, line 42 skipping to change at page 27, line 43
applications, IPv6 embedded IPsec communication between two applications, IPv6 embedded IPsec communication between two
communicating devices, instant messaging, Internet telephony, etc..) communicating devices, instant messaging, Internet telephony, etc..)
rather than focusing on discovering and traversing the increasingly rather than focusing on discovering and traversing the increasingly
complex NAT environment. complex NAT environment.
It will also allow application and service developers to rethink the It will also allow application and service developers to rethink the
security model involved with any-to-any connectivity, as the current security model involved with any-to-any connectivity, as the current
edge firewall solution in IPv4 may not be sufficient for Any-to-any edge firewall solution in IPv4 may not be sufficient for Any-to-any
service models. service models.
A.2 Auto-configuration A.2. Auto-configuration
IPv6 offers a scalable approach to minimizing human interaction and IPv6 offers a scalable approach to minimizing human interaction and
device configuration. Whereas IPv4 implementations require touching device configuration. Whereas IPv4 implementations require touching
each end system to indicate the use of DHCP vs. a static address and each end system to indicate the use of DHCP vs. a static address and
management of a server with the pool size large enough for the management of a server with the pool size large enough for the
potential number of connected devices, IPv6 uses an indication from potential number of connected devices, IPv6 uses an indication from
the router to instruct the end systems to use DHCP or the stateless the router to instruct the end systems to use DHCP or the stateless
auto configuration approach supporting a virtually limitless number auto configuration approach supporting a virtually limitless number
of devices on the subnet. This minimizes the number of systems that of devices on the subnet. This minimizes the number of systems that
require human interaction as well as improves consistency between all require human interaction as well as improves consistency between all
the systems on a subnet. In the case that there is no router to the systems on a subnet. In the case that there is no router to
provide this indication, an address for use on the local link only provide this indication, an address for use on the local link only
will be derived from the interface media layer address. will be derived from the interface media layer address.
A.3 Native Multicast services A.3. Native Multicast Services
Multicast services in IPv4 were severely restricted by the limited Multicast services in IPv4 were severely restricted by the limited
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 'Rendez-Vous Point' (or RP) makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
[15] directly in the IPv6 multicast address when using ASM multicast. [16] 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:
o IPv6 has the IPsec technology directly embedded into the IPv6 o IPv6 has the IPsec technology directly embedded into the IPv6
protocol. This allows for simpler peer-to-peer encryption and protocol. This allows for simpler peer-to-peer encryption and
authentication, once a simple key/trust management model is authentication, once a simple key/trust management model is
developed, while the usage of some other less secure mechanisms is developed, while the usage of some other less secure mechanisms is
avoided (i.e. md5 password hash for neighbor authentication). avoided (i.e. md5 password hash for neighbor authentication).
skipping to change at page 29, line 14 skipping to change at page 29, line 15
policy. policy.
o The technology to enable source-routing on a network o The technology to enable source-routing on a network
infrastructure has been enhanced to allow this feature to infrastructure has been enhanced to allow this feature to
function, without impacting the processing power of intermediate function, without impacting the processing power of intermediate
network devices. The only devices impacted with the source- network devices. The only devices impacted with the source-
routing will be the source and destination node and the routing will be the source and destination node and the
intermediate source-routed nodes. This impact behavior is intermediate source-routed nodes. This impact behavior is
different if IPv4 is used, because then all intermediate devices different if IPv4 is used, because then all intermediate devices
would have had to look into the source-route header. would have had to look into the source-route header.
A.5 Mobility A.5. Mobility
Anytime, anywhere, universal access requires MIPv6 services in Anytime, anywhere, universal access requires MIPv6 services in
support of mobile nodes. While a Home Agent is required for initial support of mobile nodes. While a Home Agent is required for initial
connection establishment in either protocol version, IPv6 mobile connection establishment in either protocol version, IPv6 mobile
nodes are able to optimize the path between them using the MIPv6 nodes are able to optimize the path between them using the MIPv6
option header while IPv4 mobile nodes are required to triangle route option header while IPv4 mobile nodes are required to triangle route
all packets. In general terms this will minimize the network all packets. In general terms this will minimize the network
resources used and maximize the quality of the communication. resources used and maximize the quality of the communication.
A.6 Merging networks A.6. Merging Networks
When two IPv4 networks want to merge it is not guaranteed that both When two IPv4 networks want to merge it is not guaranteed that both
networks would be using different address-ranges on some parts of the networks would be using different address-ranges on some parts of the
network infrastructure due to the legitimate usage of RFC 1918 network infrastructure due to the legitimate usage of RFC 1918
private addressing. This potential overlap in address space may private addressing. This potential overlap in address space may
complicate a merge of two and more networks dramatically due to the complicate a merge of two and more networks dramatically due to the
additional IPv4 renumbering effort. i.e. when the first network has a additional IPv4 renumbering effort. i.e. when the first network has a
service running (NTP, DNS, DHCP, HTTP, etc..) which need to be service running (NTP, DNS, DHCP, HTTP, etc..) which need to be
accessed by the 2nd merging network. Similar address conflicts can accessed by the 2nd merging network. Similar address conflicts can
happen when two network devices from these merging networks want to happen when two network devices from these merging networks want to
communicate. 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 A.7. Community of interest
Although some Internet-enabled devices will function as fully-fledged Although some Internet-enabled devices will function as fully-fledged
Internet hosts, it is believed that many will be operated in a highly Internet hosts, it is believed that many will be operated in a highly
restricted manner functioning largely or entirely within a Community restricted manner functioning largely or entirely within a Community
of Interest. By Community of Interest we mean a collection of hosts of Interest. By Community of Interest we mean a collection of hosts
that are logically part of a group reflecting their ownership or that are logically part of a group reflecting their ownership or
function. Typically, members of a Community of Interest need to function. Typically, members of a Community of Interest need to
communicate within the community but should not be generally communicate within the community but should not be generally
accessible on the Internet. They want the benefits of the accessible on the Internet. They want the benefits of the
connectivity provided by the Internet, but do not want to be exposed connectivity provided by the Internet, but do not want to be exposed
to the rest of the world. This functionality will be available to the rest of the world. This functionality will be available
through the usage of NAP and native IPv6 dataflows, without any through the usage of NAP and native IPv6 dataflows, without any
stateful device in the middle. It will also allow to build virtual stateful device in the middle. It will also allow to build virtual
organization networks on the fly, which is very difficult to do in organization networks on the fly, which is very difficult to do in
IPv4+NAT scenarios. IPv4+NAT scenarios.
Appendix B. Revision history Appendix B. Revision history
B.1 Changes from *-vandevelde-v6ops-nap-00 to *-vandevelde-v6ops-nap-01 B.1. Changes from *-vandevelde-v6ops-nap-00 to
*-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 been placed into o The list of additional IPv6 benefits has been been placed into
appendix. appendix.
o new security considerations section added. o new security considerations section added.
o GAP analysis revised. o GAP analysis revised.
o Section 2.6 and 4.6 have been included. o Section 2.6 and 4.6 have been included.
B.2 Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00 B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00
o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf- o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf-
v6ops-nap-00.txt. v6ops-nap-00.txt.
o Editorial changes. o Editorial changes.
B.3 Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01
o Added text in Chapter 2.2 and 4.2 to address more details on o Added text in Chapter 2.2 and 4.2 to address more details on
firewall and proxy firewall and proxy
o Revised Eric Klein contact details o Revised Eric Klein contact details
o Added note in 4.2 that control over the proposed statefull-filter o Added note in 4.2 that control over the proposed statefull-filter
should be by a simple user-interface should be by a simple user-interface
B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02
o General Note: Header more consistent capitelized.
o Section 1: para 3: s/...and privacy and will... translation./
...and privacy. NAP will achieve these security goals without
address transaltion whilst maintaining any-to-any connectivity./
o Section 1: Various editorial changes happened
o Section 2.1: Changed: 'Frequently a simple user interface is
sufficient for configuring'. into 'Frequently a simple user
interface, or no user interface is sufficient'
o Section 2.2: (Simple Security ) Better not to use the word -evil-
in the text
o Section 2.2: changed 'provided by NAT are actually ' into
'provided by NAT is actually'
o Section 2.2: para 3: s/actually false/actually an illusion/
o Section 2.2: para 2: added 'Also it will only be reliable if a
mechanism such as 'trusted computing' is implemented in the end-
system; without this enhancement administrators will be unwilling
to trust the behavior of end-systems.
o Section 2.3: para 1: s/of the NAT devices state/from the NAT
device's state/
o Section 2.4: para1: clarified the definition of topology hiding
o Section 2.4: last sentence of next-to-last paragraph, added
punctuation at end of sentence.
o Section 2.4: added first line: When mentioning 'topology hiding'
the goal is to make a reference that an entity outside the network
can not make a correlation between the location of a device and
the address of a device on the local network.
o Section 2.4: para 1: s/reflected/represented/
o Section 2.5: last par: added reference: 'Section 2.7 describes
some disadvantages that appear if independednt networks using
[RFC1918] addresses have to be merged.'
o Section 2.6: Added text that private address-space is not
limitless
o Section 2.6: Various editorial changes
o Section 2.7: Para 1 editorial revised
o Section 2.7: last para: s/This solution/The addition of an extra
NAT as a solution/
o Section 2.7: s/highly desirable to be/highly desirable due to
resiliency and load-balancing to be/
o Section 2.7: added text on the reason why there are overlapping
addresses
o Section 2.7: last para: s/merged address space/overlapping address
speaces in the merged networks/
o Section 3.1: Para 1 editorial changes
o Section 3.1: s/by contacted web sites, so IPv6/by web sites that
are accessed from the device: IPv6 /
o Section 3.1: s/as that would have a serious negative impact on
global routing/as that would have a negative effect on global
route aggregation
o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in
global routing table is not scalable
o Section 3.2: s3.2: Noted that it is not always interresting to mix
ULA with global as that may lead to SAS issues
o Section 3.3: last para: s/delegating router/delegating router
(incorporating a DHCPv6 server)/, s/across an administrative/
possibly across an administrative/
o Section 3.4: Changed: 'random assignment has as purpose' to
'random assignment has a purpose'
o Section 3.4: para 2: Replace first sentence with: 'The random
assignment is intended to mislead the outside world about the
structure of the local network.'
o Section 3.4: para 2: s/there is a correlation/needs to maintain a
correlation/
o Section 3.4: para 2: s/like a/such as a/
o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from
mapping/and from mapping of/
o Section 3.4: para 3: s/are reachable on/are allocated to devices
on/
o Section 3.4: para 3: s/belonging to the same subnet next to each
other/belonging to devices adjacent to each other on the same
subnet/
o Section 3.4: s/aggregation device/indirection device/
o Section 4.1: splitted the 1 section up into 2 separate sections
o Section 4.1: s/ End node connections involving other nodes on the
global Internet will always use the global IPv6 addresses [9]
derived from this prefix delegation./ End node connections
involving other nodes on the global Internet will always use the
global IPv6 addresses [9] derived from this prefix delegation. It
should be noted that the policy table needs to be correctly set up
so that true global prefixes are distinguished from ULAs and will
be used for the source address in preference when the destination
is not a ULA/
o Section 4.1: A more secure network environment can be established
by having the referenced ULA addresses statically configured on
the network devices as this decreases the dynamic aspects of the
network, however the operational overhead is increased.
o Section 4.2:Added note that IID should be randomized for port-scan
protection
o Section 4.2: Removed text: This is an automated procedure of
sending Internet Control Message Protocol (ICMP) echo requests
(also known as PINGs) to a range of IP addresses and recording
replies. This can enable an attacker to map the network.
o Section 4.2: paragraph beginning: "This simple rule...". The
first sentence in this paragraph was overly-long. The sentence
has been fragmented
o Section 4.2: para 1: s/similar as for an/similar to that of an/
o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/
Internet. The use of firewall and Intrusion Detection Systems
(IDS) is/
o Section 4.2: para 1: s/but has/but with/
o Section 4.2: para 1: s/end to end/end-to-end/
o Section 4.2: Item 3: s/amount/number/
o Section 4.2: Item 3: s/This goes from the assumption that the
attacker has no/This protection is nullified if the attacker has/
o Section 4.2: para after Item 3: s/pose/offer/ (or provide).
o Section 4.2: para after Item 3: s/best- practices/best practices/
o Section 4.2: para after example firewall rules: s/create similar
protection and security holes the typical IPv4 NAT device will
offer/provide (non-)protection and create security holes similar
to those offered to a network using a typical IPv4 NAT device/
o Section 4.2: para next but one after firewall rules: s/What one
does when topology probing is to get an idea of the available
hosts/The intention of topology probing is to identify a selection
of the available hosts/
o Section 4.2: s/This is directly the opposite of what IPv6 security
best practices are trying to achieve./IPv6 security best practices
will avoid this kind of illusory security but can only do this if
correctly configured firewalls and IDS systems are used at the
perimeter where some IPv4 networks have relied on NATs.
o Section 4.2: s/ It is recommended for site administrators to take
[17] into consideration to achieve the expected goal./ It is
recommended for site administrators to take [17] into
consideration to achieve the expected goal. This protection will
also be nullified if IIDs are configured in a group near the start
of the IID space./
o Section 4.2: Removed the example study and added complementiory
text to describe a potential behavior
o Section 4.4: rewrite of the section to reduce the importance of
the MIpv^ and tunneled solution
o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested
in the text, however text is added that any kind of tunneling
should do the trick.
o Section 4.4: para 2: after 'As discussed above' inserted '(see
Section 3.1)'
o Section 4.4: para 3: s/consolidated on/indirected via/
o Section 4.4: para 3: s/topololgy masked/each topology masked/
o Section 4.4: para 3: Expanded acronym COA
o Section 4.4: para 3: s/rack mounted/static/
o Section 4.4: Rephrasing of text happened in this section
o Section 4.5: change: "so that a NAT is not required" to: "so that
IPv6 address translation is not required".
o Section 4.5: changed 'periodically to look' into 'to look
periodically'
o Section 4.5: change: "2^64 hosts" to: "2^64 addresses".
o Section 4.5: Removed the statement '(or even defined)
o Section 4.6: last para: s/which will lead to the IPv4 practice/
which will require the adoption of the IPv4 workaround/
o Section 4.6: s/the IPv4 constricting scenarios of multiple devices
sharing a/the constriction of IPv4 scenarios where multiple devies
are forced to share a/
o Section 4.7: s/as the zero-touch external/as an almost zero-touch
external/
o Section 5: Replaced first three sentences with: In presenting
these case studies we have chosen to consider categories of
network divided first according to their function either as
carrier/ISP networks or end user (such as enterprise) networks
with the latter category broken down according to the number of
connected end hosts.
o Section 5: bullet points: s/connection/connected end hosts/
o Section 5.1: s/addressing independence/addressing independence
when using IPv4/
o Section 5.1: last para: s/is only affecting/will only affect/
o Section 5.1: changed 'alloaction' into 'allocation'
o Section 5.1: changed: '(typically a one or' into '(typically one
or'
o section 5.1: changed: s/allocation/assignment/ in one of the
paragraphs
o section 5.2: para 1: s?is too long?is too long (very often just a
/32 just giving a single address)?
o Section 5.4: (Case study: ISP networks) ULA usage for ISP/
Carrier-grade networks is mentioned in the draft, while it was
suggested that for these NW the PI addresses are already very
stable and they should be qualified for setting up proper
filtering -> removed ULA from this section.
o Section 5.4: changed 'intra- communication' into 'communication'
o Section 5.4: s/chapter 5.1/Section 5.1/
o Section 6.1: (Completion of work on ULAs) Text revision to reflect
current state of ULA or remove the chapter? Chapter removed ...
ULA specification is in the RFC-editor queue.
o Section 6.3: (Minimal Traceability) Better to say "topology
masking _may be_ required" instead of "is required", because
whether this is needed or not is a value judgment.
o Section 6.4: (Renumbering Procedure) Renumbering procedure is in
RFC queue. The section corrected in the current state?
o Section 6.4: s/well solved/completely solved/
o In general the whole chapter 6 has been revised to reflect current
status
Authors' Addresses
Gunter Van de Velde
Cisco Systems
De Kleetlaan 6a
Diegem 1831
Belgium
Phone: +32 2704 5473
Email: gunter@cisco.com
Tony Hain
Cisco Systems
500 108th Ave. NE
Bellevue, Wa.
USA
Email: alh-ietf@tndh.net
Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: rdroms@cisco.com
Brian Carpenter
IBM Corporation
Sauemerstrasse 4
Rueschlikon, 8803
Switzerland
Email: brc@zurich.ibm.com
Eric Klein
Tel Aviv University
Tel Aviv,
Israel
Phone:
Email: ericlklein@softhome.net
Intellectual Property Statement Intellectual Property Statement
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.
 End of changes. 156 change blocks. 
531 lines changed or deleted 772 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/