Network Working Group C. Jennings
Internet-Draft Cisco Systems
Intended status: Standards Track November 3, 2008
Expires: May 7, 2009
NAT for IPv6-Only Hosts
draft-jennings-behave-nat6-01
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 7, 2009.
Abstract
This specification defines a NAT that allows IPv6-only hosts that are
inside the NAT to operate with IPv4 hosts that are outside the NAT.
It requires no modifications to the v4 hosts or applications, or to
the operating system of v6 hosts, but it does require some changes to
v6 applications. Typically this specification would be used to allow
the hosts inside a NAT to connect to hosts outside it; but under some
limitations, it can also allow hosts outside to connect to hosts
inside.
The goal of this draft is to consider what is the minimal feasible
approach to this problem. The current intention is to merge this
with the nat64 draft. This draft is being discussed on the
Jennings Expires May 7, 2009 [Page 1]
Internet-Draft NAT6 November 2008
behave@ietf.org list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. NAT from 6 to 4 . . . . . . . . . . . . . . . . . . . . . 3
2.2. NAT from 4 to 6 . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . 7
5.1. UDP and TCP 6 to 4 . . . . . . . . . . . . . . . . . . . . 7
5.2. UDP and TCP 4 to 6 . . . . . . . . . . . . . . . . . . . . 7
5.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . . . 8
5.4. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.5. DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.6. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.6.1. Option Yes ICMP . . . . . . . . . . . . . . . . . . . 9
5.6.2. Option No ICMP . . . . . . . . . . . . . . . . . . . . 9
5.7. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.8. DCCP, SCTP, etc . . . . . . . . . . . . . . . . . . . . . 10
6. ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Others . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Helper Services . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. V6 Routing / Tunnel . . . . . . . . . . . . . . . . . . . 11
8. Requirement Conformance . . . . . . . . . . . . . . . . . . . 11
8.1. RFC 4787 Requirements . . . . . . . . . . . . . . . . . . 11
8.2. draft-ietf-behave-tcp Requirements . . . . . . . . . . . . 12
8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement
Requirements . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. draft-nishitani-cgn Requirements . . . . . . . . . . . . . 12
8.5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Jennings Expires May 7, 2009 [Page 2]
Internet-Draft NAT6 November 2008
1. Introduction
A lot of thought has gone into the question of how to connect v6-only
and v4-only hosts. This draft tries to identify the simplest
approach to what would just "barely work," since what barely works is
what is most likely to get deployed. The basic approach is to ask
what works for v4 to v4 NATs and to pick a design that requires as
few changes as possible from that. The assumption is that it is hard
to deploy changes in existing v4 applications and in both v4 and v6
operating systems. Of course, this specification relies on
subjective judgements about the relative complexity of deploying
changes into various parts of the network.
This specification therefore amounts to a rough straw man meant to
encourage discussion of what is the minimum that can be done.
2. Architecture
2.1. NAT from 6 to 4
The deployment topology that this work addresses has many v6-only
hosts behind some large, carrier-grade NAT, and these hosts wish to
be able to form connections to the v4 internet. This is the classic
NAT64 case. The harder NAT46 case is discussed later. As shown in
Figure 1, when a new connection is initiated by the host inside the
NAT using internal address X1 and port x1, the NAT creates a mapping
from the inside address port combination X1:x1 to some unused address
and port on the outside. The external v4 address that X1:x1 was
mapped to is referred to as X1':x1, and any packets that are sent to
this port on the NAT are forwarded to X1:x1.
Jennings Expires May 7, 2009 [Page 3]
Internet-Draft NAT6 November 2008
+-------------------------------+
| +----------+ External v4 |
| |Server App| |
| +----------+ |
| |Host OS | |
| +----------+ |
| Y1:y1 |
| |
| |
| X1':x1' |
| +--------+ +-------+ |
+----+--------+-----------------+
| NAT64 | | DNS64 |
+----+--------+-----------------+
| +--------+ +-------+ |
| Internal v6 |
| |
| X1:x1 |
| +--------+ |
| | Client | |
| +--------+ |
| | Host OS| |
| +--------+ |
+-------------------------------+
Figure 1
The client application needs to know how to create a v6 destination
address that will be routed to the v4 server. First the client
application finds the v4 address of the server. One way to find the
server is using a DNS query. The DNS query will go through a device
that both synthesizes a DNS AAAA record for the A record and returns
the A record. If the end application knows how to look at the A
record directly and synthesize the v6 address to use, it can do that
and continue to support features such as DNSSEC. If the application
is unaware of the fact it is behind a NAT, it can use the AAAA record
as a normal v6 only application would. The v6 address is formed by
putting a ::FFFE:0:0/96 prefix before the v4 address. This prefix
range is routed to the NAT, which can extract the v4 destination
address.
The mapping from X1:x1/X1':x1' is maintained by the NAT as long as it
sees periodic traffic being sent from X1:x1. This specification only
defines the NAT for UDP and TCP but could be extended for other
protocols that have a port multiplexing scheme. When a mapping is
created for a particular port, that mapping exists for all protocols,
not just the protocol that created the mapping. This greatly
simplifies generating the keep alive traffic that is necessary to
Jennings Expires May 7, 2009 [Page 4]
Internet-Draft NAT6 November 2008
maintain the mapping.
2.2. NAT from 4 to 6
Making it possible for a v4 host to connect to a server on the v6
side requires more complex changes to the v6 applications than the
trivial changes that were required in the 6 to 4 direction. However,
many applications that usefully have a server running behind a NAT
have already changed to work behind v4 to v4 NATs. The approach here
is the same.
+-------------------------------+
| +----------+ External v4 |
| |Client App| |
| +----------+ |
| |Host OS | |
| +----------+ |
| Y1:y1 |
| |
| +----+ |
| X1':x1' |STUN| |
| +--------+ +----+ |
+----+--------+-----------------+
| NAT |
+----+--------+-----------------+
| +--------+ Internal v6 |
| |
| |
| X1:x1 |
| +--------+ |
| | Server | |
| +--------+ |
| | Host OS| |
| +--------+ |
+-------------------------------+
Figure 2
The server starts by creating a mapping in the NAT to a v4 address
that it can use. The server does this by creating a connection to
some server in the outside v4 space and having that server tell it
what address and port the request came from, which reveals the
external X1':x1' address port that has been mapped to the port the
server is using. Typically a STUN server would be used. Note that a
UDP transaction to a STUN server will allocate a mapping that can be
used for incoming TCP connections. The NAT is required to run a STUN
server on the external side at the address ::FFFE:127.0.0.1 on the
default STUN port so the server will always be able to find a STUN
Jennings Expires May 7, 2009 [Page 5]
Internet-Draft NAT6 November 2008
server if it is behind a NAT. [[ Note - I have no idea if this
address hack would work - but we can skin the cat with some other
potato peeler if it does not ]]. The server needs to send periodic
keep alive traffic to make sure the NAT does not remove the mapping.
This can also be done with STUN.
Next the server lets the client know that it can be reached at the
address port of X1':x1'. This might be done simply, such as by
creating a URL that points to that location and providing it by
whatever means the URL is found (email, IM, bathroom walls,
whatever); or through a complex approach, such as by using a
rendezvous server such as a SIP registrar or by using DNS SRV records
as rendezvous servers that point at the correct address and port. At
this point, a client in the v4 space can initiate a connection to the
X1':x1', and this will form a connection to the server.
The applications that tend to be popular to run behind NATs are
mostly P2P applications, such as file sharing and VoIP. Many of
these types of applications have already undergone the changes that
would be necessary to enable them to work behind a NAT such as the
one described here, because these changes let them work behind v4 to
v4 NATs. HTTP servers may also turn out to be valuable to run behind
NATs. The use cases would likely not involve direct web page serving
so much as places where a web application, such as Facebook, could
make an RPC call to an application that was running on the v6 server
behind the NAT. The URL that Facebook uses for the RPC calls can
easily be updated by the application. This type of architecture is
already becoming more common as people use virtual servers in elastic
computing environments. These environments are often behind NATs to
facilitate migration of virtual servers. It is worth noting,
particularly for future protocol development, that if HTTP did a DNS
SRV lookup, it would be possible to use DNS as the rendezvous server
for a generic web browser on the v4 internet to reach a v6-only
server behind the NAT.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Mapping
When the NAT receives a packet with a source of X1:x1 from a host on
the inside, the NAT first checks to see if it already has a mapping
for it. If so, it resets the timer for the mapping; otherwise, it
Jennings Expires May 7, 2009 [Page 6]
Internet-Draft NAT6 November 2008
creates a new mapping. If the NAT already has any mapping from X1 to
an external address X1', the external address used for this new
mapping MUST be the same as the external address used for previous
mappings of X1. The external address/port combination (X1':x1')
allocated for the new mapping MUST NOT be in use by any other
mapping. When choosing a port number for the mapping, well known
port numbers MUST NOT be used.
The mappings timer MUST keep mappings for at least 10 minutes after
any packet is sent from the internal host through that mapping. Note
that applications should not assume that the mapping will be promptly
removed after 10 minutes of inactivity, since NAT implementations
often do not use a timer per mapping but instead use a periodic sweep
approach to deleting mapping.
5. Packet Forwarding
5.1. UDP and TCP 6 to 4
When the NAT receives a UDP or TCP packet from the inside, it updates
the mapping as described in Section 4, and then it extracts the
external v4 address from the v6 address by striping the ::FFFE:0:0/96
prefix. Next it takes the payload section of the UDP or TCP packet
and constructs a v4 UDP or TCP payload using this destination and
source from the associated mapping. Then it sends the packet
following the procedures defined for a host to send a UDP or TCP
packet. Note that any IP options (other than fragmentation) are lost
in this process; also, as defined in UDP and TCP, new checksums will
be updated.
It is worth noting that the v4 destination address of the packet may
be one of the external addresses of this NAT, in which case the
packet is forwarded to that address and processed just like any other
packet arriving at this address. Packets can therefore "hairpin"
though the NAT. There is no good way to avoid this without some
modifications to the applications to allow them to be aware of this
and optimize around it. ICE is an example of a way applications can
optimize around this hairpinning.
5.2. UDP and TCP 4 to 6
When the NAT receives a UDP or TCP packet from the outside, it checks
to see if it has a mapping for the address port that the packet was
received on. If it does, it uses the internal address and port
associated with the mapping as the destination. It constructs a v6
UDP or TCP packet from the payload of the received packet and
forwards that to the internal address. Note that checksums are
Jennings Expires May 7, 2009 [Page 7]
Internet-Draft NAT6 November 2008
updated when this new packet is created and sent.
If the NAT receives a TCP SYN packet for which there is no mapping it
SHOULD silently discard it; otherwise TCP hole punching techniques
using simultaneous opens will not work.
5.3. IP Fragmentation
The interaction of v4 and v6 fragmentation has some thorny issues.
The NAT MUST support reassembly of fragmented packets when the
packets are received in order, but support for out of order fragments
is OPTIONAL.
If the NAT receives a v4 packet with the do not fragment bit set, it
MUST NOT forward it if the MTU of the v6 link would require the
packet to be fragmented, and the NAT MUST NOT include a fragment
header in the v6 packet. If the NAT receives a v4 packet that does
not have the do not fragment bit set, then the packet, when
forwarded, MUST include a fragment header; and if the packet is
larger than the MTU, the packet MUST be appropriately fragmented.
When the NAT receives a v6 packet without a fragment header, it MUST
set the do not fragment bit in any v4 packets, and if the resulting
v4 packet is larger than the MTU on the v4 link that will be used,
the NAT MUST NOT forward the packet. When the NAT receives a v6
packet with a fragment header, it can send the v4 packet without the
do not fragment bit set and can fragment the packet appropriately.
The problem with this approach is that the v6 host is likely to send
packets less than 1280 octets with no fragmentation header. The v4
side will interpret these packets as being unable to be fragmented,
and if they are destined for a host in which some element of the path
has a shorter MTU, the packet will be discarded. The only practical
way to mitigate this situation is to have the application send most
of it packets with a fragmentation header, even if they are smaller
than 1280 octets.
Application that support this specification, when sending to a v6
address that starts with the prefix ::FFFE:0:0/96 SHOULD include a
fragment header regardless of the size of the packet.
5.4. TTL
When a packet is forwarded, the TTL is decremented by one. If it is
zero, the packet is not forwarded.
Jennings Expires May 7, 2009 [Page 8]
Internet-Draft NAT6 November 2008
5.5. DSCP
When packets pass from one side to the other, the DSCP needs to be
copied. If the NAT also includes diffserv classifier and marker
functionality it MAY change the DSCP values. See RFC 2983[RFC2983]
for more information.
5.6. ICMP
[[ Note - this is going to be controversial. I suspect it actually
goes too far but I'm deliberately presenting a pretty far out there
side of the argument, in the hope that it will drive a discussion
about what we really need, in practice, if we ignore IETF dogma. ]]
5.6.1. Option Yes ICMP
ICMP packets are translated as described in [RFC2765].
5.6.2. Option No ICMP
ICMP can be split into two parts, the part that reports errors for
other transports and the part that supports exactly two applications,
ping and traceroute. The problem with ICMP for reporting transport
errors is that on today's internet ICMP is so often blocked that no
application can rely on ICMP working. Applications tend to be
designed to work without ICMP. NAT processing of ICMP packets is
complicated because ICMP packets may contain embedded IP packets or
fragments thereof. The security is further complicated by the fact
that a UDP or TCP packet may cause an ICMP error to be generated by a
host other than the host for which the original packet was destined.
This possibility makes it difficult to determine which ICMP packets
are valid and which are not. Furthermore, the way the APIs for UDP
are typically used makes it hard for operating systems to notify
applications of ICMP errors.
NAT processing of ICMP errors is complicated and of very limited
value; for that reason forwarding ICMP error messages is OPTIONAL.
Processing to allow ping and traceroute through the NAT is also
OPTIONAL
5.7. IPsec
IPsec over UDP will work, but other forms of IPsec will generally not
work in a reliable way.
Jennings Expires May 7, 2009 [Page 9]
Internet-Draft NAT6 November 2008
5.8. DCCP, SCTP, etc
This specification can be extended by future specifications to
support other transports but, given the immediate needs, this
specification only requires support for UDP and TCP. This allows
vendors that have not implemented other protocols to be compliant
with this specification. No significant problems are see with using
the same basic approach for DCCP.
SCTP may be more complicated. Often one of the reasons for using
SCTP is to take advantage multi-homing for reliability reasons but
this may require that the two SCTP sessions try and use different
NATs. The requirements and deployments topologies are not clear.
6. ALGs
6.1. FTP
The deployment of personal firewalls and the misconfiguration of
other firewalls has resulted in widespread breakage of active mode
FTP. The general guess is that an FTP ALG will be needed to take
PASV responses and turn them into EPAS responses. However, more
experimentation is needed with what happens today with existing FTP
clients running on v6 only hosts behind NATs to determine what is the
best approach to this problem.
6.2. SIP
Many widely deployed SIP implementations work fine through NATs
without requiring any ALGs. SIP was not designed to work with ALGs.
More importantly, ALGs are not considered when designing new
extensions to SIP and the combination of the extensions and the ALG
often break badly. It is NOT RECOMMENDED for the NAT to have SIP
ALGs, but if SIP ALGs are insisted upon, the best approach is to
implement a dual homed proxy in the NAT that does v6 on one side and
v4 on the other. This approach will be compatible with future SIP
extensions and is significantly easier to correctly implement as SIP
was designed so this would work.
6.3. Others
All other ALGs are NOT RECOMMENDED.
7. Helper Services
There are several services that, while not actually part of NATs,
Jennings Expires May 7, 2009 [Page 10]
Internet-Draft NAT6 November 2008
greatly facilitate being able to build applications that reliably
work through NATs and should be logically, if not physically,
associated with the NAT.
7.1. STUN
The NAT must run a Basic Standalone STUN server as defined in section
13 of [I-D.ietf-behave-rfc3489bis], with the exception that it is NOT
REQUIRED that it support TCP and it is not necessary to provide a DNS
entry for this server. The server MUST run on the address ::FFFE:
127.0.0.1 with default port of 3478. [[Note, if this address hack is
inappropriate, this could be resolved by just defining a well known
v4 anycast address for STUN and using that]]
7.2. DNS
The NAT MUST provide a recursive DNS resolver that is capable of
taking a DNS request received from the inside and resolving it on the
outside.
The resolver SHOULD try to take DNS A records results from the
outside and synthesize synthetic AAAA records that would be routed to
the using the v6 prefix. This SHOULD NOT be done if a record exists
that does not use the NAT prefix address.
7.3. DHCP
DHCP is very useful for the automated configuration of many things
beyond IP addresses. [[ TODO should any particular DHCP things be
required]]
7.4. V6 Routing / Tunnel
If a packet arrives from the inside with a v6 destination that is not
in the ::FFFE:0:0/96 range, the NAT could/(should/may) forward this
to the v6 internet. This could be via a direct v6 connection or some
646 tunnel. [[ Note not sure what to require / recommend here ]]
8. Requirement Conformance
8.1. RFC 4787 Requirements
NATs meeting this specification are compliant with the specification
defined for UDP NAT behavior in RFC 4787 [RFC4787], with the
exception that RFC 4787 requires reassembly of out of order packets
while this does not.
Jennings Expires May 7, 2009 [Page 11]
Internet-Draft NAT6 November 2008
8.2. draft-ietf-behave-tcp Requirements
NATs meeting this specification are compliant with the specification
defined for [I-D.ietf-behave-tcp], with the exception of Req-9, which
requires ICMP, and Req-5, which requires that mapping of established
TCP connections with no traffic to stay valid for 2 hours and 4
minutes, while this requires only 10 minutes.
8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement Requirements
Meets all the MUST support items in
[I-D.bagnulo-v6ops-6man-nat64-pb-statement] except the requirement in
R7 for ICMP support.
Meets all the SHOULD support items except:
I4 requires support for out of order fragmented packets. See
security consideration section in this document for more
discussion on this.
I6 - not clear whether or not all of MIPv6 works with this.
I7 & I8 require support for DCCP and SCTP which could be done as
an extension to this.
I9 - not clear when this does and does not work with multicast.
8.4. draft-nishitani-cgn Requirements
Meets all the requirements of [I-D.nishitani-cgn] except the
following:
R4 & R9 - require support of ICMP.
R5 & R6 are additional constraints on reserving ports which are
not mandated by this specification; but a device that was fully
compliant with this specification could still support these.
R7 & R8 are analyzed in Section 8.1 and Section 8.2.
8.5. Multicast
More analysis is needed - your mileage may vary. Some important
multicast applications such as an IP TV-like system that used an SSM
sender in the v4 space with clients in the v6 space could probably be
made to work fine, with little modification for v6-only clients.
Some other multicast scenarios with senders in both the v4 and v6
space probably would not work.
Jennings Expires May 7, 2009 [Page 12]
Internet-Draft NAT6 November 2008
9. IANA Considerations
This document makes no request of IANA.
Open Issues: What prefix to use. We will want to allocate a
different prefix than the ::FFFE:0:0/96. This draft makes no
argument about which prefix would be best, it just requires that the
specification define some fixed prefix to use.
Note to RFC Editor: this section may be removed on publication as an
RFC.
10. Security Considerations
Often NATs are combined with firewalls that perform address-dependent
filtering (as defined in [RFC4787]) to improve security. The type of
NAT envisioned here is a large, carrier-grade NAT with many clients
behind it. Performing firewall operations at this location in the
topology is not particularly effective because the attacker may well
be on the "inside". The firewall capabilities should be provided
much closer to the host being protected. The benefit of having
mappings with address-independent filtering is that it make it
possible to easily run servers inside the NAT with no modification of
the clients outside the NAT. For this reason, this specification
adopts a NAT design with address-independent filtering.
One of the concerns about a large scale NAT that a single host inside
the NAT might be able to perform a DOS attack by using up a large
portion of the available external ports simply by creating many
mappings. To mitigate this, the NAT SHOULD allow a configurable
limit to the number of mappings that can be created by a single host
inside the NAT.
TODO - reassembly of out of order packets
11. Acknowledgements
Thanks to Dave Ward who pointed out that I and others were spending
too much time making this complicated and should stop talking and get
on with writing some drafts. Thanks for helpful comments from Mangus
Westerlud, Iljitsch van Beijnum, and .
12. References
Jennings Expires May 7, 2009 [Page 13]
Internet-Draft NAT6 November 2008
12.1. Normative References
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-16 (work in progress),
July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
12.2. Informative References
[I-D.bagnulo-v6ops-6man-nat64-pb-statement]
Bagnulo, M. and F. Baker, "IPv4/IPv6 Coexistence and
Transition: Requirements for solutions",
draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in
progress), February 2008.
[I-D.ietf-behave-tcp]
Guha, S., "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-07 (work in progress), April 2007.
[I-D.nishitani-cgn]
Nishitani, T. and S. Miyakawa, "Carrier Grade Network
Address Translator (NAT) Behavioral Requirements for
Unicast UDP, TCP and ICMP", draft-nishitani-cgn-00 (work
in progress), July 2008.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Jennings Expires May 7, 2009 [Page 14]
Internet-Draft NAT6 November 2008
Author's Address
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
Email: fluffy@cisco.com
Jennings Expires May 7, 2009 [Page 15]
Internet-Draft NAT6 November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Jennings Expires May 7, 2009 [Page 16]