Margaret, The text sent out on 6/13 was mid-edit session, basically looking to get comments about the tone changes wrt marketing. The completed edit is attached with the diff, though I have not passed this by the other authors yet. I had planned to do that when I finished today, but your note appeared to need a prompt response so you all get it at once. I made a number of grammatical changes and reordered some areas to make the points clearer. Most of the marketing comments are gone, but in their place is a statement that points out that most users of nat do not evaluate the technical trade-offs and are not even made aware of the problems they will encounter. I also changed the tone in some areas from one of offering a choice between approaches to one that explains how those approaches work. The 'offer' tone appears to have left the IESG with the perception that the approaches were speculative. One thing to highlight here though is that there appears to be an expectation that this document is a BCP, when all along it has been informational. If a BCP is the goal then substantial changes will be required. As information, it covers the range of approaches that people need to be aware of. The portability you reference below is not a nat feature. The only 'real' advantage to nat is the expansion of the address space. The reduction of impact on the routing system has more to do with insistence on ISP based aggregates that would go away with other aggregation units. Unfortunately people prefer a challenge and would rather engineer a non-deployable work-around to a problem-of-choice than discuss the fundamental issues or alternatives. I expect there will need to be some discussion in the WG to make sure it covers the issues before we present this to the IESG again, though I do believe it addresses all the comments. Tony > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Wednesday, June 28, 2006 12:40 PM > To: 'Tony Hain'; 'Fred Baker'; 'Tim Chown' > Cc: v6ops@ops.ietf.org > Subject: RE: Review of draft-ietf-v6ops-nap-02.txt > > > > Hi Tony, > > > 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. > > I think it might be useful to discuss the IESG comments in more depth, > either on the list or in the WG meeting. I realize that you have made > changes to address some of the comments, but I think that the WG has to > decide what to do (if anything) about the substantive issues that you have > not yet addressed. > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > > w_comment&id=5 > > 2102 > > I put in an arbitrary 50k number as a scale reference. > > 50K is an order of magnitude higher than the analysis in Alex Zinin's > presentation would seem to indicate. His presentation indicates that flat > routing will only scale to something on the order of 1K nodes. Please > feel > free to check with Alex, though, as he certainly has more understanding of > IGP scaling than I do. > > > 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. > > If this document is going to recommend doing flat routing for topology > hiding, I think that the WG needs to do the analysis to determine that > this > is a valid and scalable technique. I would prefer that we just took it > out > (perhaps considering a separate document to describe this technique if we > really think it is worthwhile), because this is an informational document > and I don't think it is the best place to specify a new operational > recommendation. BUt, if we do decide to leave it in, then we need to > document it in enough detail for readers to know when it is (and is not) > applcable. > > > 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. > > NAT has real (not just perceived ormarketing-invented) advantages in the > area of address portability. At this point, we do not have mechanisms in > IPv6 that provide a similar function although SHIM6 may help. > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > > w_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. > > Did you cc: the WG on that message? I don't seem to have received it. > > You made several changes based on my review comments that look good to me. > Thank you! > > However, you don't seem to have addressed some of the concerns that were > raised in my review. I realize that you don't agree with all of my review > comments, but some people did agree with them on the list. I guess I'd > like > to see some further discussion before we simply decided that no changes > are > warranted based on these comments. > > In particular, I am still concerned about the following comments: > > (1) Thomas' comments on renumbering, combined with my comments on > providing > a more balanced view of the real benefits of NAT: > > > There are at least three other _real_ benefits of NAT boxes. > > While I hold with this document's position that these benefits > > can and should be realized in other ways in IPv6, I do not think > > it is factual or helpful to argue that they don't exist. Those > > benefits are: > > > > (1) Avoiding the reliance of internal network number on externally > > allocated numbers. AKA not having to renumber when you change ISPs > > or when ISPs change address allocation strategies. > > > > (2) Hiding internal topology from external communicants. > > > > (3) Avoiding the establishment of unauthorized inbound connections. > > While this NAT side effect can also cause problems, it does provide > > the real benefits of a stateful firewall. > > (2) I think that this portion (in section 4.1) still needs some work. Let > me know if I am missing something here: > > > It should be > > noted that the address selection policy table in end-systems needs to > > be correctly set up so that true global prefixes are distinguished > > from ULAs and will be used for the source address in preference when > > the destination is not a ULA. > > > > Unless one takes steps to actively screw this up, a globally routable > > destination address will always have a longest-prefix match with a > > globally routable source and a ULA will always have a longest-prefix > > match with a ULA. So, the last sentence is unnecessary and somewhat > > misleading. > > > > The tricky part is making sure that the node uses the right destination > > address -- a ULA for local traffic and global address for non-local > > traffic. This will generally require the use of some type of split DNS, > > with ULAs returned internally but not externally. > > (3) Although you made changes based on my comments on section 4.1, bullet > 3, > you have not completely addressed by comment. We are essentially > declaring > that something will not be a problem if the IIDs are randomly distributed > while ignoring the fact that they won't be. If we are trying to indicate > that administrators should override the default mechanisms for IID > autoconfiguration to provide random IIDs, I guess we should say that. > Otherwise, we should understand that the IIDs will not be randomly > distributed, so the math later in this section does not apply. > > (4) Section 4.6 has been updated based on discussion, but it now says: > > 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 . > > The last sentence above is apparently truncated. > > (5) I still don't see any justification for this statement: > > > o On a local network, any user will have more security awareness. > > > > IPv6 will make users more security-aware? What does this mean?
Network Working Group G. Van de Velde
Internet-Draft T. Hain
Expires: January 1, 2007 R. Droms
Cisco Systems
B. Carpenter
IBM Corporation
E. Klein
Tel Aviv University
June 30, 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 January 1, 2007.
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 January 1, 2007 [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 address translation.
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 . . 7
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 . . . . . . . . . . . . . . . . 12
3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12
3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13
3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14
3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14
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 . 20
4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20
4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Medium/large private networks . . . . . . . . . . . . . . 22
5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23
5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25
5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25
6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27
6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 27
6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 27
6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Van de Velde, et al. Expires January 1, 2007 [Page 2]
Internet-Draft IPv6 Network Architecture Protection June 2006
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Additional Benefits due to Native IPv6 and
Universal Unique Addressing . . . . . . . . . . . . 31
A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 31
A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 31
A.3. Native Multicast Services . . . . . . . . . . . . . . . . 32
A.4. Increased Security Protection . . . . . . . . . . . . . . 32
A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 33
A.7. Community of interest . . . . . . . . . . . . . . . . . . 33
Appendix B. Revision history . . . . . . . . . . . . . . . . . . 34
B.1. Changes from *-vandevelde-v6ops-nap-00 to
*-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 34
B.2. Changes from *-vandevelde-v6ops-nap-01 to
*-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 34
B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 34
B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 34
B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42
Van de Velde, et al. Expires January 1, 2007 [Page 3]
Internet-Draft IPv6 Network Architecture Protection June 2006
1. Introduction
There have been periodic claims that IPv6 will require a Network
Address Translation (NAT), because in IPv4 people use NAT to
accomplish that person's preferred task. This document will explain
why those pronouncements are false by showing how to accomplish the
task goal without address translation. Although there are many
perceived benefits to NAT, its primary benefit of "amplifying"
available address space is not needed in IPv6. The serious
disadvantages and impact on applications by ambiguous address space
and Network Address Translation [1] [5] have been well documented [4]
[6] so there will not be much additional discussion here. However,
given its wide deployment NAT undoubtedly has some perceived
benefits, though the bulk of those using it have not evaluated the
technical trade-offs. Indeed, product marketing departments have
effectively driven a perception that some connectivity and security
concerns can only be solved by using a NAT device, without any
mention of the negative impacts on applications. This is amplified
through the widespread sharing of vendor best practice documents and
sample configurations that do not differentiate the translation
function of address expansion from the state function of limiting
connectivity.
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. It should be
noted that this document is 'informational', as it discusses
approaches that will work to accomplish the goals. It is
specifically not a BCP that is recommending any one approach.
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; in fact it breaks the ability to produce an audit
trail which is a fundamental security tool. That said, the artifacts
Van de Velde, et al. Expires January 1, 2007 [Page 4]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 attached 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
IPv6 deployment to protect the integrity of its network architecture.
It will focus on the 'how to accomplish 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 January 1, 2007 [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 |
| | 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 | 17*10^18 subnets |
| Pool | << 2^48 application | 3.4*10^38 addresses |
| Conservation | end points | full port list / addr |
| | topology restricted | unrestricted topology |
| | 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 |
+------------------+-----------------------+-----------------------+
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
Van de Velde, et al. Expires January 1, 2007 [Page 6]
Internet-Draft IPv6 Network Architecture Protection June 2006
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. 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
& unregistered 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 act as a simple
gateway attaching 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'.
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
Van de Velde, et al. Expires January 1, 2007 [Page 7]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 of NAT 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, often 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,
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.
Van de Velde, et al. Expires January 1, 2007 [Page 8]
Internet-Draft IPv6 Network Architecture Protection June 2006
2.4. Privacy and Topology Hiding
One 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 from 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 so all internal nodes appear to exist
at the demarcation edge. 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 systems 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 local network but can instead concentrate on the
active ports associated with the NAT adress. By periodically
scanning the limited 16 bit port range on the public side of the NAT,
the attack will routinely find all 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 network managers prefer to hide as much as possible of their
internal network topology from outsiders as a useful precaution to
mitigate scanning attacks. Mostly this is achieved by blocking
"traceroute" etc., though NAT entirely hides the internal subnet
topology. Scanning is a particular concern in IPv4 networks because
the subnet size is small enough that once the topology is known it is
easy to find all the hosts, then start scanning them for vulnerable
ports. Once a list of available devices has been mapped, a port-scan
on these IP addresses can be performed. Scanning works by tracking
which ports do not receive unreachable errors from either the
Van de Velde, et al. Expires January 1, 2007 [Page 9]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 access to an end
system to command it to start initiating attacks on others.
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 sufficiently large pool for 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, the ongoing depletion of the IPv4 address range has
already taken the remaining pool of unallocated IPv4 addresses 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, though this practice
eventually breaks down over routing ambiguity. Additionally, while
we are unlikely to know the full extent of the practice (because it
is hidden behind a nat), service providers have been known to
announce previously unallocated public space to their customers (to
avoid the problems associated with the same address space appearing
on both sides), only to find that once that space was formally
Van de Velde, et al. Expires January 1, 2007 [Page 10]
Internet-Draft IPv6 Network Architecture Protection June 2006
allocated and being publicly announced their customers couldn't reach
the registered networks.
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 limit of this approach is something substantially less than 2^48
possible active **application** endpoints (approximately [2^32 minus
2^29] * [2* 2^16 minus well known port space]), as distinct from
addressable devices each with their own application endpoint range.
Those who advocate layering of NAT frequently forget to mention that
there are topology restrictions placed on the applications. 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.
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
[15] 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 spaces in the
merged networks.
Van de Velde, et al. Expires January 1, 2007 [Page 11]
Internet-Draft IPv6 Network Architecture Protection June 2006
3. Description of the IPv6 Tools
This section describes several features that can be used as part of
the NAP solution to replace the protection features associated with
IPv4 NAT.
The reader must clearly distinguish between features of IPv6 that
were fully defined when this document was drafted and those that were
potential features that still required more work to define them. The
latter are summarized later in the 'Gap Analysis' section of this
document. However, we do not distinguish in this document between
fully defined features of IPv6 and those that were already widely
implemented at the time of writing.
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
as it moves around the Internet. 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).
As originally defined, IPv6 stateless address auto-configuration
(SLAAC) will typically embed the IEEE Link Identifier of the
interface as the IID part, though this practice facilitates tracking
and profiling of a device through the consistent IID. RFC 3041 [7]
describes an extension to SLAAC to enhance device privacy. Use of
the privacy address extension causes nodes to generate global-scope
addresses from interface identifiers that change over time,
consistent with system administrator policy. 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 auto-
configuration, 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
Van de Velde, et al. Expires January 1, 2007 [Page 12]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 [18].
3.2. Unique Local Addresses
Achieving the goal of autonomy, that many perceive as a value of NAT,
is required for local network and application services stability
during periods of intermittent connectivity or moving between one or
more providers. Such autonomy in a 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) [14] 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 For all practical purposes a 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 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.
Van de Velde, et al. Expires January 1, 2007 [Page 13]
Internet-Draft IPv6 Network Architecture Protection June 2006
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
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
Van de Velde, et al. Expires January 1, 2007 [Page 14]
Internet-Draft IPv6 Network Architecture Protection June 2006
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
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 prefix delegated via DHCP-PD
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 defenses. 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 authenticate the correspondent, prevent session
hijacking, prevent content tampering, and optionally masks the
packet contents. While IPsec might be available in IPv4
implementations and works the same way, 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 potential number of combinations available. Reducing
Van de Velde, et al. Expires January 1, 2007 [Page 15]
Internet-Draft IPv6 Network Architecture Protection June 2006
the security threat of port scans on identified nodes requires
sparse distribution within the subnet to minimize the probability
of scans finding adjacent nodes. Provided that IIDs are
essentially randomly distributed across the available space,
address scanning based attacks will effectively fail. This
protection exists if the attacker has no direct access to the
specific subnet and therefore is trying to scan it remotely. If
an attacker has local access then he could use ND [3] and ping6
to the link-scope multicast ff02::1 to detect the IEEE based
address of local neighbors, then apply the global prefix to those
to simplify its search (of course, a locally connected attacker
has many scanning options with IPv4 as well). This scanning
protection will be nullified if IIDs are configured in any
structured groupings within the IID space.
Assuming the network administrator is aware of [19] 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 full-duplex 40Gbps (400 times the typical
100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it
takes over 5000 years to scan the entirety of a single 64 bit subnet.
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.
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.
Van de Velde, et al. Expires January 1, 2007 [Page 16]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 signaling could dynamically establish pinholes based on
predefined authentication 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 without increasing
the perceived complexity for users who just want to accomplish a
task.
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 correlating 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 traceable to the most public NAT interface.
Van de Velde, et al. Expires January 1, 2007 [Page 17]
Internet-Draft IPv6 Network Architecture Protection June 2006
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.
As discussed in Section 3.1, there are multiple parts to the IPv6
address, and different techniques to manage privacy for each which
may be combined to protect the entire address. In the case where a
network administrator wishes to fully isolate the internal IPv6
topology, and the majority of its internal use addresses, one option
is to run all internal traffic using Unique Local Addresses (ULA).
By definition this prefix block is not to be advertised into the
public routing system, so without a routing path external traffic
will never reach the site. For the set of hosts that do in fact need
to interact externally, by using multiple IPv6 prefixes (ULAs and one
or more global addresses) all of the internal nodes that do not need
external connectivity, and the internally used addresses of those
that do will be masked from the outside. The policy table defined in
[10] provides a mechanism to bias the selection process when multiple
prefixes are in use such that the ULA would be preferred when the
correspondent is also local.
There are other 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 logically
exist at the edge of the network, just as they would when behind a
NAT.
o One approach uses explicit host routes in the IGP to remove the
external correlation between physical topology attachment point
and end-to-end 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 requires hosts to participate in the IGP, as well as having
the firewall block all external to internal traceroute for the
logical subnet. The specific limitations are dependent on the IGP
protocol, the physical topology, and the stability of the system.
In any case the approach should be limited to uses with
substantially fewer than the maximum number of routes that the IGP
Van de Velde, et al. Expires January 1, 2007 [Page 18]
Internet-Draft IPv6 Network Architecture Protection June 2006
can support (generally between 5,000 and 50,000 total entries
including subnet routes).
o Another technical approach to fully hide the internal topology is
use of a tunneling mechanism. Mobile IPv6 without route
optimization is one approach for using an automated tunnel, as it
always starts in tunnel mode via the Home Agent (HA). In this
deployment model the application perceived addresses of the nodes
are routed via the edge HA. This indirection method truly masks
the internal topology, as from outside the local network all nodes
with global access appear to share the prefix of one or more
logical subnets attached to the HA rather than their real
attachment point. 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 using the home
address to route via the HA tunnel, which may be undesirable. A
more efficient method would be to allow internal route
optimizations while dropping outbound binding updates at the
firewall. Another approach for the internal routes would be to
use the policy table of RFC 3484 to bias a ULA prefix as preferred
internally, leaving the Home Address external for use. The
downsides of using the MIPv6 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) uses 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 |-+-+-+-+-+-+-+-+--
| or Home Agent | Logical subnets
| |-+-+-+-+-+-+-+-+--
+------------------+ for topology
| hidden nodes
|
Real internal -------------+-
topology | |
| -+----------
-----------+--------+
|
Van de Velde, et al. Expires January 1, 2007 [Page 19]
Internet-Draft IPv6 Network Architecture Protection June 2006
|
|
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 artificial demand for NAT.
Ongoing subnet address maintenance may become simpler when IPv6
technology is utilized. Under IPv4 address space policy restrictions
each subnet must be optimized, 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 IPv4 /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.
4.6. Global Address Pool Conservation
IPv6 provides sufficient space to completely avoid the need for
overlapping address space. Since allocations in IPv6 are based on
subnets rather than hosts a reasonable way to look at the pool is
that there are about 17*10^18 unique subnet values where sparse
allocation practice within those provides for new opportunities such
as SEND 3971 [12]. 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
Van de Velde, et al. Expires January 1, 2007 [Page 20]
Internet-Draft IPv6 Network Architecture Protection June 2006
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, removing,
and renumbering active prefixes at a site have been documented in
[13] and [20].
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.
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)
Van de Velde, et al. Expires January 1, 2007 [Page 21]
Internet-Draft IPv6 Network Architecture Protection June 2006
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, academic, research, or government
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
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.
When 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 appear to exist at the external edge
of the network, and may be assigned to those hosts for which topology
Van de Velde, et al. Expires January 1, 2007 [Page 22]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 'host based
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 which will complicate auditing systems. 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.
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
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
Van de Velde, et al. Expires January 1, 2007 [Page 23]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 publicly routed. 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
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
Van de Velde, et al. Expires January 1, 2007 [Page 24]
Internet-Draft IPv6 Network Architecture Protection June 2006
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
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:
Van de Velde, et al. Expires January 1, 2007 [Page 25]
Internet-Draft IPv6 Network Architecture Protection June 2006
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
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' [16] 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
Van de Velde, et al. Expires January 1, 2007 [Page 26]
Internet-Draft IPv6 Network Architecture Protection June 2006
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. Simple Security
Dynamic pinhole management is an area for further study. Several
partial solutions exist including ICE, UPNP, as well as alternative
proposals for Service Provider based control. The 'simple' aspect of
the security provided by a stateful firewall will require some degree
of automation to mask the technical complexity from the consumer that
only wants a secure environment with working applications.
6.2. 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. Trade-off's for this optimization
work should be investigated in the IETF.
6.3. 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
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.
Van de Velde, et al. Expires January 1, 2007 [Page 27]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 [21]. When this document was drafted, the IETF was actively
defining the details of this approach to the multihoming problem.
The approach appears to be most suitable for small and medium sites,
though it will conflict with firewall state procedures. At this time
there are also active discussions in the address registries
investigating the possibility of assigning provider-independent
address space. Their challenge is finding a reasonable metric for
limiting the number of organizations that would qualify for a global
routing entry. Additional work appears to be necessary to satisfy
the entire range of requirements.
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 audit 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 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
Van de Velde, et al. Expires January 1, 2007 [Page 28]
Internet-Draft IPv6 Network Architecture Protection June 2006
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
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.
Van de Velde, et al. Expires January 1, 2007 [Page 29]
Internet-Draft IPv6 Network Architecture Protection June 2006
[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] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[13] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
11.2. Informative References
[15] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, September 1993.
[16] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314,
September 2002.
[17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004.
[18] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful
(draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004.
[19] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning
(chown-v6ops-port-scanning-implications-01.txt)", July 2004.
Van de Velde, et al. Expires January 1, 2007 [Page 30]
Internet-Draft IPv6 Network Architecture Protection June 2006
[20] 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.
[21] 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 Connectivity
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
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
Van de Velde, et al. Expires January 1, 2007 [Page 31]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 'Rendezvous Point' (or RP)
[17] 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 authentication and
encryption, 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 Translator and hence no false safety perception.
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
Van de Velde, et al. Expires January 1, 2007 [Page 32]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 Internet hosts, it is believed that many will be operated in
a highly restricted manner functioning largely or entirely within a
Community of Interest. By Community of Interest we mean a collection
of hosts that are logically part of a group reflecting their
ownership or function. Typically, members of a Community of Interest
need to communicate within the community but should not be generally
accessible from the public Internet. They want the benefits of the
connectivity provided by the Internet, but do not want to be exposed
Van de Velde, et al. Expires January 1, 2007 [Page 33]
Internet-Draft IPv6 Network Architecture Protection June 2006
to the rest of the world. The ability in NAP to virtualize the
topology and mask portions of it is applied to the community,
creating arbitrary groupings. It will also allow building virtual
organization networks on the fly, which is very difficult to do in
IPv4+NAT scenarios.
Appendix B. Revision history
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 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 capitalized.
o Section 1: para 3: s/...and privacy and will... translation./
...and privacy. NAP will achieve these security goals without
address translation whilst maintaining any-to-any connectivity./
o Section 1: Various editorial changes happened
o Section 2.1: Changed: 'Frequently a simple user interface is
sufficient for configuring'. into 'Frequently a simple user
interface, or no user interface is sufficient'
o Section 2.2: (Simple Security ) Better not to use the word -evil-
in the text
o Section 2.2: changed 'provided by NAT are actually ' into
'provided by NAT is actually'
Van de Velde, et al. Expires January 1, 2007 [Page 34]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 independent 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
spaces in the merged networks/
o Section 3.1: Para 1 editorial changes
o Section 3.1: s/by contacted web sites, so IPv6/by web sites that
are accessed from the device: IPv6 /
o Section 3.1: s/as that would have a serious negative impact on
global routing/as that would have a negative effect on global
route aggregation
o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in
global routing table is not scalable
o Section 3.2: s3.2: Noted that it is not always interesting 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.'
Van de Velde, et al. Expires January 1, 2007 [Page 35]
Internet-Draft IPv6 Network Architecture Protection June 2006
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: split the 1 section up into 2 separate sections
o Section 4.1: s/ End node connections involving other nodes on the
global Internet will always use the global IPv6 addresses [9]
derived from this prefix delegation./ End node connections
involving other nodes on the global Internet will always use the
global IPv6 addresses [9] derived from this prefix delegation. It
should be noted that the policy table needs to be correctly set up
so that true global prefixes are distinguished from ULAs and will
be used for the source address in preference when the destination
is not a ULA/
o Section 4.1: A more secure network environment can be established
by having the referenced ULA addresses statically configured on
the network devices as this decreases the dynamic aspects of the
network, however the operational overhead is increased.
o Section 4.2: Added note that IID should be randomized for port-
scan protection
o Section 4.2: Removed text: This is an automated procedure of
sending Internet Control Message Protocol (ICMP) echo requests
(also known as PINGs) to a range of IP addresses and recording
replies. This can enable an attacker to map the network.
o Section 4.2: paragraph beginning: "This simple rule...". The
first sentence in this paragraph was overly-long. The sentence
has been fragmented
o Section 4.2: para 1: s/similar as for an/similar to that of an/
o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/
Internet. The use of firewall and Intrusion Detection Systems
(IDS) is/
o Section 4.2: para 1: s/but has/but with/
o Section 4.2: para 1: s/end to end/end-to-end/
o Section 4.2: Item 3: s/amount/number/
o Section 4.2: Item 3: s/This goes from the assumption that the
attacker has no/This protection is nullified if the attacker has/
o Section 4.2: para after Item 3: s/pose/offer/ (or provide).
o Section 4.2: para after Item 3: s/best- practices/best practices/
o Section 4.2: para after example firewall rules: s/create similar
protection and security holes the typical IPv4 NAT device will
offer/provide (non-)protection and create security holes similar
Van de Velde, et al. Expires January 1, 2007 [Page 36]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 complementary
text to describe a potential behavior
o Section 4.4: rewrite of the section to reduce the importance of
the MIPv6 and tunneled solution
o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested
in the text, however text is added that any kind of tunneling
should do the trick.
o Section 4.4: para 2: after 'As discussed above' inserted '(see
Section 3.1)'
o Section 4.4: para 3: s/consolidated on/indirected via/
o Section 4.4: para 3: s/topololgy masked/each topology masked/
o Section 4.4: para 3: Expanded acronym COA
o Section 4.4: para 3: s/rack mounted/static/
o Section 4.4: Rephrasing of text happened in this section
o Section 4.5: change: "so that a NAT is not required" to: "so that
IPv6 address translation is not required".
o Section 4.5: changed 'periodically to look' into 'to look
periodically'
o Section 4.5: change: "2^64 hosts" to: "2^64 addresses".
o Section 4.5: Removed the statement '(or even defined)
o Section 4.6: last para: s/which will lead to the IPv4 practice/
which will require the adoption of the IPv4 workaround/
o Section 4.6: s/the IPv4 constricting scenarios of multiple devices
sharing a/the constriction of IPv4 scenarios where multiple
devices 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
Van de Velde, et al. Expires January 1, 2007 [Page 37]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 'allocation' 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-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: s/market acceptance/deployment
o Introduction: noted that users do not evaluate technical trade-
offs and that marketing does not mention the downside of address
translation
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 / removed last
paragraph about security
Van de Velde, et al. Expires January 1, 2007 [Page 38]
Internet-Draft IPv6 Network Architecture Protection June 2006
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 / changed comment about theory to an absolute / qualified
logging and checking times
o Section 2.4: deleted confusing/redundant comments about identifier
/ clarified point about nodes appearing to be at the edge / added
clarification that focused scanning on the port range reaches
active nodes
o Section 2.5: clarified that the reason for autonomy is large space
& impact was on the local network
o Section 2.6: clarified point about reduction of IPv4 consumption
rate / s/30%/25% / added point about limitations of cascaded nat /
added para about limited app endpoints as well as topology
restrictions
o Section 2.7: clarification about why multihoming & renumbering are
discussed together / point about sparse allocation / s/speaces/
spaces
o Section 3: s/emulate/replace / added para about 'gaps' being
discussed later
o Section 3.1: Cleaned up description of SLAAC & 3041 / specified
server as DHCP / added comment about sparse allocation
o Section 3.2: grammar cleanup / updated reference from ID to RFC
4193 / added point about policy table in 3484 to bias ULA over ISP
prefix
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 3484 table for ULA biasing / clarified
point about lack of routing protocol
o Section 4.2: clarified point about firewall at boundary /
clarified point about valid lifetime / clarified point that IPsec
works the same w/o NAT / added point about authenticating
correspondent / clarified that the scanning threat is addresses as
ports are the same once an address is known / rearranged paragraph
to keep scanning thread together / inserted firewall discussion
moved from 2.2 / 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/ s/possible/
potential/ reworded ULA description which was technically
backwards / additional description of the goal / added picture and
referenced it from descriptions converted options to descriptive
list / added discussion about blocking binding updates / added
vlan option / s/would be to use/uses to make it clear this already
Van de Velde, et al. Expires January 1, 2007 [Page 39]
Internet-Draft IPv6 Network Architecture Protection June 2006
works / para 2 s/prefixes/addresses and replaced last part of the
sentence to clarify what was being hidden.
o Section 4.5: Grammar cleanup / clarification about policy
o Section 4.6: replaced long number string with power qnty of
subnets / added reference to new capabilities like SEND
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/
Updated reference for renumbering proceedure to RFC 4192
o Section 5: d/of these/
o Section 5.1: s/private enterprise/private enterprise, academic,
research, or government / 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 as short
timeframe
o Section 5.3: capitalize Internet
o Section 5.4: s/IPv4/IP as role is not version specific / deleted
comment about preference to ULA.
o Section 6.1: (security) inserted section discussing need for
dynamic pinhole management
o Section 6.2: (topology mask) 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: (tracability) grammar cleanup
o Section 6.4: (renumbering) Cut section since it is no longer a gap
o Section A.2: word order - moved 'only'
o Section A.6: deleted 'legitimate'
o Section A.7: clarified how NAP delivers community of interest
o Spell check
Van de Velde, et al. Expires January 1, 2007 [Page 40]
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 January 1, 2007 [Page 41]
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 January 1, 2007 [Page 42]
Title: Diff: draft-ietf-v6ops-nap-02.txt - draft-ietf-v6ops-nap-03.txt
| draft-ietf-v6ops-nap-02.txt | draft-ietf-v6ops-nap-03.txt | |||
|---|---|---|---|---|
| Network Working Group G. Van de Velde | Network Working Group G. Van de Velde | |||
| Internet-Draft T. Hain | Internet-Draft T. Hain | |||
| Expires: April 25, 2006 R. Droms | Expires: January 1, 2007 R. Droms | |||
| Cisco Systems | Cisco Systems | |||
| B. Carpenter | B. Carpenter | |||
| IBM Corporation | IBM Corporation | |||
| E. Klein | E. Klein | |||
| Tel Aviv University | Tel Aviv University | |||
| October 22, 2005 | June 30, 2006 | |||
| IPv6 Network Architecture Protection | IPv6 Network Architecture Protection | |||
| <draft-ietf-v6ops-nap-02.txt> | <draft-ietf-v6ops-nap-03.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 April 25, 2006. | This Internet-Draft will expire on January 1, 2007. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| Although there are many perceived benefits to Network Address | Although there are many perceived benefits to Network Address | |||
| Translation (NAT), its primary benefit of "amplifying" available | Translation (NAT), its primary benefit of "amplifying" available | |||
| address space is not needed in IPv6. In addition to NAT's many | address space is not needed in IPv6. In addition to NAT's many | |||
| serious disadvantages, there is a perception that other benefits | serious disadvantages, there is a perception that other benefits | |||
| exist, such as a variety of management and security attributes that | exist, such as a variety of management and security attributes that | |||
| could be useful for an Internet Protocol site. IPv6 does not support | could be useful for an Internet Protocol site. IPv6 does not support | |||
| NAT by design and this document shows how Network Architecture | NAT by design and this document shows how Network Architecture | |||
| Protection (NAP) using IPv6 can provide the same or more benefits | Protection (NAP) using IPv6 can provide the same or more benefits | |||
| without the need for NAT. | without the need for address translation. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 6 | 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7 | |||
| 2.1. Simple Gateway between Internet and Private Network . . . 6 | 2.1. Simple Gateway between Internet and Private Network . . . 7 | |||
| 2.2. Simple Security due to Stateful Filter Implementation . . 6 | 2.2. Simple Security due to Stateful Filter Implementation . . 7 | |||
| 2.3. User/Application tracking . . . . . . . . . . . . . . . . 7 | 2.3. User/Application tracking . . . . . . . . . . . . . . . . 8 | |||
| 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8 | 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9 | |||
| 2.5. Independent Control of Addressing in a Private Network . . 9 | 2.5. Independent Control of Addressing in a Private Network . 10 | |||
| 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9 | 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10 | |||
| 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10 | 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11 | |||
| 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 10 | 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 12 | |||
| 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 10 | 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12 | |||
| 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 11 | 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13 | |||
| 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 12 | 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14 | |||
| 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 12 | 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14 | |||
| 4. Using IPv6 Technology to Provide the Market Perceived | 4. Using IPv6 Technology to Provide the Market Perceived | |||
| Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 13 | Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.1. Simple Gateway between Internet and Internal Network . . . 13 | 4.1. Simple Gateway between Internet and Internal Network . . . 14 | |||
| 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 13 | 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15 | |||
| 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 15 | 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17 | |||
| 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 15 | 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17 | |||
| 4.5. Independent Control of Addressing in a Private Network . . 16 | 4.5. Independent Control of Addressing in a Private Network . 20 | |||
| 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 17 | 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20 | |||
| 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 17 | 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21 | |||
| 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 5.1. Medium/large private networks . . . . . . . . . . . . . . 18 | 5.1. Medium/large private networks . . . . . . . . . . . . . . 22 | |||
| 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 20 | 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23 | |||
| 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 21 | 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25 | |||
| 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 22 | 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25 | |||
| 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 23 | 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 23 | 6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 23 | 6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 27 | |||
| 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 23 | 6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 27 | |||
| 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 24 | 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 24 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 | |||
| 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 . . . . . . . . . . . . . 27 | Universal Unique Addressing . . . . . . . . . . . . 31 | |||
| A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 27 | A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 31 | |||
| A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 27 | A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 31 | |||
| A.3. Native Multicast Services . . . . . . . . . . . . . . . . 28 | A.3. Native Multicast Services . . . . . . . . . . . . . . . . 32 | |||
| A.4. Increased Security Protection . . . . . . . . . . . . . . 28 | A.4. Increased Security Protection . . . . . . . . . . . . . . 32 | |||
| A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29 | A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 29 | A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 33 | |||
| A.7. Community of interest . . . . . . . . . . . . . . . . . . 29 | A.7. Community of interest . . . . . . . . . . . . . . . . . . 33 | |||
| Appendix B. Revision history . . . . . . . . . . . . . . . . . . 30 | Appendix B. Revision history . . . . . . . . . . . . . . . . . . 34 | |||
| B.1. Changes from *-vandevelde-v6ops-nap-00 to | B.1. Changes from *-vandevelde-v6ops-nap-00 to | |||
| *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 30 | *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 34 | |||
| B.2. Changes from *-vandevelde-v6ops-nap-01 to | B.2. Changes from *-vandevelde-v6ops-nap-01 to | |||
| *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30 | *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 34 | |||
| B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30 | B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 34 | |||
| B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 30 | B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 34 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 | B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 36 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 42 | ||||
| 1. Introduction | 1. Introduction | |||
| Although there are many perceived benefits to Network Address | There have been periodic claims that IPv6 will require a Network | |||
| Translation (NAT), its primary benefit of "amplifying" available | Address Translation (NAT), because in IPv4 people use NAT to | |||
| address space is not needed in IPv6. The serious disadvantages of | accomplish that person's preferred task. This document will explain | |||
| ambiguous "private" address space and of Network Address Translation | why those pronouncements are false by showing how to accomplish the | |||
| (NAT) [1][5] have been well documented [4][6]. However, given its | task goal without address translation. Although there are many | |||
| wide market acceptance NAT undoubtedly has some perceived benefits. | perceived benefits to NAT, its primary benefit of "amplifying" | |||
| Indeed, in an Internet model based on universal any-to-any | available address space is not needed in IPv6. The serious | |||
| connectivity, product marketing departments have driven a perception | disadvantages and impact on applications by ambiguous address space | |||
| hat some connectivity and security concerns can only be solved by | and Network Address Translation [1] [5] have been well documented [4] | |||
| using a NAT device or by using logically separated Local Area Network | [6] so there will not be much additional discussion here. However, | |||
| (LAN) address spaces. This document describes the reasons for | given its wide deployment NAT undoubtedly has some perceived | |||
| utilizing a NAT device in an IPv4 environment that are regularly | benefits, though the bulk of those using it have not evaluated the | |||
| cited in marketing pronouncements. It then shows how these needs can | technical trade-offs. Indeed, product marketing departments have | |||
| be met without using NAT in an IPv6 network. Some of the IPv6 | effectively driven a perception that some connectivity and security | |||
| solutions offer advantages beyond the equivalent IPv4 NAT solution. | concerns can only be solved by using a NAT device, without any | |||
| The use of the facilities from IPv6 described in this document avoids | mention of the negative impacts on applications. This is amplified | |||
| the negative impacts of address translation. | through the widespread sharing of vendor best practice documents and | |||
| sample configurations that do not differentiate the translation | ||||
| function of address expansion from the state function of limiting | ||||
| connectivity. | ||||
| As far as security and privacy is concerned, this document considers | 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. It should be | ||||
| noted that this document is 'informational', as it discusses | ||||
| approaches that will work to accomplish the goals. It is | ||||
| specifically not a BCP that is recommending any one approach. | ||||
| As far as security and privacy are concerned, this document considers | ||||
| how to mitigate a number of threats. Some are obviously external, | how to mitigate a number of threats. Some are obviously external, | |||
| such as having a hacker trying to penetrate your network, or having a | such as having a hacker or a worm infected machine outside trying to | |||
| worm infected machine outside your network trying to attack it. Some | penetrate and attack the local network. Some are local such as a | |||
| are local such as a disgruntled employee disrupting business | disgruntled employee disrupting business operations, or the | |||
| operations, or the unintentional negligence of a user downloading | unintentional negligence of a user downloading some malware which | |||
| some malware which then proceeds to attack any device on the LAN. | then proceeds to attack from within. Some may be inherent in the | |||
| Some may be inherent in the device hardware ("embedded") such as | device hardware ("embedded") such as having some firmware in a | |||
| having some firmware in a domestic appliance "call home" to its | domestic appliance "call home" to its manufacturer without the user's | |||
| manufacturer without the user's consent. | consent. | |||
| This document describes several techniques that may be combined on an | Another consideration discussed is the view that NAT can be used to | |||
| IPv6 site to protect the integrity of its network architecture. | fulfill the goals of a security policy. At a technical level the | |||
| These techniques, known collectively as Network Architecture | translation process fundamentally can not produce security because | |||
| Protection (NAP), retain the concept of a well defined boundary | mangling the address in the header does not fulfill any useful | |||
| between "inside" and "outside" the private network, and allow | security functions; in fact it breaks the ability to produce an audit | |||
| firewalling, topology hiding, and privacy. NAP will achieve these | trail which is a fundamental security tool. That said, the artifacts | |||
| security goals without address translation whilst maintaining any-to- | of NAT devices do provide some value. | |||
| any connectivity. | 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 attached 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 | ||||
| IPv6 deployment to protect the integrity of its network architecture. | ||||
| It will focus on the 'how to accomplish 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 | IPv6 Network Architecture Protection can be summarized in the | |||
| following table. It presents the marketed "benefits" of NAT with a | following table. It presents the marketed "benefits" of IPv4+NAT | |||
| cross-reference of how those are delivered in both the IPv4 and IPv6 | with a cross-reference of how those are delivered in both the IPv4 | |||
| environments. | and IPv6 environments. | |||
| benefit IPv4 IPv6 | Goal IPv4 IPv6 | |||
| +------------------+-----------------------+-----------------------+ | +------------------+-----------------------+-----------------------+ | |||
| | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | | | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | | |||
| | as default router| address upstream | length customer | | | as default router| address upstream | length customer | | |||
| | 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 5, line 30 | skipping to change at page 6, line 30 | |||
| | tracking | | | | | tracking | | | | |||
| | | see section 2.3 | see section 4.3 | | | | see section 2.3 | see section 4.3 | | |||
| +------------------|-----------------------|-----------------------+ | +------------------|-----------------------|-----------------------+ | |||
| | End-system | NAT transforms | Temporary use | | | End-system | NAT transforms | Temporary use | | |||
| | privacy | device ID bits in | privacy addresses | | | privacy | device ID bits in | privacy addresses | | |||
| | | the address | | | | | the address | | | |||
| | | see section 2.4 | see section 4.4 | | | | see section 2.4 | see section 4.4 | | |||
| +------------------|-----------------------|-----------------------+ | +------------------|-----------------------|-----------------------+ | |||
| | Topology hiding | NAT transforms | Untraceable addresses| | | Topology hiding | NAT transforms | Untraceable addresses| | |||
| | | subnet bits in the | using IGP host routes| | | | subnet bits in the | using IGP host routes| | |||
| | | address | /or MIPv6 tunnels for| | | | address | /or MIPv6 tunnels | | |||
| | | | stationary systems | | ||||
| | | see section 2.4 | see section 4.4 | | | | see section 2.4 | see section 4.4 | | |||
| +------------------|-----------------------|-----------------------+ | +------------------|-----------------------|-----------------------+ | |||
| | Addressing | RFC 1918 | RFC 3177 & ULA | | | Addressing | RFC 1918 | RFC 3177 & 4193 | | |||
| | Autonomy | | | | | Autonomy | see section 2.5 | see section 4.5 | | |||
| | | see section 2.5 | see section 4.5 | | ||||
| +------------------|-----------------------|-----------------------+ | +------------------|-----------------------|-----------------------+ | |||
| | Global Address | RFC 1918 | 340,282,366,920,938, | | | Global Address | RFC 1918 | 17*10^18 subnets | | |||
| | Pool | | 463,463,374,607,431, | | | Pool | << 2^48 application | 3.4*10^38 addresses | | |||
| | Conservation | | 768,211,456 | | | Conservation | end points | full port list / addr | | |||
| | | | (3.4*10^38) addresses| | | | topology restricted | unrestricted topology | | |||
| | | 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 as extolled by product marketing. The goal of | of the use of IPv4 NAT. The goal of this description is not to | |||
| this description is not to analyze these benefits or discuss the | analyze these benefits or the accuracy of the perception (detailed | |||
| accuracy of the perception (detailed discussions in [4]), but to | discussions in [4]), but to describe the deployment requirements and | |||
| describe the deployment requirements and set a context for the later | set a context for the later descriptions of the IPv6 approaches for | |||
| descriptions of the IPv6 approaches for dealing with those | dealing with 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 any kind of address | A NAT device can connect a private network with addresses allocated | |||
| (ambiguous [RFC 1918] or global registered address) towards the | from any part of the space (ambiguous [RFC 1918] or global registered | |||
| Internet. The address space of the private network can be built from | & unregistered address) towards the Internet, though extra effort is | |||
| globally unique addresses, from ambiguous address space or from both | needed when the same range exists on both sides of the NAT. The | |||
| simultaneously. Without needing specific configuration, the NAT | address space of the private network can be built from globally | |||
| device enables access between the client side of a distributed | unique addresses, from ambiguous address space or from both | |||
| client-server application in the private network and the server side | simultaneously. In the simple case of private use addresses, without | |||
| in the public Internet. | 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 | Wide-scale deployments have shown that using NAT to act as a simple | |||
| IPv4 network to the Internet is simple and practical for the non- | gateway attaching a private IPv4 network to the Internet is simple | |||
| technical end user. Frequently a simple user interface, or even a | and practical for the non-technical end user. Frequently a simple | |||
| default configuration is sufficient for configuring both device and | user interface, or even a default configuration is sufficient for | |||
| application access rights. | configuring both device and application access rights. | |||
| Additionally, thanks to successful marketing campaigns it is | This simplicity comes at a price as the resulting topology puts | |||
| perceived by end users that their equipment is protected from the | restrictions on applications. The NAT simplicity works well when the | |||
| malicious entities and attackers on the public IPv4 Internet. | 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'. | ||||
| 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 host in general and on any | cannot exploit this state to attack a specific host on any other | |||
| port. This benefit may be partially real, however, experienced | port, though in the port overload case of NAPT attacking all active | |||
| hackers are well aware of NAT devices and are very familiar with | ports will impact a potentially wide number of hosts. This benefit | |||
| private address space, and have devised methods of attack (such as | may be partially real, however, experienced hackers are well aware of | |||
| trojan horses) that readily penetrate NAT boundaries. For these | NAT devices and are very familiar with private address space, and | |||
| reasons the sense of security provided by NAT is actually an | have devised methods of attack (such as trojan horses) that readily | |||
| illusion. | penetrate NAT boundaries. For these reasons the sense of security | |||
| provided by NAT is actually an illusion. | ||||
| Address translation does not provide security in itself; for example, | The act of address translation does not provide security in itself; | |||
| consider a configuration with static NAT translation and all inbound | for example, consider a configuration with static NAT translation and | |||
| ports translating to a single machine. In such a scenario the | all inbound ports translating to a single machine. In such a | |||
| security risk for that machine is identical to the case with no NAT | scenario the security risk for that machine is identical to the case | |||
| device in the communication path. As result there is no specific | with no NAT device in the communication path. As result there is no | |||
| security value in the address translation function. The perceived | specific security value in the address translation function. The | |||
| security comes from the lack of pre-established or permanent mapping | perceived security of NAT comes from the lack of pre- established or | |||
| state. Dynamically establishing state in response to internal | permanent mapping state. Dynamically establishing state in response | |||
| requests reduces the threat of unexpected external connections to | to internal requests reduces the threat of unexpected external | |||
| internal devices. | connections to internal devices. This role, often 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 this complexity shifts | more devices need to host the same application or otherwise use the | |||
| from difficult to impossible. | same public port this complexity shifts from difficult to impossible. | |||
| 2.3. User/Application tracking | 2.3. User/Application tracking | |||
| Although NATs create temporary state for active sessions, in general | One usage of NAT is for the local network administrator to track user | |||
| they provide limited capabilities for the administrator of the NAT to | and application traffic. Although NATs create temporary state for | |||
| gather information about who in the private network is requesting | active sessions, in general they provide limited capabilities for the | |||
| access to which Internet location. This could in theory be done by | administrator of the NAT to gather information about who in the | |||
| logging the network address translation details of the private and | private network is requesting access to which Internet location. | |||
| the public addresses from the NAT device's state database. | 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 checking of this database is not always a simple task, especially | The subsequent checking of this database is not always a simple task, | |||
| if Port Address Translation is used. It also has an unstated | especially if Port Address Translation is used. It also has an | |||
| assumption that the administrative instance has a mapping between an | unstated assumption that the administrative instance has a mapping | |||
| IPv4-address and a network element or user at all times, or the | between a private IPv4-address and a network element or user at all | |||
| administrator has a time-correlated list of the address/port | times, or the administrator has a time-correlated list of the | |||
| mappings. | address/port mappings. | |||
| 2.4. Privacy and Topology Hiding | 2.4. Privacy and Topology Hiding | |||
| The goal of 'topology hiding' is to provide devices on the private | One goal of 'topology hiding' is to prevent external entities from | |||
| network with an identifier (IPv4 address) which an entity outside the | making a correlation between the topological location of devices on | |||
| network can use to communicate with or to reference the private | the local network. The ability of NAT to provide Internet access to | |||
| network devices in protocols but prevents the external entity making | a large community of users by the use of a single (or a few) global | |||
| a correlation between the topological location of the private device | IPv4 routable addresses offers a simple mechanism to hide the | |||
| and the address on the local network. | internal topology of a network. In this scenario the large community | |||
| will be represented in the Internet by a single (or a few) IPv4 | ||||
| The ability of NAT to provide Internet access to a large community of | address(es). | |||
| 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 from the Internet as a user inside the NAT box itself; | |||
| the IPv4 address that appears on the Internet is only sufficient to | i.e., the IPv4 address that appears on the Internet is only | |||
| identify the NAT. When concealed behind a NAT it is impossible to | sufficient to identify the NAT so all internal nodes appear to exist | |||
| tell from the outside which member of a family, which customer of an | at the demarcation edge. When concealed behind a NAT it is | |||
| Internet cafe, or which employee of a company generated or received a | impossible to tell from the outside which member of a family, which | |||
| particular packet. Thus, although NATs do nothing to provide | customer of an Internet cafe, or which employee of a company | |||
| application level privacy, they do prevent the external tracking and | generated or received a particular packet. Thus, although NATs do | |||
| profiling of individual host computers by means of their IP | nothing to provide application level privacy, they do prevent the | |||
| addresses, usually known as 'device profiling'. At the same time a | external tracking and profiling of individual systems by means of | |||
| NAT creates a smaller pool of addresses for a much more focused point | their IP addresses, usually known as 'device profiling'. | |||
| of attack. | ||||
| 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 local network but can instead concentrate on the | ||||
| active ports associated with the NAT adress. By periodically | ||||
| scanning the limited 16 bit port range on the public side of the NAT, | ||||
| the attack will routinely find all 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 network managers prefer to hide as much as possible of their | |||
| network topology from outsiders. Mostly this is achieved by blocking | internal network topology from outsiders as a useful precaution to | |||
| "traceroute" etc., but NAT of course entirely hides the internal | mitigate scanning attacks. Mostly this is achieved by blocking | |||
| subnet topology, which some network managers believe is a useful | "traceroute" etc., though NAT entirely hides the internal subnet | |||
| precaution to mitigate scanning attacks. Scanning for IPv6 can be | topology. Scanning is a particular concern in IPv4 networks because | |||
| much harder in comparison with IPv4 as described in [18]. | the subnet size is small enough that once the topology is known it is | |||
| easy to find all the hosts, then start scanning them for vulnerable | ||||
| Once a list of available devices and IP addresses has been mapped, a | ports. Once a list of available devices has been mapped, a port-scan | |||
| port-scan on these IP addresses can be performed. Scanning works by | on these IP addresses can be performed. Scanning works by tracking | |||
| tracking which ports do not receive unreachable errors from either | which ports do not receive unreachable errors from either the | |||
| the firewall or host. With the list of open ports an attacker can | firewall or host. With the list of open ports an attacker can | |||
| optimize the time needed for a successful attack by correlating it | optimize the time needed for a successful attack by correlating it | |||
| with known vulnerabilities to reduce the number of attempts. For | with known vulnerabilities to reduce the number of attempts. For | |||
| example, FTP usually runs on port 21, and HTTP usually runs on port | example, FTP usually runs on port 21, and HTTP usually runs on port | |||
| 80. Any vulnerable open ports could be used for initiating attacks | 80. Any vulnerable open ports could be used for access to an end | |||
| on an end system. | system to command it to start initiating attacks on others. | |||
| 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 sufficiently large pool for a clean and | |||
| network. | hierarchical addressing structure in the local network. | |||
| Another benefit is due to the usage of independent addresses on | Another benefit is due to the usage of independent addresses on | |||
| majority of the network infrastructure there is an increased ability | majority of the network infrastructure there is an increased ability | |||
| to change provider with less operational difficulties. | to change provider with less operational difficulties. | |||
| Section 2.7 describes some disadvantages that appear if independent | Section 2.7 describes some disadvantages that appear if independent | |||
| networks using [RFC1918] addresses have to be merged. | networks using [RFC1918] addresses have to be merged. | |||
| 2.6. Global Address Pool Conservation | 2.6. Global Address Pool Conservation | |||
| Due to the ongoing depletion of the IPv4 address range, the remaining | While the widespread use of IPv4+NAT has reduced the potential | |||
| pool of unallocated IPv4 addresses is below 30%. While mathematical | consumption rate, the ongoing depletion of the IPv4 address range has | |||
| models based on historical IPv4 prefix consumption periodically | already taken the remaining pool of unallocated IPv4 addresses below | |||
| attempt to predict the future exhaustion date of the IPv4 address | 25%. While mathematical models based on historical IPv4 prefix | |||
| pool, a direct result of this continuous resource consumption is that | consumption periodically attempt to predict the future exhaustion | |||
| the administrative overhead for acquiring globally unique IPv4 | date of the IPv4 address pool, a direct result of this continuous | |||
| addresses will continue increasing in direct response to tightening | resource consumption is that the administrative overhead for | |||
| allocation policies. In response to the increasing administrative | acquiring globally unique IPv4 addresses will continue increasing in | |||
| overhead many Internet Service Providers (ISPs) have already resorted | direct response to tightening allocation policies. | |||
| to the ambiguous addresses defined in RFC 1918 behind a NAT for the | ||||
| various services they provide as well as connections for their end | In response to the increasing administrative overhead many Internet | |||
| customers. This happens even though that private address-space is | Service Providers (ISPs) have already resorted to the ambiguous | |||
| strictly limited in size. In turn this has restricted the number of | addresses defined in RFC 1918 behind a NAT for the various services | |||
| and types of applications that can be deployed by these ISPs and | they provide as well as connections for their end customers. This | |||
| their customers. Forced into this limiting situation such customers | happens even though the private use address-space is strictly limited | |||
| can rightly claim that despite the optimistic predictions of | in size. Some deployments have already outgrown that space and have | |||
| mathematical models the global pool of IPv4 addresses is effectively | begun cascading NAT to continue expanding, though this practice | |||
| already exhausted, especially for larger enterprises. | eventually breaks down over routing ambiguity. Additionally, while | |||
| we are unlikely to know the full extent of the practice (because it | ||||
| is hidden behind a nat), service providers have been known to | ||||
| announce previously unallocated public space to their customers (to | ||||
| avoid the problems associated with the same address space appearing | ||||
| on both sides), only to find that once that space was formally | ||||
| allocated and being publicly announced their customers couldn't reach | ||||
| the registered networks. | ||||
| 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 limit of this approach is something substantially less than 2^48 | ||||
| possible active **application** endpoints (approximately [2^32 minus | ||||
| 2^29] * [2* 2^16 minus well known port space]), as distinct from | ||||
| addressable devices each with their own application endpoint range. | ||||
| Those who advocate layering of NAT frequently forget to mention that | ||||
| there are topology restrictions placed on the applications. 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. | ||||
| 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, making a network multihomed is | quite different functions. However these are argued together as | |||
| often a transitional state required as part of network renumbering, | reasons for using NAT, because making a network multihomed is often a | |||
| and NAT interacts with both in the same way. | 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 | 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 | [15] and/or readily change its CIDR prefix. Unfortunately, IPv4 was | |||
| not designed to facilitate either of these maneuvers. However, if a | not designed to facilitate either of these maneuvers. However, if a | |||
| site is connected to its ISPs via NAT boxes, only those boxes need to | site is connected to its ISPs via NAT boxes, only those boxes need to | |||
| deal with multihoming and renumbering issues. | deal with multihoming and renumbering issues. | |||
| Similarly, if two enterprise IPv4 networks need to be merged and | Similarly, if two enterprise IPv4 networks need to be merged and | |||
| RFC1918 addresses are used, there is a high probability of address | RFC1918 addresses are used, there is a high probability of address | |||
| overlaps. In those situations it may well be that installing a NAT | overlaps. In those situations it may well be that installing a NAT | |||
| box between them will avoid the need to renumber one or both. For | box between them will avoid the need to renumber one or both. For | |||
| any enterprise, this can be a short term financial saving, and allow | any enterprise, this can be a short term financial saving, and allow | |||
| more time to renumber the network components. The long term solution | more time to renumber the network components. The long term solution | |||
| is a single network without usage of NAT to avoid the ongoing | is a single network without usage of NAT to avoid the ongoing | |||
| operational complexity of overlapping addresses. | operational complexity of overlapping addresses. | |||
| The addition of an extra NAT as a solution may be sufficient for some | The addition of an extra NAT as a solution may be sufficient for some | |||
| networks; however when the merging networks were already using | networks; however when the merging networks were already using | |||
| address translation it will create huge problems due to | address translation it will create huge problems due to | |||
| administrative difficulties of overlapping address speaces in the | administrative difficulties of overlapping address spaces in the | |||
| merged networks. | merged networks. | |||
| 3. Description of the IPv6 Tools | 3. Description of the IPv6 Tools | |||
| This section describes several features that can be used as part of | This section describes several features that can be used as part of | |||
| the NAP solution to emulate the protection features associated with | the NAP solution to replace the protection features associated with | |||
| IPv4 NAT. | IPv4 NAT. | |||
| The reader must clearly distinguish between features of IPv6 that | ||||
| were fully defined when this document was drafted and those that were | ||||
| potential features that still required more work to define them. The | ||||
| latter are summarized later in the 'Gap Analysis' section of this | ||||
| document. However, we do not distinguish in this document between | ||||
| fully defined features of IPv6 and those that were already widely | ||||
| implemented at the time of writing. | ||||
| 3.1. Privacy Addresses (RFC 3041) | 3.1. Privacy Addresses (RFC 3041) | |||
| There are situations where it is desirable to prevent device | There are situations where it is desirable to prevent device | |||
| profiling, for example by web sites that are accessed from the | profiling, for example by web sites that are accessed from the device | |||
| device; IPv6 privacy addresses were defined to provide that | as it moves around the Internet. IPv6 privacy addresses were defined | |||
| capability. IPv6 addresses consist of a routing prefix, subnet-id | to provide that capability. IPv6 addresses consist of a routing | |||
| part (SID) and an interface identifier part (IID). For interfaces | prefix, subnet-id part (SID) and an interface identifier part (IID). | |||
| that contain embedded IEEE Link Identifiers the interface identifier | As originally defined, IPv6 stateless address auto-configuration | |||
| is typically derived from it, though this practice facilitates | (SLAAC) will typically embed the IEEE Link Identifier of the | |||
| tracking and profiling of a device as it moves around the Internet. | interface as the IID part, though this practice facilitates tracking | |||
| RFC 3041 describes an extension to IPv6 stateless address | and profiling of a device through the consistent IID. RFC 3041 [7] | |||
| autoconfiguration (SLAAC) for interfaces [7]. Use of the privacy | describes an extension to SLAAC to enhance device privacy. Use of | |||
| address extension causes nodes to generate global-scope addresses | the privacy address extension causes nodes to generate global-scope | |||
| from interface identifiers that change over time, even in cases where | addresses from interface identifiers that change over time, | |||
| the interface contains an embedded IEEE link identifier. Changing | consistent with system administrator policy. Changing the interface | |||
| the interface identifier (thus the global-scope addresses generated | identifier (thus the global-scope addresses generated from it) over | |||
| from it) over time makes it more difficult for eavesdroppers and | time makes it more difficult for eavesdroppers and other information | |||
| other information collectors to identify when addresses used in | collectors to identify when addresses used in different transactions | |||
| different transactions actually correspond to the same node. A | actually correspond to the same node. A relatively short valid | |||
| relatively short valid lifetime for the privacy address also has the | lifetime for the privacy address also has the side effect of reducing | |||
| side effect of reducing the attack profile of a device, as it is not | the attack profile of a device, as it is not directly attackable once | |||
| directly attackable once it stops answering at the temporary use | 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 auto- | |||
| autoconfiguration, there is nothing that prevents a DHCP server from | configuration, there is nothing that prevents a DHCP server from | |||
| running the RFC 3041 algorithm for any new IEEE identifier it hears, | running the RFC 3041 algorithm for any new IEEE identifier it hears | |||
| then remembering that for future queries. This would allow using | in a request, then remembering that for future queries. This would | |||
| them in DNS for registered services since the assumption of a server | allow using them in DNS for registered services since the assumption | |||
| based deployment would be a persistent value that minimizes DNS | of a DHCP server based deployment would be a persistent value that | |||
| churn. A DHCP based deployment would also allow for local policy to | minimizes DNS churn. A DHCP based deployment would also allow for | |||
| periodically change the entire collection of end device addresses | local policy to periodically change the entire collection of end | |||
| while maintaining some degree of central knowledge and control over | device addresses while maintaining some degree of central knowledge | |||
| which addresses should be in use at any point in time. | and control over which addresses should be in use at any point in | |||
| time. | ||||
| Randomizing the IID, as defined in RFC 3041, only precludes tracking | Randomizing the IID, as defined in RFC 3041, is effectively a sparse | |||
| of the lower 64 bits of the IPv6 address. Masking of the subnet ID | allocation technique which only precludes tracking of the lower 64 | |||
| will require additional approaches as discussed below in 3.4. | bits of the IPv6 address. Masking of the subnet ID will require | |||
| Additional considerations are discussed in [17]. | additional approaches as discussed below in 3.4. Additional | |||
| considerations are discussed in [18]. | ||||
| 3.2. Unique Local Addresses | 3.2. Unique Local Addresses | |||
| Local network and application services stability during periods of | Achieving the goal of autonomy, that many perceive as a value of NAT, | |||
| intermittent connectivity between one or more providers requires | is required for local network and application services stability | |||
| address management autonomy. Such autonomy in a single routing | during periods of intermittent connectivity or moving between one or | |||
| prefix environment would lead to massive expansion of the global | more providers. Such autonomy in a single routing prefix environment | |||
| routing tables, so IPv6 provides for simultaneous use of multiple | would lead to massive expansion of the global routing tables (as seen | |||
| prefixes. The Unique Local Address prefix (ULA) [13] has been set | in IPv4), so IPv6 provides for simultaneous use of multiple prefixes. | |||
| aside for use in local communications. The ULA address prefix for | The Unique Local Address prefix (ULA) [14] has been set aside for use | |||
| any network is routable over a locally defined collection of routers. | in local communications. The ULA address prefix for any network is | |||
| These prefixes are not intended to be routed on the public global | routable over a locally defined collection of routers. These | |||
| Internet; large scale inter-domain distribution of routes to ULA | prefixes are not intended to be routed on the public global Internet | |||
| prefixes would have a negative impact on global route aggregation. | 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: | ULAs have the following characteristics: | |||
| o Globally unique prefix | o For all practical purposes a globally unique prefix | |||
| * Allows networks to be combined or privately interconnected | * Allows networks to be combined or privately interconnected | |||
| without creating any address conflicts or requiring renumbering | without creating address conflicts or requiring renumbering of | |||
| of interfaces using these prefixes | 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 intermittent Internet | network without having any permanent or only intermittent Internet | |||
| connectivity | connectivity | |||
| o Well-known prefix to allow for easy filtering at network | o Well-known prefix to allow for easy filtering at network | |||
| boundaries 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 need to | scoped addresses but address selection algorithms may need to | |||
| distinguish between ULAs and ordinary global scope unicast | distinguish between ULAs and ordinary global scope unicast | |||
| addresses. Mixing the two kinds of addresses is likely to lead to | addresses to assure stability. The policy table defined in [10] | |||
| undeliverable packets. | 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 | 3.3. DHCPv6 Prefix Delegation | |||
| The Prefix Delegation (DHCP-PD) options [11] provide a mechanism for | One of the functions of a simple gateway is managing the local use | |||
| automated delegation of IPv6 prefixes using the Dynamic Host | address range. The Prefix Delegation (DHCP-PD) options [11] provide | |||
| Configuration Protocol (DHCP) [9]. This mechanism (DHCP-PD) is | a mechanism for automated delegation of IPv6 prefixes using the | |||
| intended for delegating a long-lived prefix from a delegating router | Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism | |||
| (incorporating a DHCPv6 server) to a requesting router, possibly | (DHCP-PD) is intended for delegating a long-lived prefix from a | |||
| across an administrative boundary, where the delegating router does | delegating router (possibly incorporating a DHCPv6 server) to a | |||
| not require knowledge about the topology of the links in the network | requesting router, possibly across an administrative boundary, where | |||
| to which the prefixes will be assigned. | 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 | 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 could have a default | address management. A basic IPv6 router should have a default | |||
| configuration to advertise inside the site a locally generated random | configuration to advertise inside the site a locally generated random | |||
| ULA prefix, independently from the state of any external | ULA prefix, independently from the state of any external | |||
| connectivity. This would allow local nodes to communicate amongst | connectivity. This would allow local nodes to communicate amongst | |||
| themselves prior to establishing a global connection. If the network | themselves independent of the state of a global connection. If the | |||
| happened to concatenate with another local network, this is highly | network happened to concatenate with another local network, the | |||
| unlikely to result in address collisions. A more secure network | randomness in ULA creation is highly unlikely to result in address | |||
| environment can be established by having the referenced ULA addresses | collisions. | |||
| 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 could also use DHCP-PD | With external connectivity the simple gateway should use DHCP-PD to | |||
| to acquire a routing prefix from the service provider for use when | acquire a routing prefix from the service provider for use when | |||
| connecting to the global Internet. End-system connections involving | connecting to the global Internet. End-system connections involving | |||
| other nodes on the global Internet will always use the global IPv6 | other nodes on the global Internet will always use the global IPv6 | |||
| addresses [9] derived from this prefix delegation. It should be | addresses derived from this prefix delegation. It should be noted | |||
| noted that the address selection policy table in end-systems needs to | that the address selection policy table in end-systems defined in RFC | |||
| be correctly set up so that true global prefixes are distinguished | 3484 should be configured to prefer the ULA prefix range over the | |||
| from ULAs and will be used for the source address in preference when | DHCP-PD prefix range when the goal is to keep local communications | |||
| the destination is not a ULA. | stable during periods of transient external connectivity. | |||
| In the very simple case there is no explicit routing protocol and a | In the very simple case there is no explicit routing protocol on | |||
| single default route is used out to the global Internet. A slightly | either side of the gateway, and a single default route is used | |||
| more complex case might involve local routing protocols, but with the | internally pointing out to the global Internet. A slightly more | |||
| entire local network sharing a common global prefix there would still | complex case might involve local internal routing protocols, but with | |||
| not be a need for an external routing protocol as a default route | the entire local network sharing a common global prefix there would | |||
| would continue to be consistent with the connectivity. | still not be a need for an external routing protocol as the service | |||
| provider could install a route for the prefix delegated via DHCP-PD | ||||
| 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. A proxy may be | Intrusion Detection Systems (IDS) is recommended for those that want | |||
| boundary protection in addition to host defenses. A proxy may be | ||||
| used for certain applications, but with the caveat that the end to | used for certain applications, but with the caveat that the end to | |||
| end transparancy is broken. However, with IPv6, the following | end transparency is broken. However, with IPv6, the following | |||
| protections are available without the use of NAT while maintaining | protections are available without the use of NAT while maintaining | |||
| end-to-end reachability: | end-to-end reachability: | |||
| 1. Short lifetimes on privacy extension suffixes reduce the attack | 1. Short lifetimes on privacy extension suffixes reduce the attack | |||
| profile since the node will not respond to the address once the | profile since the node will not respond to the address once its | |||
| address is no longer valid. | lifetime becomes invalid. | |||
| 2. IPsec is a mandatory service for IPv6 implementations. IPsec | 2. IPsec is a mandatory service for IPv6 implementations. IPsec | |||
| functions to prevent session hijacking, prevent content | functions to authenticate the correspondent, prevent session | |||
| tampering, and optionally masks the packet contents. While IPsec | hijacking, prevent content tampering, and optionally masks the | |||
| might be available in IPv4 implementations, deployment in NAT | packet contents. While IPsec might be available in IPv4 | |||
| implementations and works the same way, deployment in NAT | ||||
| environments either breaks the protocol or requires complex | environments either breaks the protocol or requires complex | |||
| helper services with limited functionality or efficiency. | helper services with limited functionality or efficiency. | |||
| 3. The size of the 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 an effective network ping sweep and resulting | IID) will make a complete subnet ping sweep virtually impossible | |||
| port-scan virtually impossible due to the number of possible | due to the potential number of combinations available. Reducing | |||
| combinations available, provided that IIDs are essentially | the security threat of port scans on identified nodes requires | |||
| randomly distributed across the available space. This protection | sparse distribution within the subnet to minimize the probability | |||
| is nullified if the attacker has no access to a local connection. | of scans finding adjacent nodes. Provided that IIDs are | |||
| If an attacker has local access then he could use ND [3] and | essentially randomly distributed across the available space, | |||
| ping6 to ff02::1 to detect local neighbors. (Of course, a | address scanning based attacks will effectively fail. This | |||
| locally connected attacker has many scanning options with IPv4 as | protection exists if the attacker has no direct access to the | |||
| well.) It is recommended for site administrators to take [18] | specific subnet and therefore is trying to scan it remotely. If | |||
| into consideration to achieve the expected goal. This protection | an attacker has local access then he could use ND [3] and ping6 | |||
| will also be nullified if IIDs are configured in a group near the | to the link-scope multicast ff02::1 to detect the IEEE based | |||
| start of the IID space. | address of local neighbors, then apply the global prefix to those | |||
| to simplify its search (of course, a locally connected attacker | ||||
| has many scanning options with IPv4 as well). This scanning | ||||
| protection will be nullified if IIDs are configured in any | ||||
| structured groupings within the IID space. | ||||
| Assuming the network administrator is aware of [19] 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 full-duplex 40Gbps (400 times the typical | ||||
| 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it | ||||
| takes over 5000 years to scan the entirety of a single 64 bit subnet. | ||||
| 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 do | practices will avoid this kind of illusory security but can only | |||
| this if correctly configured firewalls and IDS systems are used at | address the same threats if correctly configured firewalls and IDS | |||
| the perimeter where some IPv4 networks have relied on NATs. | systems are used at the perimeter. | |||
| 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 which provides a minimum set of connectivity | default configuration where incoming traffic is limited to return | |||
| for users in the home network (e.g., just to external HTTP servers) | traffic resulting from outgoing packets (sometimes known as | |||
| with incoming traffic limited to return traffic resulting from | reflective session state). There should also be an easy interface | |||
| outgoing packets (sometimes known as reflective session state) with | which allows users to create inbound 'pinholes' for specific purposes | |||
| an easy interface which allows users to create additional 'pinholes' | such as online-gaming. Another consideration would be the capability | |||
| for specific purposes. | for service provider mediated pinhole management where things like | |||
| voice call signaling could dynamically establish pinholes based on | ||||
| predefined authentication 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 without increasing | |||
| the perceived complexity for users who just want to accomplish a | ||||
| Assuming the network administrator is aware of [18] the increased | task. | |||
| 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 correlating 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. | |||
| Exactly as with IPv4 NAT, this only allows such a session to be | This only allows such a session to be traced back to the subnet that | |||
| traced back to the subnet that originates it, but not immediately to | originates it, but not immediately to the actual host, where IPv4 NAT | |||
| the actual host. | is only traceable to the most public NAT interface. | |||
| Due to the large IPv6 address space available there is plenty of | Due to the large IPv6 address space available there is plenty of | |||
| freedom to randomize subnet allocations. By doing this, it is | freedom to randomize subnet allocations. By doing this, it is | |||
| possible to reduce the correlation between a subnet and its location. | possible to reduce the correlation between a subnet and its location. | |||
| When doing both subnet and IID randomization [RFC 3041] a casual | When doing both subnet and IID randomization [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. | hiding, with the cost being a more complex internal routing | |||
| configuration. | ||||
| In the case where a network administrator wishes to fully conceal the | As discussed in Section 3.1, there are multiple parts to the IPv6 | |||
| internal IPv6 topology, and the majority of its host computer | address, and different techniques to manage privacy for each which | |||
| addresses, a possible option is to run all internal traffic using | may be combined to protect the entire address. In the case where a | |||
| Unique Local Addresses (ULA) since such packets can by definition | network administrator wishes to fully isolate the internal IPv6 | |||
| never exit the site. For hosts that do in fact need to generate | topology, and the majority of its internal use addresses, one option | |||
| external traffic, by using multiple IPv6 addresses (ULAs and one or | is to run all internal traffic using Unique Local Addresses (ULA). | |||
| more global addresses), it will be possible to hide and mask some or | By definition this prefix block is not to be advertised into the | |||
| all of the internal network. As discussed in Section 3.1, there are | public routing system, so without a routing path external traffic | |||
| multiple parts to the IPv6 address, and different techniques to | will never reach the site. For the set of hosts that do in fact need | |||
| manage privacy for each. | to interact externally, by using multiple IPv6 prefixes (ULAs and one | |||
| or more global addresses) all of the internal nodes that do not need | ||||
| external connectivity, and the internally used addresses of those | ||||
| that do will be masked from the outside. The policy table defined in | ||||
| [10] provides a mechanism to bias the selection process when multiple | ||||
| prefixes are in use such that the ULA would be preferred when the | ||||
| correspondent is also local. | ||||
| There are two possible scenarios for the extreme situation when a | There are other scenarios for the extreme situation when a network | |||
| network manager also wishes to fully conceal the internal IPv6 | manager also wishes to fully conceal the internal IPv6 topology. In | |||
| topology. | these cases the goal in replacing the IPv4 NAT approach is to make | |||
| all of the topology hidden nodes appear from the outside to logically | ||||
| exist at the edge of the network, just as they would when behind a | ||||
| NAT. | ||||
| o One could use explicit host routes and remove the correlation | o One approach uses explicit host routes in the IGP to remove the | |||
| between location and IPv6 address. This solution does however | external correlation between physical topology attachment point | |||
| show severe scalability issues. | and end-to-end IPv6 address. In the figure below the hosts would | |||
| o The other technology to fully hide the internal topology would be | be allocated prefixes from one or more logical subnets, and would | |||
| to use a tunneling mechanism. Mobile IPv6 without route | inject host routes to internally identify their real attachment | |||
| optimization is one example. In this example the public facing | point. This solution does however show severe scalability issues | |||
| addresses are indirected via an edge Home Agent (HA). This | and requires hosts to participate in the IGP, as well as having | |||
| indirection method truly masks the internal topology as all nodes | the firewall block all external to internal traceroute for the | |||
| with global access appear to share a common prefix. The downside | logical subnet. The specific limitations are dependent on the IGP | |||
| of using this method is that it makes usage of middleware like a | protocol, the physical topology, and the stability of the system. | |||
| Home Agent (HA). | In any case the approach should be limited to uses with | |||
| substantially fewer than the maximum number of routes that the IGP | ||||
| can support (generally between 5,000 and 50,000 total entries | ||||
| including subnet routes). | ||||
| o Another technical approach to fully hide the internal topology is | ||||
| use of a tunneling mechanism. Mobile IPv6 without route | ||||
| optimization is one approach for using an automated tunnel, as it | ||||
| always starts in tunnel mode via the Home Agent (HA). In this | ||||
| deployment model the application perceived addresses of the nodes | ||||
| are routed via the edge HA. This indirection method truly masks | ||||
| the internal topology, as from outside the local network all nodes | ||||
| with global access appear to share the prefix of one or more | ||||
| logical subnets attached to the HA rather than their real | ||||
| attachment point. 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 using the home | ||||
| address to route via the HA tunnel, which may be undesirable. A | ||||
| more efficient method would be to allow internal route | ||||
| optimizations while dropping outbound binding updates at the | ||||
| firewall. Another approach for the internal routes would be to | ||||
| use the policy table of RFC 3484 to bias a ULA prefix as preferred | ||||
| internally, leaving the Home Address external for use. The | ||||
| downsides of using the MIPv6 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) uses 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 |-+-+-+-+-+-+-+-+-- | ||||
| | or Home Agent | Logical subnets | ||||
| | |-+-+-+-+-+-+-+-+-- | ||||
| +------------------+ 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. Nodes that need access to the public Internet | the public Internet because nodes that need access to the public | |||
| may have a ULA for local use, and will have a global use address | Internet will have a global use address as well. When using IPv6, | |||
| because the global use IPv6 address space is not a scarce resource | the need to ask for more address space will become far less likely | |||
| like the global use IPv4 space. While global IPv6 allocation policy | due to the increased size of the subnets, along with an allocation | |||
| is managed through the Regional Internet Registries, it is expected | policy that recognizes table fragmentation is also an important | |||
| that they will continue with derivatives of [RFC 3177] for the | consideration. While global IPv6 allocation policy is managed | |||
| foreseeable future. | through the Regional Internet Registries, it is expected that they | |||
| will continue with derivatives of [8] for the foreseeable future so | ||||
| When using IPv6, the need to ask for more address space will become | the number of subnet prefixes available to an organization should not | |||
| far less likely due to the increased size of the subnets. These | be a limitation which would create an artificial demand for NAT. | |||
| 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 | Ongoing subnet address maintenance may become simpler when IPv6 | |||
| technology is utilised. If IPv4 address space is optimised one has | technology is utilized. Under IPv4 address space policy restrictions | |||
| to look periodically into the number of hosts on a segment and the | each subnet must be optimized, so one has to look periodically into | |||
| subnet size allocated to the segment; an enterprise today may have a | the number of hosts on a segment and the subnet size allocated to the | |||
| mix of /28 - /23 size subnets for example, and may shrink/grow these | segment and rebalance. For example an enterprise today may have a | |||
| as their network user base changes. For IPv6 all subnets have /64 | mix of IPv4 /28 - /23 size subnets, and may shrink/grow these as | |||
| prefixes. | their network user base changes. For IPv6 all 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, | overlapping address space. Since allocations in IPv6 are based on | |||
| 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total | subnets rather than hosts a reasonable way to look at the pool is | |||
| possible addresses. As previously discussed, the serious | that there are about 17*10^18 unique subnet values where sparse | |||
| allocation practice within those provides for new opportunities such | ||||
| as SEND 3971 [12]. As previously discussed, the serious | ||||
| disadvantages of ambiguous address space have been well documented, | disadvantages of ambiguous address space have been well documented, | |||
| and with sufficient space there is no need to continue the | and with sufficient space there is no need to continue the | |||
| increasingly aggressive conservation practices that are necessary | increasingly aggressive conservation practices that are necessary | |||
| with IPv4. While IPv6 allocation policies and ISP business practice | with IPv4. While IPv6 allocation policies and ISP business practice | |||
| will continue to evolve, the recommendations in RFC 3177 are based on | will continue to evolve, the recommendations in RFC 3177 are based on | |||
| the technical potential of the vast IPv6 address space. That | the technical potential of the vast IPv6 address space. That | |||
| document demonstrates that there is no resource limitation which will | document demonstrates that there is no resource limitation which will | |||
| require the adoption of the IPv4 workaround of ambiguous space behind | require the adoption of the IPv4 workaround of ambiguous space behind | |||
| a NAT. As an example of the direct contrast, many expansion oriented | a NAT. As an example of the direct contrast, many expansion oriented | |||
| IPv6 deployment scenarios result in multiple IPv6 addresses per | IPv6 deployment scenarios result in multiple IPv6 addresses per | |||
| device, as opposed to the constriction of IPv4 scenarios where | device, as opposed to the constriction of IPv4 scenarios where | |||
| multiple devices are forced to share a scarce global address. | 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-like prefixes | sites and hosts to run with several simultaneous CIDR allocated | |||
| and thus with several simultaneous ISPs. An address selection | prefixes, and thus with several simultaneous ISPs. An address | |||
| mechanism [10] is specified so that hosts will behave consistently | selection mechanism [10] is specified so that hosts will behave | |||
| when several addresses are simultaneously valid. The fundamental | consistently when several addresses are simultaneously valid. The | |||
| difficulty that IPv4 has in this regard therefore does not apply to | fundamental difficulty that IPv4 has in regard to multiple addresses | |||
| IPv6. IPv6 sites can and do run today with multiple ISPs active, and | therefore does not apply to IPv6. IPv6 sites can and do run today | |||
| the processes for adding and removing active prefixes at a site have | with multiple ISPs active, and the processes for adding, removing, | |||
| been documented [12] and [19]. | and renumbering active prefixes at a site have been documented in | |||
| [13] and [20]. | ||||
| The IPv6 address space allocated by the ISP will be dependent upon | The IPv6 address space allocated by the ISP will be dependent upon | |||
| the connecting Service provider. This may result in a renumbering | the connecting Service provider. This will likely result in a | |||
| effort if the network changes from Service Provider. When changing | renumbering effort when the network changes between service | |||
| ISPs or ISPs readjusting their addressing pool, DHCP-PD [11] can be | providers. When changing ISPs or ISPs readjusting their addressing | |||
| used as an almost zero-touch external mechanism for prefix change in | pool, DHCP-PD [11] can be used as an almost zero- touch external | |||
| conjunction with a ULA prefix for internal connection stability. | mechanism for prefix change in conjunction with a ULA prefix for | |||
| With appropriate management of the lifetime values and overlap of the | internal connection stability. With appropriate management of the | |||
| external prefixes, a smooth make-before-break transition is possible | lifetime values and overlap of the external prefixes, a smooth make- | |||
| as existing communications will continue on the old prefix as long as | before-break transition is possible as existing communications will | |||
| it remains valid, while any new communications will use the new | continue on the old prefix as long as it remains valid, while any new | |||
| prefix. | communications will use the new 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 of these category of networks we | of connected end hosts. For each category of networks we can use | |||
| can use IPv6 Network Architecture Protection to achieve a secure and | IPv6 Network Architecture Protection to achieve a secure and flexible | |||
| flexible infrastructure, which provides an enhanced network | infrastructure, which provides an enhanced network functionality in | |||
| functionality in comparison with the usage of address translation. | 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, academic, research, or government | |||
| Many of these networks have one or more exit points to the Internet. | networks fall into this category. Many of these networks have one or | |||
| Though these organizations have sufficient resources to acquire | more exit points to the Internet. Though these organizations have | |||
| addressing independence when using IPv4 there are several reasons why | sufficient resources to acquire addressing independence when using | |||
| they might choose to use NAT in such a network. For the ISP there is | IPv4 there are several reasons why they might choose to use NAT in | |||
| no need to import the IPv4 address range from the remote end- | such a network. For the ISP there is no need to import the IPv4 | |||
| customer, which facilitates IPv4 route summarization. The customer | address range from the remote end-customer, which facilitates IPv4 | |||
| can use a larger IPv4 address range (probably with less- | route summarization. The customer can use a larger IPv4 address | |||
| administrative overhead) by the use of RFC 1918 and NAT. The | range (probably with less-administrative overhead) by the use of RFC | |||
| customer also reduces the overhead in changing to a new ISP, because | 1918 and NAT. The customer also reduces the overhead in changing to | |||
| the addresses assigned to devices behind the NAT do not need to be | a new ISP, because the addresses assigned to devices behind the NAT | |||
| changed when the customer is assigned a different address by a new | do not need to be changed when the customer is assigned a different | |||
| ISP. By using address translation one avoids the need for network | address by a new ISP. By using address translation in IPv4 one | |||
| renumbering. Finally, the customer can provide privacy for its hosts | avoids the expensive process of network renumbering. Finally, the | |||
| and the topology of its internal network if the internal addresses | customer can provide privacy for its hosts and the topology of its | |||
| are mapped through NAT. | internal network if the internal addresses are mapped through NAT. | |||
| It is expected that there will be enough IPv6 addresses available for | It is expected that there will be enough IPv6 addresses available for | |||
| all networks and appliances for the foreseeable future. The basic | all networks and appliances for the foreseeable future. The basic | |||
| IPv6 address range an ISP allocates for a private network is large | IPv6 address range an ISP allocates for a private network is large | |||
| enough (currently /48) for most of the medium and large enterprises, | enough (currently /48) for most of the medium and large enterprises, | |||
| while for the very large private enterprise networks address-ranges | while for the very large private enterprise networks address-ranges | |||
| can be concatenated. A single /48 allocation provides an enterprise | can be concatenated. The goal of this assignment mechanism is to | |||
| network with 65536 different /64 prefixes. | decrease the total amount of entries in the public Internet routing | |||
| table. A single /48 allocation provides an enterprise network with | ||||
| The summarization benefit for the ISP results from the IPv6 | 65536 different /64 subnet prefixes. | |||
| 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 factor to the host part of an IPv6 address | extensions add a random time-limited factor to the host part of an | |||
| and will make it very hard for an external element to keep | IPv6 address and will make it very hard for an external element to | |||
| correlating the IPv6 address to a host on the inside network. The | keep correlating the IPv6 address to a specific host on the inside | |||
| usage of IPv6 privacy extensions does not mask the internal network | network. The usage of IPv6 privacy extensions does not mask the | |||
| structure of an enterprise network. | internal network structure of an enterprise network. | |||
| If there is need to mask the internal structure towards the external | When there is need to mask the internal structure towards the | |||
| IPv6 internet, then some form of 'untraceable' addresses may be used. | external IPv6 Internet, then some form of 'untraceable' addresses may | |||
| These addresses will be derived from a local pool, and may be | be used. These addresses will appear to exist at the external edge | |||
| assigned to those hosts for which topology masking is required or | of the network, and may be assigned to those hosts for which topology | |||
| which want to reach the IPv6 Internet or other external networks. | masking is required or which want to reach the IPv6 Internet or other | |||
| The technology to assign these addresses to the hosts could be based | external networks. The technology to assign these addresses to the | |||
| on DHCPv6. To complement the 'Untraceable' addresses it is needed to | hosts could be based on DHCPv6 or static configuration. To | |||
| have at least awareness of the IPv6 address location when routing an | complement the 'Untraceable' addresses it is needed to have at least | |||
| IPv6 packet through the internal network. This could be achieved by | awareness of the IPv6 address location when routing an IPv6 packet | |||
| 'route-injection' in the network infrastructure. This route- | through the internal network. This could be achieved by 'host based | |||
| route- injection' in the local network infrastructure. This route- | ||||
| injection could be done based on /128 host-routes to each device that | injection could be done based on /128 host-routes to each device that | |||
| wants to connect to the Internet using an untraceable address. This | wants to connect to the Internet using an untraceable address. This | |||
| will provide the most dynamic masking, but will have a scalability | will provide the most dynamic masking, but will have a scalability | |||
| limitation, as an IGP is typically not designed to carry many | limitation, as an IGP is typically not designed to carry many | |||
| thousands of IPv6 prefixes. A large enterprise may have thousands of | thousands of IPv6 prefixes. A large enterprise may have thousands of | |||
| hosts willing to connect to the Internet. Less flexible masking | hosts willing to connect to 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 | ||||
| factor, but has as trade-off that masking is time and subnet based. | ||||
| The dynamic allocation of 'Untraceable' addresses can also limit the | An alternative for larger deployments is to leverage the tunneling | |||
| IPv6 access between local and external hosts to those local hosts | aspect of MIPv6 even for non-mobile devices. With the logical subnet | |||
| being authorized for this capability. Dynamically allocated | being allocated as attached to the edge Home Agent, the real | |||
| 'Untraceable' addresses may also facilitate and simplify the | attachment and internal topology are masked from the outside. | |||
| connectivity to the outside networks during renumbering, because the | Dropping outbound binding updates at the firewall is also necessary | |||
| existing IPv6 central address pool could be swapped for the newly | to avoid leaking the attachment information. | |||
| allocated IPv6 address pool. | ||||
| 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 which will complicate auditing systems. 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. | ||||
| 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 20, line 40 | skipping to change at page 24, line 22 | |||
| 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 a server, | sufficient technical knowledge to manage the NAT to enable external | |||
| only one server of any given protocol type is possible per address, | access to a server, only one server can be mapped per protocol/ | |||
| and then only when the address from the ISP is public. | port-number per address, and then only when the address from the ISP | |||
| is publicly routed. 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 21, line 29 | skipping to change at page 25, line 15 | |||
| 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 if the single device | available at essentially the same cost. Also it will be likely that | |||
| wants to mask its identity to the called party or its attack profile | the single device wants to mask its identity to the called party or | |||
| over a short time window it will need to enable IPv6 privacy | its attack profile over a shorter time window than the life of the | |||
| extensions, which in turn leads to the need for a minimum allocation | ISP attachment, so it will need to enable IPv6 privacy extensions | |||
| of a /64 prefix rather than a single address. | 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 | 5.3. Single User Connection | |||
| This group identifies the users which are connected via a single IPv4 | This group identifies the users which are connected via a single IPv4 | |||
| address and use a single piece of equipment (PC, PDA, etc.). This | address and use a single piece of equipment (PC, PDA, etc.). This | |||
| user may get an ambiguous IPv4 address (frequently imposed by the | user may get an ambiguous IPv4 address (frequently imposed by the | |||
| ISP) from the service provider which is based on RFC 1918. If | ISP) from the service provider which is based on RFC 1918. If | |||
| ambiguous addressing is utilized, the service provider will execute | ambiguous addressing is utilized, the service provider will execute | |||
| NAT on the allocated IPv4 address for global Internet connectivity. | NAT on the allocated IPv4 address for global Internet connectivity. | |||
| This also limits the internet capability of the equipment to being | This also limits the Internet capability of the equipment to being | |||
| mainly a receiver of Internet data, and makes it quite hard for the | mainly a receiver of Internet data, and makes it quite hard for the | |||
| equipment to become a world wide internet server (i.e. HTTP, FTP, | equipment to become a world wide Internet server (i.e. HTTP, FTP, | |||
| etc.) due to the stateful operation of the NAT equipment. | etc.) due to the stateful operation of the NAT equipment. | |||
| When using IPv6 NAP, this group will identify the users which are | When using IPv6 NAP, this group will identify the users which are | |||
| connected via a single IPv6 address and use a single piece of | connected via a single IPv6 address and use a single piece of | |||
| equipment (PC, PDA, etc.). | equipment (PC, PDA, etc.). | |||
| In IPv6 world the assumption is that there is unrestricted | In IPv6 world the assumption is that there is unrestricted | |||
| availability of a large amount of globally routable and unique IPv6 | availability of a large amount of globally routable and unique IPv6 | |||
| addresses. The ISP will not be motivated to allocate private | addresses. The ISP will not be motivated to allocate private | |||
| addresses towards the single user connection because he has enough | addresses towards the single user connection because he has enough | |||
| global addresses available, if scarcity was the motivation with IPv4 | global addresses available, if scarcity was the motivation with IPv4 | |||
| to provide RFC 1918 addresses. If the single user wants to mask his | to provide RFC 1918 addresses. If the single user wants to mask his | |||
| identity, he may choose to enable IPv6 privacy extensions. | identity, he may choose to enable IPv6 privacy extensions. | |||
| 5.4. ISP/Carrier Customer Networks | 5.4. ISP/Carrier Customer Networks | |||
| This group refers to the actual service providers that are providing | This group refers to the actual service providers that are providing | |||
| the IPv4 access and transport services. They tend to have three | the IP access and transport services. They tend to have three | |||
| separate IPv4 domains that they support: | separate IP domains that they support: | |||
| o For the first they fall into the Medium/large private networks | o For the first they fall into the Medium/large private networks | |||
| category (above) for their own internal networks, LANs etc. | category (above) for their own internal networks, LANs etc. | |||
| o The second is the Operations network which addresses their | o The second is the Operations network which addresses their | |||
| backbone and access switches, and other hardware, this is separate | backbone and access switches, and other hardware, this is separate | |||
| for both engineering reasons as well as simplicity in managing the | for both engineering reasons as well as simplicity in managing the | |||
| security of the backbone. | security of the backbone. | |||
| o The third is the IP addresses (single or blocks) that they assign | o The third is the IP addresses (single or blocks) that they assign | |||
| to customers. These can be registered addresses (usually given to | to customers. These can be registered addresses (usually given to | |||
| category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of | category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of | |||
| RFC 1918 addresses used with NAT for single user connections. | RFC 1918 addresses used with IPv4 NAT for single user connections. | |||
| Therefore they can actually have two different NAT domains that | Therefore they can actually have two different NAT domains that | |||
| are not connected (internal LAN and single user customers). | are not connected (internal LAN and single user customers). | |||
| When IPv6 NAP is utilized in these three domains then for the first | When IPv6 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 in preference to ULA addresses. | Independent addresses can be used. This would give a solid and | |||
| This would give a solid and scalable configuration with respect to a | scalable configuration with respect to a local IPv6 address plan. By | |||
| local IPv6 address plan. By the usage of proper network edge | the usage of proper network edge filters, outside access to the | |||
| filters, outside access to the closed environment can be avoided. | closed environment can be avoided. The third is the IPv6 addresses | |||
| The third is the IPv6 addresses that ISP/carrier network assign to | that ISP/carrier network assign to customers. These will typically | |||
| customers. These will typically be assigned with prefix lengths | be assigned with prefix lengths terminating on nibble boundaries to | |||
| terminating on nibble boundaries to be consistent with the DNS PTR | be consistent with the DNS PTR records. As scarcity of IPv6 | |||
| records. As scarcity of IPv6 addresses is not a concern, it will be | addresses is not a concern, it will be possible for the ISP to | |||
| possible for the ISP to provide global routable IPv6 prefixes without | provide global routable IPv6 prefixes without a requirement for | |||
| a requirement for address translation. An ISP may for commercial | address translation. An ISP may for commercial reasons still decide | |||
| reasons still decide to restrict the capabilities of the end users by | to restrict the capabilities of the end users by other means like | |||
| other means like traffic and/or route filtering etc. | traffic and/or route filtering etc. | |||
| If the carrier network is a mobile provider, then IPv6 is encouraged | If the carrier network is a mobile provider, then IPv6 is encouraged | |||
| in comparison with the combination of IPv4+NAT for 3GPP attached | in comparison with the combination of IPv4+NAT for 3GPP attached | |||
| devices. When looking in chapter 2.3 of RFC3314 'Recommendations for | devices. When looking in chapter 2.3 of RFC3314 'Recommendations for | |||
| IPv6 in 3GPP Standards' [15] it is found that the IPv6 WG recommends | IPv6 in 3GPP Standards' [16] it is found that the IPv6 WG recommends | |||
| that one or more /64 prefixes should be assigned to each primary PDP | that one or more /64 prefixes should be assigned to each primary PDP | |||
| context. This will allow sufficient address space for a 3GPP- | context. This will allow sufficient address space for a 3GPP- | |||
| attached node to allocate privacy addresses and/or route to a multi- | attached node to allocate privacy addresses and/or route to a multi- | |||
| link subnet, and will discourage the use of NAT within 3GPP-attached | link subnet, and will discourage the use of NAT within 3GPP-attached | |||
| devices. | devices. | |||
| 6. IPv6 Gap Analysis | 6. IPv6 Gap Analysis | |||
| Like IPv4 and any major standards effort, IPv6 standardization work | Like IPv4 and any major standards effort, IPv6 standardization work | |||
| continues as deployments are ongoing. This section discusses several | continues as deployments are ongoing. This section discusses several | |||
| topics for which additional standardization, or documentation of best | topics for which additional standardization, or documentation of best | |||
| practice, is required to fully realize the benefits of NAP. None of | practice, is required to fully realize the benefits of 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. Simple Security | |||
| Dynamic pinhole management is an area for further study. Several | ||||
| partial solutions exist including ICE, UPNP, as well as alternative | ||||
| proposals for Service Provider based control. The 'simple' aspect of | ||||
| the security provided by a stateful firewall will require some degree | ||||
| of automation to mask the technical complexity from the consumer that | ||||
| only wants a secure environment with working applications. | ||||
| 6.2. Subnet Topology Masking | ||||
| There really is no functional gap here as a centrally assigned pool | There really is no functional gap here as a centrally assigned pool | |||
| of addresses in combination with host routes in the IGP is an | of addresses in combination with host routes in the IGP is an | |||
| effective way to mask topology. If necessary a best practice | effective way to mask topology for smaller deployments. If necessary | |||
| document could be developed describing the interaction between DHCP | a best practice document could be developed describing the | |||
| and various IGPs which would in effect define Untraceable Addresses. | interaction between DHCP and various IGPs which would in effect | |||
| define Untraceable Addresses. | ||||
| As an alternative, some work in Mobile IP to define a policy message | As an alternative for larger deployments, there is no gap in the HA | |||
| where a mobile node would learn from the Home Agent. It should not | tunneling approach when firewalls are configured to block outbound | |||
| try to inform its correspondent about route optimization and thereby | binding update messages. A border Home Agent using internal | |||
| expose its real location. A border Home Agent using internal | tunneling to the logical mobile node (potentially rack mounted) can | |||
| 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. This work should be | a large number of host routes in the IGP. Some optimization work | |||
| pursued in the IETF. | 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. Trade-off's for this optimization | ||||
| work should be investigated in the IETF. | ||||
| 6.2. Minimal Traceability of Privacy Addresses | 6.3. Minimal Traceability of Privacy Addresses | |||
| Privacy addresses (RFC 3041) may certainly be used to limit the | Privacy addresses (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 | ||||
| Documentation of site renumbering procedures [12] is completed and is | ||||
| in the RFC-editor's queue. It should also be noticed that ULAs may | ||||
| 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' work, the IETF has converged on an architectural | after several years of work, the IETF has converged on an | |||
| approach intended with service restoration as initial aim [20]. | architectural approach intended with service restoration as initial | |||
| Again, ULAs may help since they will provide stable addressing for | aim [21]. When this document was drafted, the IETF was actively | |||
| internal communications that are not affected by multihoming. | defining the details of this approach to the multihoming problem. | |||
| The approach appears to be most suitable for small and medium sites, | ||||
| 6.5. Untraceable Addresses | though it will conflict with firewall state procedures. At this time | |||
| there are also active discussions in the address registries | ||||
| The details of the untraceable addresses, along with any associated | investigating the possibility of assigning provider-independent | |||
| mechanisms such as route injection, must be worked out and specified. | address space. Their challenge is finding a reasonable metric for | |||
| limiting the number of organizations that would qualify for a global | ||||
| routing entry. Additional work appears to be necessary to satisfy | ||||
| the entire range of requirements. | ||||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document requests no action by IANA | This document requests no action by IANA | |||
| 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 | |||
| RFC 2663 [2] and RFC 2993 [4]. | [2] and [4]. | |||
| This document defines IPv6 approaches which collectively achieve the | This document defines IPv6 approaches which collectively achieve the | |||
| goals of the network manager without the negative impact on | goals of the network manager without the negative impact on | |||
| applications or security that are inherent in a NAT approach. To the | applications or security that are inherent in a NAT approach. To the | |||
| degree that these techniques improve a network manager's ability to | degree that these techniques improve a network manager's ability to | |||
| explicitly know about or control access, and thereby manage the | explicitly audit or control access, and thereby manage the overall | |||
| overall attack exposure of local resources, they act to improve local | attack exposure of local resources, they act to improve local network | |||
| network security. In particular the explicit nature of a content | security. In particular the explicit nature of a content aware | |||
| aware firewall in NAP will be a vast security improvement over the | firewall in NAP will be a vast security improvement over the NAT | |||
| NAT artifact where lack of translation state has been widely sold as | artifact where lack of translation state has been widely sold as a | |||
| a form of protection. | form of protection. | |||
| 9. Conclusion | 9. Conclusion | |||
| This document has described a number of techniques that may be | This document has described a number of techniques that may be | |||
| combined on an IPv6 site to protect the integrity of its network | combined on an IPv6 site to protect the integrity of its network | |||
| architecture. These techniques, known collectively as Network | architecture. These techniques, known collectively as Network | |||
| Architecture Protection, retain the concept of a well defined | Architecture Protection, retain the concept of a well defined | |||
| boundary between "inside" and "outside" the private network, and | boundary between "inside" and "outside" the private network, and | |||
| allow firewalling, topology hiding, and privacy. However, because | allow firewalling, topology hiding, and privacy. However, because | |||
| they preserve address transparency where it is needed, they achieve | they preserve address transparency where it is needed, they achieve | |||
| skipping to change at page 26, line 25 | skipping to change at page 30, 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., "Procedures for Renumbering an IPv6 Network without | [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure | |||
| a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in | Neighbor Discovery (SEND)", RFC 3971, March 2005. | |||
| progress), March 2005. | ||||
| [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | [13] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering | |||
| Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in | an IPv6 Network without a Flag Day", RFC 4192, September 2005. | |||
| progress), January 2005. | ||||
| [14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | ||||
| Addresses", RFC 4193, October 2005. | ||||
| 11.2. Informative References | 11.2. Informative References | |||
| [14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- | [15] 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 | [16] Wasserman, M., "Recommendations for IPv6 in Third Generation | |||
| Partnership Project (3GPP) Standards", RFC 3314, | Partnership Project (3GPP) Standards", RFC 3314, | |||
| September 2002. | September 2002. | |||
| [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point | [17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point | |||
| (RP) Address in an IPv6 Multicast Address", RFC 3956, | (RP) Address in an IPv6 Multicast Address", RFC 3956, | |||
| November 2004. | November 2004. | |||
| [17] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful | [18] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful | |||
| (draft-dupont-ipv6- rfc3041harmful-05.txt)", June 2004. | (draft-dupont-ipv6- rfc3041harmful-05.txt)", June 2004. | |||
| [18] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- | [19] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning | |||
| v6ops- port-scanning-implications-01.txt)", July 2004. | (chown-v6ops-port-scanning-implications-01.txt)", July 2004. | |||
| [19] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to | [20] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to | |||
| think about when Renumbering an IPv6 network | think about when Renumbering an IPv6 network | |||
| (draft-chown-v6ops-renumber-thinkabout-03)", October 2004. | (draft-chown-v6ops-renumber-thinkabout-03)", October 2004. | |||
| [20] Huston, G., "Architectural Commentary on Site Multi-homing | [21] Huston, G., "Architectural Commentary on Site Multi-homing | |||
| using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)", | using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)", | |||
| July 2004. | July 2004. | |||
| Appendix A. Additional Benefits due to Native IPv6 and Universal Unique | Appendix A. Additional Benefits due to Native IPv6 and Universal | |||
| Addressing | Unique Addressing | |||
| The users of native IPv6 technology and global unique IPv6 addresses | The users of native IPv6 technology and global unique IPv6 addresses | |||
| have the potential to make use of the enhanced IPv6 capabilities, in | have the potential to make use of the enhanced IPv6 capabilities, in | |||
| addition to the benefits offered by the IPv4 technology. | addition to the benefits offered by the IPv4 technology. | |||
| A.1. Universal Any-to-Any Aonnectivity | A.1. Universal Any-to-Any Connectivity | |||
| One of the original design points of the Internet was any-to-any | One of the original design points of the Internet was any-to-any | |||
| connectivity. The dramatic growth of Internet connected systems | connectivity. The dramatic growth of Internet connected systems | |||
| coupled with the limited address space of the IPv4 protocol spawned | coupled with the limited address space of the IPv4 protocol spawned | |||
| address conservation techniques. NAT was introduced as a tool to | address conservation techniques. NAT was introduced as a tool to | |||
| reduce demand on the limited IPv4 address pool, but the side effect | reduce demand on the limited IPv4 address pool, but the side effect | |||
| of the NAT technology was to remove the any-to-any connectivity | of the NAT technology was to remove the any-to-any connectivity | |||
| capability. By removing the need for address conservation (and | capability. By removing the need for address conservation (and | |||
| therefore NAT), IPv6 returns the any-to-any connectivity model and | therefore NAT), IPv6 returns the any-to-any connectivity model and | |||
| removes the limitations on application developers. With the freedom | removes the limitations on application developers. With the freedom | |||
| to innovate unconstrained by NAT traversal efforts, developers will | to innovate unconstrained by NAT traversal efforts, developers will | |||
| be able to focus on new advanced network services (i.e. peer-to-peer | be able to focus on new advanced network services (i.e. peer-to-peer | |||
| applications, IPv6 embedded IPsec communication between two | applications, IPv6 embedded IPsec communication between two | |||
| communicating devices, instant messaging, Internet telephony, etc..) | communicating devices, instant messaging, Internet telephony, etc..) | |||
| rather than focusing on discovering and traversing the increasingly | rather than focusing on discovering and traversing the increasingly | |||
| complex NAT environment. | complex NAT environment. | |||
| It will also allow application and service developers to rethink the | It will also allow application and service developers to rethink the | |||
| security model involved with any-to-any connectivity, as the current | security model involved with any-to-any connectivity, as the current | |||
| edge firewall solution in IPv4 may not be sufficient for Any-to-any | edge firewall solution in IPv4 may not be sufficient for any- to-any | |||
| service models. | service models. | |||
| A.2. Auto-configuration | A.2. Auto-configuration | |||
| IPv6 offers a scalable approach to minimizing human interaction and | IPv6 offers a scalable approach to minimizing human interaction and | |||
| device configuration. Whereas IPv4 implementations require touching | device configuration. Whereas IPv4 implementations require touching | |||
| each end system to indicate the use of DHCP vs. a static address and | each end system to indicate the use of DHCP vs. a static address and | |||
| management of a server with the pool size large enough for the | management of a server with the pool size large enough for the | |||
| potential number of connected devices, IPv6 uses an indication from | potential number of connected devices, IPv6 uses an indication from | |||
| the router to instruct the end systems to use DHCP or the stateless | the router to instruct the end systems to use DHCP or the stateless | |||
| auto configuration approach supporting a virtually limitless number | auto configuration approach supporting a virtually limitless number | |||
| of devices on the subnet. This minimizes the number of systems that | of devices on the subnet. This minimizes the number of systems that | |||
| require human interaction as well as improves consistency between all | require human interaction as well as improves consistency between all | |||
| the systems on a subnet. In the case that there is no router to | the systems on a subnet. In the case that there is no router to | |||
| provide this indication, an address for use on the local link only | provide this indication, an address for use only on the local link | |||
| will be derived from the interface media layer address. | will be derived from the interface media layer address. | |||
| A.3. Native Multicast Services | A.3. Native Multicast Services | |||
| Multicast services in IPv4 were severely restricted by the limited | Multicast services in IPv4 were severely restricted by the limited | |||
| address space available to use for group assignments and an implicit | address space available to use for group assignments and an implicit | |||
| locally defined range for group membership. IPv6 multicast corrects | locally defined range for group membership. IPv6 multicast corrects | |||
| this situation by embedding explicit scope indications as well as | this situation by embedding explicit scope indications as well as | |||
| expanding to 4 billion groups per scope. In the source specific | expanding to 4 billion groups per scope. In the source specific | |||
| multicast case, this is further expanded to 4 billion groups per | multicast case, this is further expanded to 4 billion groups per | |||
| scope per subnet by embedding the 64 bits of subnet identifier into | scope per subnet by embedding the 64 bits of subnet identifier into | |||
| the multicast address. | the multicast address. | |||
| IPv6 allows also for innovative usage of the IPv6 address length, and | IPv6 allows also for innovative usage of the IPv6 address length, and | |||
| makes it possible to embed the multicast 'Rendez-Vous Point' (or RP) | makes it possible to embed the multicast 'Rendezvous Point' (or RP) | |||
| [16] directly in the IPv6 multicast address when using ASM multicast. | [17] directly in the IPv6 multicast address when using ASM multicast. | |||
| this is not possible with limited size of the IPv4 address. This | This is not possible with limited size of the IPv4 address. This | |||
| approach also simplifies the multicast model considerably, making it | approach also simplifies the multicast model considerably, making it | |||
| easier to understand and deploy. | easier to understand and deploy. | |||
| A.4. Increased Security Protection | A.4. Increased Security Protection | |||
| The security protection offered by native IPv6 technology is more | The security protection offered by native IPv6 technology is more | |||
| advanced than IPv4 technology. There are various transport | advanced than IPv4 technology. There are various transport | |||
| mechanisms enhanced to allow a network to operate more securely with | mechanisms enhanced to allow a network to operate more securely with | |||
| less performance impact: | less performance impact: | |||
| o IPv6 has the IPsec technology directly embedded into the IPv6 | o IPv6 has the IPsec technology directly embedded into the IPv6 | |||
| protocol. This allows for simpler peer-to-peer encryption and | protocol. This allows for simpler peer-to-peer authentication and | |||
| authentication, once a simple key/trust management model is | encryption, once a simple key/trust management model is developed, | |||
| developed, while the usage of some other less secure mechanisms is | while the usage of some other less secure mechanisms is avoided | |||
| avoided (i.e. md5 password hash for neighbor authentication). | (i.e. md5 password hash for neighbor authentication). | |||
| o On a local network, any user will have more security awareness. | o On a local network, any user will have more security awareness. | |||
| This awareness will motivate the usage of simple firewall | This awareness will motivate the usage of simple firewall | |||
| applications/devices to be inserted on the border between the | applications/devices to be inserted on the border between the | |||
| external network and the local (or home network) as there is no | external network and the local (or home network) as there is no | |||
| Address Translater and hance no false safety perception. | Address Translator and hence no false safety perception. | |||
| o All flows on the Internet will be better traceable due to a unique | o All flows on the Internet will be better traceable due to a unique | |||
| and globally routable source and destination IPv6 address. This | and globally routable source and destination IPv6 address. This | |||
| may facilitate an easier methodology for back-tracing DoS attacks | may facilitate an easier methodology for back-tracing DoS attacks | |||
| and avoid illegal access to network resources by simpler traffic | and avoid illegal access to network resources by simpler traffic | |||
| filtering. | filtering. | |||
| o The usage of private address-space in IPv6 is now provided by | o The usage of private address-space in IPv6 is now provided by | |||
| Unique Local Addresses, which will avoid conflict situations when | Unique Local Addresses, which will avoid conflict situations when | |||
| merging networks and securing the internal communication on a | merging networks and securing the internal communication on a | |||
| local network infrastructure due to simpler traffic filtering | local network infrastructure due to simpler traffic filtering | |||
| policy. | policy. | |||
| skipping to change at page 29, line 29 | skipping to change at page 33, 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 legitimate usage of RFC 1918 | network infrastructure due to the usage of RFC 1918 private | |||
| private addressing. This potential overlap in address space may | addressing. This potential overlap in address space may complicate a | |||
| complicate a merge of two and more networks dramatically due to the | merge of two and more networks dramatically due to the additional | |||
| additional IPv4 renumbering effort. i.e. when the first network has a | IPv4 renumbering effort. i.e. when the first network has a service | |||
| service running (NTP, DNS, DHCP, HTTP, etc..) which need to be | running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by | |||
| accessed by the 2nd merging network. Similar address conflicts can | the 2nd merging network. Similar address conflicts can happen when | |||
| happen when two network devices from these merging networks want to | two network devices from these merging networks want to communicate. | |||
| communicate. | ||||
| With the usage of IPv6 the addressing overlap will not exist because | With the usage of IPv6 the addressing overlap will not exist because | |||
| of the existence of the Unique Local Address usage for private and | of the existence of the Unique Local Address usage for private and | |||
| local addressing. | local addressing. | |||
| A.7. Community of interest | A.7. Community of interest | |||
| Although some Internet-enabled devices will function as fully-fledged | Although some Internet-enabled devices will function as fully- | |||
| Internet hosts, it is believed that many will be operated in a highly | fledged Internet hosts, it is believed that many will be operated in | |||
| restricted manner functioning largely or entirely within a Community | a highly restricted manner functioning largely or entirely within a | |||
| of Interest. By Community of Interest we mean a collection of hosts | Community of Interest. By Community of Interest we mean a collection | |||
| that are logically part of a group reflecting their ownership or | of hosts that are logically part of a group reflecting their | |||
| function. Typically, members of a Community of Interest need to | ownership or function. Typically, members of a Community of Interest | |||
| communicate within the community but should not be generally | need to communicate within the community but should not be generally | |||
| accessible on the Internet. They want the benefits of the | accessible from the public Internet. They want the benefits of the | |||
| connectivity provided by the Internet, but do not want to be exposed | connectivity provided by the Internet, but do not want to be exposed | |||
| to the rest of the world. This functionality will be available | to the rest of the world. The ability in NAP to virtualize the | |||
| through the usage of NAP and native IPv6 dataflows, without any | topology and mask portions of it is applied to the community, | |||
| stateful device in the middle. It will also allow to build virtual | creating arbitrary groupings. It will also allow building 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 | |||
| a new case study section 5. | a new case study section 5. | |||
| o The list of additional IPv6 benefits has been been placed into | o The list of additional IPv6 benefits has been placed into | |||
| appendix. | appendix. | |||
| o new security considerations section added. | o new security considerations section added. | |||
| o GAP analysis revised. | o GAP analysis revised. | |||
| o Section 2.6 and 4.6 have been included. | o Section 2.6 and 4.6 have been included. | |||
| B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00 | B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00 | |||
| o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf- | o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *- | |||
| v6ops-nap-00.txt. | ietf-v6ops-nap-00.txt. | |||
| o Editorial changes. | o Editorial changes. | |||
| B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 | B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 | |||
| o Added text in Chapter 2.2 and 4.2 to address more details on | o Added text in Chapter 2.2 and 4.2 to address more details on | |||
| firewall and proxy | firewall and proxy | |||
| o Revised Eric Klein contact details | o Revised Eric Klein contact details | |||
| o Added note in 4.2 that control over the proposed statefull-filter | o Added note in 4.2 that control over the proposed statefull-filter | |||
| should be by a simple user-interface | should be by a simple user-interface | |||
| B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 | B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 | |||
| o General Note: Header more consistent capitelized. | o General Note: Header more consistent capitalized. | |||
| o Section 1: para 3: s/...and privacy and will... translation./ | o Section 1: para 3: s/...and privacy and will... translation./ | |||
| ...and privacy. NAP will achieve these security goals without | ...and privacy. NAP will achieve these security goals without | |||
| address transaltion whilst maintaining any-to-any connectivity./ | address translation whilst maintaining any-to-any connectivity./ | |||
| o Section 1: Various editorial changes happened | o Section 1: Various editorial changes happened | |||
| o Section 2.1: Changed: 'Frequently a simple user interface is | o Section 2.1: Changed: 'Frequently a simple user interface is | |||
| sufficient for configuring'. into 'Frequently a simple user | sufficient for configuring'. into 'Frequently a simple user | |||
| interface, or no user interface is sufficient' | interface, or no user interface is sufficient' | |||
| o Section 2.2: (Simple Security ) Better not to use the word -evil- | o Section 2.2: (Simple Security ) Better not to use the word -evil- | |||
| in the text | in the text | |||
| o Section 2.2: changed 'provided by NAT are actually ' into | o Section 2.2: changed 'provided by NAT are actually ' into | |||
| 'provided by NAT is actually' | 'provided by NAT is actually' | |||
| o Section 2.2: para 3: s/actually false/actually an illusion/ | 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 | o Section 2.2: para 2: added 'Also it will only be reliable if a | |||
| skipping to change at page 31, line 20 | skipping to change at page 35, line 20 | |||
| device's state/ | device's state/ | |||
| o Section 2.4: para1: clarified the definition of topology hiding | o Section 2.4: para1: clarified the definition of topology hiding | |||
| o Section 2.4: last sentence of next-to-last paragraph, added | o Section 2.4: last sentence of next-to-last paragraph, added | |||
| punctuation at end of sentence. | punctuation at end of sentence. | |||
| o Section 2.4: added first line: When mentioning 'topology hiding' | o Section 2.4: added first line: When mentioning 'topology hiding' | |||
| the goal is to make a reference that an entity outside the network | 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 | can not make a correlation between the location of a device and | |||
| the address of a device on the local network. | the address of a device on the local network. | |||
| o Section 2.4: para 1: s/reflected/represented/ | o Section 2.4: para 1: s/reflected/represented/ | |||
| o Section 2.5: last par: added reference: 'Section 2.7 describes | o Section 2.5: last par: added reference: 'Section 2.7 describes | |||
| some disadvantages that appear if independednt networks using | some disadvantages that appear if independent networks using | |||
| [RFC1918] addresses have to be merged.' | [RFC1918] addresses have to be merged.' | |||
| o Section 2.6: Added text that private address-space is not | o Section 2.6: Added text that private address-space is not | |||
| limitless | limitless | |||
| o Section 2.6: Various editorial changes | o Section 2.6: Various editorial changes | |||
| o Section 2.7: Para 1 editorial revised | o Section 2.7: Para 1 editorial revised | |||
| o Section 2.7: last para: s/This solution/The addition of an extra | o Section 2.7: last para: s/This solution/The addition of an extra | |||
| NAT as a solution/ | NAT as a solution/ | |||
| o Section 2.7: s/highly desirable to be/highly desirable due to | o Section 2.7: s/highly desirable to be/highly desirable due to | |||
| resiliency and load-balancing to be/ | resiliency and load-balancing to be/ | |||
| o Section 2.7: added text on the reason why there are overlapping | o Section 2.7: added text on the reason why there are overlapping | |||
| addresses | addresses | |||
| o Section 2.7: last para: s/merged address space/overlapping address | o Section 2.7: last para: s/merged address space/overlapping address | |||
| speaces in the merged networks/ | spaces in the merged networks/ | |||
| o Section 3.1: Para 1 editorial changes | o Section 3.1: Para 1 editorial changes | |||
| o Section 3.1: s/by contacted web sites, so IPv6/by web sites that | o Section 3.1: s/by contacted web sites, so IPv6/by web sites that | |||
| are accessed from the device: IPv6 / | are accessed from the device: IPv6 / | |||
| o Section 3.1: s/as that would have a serious negative impact on | 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 | global routing/as that would have a negative effect on global | |||
| route aggregation | route aggregation | |||
| o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in | o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in | |||
| global routing table is not scalable | global routing table is not scalable | |||
| o Section 3.2: s3.2: Noted that it is not always interresting to mix | o Section 3.2: s3.2: Noted that it is not always interesting to mix | |||
| ULA with global as that may lead to SAS issues | ULA with global as that may lead to SAS issues | |||
| o Section 3.3: last para: s/delegating router/delegating router | o Section 3.3: last para: s/delegating router/delegating router | |||
| (incorporating a DHCPv6 server)/, s/across an administrative/ | (incorporating a DHCPv6 server)/, s/across an administrative/ | |||
| possibly across an administrative/ | possibly across an administrative/ | |||
| o Section 3.4: Changed: 'random assignment has as purpose' to | o Section 3.4: Changed: 'random assignment has as purpose' to | |||
| 'random assignment has a purpose' | 'random assignment has a purpose' | |||
| o Section 3.4: para 2: Replace first sentence with: 'The random | o Section 3.4: para 2: Replace first sentence with: 'The random | |||
| assignment is intended to mislead the outside world about the | assignment is intended to mislead the outside world about the | |||
| structure of the local network.' | structure of the local network.' | |||
| o Section 3.4: para 2: s/there is a correlation/needs to maintain a | o Section 3.4: para 2: s/there is a correlation/needs to maintain a | |||
| correlation/ | correlation/ | |||
| o Section 3.4: para 2: s/like a/such as a/ | o Section 3.4: para 2: s/like a/such as a/ | |||
| o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from | o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from | |||
| mapping/and from mapping of/ | mapping/and from mapping of/ | |||
| o Section 3.4: para 3: s/are reachable on/are allocated to devices | o Section 3.4: para 3: s/are reachable on/are allocated to devices | |||
| on/ | on/ | |||
| o Section 3.4: para 3: s/belonging to the same subnet next to each | 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 | other/belonging to devices adjacent to each other on the same | |||
| subnet/ | subnet/ | |||
| o Section 3.4: s/aggregation device/indirection device/ | 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: split the 1 section up into 2 separate sections | |||
| o Section 4.1: s/ End node connections involving other nodes on the | o Section 4.1: s/ End node connections involving other nodes on the | |||
| global Internet will always use the global IPv6 addresses [9] | global Internet will always use the global IPv6 addresses [9] | |||
| derived from this prefix delegation./ End node connections | derived from this prefix delegation./ End node connections | |||
| involving other nodes on the global Internet will always use the | involving other nodes on the global Internet will always use the | |||
| global IPv6 addresses [9] derived from this prefix delegation. It | global IPv6 addresses [9] derived from this prefix delegation. It | |||
| should be noted that the policy table needs to be correctly set up | should be noted that the policy table needs to be correctly set up | |||
| so that true global prefixes are distinguished from ULAs and will | so that true global prefixes are distinguished from ULAs and will | |||
| be used for the source address in preference when the destination | be used for the source address in preference when the destination | |||
| is not a ULA/ | is not a ULA/ | |||
| o Section 4.1: A more secure network environment can be established | o Section 4.1: A more secure network environment can be established | |||
| by having the referenced ULA addresses statically configured on | by having the referenced ULA addresses statically configured on | |||
| the network devices as this decreases the dynamic aspects of the | the network devices as this decreases the dynamic aspects of the | |||
| network, however the operational overhead is increased. | network, however the operational overhead is increased. | |||
| o Section 4.2:Added note that IID should be randomized for port-scan | o Section 4.2: Added note that IID should be randomized for port- | |||
| protection | scan protection | |||
| o Section 4.2: Removed text: This is an automated procedure of | o Section 4.2: Removed text: This is an automated procedure of | |||
| sending Internet Control Message Protocol (ICMP) echo requests | sending Internet Control Message Protocol (ICMP) echo requests | |||
| (also known as PINGs) to a range of IP addresses and recording | (also known as PINGs) to a range of IP addresses and recording | |||
| replies. This can enable an attacker to map the network. | replies. This can enable an attacker to map the network. | |||
| o Section 4.2: paragraph beginning: "This simple rule...". The | o Section 4.2: paragraph beginning: "This simple rule...". The | |||
| first sentence in this paragraph was overly-long. The sentence | first sentence in this paragraph was overly-long. The sentence | |||
| has been fragmented | 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/similar as for an/similar to that of an/ | |||
| o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/ | o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/ | |||
| Internet. The use of firewall and Intrusion Detection Systems | Internet. The use of firewall and Intrusion Detection Systems | |||
| skipping to change at page 33, line 20 | skipping to change at page 37, line 20 | |||
| best practices are trying to achieve./IPv6 security best practices | best practices are trying to achieve./IPv6 security best practices | |||
| will avoid this kind of illusory security but can only do this if | will avoid this kind of illusory security but can only do this if | |||
| correctly configured firewalls and IDS systems are used at the | correctly configured firewalls and IDS systems are used at the | |||
| perimeter where some IPv4 networks have relied on NATs. | perimeter where some IPv4 networks have relied on NATs. | |||
| o Section 4.2: s/ It is recommended for site administrators to take | o Section 4.2: s/ It is recommended for site administrators to take | |||
| [17] into consideration to achieve the expected goal./ It is | [17] into consideration to achieve the expected goal./ It is | |||
| recommended for site administrators to take [17] into | recommended for site administrators to take [17] into | |||
| consideration to achieve the expected goal. This protection will | consideration to achieve the expected goal. This protection will | |||
| also be nullified if IIDs are configured in a group near the start | also be nullified if IIDs are configured in a group near the start | |||
| of the IID space./ | of the IID space./ | |||
| o Section 4.2: Removed the example study and added complementiory | o Section 4.2: Removed the example study and added complementary | |||
| text to describe a potential behavior | text to describe a potential behavior | |||
| o Section 4.4: rewrite of the section to reduce the importance of | o Section 4.4: rewrite of the section to reduce the importance of | |||
| the MIpv^ and tunneled solution | the MIPv6 and tunneled solution | |||
| o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested | o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested | |||
| in the text, however text is added that any kind of tunneling | in the text, however text is added that any kind of tunneling | |||
| should do the trick. | should do the trick. | |||
| o Section 4.4: para 2: after 'As discussed above' inserted '(see | o Section 4.4: para 2: after 'As discussed above' inserted '(see | |||
| Section 3.1)' | Section 3.1)' | |||
| o Section 4.4: para 3: s/consolidated on/indirected via/ | 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: s/topololgy masked/each topology masked/ | |||
| o Section 4.4: para 3: Expanded acronym COA | o Section 4.4: para 3: Expanded acronym COA | |||
| o Section 4.4: para 3: s/rack mounted/static/ | o Section 4.4: para 3: s/rack mounted/static/ | |||
| o Section 4.4: Rephrasing of text happened in this section | 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 | o Section 4.5: change: "so that a NAT is not required" to: "so that | |||
| IPv6 address translation is not required". | IPv6 address translation is not required". | |||
| o Section 4.5: changed 'periodically to look' into 'to look | o Section 4.5: changed 'periodically to look' into 'to look | |||
| periodically' | periodically' | |||
| o Section 4.5: change: "2^64 hosts" to: "2^64 addresses". | o Section 4.5: change: "2^64 hosts" to: "2^64 addresses". | |||
| o Section 4.5: Removed the statement '(or even defined) | o Section 4.5: Removed the statement '(or even defined) | |||
| o Section 4.6: last para: s/which will lead to the IPv4 practice/ | o Section 4.6: last para: s/which will lead to the IPv4 practice/ | |||
| which will require the adoption of the IPv4 workaround/ | which will require the adoption of the IPv4 workaround/ | |||
| o Section 4.6: s/the IPv4 constricting scenarios of multiple devices | o Section 4.6: s/the IPv4 constricting scenarios of multiple devices | |||
| sharing a/the constriction of IPv4 scenarios where multiple devies | sharing a/the constriction of IPv4 scenarios where multiple | |||
| are forced to share a/ | devices are forced to share a/ | |||
| o Section 4.7: s/as the zero-touch external/as an almost zero-touch | o Section 4.7: s/as the zero-touch external/as an almost zero-touch | |||
| external/ | external/ | |||
| o Section 5: Replaced first three sentences with: In presenting | o Section 5: Replaced first three sentences with: In presenting | |||
| these case studies we have chosen to consider categories of | these case studies we have chosen to consider categories of | |||
| network divided first according to their function either as | network divided first according to their function either as | |||
| carrier/ISP networks or end user (such as enterprise) networks | carrier/ISP networks or end user (such as enterprise) networks | |||
| with the latter category broken down according to the number of | with the latter category broken down according to the number of | |||
| connected end hosts. | connected end hosts. | |||
| o Section 5: bullet points: s/connection/connected end hosts/ | o Section 5: bullet points: s/connection/connected end hosts/ | |||
| o Section 5.1: s/addressing independence/addressing independence | o Section 5.1: s/addressing independence/addressing independence | |||
| when using IPv4/ | when using IPv4/ | |||
| o Section 5.1: last para: s/is only affecting/will only affect/ | 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 'allocation' into 'allocation' | |||
| o Section 5.1: changed: '(typically a one or' into '(typically one | o Section 5.1: changed: '(typically a one or' into '(typically one | |||
| or' | or' | |||
| o section 5.1: changed: s/allocation/assignment/ in one of the | o section 5.1: changed: s/allocation/assignment/ in one of the | |||
| paragraphs | paragraphs | |||
| o section 5.2: para 1: s?is too long?is too long (very often just a | o section 5.2: para 1: s?is too long?is too long (very often just a | |||
| /32 just giving a single address)? | /32 just giving a single address)? | |||
| o Section 5.4: (Case study: ISP networks) ULA usage for ISP/ | o Section 5.4: (Case study: ISP networks) ULA usage for ISP/ | |||
| Carrier-grade networks is mentioned in the draft, while it was | Carrier-grade networks is mentioned in the draft, while it was | |||
| suggested that for these NW the PI addresses are already very | suggested that for these NW the PI addresses are already very | |||
| stable and they should be qualified for setting up proper | stable and they should be qualified for setting up proper | |||
| skipping to change at page 35, line 5 | skipping to change at page 38, line 35 | |||
| 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-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: s/market acceptance/deployment | ||||
| o Introduction: noted that users do not evaluate technical trade- | ||||
| offs and that marketing does not mention the downside of address | ||||
| translation | ||||
| 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 / removed last | ||||
| paragraph about security | ||||
| 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 / changed comment about theory to an absolute / qualified | ||||
| logging and checking times | ||||
| o Section 2.4: deleted confusing/redundant comments about identifier | ||||
| / clarified point about nodes appearing to be at the edge / added | ||||
| clarification that focused scanning on the port range reaches | ||||
| active nodes | ||||
| o Section 2.5: clarified that the reason for autonomy is large space | ||||
| & impact was on the local network | ||||
| o Section 2.6: clarified point about reduction of IPv4 consumption | ||||
| rate / s/30%/25% / added point about limitations of cascaded nat / | ||||
| added para about limited app endpoints as well as topology | ||||
| restrictions | ||||
| o Section 2.7: clarification about why multihoming & renumbering are | ||||
| discussed together / point about sparse allocation / s/speaces/ | ||||
| spaces | ||||
| o Section 3: s/emulate/replace / added para about 'gaps' being | ||||
| discussed later | ||||
| o Section 3.1: Cleaned up description of SLAAC & 3041 / specified | ||||
| server as DHCP / added comment about sparse allocation | ||||
| o Section 3.2: grammar cleanup / updated reference from ID to RFC | ||||
| 4193 / added point about policy table in 3484 to bias ULA over ISP | ||||
| prefix | ||||
| 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 3484 table for ULA biasing / clarified | ||||
| point about lack of routing protocol | ||||
| o Section 4.2: clarified point about firewall at boundary / | ||||
| clarified point about valid lifetime / clarified point that IPsec | ||||
| works the same w/o NAT / added point about authenticating | ||||
| correspondent / clarified that the scanning threat is addresses as | ||||
| ports are the same once an address is known / rearranged paragraph | ||||
| to keep scanning thread together / inserted firewall discussion | ||||
| moved from 2.2 / 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/ s/possible/ | ||||
| potential/ reworded ULA description which was technically | ||||
| backwards / additional description of the goal / added picture and | ||||
| referenced it from descriptions converted options to descriptive | ||||
| list / added discussion about blocking binding updates / added | ||||
| vlan option / s/would be to use/uses to make it clear this already | ||||
| works / para 2 s/prefixes/addresses and replaced last part of the | ||||
| sentence to clarify what was being hidden. | ||||
| o Section 4.5: Grammar cleanup / clarification about policy | ||||
| o Section 4.6: replaced long number string with power qnty of | ||||
| subnets / added reference to new capabilities like SEND | ||||
| 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/ | ||||
| Updated reference for renumbering proceedure to RFC 4192 | ||||
| o Section 5: d/of these/ | ||||
| o Section 5.1: s/private enterprise/private enterprise, academic, | ||||
| research, or government / 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 as short | ||||
| timeframe | ||||
| o Section 5.3: capitalize Internet | ||||
| o Section 5.4: s/IPv4/IP as role is not version specific / deleted | ||||
| comment about preference to ULA. | ||||
| o Section 6.1: (security) inserted section discussing need for | ||||
| dynamic pinhole management | ||||
| o Section 6.2: (topology mask) 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: (tracability) grammar cleanup | ||||
| o Section 6.4: (renumbering) Cut section since it is no longer a gap | ||||
| o Section A.2: word order - moved 'only' | ||||
| o Section A.6: deleted 'legitimate' | ||||
| o Section A.7: clarified how NAP delivers community of interest | ||||
| o Spell check | ||||
| 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 36, line 41 | skipping to change at page 42, 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 (2005). This document is subject | Copyright (C) The Internet Society (2006). 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. 137 change blocks. | ||||
| 629 lines changed or deleted | 883 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/ | ||||