One document matched: draft-daley-ipv6-nonat6-00.txt
Network Working Group G. Daley
Internet-Draft July 7, 2009
Intended status: Standards Track
Expires: January 8, 2010
Achieving Addressing Functions in IPv6 without using NAT
draft-daley-ipv6-nonat6-00.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 8, 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 8, 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 8, 2010 [Page 2]
Internet-Draft IPv6 Function without NAT July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Existing NAT Models for IPv6 . . . . . . . . . . . . . . . 4
1.2. Application impacts of existing NAT deployments . . . . . 5
1.2.1. Behaviour of some port address translating IPv4
NATs . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Network Topology Hiding in IPv6 . . . . . . . . . . . . . . . 6
2.1. Network Topology Hiding using Stateful Mappings . . . . . 6
2.2. Network Topology Hiding using Stateless Mappings . . . . . 7
2.2.1. Prefix Only Transformations . . . . . . . . . . . . . 7
2.2.2. Prefix and Suffix Transformations . . . . . . . . . . 7
2.3. Source Address Mappings and NAT . . . . . . . . . . . . . 8
3. Provider Independence in IPv6 . . . . . . . . . . . . . . . . 8
3.1. Using Provider Aggregatable Addresses for Multihoming . . 8
3.1.1. Aggregatable Addresses and host selection . . . . . . 9
3.1.2. Provider Aggregatable Addresses and gateway
selection . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Limits of Provider Aggregatable Addressing . . . . . . 11
3.2. Provider Independent Addressing and Multihoming . . . . . 11
4. Reduce impacts on the global routing table . . . . . . . . . . 13
5. No prefix reassignment on ISP change . . . . . . . . . . . . . 14
6. Address Amplification . . . . . . . . . . . . . . . . . . . . 14
7. Alternatives to NAT for Network Topology Hiding . . . . . . . 15
7.1. Local Tunnels For network topology hiding . . . . . . . . 16
7.2. Translation extension headers For network Topology
Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Address Allocation Channel for NAT . . . . . . . . . . . . 18
8. Problems with NAT and Topology Hiding . . . . . . . . . . . . 19
9. Problems with Local Delivery mechanisms and Topology Hiding . 19
9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Local Transport . . . . . . . . . . . . . . . . . . . . . 20
9.3. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . 20
9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 20
9.5. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 20
9.6. Source Address Selection . . . . . . . . . . . . . . . . . 20
10. General problems with Topology Hiding and the Internet . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Daley Expires January 8, 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][RFC4864]. 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
these.
The discussion in this document can be seen as an adjunct to existing
descriptions of IPv6 and NAT relationships [RFC2993].
1.1. 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.
Daley Expires January 8, 2010 [Page 4]
Internet-Draft IPv6 Function without NAT July 2009
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.2. 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.
+---+ 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
1.2.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
Daley Expires January 8, 2010 [Page 5]
Internet-Draft IPv6 Function without NAT July 2009
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 [CITE].
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 or add local routing identifiers to packets in
transit.
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.
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.
Daley Expires January 8, 2010 [Page 6]
Internet-Draft IPv6 Function without NAT July 2009
Since state is 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.
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.
Daley Expires January 8, 2010 [Page 7]
Internet-Draft IPv6 Function without NAT July 2009
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.
Some of these alternatives are explored below in Section 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
Daley Expires January 8, 2010 [Page 8]
Internet-Draft IPv6 Function without NAT July 2009
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]).
+------+ +------+
| 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
Daley Expires January 8, 2010 [Page 9]
Internet-Draft IPv6 Function without NAT July 2009
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 [MHpath selection]. Applications able to withstand
individual connection failures will be able to survive path failures.
Otherwise application sockets or APIs may present error conditions
[RFC2553].
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
Daley Expires January 8, 2010 [Page 10]
Internet-Draft IPv6 Function without NAT July 2009
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
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 [RFC1771][RFC2858].
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
Daley Expires January 8, 2010 [Page 11]
Internet-Draft IPv6 Function without NAT July 2009
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].
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.
Daley Expires January 8, 2010 [Page 12]
Internet-Draft IPv6 Function without NAT July 2009
+------+ +------+
| 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.
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.
Daley Expires January 8, 2010 [Page 13]
Internet-Draft IPv6 Function without NAT July 2009
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.
Unlike IPv4 though, parallel network addressing infrastructure is
available and supported by all hosts [RFC4294]. Internal addressing
plans based on ULA [RFC4193] allow for 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].
Still in IPv4, renumbering 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.
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.
6. Address Amplification
Address amplification is used to make sure multiple addresses or
subnets may be served 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.
Daley Expires January 8, 2010 [Page 14]
Internet-Draft IPv6 Function without NAT July 2009
The IAB and IESG recommendations for IPv6 site address allocations
identify three models allows for each substantive organization
[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
Local delivery 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 [CITE]. Alternatives to NAT require a way
of allocating external addresses to applications before bindings at
the application programming interface occur [CITE]. 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.
Daley Expires January 8, 2010 [Page 15]
Internet-Draft IPv6 Function without NAT July 2009
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
(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].
Daley Expires January 8, 2010 [Page 16]
Internet-Draft IPv6 Function without NAT July 2009
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.
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
Daley Expires January 8, 2010 [Page 17]
Internet-Draft IPv6 Function without NAT July 2009
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.
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
Daley Expires January 8, 2010 [Page 18]
Internet-Draft IPv6 Function without NAT July 2009
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
* Local Transport
* MTU issues
* Backward compatibility.
Daley Expires January 8, 2010 [Page 19]
Internet-Draft IPv6 Function without NAT July 2009
* 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
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
Daley Expires January 8, 2010 [Page 20]
Internet-Draft IPv6 Function without NAT July 2009
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. Application report bugs including stack traces
[CITE], Cookies uniquely identify hosts and browsers [CITE]. and
operating system information can be gleaned through reviewing
fragmentation and TCP windowing behaviour [CITE][CITE].
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
Security considerations of several delivery mechanisms have not yet
been completely explored.
13. Acknowledgments
Some of the local delivery mechanism discussions were informed by a
discussion with Tony Hain at IETF 74.
Daley Expires January 8, 2010 [Page 21]
Internet-Draft IPv6 Function without NAT July 2009
14. References
14.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[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.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 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
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.
Daley Expires January 8, 2010 [Page 22]
Internet-Draft IPv6 Function without NAT July 2009
[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.
[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.
[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.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[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.
[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]
Daley Expires January 8, 2010 [Page 23]
Internet-Draft IPv6 Function without NAT July 2009
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.
14.2. Informative References
[APNICv6MH]
"http://www.apnic.net/policy/proposals/
prop-035-v002.html".
[CITE] "Placeholder Citation".
Author's Address
Greg Daley
22 Maryston St
Yarraville, Victoria 3013
Australia
Phone: +61 3 9314 9797
Email: hoskuld@hotmail.com
Daley Expires January 8, 2010 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 01:32:43 |