[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Review of draft-ietf-v6ops-nap-02.txt

I had done some updating before the last IESG call & round of comments. The
working draft is attached along with a diff to the -02 version. As always
comments are welcome. I am not sure this needs a WG slot, but if someone
really wants one I am sure we can figure out which one of us can lead the
discussion. Below are the comments I sent to the authors about the IESG
discuss items.

Tony

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5
2102
I put in an arbitrary 50k number as a scale reference. That text could be
expanded to discuss protocol specifics, topology, and churn rate as hinted
by the reference, but that somewhat misses the point. "The technology does
work with scale limitations", is the bullet that the IESG appears to be
missing by essentially asking for a tutorial on igp engineering. It might be
better to put in a range of something like 5k-50k to highlight the point
that this is not a hard limit without having to discuss the details of why.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5
2051
This one is somewhat all over the place. Lack of understanding of the
technology by an IESG member should not override a working group consensus.
2.2 has already been reworked. 
3.4 does not oversell if you understand how MIPv6 really works. 
4.2 -2 does not oversell IPsec, it simply states the real situation. 
4.3 has additional text, though this is one where the IESG has lost the
context of this being wrt a nat deployment. 
4.7 the comments here are just wrong because it already did cover the points
and there was already a forward reference, it just didn't specify 6.4 as the
section number.
I did not buy all of Margaret's personal views though clarifications were
added. 
I did not expand on renumbering as Thomas requested. It is not clear to me
what he wants beyond referencing rfc 4192. The second paragraph of 2.5 could
be expanded, but that is not the focus of the section. The second paragraph
of 2.7 could be expanded, but would seem to loose context. It sounds like he
wants a statement like 'renumbering is hard in IPv4' as justification for
nat. 

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5
1234
This was covered by the edits, and additional background explanation was in
the message I sent to the IESG on 5/26. 


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of Fred Baker
> Sent: Monday, June 12, 2006 10:16 AM
> To: Tim Chown
> Cc: v6ops@ops.ietf.org
> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt
> 
> On Jun 12, 2006, at 5:39 AM, Tim Chown wrote:
> > A major overhaul isn't needed.
> 
> I agree. Can we get the discuss comments and other review comments
> addressed by the 26 Jun cut-off date?
> 
> Do we nee to discuss this in the coming meeting? I would guess not,
> but I'm willing to give you a slot if you want one. I'm supposed to
> post an agenda by next Monday.
> 
> Still looking for the update port-scanning document to put it into
> WGLC...
Title: Diff: draft-ietf-v6ops-nap-03.txt - draft-ietf-v6ops-nap-02.txt
 draft-ietf-v6ops-nap-03.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 4, 2006 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 2, 2006 October 22, 2005
IPv6 Network Architecture Protection IPv6 Network Architecture Protection
<draft-ietf-v6ops-nap-03.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 4, 2006. This Internet-Draft will expire on April 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 . . . . . . . 7 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 6
2.1. Simple Gateway between Internet and Private Network . . . 7 2.1. Simple Gateway between Internet and Private Network . . . 6
2.2. Simple Security due to Stateful Filter Implementation . . 8 2.2. Simple Security due to Stateful Filter Implementation . . 6
2.3. User/Application tracking . . . . . . . . . . . . . . . . 8 2.3. User/Application tracking . . . . . . . . . . . . . . . . 7
2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8
2.5. Independent Control of Addressing in a Private Network . . 10 2.5. Independent Control of Addressing in a Private Network . . 9
2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9
2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10
3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 11 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 10
3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 10
3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 12 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 11
3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 12
3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 14 Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Simple Gateway between Internet and Internal Network . . . 14 4.1. Simple Gateway between Internet and Internal Network . . . 13
4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 13
4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 15
4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 15
4.5. Independent Control of Addressing in a Private Network . . 19 4.5. Independent Control of Addressing in a Private Network . . 16
4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 17
4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 20 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 17
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Medium/large private networks . . . . . . . . . . . . . . 21 5.1. Medium/large private networks . . . . . . . . . . . . . . 18
5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 20
5.3. Single User Connection . . . . . . . . . . . . . . . . . . 24 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 21
5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 22
6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 26 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 23
6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 26 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 23
6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 27 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 23
6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 27 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 24
6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 27 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Additional Benefits due to Native IPv6 and Appendix A. Additional Benefits due to Native IPv6 and
Universal Unique Addressing . . . . . . . . . . . . . 30 Universal Unique Addressing . . . . . . . . . . . . . 27
A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 30 A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 27
A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 30 A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 27
A.3. Native Multicast Services . . . . . . . . . . . . . . . . 31 A.3. Native Multicast Services . . . . . . . . . . . . . . . . 28
A.4. Increased Security Protection . . . . . . . . . . . . . . 31 A.4. Increased Security Protection . . . . . . . . . . . . . . 28
A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 32 A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 32 A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 29
A.7. Community of interest . . . . . . . . . . . . . . . . . . 32 A.7. Community of interest . . . . . . . . . . . . . . . . . . 29
Appendix B. Revision history . . . . . . . . . . . . . . . . . . 33 Appendix B. Revision history . . . . . . . . . . . . . . . . . . 30
B.1. Changes from *-vandevelde-v6ops-nap-00 to B.1. Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 33 *-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 . . . . . . . . . . . . . . . . . . . 33 *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30
B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 33 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30
B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 33 B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 30
B.5. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
B.6. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41
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 and address space is not needed in IPv6. The serious disadvantages of
impact on applications by ambiguous "private" address space and ambiguous "private" address space and of Network Address Translation
Network Address Translation (NAT) [1] [5] have been well documented (NAT) [1][5] have been well documented [4][6]. However, given its
[4] [6] so there will not be much additional discussion here. wide market acceptance NAT undoubtedly has some perceived benefits.
However, given its wide market acceptance NAT undoubtedly has some Indeed, in an Internet model based on universal any-to-any
perceived benefits. Indeed, in an Internet model based on universal connectivity, product marketing departments have driven a perception
any-to-any connectivity, product marketing departments have driven a hat some connectivity and security concerns can only be solved by
perception that some connectivity and security concerns can only be using a NAT device or by using logically separated Local Area Network
solved by using a NAT device or by using logically separated address (LAN) address spaces. This document describes the reasons for
spaces. This document describes the goals for utilizing a NAT device utilizing a NAT device in an IPv4 environment that are regularly
in an IPv4 environment that are regularly cited as solutions for cited in marketing pronouncements. It then shows how these needs can
perceived problems. It then shows how these needs can be met without be met without using NAT in an IPv6 network. Some of the IPv6
using the header modification feature of NAT in an IPv6 network. The solutions offer advantages beyond the equivalent IPv4 NAT solution.
use of the facilities from IPv6 described in this document avoids the The use of the facilities from IPv6 described in this document avoids
negative impacts on applications of address translation while meeting the negative impacts of address translation.
or exceeding the comparable IPv4+NAT equivlent goal.
As far as security and privacy are 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 or a worm infected machine outside trying to such as having a hacker trying to penetrate your network, or having a
penetrate and attack the local network. Some are local such as a worm infected machine outside your network trying to attack it. Some
disgruntled employee disrupting business operations, or the are local such as a disgruntled employee disrupting business
unintentional negligence of a user downloading some malware which operations, or the unintentional negligence of a user downloading
then proceeds to attack from within. Some may be inherent in the some malware which then proceeds to attack any device on the LAN.
device hardware ("embedded") such as having some firmware in a Some may be inherent in the device hardware ("embedded") such as
domestic appliance "call home" to its manufacturer without the user's having some firmware in a domestic appliance "call home" to its
consent. manufacturer without the user's consent.
Another consideration discussed is the view that NAT can be used to
fulfill the goals of a security policy. At a technical level the
translation process fundamentally can not produce security because
mangling the address in the header does not fulfill any useful
security functions, it only breaks the ability to track what is going
on. The artifacts of NAT devices do provide some value.
1. the need to establish state before anything gets through from
outside to inside solves one set of problems.
2. the need to stop receiving any packets when finished with a flow
solves a set of problems
3. the need to appear to be at the edge of the network solves a set
of problems
4. and the ability to have addresses that are not publicly routed
solves yet another set (mostly changes where the state is and
scale requirements for the first one).
This document describes several techniques that may be combined in an This document describes several techniques that may be combined on an
IPv6 deployment to protect the integrity of its network architecture. IPv6 site to protect the integrity of its network architecture.
It will focus on the 'how to acomplish a goal' perspective, leaving These techniques, known collectively as Network Architecture
most of the 'why that goal' perspective for other documents. These Protection (NAP), retain the concept of a well defined boundary
techniques, known collectively as Network Architecture Protection between "inside" and "outside" the private network, and allow
(NAP), retain the concept of a well defined boundary between "inside" firewalling, topology hiding, and privacy. NAP will achieve these
and "outside" the private network, and allow firewalling, topology security goals without address translation whilst maintaining any-to-
hiding, and privacy. NAP will achieve these security goals without any connectivity.
address translation whilst regaining the ability for arbitrary any-
to-any connectivity.
IPv6 Network Architecture Protection can be summarized in the IPv6 Network Architecture Protection can be summarized in the
following table. It presents the marketed "benefits" of IPv4+NAT following table. It presents the marketed "benefits" of NAT with a
with a cross-reference of how those are delivered in both the IPv4 cross-reference of how those are delivered in both the IPv4 and IPv6
and IPv6 environments. environments.
Goal 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 |
skipping to change at page 6, line 34 skipping to change at page 5, line 34
| 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 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Addressing | RFC 1918 | RFC 3177 & 4193 | | Addressing | RFC 1918 | RFC 3177 & ULA |
| Autonomy | | | | Autonomy | | |
| | see section 2.5 | see section 4.5 | | | see section 2.5 | see section 4.5 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Global Address | RFC 1918 | 18*10^18 subnets | | Global Address | RFC 1918 | 340,282,366,920,938, |
| Pool | << 2^48 application | 3.4*10^38 addresses | | Pool | | 463,463,374,607,431, |
| Conservation | end points | unrestricted | | Conservation | | 768,211,456 |
| | topology restricted | | | | | (3.4*10^38) addresses|
| | see section 2.6 | see section 4.6 | | | see section 2.6 | see section 4.6 |
+------------------|-----------------------|-----------------------+ +------------------|-----------------------|-----------------------+
| Renumbering and | Address translation | Preferred lifetime | | Renumbering and | Address translation | Preferred lifetime |
| Multi-homing | at border | per prefix & Multiple| | Multi-homing | at border | per prefix & Multiple|
| | | addresses per | | | | addresses per |
| | | interface | | | | interface |
| | see section 2.7 | see section 4.7 | | | see section 2.7 | see section 4.7 |
+------------------+-----------------------+-----------------------+ +------------------+-----------------------+-----------------------+
This document first identifies the perceived benefits of NAT in more This document first identifies the perceived benefits of NAT in more
detail, and then shows how IPv6 NAP can provide each of them. It detail, and then shows how IPv6 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 insight into the generally perceived benefits This section provides insight into the generally perceived benefits
of the use of IPv4 NAT which are frequently reinforced by product of the use of IPv4 NAT as extolled by product marketing. The goal of
marketing. The goal of this description is not to analyze these this description is not to analyze these benefits or discuss the
benefits or the accuracy of the perception (detailed discussions in accuracy of the perception (detailed discussions in [4]), but to
[4]), but to describe the deployment requirements and set a context describe the deployment requirements and set a context for the later
for the later descriptions of the IPv6 approaches for dealing with descriptions of the IPv6 approaches for dealing with those
those requirements. requirements.
2.1. Simple Gateway between Internet and Private Network 2.1. Simple Gateway between Internet and Private Network
A NAT device can connect a private network with addresses allocated A NAT device can connect a private network with any kind of address
from any part of the space (ambiguous [RFC 1918] or global registered (ambiguous [RFC 1918] or global registered address) towards the
address) towards the Internet, though extra effort is needed when the Internet. The address space of the private network can be built from
same range exists on both sides of the NAT. The address space of the globally unique addresses, from ambiguous address space or from both
private network can be built from globally unique addresses, from simultaneously. Without needing specific configuration, the NAT
ambiguous address space or from both simultaneously. In the simple device enables access between the client side of a distributed
case of private use addresses, without needing specific configuration client-server application in the private network and the server side
the NAT device enables access between the client side of a in the public Internet.
distributed client-server application in the private network and the
server side located 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, or even a technical end user. Frequently a simple user interface, or even a
default configuration is sufficient for configuring both device and default configuration is sufficient for configuring both device and
application access rights. application access rights.
This simplicity comes at a price as the resulting topology puts
restrictions on applications. The NAT simplicity works well when the
applications are limited to a client/server model with the server
deployed on the public side of the NAT. For peer-to-peer, multi-
party, or servers deployed on the private side of the NAT, helper
technologies must be available. These helper technologies are
frequently complex to develop and manage, creating a hidden cost to
this 'simple gateway'.
Additionally, thanks to successful marketing campaigns it is Additionally, thanks to successful marketing campaigns it is
perceived by end users that by installing a NAT as the gateway, their perceived by end users that their equipment is protected from the
equipment is protected from the malicious entities and attackers on malicious entities and attackers on the public IPv4 Internet.
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
from inside or are at a layer higher than the firewall can protect
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
robust in the face of challenges like stack overflows etc. What a
firewall does is prevent a network administration from having to pay
for bandwidth to carry unauthorized traffic, and in so doing reduce
the probability of certain kinds of attacks across the protected
boundary.
A distributed security mechanism to protect the end-systems may help
in the above situation; however, to deploy such a system is quite
complex and may depend upon behaviour per operating system and
release version. 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. As a result it will probably not be available in the
next couple of years for end-user organizations. End-system-only
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 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 specific host on any other cannot exploit this state to attack a host in general and on any
port, though in the port overload case of NAPT attacking all active port. This benefit may be partially real, however, experienced
ports will impact a potentially wide number of hosts. This benefit hackers are well aware of NAT devices and are very familiar with
may be partially real, however, experienced hackers are well aware of private address space, and have devised methods of attack (such as
NAT devices and are very familiar with private address space, and trojan horses) that readily penetrate NAT boundaries. For these
have devised methods of attack (such as trojan horses) that readily reasons the sense of security provided by NAT is actually an
penetrate NAT boundaries. For these reasons the sense of security illusion.
provided by NAT is actually an illusion.
The act of address translation does not provide security in itself; Address translation does not provide security in itself; for example,
for example, consider a configuration with static NAT translation and consider a configuration with static NAT translation and all inbound
all inbound ports translating to a single machine. In such a ports translating to a single machine. In such a scenario the
scenario the security risk for that machine is identical to the case security risk for that machine is identical to the case with no NAT
with no NAT device in the communication path. As result there is no device in the communication path. As result there is no specific
specific security value in the address translation function. The security value in the address translation function. The perceived
perceived security in this case comes from the lack of pre- security comes from the lack of pre-established or permanent mapping
established or permanent mapping state. Dynamically establishing state. Dynamically establishing state in response to internal
state in response to internal requests reduces the threat of requests reduces the threat of unexpected external connections to
unexpected external connections to internal devices. This role, internal devices.
marketed as a firewall, is really an arbitrary artifact while a real
firewall has explicit management controls.
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 two or complexity compared to a simple router. In situations where two or
more devices need to host the same application or otherwise use the more devices need to host the same application this complexity shifts
same public port this complexity shifts from difficult to impossible. from difficult to impossible.
2.3. User/Application tracking 2.3. User/Application tracking
One usage of NAT is for the local network administrator to track user Although NATs create temporary state for active sessions, in general
and application traffic. Although NATs create temporary state for they provide limited capabilities for the administrator of the NAT to
active sessions, in general they provide limited capabilities for the gather information about who in the private network is requesting
administrator of the NAT to gather information about who in the access to which Internet location. This could in theory be done by
private network is requesting access to which Internet location. logging the network address translation details of the private and
This is done by periodically logging the network address translation the public addresses from the NAT device's state database.
details of the private and the public addresses from the NAT device's
state database.
The subsequent checking of this database is not always a simple task, The checking of this database is not always a simple task, especially
especially if Port Address Translation is used. It also has an if Port Address Translation is used. It also has an unstated
unstated assumption that the administrative instance has a mapping assumption that the administrative instance has a mapping between an
between a private IPv4-address and a network element or user at all IPv4-address and a network element or user at all times, or the
times, or the administrator has a time-correlated list of the administrator has a time-correlated list of the address/port
address/port mappings. mappings.
2.4. Privacy and Topology Hiding 2.4. Privacy and Topology Hiding
The goal of 'topology hiding' is to prevent external entities from The goal of 'topology hiding' is to provide devices on the private
making a correlation between the topological location of devices on network with an identifier (IPv4 address) which an entity outside the
the local network. The ability of NAT to provide Internet access to network can use to communicate with or to reference the private
a large community of users by the use of a single (or a few) global network devices in protocols but prevents the external entity making
IPv4 routable addresses offers a simple mechanism to hide the a correlation between the topological location of the private device
internal topology of a network. In this scenario the large community and the address on the local network.
will be represented in the Internet by a single (or a few) IPv4
address(es). 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, usually known as 'device profiling'. At the same time a addresses, usually known as 'device profiling'. At the same time a
NAT creates a smaller pool of addresses for a much more focused point NAT creates a smaller pool of addresses for a much more focused point
of attack, where the adversary does not need to scan the entire of attack.
network. By periodically scanning the limited 16 bit port range on
the public side of the NAT, the attack will eventually find ports
that are open to active nodes.
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
skipping to change at page 10, line 20 skipping to change at page 9, line 26
80. Any vulnerable open ports could be used for initiating attacks 80. Any vulnerable open ports could be used for initiating attacks
on an end 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
local 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.
Section 2.7 describes some disadvantages that appear if independent Section 2.7 describes some disadvantages that appear if independent
networks using [RFC1918] addresses have to be merged. networks using [RFC1918] addresses have to be merged.
2.6. Global Address Pool Conservation 2.6. Global Address Pool Conservation
While the widespread use of IPv4+NAT has reduced the potential Due to the ongoing depletion of the IPv4 address range, the remaining
consumption rate, due to the ongoing depletion of the IPv4 address pool of unallocated IPv4 addresses is below 30%. While mathematical
range the remaining pool of unallocated IPv4 addresses is already models based on historical IPv4 prefix consumption periodically
below 25%. While mathematical models based on historical IPv4 prefix attempt to predict the future exhaustion date of the IPv4 address
consumption periodically attempt to predict the future exhaustion pool, a direct result of this continuous resource consumption is that
date of the IPv4 address pool, a direct result of this continuous the administrative overhead for acquiring globally unique IPv4
resource consumption is that the administrative overhead for addresses will continue increasing in direct response to tightening
acquiring globally unique IPv4 addresses will continue increasing in allocation policies. In response to the increasing administrative
direct response to tightening allocation policies. overhead many Internet Service Providers (ISPs) have already resorted
to the ambiguous addresses defined in RFC 1918 behind a NAT for the
In response to the increasing administrative overhead many Internet various services they provide as well as connections for their end
Service Providers (ISPs) have already resorted to the ambiguous customers. This happens even though that private address-space is
addresses defined in RFC 1918 behind a NAT for the various services strictly limited in size. In turn this has restricted the number of
they provide as well as connections for their end customers. This and types of applications that can be deployed by these ISPs and
happens even though the private use address-space is strictly limited their customers. Forced into this limiting situation such customers
in size. Some deployments have already outgrown that space and have
begun cascading NAT to continue expanding. Unfortunately, the number
of and types of applications that can be deployed by these ISPs and
their customers is restricted by the ability to overload the port
range on the public side of the most public NAT in the path. The
result is something substantially less than 2^48 possible active
application endpoints, rather than the perception of arbitrary
utility one might expect from the large number of addressable
devices. In addition it is highly likely that nodes will become
confused because they are not topology aware, though as already
mentioned NAT enforces specific topologies on the application
deployment model. Forced into this limiting situation such customers
can rightly claim that despite the optimistic predictions of can rightly claim that despite the optimistic predictions of
mathematical models the global pool of IPv4 addresses is effectively mathematical models the global pool of IPv4 addresses is effectively
already exhausted, especially for larger enterprises. already exhausted, especially for larger enterprises.
2.7. Multihoming and Renumbering with NAT 2.7. Multihoming and Renumbering with NAT
Allowing a network to be multihomed and renumbering a network are Allowing a network to be multihomed and renumbering a network are
quite different functions. However these are argued together as quite different functions. However, making a network multihomed is
reasons for using NAT, because making a network multihomed is often a often a transitional state required as part of network renumbering,
transitional state required as part of network renumbering, and NAT and NAT interacts with both in the same way.
interacts with both in the same way.
For enterprise networks, it is highly desirable to provide resiliency For enterprise networks, it is highly desirable to provide resiliency
and load-balancing to be connected to more than one Internet Service and load-balancing to be connected to more than one Internet Service
Provider (ISP) and to be able to change ISPs at will. This means Provider (ISP) and to be able to change ISPs at will. This means
that a site must be able to operate under more than one CIDR prefix that a site must be able to operate under more than one CIDR prefix
[14] and/or readily change its CIDR prefix. Unfortunately, IPv4 was [14] and/or readily change its CIDR prefix. Unfortunately, IPv4 was
not designed to facilitate either of these maneuvers. However, if a not designed to facilitate either of these maneuvers. However, if a
site is connected to its ISPs via NAT boxes, only those boxes need to site is connected to its ISPs via NAT boxes, only those boxes need to
deal with multihoming and renumbering issues. deal with multihoming and renumbering issues.
skipping to change at page 12, line 32 skipping to change at page 11, line 25
other information collectors to identify when addresses used in other information collectors to identify when addresses used in
different transactions actually correspond to the same node. A different transactions actually correspond to the same node. A
relatively short valid lifetime for the privacy address also has the relatively short valid lifetime for the privacy address also has the
side effect of reducing the attack profile of a device, as it is not side effect of reducing the attack profile of a device, as it is not
directly attackable once it stops answering at the temporary use directly attackable once it stops answering at the temporary use
address. 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,
in a request, then remembering that for future queries. This would then remembering that for future queries. This would allow using
allow using them in DNS for registered services since the assumption them in DNS for registered services since the assumption of a server
of a DHCP server based deployment would be a persistent value that based deployment would be a persistent value that minimizes DNS
minimizes DNS churn. A DHCP based deployment would also allow for churn. A DHCP based deployment would also allow for local policy to
local policy to periodically change the entire collection of end periodically change the entire collection of end device addresses
device addresses while maintaining some degree of central knowledge while maintaining some degree of central knowledge and control over
and control over which addresses should be in use at any point in which addresses should be in use at any point in time.
time.
Randomizing the IID, as defined in RFC 3041, is effectively a sparse Randomizing the IID, as defined in RFC 3041, only precludes tracking
allocation technique which only precludes tracking of the lower 64 of the lower 64 bits of the IPv6 address. Masking of the subnet ID
bits of the IPv6 address. Masking of the subnet ID will require will require additional approaches as discussed below in 3.4.
additional approaches as discussed below in 3.4. Additional Additional considerations are discussed in [17].
considerations are discussed in [17].
3.2. Unique Local Addresses 3.2. Unique Local Addresses
Acheiving the goal of autonomy is required for local network and Local network and application services stability during periods of
application services stability during periods of intermittent intermittent connectivity between one or more providers requires
connectivity between one or more providers. Such autonomy in a address management autonomy. Such autonomy in a single routing
single routing prefix environment would lead to massive expansion of prefix environment would lead to massive expansion of the global
the global routing tables (as seen in IPv4), so IPv6 provides for routing tables, so IPv6 provides for simultaneous use of multiple
simultaneous use of multiple prefixes. The Unique Local Address prefixes. The Unique Local Address prefix (ULA) [13] has been set
prefix (ULA) [13] has been set aside for use in local communications. aside for use in local communications. The ULA address prefix for
The ULA address prefix for any network is routable over a locally any network is routable over a locally defined collection of routers.
defined collection of routers. These prefixes are not intended to be These prefixes are not intended to be routed on the public global
routed on the public global Internet as large scale inter-domain Internet; large scale inter-domain distribution of routes to ULA
distribution of routes for ULA prefixes would have a negative impact prefixes would have a negative impact on global route aggregation.
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 address conflicts or requiring renumbering of without creating any address conflicts or requiring renumbering
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,
it is highly unlikely that there will be a conflict with any it is highly unlikely that there will be a conflict with any
other addresses 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 or only intermittent network without having any permanent or intermittent Internet
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 preventing leakage of local routes and packets. boundaries preventing leakage of local routes and packets.
o In practice, applications may treat these addresses like global o In practice, applications may treat these addresses like global
scoped addresses but address selection algorithms may need to scoped addresses but address selection algorithms need to
distinguish between ULAs and ordinary global scope unicast distinguish between ULAs and ordinary global scope unicast
addresses to assure stability. The policy table defined in [10] addresses. Mixing the two kinds of addresses is likely to lead to
is one way to bias this selection, by giving higher preference to undeliverable packets.
FC00::/7 over 2001::/3. Mixing the two kinds of addresses may
lead to undeliverable packets during times of instability, but
that mixing is not likely to happen when the rules of RFC 3484 are
followed.
3.3. DHCPv6 Prefix Delegation 3.3. DHCPv6 Prefix Delegation
One of the functions of a simple gateway is managing the local use The Prefix Delegation (DHCP-PD) options [11] provide a mechanism for
address range. The Prefix Delegation (DHCP-PD) options [11] provide automated delegation of IPv6 prefixes using the Dynamic Host
a mechanism for automated delegation of IPv6 prefixes using the Configuration Protocol (DHCP) [9]. This mechanism (DHCP-PD) is
Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism intended for delegating a long-lived prefix from a delegating router
(DHCP-PD) is intended for delegating a long-lived prefix from a (incorporating a DHCPv6 server) to a requesting router, possibly
delegating router (possibly incorporating a DHCPv6 server) to a across an administrative boundary, where the delegating router does
requesting router, possibly across an administrative boundary, where not require knowledge about the topology of the links in the network
the delegating router does not require knowledge about the topology to which the prefixes will be assigned.
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
randomly and independently assigned to IPv6 devices.
The random assignment is intended to mislead the outside world about
the structure of the local network. However the local network needs
to maintain a correlation between the location of the device and the
untraceable IPv6 address. This correlation could be done by
generating IPv6 host route entries or by utilizing an indirection
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 amorphous network infrastructure as seen from external apparently amorphous network infrastructure as seen from external
networks to protect the local infrastructure from malicious outside networks to protect the local infrastructure from malicious outside
influences and from mapping of any correlation between the network influences and from mapping of any correlation between the network
activities of multiple devices from external networks. When using activities of multiple devices from external networks. When using
untraceable IPv6 addresses, it could be that two apparently untraceable IPv6 addresses, it could be that two apparently
sequential addresses are allocated to devices on very different parts sequential addresses are allocated to devices on very different parts
of the local network instead of belonging to devices adjacent to each of the local network instead of belonging to devices adjacent to each
other on the same subnet. other on the same subnet.
These should be globally routable IPv6 addresses which can be
randomly and independently assigned to IPv6 devices.
The random assignment is intended to mislead the outside world about
the structure of the local network. However the local network needs
to maintain a correlation between the location of the device and the
untraceable IPv6 address. For smaller deployments this correlation
could be done by generating IPv6 host route entries, or for larger
ones by utilizing an indirection device such as a Mobile IPv6 Home
Agent. Additional details are in section 4.7.
4. Using IPv6 Technology to Provide the Market Perceived Benefits of 4. Using IPv6 Technology to Provide the Market Perceived Benefits of
NAT NAT
The facilities in IPv6 described in Section 3 can be used to provide The facilities in IPv6 described in Section 3 can be used to provide
the protection perceived to be associated with IPv4 NAT. This the protection perceived to be associated with IPv4 NAT. This
section gives some examples of how IPv6 can be used securely. section gives some examples of how IPv6 can be used securely.
4.1. Simple Gateway between Internet and Internal Network 4.1. Simple Gateway between Internet and Internal Network
As a simple gateway, the device manages both packet routing and local As a simple gateway, the device manages both packet routing and local
address management. A basic IPv6 router should have a default address management. A basic IPv6 router could have a default
configuration to advertise inside the site a locally generated random configuration to advertise inside the site a locally generated random
ULA prefix, independently from the state of any external ULA prefix, independently from the state of any external
connectivity. This would allow local nodes to communicate amongst connectivity. This would allow local nodes to communicate amongst
themselves independent of the state of a global connection. If the themselves prior to establishing a global connection. If the network
network happened to concatenate with another local network, the happened to concatenate with another local network, this is highly
randomness in ULA creation is highly unlikely to result in address unlikely to result in address collisions. A more secure network
collisions. 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.
With external connectivity the simple gateway should use DHCP-PD to With external connectivity the simple gateway could also use DHCP-PD
acquire a routing prefix from the service provider for use when to acquire a routing prefix from the service provider for use when
connecting to the global Internet. End-system connections involving connecting to the global Internet. End-system connections involving
other nodes on the global Internet will always use the global IPv6 other nodes on the global Internet will always use the global IPv6
addresses derived from this prefix delegation. It should be noted addresses [9] derived from this prefix delegation. It should be
that the address selection policy table in end-systems defined in RFC noted that the address selection policy table in end-systems needs to
3484 should be configured to prefer the ULA prefix range over the be correctly set up so that true global prefixes are distinguished
DHCP-PD prefix range when the goal is to keep local communications from ULAs and will be used for the source address in preference when
stable during periods of transient external connectivity. the destination is not a ULA.
In the very simple case there is no explicit routing protocol on In the very simple case there is no explicit routing protocol and a
either side of the gateway, and a single default route is used single default route is used out to the global Internet. A slightly
internally pointing out to the global Internet. A slightly more more complex case might involve local routing protocols, but with the
complex case might involve local internal routing protocols, but with entire local network sharing a common global prefix there would still
the entire local network sharing a common global prefix there would not be a need for an external routing protocol as a default route
still not be a need for an external routing protocol as the service would continue to be consistent with the connectivity.
provider could install a route for the delegated prefix pointing
toward the connecting link.
4.2. IPv6 and Simple Security 4.2. IPv6 and Simple Security
The vulnerability of an IPv6 host is similar to that of an IPv4 host The vulnerability of an IPv6 host is similar to that of an IPv4 host
directly connected towards the Internet. The use of firewall and directly connected towards the Internet. The use of firewall and
Intrusion Detection Systems (IDS) is recommended for those that want Intrusion Detection Systems (IDS) is recommended. A proxy may be
boundary protection in addition to host defences. A proxy may be
used for certain applications, but with the caveat that the end to used for certain applications, but with the caveat that the end to
end transparency is broken. However, with IPv6, the following end transparancy is broken. However, with IPv6, the following
protections are available without the use of NAT while maintaining protections are available without the use of NAT while maintaining
end-to-end reachability: end-to-end reachability:
1. Short lifetimes on privacy extension suffixes reduce the attack 1. Short lifetimes on privacy extension suffixes reduce the attack
profile since the node will not respond to the address once its profile since the node will not respond to the address once the
lifetime becomes invalid. 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
works the same way and might be available in IPv4 might be available in IPv4 implementations, deployment in NAT
implementations, deployment in NAT environments either breaks the environments either breaks the protocol or requires complex
protocol or requires complex helper services with limited helper services with limited functionality or efficiency.
functionality or efficiency.
3. The size of the address space of a typical subnet (64 bits of 3. The size of the address space of a typical subnet (64 bits of
IID) will make a complete subnet ping sweep virtually impossible IID) will make an effective network ping sweep and resulting
due to the number of possible combinations available. Reducing port-scan virtually impossible due to the number of possible
the security threat of port scans on identified nodes requires combinations available, provided that IIDs are essentially
sparse distribution within the subnet to minimize the list of randomly distributed across the available space. This protection
known nodes. Provided that IIDs are essentially randomly is nullified if the attacker has no access to a local connection.
distributed across the available space, address scanning based If an attacker has local access then he could use ND [3] and
attacks will fail. This protection exists if the attacker has no ping6 to ff02::1 to detect local neighbors. (Of course, a
direct access to the specific subnet. If an attacker has local
access then he could use ND [3] and ping6 to the link-scope
multicast 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.) This scanning protection will also be nullified if IIDs well.) It is recommended for site administrators to take [18]
are configured in a group near the start of the IID space. into consideration to achieve the expected goal. This protection
will also be nullified if IIDs are configured in a group near the
Assuming the network administrator is aware of [18]the increased size start of the IID space.
of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices. The intention of topology
probing is to identify a selection of the available hosts inside an
enterprise. This mostly starts with a ping-sweep. Since the IPv6
subnets are 64 bits worth of address space, this means that an
attacker has to send out a simply unrealistic number of pings to map
the network, and virus/worm propagation will 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.
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 offer 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. IPv6 security best their network is secure due to the usage of NAT. IPv6 security best
practices will avoid this kind of illusory security but can only practices will avoid this kind of illusory security but can only do
address the same threats if correctly configured firewalls and IDS this if correctly configured firewalls and IDS systems are used at
systems are used at the perimeter where some IPv4 networks have the perimeter where some IPv4 networks have relied on NATs.
relied on NATs.
It must be noted that even a firewall doesn't fully secure a network.
Many attacks come from inside or are at a layer higher than the
firewall can protect 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 robust in the face of challenges like stack
overflows etc. What a firewall does is prevent a network
administration from having to pay for bandwidth to carry unauthorized
traffic, and in so doing reduce the probability of certain kinds of
attacks across the protected boundary.
To implement simple security for IPv6 in, for example, a DSL To implement simple security for IPv6 in, for example, a DSL
connected home network, the DSL broadband gateway/router should be connected home network, the DSL broadband gateway/router should be
equipped with stateful firewall capabilities. These should provide a equipped with stateful firewall capabilities. These should provide a
default configuration where incoming traffic is limited to return default configuration which provides a minimum set of connectivity
traffic resulting from outgoing packets (sometimes known as for users in the home network (e.g., just to external HTTP servers)
reflective session state). There should also be an easy interface with incoming traffic limited to return traffic resulting from
which allows users to create inbound 'pinholes' for specific purposes outgoing packets (sometimes known as reflective session state) with
such as online-gaming. Another consideration would be the capability an easy interface which allows users to create additional 'pinholes'
for service provider mediated pinhole management where things like for specific purposes.
voice call signalling could dynamically establish pinholes based on
predefined rules.
Administrators and the designers of configuration interfaces for Administrators and the designers of configuration interfaces for
simple IPv6 Firewalls need to provide a means of documenting the simple IPv6 Firewalls need to provide a means of documenting the
security caveats that arise from a given set configuration rules so security caveats that arise from a given set configuration rules so
that users (who are normally oblivious to such things) can be made that users (who are normally oblivious to such things) can be made
aware of the risks. As rules are improved iteratively, the goal will aware of the risks. As rules are improved iteratively, the goal will
be to make use of the IPv6 Internet more secure for oblivious users. be to make use of the IPv6 Internet more secure for oblivious users.
Assuming the network administrator is aware of [18] the increased
size of the IPv6 address will make topology probing much harder, and
almost impossible for IPv6 devices. The intention of topology
probing is to identify a selection of the available hosts inside an
enterprise. This mostly starts with a ping-sweep. Since the IPv6
subnets are 64 bits worth of address space, this means that an
attacker has to send out a simply unrealistic number of pings to map
the network, and virus/worm propagation will 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.
At the same time, this tracking is per address. In environments
where the goal is tracking back to the user, additional external
information will be necessary coorelating a user with an address. In
the case of short lifetime privacy address usage, this external
information will need to be based on more stable information such as
the layer 2 media address.
4.4. Privacy and Topology Hiding using IPv6 4.4. Privacy and Topology Hiding using IPv6
Partial host privacy is achieved in IPv6 using pseudo-random privacy Partial host privacy is achieved in IPv6 using pseudo-random privacy
addresses [RFC 3041] which are generated as required, so that a addresses [RFC 3041] which are generated as required, so that a
session 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.
This only allows such a session to be traced back to the subnet that Exactly as with IPv4 NAT, this only allows such a session to be
originates it, but not immediately to the actual host, where IPv4 NAT traced back to the subnet that originates it, but not immediately to
is only tracable to the most public NAT interface. the actual host.
Due to the large IPv6 address space available there is plenty of Due to the large IPv6 address space available there is plenty of
freedom to randomize subnet allocations. By doing this, it is freedom to randomize subnet allocations. By doing this, it is
possible to reduce the correlation between a subnet and its location. possible to reduce the correlation between a subnet and its location.
When doing both subnet and IID randomization [RFC 3041] a casual When doing both subnet and IID randomization [RFC 3041] a casual
snooper won't be able to deduce much about the networks topology. snooper won't be able to deduce much about the networks topology.
The obtaining of a single address will tell the snooper very little The obtaining of a single address will tell the snooper very little
about other addresses. This is different from IPv4 where address about other addresses. This is different from IPv4 where address
space limitations cause this to be not true. In most usage cases space limitations cause this to be not true. In most usage cases
this concept should be sufficient for address privacy and topology this concept should be sufficient for address privacy and topology
hiding, with the cost being a more complex internal routing hiding.
configuration.
In the case where a network administrator wishes to fully isolate the In the case where a network administrator wishes to fully conceal the
internal IPv6 topology, and the majority of its host computer internal IPv6 topology, and the majority of its host computer
addresses, a possible option is to run all internal traffic using addresses, a possible option is to run all internal traffic using
Unique Local Addresses (ULA) since by definition external traffic Unique Local Addresses (ULA) since such packets can by definition
will never reach the site. For the set of hosts that do in fact need never exit the site. For hosts that do in fact need to generate
to interact externally, by using multiple IPv6 addresses (ULAs and external traffic, by using multiple IPv6 addresses (ULAs and one or
one or more global addresses), it will be possible to hide and mask more global addresses), it will be possible to hide and mask some or
some or all of the internal network. As discussed in Section 3.1, all of the internal network. As discussed in Section 3.1, there are
there are multiple parts to the IPv6 address, and different multiple parts to the IPv6 address, and different techniques to
techniques to manage privacy for each which may be combined to manage privacy for each.
protect the entire address.
There are other possible scenarios for the extreme situation when a There are two possible scenarios for the extreme situation when a
network manager also wishes to fully conceal the internal IPv6 network manager also wishes to fully conceal the internal IPv6
topology. In these cases the goal in replacing the IPv4 NAT approach topology.
is to make all of the topology hidden nodes appear from the outside
to exist at the edge of the network, just as they would when behind a
NAT.
o One could use explicit host routes and remove the correlation o One could use explicit host routes and remove the correlation
between location and IPv6 address. In the figure below the hosts between location and IPv6 address. This solution does however
would be allocated prefixes from one or more logical subnets, and show severe scalability issues.
would inject host routes to internally identify their real o The other technology to fully hide the internal topology would be
attachment point. This solution does however show severe to use a tunneling mechanism. Mobile IPv6 without route
scalability issues and should be limited to uses with optimization is one example. In this example the public facing
substantially fewer than the maximum number of routes that the IGP addresses are indirected via an edge Home Agent (HA). This
can support (generally about 50,000). indirection method truly masks the internal topology as all nodes
o Another technology to fully hide the internal topology would be to with global access appear to share a common prefix. The downside
use a tunneling mechanism. Mobile IPv6 without route optimization of using this method is that it makes usage of middleware like a
is one example. In this example the public facing addresses are Home Agent (HA).
indirected via the edge Home Agent (HA). This indirection method
truly masks the internal topology as all nodes with global access
appear to share the prefix of one or more logical subnets attached
to the HA. While turning off all binding updates would appear to
be necessary to prevent leakage of topology information, that
approach would also force all internal traffic to route via the HA
tunnel. A better method would be to allow internal route
optimizations while dropping outbound binding updates at the
firewall. The downsides of using this tunneling method is that it
makes usage of middleware like a Home Agent (HA) and consumes
slightly more bandwidth for the tunnel overhead.
o Another method where the layer 2 topology allows would be to use a
virtual lan approach to logically attach the devices to one or
more subnets on the edge router. The downsides of this approach
is that all internal traffic would be directed over sub-optimal
paths via the edge router, as well as the complexity of managing a
distributed logical lan.
Internet
|
\
|
+------------------+
| Simple Gateway | Logical subnet
| or Home Agent |-+-+-+-+-+-+-+-+--
+------------------+ for topology
| hidden nodes
|
Real internal -------------+-
topology | |
| -+----------
-----------+--------+
|
4.5. Independent Control of Addressing in a Private Network 4.5. Independent Control of Addressing in a Private Network
IPv6 provides for autonomy in local use addresses through ULAs. At IPv6 provides for autonomy in local use addresses through ULAs. At
the same time IPv6 simplifies simultaneous use of multiple addresses the same time IPv6 simplifies simultaneous use of multiple addresses
per interface so that an IPv6 NAT is not required between the ULA and per interface so that an IPv6 NAT is not required between the ULA and
the public Internet because nodes that need access to the public the public Internet. Nodes that need access to the public Internet
Internet will have a global use address as well. When using IPv6, may have a ULA for local use, and will have a global use address
the need to ask for more address space will become far less likely because the global use IPv6 address space is not a scarce resource
due to the increased size of the subnets, along with an allocation like the global use IPv4 space. While global IPv6 allocation policy
policy that recognizes table fragmentation is also an important is managed through the Regional Internet Registries, it is expected
consideration. While global IPv6 allocation policy is managed that they will continue with derivatives of [RFC 3177] for the
through the Regional Internet Registries, it is expected that they foreseeable future.
will continue with derivatives of [8] for the foreseeable future so
the number of subnet prefixes available to an organization should not When using IPv6, the need to ask for more address space will become
be a limitation which would create an artifical demand for NAT. far less likely due to the increased size of the subnets. These
subnets typically allow 2^64 addresses per subnet and an enterprise
will typically receive a /48 which allows segmentation into at least
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. Under IPv4 address space policy technology is utilised. If IPv4 address space is optimised one has
restrictions, each subnet must be optimised so one has to look to look periodically into the number of hosts on a segment and the
periodically into the number of hosts on a segment and the subnet subnet size allocated to the segment; an enterprise today may have a
size allocated to the segment and rebalance. For example an mix of /28 - /23 size subnets for example, and may shrink/grow these
enterprise today may have a mix of /28 - /23 size subnets, and may as their network user base changes. For IPv6 all subnets have /64
shrink/grow these as their network user base changes. For IPv6 all prefixes.
subnets have /64 prefixes which will reduce the operational and
configuration overhead.
4.6. Global Address Pool Conservation 4.6. Global Address Pool Conservation
IPv6 provides sufficient space to completely avoid the need for IPv6 provides sufficient space to completely avoid the need for
overlapping address space with the total possible addresses being overlapping address space,
340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38). 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total
Since allocations in IPv6 are based on subnets rather than hosts a possible addresses. As previously discussed, the serious
more reasonable way to look at the pool is that there are about disadvantages of ambiguous address space have been well documented,
17,293,822,569,102,704,640 (17*10^18) unique subnet values where and with sufficient space there is no need to continue the
sparse allocation practice within those provdes for new opportunities increasingly aggressive conservation practices that are necessary
such as . As previously discussed, the serious disadvantages of with IPv4. While IPv6 allocation policies and ISP business practice
ambiguous address space have been well documented, and with will continue to evolve, the recommendations in RFC 3177 are based on
sufficient space there is no need to continue the increasingly the technical potential of the vast IPv6 address space. That
aggressive conservation practices that are necessary with IPv4. document demonstrates that there is no resource limitation which will
While IPv6 allocation policies and ISP business practice will require the adoption of the IPv4 workaround of ambiguous space behind
continue to evolve, the recommendations in RFC 3177 are based on the a NAT. As an example of the direct contrast, many expansion oriented
technical potential of the vast IPv6 address space. That document IPv6 deployment scenarios result in multiple IPv6 addresses per
demonstrates that there is no resource limitation which will require device, as opposed to the constriction of IPv4 scenarios where
the adoption of the IPv4 workaround of ambiguous space behind a NAT. multiple devices are forced to share a scarce global address.
As an example of the direct contrast, many expansion oriented IPv6
deployment scenarios result in multiple IPv6 addresses per device, as
opposed to the constriction of IPv4 scenarios where multiple devices
are forced to share a scarce global address through a NAT.
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 allocated sites and hosts to run with several simultaneous CIDR-like prefixes
prefixes, and thus with several simultaneous ISPs. An address and thus with several simultaneous ISPs. An address selection
selection mechanism [10] is specified so that hosts will behave mechanism [10] is specified so that hosts will behave consistently
consistently when several addresses are simultaneously valid. The when several addresses are simultaneously valid. The fundamental
fundamental difficulty that IPv4 has in regard to multiple addresses difficulty that IPv4 has in this regard therefore does not apply to
therefore does not apply to IPv6. IPv6 sites can and do run today IPv6. IPv6 sites can and do run today with multiple ISPs active, and
with multiple ISPs active, and the processes for adding and removing the processes for adding and removing active prefixes at a site have
active prefixes at a site have been documented in [12] and [19]. 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 will likely result in a the connecting Service provider. This may result in a renumbering
renumbering effort when the network changes between service effort if the network changes from Service Provider. When changing
providers. When changing ISPs or ISPs readjusting their addressing ISPs or ISPs readjusting their addressing pool, DHCP-PD [11] can be
pool, DHCP-PD [11] can be used as an almost zero-touch external used as an almost zero-touch external mechanism for prefix change in
mechanism for prefix change in conjunction with a ULA prefix for conjunction with a ULA prefix for internal connection stability.
internal connection stability. With appropriate management of the With appropriate management of the lifetime values and overlap of the
lifetime values and overlap of the external prefixes, a smooth make- external prefixes, a smooth make-before-break transition is possible
before-break transition is possible as existing communications will as existing communications will continue on the old prefix as long as
continue on the old prefix as long as it remains valid, while any new it remains valid, while any new communications will use the new
communications will use the new prefix. prefix.
5. Case Studies 5. Case Studies
In presenting these case studies we have chosen to consider In presenting these case studies we have chosen to consider
categories of network divided first according to their function categories of network divided first according to their function
either as carrier/ISP networks or end user (such as enterprise) either as carrier/ISP networks or end user (such as enterprise)
networks with the latter category broken down according to the number networks with the latter category broken down according to the number
of connected end hosts. For each category of networks we can use of connected end hosts. For each of these category of networks we
IPv6 Network Architecture Protection to achieve a secure and flexible can use IPv6 Network Architecture Protection to achieve a secure and
infrastructure, which provides an enhanced network functionality in flexible infrastructure, which provides an enhanced network
comparison with the usage of address translation. 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
The majority of private enterprise networks fall into this category. 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 when using IPv4 there are several reasons why addressing independence when using IPv4 there are several reasons why
they might choose to use NAT in such a network. For the ISP there is they might choose to use NAT in such a network. For the ISP there is
no need to import the IPv4 address range from the remote end- no need to import the IPv4 address range from the remote end-
customer, which facilitates IPv4 route summarization. The customer customer, which facilitates IPv4 route summarization. The customer
can use a larger IPv4 address range (probably with less- can use a larger IPv4 address range (probably with less-
administrative overhead) by the use of RFC 1918 and NAT. The administrative overhead) by the use of RFC 1918 and NAT. The
customer also reduces the overhead in changing to a new ISP, because customer also reduces the overhead in changing to a new ISP, because
the addresses assigned to devices behind the NAT do not need to be the addresses assigned to devices behind the NAT do not need to be
changed when the customer is assigned a different address by a new changed when the customer is assigned a different address by a new
ISP. By using address translation in IPv4 one avoids the expensive ISP. By using address translation one avoids the need for network
process of network renumbering. Finally, the customer can provide renumbering. Finally, the customer can provide privacy for its hosts
privacy for its hosts and the topology of its internal network if the and the topology of its internal network if the internal addresses
internal addresses are mapped through 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. The goal of this assignment mechanism is to can be concatenated. A single /48 allocation provides an enterprise
decrease the total amount of entries in the public Internet routing network with 65536 different /64 prefixes.
table. A single /48 allocation provides an enterprise network with
65536 different /64 subnet prefixes. The summarization benefit for the ISP results from the IPv6
allocation rules. This means that the ISP will provide the
enterprise with an IPv6 address-range (typically one or multiple
range(s) of '/48') from its RIR assigned IPv6 address-space. The
goal of this assignment mechanism is to decrease the total amount of
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 time-limited factor to the host part of an extensions add a random factor to the host part of an IPv6 address
IPv6 address and will make it very hard for an external element to and will make it very hard for an external element to keep
keep correlating the IPv6 address to a specific host on the inside correlating the IPv6 address to a host on the inside network. The
network. The usage of IPv6 privacy extensions does not mask the usage of IPv6 privacy extensions does not mask the internal network
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 or static configuration. To complement the 'Untraceable' on DHCPv6. To complement the 'Untraceable' addresses it is needed to
addresses it is needed to have at least awareness of the IPv6 address have at least awareness of the IPv6 address location when routing an
location when routing an IPv6 packet through the internal network. IPv6 packet through the internal network. This could be achieved by
This could be achieved by 'route-injection' in the local network 'route-injection' in the network infrastructure. This route-
infrastructure. This route-injection could be done based on /128 injection could be done based on /128 host-routes to each device that
host-routes to each device that wants to connect to the Internet wants to connect to the Internet using an untraceable address. This
using an untraceable address. This will provide the most dynamic will provide the most dynamic masking, but will have a scalability
masking, but will have a scalability limitation, as an IGP is limitation, as an IGP is typically not designed to carry many
typically not designed to carry many thousands of IPv6 prefixes. A thousands of IPv6 prefixes. A large enterprise may have thousands of
large enterprise may have thousands of hosts willing to connect to hosts willing to connect to the Internet. Less flexible masking
the Internet. could be to have time-based IPv6 prefixes per link or subnet. This
may reduce the amount of route entries in the IGP by a significant
An alternative for larger deployments is to leverage the tunneling factor, but has as trade-off that masking is time and subnet based.
aspect of MIPv6 even for non-mobile devices. With the logical subnet
being allocated as attached to the edge Home Agent, the real
attachment and internal topology are masked from the outside.
Dropping outbound binding updates at the firewall is also necessary
to avoid leaking the attachment information.
Less flexible masking could be to have time-based IPv6 prefixes per The dynamic allocation of 'Untraceable' addresses can also limit the
link or subnet. This may reduce the amount of route entries in the IPv6 access between local and external hosts to those local hosts
IGP by a significant factor, but has as trade-off that masking is being authorized for this capability. Dynamically allocated
time and subnet based.The dynamic allocation of 'Untraceable' 'Untraceable' addresses may also facilitate and simplify the
addresses can also limit the IPv6 access between local and external connectivity to the outside networks during renumbering, because the
hosts to those local hosts being authorized for this capability. existing IPv6 central address pool could be swapped for the newly
Dynamically allocated 'Untraceable' addresses may also facilitate and allocated IPv6 address pool.
simplify the connectivity to the outside networks during renumbering,
because the existing IPv6 central address pool could be swapped for
the newly 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 will that even if an enterprise would change its ISP, the renumbering will
only affect 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
skipping to change at page 23, line 37 skipping to change at page 20, line 40
blocks, or IPv4 prefixes that are static over time, due to the larger blocks, or IPv4 prefixes that are static over time, due to the larger
public address pool each of those requires. 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 external sufficient technical knowledge to manage the NAT to enable a server,
access to a server, only one server can be mapped per protocol/port only one server of any given protocol type is possible per address,
number per address, and then only when the address from the ISP is and then only when the address from the ISP is public.
public. When there is an upstream NAT providing private address
space to the ISP side of the private NAT, additional negotiation with
the ISP will be necessary to provide an inbound mapping, if that is
even possible.
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 is For the DHCPv6-PD solution, a dynamic address allocation approach is
chosen. By means of the enhanced DHCPv6 protocol it is possible to chosen. By means of the enhanced DHCPv6 protocol it is possible to
have the ISP push down an IPv6 prefix range automatically towards the have the ISP push down an IPv6 prefix range automatically towards the
small private network and populate all interfaces in that small small private network and populate all interfaces in that small
skipping to change at page 24, line 30 skipping to change at page 21, line 29
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
use on a single piece of equipment (PC, PDA, etc.). This is expected use on a single piece of equipment (PC, PDA, etc.). This is expected
to be rare though, because in the IPv6 world the assumption is that to be rare though, because in the IPv6 world the assumption is that
there is an unrestricted availability of a large amount of globally there is an unrestricted availability of a large amount of globally
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 it will be likely that available at essentially the same cost. Also if the single device
the single device wants to mask its identity to the called party or wants to mask its identity to the called party or its attack profile
its attack profile over a shorter time window than the life of the over a short time window it will need to enable IPv6 privacy
ISP attachment, so it will need to enable IPv6 privacy extensions extensions, which in turn leads to the need for a minimum allocation
which in turn leads to the need for a minimum allocation of a /64 of a /64 prefix rather than a single address.
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
skipping to change at page 25, line 17 skipping to change at page 22, line 16
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 IP access and transport services. They tend to have three the IPv4 access and transport services. They tend to have three
separate IP 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 IPv4 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 Section 5.1. The second domain of the ISP/carrier is the in Section 5.1. The second domain of the ISP/carrier is the
Operations network. This environment tends to be a closed Operations network. This environment tends to be a closed
environment, and consequently communication can be done based on ULA environment, and consequently communication can be done based on ULA
addresses, however, in this environment, stable IPv6 Provider addresses, however, in this environment, stable IPv6 Provider
Independent addresses can be used. This would give a solid and Independent addresses can be used in preference to ULA addresses.
scalable configuration with respect to a local IPv6 address plan. By This would give a solid and scalable configuration with respect to a
the usage of proper network edge filters, outside access to the local IPv6 address plan. By the usage of proper network edge
closed environment can be avoided. The third is the IPv6 addresses filters, outside access to the closed environment can be avoided.
that ISP/carrier network assign to customers. These will typically The third is the IPv6 addresses that ISP/carrier network assign to
be assigned with prefix lengths terminating on nibble boundaries to customers. These will typically be assigned with prefix lengths
be consistent with the DNS PTR records. As scarcity of IPv6 terminating on nibble boundaries to be consistent with the DNS PTR
addresses is not a concern, it will be possible for the ISP to records. As scarcity of IPv6 addresses is not a concern, it will be
provide global routable IPv6 prefixes without a requirement for possible for the ISP to provide global routable IPv6 prefixes without
address translation. An ISP may for commercial reasons still decide a requirement for address translation. An ISP may for commercial
to restrict the capabilities of the end users by other means like reasons still decide to restrict the capabilities of the end users by
traffic and/or route filtering etc. 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' [15] 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.
skipping to change at page 26, line 26 skipping to change at page 23, line 24
continues as deployments are ongoing. This section discusses several continues as deployments are ongoing. This section discusses several
topics for which additional standardization, or documentation of best topics for which additional standardization, or documentation of best
practice, is required to fully realize the benefits of NAP. None of practice, is required to fully realize the benefits of NAP. None of
these items are show-stoppers for immediate usage of NAP in roles these items are show-stoppers for immediate usage of NAP in roles
where there are no current gaps. where there are no current gaps.
6.1. Subnet Topology Masking 6.1. Subnet Topology Masking
There really is no functional gap here as a centrally assigned pool There really is no functional gap here as a centrally assigned pool
of addresses in combination with host routes in the IGP is an of addresses in combination with host routes in the IGP is an
effective way to mask topology for smaller deployments. If necessary effective way to mask topology. If necessary a best practice
a best practice document could be developed describing the document could be developed describing the interaction between DHCP
interaction between DHCP and various IGPs which would in effect and various IGPs which would in effect define Untraceable Addresses.
define Untraceable Addresses.
As an alternative for larger deployments, there is no gap in the HA As an alternative, some work in Mobile IP to define a policy message
tunneling approach when firewalls are configured to block outbound where a mobile node would learn from the Home Agent. It should not
binding update messages. A border Home Agent using internal try to inform its correspondent about route optimization and thereby
tunneling to the logical mobile node (potentially rack mounted) can expose its real location. A border Home Agent using internal
tunneling to the logical mobile node (potentially static) can
completely mask all internal topology, while avoiding the strain from completely mask all internal topology, while avoiding the strain from
a large number of host routes in the IGP. Some optimization work a large number of host routes in the IGP. This work should be
could be done in Mobile IP to define a policy message where a mobile
node would learn from the Home Agent that it should not try to inform
its correspondent about route optimization and thereby expose its
real location. This optimization which reduces the load on the
firewall would result in less optimal internal traffic routing as
that would also transit the HA. This optimization work should be
pursued in the IETF. pursued in the IETF.
6.2. 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 may be 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.3. Renumbering Procedure 6.3. Renumbering Procedure
Site renumbering procedures are discussed in [12]. It should also be Documentation of site renumbering procedures [12] is completed and is
noticed that ULAs may help here too, since a change of ISP prefix in the RFC-editor's queue. It should also be noticed that ULAs may
will only affect hosts that are communicating externally. help here too, since a change of ISP prefix will only affect hosts
that need an externally routeable address as well as an ULA.
6.4. Site Multihoming 6.4. Site Multihoming
This complex problem has never been completely solved for IPv4, which This complex problem has never been completely solved for IPv4, which
is exactly why NAT has been used as a partial solution. For IPv6, is exactly why NAT has been used as a partial solution. For IPv6,
after several years of work, the IETF has converged on an after several years' work, the IETF has converged on an architectural
architectural approach intended with service restoration as initial approach intended with service restoration as initial aim [20].
aim [20]. Again, ULAs may 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.5. 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 and suppliers have been implementing sold IPv4 NAT as a security tool and suppliers have been implementing
address translation functionality in their firewalls, though the address translation functionality in their firewalls, though the
misleading nature of those claims has been previously documented in misleading nature of those claims has been previously documented in
[2] and [4]. RFC 2663 [2] and RFC 2993 [4].
This document defines IPv6 approaches which collectively achieve the This document defines IPv6 approaches which collectively achieve the
goals of the network manager without the negative impact on goals of the network manager without the negative impact on
applications or security that are inherent in a NAT approach. To the applications or security that are inherent in a NAT approach. To the
degree that these techniques improve a network manager's ability to degree that these techniques improve a network manager's ability to
explicitly 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
skipping to change at page 29, line 32 skipping to change at page 26, line 25
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[10] Draves, R., "Default Address Selection for Internet Protocol [10] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[12] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering [12] Baker, F., "Procedures for Renumbering an IPv6 Network without
an IPv6 Network without a Flag Day", RFC 4192, September 2005. a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in
progress), March 2005.
[13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
progress), January 2005.
11.2. Informative References 11.2. Informative References
[14] 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.
[15] 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.
skipping to change at page 31, line 13 skipping to change at page 28, line 7
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 only on the local link 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
skipping to change at page 32, line 38 skipping to change at page 29, line 29
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 usage of RFC 1918 private network infrastructure due to the legitimate usage of RFC 1918
addressing. This potential overlap in address space may complicate a private addressing. This potential overlap in address space may
merge of two and more networks dramatically due to the additional complicate a merge of two and more networks dramatically due to the
IPv4 renumbering effort. i.e. when the first network has a service additional IPv4 renumbering effort. i.e. when the first network has a
running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by service running (NTP, DNS, DHCP, HTTP, etc..) which need to be
the 2nd merging network. Similar address conflicts can happen when accessed by the 2nd merging network. Similar address conflicts can
two network devices from these merging networks want to communicate. happen when two network devices from these merging networks want to
communicate.
With the usage of IPv6 the addressing overlap will not exist because With the usage of IPv6 the addressing overlap will not exist because
of the existence of the Unique Local Address usage for private and of the existence of the Unique Local Address usage for private and
local addressing. local addressing.
A.7. Community of interest 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. The ability in NAP to virtualize the to the rest of the world. This functionality will be available
topology to mask it is applied to the cluster, creating arbitrary through the usage of NAP and native IPv6 dataflows, without any
groupings or communities. 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 B.1. Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 *-vandevelde-v6ops-nap-01
o Document introduction has been revised and overview table added o Document introduction has been revised and overview table added
o Comments and suggestions from nap-00 draft have been included. o Comments and suggestions from nap-00 draft have been included.
o Initial section of -00 draft 2.6 and 4.6 have been aggregated into o Initial section of -00 draft 2.6 and 4.6 have been aggregated into
skipping to change at page 37, line 47 skipping to change at page 35, line 5
ULA specification is in the RFC-editor queue. ULA specification is in the RFC-editor queue.
o Section 6.3: (Minimal Traceability) Better to say "topology o Section 6.3: (Minimal Traceability) Better to say "topology
masking _may be_ required" instead of "is required", because masking _may be_ required" instead of "is required", because
whether this is needed or not is a value judgment. whether this is needed or not is a value judgment.
o Section 6.4: (Renumbering Procedure) Renumbering procedure is in o Section 6.4: (Renumbering Procedure) Renumbering procedure is in
RFC queue. The section corrected in the current state? RFC queue. The section corrected in the current state?
o Section 6.4: s/well solved/completely solved/ o Section 6.4: s/well solved/completely solved/
o In general the whole chapter 6 has been revised to reflect current o In general the whole chapter 6 has been revised to reflect current
status status
B.5. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02
o
B.6. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03
o Editorial changes in response to IESG review comments and
questions.
o Introduction: clarified impact & goal for limited additional NAT
discussion here / modified tone wrt marketing / grammar cleanup
o Introduction: added paragraph about why nat != security
o Table1: s/benefit/Goal/ s/ULA/4193/ removed long numeric string /
added app end points & number of subnets
o Section 2: tone reduction about marketing
o Section 2.1: grammar cleanup / clarified point about use of public
space / added paragraph about topology restrictions
o Section 2.2: moved paragraph about firewalls to 4.2 / deleted
discussion about distributed security / clarified point about port
overload
o Section 2.3: Added opening sentence to explain the goal of the
section / deleted comment about theory
o Section 2.4: deleted confusing/redundant comments about identifier
/ added clarification that focused scanning on the port range
reaches active nodes
o Section 2.5: clarified that the impact was on the local network
o Section 2.6: added point about limitations of cascaded nat
o Section 2.7: clarification about why multihoming & renumbering are
discussed together / point about sparse allocation
o Section 3.2: grammer cleanup / updated reference from ID to RFC
added point about policy table to bias ULA over ISP block
o Section 3.3: Clarification about goal for section
o Section 3.4: reorder paragraphs to put goal up front
o Section 4.1: s/could/should/ s/prior to establishing/independent
of the state of/ clarified why concatenation would not collide /
another comment about the policy table for ULA biasing / clarified
point about lack of routing protocol
o Section 4.2: clarified point about firewall for boundary / 1.
clarified point about valid lifetime / 2. clarified point that
IPsec works the same w/o NAT / 3. clarified that the scanning
threat is addresses as ports are the same once an address is known
/ rearranged paragraph to keep scanning thread together /
clarified role of simple firewall / added comment about service
provider mediated pinhole management
o Section 4.3: added paragraph about tracking privacy address use
o Section 4.4: clarified point about tracking wrt NAT / added
comment about IGP complexity / s/conceal/isolate/ reworded ULA
description which was technically backwards / additional
description of the goal / added picture and referenced it from
descriptions / added vlan option
o Section 4.5: Grammar cleanup / clarification about policy
o Section 4.6: added discussion about policy focus on subnets
o Section 4.7: s/CIDR-like/CIDR allocated/ s/this/to multiple
addresses/ s/may/will likely/ s/if/when/ s/from SP/between sp/
o Section 5: d/of these/
o Section 5.1: deleted redundant discussion about /48 allocation /
added discussion about larger deployments using tunneling
o Section 5.2: clarification of overload on port vs. protocol /
added comment about upstream NAT / clarified 3041 use
o Section 5.4: s/IPv4/IP as role is not version specific / deleted
comment about preference to ULA.
o Section 6.1: added comment about deployment scale / added comment
about firewall blocking BU / clarified point about future work
being an optimization to reduce firewall load
o Section 6.3: replaced reference to renumbering draft w/RFC
o Section 6.4: grammar cleanup
o Section A.2: word order - moved 'only'
o Section A.6: deleted 'legitimate'
o Section A.7: clarified how NAP delivers community of interest
o Section B.5: added place holder for missing change log -01 to -02
Authors' Addresses Authors' Addresses
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2704 5473 Phone: +32 2704 5473
Email: gunter@cisco.com Email: gunter@cisco.com
skipping to change at page 41, line 41 skipping to change at page 36, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 96 change blocks. 
666 lines changed or deleted 491 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ 


Network Working Group                                    G. Van de Velde
Internet-Draft                                                   T. Hain
Expires: December 4, 2006                                       R. Droms
                                                           Cisco Systems
                                                            B. Carpenter
                                                         IBM Corporation
                                                                E. Klein
                                                     Tel Aviv University
                                                            June 2, 2006


                  IPv6 Network Architecture Protection
                     <draft-ietf-v6ops-nap-03.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many



Van de Velde, et al.    Expires December 4, 2006                [Page 1]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 does not support
   NAT by design and this document shows how Network Architecture
   Protection (NAP) using IPv6 can provide the same or more benefits
   without the need for NAT.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Perceived Benefits of NAT and its Impact on IPv4 . . . . . . .  7
     2.1.  Simple Gateway between Internet and Private Network  . . .  7
     2.2.  Simple Security due to Stateful Filter Implementation  . .  8
     2.3.  User/Application tracking  . . . . . . . . . . . . . . . .  8
     2.4.  Privacy and Topology Hiding  . . . . . . . . . . . . . . .  9
     2.5.  Independent Control of Addressing in a Private Network . . 10
     2.6.  Global Address Pool Conservation . . . . . . . . . . . . . 10
     2.7.  Multihoming and Renumbering with NAT . . . . . . . . . . . 11
   3.  Description of the IPv6 Tools  . . . . . . . . . . . . . . . . 11
     3.1.  Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12
     3.2.  Unique Local Addresses . . . . . . . . . . . . . . . . . . 12
     3.3.  DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13
     3.4.  Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13
   4.  Using IPv6 Technology to Provide the Market Perceived
       Benefits of NAT  . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Simple Gateway between Internet and Internal Network . . . 14
     4.2.  IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
     4.3.  User/Application Tracking  . . . . . . . . . . . . . . . . 17
     4.4.  Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17
     4.5.  Independent Control of Addressing in a Private Network . . 19
     4.6.  Global Address Pool Conservation . . . . . . . . . . . . . 20
     4.7.  Multihoming and Renumbering  . . . . . . . . . . . . . . . 20
   5.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.1.  Medium/large private networks  . . . . . . . . . . . . . . 21
     5.2.  Small Private Networks . . . . . . . . . . . . . . . . . . 23
     5.3.  Single User Connection . . . . . . . . . . . . . . . . . . 24
     5.4.  ISP/Carrier Customer Networks  . . . . . . . . . . . . . . 25
   6.  IPv6 Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  Subnet Topology Masking  . . . . . . . . . . . . . . . . . 26
     6.2.  Minimal Traceability of Privacy Addresses  . . . . . . . . 26
     6.3.  Renumbering Procedure  . . . . . . . . . . . . . . . . . . 27
     6.4.  Site Multihoming . . . . . . . . . . . . . . . . . . . . . 27
     6.5.  Untraceable Addresses  . . . . . . . . . . . . . . . . . . 27
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28



Van de Velde, et al.    Expires December 4, 2006                [Page 2]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     11.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Appendix A.  Additional Benefits due to Native IPv6 and
                Universal Unique Addressing . . . . . . . . . . . . . 30
     A.1.  Universal Any-to-Any Aonnectivity  . . . . . . . . . . . . 30
     A.2.  Auto-configuration . . . . . . . . . . . . . . . . . . . . 30
     A.3.  Native Multicast Services  . . . . . . . . . . . . . . . . 31
     A.4.  Increased Security Protection  . . . . . . . . . . . . . . 31
     A.5.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 32
     A.6.  Merging Networks . . . . . . . . . . . . . . . . . . . . . 32
     A.7.  Community of interest  . . . . . . . . . . . . . . . . . . 32
   Appendix B.  Revision history  . . . . . . . . . . . . . . . . . . 33
     B.1.  Changes from *-vandevelde-v6ops-nap-00 to
           *-vandevelde-v6ops-nap-01  . . . . . . . . . . . . . . . . 33
     B.2.  Changes from *-vandevelde-v6ops-nap-01 to
           *-ietf-v6ops-nap-00  . . . . . . . . . . . . . . . . . . . 33
     B.3.  Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01  . 33
     B.4.  Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02  . 33
     B.5.  Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02  . 37
     B.6.  Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03  . 38
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
   Intellectual Property and Copyright Statements . . . . . . . . . . 41




























Van de Velde, et al.    Expires December 4, 2006                [Page 3]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


1.  Introduction

   Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  The serious disadvantages and
   impact on applications by ambiguous "private" address space and
   Network Address Translation (NAT) [1] [5] have been well documented
   [4] [6] so there will not be much additional discussion here.
   However, given its wide market acceptance NAT undoubtedly has some
   perceived benefits.  Indeed, in an Internet model based on universal
   any-to-any connectivity, product marketing departments have driven a
   perception that some connectivity and security concerns can only be
   solved by using a NAT device or by using logically separated address
   spaces.  This document describes the goals for utilizing a NAT device
   in an IPv4 environment that are regularly cited as solutions for
   perceived problems.  It then shows how these needs can be met without
   using the header modification feature of NAT in an IPv6 network.  The
   use of the facilities from IPv6 described in this document avoids the
   negative impacts on applications of address translation while meeting
   or exceeding the comparable IPv4+NAT equivlent goal.

   As far as security and privacy are concerned, this document considers
   how to mitigate a number of threats.  Some are obviously external,
   such as having a hacker or a worm infected machine outside trying to
   penetrate and attack the local network.  Some are local such as a
   disgruntled employee disrupting business operations, or the
   unintentional negligence of a user downloading some malware which
   then proceeds to attack from within.  Some may be inherent in the
   device hardware ("embedded") such as having some firmware in a
   domestic appliance "call home" to its manufacturer without the user's
   consent.

   Another consideration discussed is the view that NAT can be used to
   fulfill the goals of a security policy.  At a technical level the
   translation process fundamentally can not produce security because
   mangling the address in the header does not fulfill any useful
   security functions, it only breaks the ability to track what is going
   on.  The artifacts of NAT devices do provide some value.
   1.  the need to establish state before anything gets through from
       outside to inside solves one set of problems.
   2.  the need to stop receiving any packets when finished with a flow
       solves a set of problems
   3.  the need to appear to be at the edge of the network solves a set
       of problems
   4.  and the ability to have addresses that are not publicly routed
       solves yet another set (mostly changes where the state is and
       scale requirements for the first one).




Van de Velde, et al.    Expires December 4, 2006                [Page 4]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   This document describes several techniques that may be combined in an
   IPv6 deployment to protect the integrity of its network architecture.
   It will focus on the 'how to acomplish a goal' perspective, leaving
   most of the 'why that goal' perspective for other documents.  These
   techniques, known collectively as Network Architecture Protection
   (NAP), retain the concept of a well defined boundary between "inside"
   and "outside" the private network, and allow firewalling, topology
   hiding, and privacy.  NAP will achieve these security goals without
   address translation whilst regaining the ability for arbitrary any-
   to-any connectivity.

   IPv6 Network Architecture Protection can be summarized in the
   following table.  It presents the marketed "benefits" of IPv4+NAT
   with a cross-reference of how those are delivered in both the IPv4
   and IPv6 environments.




































Van de Velde, et al.    Expires December 4, 2006                [Page 5]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


          Goal                  IPv4                     IPv6
   +------------------+-----------------------+-----------------------+
   | Simple Gateway   |  DHCP - single        |  DHCP-PD - arbitrary  |
   | as default router|  address upstream     |  length customer      |
   | and address pool |  DHCP - limited       |  prefix upstream      |
   | manager          |  number of individual |  SLAAC via RA         |
   |                  |  devices downstream   |  downstream           |
   |                  |  see section 2.1      |  see section 4.1      |
   +------------------|-----------------------|-----------------------+
   |  Simple Security |  Filtering side       |  Explicit Context     |
   |                  |  effect due to lack   |  Based Access Control |
   |                  |  of translation state |  (Reflexive ACL)      |
   |                  |  see section 2.2      |  see section 4.2      |
   +------------------|-----------------------|-----------------------+
   |  Local usage     |  NAT state table      |  Address uniqueness   |
   |  tracking        |                       |                       |
   |                  |  see section 2.3      |  see section 4.3      |
   +------------------|-----------------------|-----------------------+
   |  End-system      |  NAT transforms       |  Temporary use        |
   |  privacy         |  device ID bits in    |  privacy addresses    |
   |                  |  the address          |                       |
   |                  |  see section 2.4      |  see section 4.4      |
   +------------------|-----------------------|-----------------------+
   |  Topology hiding |  NAT transforms       |  Untraceable addresses|
   |                  |  subnet bits in the   |  using IGP host routes|
   |                  |  address              |  /or MIPv6 tunnels for|
   |                  |                       |  stationary systems   |
   |                  |  see section 2.4      |  see section 4.4      |
   +------------------|-----------------------|-----------------------+
   |  Addressing      |  RFC 1918             |  RFC 3177 & 4193      |
   |  Autonomy        |                       |                       |
   |                  |  see section 2.5      |  see section 4.5      |
   +------------------|-----------------------|-----------------------+
   |  Global Address  |  RFC 1918             |  18*10^18 subnets     |
   |  Pool            |  << 2^48 application  |  3.4*10^38 addresses  |
   |  Conservation    |  end points           |  unrestricted         |
   |                  |  topology restricted  |                       |
   |                  |  see section 2.6      |  see section 4.6      |
   +------------------|-----------------------|-----------------------+
   |  Renumbering and |  Address translation  |  Preferred lifetime   |
   |  Multi-homing    |  at border            |  per prefix & Multiple|
   |                  |                       |  addresses per        |
   |                  |                       |  interface            |
   |                  |  see section 2.7      |  see section 4.7      |
   +------------------+-----------------------+-----------------------+






Van de Velde, et al.    Expires December 4, 2006                [Page 6]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   This document first identifies the perceived benefits of NAT in more
   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
   remains to be done for a complete NAP solution.


2.  Perceived Benefits of NAT and its Impact on IPv4

   This section provides insight into the generally perceived benefits
   of the use of IPv4 NAT which are frequently reinforced by product
   marketing.  The goal of this description is not to analyze these
   benefits or the accuracy of the perception (detailed discussions in
   [4]), but to describe the deployment requirements and set a context
   for the later descriptions of the IPv6 approaches for dealing with
   those requirements.

2.1.  Simple Gateway between Internet and Private Network

   A NAT device can connect a private network with addresses allocated
   from any part of the space (ambiguous [RFC 1918] or global registered
   address) towards the Internet, though extra effort is needed when the
   same range exists on both sides of the NAT.  The address space of the
   private network can be built from globally unique addresses, from
   ambiguous address space or from both simultaneously.  In the simple
   case of private use addresses, without needing specific configuration
   the NAT device enables access between the client side of a
   distributed client-server application in the private network and the
   server side located in the public Internet.

   Wide-scale deployments have shown that using NAT to attach a private
   IPv4 network to the Internet is simple and practical for the non-
   technical end user.  Frequently a simple user interface, or even a
   default configuration is sufficient for configuring both device and
   application access rights.

   This simplicity comes at a price as the resulting topology puts
   restrictions on applications.  The NAT simplicity works well when the
   applications are limited to a client/server model with the server
   deployed on the public side of the NAT.  For peer-to-peer, multi-
   party, or servers deployed on the private side of the NAT, helper
   technologies must be available.  These helper technologies are
   frequently complex to develop and manage, creating a hidden cost to
   this 'simple gateway'.

   Additionally, thanks to successful marketing campaigns it is
   perceived by end users that by installing a NAT as the gateway, their
   equipment is protected from the malicious entities and attackers on
   the public IPv4 Internet.



Van de Velde, et al.    Expires December 4, 2006                [Page 7]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


2.2.  Simple Security due to Stateful Filter Implementation

   It is frequently believed that through its session-oriented
   operation, NAT puts in an extra barrier to keep the private network
   protected from outside influences.  Since a NAT device typically
   keeps state only for individual sessions, attackers, worms, etc.
   cannot exploit this state to attack a specific host on any other
   port, though in the port overload case of NAPT attacking all active
   ports will impact a potentially wide number of hosts.  This benefit
   may be partially real, however, experienced hackers are well aware of
   NAT devices and are very familiar with private address space, and
   have devised methods of attack (such as trojan horses) that readily
   penetrate NAT boundaries.  For these reasons the sense of security
   provided by NAT is actually an illusion.

   The act of address translation does not provide security in itself;
   for example, consider a configuration with static NAT translation and
   all inbound ports translating to a single machine.  In such a
   scenario the security risk for that machine is identical to the case
   with no NAT device in the communication path.  As result there is no
   specific security value in the address translation function.  The
   perceived security in this case comes from the lack of pre-
   established or permanent mapping state.  Dynamically establishing
   state in response to internal requests reduces the threat of
   unexpected external connections to internal devices.  This role,
   marketed as a firewall, is really an arbitrary artifact while a real
   firewall has explicit management controls.

   In some cases, NAT operators (including domestic users) may be
   obliged to configure quite complex port mapping rules to allow
   external access to local applications such as a multi-player game or
   web servers.  In this case the NAT actually adds management
   complexity compared to a simple router.  In situations where two or
   more devices need to host the same application or otherwise use the
   same public port this complexity shifts from difficult to impossible.

2.3.  User/Application tracking

   One usage of NAT is for the local network administrator to track user
   and application traffic.  Although NATs create temporary state for
   active sessions, in general they provide limited capabilities for the
   administrator of the NAT to gather information about who in the
   private network is requesting access to which Internet location.
   This is done by periodically logging the network address translation
   details of the private and the public addresses from the NAT device's
   state database.

   The subsequent checking of this database is not always a simple task,



Van de Velde, et al.    Expires December 4, 2006                [Page 8]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   especially if Port Address Translation is used.  It also has an
   unstated assumption that the administrative instance has a mapping
   between a private IPv4-address and a network element or user at all
   times, or the administrator has a time-correlated list of the
   address/port mappings.

2.4.  Privacy and Topology Hiding

   The goal of 'topology hiding' is to prevent external entities from
   making a correlation between the topological location of devices 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
   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
   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
   Internet cafe, or which employee of a company generated or received a
   particular packet.  Thus, although NATs do nothing to provide
   application level privacy, they do prevent the external tracking and
   profiling of individual host computers by means of their IP
   addresses, usually known as 'device profiling'.  At the same time a
   NAT creates a smaller pool of addresses for a much more focused point
   of attack, where the adversary does not need to scan the entire
   network.  By periodically scanning the limited 16 bit port range on
   the public side of the NAT, the attack will eventually find ports
   that are open to active nodes.

   There is a similarity with privacy based on application level
   proxies.  When using an application level gateway for browsing the
   web for example, the 'privacy' of a web user can be provided by
   masking the true identity of the original web user towards the
   outside world (although the details of what is - or is not - logged
   at the NAT/proxy will be different).

   Some enterprises prefer to hide as much as possible of their internal
   network topology from outsiders.  Mostly this is achieved by blocking
   "traceroute" etc., but NAT of course entirely hides the internal
   subnet topology, which some network managers believe is a useful
   precaution to mitigate scanning attacks.  Scanning for IPv6 can be
   much harder in comparison with IPv4 as described in [18].

   Once a list of available devices and IP addresses has been mapped, a



Van de Velde, et al.    Expires December 4, 2006                [Page 9]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   port-scan on these IP addresses can be performed.  Scanning works by
   tracking which ports do not receive unreachable errors from either
   the firewall or host.  With the list of open ports an attacker can
   optimize the time needed for a successful attack by correlating it
   with known vulnerabilities to reduce the number of attempts.  For
   example, FTP usually runs on port 21, and HTTP usually runs on port
   80.  Any vulnerable open ports could be used for initiating attacks
   on an end system.

2.5.  Independent Control of Addressing in a Private Network

   Many private IPv4 networks take benefit from using the address space
   defined in RFC 1918 to enlarge the available addressing space for
   their private network, and at the same time reduce their need for
   globally routable addresses.  This type of local control of address
   resources allows a clean and hierarchical addressing structure in the
   local network.

   Another benefit is due to the usage of independent addresses on
   majority of the network infrastructure there is an increased ability
   to change provider with less operational difficulties.

   Section 2.7 describes some disadvantages that appear if independent
   networks using [RFC1918] addresses have to be merged.

2.6.  Global Address Pool Conservation

   While the widespread use of IPv4+NAT has reduced the potential
   consumption rate, due to the ongoing depletion of the IPv4 address
   range the remaining pool of unallocated IPv4 addresses is already
   below 25%.  While mathematical models based on historical IPv4 prefix
   consumption periodically attempt to predict the future exhaustion
   date of the IPv4 address pool, a direct result of this continuous
   resource consumption is that the administrative overhead for
   acquiring globally unique IPv4 addresses will continue increasing in
   direct response to tightening allocation policies.

   In response to the increasing administrative overhead many Internet
   Service Providers (ISPs) have already resorted to the ambiguous
   addresses defined in RFC 1918 behind a NAT for the various services
   they provide as well as connections for their end customers.  This
   happens even though the private use address-space is strictly limited
   in size.  Some deployments have already outgrown that space and have
   begun cascading NAT to continue expanding.  Unfortunately, the number
   of and types of applications that can be deployed by these ISPs and
   their customers is restricted by the ability to overload the port
   range on the public side of the most public NAT in the path.  The
   result is something substantially less than 2^48 possible active



Van de Velde, et al.    Expires December 4, 2006               [Page 10]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   application endpoints, rather than the perception of arbitrary
   utility one might expect from the large number of addressable
   devices.  In addition it is highly likely that nodes will become
   confused because they are not topology aware, though as already
   mentioned NAT enforces specific topologies on the application
   deployment model.  Forced into this limiting situation such customers
   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

   Allowing a network to be multihomed and renumbering a network are
   quite different functions.  However these are argued together as
   reasons for using NAT, because making a network multihomed is often a
   transitional state required as part of network renumbering, and NAT
   interacts with both in the same way.

   For enterprise networks, it is highly desirable to provide resiliency
   and load-balancing to be connected to more than one Internet Service
   Provider (ISP) and to be able to change ISPs at will.  This means
   that a site must be able to operate under more than one CIDR prefix
   [14] and/or readily change its CIDR prefix.  Unfortunately, IPv4 was
   not designed to facilitate either of these maneuvers.  However, if a
   site is connected to its ISPs via NAT boxes, only those boxes need to
   deal with multihoming and renumbering issues.

   Similarly, if two enterprise IPv4 networks need to be merged and
   RFC1918 addresses are used, there is a high probability of address
   overlaps.  In those situations it may well be that installing a NAT
   box between them will avoid the need to renumber one or both.  For
   any enterprise, this can be a short term financial saving, and allow
   more time to renumber the network components.  The long term solution
   is a single network without usage of NAT to avoid the ongoing
   operational complexity of overlapping addresses.

   The addition of an extra NAT as a solution may be sufficient for some
   networks; however when the merging networks were already using
   address translation it will create huge problems due to
   administrative difficulties of overlapping address speaces in the
   merged networks.


3.  Description of the IPv6 Tools

   This section describes several features that can be used as part of
   the NAP solution to emulate the protection features associated with
   IPv4 NAT.



Van de Velde, et al.    Expires December 4, 2006               [Page 11]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


3.1.  Privacy Addresses (RFC 3041)

   There are situations where it is desirable to prevent device
   profiling, for example by web sites that are accessed from the
   device; IPv6 privacy addresses were defined to provide that
   capability.  IPv6 addresses consist of a routing prefix, subnet-id
   part (SID) and an interface identifier part (IID).  For interfaces
   that contain embedded IEEE Link Identifiers the interface identifier
   is typically derived from it, though this practice facilitates
   tracking and profiling of a device as it moves around the Internet.
   RFC 3041 describes an extension to IPv6 stateless address
   autoconfiguration (SLAAC) for interfaces [7].  Use of the privacy
   address extension causes nodes to generate global-scope addresses
   from interface identifiers that change over time, even in cases where
   the interface contains an embedded IEEE link identifier.  Changing
   the interface identifier (thus the global-scope addresses generated
   from it) over time makes it more difficult for eavesdroppers and
   other information collectors to identify when addresses used in
   different transactions actually correspond to the same node.  A
   relatively short valid lifetime for the privacy address also has the
   side effect of reducing the attack profile of a device, as it is not
   directly attackable once it stops answering at the temporary use
   address.

   While the primary implementation and source of randomized RFC 3041
   addresses is expected to be from end-systems running stateless
   autoconfiguration, there is nothing that prevents a DHCP server from
   running the RFC 3041 algorithm for any new IEEE identifier it hears
   in a request, then remembering that for future queries.  This would
   allow using them in DNS for registered services since the assumption
   of a DHCP server based deployment would be a persistent value that
   minimizes DNS churn.  A DHCP based deployment would also allow for
   local policy to periodically change the entire collection of end
   device addresses while maintaining some degree of central knowledge
   and control over which addresses should be in use at any point in
   time.

   Randomizing the IID, as defined in RFC 3041, is effectively a sparse
   allocation technique which only precludes tracking of the lower 64
   bits of the IPv6 address.  Masking of the subnet ID will require
   additional approaches as discussed below in 3.4.  Additional
   considerations are discussed in [17].

3.2.  Unique Local Addresses

   Acheiving the goal of autonomy is required for local network and
   application services stability during periods of intermittent
   connectivity between one or more providers.  Such autonomy in a



Van de Velde, et al.    Expires December 4, 2006               [Page 12]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   single routing prefix environment would lead to massive expansion of
   the global routing tables (as seen in IPv4), so IPv6 provides for
   simultaneous use of multiple prefixes.  The Unique Local Address
   prefix (ULA) [13] has been set aside for use in local communications.
   The ULA address prefix for any network is routable over a locally
   defined collection of routers.  These prefixes are not intended to be
   routed on the public global Internet as large scale inter-domain
   distribution of routes for ULA prefixes would have a negative impact
   on global route aggregation.

   ULAs have the following characteristics:
   o  Globally unique prefix
      *  Allows networks to be combined or privately interconnected
         without creating address conflicts or requiring renumbering of
         interfaces using these prefixes
      *  If accidentally leaked outside of a network via routing or DNS,
         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
      network without having any permanent or or only intermittent
      Internet connectivity
   o  Well-known prefix to allow for easy filtering at network
      boundaries preventing leakage of local routes and packets.
   o  In practice, applications may treat these addresses like global
      scoped addresses but address selection algorithms may need to
      distinguish between ULAs and ordinary global scope unicast
      addresses to assure stability.  The policy table defined in [10]
      is one way to bias this selection, by giving higher preference to
      FC00::/7 over 2001::/3.  Mixing the two kinds of addresses may
      lead to undeliverable packets during times of instability, but
      that mixing is not likely to happen when the rules of RFC 3484 are
      followed.

3.3.  DHCPv6 Prefix Delegation

   One of the functions of a simple gateway is managing the local use
   address range.  The Prefix Delegation (DHCP-PD) options [11] provide
   a mechanism for automated delegation of IPv6 prefixes using the
   Dynamic Host Configuration Protocol (DHCP) [9].  This mechanism
   (DHCP-PD) is intended for delegating a long-lived prefix from a
   delegating router (possibly incorporating a DHCPv6 server) to a
   requesting router, possibly across an administrative boundary, where
   the delegating router does not require knowledge about the topology
   of the links in the network to which the prefixes will be assigned.

3.4.  Untraceable IPv6 Addresses

   The main goal of untraceable IPv6 addresses is to create an



Van de Velde, et al.    Expires December 4, 2006               [Page 13]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   apparently amorphous network infrastructure as seen from external
   networks to protect the local infrastructure from malicious outside
   influences and from mapping of any correlation between the network
   activities of multiple devices from external networks.  When using
   untraceable IPv6 addresses, it could be that two apparently
   sequential addresses are allocated to devices on very different parts
   of the local network instead of belonging to devices adjacent to each
   other on the same subnet.

   These should be globally routable IPv6 addresses which can be
   randomly and independently assigned to IPv6 devices.

   The random assignment is intended to mislead the outside world about
   the structure of the local network.  However the local network needs
   to maintain a correlation between the location of the device and the
   untraceable IPv6 address.  For smaller deployments this correlation
   could be done by generating IPv6 host route entries, or for larger
   ones by utilizing an indirection device such as a Mobile IPv6 Home
   Agent.  Additional details are in section 4.7.


4.  Using IPv6 Technology to Provide the Market Perceived Benefits of
    NAT

   The facilities in IPv6 described in Section 3 can be used to provide
   the protection perceived to be associated with IPv4 NAT.  This
   section gives some examples of how IPv6 can be used securely.

4.1.  Simple Gateway between Internet and Internal Network

   As a simple gateway, the device manages both packet routing and local
   address management.  A basic IPv6 router should have a default
   configuration to advertise inside the site a locally generated random
   ULA prefix, independently from the state of any external
   connectivity.  This would allow local nodes to communicate amongst
   themselves independent of the state of a global connection.  If the
   network happened to concatenate with another local network, the
   randomness in ULA creation is highly unlikely to result in address
   collisions.

   With external connectivity the simple gateway should 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 derived from this prefix delegation.  It should be noted
   that the address selection policy table in end-systems defined in RFC
   3484 should be configured to prefer the ULA prefix range over the
   DHCP-PD prefix range when the goal is to keep local communications



Van de Velde, et al.    Expires December 4, 2006               [Page 14]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   stable during periods of transient external connectivity.

   In the very simple case there is no explicit routing protocol on
   either side of the gateway, and a single default route is used
   internally pointing out to the global Internet.  A slightly more
   complex case might involve local internal 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 the service
   provider could install a route for the delegated prefix pointing
   toward the connecting link.

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 for those that want
   boundary protection in addition to host defences.  A proxy may be
   used for certain applications, but with the caveat that the end to
   end transparency 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
       profile since the node will not respond to the address once its
       lifetime becomes invalid.
   2.  IPsec is a mandatory service for IPv6 implementations.  IPsec
       functions to prevent session hijacking, prevent content
       tampering, and optionally masks the packet contents.  While IPsec
       works the same way and might be available in IPv4
       implementations, deployment in NAT environments either breaks the
       protocol or requires complex helper services with limited
       functionality or efficiency.
   3.  The size of the address space of a typical subnet (64 bits of
       IID) will make a complete subnet ping sweep virtually impossible
       due to the number of possible combinations available.  Reducing
       the security threat of port scans on identified nodes requires
       sparse distribution within the subnet to minimize the list of
       known nodes.  Provided that IIDs are essentially randomly
       distributed across the available space, address scanning based
       attacks will fail.  This protection exists if the attacker has no
       direct access to the specific subnet.  If an attacker has local
       access then he could use ND [3] and ping6 to the link-scope
       multicast ff02::1 to detect local neighbors.  (Of course, a
       locally connected attacker has many scanning options with IPv4 as
       well.)  This scanning protection will also be nullified if IIDs
       are configured in a group near the start of the IID space.

   Assuming the network administrator is aware of [18]the increased size
   of the IPv6 address will make topology probing much harder, and



Van de Velde, et al.    Expires December 4, 2006               [Page 15]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   almost impossible for IPv6 devices.  The intention of topology
   probing is to identify a selection of the available hosts inside an
   enterprise.  This mostly starts with a ping-sweep.  Since the IPv6
   subnets are 64 bits worth of address space, this means that an
   attacker has to send out a simply unrealistic number of pings to map
   the network, and virus/worm propagation will 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.

   IPv4 NAT was not developed as a security mechanism.  Despite
   marketing messages to the contrary it is not a security mechanism,
   and hence it will offer some security holes while many people assume
   their network is secure due to the usage of NAT.  IPv6 security best
   practices will avoid this kind of illusory security but can only
   address the same threats if correctly configured firewalls and IDS
   systems are used at the perimeter where some IPv4 networks have
   relied on NATs.

   It must be noted that even a firewall doesn't fully secure a network.
   Many attacks come from inside or are at a layer higher than the
   firewall can protect 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 robust in the face of challenges like stack
   overflows etc.  What a firewall does is prevent a network
   administration from having to pay for bandwidth to carry unauthorized
   traffic, and in so doing reduce the probability of certain kinds of
   attacks across the protected boundary.

   To implement simple security for IPv6 in, for example, a DSL
   connected home network, the DSL broadband gateway/router should be
   equipped with stateful firewall capabilities.  These should provide a
   default configuration where incoming traffic is limited to return
   traffic resulting from outgoing packets (sometimes known as
   reflective session state).  There should also be an easy interface
   which allows users to create inbound 'pinholes' for specific purposes
   such as online-gaming.  Another consideration would be the capability
   for service provider mediated pinhole management where things like
   voice call signalling could dynamically establish pinholes based on
   predefined rules.

   Administrators and the designers of configuration interfaces for
   simple IPv6 Firewalls need to provide a means of documenting the
   security caveats that arise from a given set configuration rules so
   that users (who are normally oblivious to such things) can be made
   aware of the risks.  As rules are improved iteratively, the goal will
   be to make use of the IPv6 Internet more secure for oblivious users.




Van de Velde, et al.    Expires December 4, 2006               [Page 16]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


4.3.  User/Application Tracking

   IPv6 enables the collection of information about data flows.  Due to
   the fact that all addresses used for Internet and intra-/inter-site
   communication are unique, it is possible for an enterprise or ISP to
   get very detailed information on any communication exchange between
   two or more devices.  This enhances the capability of data-flow
   tracking for security audits compared with IPv4 NAT, because in IPv6
   a flow between a sender and receiver will always be uniquely
   identified due to the unique IPv6 source and destination addresses.

   At the same time, this tracking is per address.  In environments
   where the goal is tracking back to the user, additional external
   information will be necessary coorelating a user with an address.  In
   the case of short lifetime privacy address usage, this external
   information will need to be based on more stable information such as
   the layer 2 media address.

4.4.  Privacy and Topology Hiding using IPv6

   Partial host privacy is achieved in IPv6 using pseudo-random privacy
   addresses [RFC 3041] which are generated as required, so that a
   session can use an address that is valid only for a limited time.
   This only allows such a session to be traced back to the subnet that
   originates it, but not immediately to the actual host, where IPv4 NAT
   is only tracable to the most public NAT interface.

   Due to the large IPv6 address space available there is plenty of
   freedom to randomize subnet allocations.  By doing this, it is
   possible to reduce the correlation between a subnet and its location.
   When doing both subnet and IID randomization [RFC 3041] a casual
   snooper won't be able to deduce much about the networks topology.
   The obtaining of a single address will tell the snooper very little
   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, with the cost being a more complex internal routing
   configuration.

   In the case where a network administrator wishes to fully isolate 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 by definition external traffic
   will never reach the site.  For the set of hosts that do in fact need
   to interact externally, 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



Van de Velde, et al.    Expires December 4, 2006               [Page 17]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   techniques to manage privacy for each which may be combined to
   protect the entire address.

   There are other possible scenarios for the extreme situation when a
   network manager also wishes to fully conceal the internal IPv6
   topology.  In these cases the goal in replacing the IPv4 NAT approach
   is to make all of the topology hidden nodes appear from the outside
   to exist at the edge of the network, just as they would when behind a
   NAT.

   o  One could use explicit host routes and remove the correlation
      between location and IPv6 address.  In the figure below the hosts
      would be allocated prefixes from one or more logical subnets, and
      would inject host routes to internally identify their real
      attachment point.  This solution does however show severe
      scalability issues and should be limited to uses with
      substantially fewer than the maximum number of routes that the IGP
      can support (generally about 50,000).
   o  Another 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 the edge Home Agent (HA).  This indirection method
      truly masks the internal topology as all nodes with global access
      appear to share the prefix of one or more logical subnets attached
      to the HA.  While turning off all binding updates would appear to
      be necessary to prevent leakage of topology information, that
      approach would also force all internal traffic to route via the HA
      tunnel.  A better method would be to allow internal route
      optimizations while dropping outbound binding updates at the
      firewall.  The downsides of using this tunneling method is that it
      makes usage of middleware like a Home Agent (HA) and consumes
      slightly more bandwidth for the tunnel overhead.
   o  Another method where the layer 2 topology allows would be to use a
      virtual lan approach to logically attach the devices to one or
      more subnets on the edge router.  The downsides of this approach
      is that all internal traffic would be directed over sub-optimal
      paths via the edge router, as well as the complexity of managing a
      distributed logical lan.













Van de Velde, et al.    Expires December 4, 2006               [Page 18]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


                             Internet
                                 |
                                 \
                                 |
                       +------------------+
                       | Simple Gateway   |  Logical subnet
                       | or Home Agent    |-+-+-+-+-+-+-+-+--
                       +------------------+  for topology
                                 |           hidden nodes
                                 |
               Real internal  -------------+-
               topology       |            |
                              |           -+----------
                   -----------+--------+
                                       |







4.5.  Independent Control of Addressing in a Private Network

   IPv6 provides for autonomy in local use addresses through ULAs.  At
   the same time IPv6 simplifies simultaneous use of multiple addresses
   per interface so that an IPv6 NAT is not required between the ULA and
   the public Internet because nodes that need access to the public
   Internet will have a global use address as well.  When using IPv6,
   the need to ask for more address space will become far less likely
   due to the increased size of the subnets, along with an allocation
   policy that recognizes table fragmentation is also an important
   consideration.  While global IPv6 allocation policy is managed
   through the Regional Internet Registries, it is expected that they
   will continue with derivatives of [8] for the foreseeable future so
   the number of subnet prefixes available to an organization should not
   be a limitation which would create an artifical demand for NAT.

   The ongoing subnet size maintenance may become simpler when IPv6
   technology is utilised.  Under IPv4 address space policy
   restrictions, each subnet must be optimised so one has to look
   periodically into the number of hosts on a segment and the subnet
   size allocated to the segment and rebalance.  For example an
   enterprise today may have a mix of /28 - /23 size subnets, and may
   shrink/grow these as their network user base changes.  For IPv6 all
   subnets have /64 prefixes which will reduce the operational and
   configuration overhead.




Van de Velde, et al.    Expires December 4, 2006               [Page 19]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


4.6.   Global Address Pool Conservation

   IPv6 provides sufficient space to completely avoid the need for
   overlapping address space with the total possible addresses being
   340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38).
   Since allocations in IPv6 are based on subnets rather than hosts a
   more reasonable way to look at the pool is that there are about
   17,293,822,569,102,704,640 (17*10^18) unique subnet values where
   sparse allocation practice within those provdes for new opportunities
   such as .  As previously discussed, the serious disadvantages of
   ambiguous address space have been well documented, and with
   sufficient space there is no need to continue the increasingly
   aggressive conservation practices that are necessary with IPv4.
   While IPv6 allocation policies and ISP business practice will
   continue to evolve, the recommendations in RFC 3177 are based on the
   technical potential of the vast IPv6 address space.  That document
   demonstrates that there is no resource limitation which will require
   the adoption of the IPv4 workaround of ambiguous space behind a NAT.
   As an example of the direct contrast, many expansion oriented IPv6
   deployment scenarios result in multiple IPv6 addresses per device, as
   opposed to the constriction of IPv4 scenarios where multiple devices
   are forced to share a scarce global address through a NAT.

4.7.  Multihoming and Renumbering

   Multihoming and renumbering remain technically challenging with IPv6
   (see the Gap Analysis below).  However, IPv6 was designed to allow
   sites and hosts to run with several simultaneous CIDR allocated
   prefixes, and thus with several simultaneous ISPs.  An address
   selection mechanism [10] is specified so that hosts will behave
   consistently when several addresses are simultaneously valid.  The
   fundamental difficulty that IPv4 has in regard to multiple addresses
   therefore does not apply to 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 been documented in [12] and [19].

   The IPv6 address space allocated by the ISP will be dependent upon
   the connecting Service provider.  This will likely result in a
   renumbering effort when the network changes between service
   providers.  When changing ISPs or ISPs readjusting their addressing
   pool, DHCP-PD [11] can be used as an almost zero-touch external
   mechanism for prefix change in conjunction with a ULA prefix for
   internal connection stability.  With appropriate management of the
   lifetime values and overlap of the external prefixes, a smooth make-
   before-break transition is possible as existing communications will
   continue on the old prefix as long as it remains valid, while any new
   communications will use the new prefix.




Van de Velde, et al.    Expires December 4, 2006               [Page 20]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


5.  Case Studies

   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.  For each category of networks we can use
   IPv6 Network Architecture Protection to achieve a secure and 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  Small Private Networks (typically 1 to 10 connections)
   o  Single User Connection (typically 1 connection)
   o  ISP/Carrier Customer Networks


5.1.  Medium/large private networks

   The majority of private enterprise networks fall into this category.
   Many of these networks have one or more exit points to the Internet.
   Though these organizations have sufficient resources to acquire
   addressing independence when using IPv4 there are several reasons why
   they might choose to use NAT in such a network.  For the ISP there is
   no need to import the IPv4 address range from the remote end-
   customer, which facilitates IPv4 route summarization.  The customer
   can use a larger IPv4 address range (probably with less-
   administrative overhead) by the use of RFC 1918 and NAT.  The
   customer also reduces the overhead in changing to a new ISP, because
   the addresses assigned to devices behind the NAT do not need to be
   changed when the customer is assigned a different address by a new
   ISP.  By using address translation in IPv4 one avoids the expensive
   process of network renumbering.  Finally, the customer can provide
   privacy for its hosts and the topology of its internal network if the
   internal addresses are mapped through NAT.

   It is expected that there will be enough IPv6 addresses available for
   all networks and appliances for the foreseeable future.  The basic
   IPv6 address range an ISP allocates for a private network is large
   enough (currently /48) for most of the medium and large enterprises,
   while for the very large private enterprise networks address-ranges
   can be concatenated.  The goal of this assignment mechanism is to
   decrease the total amount of entries in the public Internet routing
   table.  A single /48 allocation provides an enterprise network with
   65536 different /64 subnet prefixes.

   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



Van de Velde, et al.    Expires December 4, 2006               [Page 21]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   when an external element wants to track and collect all information
   sent and received by a certain host with known IPv6 address.  Privacy
   extensions add a random time-limited factor to the host part of an
   IPv6 address and will make it very hard for an external element to
   keep correlating the IPv6 address to a specific host on the inside
   network.  The usage of IPv6 privacy extensions does not mask the
   internal network structure of an enterprise network.

   If there is need to mask the internal structure towards the external
   IPv6 Internet, then some form of 'untraceable' addresses may be used.
   These addresses will be derived from a local pool, and may be
   assigned to those hosts for which topology masking is required or
   which want to reach the IPv6 Internet or other external networks.
   The technology to assign these addresses to the hosts could be based
   on DHCPv6 or static configuration.  To complement the 'Untraceable'
   addresses it is needed to have at least awareness of the IPv6 address
   location when routing an IPv6 packet through the internal network.
   This could be achieved by 'route-injection' in the local network
   infrastructure.  This route-injection could be done based on /128
   host-routes to each device that wants to connect to the Internet
   using an untraceable address.  This will provide the most dynamic
   masking, but will have a scalability limitation, as an IGP is
   typically not designed to carry many thousands of IPv6 prefixes.  A
   large enterprise may have thousands of hosts willing to connect to
   the Internet.

   An alternative for larger deployments is to leverage the tunneling
   aspect of MIPv6 even for non-mobile devices.  With the logical subnet
   being allocated as attached to the edge Home Agent, the real
   attachment and internal topology are masked from the outside.
   Dropping outbound binding updates at the firewall is also necessary
   to avoid leaking the attachment information.

   Less flexible masking could be to have time-based IPv6 prefixes per
   link or subnet.  This may reduce the amount of route entries in the
   IGP by a significant factor, but has as trade-off that masking is
   time and subnet based.The dynamic allocation of 'Untraceable'
   addresses can also limit the IPv6 access between local and external
   hosts to those local hosts being authorized for this capability.
   Dynamically allocated 'Untraceable' addresses may also facilitate and
   simplify the connectivity to the outside networks during renumbering,
   because the existing IPv6 central address pool could be swapped for
   the newly allocated IPv6 address pool.

   The use of permanent ULA addresses on a site provides the benefit
   that even if an enterprise would change its ISP, the renumbering will
   only affect those devices that have a wish to connect beyond the
   site.  Internal servers and services would not change their allocated



Van de Velde, et al.    Expires December 4, 2006               [Page 22]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   IPv6 ULA address, and the service would remain available even during
   global address renumbering.

5.2.  Small Private Networks

   Also known as SOHO (Small Office/Home Office) networks, this category
   describes those networks which have few routers in the topology, and
   usually have a single network egress point.  Typically these networks
   are:

   o  connected via either a dial-up connection or broadband access
   o  don't have dedicated Network Operation Center (NOC)
   o  and through economic pressure are typically forced today to use
      NAT

   In most cases the received global IPv4 prefix is not fixed over time
   and is too long (very often just a /32 just giving a single address)
   to provide every node in the private network with a unique globally
   usable address.  Fixing either of those issues typically adds an
   administrative overhead for address management to the user.  This
   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
   this category has deployed NAPT (port demultiplexing NAT) to minimize
   the number of addresses in use.  Unfortunately this also limits the
   Internet capability of the equipment to being mainly a receiver of
   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
   the stateful operation of the NAT equipment.  Even when there is
   sufficient technical knowledge to manage the NAT to enable external
   access to a server, only one server can be mapped per protocol/port
   number per address, and then only when the address from the ISP is
   public.  When there is an upstream NAT providing private address
   space to the ISP side of the private NAT, additional negotiation with
   the ISP will be necessary to provide an inbound mapping, if that is
   even possible.

   When deploying IPv6 NAP in this environment, there are two approaches
   possible with respect to IPv6 addressing.
   o  DHCPv6 Prefix-Delegation
   o  ISP provides a static IPv6 address-range

   For the DHCPv6-PD solution, a dynamic address allocation approach is
   chosen.  By means of the enhanced DHCPv6 protocol it is possible to



Van de Velde, et al.    Expires December 4, 2006               [Page 23]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   have the ISP push down an IPv6 prefix range automatically towards the
   small private network and populate all interfaces in that small
   private network dynamically.  This reduces the burden for
   administrative overhead because everything happens automatically.

   For the static configuration the mechanisms used could be the same as
   for the medium/large enterprises.  Typically the need for masking the
   topology will not be of high priority for these users, and the usage
   of IPv6 privacy extensions could be sufficient.

   For both alternatives the ISP has the unrestricted capability for
   summarization of its RIR allocated IPv6 prefix, while the small
   private network administrator has all flexibility in using the
   received IPv6 prefix to its advantage because it will be of
   sufficient size to allow all the local nodes to have a public address
   and full range of ports available whenever necessary.

   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
   use on a single piece of equipment (PC, PDA, etc.).  This is expected
   to be rare though, because in the IPv6 world the assumption is that
   there is an unrestricted availability of a large amount of globally
   routable and unique address space.  If scarcity was the motivation
   with IPv4 to provide RFC 1918 addresses, in this environment the ISP
   will not be motivated to allocate private addresses towards the
   single user connection because there are enough global addresses
   available at essentially the same cost.  Also it will be likely that
   the single device wants to mask its identity to the called party or
   its attack profile over a shorter time window than the life of the
   ISP attachment, so it will need to enable IPv6 privacy extensions
   which in turn leads to the need for a minimum allocation of a /64
   prefix rather than a single address.

5.3.  Single User Connection

   This group identifies the users which are connected via a single IPv4
   address and use a single piece of equipment (PC, PDA, etc.).  This
   user may get an ambiguous IPv4 address (frequently imposed by the
   ISP) from the service provider which is based on RFC 1918.  If
   ambiguous addressing is utilized, the service provider will execute
   NAT on the allocated IPv4 address for global Internet connectivity.
   This also limits the internet capability of the equipment to being
   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,
   etc.) due to the stateful operation of the NAT equipment.

   When using IPv6 NAP, this group will identify the users which are
   connected via a single IPv6 address and use a single piece of



Van de Velde, et al.    Expires December 4, 2006               [Page 24]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   equipment (PC, PDA, etc.).

   In IPv6 world the assumption is that there is unrestricted
   availability of a large amount of globally routable and unique IPv6
   addresses.  The ISP will not be motivated to allocate private
   addresses towards the single user connection because he has enough
   global addresses available, if scarcity was the motivation with IPv4
   to provide RFC 1918 addresses.  If the single user wants to mask his
   identity, he may choose to enable IPv6 privacy extensions.

5.4.  ISP/Carrier Customer Networks

   This group refers to the actual service providers that are providing
   the IP access and transport services.  They tend to have three
   separate IP domains that they support:
   o  For the first they fall into the Medium/large private networks
      category (above) for their own internal networks, LANs etc.
   o  The second is the Operations network which addresses their
      backbone and access switches, and other hardware, this is separate
      for both engineering reasons as well as simplicity in managing the
      security of the backbone.
   o  The third is the IP addresses (single or blocks) that they assign
      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
      RFC 1918 addresses used with IPv4 NAT for single user connections.
      Therefore they can actually have two different NAT domains that
      are not connected (internal LAN and single user customers).

   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
   in Section 5.1.  The second domain of the ISP/carrier is the
   Operations network.  This environment tends to be a closed
   environment, and consequently communication can be done based on ULA
   addresses, however, in this environment, stable IPv6 Provider
   Independent addresses can be used.  This would give a solid and
   scalable configuration with respect to a local IPv6 address plan.  By
   the usage of proper network edge filters, outside access to the
   closed environment can be avoided.  The third is the IPv6 addresses
   that ISP/carrier network assign to customers.  These will typically
   be assigned with prefix lengths terminating on nibble boundaries to
   be consistent with the DNS PTR records.  As scarcity of IPv6
   addresses is not a concern, it will be possible for the ISP to
   provide global routable IPv6 prefixes without 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



Van de Velde, et al.    Expires December 4, 2006               [Page 25]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   in comparison with the combination of IPv4+NAT for 3GPP attached
   devices.  When looking in chapter 2.3 of RFC3314 'Recommendations for
   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
   context.  This will allow sufficient address space for a 3GPP-
   attached node to allocate privacy addresses and/or route to a multi-
   link subnet, and will discourage the use of NAT within 3GPP-attached
   devices.


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.  Subnet Topology Masking

   There really is no functional gap here as a centrally assigned pool
   of addresses in combination with host routes in the IGP is an
   effective way to mask topology for smaller deployments.  If necessary
   a best practice document could be developed describing the
   interaction between DHCP and various IGPs which would in effect
   define Untraceable Addresses.

   As an alternative for larger deployments, there is no gap in the HA
   tunneling approach when firewalls are configured to block outbound
   binding update messages.  A border Home Agent using internal
   tunneling to the logical mobile node (potentially rack mounted) can
   completely mask all internal topology, while avoiding the strain from
   a large number of host routes in the IGP.  Some optimization work
   could be done in Mobile IP to define a policy message where a mobile
   node would learn from the Home Agent that it should not try to inform
   its correspondent about route optimization and thereby expose its
   real location.  This optimization which reduces the load on the
   firewall would result in less optimal internal traffic routing as
   that would also transit the HA.  This optimization work should be
   pursued in the IETF.

6.2.  Minimal Traceability of Privacy Addresses

   Privacy addresses (RFC 3041) may certainly be used to limit the
   traceability of external traffic flows back to specific hosts, but
   lacking a topology masking component above they would still reveal
   the subnet address bits.  For complete privacy a best practice



Van de Velde, et al.    Expires December 4, 2006               [Page 26]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   document describing the combination of privacy addresses with
   topology masking may be required.  This work remains to be done, and
   should be pursued by the IETF.

6.3.  Renumbering Procedure

   Site renumbering procedures are discussed in [12].  It should also be
   noticed that ULAs may help here too, since a change of ISP prefix
   will only affect hosts that are communicating externally.

6.4.  Site Multihoming

   This complex problem has never been completely solved for IPv4, which
   is exactly why NAT has been used as a partial solution.  For IPv6,
   after several years of work, the IETF has converged on an
   architectural approach intended with service restoration as initial
   aim [20].  Again, ULAs may help since they will provide stable
   addressing for internal communications that are not affected by
   multihoming.

6.5.  Untraceable Addresses

   The details of the untraceable addresses, along with any associated
   mechanisms such as route injection, must be worked out and specified.


7.  IANA Considerations

   This document requests no action by IANA


8.  Security Considerations

   While issues which are potentially security related are discussed
   throughout the document, the approaches herein do not introduce any
   new security concerns.  Product marketing departments have widely
   sold IPv4 NAT as a security tool and suppliers have been implementing
   address translation functionality in their firewalls, though the
   misleading nature of those claims has been previously documented in
   [2] and [4].

   This document defines IPv6 approaches which collectively achieve the
   goals of the network manager without the negative impact on
   applications or security that are inherent in a NAT approach.  To the
   degree that these techniques improve a network manager's ability to
   explicitly know about or control access, and thereby manage the
   overall attack exposure of local resources, they act to improve local
   network security.  In particular the explicit nature of a content



Van de Velde, et al.    Expires December 4, 2006               [Page 27]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   aware firewall in NAP will be a vast security improvement over the
   NAT artifact where lack of translation state has been widely sold as
   a form of protection.


9.  Conclusion

   This document has described a number of techniques that may be
   combined on an IPv6 site to protect the integrity of its network
   architecture.  These techniques, known collectively as Network
   Architecture Protection, retain the concept of a well defined
   boundary between "inside" and "outside" the private network, and
   allow firewalling, topology hiding, and privacy.  However, because
   they preserve address transparency where it is needed, they achieve
   these goals without the disadvantage of address translation.  Thus,
   Network Architecture Protection in IPv6 can provide the benefits of
   IPv4 Network Address Translation without the corresponding
   disadvantages.

   The document has also identified a few ongoing IETF work items that
   are needed to realize 100% of the benefits of NAP.


10.  Acknowledgements

   Christian Huitema has contributed during the initial round table to
   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
   note.  Editorial comments and contributions have been received from:
   Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar,
   Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark
   Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith,
   Elwyn Davies, Daniel Senie, Soininen Jonne, Lindqvist Erik Kurt and
   other members of the v6ops WG.


11.  References

11.1.  Normative References

   [1]   Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
         Lear, "Address Allocation for Private Internets", BCP 5,
         RFC 1918, February 1996.

   [2]   Srisuresh, P. and M. Holdrege, "IP Network Address Translator
         (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [3]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery



Van de Velde, et al.    Expires December 4, 2006               [Page 28]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [4]   Hain, T., "Architectural Implications of NAT", RFC 2993,
         November 2000.

   [5]   Srisuresh, P. and K. Egevang, "Traditional IP Network Address
         Translator (Traditional NAT)", RFC 3022, January 2001.

   [6]   Holdrege, M. and P. Srisuresh, "Protocol Complications with the
         IP Network Address Translator", RFC 3027, January 2001.

   [7]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [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
         (DHCPv6)", RFC 3315, July 2003.

   [10]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [11]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633,
         December 2003.

   [12]  Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
         an IPv6 Network without a Flag Day", RFC 4192, September 2005.

   [13]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", RFC 4193, October 2005.

11.2.  Informative References

   [14]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
         Domain Routing (CIDR): an Address Assignment and Aggregation
         Strategy", RFC 1519, September 1993.

   [15]  Wasserman, M., "Recommendations for IPv6 in Third Generation
         Partnership Project (3GPP) Standards", RFC 3314,
         September 2002.

   [16]  Savola, P. and B. Haberman, "Embedding the Rendezvous Point
         (RP) Address in an IPv6 Multicast Address", RFC 3956,
         November 2004.




Van de Velde, et al.    Expires December 4, 2006               [Page 29]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   [17]  Dupont, F. and P. Savola, "RFC 3041 Considered Harmful
         (draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004.

   [18]  Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown-
         v6ops-port-scanning-implications-01.txt)", July 2004.

   [19]  Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to
         think about when Renumbering an IPv6 network
         (draft-chown-v6ops-renumber-thinkabout-03)", October 2004.

   [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
             Addressing

   The users of native IPv6 technology and global unique IPv6 addresses
   have the potential to make use of the enhanced IPv6 capabilities, in
   addition to the benefits offered by the IPv4 technology.

A.1.  Universal Any-to-Any Aonnectivity

   One of the original design points of the Internet was any-to-any
   connectivity.  The dramatic growth of Internet connected systems
   coupled with the limited address space of the IPv4 protocol spawned
   address conservation techniques.  NAT was introduced as a tool to
   reduce demand on the limited IPv4 address pool, but the side effect
   of the NAT technology was to remove the any-to-any connectivity
   capability.  By removing the need for address conservation (and
   therefore NAT), IPv6 returns the any-to-any connectivity model and
   removes the limitations on application developers.  With the freedom
   to innovate unconstrained by NAT traversal efforts, developers will
   be able to focus on new advanced network services (i.e. peer-to-peer
   applications, IPv6 embedded IPsec communication between two
   communicating devices, instant messaging, Internet telephony, etc..)
   rather than focusing on discovering and traversing the increasingly
   complex NAT environment.

   It will also allow application and service developers to rethink the
   security model involved with any-to-any connectivity, as the current
   edge firewall solution in IPv4 may not be sufficient for Any-to-any
   service models.

A.2.  Auto-configuration

   IPv6 offers a scalable approach to minimizing human interaction and



Van de Velde, et al.    Expires December 4, 2006               [Page 30]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   device configuration.  Whereas IPv4 implementations require touching
   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
   potential number of connected devices, IPv6 uses an indication from
   the router to instruct the end systems to use DHCP or the stateless
   auto configuration approach supporting a virtually limitless number
   of devices on the subnet.  This minimizes the number of systems that
   require human interaction as well as improves consistency between all
   the systems on a subnet.  In the case that there is no router to
   provide this indication, an address for use only on the local link
   will be derived from the interface media layer address.

A.3.  Native Multicast Services

   Multicast services in IPv4 were severely restricted by the limited
   address space available to use for group assignments and an implicit
   locally defined range for group membership.  IPv6 multicast corrects
   this situation by embedding explicit scope indications as well as
   expanding to 4 billion groups per scope.  In the source specific
   multicast case, this is further expanded to 4 billion groups per
   scope per subnet by embedding the 64 bits of subnet identifier into
   the multicast address.

   IPv6 allows also for innovative usage of the IPv6 address length, and
   makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
   [16] directly in the IPv6 multicast address when using ASM multicast.
   this is not possible with limited size of the IPv4 address.  This
   approach also simplifies the multicast model considerably, making it
   easier to understand and deploy.

A.4.  Increased Security Protection

   The security protection offered by native IPv6 technology is more
   advanced than IPv4 technology.  There are various transport
   mechanisms enhanced to allow a network to operate more securely with
   less performance impact:
   o  IPv6 has the IPsec technology directly embedded into the IPv6
      protocol.  This allows for simpler peer-to-peer encryption and
      authentication, once a simple key/trust management model is
      developed, while the usage of some other less secure mechanisms is
      avoided (i.e. md5 password hash for neighbor authentication).
   o  On a local network, any user will have more security awareness.
      This awareness will motivate the usage of simple firewall
      applications/devices to be inserted on the border between the
      external network and the local (or home network) as there is no
      Address Translater and hance no false safety perception.





Van de Velde, et al.    Expires December 4, 2006               [Page 31]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   o  All flows on the Internet will be better traceable due to a unique
      and globally routable source and destination IPv6 address.  This
      may facilitate an easier methodology for back-tracing DoS attacks
      and avoid illegal access to network resources by simpler traffic
      filtering.
   o  The usage of private address-space in IPv6 is now provided by
      Unique Local Addresses, which will avoid conflict situations when
      merging networks and securing the internal communication on a
      local network infrastructure due to simpler traffic filtering
      policy.
   o  The technology to enable source-routing on a network
      infrastructure has been enhanced to allow this feature to
      function, without impacting the processing power of intermediate
      network devices.  The only devices impacted with the source-
      routing will be the source and destination node and the
      intermediate source-routed nodes.  This impact behavior is
      different if IPv4 is used, because then all intermediate devices
      would have had to look into the source-route header.

A.5.  Mobility

   Anytime, anywhere, universal access requires MIPv6 services in
   support of mobile nodes.  While a Home Agent is required for initial
   connection establishment in either protocol version, IPv6 mobile
   nodes are able to optimize the path between them using the MIPv6
   option header while IPv4 mobile nodes are required to triangle route
   all packets.  In general terms this will minimize the network
   resources used and maximize the quality of the communication.

A.6.   Merging Networks

   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
   network infrastructure due to the usage of RFC 1918 private
   addressing.  This potential overlap in address space may complicate a
   merge of two and more networks dramatically due to the additional
   IPv4 renumbering effort. i.e. when the first network has a service
   running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by
   the 2nd merging network.  Similar address conflicts can happen when
   two network devices from these merging networks want to communicate.

   With the usage of IPv6 the addressing overlap will not exist because
   of the existence of the Unique Local Address usage for private and
   local addressing.

A.7.  Community of interest

   Although some Internet-enabled devices will function as fully-fledged



Van de Velde, et al.    Expires December 4, 2006               [Page 32]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   Internet hosts, it is believed that many will be operated in a highly
   restricted manner functioning largely or entirely within a Community
   of Interest.  By Community of Interest we mean a collection of hosts
   that are logically part of a group reflecting their ownership or
   function.  Typically, members of a Community of Interest need to
   communicate within the community but should not be generally
   accessible on the Internet.  They want the benefits of the
   connectivity provided by the Internet, but do not want to be exposed
   to the rest of the world.  The ability in NAP to virtualize the
   topology to mask it is applied to the cluster, creating arbitrary
   groupings or communities.  It will also allow to build virtual
   organization networks on the fly, which is very difficult to do in
   IPv4+NAT scenarios.


Appendix B.  Revision history

B.1.  Changes from *-vandevelde-v6ops-nap-00 to
      *-vandevelde-v6ops-nap-01
   o  Document introduction has been revised and overview table added
   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
      a new case study section 5.
   o  The list of additional IPv6 benefits has been been placed into
      appendix.
   o  new security considerations section added.
   o  GAP analysis revised.
   o  Section 2.6 and 4.6 have been included.

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-
      v6ops-nap-00.txt.
   o  Editorial changes.

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
      firewall and proxy
   o  Revised Eric Klein contact details
   o  Added note in 4.2 that control over the proposed statefull-filter
      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./





Van de Velde, et al.    Expires December 4, 2006               [Page 33]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   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





Van de Velde, et al.    Expires December 4, 2006               [Page 34]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   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/



Van de Velde, et al.    Expires December 4, 2006               [Page 35]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   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)





Van de Velde, et al.    Expires December 4, 2006               [Page 36]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   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

B.5.  Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02
   o






Van de Velde, et al.    Expires December 4, 2006               [Page 37]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


B.6.  Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03
   o  Editorial changes in response to IESG review comments and
      questions.
   o  Introduction: clarified impact & goal for limited additional NAT
      discussion here / modified tone wrt marketing / grammar cleanup
   o  Introduction: added paragraph about why nat != security
   o  Table1: s/benefit/Goal/ s/ULA/4193/ removed long numeric string /
      added app end points & number of subnets
   o  Section 2: tone reduction about marketing
   o  Section 2.1: grammar cleanup / clarified point about use of public
      space / added paragraph about topology restrictions
   o  Section 2.2: moved paragraph about firewalls to 4.2 / deleted
      discussion about distributed security / clarified point about port
      overload
   o  Section 2.3: Added opening sentence to explain the goal of the
      section / deleted comment about theory
   o  Section 2.4: deleted confusing/redundant comments about identifier
      / added clarification that focused scanning on the port range
      reaches active nodes
   o  Section 2.5: clarified that the impact was on the local network
   o  Section 2.6: added point about limitations of cascaded nat
   o  Section 2.7: clarification about why multihoming & renumbering are
      discussed together / point about sparse allocation
   o  Section 3.2: grammer cleanup / updated reference from ID to RFC
      added point about policy table to bias ULA over ISP block
   o  Section 3.3: Clarification about goal for section
   o  Section 3.4: reorder paragraphs to put goal up front
   o  Section 4.1: s/could/should/ s/prior to establishing/independent
      of the state of/ clarified why concatenation would not collide /
      another comment about the policy table for ULA biasing / clarified
      point about lack of routing protocol
   o  Section 4.2: clarified point about firewall for boundary / 1.
      clarified point about valid lifetime / 2. clarified point that
      IPsec works the same w/o NAT / 3. clarified that the scanning
      threat is addresses as ports are the same once an address is known
      / rearranged paragraph to keep scanning thread together /
      clarified role of simple firewall / added comment about service
      provider mediated pinhole management
   o  Section 4.3: added paragraph about tracking privacy address use
   o  Section 4.4: clarified point about tracking wrt NAT / added
      comment about IGP complexity / s/conceal/isolate/ reworded ULA
      description which was technically backwards / additional
      description of the goal / added picture and referenced it from
      descriptions / added vlan option
   o  Section 4.5: Grammar cleanup / clarification about policy
   o  Section 4.6: added discussion about policy focus on subnets





Van de Velde, et al.    Expires December 4, 2006               [Page 38]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


   o  Section 4.7: s/CIDR-like/CIDR allocated/ s/this/to multiple
      addresses/ s/may/will likely/ s/if/when/ s/from SP/between sp/
   o  Section 5: d/of these/
   o  Section 5.1: deleted redundant discussion about /48 allocation /
      added discussion about larger deployments using tunneling
   o  Section 5.2: clarification of overload on port vs. protocol /
      added comment about upstream NAT / clarified 3041 use
   o  Section 5.4: s/IPv4/IP as role is not version specific / deleted
      comment about preference to ULA.
   o  Section 6.1: added comment about deployment scale / added comment
      about firewall blocking BU / clarified point about future work
      being an optimization to reduce firewall load
   o  Section 6.3: replaced reference to renumbering draft w/RFC
   o  Section 6.4: grammar cleanup
   o  Section A.2: word order - moved 'only'
   o  Section A.6: deleted 'legitimate'
   o  Section A.7: clarified how NAP delivers community of interest
   o  Section B.5: added place holder for missing change log -01 to -02

































Van de Velde, et al.    Expires December 4, 2006               [Page 39]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


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





Van de Velde, et al.    Expires December 4, 2006               [Page 40]

Internet-Draft    IPv6 Network Architecture Protection         June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   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
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Van de Velde, et al.    Expires December 4, 2006               [Page 41]