Network Working Group G. Van de Velde
Internet-Draft T. Hain
Expires: April 12, 2005 R. Droms
Cisco Systems
B. Carpenter
IBM Corporation
E. Klein
TTI Telecom
October 12, 2004
IPv6 Network Architecture Protection
<draft-vandevelde-v6ops-nap-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 April 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Although there are many perceived benefits to Network Address
Translation (NAT), the primary benefit of "amplifying" available
Van de Velde, et al. Expires April 12, 2005 [Page 1]
Internet-Draft IPv6 Network Architecture Protection October 2004
address space is not needed in IPv6. In addition to its many serious
disadvantages there is a perception that other benefits exist, such
as a variety of management and security reasons that could be useful
for an Internet Protocol. IPv6 does not support NAT by design and
this document shows how Network Architecture Protection (NAP) using
IPv6 can provide the benefits without the need for NAT.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Perceived benefits of NAT and its impact on IPv4 . . . . . . . 4
2.1 Simple gateway between Internet and internal network . . . 5
2.2 Simple security due to stateful filter implementation . . 5
2.3 User/Application tracking . . . . . . . . . . . . . . . . 5
2.4 Privacy and topology hiding . . . . . . . . . . . . . . . 6
2.5 Independent control of addressing in a private network . . 6
2.6 IPv4 and address allocation dynamics with NAT devices . . 7
2.6.1 Medium/large private networks . . . . . . . . . . . . 7
2.6.2 Small private networks . . . . . . . . . . . . . . . . 8
2.6.3 Single user connection . . . . . . . . . . . . . . . . 8
2.6.4 ISP/Carrier customer networks . . . . . . . . . . . . 8
2.7 Multihoming and renumbering with NAT . . . . . . . . . . . 9
3. Description of the IPv6 tools . . . . . . . . . . . . . . . . 9
3.1 Privacy addresses (RFC 3041) . . . . . . . . . . . . . . . 9
3.2 Unique Local Addresses . . . . . . . . . . . . . . . . . . 10
3.3 DHCPv6 prefix delegation . . . . . . . . . . . . . . . . . 10
3.4 Untraceable IPv6 addresses . . . . . . . . . . . . . . . . 10
3.5 Route-injection . . . . . . . . . . . . . . . . . . . . . 11
4. Using IPv6 technology to provide the market perceived
benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Simple gateway between Internet and internal network . . . 11
4.2 IPv6 and Simple security . . . . . . . . . . . . . . . . . 11
4.3 User/Application tracking . . . . . . . . . . . . . . . . 13
4.4 Privacy and topology hiding using IPv6 . . . . . . . . . . 13
4.5 independent control of addressing in a private network . . 14
4.6 IPv6 and address allocation dynamics . . . . . . . . . . . 14
4.6.1 Medium/large private networks . . . . . . . . . . . . 14
4.6.2 small private networks . . . . . . . . . . . . . . . . 16
4.6.3 Single user connection . . . . . . . . . . . . . . . . 16
4.6.4 ISP/Carrier customer networks . . . . . . . . . . . . 16
4.7 Multihoming and renumbering . . . . . . . . . . . . . . . 17
5. Additional benefits due to Native IPv6 and universal
unique addressing . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Universal any-to-any connectivity . . . . . . . . . . . . 18
5.2 Auto-configuration . . . . . . . . . . . . . . . . . . . . 18
5.3 Native Multicast services . . . . . . . . . . . . . . . . 18
5.4 Increased security protection . . . . . . . . . . . . . . 19
5.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 19
Van de Velde, et al. Expires April 12, 2005 [Page 2]
Internet-Draft IPv6 Network Architecture Protection October 2004
5.6 Merging networks . . . . . . . . . . . . . . . . . . . . . 20
5.7 Community of interest . . . . . . . . . . . . . . . . . . 20
6. IPv6 gap analysis . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Completion of work on ULAs . . . . . . . . . . . . . . . . 20
6.2 How to completely hide subnet topology . . . . . . . . . . 21
6.3 Minimal traceability of privacy addresses . . . . . . . . 21
6.4 Renumbering procedure . . . . . . . . . . . . . . . . . . 21
6.5 Site multihoming . . . . . . . . . . . . . . . . . . . . . 21
6.6 Untraceable addresses . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
Van de Velde, et al. Expires April 12, 2005 [Page 3]
Internet-Draft IPv6 Network Architecture Protection October 2004
1. Introduction
The serious disadvantages of ambiguous "private" address space and of
Network Address Translation (NAT) [2][4] have been well documented
[3][5]. However, given its wide market acceptance NAT undoubtedly
has some perceived benefits. Indeed, in an Internet model based on
universal any-to-any connectivity, product marketing departments have
driven a perception that some connectivity and security concerns can
only be solved by using a NAT device or by using logically separated
LAN address spaces. This document describes the market perceived
reasons to utilize a NAT device in an IPv4 environment and shows how
these needs can be met and even exceeded with native IPv6. The use
of the facilities from IPv6 described in this document avoids the
negative impacts of translation and may be described as Network
Architecture Protection (NAP).
As far as security and privacy is concerned, this document considers
how to mitigate a number of threats. Some are obviously external,
such as having a hacker try to penetrate your network, or having a
worm infected machine outside your network trying to attack it. Some
are local such as a disgruntled employee disrupting business
operations,or the unintentional negligence of a user download some
malware which then proceeds to attack any device on the LAN. Some
may be embedded such as having some firmware in a domestic appliance
"call home" to its manufacturer without the user's consent.
This document describes several techniques that may be combined on an
IPv6 site to protect the integrity of its network architecture.
These techniques, known collectively as NAP, retain the concept of a
well defined boundary between "inside" and "outside" the private
network, and allow firewalling, topology hiding, and privacy and
achieve these goals without address translation.
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 reminder of the other benefits of the enlarged IPv6
address space, and a gap analysis of work that remains to be done.
2. Perceived benefits of NAT and its impact on IPv4
This section provides visibility into the generally perceived
benefits of the use of IPv4 NAT. The goal of this description is not
to analyze these benefits or discus the rightfulness of the
perception, but to identify the connectivity and security
prerequisites to deploy IPv6 to functionally replace IPv4 combined
with a NAT device.
Van de Velde, et al. Expires April 12, 2005 [Page 4]
Internet-Draft IPv6 Network Architecture Protection October 2004
2.1 Simple gateway between Internet and internal network
A NAT device can connect a private network with any kind of address
(ambiguous [RFC 1918] or global registered address) towards the
Internet. The address space of the private network can be built from
globally unique addresses, from ambiguous addresses space or from
both simultaneously. Without specific configuration from public to
private, the NAT device enables access between the client side of an
application in the private network with the server side in the public
Internet.
Wide-scale deployments have shown that attaching a private network to
the Internet is simple and practical for the non-technical end user.
Frequently a simple user interface is sufficient for configuring both
device and application access rights. Additional, thanks to
successful marketing campaigns it is perceived by end users that
their equipment is protected from the bad-elements and attackers on
the public IPv4 Internet.
2.2 Simple security due to stateful filter implementation
It is frequently believed that a NAT device puts in an extra barrier
to keep the private network protected from evil outside influences
due to the stateful character of NAT technology (to protect against
hackers, worms, etc..). This benefit may be partially real; however,
experienced hackers are well aware of NAT devices and are very
familiar with the private address space, and hence the secure feeling
is in vain.
Address translation does not provide security on itself; for example,
consider a configuration with static NAT translation and all ports
translating to a single machine. In such a scenario the security
risk for that machine is identical as if there were no NAT device in
the communication path. As result there is no specific security
value in the address translation function. The perceived security
comes from the lack of pre-established mapping state. Dynamically
establishing state in response to internal requests reduces the
threat of unexpected external connections to internal devices.
2.3 User/Application tracking
Due to the fact that NAT is a stateful technology, it could 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 can be done by checking the network
address translation details of the private and the public addresses
of the NAT devices state-database.
Van de Velde, et al. Expires April 12, 2005 [Page 5]
Internet-Draft IPv6 Network Architecture Protection October 2004
The 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 an
IPv4-address and a network element or user at all times, or the
administrator has a time-correlated list of the address/port
mappings.
2.4 Privacy and topology hiding
The ability NAT to provide internet access by the use of a single (or
few) global IPv4 routable addresses to a large community of users
offers a simple mechanism to hide the internal topology of a network.
In this example the large community will be reflected in the internet
by a single (or few) IPv4 address(es).
The use of NAT then results in a user behind a NAT gateway actually
appearing on the Internet as a user inside the NAT box itself; i.e.,
the IPv4 address that appears on the Internet is only sufficient to
identify the NAT. Thus it is impossible to tell from the outside
which member of a family, which customer of an Internet caf‰, or
which employee of a company generated or received a particular
packet, if concealed behind NAT. Thus, although NATs do nothing to
provide application level privacy, they do prevent the external
tracking and profiling of individual host computers by means of their
IP addresses. At the same time it creates a smaller pool of
addresses for a much more focused point of attack.
Some enterprises prefer to hide as much as possible of their internal
network topology from outsiders. Mostly this is achieved by blocking
"traceroute" etc., but NAT of course entirely hides the internal
subnet topology, which some network managers believe is a useful
precaution to mitigate scanning attacks.
Once a list of available devices and IP addresses has been mapped, a
port-scan on these IP addresses can be performed. A port scan is an
automated procedure of initiating sessions on every specified TCP
port to see whether the host replies. If it does, a service is
running on the target port of the machine. Different services run on
default ports. For example, FTP usually runs on port 21, and HTTP
usually runs on port 80. These open port cold be used for initiating
attacks on an end system.
2.5 Independent control of addressing in a private network
Due to the ongoing depletion of the IPv4 address range, the remaining
pool of unallocated IPv4 addresses is below 30%. Recent consumption
rates are over 7% of the total IPv4 space per year. This run rate
leaves about 4 years to deplete the remaining unallocated pool. A
Van de Velde, et al. Expires April 12, 2005 [Page 6]
Internet-Draft IPv6 Network Architecture Protection October 2004
direct result of this is that the administrative cost of a globally
unique and routable IPv4 address will continue increasing as
allocation policies tighten so that they become more difficult to
obtain. Due to these increased administrative barriers, many
Internet Service Providers (ISPs) decide to use addresses based on
RFC 1918 for various services they provide, and use NAT to provide
global Internet connectivity for some end-customers. This type of
local control of address resources allow a clean and hierarchical
addressing structure in the network that is not restricted by the
size of the publicly routed address pool.
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 allow a clean and hierarchical addressing structure in the
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.
2.6 IPv4 and address allocation dynamics with NAT devices
Based on the amount of connections and required network services the
network design and addressing dynamics are different. It is possible
to differentiate the type of networks in four different types:
o Medium/large private networks (typically >10 connections)
o Small private networks (typically 1 to 10 connections)
o Single user connection (typically 1 connection)
o ISP/Carrier customer networks
2.6.1 Medium/large private networks
Under this category fall the majority of private enterprise networks.
Many of these networks have one or more exit points to the Internet.
There are several reasons why NAT be be used 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 address 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. Finally, the customer can provide privacy about its hosts and
the topology of its internal network if the internal addresses are
Van de Velde, et al. Expires April 12, 2005 [Page 7]
Internet-Draft IPv6 Network Architecture Protection October 2004
mapped through NAT.
2.6.2 Small private networks
This category describes those networks which have few routers in the
topology, and have a single network egress point. These networks are
also known as SOHO (Small Office/Home Office) networks. Typically
these networks don't have dedicated Network Operation Center (NOC)
and are using either a dial-up connection or broadband access. In
many cases the received global IPv4 prefix is not fixed and may add
an administrative overhead for address management to the user. An
ISP will typically have a higher cost attached to a dedicated user
IPv4 address due to his own higher administration costs with this
type of addresses.
Small networks typically deploy RFC 1918 addressing internally to
limit the explicit charges for a dedicated publicly routable
addresses. This approach also has the advantage of avoiding the
administrative overhead and dedicated NOC associated with acquiring
blocks of publicly routed address space.
2.6.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 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.
2.6.4 ISP/Carrier customer networks
This group refers to the actual service providers that are providing
the IP access. They tend to have three separate IP domains that they
support. For the first they fall into the Medium/large private
networks category (above) for their own internal networks, LANs etc.
The second is their 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. The third is the IP addresses (single or blocks) that
they assign to customers. These can be registered addresses (usually
given to category a and b and sometimes c) or can from a pool of RFC
1918 addresses used with NAT for single user connections. Therefore
they can actually have two different NAT domains that are not
Van de Velde, et al. Expires April 12, 2005 [Page 8]
Internet-Draft IPv6 Network Architecture Protection October 2004
connected (internal LAN and single user customers).
2.7 Multihoming and renumbering with NAT
The elements of multihoming and renumbering are quite different.
Multihoming is often a transitioning state for renumbering, however
NAT interacts with both in the same way.
For enterprise networks, it is highly desirable 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 [1] and/or readily change its CIDR
prefix. Unfortunately, IPv4 does not allow for either of these
maneuvers. However, if a site is connected to its ISPs via NAT
boxes, only those boxes need to deal with multihoming issues or to be
renumbered.
Similarly, if two enterprise IPv4 networks need to be merged, 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 longterm solution is a single network without usage
of NAT to avoid the ongoing operational complexity of overlapping
addresses
3. Description of the IPv6 tools
This section describes several features that can be used to provide
the protection features associated with IPv4 NAT.
3.1 Privacy addresses (RFC 3041)
Nodes use IPv6 stateless address autoconfiguration to generate
addresses without the necessity of a Dynamic Host Configuration
Protocol (DHCP) server. Addresses are formed by combining network
prefixes with an interface identifier. On interfaces that contain
embedded IEEE Identifiers, the interface identifier is typically
derived from it. On other interface types, the interface identifier
is generated through other means, for example, via random number
generation. RFC 3041 describes an extension to IPv6 stateless
address autoconfiguration for interfaces whose interface identifier
is derived from an IEEE identifier [6]. Use of the privacy address
extension causes nodes to generate global-scope addresses from
interface identifiers that change over time, even in cases where the
interface contains an embedded IEEE identifier. Changing the
interface identifier (and the global-scope addresses generated from
it) over time makes it more difficult for eavesdroppers and other
information collectors to identify when different addresses used in
Van de Velde, et al. Expires April 12, 2005 [Page 9]
Internet-Draft IPv6 Network Architecture Protection October 2004
different transactions actually correspond to the same node.
There is nothing that prevents a DHCP server from running RFC 3041
for any new MAC it hears, then remembering that for future queries.
This would allow using them in DNS for registered services since the
assumption would be a persistent value that minimizes DNS churn.
3.2 Unique Local Addresses
A unique local address (ULA) is an IPv6 unicast address format that
is globally unique and is intended for local communications [12].
These are expected NOT to be routed on the global Internet. They are
routable inside of a more limited area defined by a local network
administrator.
ULAs have the following characteristics:
o Globally unique prefix.
o Well known prefix to allow for easy filtering at network
boundaries
o Allows networks to be combined or privately interconnected without
creating any address conflicts or requiring renumbering of
interfaces using these prefixes.
o ISP independent and can be used for communications inside of a
network without having any permanent or intermittent Internet
connectivity
o If accidentally leaked outside of a network via routing or DNS,
there is no conflict with any other addresses
o In practice, applications may treat these addresses like global
scoped addresses
3.3 DHCPv6 prefix delegation
The Prefix Delegation (DHCP-PD) options [8] provide a mechanism for
automated delegation of IPv6 prefixes using the Dynamic Host
Configuration Protocol (DHCP) [7]. This mechanism (DHCP-PD) is
intended for delegating a long-lived prefix from a delegating router
to a requesting router, 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
These are globally routable IPv6 addresses which can be randomly and
dynamically assigned to IPv6 devices and are globally aggregatable
addresses assigned to the local network by either a registry or
connecting ISP. The random assignment has as purpose to confuse the
outside world on the structure of the local network, while for the
local network the location of the randomly assigned IPv6 address is
Van de Velde, et al. Expires April 12, 2005 [Page 10]
Internet-Draft IPv6 Network Architecture Protection October 2004
known and connectivity inside the local network can exist. The goal
is to create a network infrastructure which appears from external
networks with an unpredictable structure, to avoid malicious events
to happen to the local network. When using untraceable IPv6
addresses, it may be that two apparently sequential addresses are
reachable on very different parts of the local network instead of
belonging to the same subnet next to each other.
3.5 Route-injection
To complement the untraceable IPv6 addresses, it will be required to
implement a mechanism to correlate the IPv6 address with the location
of the device using the IPv6 untraceable address. This can be done
by injecting the dynamic allocated untraceable addresses into a
routing protocol.
4. Using IPv6 technology to provide the market perceived benefits of
NAT
The facilities in IPv6 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
The connection creation towards the global Internet hosts/systems
will always happen with global IPv6 addresses. An enterprise will
typically receive a global IPv6 address prefix from his connecting
IPv6 Service Provider.
4.2 IPv6 and Simple security
The vulnerability of an IPv6 host is similar as for an IPv4 host
directly connected towards the Internet, and firewall and IDS systems
are recommended. However, with IPv6, the following protections are
available without the use of NAT:
1. Short lifetimes on privacy extension suffixes reduce the attack
profile since the node will not respond to the address once the
address is no longer valid.
2. IPsec is a mandatory service for IPv6 implementations. IPsec
functions to prevent session hijacking, prevent content
tampering, and optionally masks the packet contents. While IPsec
might be available in IPv4 implementations, deployment in NAT
environments either breaks the protocol or requires complex
helper services with limited functionality.
3. The size of the typical subnet ::/64 will make a network ping
sweep and resulting port-scan virtually impossible due to the
Van de Velde, et al. Expires April 12, 2005 [Page 11]
Internet-Draft IPv6 Network Architecture Protection October 2004
amount of possible combinations available
IPv4 NAT was not developed as security mechanism. Despite marketing
messages to the contrary it is not a security mechanism, and hence it
will pose some security holes while many people assume their network
is secure due to the usage of NAT. This is directly the opposite of
what IPv6 security best-practices are trying to achieve.
An example of a potential rule could be:
Source_A: IPv6 Home broadband user
located on the internal network
Destination_B: IPv6 HTTP server
located on the external network
On the edge broadband router a security rule could be:
Internal network -> external network:
Actions:
Allow all traffic
Create reflective session state (true) for the session
External network -> internal network
Actions:
If the session had reflective 'true'-state,
then allow the inbound traffic
If the session had reflective 'false' state,
then drop the traffic
This simple rule would create similar protection and security holes
the typical IPv4 NAT device will offer and may for example be enabled
by default on all broadband edge-routers. but with that difference
that the security caveats will be documented, and may hence be
removed with the next revision of the rule. The goal is that every
iteration, the IPv6 internet will become more secure for the
oblivious users.
The increased size of the IPv6 address will make topology probing
much harder, and almost impossible for IPv6 devices. What one does
when topology probing is to get an idea of the available hosts inside
an enterprise. This mostly starts with a ping-sweep. 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. Since the IPv6 subnets are 64 bits worth of address space,
this means that an attacker has to send out many more (simply
Van de Velde, et al. Expires April 12, 2005 [Page 12]
Internet-Draft IPv6 Network Architecture Protection October 2004
unrealistic) 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
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 over IPv4 with 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.
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.
Exactly like IPv4 NAT, this only allows such a session to be traced
back to the subnet that originates it, but not immediately to the
actual host.
If a network manager wishes to conceal the internal IPv6 topology,
and the majority of its host computer addresses, a good option will
be to run all internal traffic using ULA since such packets can by
definition never exit the site. For hosts that do in fact need to
generate external traffic, by using multiple IPv6 addresses (ULAs and
one or more global addresses), it will be possible to hide and mask
some or all of the internal network. For external communication, the
global unique address(es) must be used. They can of course be
privacy addresses (see above) if required.
By using untraceable addresses, it is possible to only allocate
certain parts of the internal network with global prefixes, while
other, private network parts do not have global prefixes and remain
totally cut off from the outside. If an edge firewall is used (which
is strongly suggested) a traffic policy can be implemented as today,
based on various filtering and inspection rules. (Older techniques
such as application level proxies and SOCKS also remain available.)
An alternative method to hide the internal topology would be to use
MIPv6 internally where the public facing addresses (HA) are
consolidated on an edge Home Agent, then use MIP in tunnel mode to
the ULA as a COA. This truly masks the internal topology as all
nodes with global access appear to share a common subnet. (it
Van de Velde, et al. Expires April 12, 2005 [Page 13]
Internet-Draft IPv6 Network Architecture Protection October 2004
wouldn't really need to be a single subnet either so local policy can
run rampant trying to obscure addressing correlations.) There is no
reason that rack mounted devices shouldn't be considered mobile nodes
to mask the internal topology.
4.5 independent control of addressing in a private network
IPv6 provides for autonomy in local use addresses through ULAs. At
the same time IPv6 simplifies simultaneous use of multiple addresses
per interface so that a NAT is not required (or even defined) between
the ULA and the public Internet. Nodes that need access to the
public Internet should have a global use address, and may
simultaneously have a local use ULA. Since the IPv6 address space
for global use is not a scarce resource like it is in IPv4, each
network should be able to acquire a sufficient quantity for its
needs. While global IPv6 allocation policy is managed through the
Regional Internet Registries, it is expected that they will continue
with derivatives of RFC 3177 for the foreseeable future.
4.6 IPv6 and address allocation dynamics
In an IPv6 networks the network design and addressing dynamics are
different from those seen in IPv4 networks and the impact on the four
network types is discussed below.
o Medium/large private networks (typically >10 connections)
o Small private networks (typically 1 to 10 connections)
o Single user connection (typically 1 connection)
o ISP/Carrier customer networks
4.6.1 Medium/large private networks
Under this category fall the majority of private enterprise networks.
Many of these networks have single or more exit points to the
Internet.
It is expected that there will be enough IPv6 addresses available for
all networks and appliances in the first couple of decennia. 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 summarization benefit for the ISP is happening based on the IPv6
allocation rules. This means that the ISP will provide the
enterprise with an IPv6 address-range (typically a single or multiple
range(s) of '/48') from its RIR assigned IPv6 address-space. The
goal of this allocation mechanism is to decrease the total size of
the internet routing table.
Van de Velde, et al. Expires April 12, 2005 [Page 14]
Internet-Draft IPv6 Network Architecture Protection October 2004
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 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 host on the inside network. The
usage of IPv6 privacy extensions does not mask the internal network
structure of an enterprise network.
If there is need to mask the internal structure towards the external
IPv6 internet, then the usage of 'Untraceable' addresses may be used.
These addresses will be derived from a local pool, and may be
assigned to those hosts for which topology masking is required or
which want to reach the IPv6 Internet or other external networks.
The technology to assign these addresses to the hosts could be based
on DHCPv6. To complement the 'Untraceable' addresses it is needed to
have at least awareness of the IPv6 address location when routing an
IPv6 packet through the internal network. This could be achieved by
'route-injection' in the network infrastructure. This
route-injection could be done based on ::/128 host-routes to each
device that wants to connect to the Internet. This will provide with
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. 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 with a significant factor, but has
as trade-off that masking is time and subnet based.
The dynamic allocation of 'Untraceable' addresses, can also limit the
IPv6 access between local and external hosts to those local hosts
being authorized for this capability.
The internal topology masking could be complemented with the usage of
ULA addresses for the site local communication. The combination of
'FIXED' ULA addresses on a site, provide the benefit that even if an
enterprise would change from ISP, the renumbering is only affecting
those devices that have a wish to connect beyond the site. Internal
servers and services would not change the allocated IPv6 ULA address,
and the service would remain available even during global address
renumbering. The dynamically allocated 'Untraceable' addresses, may
also facilitate and simplify the connectivity to the outside networks
during renumbering, because the existing IPv6 central address-pool
could be swapped for the newly allocated IPv6 address-pool.
Van de Velde, et al. Expires April 12, 2005 [Page 15]
Internet-Draft IPv6 Network Architecture Protection October 2004
4.6.2 small private networks
The category describes those networks which only have only few
routers in the topology, and have a single network egress point.
These networks are also known as SOHO (Small Office/Home Office)
networks. Typically these networks don't have dedicated Network
Operation Center (NOC) and are using either a dial-up connection or
broadband access..
Currently, there are two approaches possible with respect to IPv6
addressing in this kind of network topology and design.
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 same as for
the medium/large enterprises. Typically the need for masking the
topology will not be of high priority for these organizations, 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.
4.6.3 Single user connection
This group identifies 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 the single user wants to mask his
identity, he may choose to enable IPv6 privacy extensions.
4.6.4 ISP/Carrier customer networks
This group refers to the actual service providers that are providing
the IP access. They tend to have three separate IP domains that they
support. For the first they fall into the Medium/large private
Van de Velde, et al. Expires April 12, 2005 [Page 16]
Internet-Draft IPv6 Network Architecture Protection October 2004
networks category (above) for their own internal networks, LANs etc.
and will be able to use the same solutions as above. The second is
their 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, for this it is again possible to configure a single range
of addresses with the defined local scope defined in order to prevent
these from being accessed from the public network. The third is the
IP addresses (single or blocks) that they assign to customers. These
can be registered addresses (usually given to category a and b and
sometimes c) or can from a pool of RFC 1918 addresses used with NAT
for single user connections. Therefore they can actually have two
different NAT domains that are not connected (internal LAN and single
user customers) again this will be resolved by the large availability
of addresses and the procedures mentioned above.
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-like prefixes
and thus with several simultaneous ISPs. An address selection
mechanism [9] is specified so that hosts will behave consistently
when several addresses are simultaneously valid. The fundamental
difficulty that IPv4 has in this regard therefore does not apply to
IPv6. IPv6 sites can and do run today with multiple ISPs active, and
the processes for adding and removing active prefixes at a site have
been documented [11].
The IPv6 address space allocated by the ISP will be dependent upon
the connecting Service provider. This may result in a renumbering
effort if the enterprise changes from Service Provider. To keep the
impact on the gateway when changing ISP to a zero human touch
environment, DHCPv6 Prefix Delegation [10] can be used.
5. 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.
NOTE:
Is all of the material in this section, specifically the material
that does not directly address the "advantages" of IPv4 NAT,
necessary?
Van de Velde, et al. Expires April 12, 2005 [Page 17]
Internet-Draft IPv6 Network Architecture Protection October 2004
5.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.
5.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
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 on the local link only
will be derived from the interface media layer address.
5.3 Native Multicast services
Multicast services in IPv4 were severely restricted by the limited
address space available to use for group assignments and an implicit
locally defined range for group membership. IPv6 multicast corrects
this situation by embedding explicit scope indications as well as
expanding to 4 billion groups per scope. In the source specific
multicast case, this is further expanded to 4 billion groups per
scope per subnet by embedding the 64 bits of subnet identifier into
the multicast address.
IPv6 allows also for innovative usage of the IPv6 address length, and
makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
directly in the IPv6 multicast address when using ASM multicast.
this is not possible with limited size of the IPv4 address.
Van de Velde, et al. Expires April 12, 2005 [Page 18]
Internet-Draft IPv6 Network Architecture Protection October 2004
5.4 Increased security protection
The security protection offered by native IPv6 technology is more
advanced as with IPv4 technology. There are various transport
mechanisms enhanced to allow a network to operate more secure with
less performance impact:
o IPv6 has the IPsec technology embedded directly embedded into the
IPv6 protocol. This allows for simpler peer-to-peer encryption
and authentication, 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).
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 still provides with
Unique Local Addresses, which will avoid conflict situations when
joining networks and securing the internal communication on a
local network infrastructure due to simpler traffic filtering
policy
o The technology to enable source-routing on a network
infrastructure has been enhanced to allow this feature to
function, without impacting the processing power of intermediate
network devices. The only devices impacted with the
source-routing will be the source and destination node and the
intermediate source-routed nodes. This impact behavior is
different if IPv4 is used, because then all intermediate devices
would have had to look into the source-route header. Looking into
the source-route header consumed CPU power of these devices and
was generally discouraged to be enabled on a network due to
potential Denial-of-Service attack potential.
5.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
Van de Velde, et al. Expires April 12, 2005 [Page 19]
Internet-Draft IPv6 Network Architecture Protection October 2004
5.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 legitimate 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.
5.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 on the Internet. They want the benefits of the
connectivity provided by the Internet, but do not want to be exposed
to the rest of the world. This functionality will be available
through the usage of NAP and native IPv6 dataflows, without any
stateful device in the middle.
6. IPv6 gap analysis
Like IPv4 and any major standards effort, IPv6 standardization work
continues as deployment starts. This section discusses several
topics for which additional standardization, or documentation of best
practice, is required to fully realize the benefits of NAP. None of
these items are show-stoppers for immediate usage of NAP.
6.1 Completion of work on ULAs
As noted above, a new form of Unique Local IPv6 Unicast Addresses
(ULAs) is being standardized by the IETF. Since these addresses can
be used to guarantee concealment of hosts or interfaces from the
outside unless they communicate externally, they assist NAP in
several ways, and this work should be completed as soon as possible.
Van de Velde, et al. Expires April 12, 2005 [Page 20]
Internet-Draft IPv6 Network Architecture Protection October 2004
6.2 How to completely hide subnet topology
ULAs may be used to assist in hiding subnet topology, but as
mentioned, this could be done more effectively by combining ULAs with
Mobile IP. This work should be pursued in the IETF.
6.3 Minimal traceability of privacy addresses
Privacy addresses (RFC 3041) may certainly be used within the
enterprise to limit the traceability of external traffic flows, but
they would still reveal the subnet address bits. To eliminate this,
some combination of privacy addresses with the previous two points is
required, and this work remains to be done.
6.4 Renumbering procedure
Documentation of site renumbering procedures [11] should be
completed. It should also be noticed that ULAs will help here too,
since a change of ISP prefix will only affect hosts that need an
externally routeable address as well as a ULA.
6.5 Site multihoming
This complex problem has never been well solved for IPv4, which is
exactly why NAT has been used as a partial solution. For IPv6, after
several years' work, the relevant IETF WG is finally converging on an
architectural approach intended to reconcile enterprise and ISP
perspectives. Again, ULAs will help since they will provide stable
addressing for internal communications that are not affected by
multihoming.
6.6 Untraceable addresses
The details of the untraceable addresses, along with any associated
mechanisms such as route injection, must be worked out and specified.
7. IANA Considerations
This document requests no action by IANA
8. Security Considerations
Various security and privacy benefits of both IPv4 NAT and native
IPv6 are discussed throughout this document. It does not introduce
any new security concerns.
Van de Velde, et al. Expires April 12, 2005 [Page 21]
Internet-Draft IPv6 Network Architecture Protection October 2004
9. Conclusion
This document has described a number of techniques that may be
combined on an IPv6 site to protect the integrity of its network
architecture. These techniques, known collectively as Network
Architecture Protection, retain the concept of a well defined
boundary between "inside" and "outside" the private network, and
allow firewalling, topology hiding, and privacy. However, because
they preserve address transparency where it is needed, they achieve
these goals without the disadvantage of address translation. Thus,
Network Architecture Protection in IPv6 can provide the benefits of
IPv4 Network Address Translation without the corresponding
disadvantages.
The document has also identified a few ongoing IETF work items that
are needed to realize 100% of the benefits of NAP.
10. Acknowledgements
Christian Huitema has contributed during the initial round table to
discus the scope and goal of the document
11 References
[1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[3] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[5] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001.
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
Van de Velde, et al. Expires April 12, 2005 [Page 22]
Internet-Draft IPv6 Network Architecture Protection October 2004
[8] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain,
"Representing Internet Protocol version 6 (IPv6) Addresses in
the Domain Name System (DNS)", RFC 3363, August 2002.
[9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December
2003.
[11] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day",
draft-ietf-v6ops-renumbering-procedure-01 (work in progress),
July 2004.
[12] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
progress), September 2004.
Authors' Addresses
Gunter Van de Velde
Cisco Systems
De Kleetlaan 6a
Diegem 1831
Belgium
Phone: +32 2704 5473
EMail: gunter@cisco.com
Tony Hain
Cisco Systems
500 108th Ave. NE
Bellevue, Wa.
USA
EMail: alh-ietf@tndh.net
Van de Velde, et al. Expires April 12, 2005 [Page 23]
Internet-Draft IPv6 Network Architecture Protection October 2004
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
TTI Telecom
Petach Tikvah,
Israel
Phone: +972 3 926-9130
EMail: erick@tti-telecom.com
Van de Velde, et al. Expires April 12, 2005 [Page 24]
Internet-Draft IPv6 Network Architecture Protection October 2004
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 (2004). 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 April 12, 2005 [Page 25]