One document matched: draft-van-beijnum-modified-nat-pt-02.txt
Differences from draft-van-beijnum-modified-nat-pt-01.txt
Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: May 22, 2008 November 19, 2007
Modified Network Address Translation - Protocol Translation
draft-van-beijnum-modified-nat-pt-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
A smooth transition from IPv4 to IPv6 requires that either all hosts
are upgraded to dual stack before the first hosts can become IPv6-
only, or that there be some mechanism for IPv6-only hosts to talk to
IPv4-only hosts. Expecting the former within a reasonable timeframe
isn't realistic, based on current adoption of dual stack combined
with the latest projections for the IPv4 depletion that point to a
date early in the next decade. And the IETF has recently deprecated
the main mechanism that allows the latter: NAT-PT.
van Beijnum Expires May 22, 2008 [Page 1]
Internet-Draft Modified NAT-PT November 2007
This document proposes modifications to NAT-PT that address the
reasons why the mechanism was deprecated. This should allow future
deployment of the modified NAT-PT as an IPv4-to-IPv6 transition
mechanism, giving operators the option of running their networks
largely IPv6-only.
1. Introduction
The original NAT-PT mechanism outlined in [RFC2766] couples three
underlying techniques to arrive at a comprehensive solution that
allows IPv6-only hosts to initiate connections or associations
towards IPv4-only hosts:
1. Stateless IP and ICMP Translation [RFC2765]
2. Network Address / Port Translation
3. A DNS Application Layer Gateway [RFC2694]
Basically, when an IPv6 host wants to connect to a service, it looks
up the associated host/service name in the DNS. If no AAAA records
are available for the name in question, the DNS ALG synthesizes an
AAAA record based on the A record for the host/service and a prefix
that's routed to a translation device. The IPv6 host initiates
communication towards the resulting IPv6 address. The associated
packets end up at the translator, which recovers the original IPv4
destination address, translates between IPv6 and IPv4, performs IPv4
NAT and sends the resulting packet to the IPv4 destination. Return
packets are translated back and sent to the IPv6 host.
[RFC4966] explains why this is problematic. The main objections boil
down to hosts being exposed to an unexpected environment, issues with
referrals in the absence of relevant Application Layer Gateways,
generation of synthetic DNS responses that may be harmful if not
properly contained and constraints on network topology.
This document proposes to make the IPv6-side is aware of the
translation in order to avoid the majority of the problems associated
with the original NAT-PT. Additionally, it specifies a way for IPv4
hosts in sites that only have IPv6 to have access to the IPv4
internet.
Although this document goes into some detail, it's intended as a
discussion document; as such, not every aspect is completely worked
out.
In some circles, a distinction is made between Network Address
van Beijnum Expires May 22, 2008 [Page 2]
Internet-Draft Modified NAT-PT November 2007
Translation (NAT) which only translates just addresses, and Network
Address/Port Translation (NAPT) which translates both addresses and
TCP/UDP port numbers. No such distinction is made here; "NAT" is
used to refer to both types of translation.
2. IPv6-to-IPv4
There are two modifications to existing NAT-PT possible to allow for
IPv6-only hosts to connect to IPv4-only hosts. The only one mandated
by this document is the use of A records.
3. Use of A records
In the original NAT-PT design a DNS ALG would create synthetic AAAA
DNS records for FQDNs that only have A records. This behavior is no
longer supported; IPv6 hosts that want to communicate with IPv4 hosts
must now look up the A records themselves and create a synthetic IPv6
destination address from the IPv4 address bits and a /96 prefix that
is routed to the translator. The /96 prefix and hence the
translation device used may be configured administratively, but an
anycasted default prefix (TBD) is made available so that IPv6 hosts
can use a topologically close translation device without
configuration.
Discussion: do we want to reuse the IPv4-mapped IPv6 address range
for this? On the surface, that would seem to make sense. However,
it has been long standing policy that IPv4-mapped IPv6 addresses do
no appear on the wire.
3.1. Use of a synthetic IPv4 source address
Optionally, IPv6-only hosts may support IPv4 (and IPv4-mapped IPv6)
socket calls for compatibility with applications that don't support
native IPv6 communication and/or need to be aware of the fact that
communication is happening over IPv4 and is subject to NAT. A
natural way to indicate this is through the use of an IPv4 source
address from [RFC1918] space.
An IPv6-only host implementing IPv4 compatible socket calls picks one
of its global scope IPv6 addresses as the source address for MNAT-PT.
It then generates a local IPv4 address in the prefix 172.31.0.0/16,
where the lower 16 bits are chosen such that a TCP or UDP checksum
computed over the IPv6 addresses that appear on the wire are the same
as those resulting from the synthetic IPv4 source address and the
IPv4 destination address.
van Beijnum Expires May 22, 2008 [Page 3]
Internet-Draft Modified NAT-PT November 2007
This means that the value of the lower 16 bits in the synthetic IPv4
address are generated through the one's complement addition of the
16-bit words that make up the 96 bit prefix used for IPv4
destinations reachable through the translator and the selected IPv6
source address. Then, a one's complement subtraction of the value
44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix.
The result of this is that TCP and UDP checksums computed over both
the IPv4 and MNAT-PT IPv6 representations of packets destined for the
translator are the same. UDP packets MUST have a valid checksum.
Although adjusting checksums during translation steps is relatively
easy, knowing that IPv4 and IPv6 versions of the checksum are
identical may allow for a more flexible implementation, where it's
not necessary to keep track of whether a packet was or will be
translated when a checksum is computed.
The resulting synthetic IPv4 address is internally used as the source
address in all IPv4 processing.
3.2. Operation
Packets towards to-be-translated IPv4 destinations are transmitted
over the network as usual. The translation device performs SIIT
translation and IPv4 NAT. The possible artificial IPv4 source
address is ignored during these steps, since it is not required by
either step except as a means to keep track of which sessions on the
public IPv4 side map to which sessions on the "internal" side.
However, since different hosts served by the same translation device
may have selected the same artificial IPv4 address, (de)multiplexing
based on this value won't work well. So the SIIT and NAT functions
must be integrated such that the NAT associates sessions on the
public IPv4 side directly with the IPv6 side without a private IPv4
intermediate.
4. IPv4-to-IPv6 operation
In order for IPv6-only hosts to receive incoming TCP sessions and UDP
packets that aren't replies to UDP packets sent earlier, TCP and UDP
packets towards a certain address / port combination translated to a
corresponding IPv6 address in MNAT-PT translators. State is kept to
be able to translate return packets from IPv6 to IPv4. Holders of
IPv4 address space (including [RFC1918] address space) may set up
translation mappings administratively for IPv4 addresses under their
control. In addition, one or more blocks of IPv4 address space are
set aside to make IPv6-only hosts reachable for IPv4-only hosts.
These address blocks are translated by all MNAT-PT translators in an
anycast-like fashion.
van Beijnum Expires May 22, 2008 [Page 4]
Internet-Draft Modified NAT-PT November 2007
MNAT-PT translators MUST encode the IPv4 source address in the lower
32 bits of the IPv6 source address in translated packets. This means
that translators must have a /96 range of IPv6 addresses available to
perform this type of translation. Encoding of the IPv4 source
address in the IPv6 source address allows conformant applications or
operating systems to recover the original IPv4 source address of the
correspondent. However, this only works if the incoming packets are
indeed translated IPv4 packets. If this functionality is desired,
administrators must take care to keep incoming translated IPv4
sessions and normal IPv6 sessions apart by making these arrive at
different addresses.
Note that for this type of translation, there is no requirement that
checksums calculated over the IPv4 and IPv6 pseudo headers are the
same: translators must adjust checksums.
4.1. DNS
As it's impractical to configure all MNAT-PT translators globally
with the full set of translation mappings, the mappings are stored in
the DNS in the following format:
a7.a6.a5.a3.p3.p2.p1.p0.a2.a1.a1.a0.ip4ip6.arpa.
a0 - a7 are bits 0 - 3 ... 28 - 31 from the IPv4 address,
respectively. p0 - p3 are bits 0 - 3 ... 12 - 15 from the port
number, respectively. The groups of four bits are represented by a
hexadecimal digit. So a packet to 192.0.2.171 port 993 would map to:
b.a.2.0.1.e.3.0.0.0.0.c.ip4ip6.arpa.
Each individual name within this domain uses a PTR record to point to
a name elsewhere in the domain tree, which in turn hold one or more
SRV records. The holder of an address / port combination can publish
a port number and name (presumably mapping to one or more AAAA
records) where the service is located at any given point in time.
The translator caches at least one packet while it performs the
necessary DNS lookups to create a translation mapping. It is
unavoidable that packets may be lost or delayed while DNS lookups are
performed.
4.2. IPv4 address space for IPv6 services
A /8 block of IPv4 address space, combined with the 16 bits from the
port number, would allow for 2^40 IPv6-only services to be available
from the IPv4-only internet. Presumably, this would be enough to
accommodate a smooth transition from IPv4 to IPv6. (Additional
blocks could be made available later; implementors of MNAT-PT
van Beijnum Expires May 22, 2008 [Page 5]
Internet-Draft Modified NAT-PT November 2007
translators MUST make it possible to add additional IPv4 blocks to
the list of IPv4-to-IPv6 translation addresses.)
A /8 block of IPv4 address space could be taken from unused unicast
space. However, it may be possible to reuse a part of the IPv4
address space that isn't currently usable. Since any hosts are
unable to send packets to class E address space, that wouldn't be a
suitable choice, but possibly parts of the 0.0.0.0/8 or 127.0.0.0/8
blocks could be used for this. It may even be possible to reuse the
addresses ending in all-zeroes or all-ones from class C address
space, which are generally presumed to be unusable. Further
investigation is warranted.
5. IPv4-IPv6-IPv4 operation
It would be optimistic to expect that all hosts implement IPv6 and
the mechanisms outlined above within a limited timeframe. As such,
it is useful to support both hosts that don't implement the changes
set forth in this document, and even hosts that don't implement IPv6
at all. In these cases, a gateway device may be employed that
manages a block of private IPv4 address space using DHCP and
translates these to IPv6 addresses. The local device performs SIIT
between the resulting IPv4 and IPv6 address pairs but not IPv4 NAT.
Since the remote translator that translates from IPv6 to public IPv4
requires a unique IPv6 address in order to demultiplex, the local
gateway MUST use a dedicated IPv6 address for each local IPv4
address. Any [RFC1918] address may be used locally as long as the
requirements are met that only a single local IPv4 address maps to an
IPv6 address, and that the addresses are equivalent for the purposes
of computing checksums. A way to conform to these requirements is to
construct the IPv6 address from the IPv4 address as follows:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 64-bit subnet prefix |F0|ID|CHKSM| IPv4 addr |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Bit 70 in the address MUST be set to 0 to indicate a non globally
unique address. The ID bits can contain a value that allows
different gateways to live on the same subnet. In the absence of any
administrative settings or the detection of duplicate addresses, this
could be the lower 8 bits of the gateway's MAC address. The CHKSM
bits are chosen such that they compensate for the differences in the
checksum generated over the IPv4 pseudo-header and the checksum
generated over the IPv6 pseudo-header. This means that this value is
the one's complement of the one's complement addition of the 16-bit
words from the top 96 bits of the address of remote modified NAT-PT
van Beijnum Expires May 22, 2008 [Page 6]
Internet-Draft Modified NAT-PT November 2007
translator and all the 16-bit words from the top 80 bits of IPv6
address that is being constructed.
The local gateway SHOULD also perform IPv6 routing or otherwise allow
IPv6 connectivity so that hosts that do support IPv6, but not
MNAT-PT, have the ability to communicate directly over IPv6 in
addition to being able to use translated IPv4 connectivity.
There are two open issues: how do IPv4 hosts using different local
gateways but the same modified NAT-PT translator communicate, and how
do NAT traversal protocols such as uPnP, NAT-PMP and others work.
6. Control connection
If a non-anycast address range is used to IPv6-to-IPv4 translation,
it's likely that users of the translator in question may be
authorized to use the translator, but this fact isn't obvious from
the source addresses used by the IPv6 host in question. A
lightweight way to authenticate an IPv6 host to a translator would be
for the host to set up a TLS-protected TCP session towards an address
held by the translator, and exchange credentials over this
connection. Afterwards, the session could be kept alive and be used
as a generic control connection, for the purposes of detecting loss
of state in the translation device and negotiating NAT parameters.
It should be possible to reuse an existing IETF protocol for this
purpose.
Discussion: do we want to perform generic NAT traversal functions
though the control connection, or do we want to use existing uPnP and
NAT-PMP protocols for this? There are security issues with these
protocols, but they are widely used in home networks. The use of
protocols like STUN is also possible, but these aren't widely
deployed in home networks.
7. Examples
The anycast range for IPv6-to-IPv4 translation is assumed to be
1000::/96 in these examples, and the IPv4 address of the translator
is 10.0.0.96. (10.0.0.96 is used as an example public IPv4 address,
not as a private address here.)
7.1. IPv6-to-IPv4
IPv6 host pc1.beispiel.de 2001:db8:31::dead:beef wants to communicate
with IPv4 host www.example.com, which holds address 192.0.2.58.
pc1.beispiel.de doesn't use a synthetic IPv4 source address.
van Beijnum Expires May 22, 2008 [Page 7]
Internet-Draft Modified NAT-PT November 2007
1. pc1.beispiel.de looks up AAAA records for www.example.com with no
results
2. pc1.beispiel.de looks up A records for www.example.com:
192.0.2.58
3. pc1.beispiel.de initiates a TCP session from 2001:db8:31::dead:
beef port 1025 to 1000::192.0.2.58 port 80
4. the translator sets up a translation mapping from { [2001:db8:
31::dead:beef]:1025 [1000::192.0.2.58]:80 } to { [10.0.0.96]:
49152 [192.0.2.58]:80 }
5. the translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
7.2. IPv6-to-IPv4 with synthetic IPv4 source address
IPv6 host pc2.beispiel.de 2001:db8:31::cafe wants to communicate with
IPv4 host www.example.com, which holds address 192.0.2.58.
pc2.beispiel.de uses a synthetic IPv4 source address.
1. pc2.beispiel.de does a one's complement addition of the values
1000, 0000, 0000, 0000, 0000, 0000 (the translator anycast
address), 2001, 0db8, 0031, 0000, 0000, 0000, 0000, cafe (its
source address) which results in 08e9
2. pc2.beispiel.de does a one's complement subtraction of ac1f
(172.31) from 08e9 = a336 (163.54)
3. pc2.beispiel.de configures a virtual network interface with IPv4
address 172.31.163.54
4. pc2.beispiel.de looks up AAAA records for www.example.com with no
results
5. pc2.beispiel.de looks up A records for www.example.com:
192.0.2.58
6. pc2.beispiel.de initiates a TCP session from 2001:db8:31::cafe
port 1025 to 1000::192.0.2.58 port 80
7. the translator sets up a translation mapping from { [2001:db8:
31::cafe]:1025 [1000::192.0.2.58]:80 } to { 10.0.0.96:49153
192.0.2.58:80 }
8. the translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
van Beijnum Expires May 22, 2008 [Page 8]
Internet-Draft Modified NAT-PT November 2007
7.3. IPv4-to-IPv6-to-IPv4
IPv4 host pc3.beispiel.de wants to communicate over the IPv6 internet
with IPv4 host www.example.com, which holds address 192.0.2.58.
1. the local translator gives out IPv4 address 192.168.1.3 to
pc3.beispiel.de and sets up a mapping between private IPv4
address 192.168.1.3 and IPv6 address 2001:db8:31:0:f0aa:
d16a.192.168.1.3
2. note that in one's complement math the addition of 1000, 0000,
0000, 0000, 0000, 0000, 2001, 0db8, 0031, 0000, f0aa, d16a equals
ffff (-0, which is equal to 0)
3. pc3.beispiel.de looks up A records for www.example.com:
192.0.2.58
4. pc3.beispiel.de initiates a TCP session from 192.168.1.3 port
1025 to 192.0.2.58 port 80
5. the local translator translates the packet { 192.168.1.3:1025
192.0.2.58:80 } to { [2001:db8:31:0:f0aa:d16a.192.168.1.3]:80
[1000::192.0.2.58]:80 }
6. the remote MNAT-PT translator sets up a translation mapping from
{ [2001:db8:31:0:f0aa:d16a.192.168.1.3]:80 [1000::192.0.2.58]:80
} to { 10.0.0.96:49154 192.0.2.58:80 }
7. the remote translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
7.4. IPv4-to-IPv6
IPv4 host mac1.example.com holding address 192.0.2.253 wants to
communicate with IPv6 host pc1.beispiel.de. The port number
available for this service is 32767. In order to accommodate
incoming sessions, pc1.beispiel.de has set up the following entries
in the DNS:
pc1.beispiel.de. A 0.48.64.80
0.5.0.4.f.f.f.7.0.3.0.0.ip4ip6.arpa. PTR pc1._ftp._tcp.beispiel.de.
pc1._ftp._tcp.beispiel.de. SRV 0 0 21 pc1-dynamic.ddns.beispiel.de.
pc1-dynamic.ddns.beispiel.de. AAAA 2001:db8:31::dead:beef
van Beijnum Expires May 22, 2008 [Page 9]
Internet-Draft Modified NAT-PT November 2007
The closest MNAT-PT translator uses prefix 2001:db8:ffff::/96 for
translations from IPv4 to IPv6.
1. mac1.example.com wants to connect to pc1.beispiel.de on port
32767
2. mac1.example.com looks up A records for pc1.beispiel.de in the
DNS: 0.48.64.80
3. mac1.example.com sets up a TCP session from 192.0.2.253:1025 to
0.48.64.80:32767
4. the packet for 0.48.64.80 is routed towards the nearest MNAT-PT
translator
5. the translator transfers 0.48.64.80:32767 into
0.5.0.4.f.f.f.7.0.3.0.0.ip4ip6.arpa
6. the translator looks up PTR records: pc1._ftp._tcp.beispiel.de
7. the translator looks up SRV records: 0 0 21 pc1-
dynamic.ddns.beispiel.de
8. the translator looks up AAAA records: 2001:db8:31::dead:beef
9. the translator sets up a mapping from { 192.0.2.253:1025
0.48.64.80:32767 } to { [2001:db8:ffff::192.0.2.253]:1025 [2001:
db8:31::dead:beef]:21 }
10. the translator translates packets back and forth until the
session is no longer used and the mapping is garbage collected
8. Advantages and disadvantages
8.1. Disadvantages
The disadvantage of this mechanism is that for IPv6-to-IPv4
operation, it's required that the IPv6 host supports at least the use
of A records and set up IPv6 connections to a translator. As such,
deployment is non-trivial. Incoming sessions for IPv6 hosts can
happen without necessarily requiring changes to the TCP/IP stack or
applications, but in that case, applications may operate under the
assumption that they're talking to IPv6 correspondents, while in fact
they are communicating with IPv4 correspondents. This may result in
a mismatch in IP protocol version for protocols that embed IP
addresses.
van Beijnum Expires May 22, 2008 [Page 10]
Internet-Draft Modified NAT-PT November 2007
8.2. Advantages
There are several advantages. An important one is that NAT issues
only come up when the host is communicating towards IPv4 addresses.
As such, it's trivial for applications to limit NAT workaround code
to sessions towards IPv4 destinations and assume global
addressability for IPv6 destinations. Since there is no DNS ALG,
there are no issues with possible leakage of synthetic AAAA records.
Both IPv4 applications that use IPv4 socket calls and IPv6
applications that use IPv6 socket calls with IPv4-mapped IPv6
addresses can work over MNAT-PT. Alternatively, light-weight
implementations may omit all IPv4 code except the ability to resolve
A records.
8.3. Advantages over providing real NATed IPv4 connectivity
An obvious way to enjoy many of the same benefits would be to build a
network that supports both IPv6 and IPv4 with NATed connectivity.
However, this means that there must be an IPv4 network infrastructure
in place in the form of IPv4 routers and IPv4 address provisioning
(DHCP). Today, this is easy to do in smaller installations if there
is a single public IPv4 address available. However, in larger
networks the planning of private IPv4 addressing can become
cumbersome, and when IPv4 addresses are scarce, it may be unavoidable
to implement multiple levels of NAT. Multiple levels of NAT at the
very least impose the limits of the most restrictive NAT, and also
make hole punching that is used to be able to receive incoming
connections much harder as a single set of port numbers must be
shared by a larger number of hosts. NAT traversal technologies may
or may not support multiple layers of NAT.
With MNAT-PT, it's only necessary to provision IPv6 connectivity and
addressing, which is easier to plan for because unlike IPv4, a
standard /64 IPv6 subnet supports arbitrary numbers of hosts. The
translation device that performs NAT and the hosts making use of the
MNAT-PT service can be located with few topological constraints, so
multiple layers of NAT are much easier to avoid.
9. Evaluation of RFC4966 concerns
This section provides an overview of the issues raised in [RFC4966]
and how they apply to the use of modified NAT-PT with modifications
on the IPv6 side.
van Beijnum Expires May 22, 2008 [Page 11]
Internet-Draft Modified NAT-PT November 2007
9.1. Issues with Lack of Address Persistence
To-be-translated IPv4 destination addresses map to the same IPv6
destination address until the host selects a different /96 prefix.
However, if addresses are stored in their IPv4 form, this doesn't
lead to broken referrals. Issues with mapping persistence from the
IPv4 side to the IPv6 side are the same as with regular NAT and can
be solved in the same way: by having the application or OS set up a
persistent mapping that allows incoming connections.
9.2. DoS Attacks on Memory and Address/Port Pools
Denial-of-service issues are mostly the same as with regular NAT.
When a non-anycast translator is used, it's likely that
authentication through a control connection is required, allowing for
easy rejection of to-be-translated traffic coming from addresses that
don't have an active control connection. However, unless the IPv6
source host and the translator are prepared to set up an IPsec
tunnel, there is no way to reject to-be-translated traffic which
spoofs the source address of a host with an active control
connection. If the source host uses an IPv6 source address for this
communication that it doesn't use for other types of communication,
only on-path attackers or hosts on the same subnet have easy
knowledge of the source address in question.
9.3. Issues Directly Related to Use of DNS-ALG
N/A.
9.4. Impact on IPv6 Application Development
Applications see regular IPv4 destination addresses for to-be-
translated destinations so they can engage IP version specific code
paths as required. The presence of the [RFC1918] synthetic source
address makes it possible for applications to use NAT workarounds for
to-be-translated destinations. The extra work the application needs
to do here is the same as it would when running on a dual stack host.
Alternatively, TCP/IP stacks may forego implementing the synthetic
IPv4 source address and/or applications may choose to remain ignorant
of whether they're communicating with an IPv4 or IPv6 correspondent.
In those cases, address-based referrals are likely to break for IPv4
destinations unless the MNAT-PT translator employs an Application
Layer Gateway for the protocol that's used.
van Beijnum Expires May 22, 2008 [Page 12]
Internet-Draft Modified NAT-PT November 2007
10. Acknowledgments
This document has benefited from ideas from Marcelo Bagnulo, Brian
Carpenter and Alain Durand. Readers are encouraged to also review
[I-D.carpenter-shanti], [I-D.durand-v6ops-natv4v6v4] and
[I-D.bagnulo-v6ops-6man-nat64-pb-statement].
11. IANA considerations
None at this time.
12. Security considerations
Security considerations need to be worked out in a revision of this
document.
In the past, security issues have been identified with the use of
IPv4-mapped IPv6 addresses. If these addresses were to appear on the
wire, neither IPv4 nor IPv6 filters would recognize them as packets
associated with IPv4 operation, possibly allowing the bypassing of
access restrictions.
Implementers should take care to avoid having mechanisms that
restrict access based on IPv4 addresses without also taking into
account various translation mechanisms.
13. References
13.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
van Beijnum Expires May 22, 2008 [Page 13]
Internet-Draft Modified NAT-PT November 2007
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
13.2. Informative References
[I-D.carpenter-shanti]
Carpenter, B., "Shimmed IPv4/IPv6 Address Network
Translation Interface (SHANTI)", draft-carpenter-shanti-01
(work in progress), November 2007.
[I-D.durand-v6ops-natv4v6v4]
Durand, A., "Non dual-stack IPv6 deployments for broadband
providers", draft-durand-v6ops-natv4v6v4-00 (work in
progress), November 2007.
[I-D.bagnulo-v6ops-6man-nat64-pb-statement]
Bagnulo, M., "IPv6 - IPv4 Translators (NAT64) - Problem
Statement and Analysis",
draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in
progress), November 2007.
Appendix A. Document and discussion information
Revision history:
o Version 00: initial version
o Version 01: added mechanisms that require changes at the IPv4 side
o Version 02: added support for incoming sessions from IPv4-only to
IPv6-only host and IPv4-IPv6-IPv4 translation; removed mechanisms
that require changes at the IPv4 side to avoid confusion
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the v6ops mailinglist or directly to the author.
van Beijnum Expires May 22, 2008 [Page 14]
Internet-Draft Modified NAT-PT November 2007
Author's Address
Iljitsch van Beijnum
IMDEA Networks
Av. Universidad 30
Leganes, Madrid 28911
ES
Phone: +34-91-6246245
Email: iljitsch@muada.com
van Beijnum Expires May 22, 2008 [Page 15]
Internet-Draft Modified NAT-PT November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
van Beijnum Expires May 22, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 09:27:03 |