Transcript IPv6 No Need for NAT (Israel Internet Society '07)

IPv6 NAP:
There is no need for NAT in IPv6
Eric Klein, MSc.
Leon Recanati Graduate School of Business Administration
and the Netvision Institute for Internet Studies,
Tel Aviv University
Note:
Based on IETF draft standard Local Network Protection for IPv6
< www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-06.txt >
Background
IPv4 - NAT
IPv6 - NAP
IP Allocation
Addresses Allocation
Address Translation
Summary
Originally IP addresses were allocated in a “classful”
method
Hosts per server:
• Class A 126 Class As
.................................... 16,777,214
• Class B 16,384 Class Bs
........................................... 65,532
• Class C 2,097,152 Class Cs ............................................... 254
•Class D
Multicast addresses
•Class E
Reserved for experimental use
For more on:
IP Classes see RFC 791
Class D Addresses see RFC 1112
Background
IPv4 - NAT
IPv6 - NAP
IP Allocation
Addresses Allocation
Address Translation
Summary
IPv4 Address Allocation History
• 1981 – IPv4 protocol published
– IP addresses used to uniquely identify
and locate IP devices
100%
90%
80%
70%
• 1985 – 1/16 of total space
60%
• 1990 – 1/8 of total space
40%
• 1995 – 1/3 of total space
20%
• 2000 – 1/2 of total space
0%
50%
30%
10%
1980
1985
1990
1995
2000
2005
2010
• 2002.5 – 2/3 of total space
This consumption despite increasingly intense conservation efforts
Current estimates predict that all IPv4 addresses will be used between
2008 and 2015, the most common prediction is sometime in 2010.
Source: Neil Lovering, Cisco Systems “IPv6 and Semantic Interoperability”
(http://colab.cim3.net/file/work/SICoP/2006-04-2728/NLovering04272006.ppt )
Background
IPv4 - NAT
IPv6 - NAP
IP Allocation
Addresses Allocation
Address Translation
Summary
RFC 1918 opened up the reserved spaces for private networks with the following
private address spaces:
• Class A: 10.*.*.*
• Class B: 172.16.*.* - 172.31.*.*
• Class C: 192.168.*.*
This was not based on a planned action, but was the reaction to common practice
codified in order to prevent future problems
Most NAT implementations use one of these 3 ranges rather than a registered
address range, or as was the practice prior to these utilizing any address space that
the network administrator wanted to use.
This enabled the deepening shortage to be offset by thousands of sites
utilizing these addresses behind NAT routers.
Then in 1993 came Classless Inter-Domain Routing (CIDR) which allowed
those large blocks of addresses to be opened up as they became available.
Effectively increasing the pool of available addresses. So each time a Class A
address was returned to the pool, instead of one company benefiting, hundreds
benefited. - For more on CIDR See RFCs 1517, 1519, and 1817
Background
IPv4 - NAT
IPv6 - NAP
IP Allocation
Addresses Allocation
Address Translation
Summary
In the early 1990’s the two most compelling problems facing the IP Internet are IP address
depletion and scaling in routing. Long-term and short-term solutions to these problems are
being developed. The short-term solution is CIDR (Classless Inter-Domain Routing). The
long-term solutions consist of various proposals for new internet protocols with larger
addresses (IPv6).
Until the long-term solutions are ready an easy way to hold down the demand for IP
addresses is through address reuse. This solution takes advantage of the fact that a very
small percentage of hosts in a stub domain are communicating outside of the domain at
any given time. Thus it was possible to use fewer addresses publicly while using Network
Address Translation to support a large pool of numbers inside an organization.
For Example: In most home networks there is only one IP address assigned that is publicly
announced, and thus addressable by outside services. This does not stop you from having more
than one computer on a home LAN. This is done via NAT in the broadband router that
connects the home to the public internet.
3
2
Without NAT = 5 public addresses
1
IP Address
4
5
With-NAT = 1 public address
Internet
Background
IPv4 - NAT
IPv6 - NAP
Why Nat?
NAT Requirements
IPv4 Problems
Summary
Originally NAT was designed because there were not enough addresses
available from the different ISPs.
• “Our ISP will only give me one address and I need to support many
computers.”
Over time other uses of NAT were found and became the “reason” for its
implementation:
• “It offers security by hiding the network topology.”
• “It is easier to configure DCHP on a NAT pool when setting up the
network.”
• “When we merge sites, manage multiple sites, it is easier to
renumber.”
For more on DHCP see RFCs 2131 and 2132
Background
IPv4 - NAT
IPv6 - NAP
Why Nat?
NAT Requirements
IPv4 Problems
Summary
Goal
Description
Simple Gateway as default router
and address pool manager
Connect a private network with addresses allocated from any part of
the space (registered & unregistered address) towards the Internet
Simple Security
Through its session-oriented operation, NAT puts in an extra barrier to
keep the private network protected from outside influences.
Local usage tracking
One usage of NAT is for the local network administrator to track user
and application traffic.
End-system privacy
One goal of 'topology hiding' is to prevent external entities from
making a correlation between the topological location of devices on
the local network. NAT hides the end device behind a wall of other
devices that use the same address but are not on the same network.
Thus giving some privacy to the host and hiding the real topology of
the LAN.
Topology hiding
Addressing Autonomy
Many private IPv4 networks make use of 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.
Global Address Pool Conservation
Use of IPv4+NAT has reduced the potential consumption rate
Renumbering and Multi-homing
Often sited as examples where NAT helps enterprises.
Background
IPv4 - NAT
IPv6 - NAP
Why Nat?
NAT Requirements
IPv4 Problems
Goal
IPv4 Solution
Summary
IPv4 Problems
Simple Gateway as
default router and
address pool
manager
DHCP - single address upstream
DHCP - limited number of
individual devices downstream
•Extra effort is needed when the same range exists on both
sides of the NAT.
• NAT works well in the client/server model . For peer-topeer, multi- party, or servers deployed on the private side
of the NAT, helper technologies must also be deployed
Simple Security
Filtering side effect due to lack of
translation state
Experienced hackers are well aware of NAT devices and
are very familiar with private address space, and have
devised methods of attack that readily penetrate NAT
boundaries.
Local usage
tracking
NAT state table
Checking of this database is not always a simple task,
especially if Port Address Translation is used.
End-system
privacy
NAT transforms device ID bits in
the address
Topology hiding
NAT transforms subnet bits in the
address
Scanning is a particular concern 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.
Addressing
Autonomy
RFC 1918
Can cause problems when merging networks or moving
between ISPs.
Global Address
Pool Conservation
RFC 1918 << 248 application end
points topology restricted
Over use leads to cascading NATs, or multiple LAN using
the same address spaces, and many do not filter properly.
Renumbering and
Multi-homing
Address translation at border
IPv4 was not designed to facilitate either of these
maneuvers. However, only the NAT boxes need to deal
with multi-homing and renumbering issues.
Background
IPv4 - NAT
IPv6 - NAP
Summary
History
IPv6 Solutions
Private Addresses
Untraceable Addresses
Started in 1994 IPv6 was originally conceived of as the evolution of the IP
address pool and an update of the protocol architecture.
IPv6 has been heralded as the savior of the Internet by offering all sorts of
catch phrases:
• “An IP address for everyone alive today born in the next 100 years.”
• “It is more secure than IPv4 because it has IPSec built in.”
• And others.
As you have heard in the other presentations in this panel, IPv6 is coming,
some would say that it is already here as services are available from many
different ISPs while software and hardware vendors are including support
for the protocol for up to the past 4 years.
There is a reality that you need to understand:
IPv6 is being resisted by companies that don’t want to spend money to
upgrade but it is mandated by many governments starting in 2008.
Background
IPv4 - NAT
IPv6 - NAP
Summary
History
IPv6 Solutions
Private Addresses
Untraceable Addresses
Goal
IPv4 Problem
IPv6 Solution
Simple Gateway as
default router and
address pool manager
•Extra effort is needed when the same range
exists on both sides of the NAT.
• For peer-to-peer, multi- party, or servers
deployed on the private side of the NAT, helper
technologies must also be deployed
IPv6 routers should have a default configuration to advertise
inside the site a locally generated random Unique Local
Address (ULA) prefix, independently from the state of any
external connectivity
Simple Security
Experienced hackers are well aware of NAT
devices and are very familiar with private
address space, and have devised methods of
attack that readily penetrate NAT boundaries.
Short lifetimes on privacy extension suffixes.
IPsec is often cited as the reason for improved security
because it is a mandatory service for IPv6 implementations.
The size of a typical subnet makes a complete subnet ping
sweep usually significantly harder and more expensive
Local usage tracking
Checking of this database is not always a simple
task, especially if Port Address Translation is
used.
IPv6 enables the collection of information about data flows.
End-system privacy
Scanning is a particular concern 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.
Temporary use privacy addresses based on RFC 3041 pseudorandom privacy addresses which are generated as required
Addressing Autonomy
Can cause problems when merging networks or
moving between ISPs.
IPv6 provides for autonomy in local use addresses through
ULAs and simplifies simultaneous use of multiple addresses
per interface
Global Address Pool
Conservation
Over use leads to cascading NATs, or multiple
LAN using the same address spaces, and many
do not filter properly.
17*1018 subnets 3.4*1038 addresses full port list giving an
unrestricted topology
Renumbering and
Multi-homing
IPv4 was not designed to facilitate either of these
maneuvers.
Preferred lifetime per prefix & Multiple addresses per
interface
Topology hiding
Untraceable addresses using IGP host routes /or MIPv6
tunnels
Background
IPv4 - NAT
IPv6 - NAP
Summary
History
IPv6 Solutions
Private Addresses
Untraceable Addresses
In IPv4 there was no way to officially have private addresses, so Network
Admins would randomly choose a set of addresses and use them
internally. Initially this was fine as LANs were local only. This became a
problem when the addresses chosen were registered to other companies
and then the various LANs were connected to the Internet. To solve this
NAT and the private address spaces were assigned.
In IPv6, learning from the past, Unique Local Addresses (ULAs) were
defined with the following characteristics:
• For all practical purposes a globally unique prefix.
• Allows networks to be combined or privately interconnected without
creating address conflicts or requiring renumbering.
• 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.
• ISP independent and can be used for communications inside of a network.
• Well-known prefix to allow for easy filtering at network boundaries.
• In practice, applications may treat these addresses like global scoped
addresses.
Background
IPv4 - NAT
IPv6 - NAP
Summary
History
IPv6 Solutions
Private Addresses
Untraceable 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.
Since IPv6 addresses will not be in short supply even within a single /64
(or shorter) prefix, it is possible to generate them effectively at random
when untraceability is required. They will be globally routable IPv6
addresses under the site's prefix, which can be randomly and
independently assigned to IPv6 devices. The random assignment is
intended to mislead the outside world about the structure of the local
network.
As the DHCP algorithm can include a random seed, two hosts connecting
one after the other can have addresses that are non-sequential.
Background
IPv4 - NAT
IPv6 - NAP
Conclusions
Status of the Draft
Acknowledgements
Summary
Companies that have traditionally relied on NAT for security and
ease of numbering will no longer need it under IPv6.
For companies where multiple networks/segments exist, but must
maintain independence between them like
• Service Providers with both public ISP and private
management networks
• Large corporations with special security requirements for
some subnets (finance dept., legal dept., Development vs. Live
networks, etc.)
It is possible to assign specific ULAs to those special areas, filter
them at the router while maintaining global connectivity.
Background
IPv4 - NAT
IPv6 - NAP
Conclusions
Status of the Draft
Acknowledgements
Summary
Status of the draft standard Local Network Protection for IPv6
Detail Info
Draft Name:
draft-ietf-v6ops-nap-06.txt (WG <v6ops> submission)
Version:
06
Intended Status: Informational
Current State:
Approved-announcement to be sent (14-02-2007)
Approved-announcement to be sent:
The IESG has approved the document for publication, but the
Secretariat has not yet sent out on official approval message.
• A RFC number should be assigned within 2 months due to the backlog in
the RFC editor.
Latest version can be found at:
www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-06.txt
Background
IPv4 - NAT
IPv6 - NAP
Conclusions
Status of the Draft
Acknowledgements
I would like to thank my fellow authors:
Gunter Van de Velde of Cisco Systems
Diegem, Belgium
Tony Hain of Cisco Systems
Bellevue, WA. USA
Ralph Droms of Cisco Systems
Boxborough, MA USA
Brian Carpenter of IBM
Vernier, Switzerland
Summary
Thank You
Eric Klein
[email protected]
This Presentation can be found at:
http://www.tau.ac.il/~ericklei/ISOC-IL-2007-No-Need -For-NAT.pdf