One document matched: draft-daley-ipv6-nonat6-01.txt
Differences from draft-daley-ipv6-nonat6-00.txt
Network Working Group G. Daley
Internet-Draft July 14, 2009
Intended status: Standards Track
Expires: January 15, 2010
Achieving Addressing Functions in IPv6 without using NAT
draft-daley-ipv6-nonat6-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 15, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Proposals have been made to include Network Address Translation (NAT)
in IPv6. Network Address Translation substitutes a source address in
the outbound Packet headers at the Internet Egress point for one
Daley Expires January 15, 2010 [Page 1]
Internet-Draft IPv6 Function without NAT July 2009
present at the network edge. It then matches the responding packets
by destination address, and restores the original headers.
NAT itself is not a feature. It is a mechanism which provides
features at an application cost. This document identifies features
which are supplied by NAT in IPv4 and how these features may be
provisioned in IPv6. Both NAT and application-friendly alternatives
are presented.
Daley Expires January 15, 2010 [Page 2]
Internet-Draft IPv6 Function without NAT July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Relationship to previous work . . . . . . . . . . . . . . 4
1.2. Existing NAT Models for IPv6 . . . . . . . . . . . . . . . 5
1.3. Application impacts of existing NAT deployments . . . . . 5
1.3.1. Behaviour of some port address translating IPv4
NATs . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Network Topology Hiding in IPv6 . . . . . . . . . . . . . . . 6
2.1. Network Topology Hiding using Stateful Mappings . . . . . 7
2.2. Network Topology Hiding using Stateless Mappings . . . . . 7
2.2.1. Prefix Only Transformations . . . . . . . . . . . . . 7
2.2.2. Prefix and Suffix Transformations . . . . . . . . . . 8
2.3. Source Address Mappings and NAT . . . . . . . . . . . . . 8
3. Provider Independence in IPv6 . . . . . . . . . . . . . . . . 9
3.1. Using Provider Aggregatable Addresses for Multihoming . . 9
3.1.1. Aggregatable Addresses and host selection . . . . . . 9
3.1.2. Provider Aggregatable Addresses and gateway
selection . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3. Limits of Provider Aggregatable Addressing . . . . . . 11
3.2. Provider Independent Addressing and Multihoming . . . . . 12
4. Reduce impacts on the global routing table . . . . . . . . . . 14
5. No prefix reassignment on ISP change . . . . . . . . . . . . . 14
6. Address Amplification . . . . . . . . . . . . . . . . . . . . 16
7. Alternatives to NAT for Network Topology Hiding . . . . . . . 16
7.1. Local Tunnels For network topology hiding . . . . . . . . 17
7.2. Translation extension headers For network Topology
Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Address Allocation Channel for NAT . . . . . . . . . . . . 20
8. Problems with NAT and Topology Hiding . . . . . . . . . . . . 20
9. Problems with Local Delivery mechanisms and Topology Hiding . 20
9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Local Transport . . . . . . . . . . . . . . . . . . . . . 21
9.3. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . 21
9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 21
9.5. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 21
9.6. Source Address Selection . . . . . . . . . . . . . . . . . 21
10. General problems with Topology Hiding and the Internet . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Daley Expires January 15, 2010 [Page 3]
Internet-Draft IPv6 Function without NAT July 2009
1. Introduction
Network Address Translation substitutes a source address in the
outbound Packet headers at the Internet Egress point for one present
at the network edge. It then matches the responding packets by
destination address, and restores the original headers [RFC2663].
For some applications, changes in packet headers mismatch application
semantics, requiring in-band NAT detection or helper services such as
STUN [RFC3489][RFC3947]. The experience with IPv4 has shown that
implementing NATs in network gateways is simple, taking few man-
months to achieve a production ready solution. The impact of Network
Address Translation on IPv4 applications development has been
significant, with development of peer-to-peer and address referring
applications being hampered [RFC2993].
Until now, NATs have only existed for IPv4, and for transitioning
from an IPv6 network to an IPv4 network [RFC2766]. Current IPv6 NAT
proposals aim at providing the following functions, aimed at
providing "Feature Parity" with IPv4 [I-D.mrw-behave-nat66]:
* Topology Concealment
* Provider Independence
* Reduce impacts on the global routing table
* No prefix reassignment on ISP change
* Address Amplification
This document explores each of these features and identifies
capabilities and gaps within the IPv6 protocol suite to deliver them.
1.1. Relationship to previous work
The discussion in this document can be seen as an adjunct to existing
descriptions of IPv6 and NAT relationships [RFC2993].
Particularly, previous work on Local Network Protection is described
in RFC4864 [RFC4864]. This document provides encyclopedic
description of alternatives to NAT technologies in delivering
addressing features in IPv6. In comparison, the current document
provides specific analysis of features and direct comparison of
proposed measures for local IPv6 packet delivery.
Further work is required to consolidate this analysis either to
supplement the information in RFC 4864, or specialize in the
particular area of most benefit.
Daley Expires January 15, 2010 [Page 4]
Internet-Draft IPv6 Function without NAT July 2009
1.2. Existing NAT Models for IPv6
Current NAT proposals for IPv6 allow for a stateless mapping of IPv6
address or prefix at the network boundary [I-D.mrw-behave-nat66], or
more traditional stateful NAT and PAT [RFC2663].
Stateful NAT systems store information regarding the interior address
used for communication, and allocate another exterior address for
communication on the Internet. If packets arrive at another gateway
which does not have this stored state, communications fail as no
mapping can be made to an interior address.
Stateless NAT systems use an algorithmic mapping to identify the
exterior address to use on outbound packets, and the reverse mapping
to identify the interior address for inbound packets. The scope of
the changes depends on the algorithm and its parameters. Arrival of
an inbound packet at another gateway will generate the same interior
address, so long as the algorithm and parameters are uniformly
configured.
1.3. Application impacts of existing NAT deployments
While implementation of either stateless or stateful NAT in a gateway
is relatively simple to perform, the implications for application
programmers are significant.
Applications which contain addresses for referral cannot discern
their exterior address locally. This means inbound connections can
only be provisioned by long term static configuration, or by
determination at application run-time of the exterior IP.
Existing IPv4 deployment relies heavily on address and port address
translation [RFC2766], which has the additional impact that inbound
connections cannot consistently be mapped to the same internal
address [RFC4787]. As such, mechanisms are required which identify
the availability and reachability of sessions at particular ports and
addresses.
Daley Expires January 15, 2010 [Page 5]
Internet-Draft IPv6 Function without NAT July 2009
+---+ SrcIP 192.1.0.1 DstIP 192.1.0.50 +---+
Host A | | SrcPort: 23456 DstPort: 5080 | |
\--|---|------------------------------------>| |
| | | |
| | DstIP 192.1.0.1 SrcIP 192.1.0.50 | |
| | DstPort: 10001 SrcPort: 10234 | |
| X |<------------------------------------| |
Host B | | | |
+---+ +---+
Port Server
Translator
A Port translating NAT receiving an unmapped inbound communication
1.3.1. Behaviour of some port address translating IPv4 NATs
Existing NAT IP testing is provided by in-band addressing tests
[RFC3489], and by either in-band relaying through external devices
[I-D.ietf-mmusic-ice] or hole-punching to establish. Both of these
mechanisms rely upon the availability, trust and trust of third parth
devices outside the perimeter of the organization.
Even where a one-to-one or pool mapping of addresses is available in
NAT, applications cannot make assessments about their visible
addresses without contacting the exterior network. Where information
is provided between end devices, each endpoint must understand that
addresses can change in transit.
2. Network Topology Hiding in IPv6
NAT in IPv4 is used also to prevent simple disclosure of topological
structures in corporate network environments. This may be performed
in order to limit data loss, for commercial purposes, or to reduce
information flows due to security concerns [I-D.iab-ipv6-nat].
Proposals for using NAT within IPv6 cite topology hiding as a
requirement. Current IPv6 NAT proposals allow for a stateless
mapping of an IPv6 address or prefix, or traditional NAT and Port
Translation. Other proposals which provide topology hiding use
tunnel mechanisms [RFC3775] or discover local routing identifiers for
packet transit [I-D.thaler-ipv6-saf].
Independent of whether NAT is in use, topology hiding requires a
mapping between external addressing and internal addressing. The
delivery of topology hiding within these environments is examined
below.
Daley Expires January 15, 2010 [Page 6]
Internet-Draft IPv6 Function without NAT July 2009
2.1. Network Topology Hiding using Stateful Mappings
If using existing stateful address mapping mechanisms for topology
hiding, information is lost to the external viewer. This loss of
information occurs where the exterior address pool is smaller than
the available interior addressing, or where allocation of an exterior
address loses structure.
I::A -----------> G::A'
State
Allocation
I::B -----------> G::B'
such that B' =/=> B and A ' =/=> A,
Stateful mapping operations require a return packet from the Internet
to be routed by the original gateway or one to which its state
mappings have been distributed.
State held within the network may be significantly less than the
number of hosts in the network. Address reallocation over time could
allow further compression of the number of exterior addresses.
2.2. Network Topology Hiding using Stateless Mappings
For Stateless address mapping mechanisms, an algorithm provides a
one-to-one correspondence between interior addresses and externally
visible addresses [I-D.ietf-behave-v6v4-xlate]. This relies upon an
algorithmic transform T, which may have site specific parameters,
such as internal (I) and external prefixes (G), and a site key (k).
Inbound packets use the inverted transform, to restore the original
address.
T(I,G,k)
Interior --------------> Exterior
Address <-------------- Address
________
T(I,G,k)
2.2.1. Prefix Only Transformations
Existing IPv6 NAT proposals specify a stateless prefix mapping for
addresses [I-D.mrw-behave-nat66]. Using this transform, only the
prefix information is changed, with the subnet portion of the prefix
being exchanged using the Transform Tp.
Daley Expires January 15, 2010 [Page 7]
Internet-Draft IPv6 Function without NAT July 2009
Tp(I,G,k)
I:A::C <-------------> G:A'::C
I:B::D <-------------> G:B'::D
I:B::E <-------------> G:B'::E
_________
Tp(I,G,k)
This exchange preserves information about which links and prefixes
are related, which doesn't hide topology. It only hides the mapping
of the internal prefix number.
2.2.2. Prefix and Suffix Transformations
Where IPv6 prefixes and suffixes are transformed, and there is a
stateless mapping between internal and external addresses, beyond the
site prefix (G or I). The transforms Tps applies these changes.
Tps(I,G,k)
I:A::C <-------------> G:T::U
I:B::D <-------------> G:V::W
I:B::E <-------------> G:X::Y
__________
Tps(I,G,k)
Information about relationships between topological elements may be
obscured, since suffixes are changed. The number of unique hosts
communicating on the network cannot be obscured though because
stateless transforms require a one-to-one mapping between interior
and exterior addresses.
Maintaining topology secrecy relies entirely upon keeping the mapping
transform secret. Where it makes sense to standardize the base
transforms, the importance of the site specific key (k) becomes
critical.
2.3. Source Address Mappings and NAT
Each of the above approaches may be deployed with NAT for the purpose
of internal topology hiding. Alternatives which make similar
mappings can achieve the same topology hiding without the impact of
NAT on applications.
Daley Expires January 15, 2010 [Page 8]
Internet-Draft IPv6 Function without NAT July 2009
Some of these alternatives are explored below in Section 7.
3. Provider Independence in IPv6
One of the motivations for IPv6 Network Address Translation is to
gain provider independence [NAT66pres]. Provider independence allows
packets to transit through either one Internet Service Provider (ISP)
or another. In order to achieve provider independence, addresses
advertisable through multiple ISPs are required, or multiple ISP
specific addresses need to be used.
IAB/IESG Recommendations on IPv6 Addresses [RFC3177] provides
guidelines for address allocations to sites. It identifies that
sites may require multihoming mechanisms, although it doesn't
identify valid multihoming schemes.
3.1. Using Provider Aggregatable Addresses for Multihoming
Default IP address allocations in IPv6 and IPv4 are provider
aggregatable (dependent). These addresses are advertisable through
one ISP and provide routing scalability through summarization
[RFC4291]. With multiple provider aggregatable connections,
multihoming can be provided using either address selection on the
end-host, or on a gateway (for example by using NAT).
3.1.1. Aggregatable Addresses and host selection
The below shows how addressing is presented to hosts from multiple
ISPs, along with any stable local prefix (The stable addressing in
this case comes from Unique Local Addresses [RFC4193]).
Daley Expires January 15, 2010 [Page 9]
Internet-Draft IPv6 Function without NAT July 2009
+------+ +------+
| ISP1 | | ISP2 |
+------+ +------+
^ ^ ---
\ / |
PA1::/48\ /PA2::/48 |
V/------\V |
/ \ |
|Firewall| |
|/Gateway| --- |Range of
+--------+ | | Prefix
: | |PA2::/48
: Range of| |
+---+ Prefix | |
| R | ULA::/48| |
+---+ | |
|PA1:C::/64 | |
|ULA:C::/64 | |
VPA1:C::/64 | |
+--------+ | |
Host: |PA1:C::M| | |
|ULA:C::N| --- ---
|PA2:C::R|
+--------+
Multihoming using routed provider aggregatable prefixes
Each of the prefixes is applied across the network and hosts receive
router advertisements or DHCPv6 address allocations with the prefixes
[RFC4861][RFC4862][RFC3315]. Hosts then have multiple addresses
configured, and make assessments within applications to use all or
one of the addresses.
Assessments of whether a local or global address is used would be
based on internal policy (NOTE: This makes assumptions about the
status of [RFC3484]). Network connectivity through the address lasts
as long as the provider aggregatable prefix is valid, although if
connectivity through an ISP fails, application connectivity may
break.
This is because TCP binds a source IP/Dest IP/Source Port/Dest Port
tuple. Unavailablity of the path between these endpoints will impact
applications [RFC5533]. Applications able to withstand individual
connection failures will be able to survive path failures. Otherwise
application sockets or APIs may present error conditions [RFC2553].
Daley Expires January 15, 2010 [Page 10]
Internet-Draft IPv6 Function without NAT July 2009
3.1.2. Provider Aggregatable Addresses and gateway selection
Where a gateway exists on the path to the Internet, choice of ISP
paths can be made by that gateway, as shown below. Internally the
network operates with a local address plan, and the gateway
substitutes or translates packet headers in order to load balance or
provide some robustness in accordance with site policy.
+------+ +------+
| ISP1 | | ISP2 |
+------+ +------+
^ ^ ---
\ / | Range of
PA1::/48\ /PA2::/48 | Prefix
V/------\V | PA2::/48
/ \ ---
|Firewall| Translate/Present PA1,PA2
|/Gateway| ---
+--------+ |
: |
: | Range of
+---+ | Prefix
| R | | ULA::/48
+---+ |
| |
|ULA:C::/64 |
V |
+--------+ |
Host: |ULA:C::N| |
| | ---
+--------+
This scenario has the same session survivability challenges
illustrated by the host selected provider aggregatable addressing.
This scenario has the additional issue that that if address
translation occurs without explicit involvement of the host, failures
of one routing path are not readily identifiable to the host.
Even when the gateway fails over to another ISP's addresses, existing
sessions will fail, and new sessions succeed. even though the local
addressing plan has not changed.
3.1.3. Limits of Provider Aggregatable Addressing
Where Provider Aggregatable addresses are used for multihoming,
control over inbound connection requests is diminished. Content
providers typically provide information about services through domain
Daley Expires January 15, 2010 [Page 11]
Internet-Draft IPv6 Function without NAT July 2009
name mechanisms [RFC1035][RFC3596]. A lookup of name to IP address
mapping occurs, and the client selects one of the available addresses
for the service.
For example, if a company has the following Provider Aggregatable
prefixes from different ISPs, it may provision two IP addresses
[RFC3849]:
2001:DB8:0000:/48 -> 2001:DB8:0000:0003:0200:5eff:fe78:9abc
2001:DB8:ffff:/48 -> 2001:DB8:ffff:0003:0200:5eff:fe78:9abc
An IPv6 (AAAA) domain name lookup for www.example.com would return
both of these records either from cache or from the originating DNS
server. Content providers have little control over which of these
addresses are used by clients to initiate sessions.
Where a client uses TCP to connect to a content service, it selects
one of the server IP addresses, which with provider aggregatable
addressing determines which of the ISPs will deliver the traffic.
Leaving the selection of the ISP to the client is undesirable
particularly if one of the service providers has capacity constraints
or is more costly to utilize.
An alternative solution is to use provider independent addressing.
3.2. Provider Independent Addressing and Multihoming
Provider Independent (PI) address prefixes may be advertised through
multiple ISPs simultaneously. PI addresses are advertised
individually according to the source organization's routing policy.
Announcements from two or more ISPs are typical, with BGP parameters
being set to identify which path is best [RFC4271][RFC4760].
This sort of control over path selection toward a particular address
ensures flexibility for content providers. Additionally, outbound
sessions gain survivability from a particular ISP failure, without
impacting sessions. This is due to the preservation of IP addressing
at the application, that is unavailable using provider aggregatable
addresses.
Initially, IPv6 address allocation policy did not include Provider
Independent addressing in order to reduce the number of prefixes
advertised within the Internet. The desire of existing multihomed
content providers to retain equivalent inbound traffic control
contributed to the regional internet registries allowing allocation
of IPv6 provider independent addressing for all sites which are
currently multihomed [APNICv6MH].
Daley Expires January 15, 2010 [Page 12]
Internet-Draft IPv6 Function without NAT July 2009
Current (2009/04) allocation policy provides provider independent
addressing for IPv6 on exactly the same terms as IPv4. Please note
that in the past, early adopting organizations received PI address
blocks even though they were not multihomed. The current policy does
not extend PI IPv6 addresses to these organizations. Please also
note that policies to acquire new provider independent IPv4
addressing may change as addresses become scarce.
In order to provide a stable internal address plan with multiple
providers, organizations will likely use a local addressing plan such
as Unique Local Addressing [RFC4193]. In the typical case, the PI
address plan is deployed across the internal infrastructure of the
network, in parallel to any local addressing scheme. This is shown
below.
+------+ +------+
| ISP1 | | ISP2 |
+------+ +------+
^ ^ ---
\ / |
PI::/48\ /PI::/48 |
V/------\V |
/ \ |
|Firewall| |
|/Gateway| --- |Range of
+--------+ | | Prefix
: | |PI::/48
: Range of| |
+---+ Prefix | |
| R | ULA::/48| |
+---+ | |
|PI:C::/64 | |
|ULA:C::/64 | |
V | |
+--------+ | |
Host: |PI:C::M | | |
|ULA:C::N| --- ---
+--------+
Multihomed provider aggregatable prefixes using routing and source
address selection.
Alternatively, connectivity can be delegated to the gateway, which
would require a NAT or local delivery scheme to send packets within a
locally addressed network.
Daley Expires January 15, 2010 [Page 13]
Internet-Draft IPv6 Function without NAT July 2009
4. Reduce impacts on the global routing table
Provider independence of internal packet delivery can be achieved
without network renumbering by making use of either Provider
Independent Addressing or Network Address Translation.
Network Address Translation can be used along with provider
aggregatable addressing, to ease transition operations when changing
ISPs. This means that the addressing which is tied to carriers can
be aggregated to a single set of routes advertised in the network
core.
With Provider Independent addressing, addresses may be retained when
a ISP change occurs. As such they are not able to be aggregated or
summarized within the Internet routing table.
Note that the current IPv6 allocation policy results in an IPv6
routing table with a number of routes not greater than the equivalent
IPv4 routing table. While this system does not curtail growth of the
internet routing table, the overall impact in the number of churned
routes should still be no greater than that of IPv4, especially
considering that the provider aggregatable address space will not
need to be so fragmented.
5. No prefix reassignment on ISP change
With provider aggregatable addresses, when an organization connects
to a new ISP, they need to renumber their external addressing plan.
Where no gateway NAT or local delivery scheme is in place, they will
also need to renumber their internal addressing.
In IP, renumbering Provider Aggregatable addresses upon ISP change is
limited to those hosts that hold exterior addresses (or provide
lookup records for them, as in DNS), and devices performing Network
Address Translation. It is desirable that the transitions in IPv6
are able to replicate the ease of transition available within IPv4.
Daley Expires January 15, 2010 [Page 14]
Internet-Draft IPv6 Function without NAT July 2009
/-------------\ /-------------\
/ PA1::/32 \ / PA2::/32 \
| | | |
\ +------+ / \ +------+ /
\-----| ISP1 |/ \| ISP2 |-----/
+------+ +------+
^ ^ ---
\ / |Range of
PA1:D::/48\ /PA2:E::/48 | Prefix
V/------\V |PA2:E::/48
/ \ ---
|Firewall|
|/Gateway| ---
+--------+ |
: |
: Range of|
+---+ Prefix |
| R | ULA::/48|
+---+ |
| |
|ULA:C::/64 |
V |
+---------+ |
|ULA:C::Q | ---
+---------+
Route injection from multihomed provider aggregatatble prefixes
Where similar function is to be deployed, it remains useful to
determine if the capability can be acquired without damage to
applications as would occur with Network Address Translation.
Unlike IPv4 though, parallel network addressing infrastructure is
available and supported by all hosts [RFC4294]. Internal addressing
plans based on Universal Local Addressing (ULA) [RFC4193] provide
stable local addresses for internal corporate resources regardless of
the addresses to be used on the Internet. This means that if
renumbering is deployed to end hosts either through on-link
configuration [RFC4862] or DHCPv6 [RFC3315], internal connectivity
will not be interrupted.
Additionally, DHCPv6 prefix delegation [RFC3633] provides means for
changing IPv6 Address allocations on routers in a non-disruptive
fashion [RFC4193].
Daley Expires January 15, 2010 [Page 15]
Internet-Draft IPv6 Function without NAT July 2009
6. Address Amplification
Address amplification is used to serve multiple addresses or subnets
by a smaller address allocation. This allows for preservation of
address space, or making use of address space otherwise insufficient
to route for all local devices.
This feature of NAT has been extensively used in IPv4 because of
insufficient allocation of IP addresses to homes and businesses.
The IAB and IESG recommendations for IPv6 site address allocations
identify three models allows for address delivery [RFC3177]:
1. typical deployments of addresses receive a /48 prefix, which
supplies 65536 subnets per organization.
2. When by design only a single subnet is required, a /64 may be
allocated.
3. When absolutely only one device is connecting, a /128 is
allocated.
Discussions within the IETF about alternative deployments allow for
the specification of an intermediate allocation at /56, allowing for
256 subnets for a household use.
In either this case, or case 1 above, the number of subnets which can
be served by each prefix allocation may be sufficient to avoid NAT or
address amplification operations.
For case 2, the unforseen usage of additional devices may later
become an issue requiring address amplification. In these cases, a
local addressing mechanism is required to allocate addressing to edge
devices.
In order to achieve address amplification, state must be kept, which
identifies which of the public address resources is currently in use.
This precludes all stateless schemes. Consequently local tunneling,
Translation extension headers, stateful NAT and NAT with address
allocation channels may all be used with a smaller number of external
addresses than internal addresses.
7. Alternatives to NAT for Network Topology Hiding
NAT's principal problems are associated with a lack of address
knowledge in applications [RFC2993][RFC5389]. Alternatives to NAT
require a way of allocating external addresses to applications before
Daley Expires January 15, 2010 [Page 16]
Internet-Draft IPv6 Function without NAT July 2009
bindings at the application programming interface occur
[RFC3775][I-D.thaler-ipv6-saf]. This allows applications to function
independently of whether an address is translated or not.
Once the exterior address is allocated, devices at the network
perimeter need to handle delivery and transmission of packets for
interior devices. The location of such devices separate to the hosts
provides opportunities for topology hiding.
Each of these local delivery mechanisms requires a protocol to be run
between the host and network. Participants are likely to be the
internet access gateway itself, and the host participating in the
communications.
7.1. Local Tunnels For network topology hiding
As presented at IETF 74 by Dave Thaler, local tunnelling provides
equivalent support for address hiding, when deployed at the network
perimeter.
^ ^
: .
: .
: .
G:T::U V V G:V::W
+-----+ +-----+
______| GW1 |_______| GW2 |______
| | | |
+-----+ +-----+
|^| \^\
|:| \.\
|:| \.\
|:| \.\
I:A::C |V| \V\ I:B::D
+-----+ +-----+
| | | |
| | | |
+-----+ +-----+
VIP=G:T::U VIP=G:V::W
Use of a local tunnel to a gateway
Devices discover a gateway using local configuration mechanisms, such
as DHCPv6 [RFC3315][RFC3736] or IPv6 Router Discovery [RFC4861]. A
tunnel is established to the gateway, and either a stateful
relationship is established, or an algorithmic mapping of addresses
Daley Expires January 15, 2010 [Page 17]
Internet-Draft IPv6 Function without NAT July 2009
(such as identified for stateless NATs above) is used to provide IP
addressing information.
The local topology hiding mechanisms are bound by the same
limitations as for the equivalent mechanism under NAT. Applications
have the advantage that they are able to bind virtual IP addresses
associated with the allocated address. This removes the requirement
for in-band address discovery mechanisms prevalent in IPv4 [RFC3849].
Hierarchical Mobile IPv6 provides an example of one such tunneling
mechanism. It incorporates discovery mechanisms, a stateful binding
of addresses, and an ability to update stateful bindings (as is
necessary for mobile environments).
Explicit tunnel systems allow for failover by directing
communications through an alternate gateway. Topology hiding is
preserved, and existing communications continue after tunnel
connection repair. This is not a service available with stateful
Network Address Translations.
^ ^
: .
: .
: .
G:T::U V V G:V::W
+-----+ +-----+
______| GW1 |_______| GW2 |______
| | | |
+-----+ +-----+
/:/ |^|
/:/ |.|
/:/ |.|
/:/ |.|
I:A::C /V/ |V| I:B::D
+-----+ +-----+
| | | |
| | | |
+-----+ +-----+
VIP=G:T::U VIP=G:V::W
Failover to alternate gateway
7.2. Translation extension headers For network Topology Hiding
Tony Hain identified a mechanism for providing topology hiding
through use of an IPv6 extension header that replaces a packet source
address when passing through a gateway or firewall.
Daley Expires January 15, 2010 [Page 18]
Internet-Draft IPv6 Function without NAT July 2009
A routing header could be constructed and placed on the packet, to be
examined upon passage through the gateway. This header would contain
the topologically correct exterior address for the interior host.
The gateway would save the interior->exterior address mapping, and
pass the packet upstream toward the destination.
Inbound packets would be modified with a routing or desintation
header to include the path taken upon ingress through a gateway. The
original header is presented to upper layer applications as the
application address.
Inbound
A:B +--+ A:B1 D[B] +--+ A:B2 D[B,B1] +--+ A:B3 D[B,B1,B2]
----->| |---------->| |------------->| |---------------->
+--+ +--+ +--+
Example inbound packet flows with multiple levels of NAT using
routing header
Outbound data flows use information about exterior addressing within
the application, and encapsulate data with information about external
addresses in a routing header, along with the internal address
comprising the packet header.
Outbound
B:A +--+ B1:A R[B] +--+ B2:A R[B1,B] +--+ B3:A R[B2,B1,B]
<-----| |<----------| |<-------------| |<----------------
+--+ +--+ +--+
Example outbound packet flows with multiple levels of NAT using
routing header
As packets pass through a gateway, the source address is replaced
with an address from the next routing header. The contents of the
routing extension header allow outbound mapping, or stored state to
be created on a gateway. This allows the packet to pass to an
exterior network containing only the source address information
visible to the exterior domain.
Outbound packets reaching a gateway without valid routing header
information are rejected by ICMP message. This causes systems to
learn the location and addressing requirements of the gateway, if
necessary for internet access. Additionally, policy could be
specified in the first instance by DHCP.
Daley Expires January 15, 2010 [Page 19]
Internet-Draft IPv6 Function without NAT July 2009
Mappings can be stateless, or stateful as for pool NATs. The same
mapping criteria for Topology Hiding apply.
7.3. Address Allocation Channel for NAT
It is possible to perform Network address translation in a way that
allows applications to bind to the exterior address. This requires
an address allocation channel which informs interior devices of their
exterior IP address mapping.
For stateless mappings, this entails informing the hosts as to their
transform algorithm. Devices communicating through the gateway can
then identify.
For stateful mappings, a communication with the gateway would be
required, although packets themselves would require no additional
tunnel or header components.
In both of these cases, identification of internal destinations would
be valuable to ensure that application address allocation uses an
appropriate address.
Due to the addition of a discovery channel, this has been categorized
as a local delivery mechanism, rather than a pure NAT.
8. Problems with NAT and Topology Hiding
Since applications are initially unaware of their public addresses,
and the boundary where topology hiding is present. Protocols
expressing identity or addressing information may require testing and
application awareness.
Indeed, the predominant NAT and Firewall traversal mechanisms used in
IPv4 perform initial NAT mapping tests using native source addresses.
Additionally, network applications such as traceroute can identify
those hosts which share hop-distance and delay. In some
circumstances it is possible to construct the topology solely from
such information.
9. Problems with Local Delivery mechanisms and Topology Hiding
Local delivery mechanisms that avoid NAT have a series of issues
which must be managed.
* Discovery
Daley Expires January 15, 2010 [Page 20]
Internet-Draft IPv6 Function without NAT July 2009
* Local Transport
* MTU issues
* Backward compatibility.
* Recursion
* Source Address Selection.
9.1. Discovery
Local delivery mechanisms require new and reliable mechanisms which
describe operations at the network boundary.
Additionally, the correct operation of existing IPv6 devices which do
not support local delivery mechanisms need to be identified.
9.2. Local Transport
The construction of packets to be delivered to network boundaries is
required in a way which allows traversal of firewalls and reliable
gateway operation.
9.3. MTU Issues
The transfer of data within a local delivery encapsulation may
require addition of addressing and extension headers. In some
circumstances this will impact on the efficiency of transmission due
to packet overheads. Additionally, while the aim of local delivery
is to reduce application impacts, there is some interplay between the
reduced MTU and application operations [RFC2292][RFC2460].
9.4. Backward Compatibility
The correct operation of existing IPv6 devices which do not support
local delivery mechanisms need to be identified.
9.5. Recursion
If multiple levels of local delivery are required, the issues of
discovery, delivery, MTU and source addressing are
9.6. Source Address Selection
Source address selection requires particular care in order to
insulate applications from the address translation knowledge required
in IPv4 NAT today. Since the application program doesn't have to
Daley Expires January 15, 2010 [Page 21]
Internet-Draft IPv6 Function without NAT July 2009
make explicit computations about determining addressing, the u
require revisiting. system has to assist in finding which of the
addresses is suitable for binding in communications.
The operating system needs to be able to identify that an address on
the Internet requires connectivity through a Virtual IP address held
at the gateway, rather than through a locally acquired address.
Existing IPv6 source address selection rules go part way toward this,
by providing scope-matching constructs [RFC3484]. In order to ensure
that communications use the external gateway provided address,
support to distinguish between ULA addressed destinations and
globally addressed destinations should be incorporated into this
specification. This could be assisted by providing address selection
advice in gateway discovery mechanisms which identify address
prefixes which are local, and those requiring local delivery
services, even where globally routable addresses are used within a
local network.
10. General problems with Topology Hiding and the Internet
Whether or not appplication programs understand their external
address, topological and network composition information still passes
network boundaries. Applications report bugs including stack traces
[DRWatsonDescript], Cookies uniquely identify hosts and browsers. and
operating system information can be gleaned through reviewing
fragmentation and TCP windowing behaviour [ettercap].
As such neither NAT or an address preserving local delivery mechanism
is a complete solution to divulgence of operating information.
The author considers that due to the ongoing issues in application
transparency place address preserving mechanisms in a more favourable
position.
11. IANA Considerations
There are no allocations made in this document.
12. Security Considerations
Delivery of application services based on the IP addressing is
subject to source address spoofing. Migration to Non-NAT services
provides no stronger identification tie for security purposes.
Daley Expires January 15, 2010 [Page 22]
Internet-Draft IPv6 Function without NAT July 2009
Several schemes are described to achieve similar addressing
functions. Without concrete description of the mechanisms in use,
security aspects of the external interface, or the internal packet
delivery cannot be completely described.
13. Acknowledgments
Some of the local delivery mechanism discussions were informed by a
discussion with Tony Hain at IETF 74.
14. References
14.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for
IPv6", RFC 2292, February 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet
Daley Expires January 15, 2010 [Page 23]
Internet-Draft IPv6 Function without NAT July 2009
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Daley Expires January 15, 2010 [Page 24]
Internet-Draft IPv6 Function without NAT July 2009
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[I-D.iab-ipv6-nat]
Thaler, D. and L. Zhang, "IAB Thoughts on IPv6 Network
Address Translation", draft-iab-ipv6-nat-00 (work in
progress), March 2009.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-00 (work in
progress), June 2009.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful-00 (work
in progress), July 2009.
[I-D.mrw-behave-nat66]
Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
Translation (NAT66)", draft-mrw-behave-nat66-02 (work in
progress), March 2009.
[NAT66pres]
Wasserman, M., "NAT66: draft-mrw-behave-nat-02.txt", IETF
74 Presentation draft-mrw-behave-nat66-02, March 2009.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
Daley Expires January 15, 2010 [Page 25]
Internet-Draft IPv6 Function without NAT July 2009
14.2. Informative References
[I-D.thaler-ipv6-saf]
Thaler, D., "Source Address Finding (SAF) for IPv6
Translation Mechanisms", draft-thaler-ipv6-saf-01 (work in
progress), February 2009.
[APNICv6MH]
"http://www.apnic.net/policy/proposals/
prop-035-v002.html".
[DRWatsonDescript]
Microsoft Corporation, "Description of the Dr. Watson for
Windows (Drwtsn32.exe) Tool", Microsoft Knowledge
Base Q308538.
[ettercap]
Ornaghi, A. and M. Valleri, "Ettercap NG:
http://ettercap.sourceforge.net".
Author's Address
Greg Daley
22 Maryston St
Yarraville, Victoria 3013
Australia
Phone: +61 3 9314 9797
Email: hoskuld@hotmail.com
Daley Expires January 15, 2010 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 01:32:55 |