2.7.8 Network Address Translators (nat)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98


Pyda Srisuresh <suresh@livingston.com>
Matt Holdrege <matt@ascend.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Vern Paxson <vern@ee.lbl.gov>

Mailing Lists:

General Discussion:nat@livingston.com
To Subscribe: nat-request@livingston.com
Archive: ftp://ftp.livingston.com/pub/archive/nat

Description of Working Group:

IP V4 Network Address Translation (NAT) has become an increasingly common function in the Internet for a variety of reasons. NATs are used to interconnect a private network consisting of unregistered IP addresses with a global IP network using limited number of registered IP addresses. NATs are also used to avoid address renumbering in a private network when topology outside the private network changes for variety of reasons. And, there are many other applications of NAT operation.

A number of NAT deployments are currently in use and naturally, a large number of internet applications work transparently with NATs. However, there are applications for which NATs would fail and custom-specific Application Level Gateways (ALGs) are required to perform translations for those applications.

NAT has the potential to interrupt end-to-end nature of Internet applications, thereby threatening end-to-end security and other end-to-end functions. In addition, NAT has topology restrictions and other constraints on the protocols and applications that run across NATs. Thus NATs have a particular area of application and should not be considered a general solution.

This working group will provide a forum to discuss applications of NAT operation, limitations to NAT, and impact of NAT operation on internet protocols and applications. The Working Group recognizes that NAT may interfere with protocols that use cryptographic protection for authentication, integrity or confidentiality. The Working Group will NOT suggest changes in such protocols to make them NAT friendly when such modification will significantly reduce the security provided by those protocols. However, the Work Group will examine and discuss alternative solutions, and other new ideas relating to this issue. Broadly speaking, the objective of the work group is to come up with a series of documents in the following categories.

The first category of documents will address what NAT is, how NAT works and applications of NAT operation in address conservation, prevention of address renumbering, load sharing and other areas.

The second category of documents will address requirements of NAT and limitations to NAT operation. Specifically, this will include a detailed list of applications which are known to have problems working over NATs.

The third category of documents are Informational RFCs which will specify NAT friendly application and protocol design guidelines, interactions between NATs and applications such as DNS and protocols such as IP sec. Particular emphasis will be placed on security issues. The Work group will also examine and discuss various alternative solutions, and other ideas to identify areas where NATs or other protocols and applications can be improved to overcome the shortcomings in interoperability or functionality.

The fourth category of documents will deal with network management of NATs.

Exploration of the use of NATs for load sharing is not within the scope of this working group.

The goals and milestones section below lists just the subject matter of issues to be covered. This is done so deliberately because there may be some adjustments made to the packaging of the RFCs, while covering all of the contents below. The work group will decide how to group the contents into different RFCs.

Goals and Milestones:

Aug 98


Submit Internet-Draft on what is NAT and how NAT works.

Aug 98


Submit Internet-Draft on NAT limitations and a list of applications and protocols known to have problems working with NAT.

Dec 98


Submit Internet-Draft on NAT friendly application and protocol design guidelines.

Dec 98


Submit Internet-Draft on Interaction of NATs with IP switching, roaming IP, mobile IP, IP multicast, DNS and other protocols and applications.

Dec 98


Submit Internet-Draft on security implications of NAT.

Apr 99


Submit Internet-Draft on Network Management Information Base for NATs.


No Request For Comments

Current Meeting Report

Chairs: Matt Holdrege <matt@ascend.com>

Reported by: Ben Rogers <ben@ascend.com>
Edited by: Matt & Suresh

Mailing list: nat@livingston.com

To subscribe: Send e-mail to nat-request@livingston.com with "subscribe"

To unsubscribe: Send e-mail to nat-request@livingston.com with "unsubscribe"

Mailing list: nat-digest@livingston.com

(This is nat mailing list, in daily-digest format.

To subscribe: Send e-mail to nat-digest-request@livingston.com with

To unsubscribe: Send e-mail to nat-digest-request@livingston.com with

Slide presentations:

All of the slides presented during NAT WG, along with meeting minutes are available
on-line from the following URL.




- NAT Terminology & Considerations Draft, by Suresh & Matt
- NAT Protocol Issues Draft, by Matt & Suresh
- Traditional NAT Draft, by Suresh & Kjeld
- DNS extensions to NAT Draft, by Suresh, George, Praveen & Andy
- Architectural Implications of NAT Draft, by Tony Hain
- Implications of NAT on TCP/IP Architecture, by Yakov Rekhter
- Miscellaneous Issues

ADs have emphasized that the meeting should be run so as to increase participation
from the audience. Draft authors should focus on issues raised about their specific
drafts rather than the presentations.

Pyda Srisuresh - "Nat terminology and Considerations"

NAT Terminology draft has gone through considerable review and should be put forward.

From a cursory poll, it seems just a few people have read the draft.

This needs to be out of the way quickly because it is used in all other drafts.



The chairs stated that without comments, this draft would go to Working Group last call.

Per Tony's request, Tony's draft review was moved ahead in the agenda.

Tony Hain - "Architectural Implications of NAT"

Some people feel this is an anti-NAT draft, but it is not intended to be. It attempts to
address the issues and discourage people from randomly using NAT. Ducking the
hard issues as out-of-scope is inconsistent with the group charter.


[Pyda Srisuresh - Guidelines are beneficial. Issues with DNS across realms + concerns
about fragmenting name space seem to be unfounded.]

It is the nature of people to do what they want. A fragmentation of namespace would
probably result from this chaotic behavior.

[Pyda Srisuresh - Should this be an issue?]

This cannot be ignored. We need to warn people to keep away from this sort of behavior.

Documents tend to be geared towards a NAT connecting private networks with public
networks. We don't have much of an architecture for connecting two private networks.
DNS can be an issue here because it likes to work through the public net.

[Pyda Srisuresh - NATs will tend to be connected through a VPN type network.]

Routing works fine, but DNS resolves don't tend to work without some interaction with
the public network.

Matt Holdrege - "NAT protocol issues"

This is very incomplete at the current time & needs feedback from the community.

We need people to come forward with both standard protocols & non-standard
protocols (games, multimedia)

[George Tsirtsis - Proxy protocols tend to have problems with NAT.]

Whether we want to do these things or not, we should document them, so the issues
are known to the larger community.

Go home, look at the draft and add comments about protocols which have issues. It is
preferred that commentators provide specific protocol actions through the NAT device.
Please send comments to the list or privately to the authors.

Pyda Srisuresh - "Traditional NAT"

This has been around for quite some time, but has now been isolated into its own draft.

Traditional NAT

- External Addresses are valid in private domain, but the reverse is not true.
- Permits outbound sessions only from the private domain. (This tends to provide
privacy for the private realm.)
- Basic NAT
* Private to External Address mapping
- Network Address Port Translation (NAPT)
* Many-to-one Address mapping

- RFC 1918 recommended private addresses

NAT is used so the end-nodes don't have to be aware of routing realms, and can treat
all hosts as if they were in the same realm.

Packet translations by NAT

NAT performs just the header translations, without changing payload. We need ALGs
to munge things in the payload.

- NAT translates IP header.
- NAT translates TCP/UDP headers.
- NAT translates ICMP headers & packet headers embedded in ICMP error packets.
- NAT does not modify transport payload.
- ALGs are needed for protocols which need payload modification.
- FTP ALG is used to assist with FTP payload and header translations.

NAT considerations

- NATs require ALGs to provide transparency for certain applications. (Merely
stating that we have a NAT is not good enough. One would need to assess the
need for applications on network and select appropriate ALGs to cover them.)
- IP addresses are not end-to-end unique.
- End-to-end IPsec not attainable with NAT enroute. (Endpoints need to be
locatable by their IP addresses as a requirement of IPsec.)
- End-to-end Transport level security attainable for certain applications not
requiring ALG.
- (Since the payload is not modified, we can encrypt the payload without adversely
affecting Transport security through a NAT.)
- Packet fragmentation could be problematic. (Multiple private nodes sending large
packets in fragments. NAT can only identify the fragments by their IP addresses.
There is no transport header in fragments after the first fragment.)
- NATs can be a target for attack such as SYN flood and ping flood attacks. (This
is a direct result of NAT keeping state. A number of packets could be sent to
make NAT run out of state storage space. NATs should employ the same
protection techniques adapted by Internet servers.)

Traditional-NAT limitations

- All of the limitations applicable with NATs
- Basic NAT is limited by the external addresses available for mapping.
- NAPT is limited to TCP/UDP/ICMP based applications.
- Typically operates on the borders of the Internet.
- Translation of fragmented packets originating from NAPT private domain.

[Steve D. - Was the previous slide meant to be a complete list?]

No. Full list is in the draft

[Steve D. - When address mapping changes, this would cause problems with some
protocols over time.]

Do you have Specific application in mind?

[General property of NAT. This is a change in the normal service model. Often,
multiple transport sessions are used in a logical session.]

In that case, such an application would need to be tracked by an ALG.

[George Tsirtsis - DHCP already does this.]

[Daniel Senie - Load sharing might cause problems, such as with nonces.]

Load sharing NAT is outside scope. However, there may be some Gaming
applications where such a requirement (serial reusability of same address mapping)
might exist.

[Liam Casey - Voice/Fax over IP H.323 does a register request which is more long
standing and you might get called at that address at some later time.]

[Radia Perleman - Should we put energy into some aging applications such as FTP?]

[Daniel Senie - NAT hasn't been around for too long so the "traditional" moniker is
strange. One thing we do is to map one server to a well known port (inside of NAPT).
This has yet to be addressed.]

Traditional is based on documents we already have.

Majority of cases, sessions are outbound. As a special case, you could map specific
services to certain private servers. If this is not mentioned in the draft, it should be.

Should we move drafts we have discussed so far into next stage?

[Daniel Senie - not the issues draft]

Okay. This needs help from the WG.

We will issue a WG last-call on the mailing list for these drafts.

George Tsirtsis - "DNS extensions to NAT"


Example Configuration/Terminology

Firewall within a private network with some servers between the firewall and a router
to external network, in a DMZ. These DMZ servers tend to have global accessibility.
We would like to put a NAT router between the DMZ and the public network.

Assumes that DNS names for the servers are unique and part of the globally unique
DNS tree.

Assignment vs Binding

- Address assignment
* an external address is _reserved_ to be used in place of a private address.
- Address binding
* an external address is committed to be used in place of a private address.

This address will be kept for some time so that sessions may pass based on this DNS

Address holdout time


DNS payload modifications by DNS-ALG

Header - No translation is needed

Zone transfers

Don't do zone transfers across the DNS-ALG


[Ramen R. - Is address holding concept resistant to denial of service?]

The holdout time is meant to ensure that this address is only assigned for a short
period of time.

Andy Heffernan - "DNS extensions to NAT"

DNS lookup sequence

Diagram, describing 6 steps involved in the lookup sequence

Traditional NAT + DNS-ALG

Follow the DNS lookup sequence, on the same diagram, with a (traditional NAT +
DNS ALG) box at the edge of private.com domain.

(Private machine looking up a public address doesn't do anything)

Bidirectional NAT + DNS-ALG

Follow the DNS lookup sequence, on the same diagram, with a (Bidirectional NAT +
DNS ALG) box at the edge of private.com domain.

- External Host wants to talk to private host (by assumption, dynamically translated).

- A-record (step 5) has the private address for HostA DNS-ALG maps private address
to a public address. HostX can then start a session to HostA

- DNS-ALG needs to translate request (step 4) before passing onto DNSe.

- Possible translation of A-record. PTR needs to be changed as well (step 5) so we
can match query with response.

Twice NAT + DNS-ALG (1)

Follow the DNS lookup sequence, on the same diagram, with a (Twice NAT + DNS
ALG) box at the edge of private.com domain.

Private network and public network are addressed from the same address space.

- HostA to DNSp
- DNSp to DNSroot
- DNS-ALG needs to produce an address assignment for DNSe(step 3)
- DNSp to DNSe
- A-record will need to be processed by DNS-ALG (step 5)
- Session can start and bindings can be made

Twice NAT + DNS-ALG (2)

This is the same as the bidirectional case.

DNS-ALG allows us to do the following:

- Outside world can start sessions with dynamically addressed private hosts.
- We can now have overlapping domains.


[Tony Hain - What happens if there is a delay and the address HostX gets (and
caches) is assigned to a different host.]

[George Tsirtsis - 0 TTL is given for all DNS-ALG modified responses.]

George Tsirtsis - "DNS extensions to NAT"



- The DNS-ALG is modifying DNS payload on transit
- Signed DNS responses cannot be altered by DNSALG.

How many people have read the draft?

[Maybe 10]

[??? - DNS request flood?]

The timeout is meant to prevent this problem. The attacker can prevent both incoming
and outgoing session by soaking up all the addresses with bogus requests.

[Still prone to Denial of Service?]


[Eric O. - Change timeout based on how many addresses have been given out?]

[Pyda Srisuresh - This doesn't give you much.]

We have to grapple with the problem of end-to-end unique names with non-unique

Yakov Rekhter - "Implications of NATs on the TCP/IP architecture"

Implications of NAT on TCP/IP Architecture


Comments on draft-iab-nat-implications-01.txt

Last WG meeting

- Proposal: take draft-iab-nat-implications-00.txt as input, and revise it to
* correct factual errors
* remove FUD
* clearly separate facts from opinions
* provide alternative opinions

Comments on draft-iab-nat-implications-01.txt

Improvements over the previous version:
> NATs and routing realms
>> impact on routing scalability
>> impacts on Address space consumption
> Use of SSL as an option to provide security

Comments on draft-iab-nat-implications-01.txt (cont.)

Confusion continues
> Handling DNS in the presence of NATs
>> "mandates multiple name spaces"

NOTE: See draft-ietf-nat-dns-alg-00.txt for technical information (reflecting
"working code")

These statements clearly don't reflect reality. People should look at the above draft
before making those types of statements.

Comments on draft-iab-nat-implications-01.txt (cont.)

Confusion continues
> Use of RFC1918 addressed by VPNs

>> "VPNs.. increase the likelihood od address collision when traversing NATs"

Problems with address space collisions caused by merging privately addressed networks.

Comments on draft-iab-nat-implications-01.txt (cont.)

Anti-NAT rhetoric continues
> "necessary evil"
> "weed which is destined to choke out continued development"
> "equivalent to digging a hole"
> "The single greatest threat to a secure Internet"
> "NAts are a diversion from forward motion"


Focus on architectural implications to the TCP/IP architecture We should broaden
the focus to look at TCP/IP as a whole.

- Identifies open technical issues
- Focus on facts, not on opinions.
- More technical substance, less passions/emotions.

Discuss implications on various components of the TCP/IP architecture.

- Implications on routing and addressing.
- Implications on DNS.
- Implications on transport layer.
- Implications on applications.
- Implications on security.
- Implications on performance.
- End-to-end address preservation.

Identify open issues

- Interconnecting routing realms in an arbitrary (mesh) topology (instead of a
CIDR tree format)
- Implications on DNS in the presence of DNS security and DNS dynamic updates.
- Carrying IP addresses in the application data stream
- Is that a good architecture?
- End-to-end address preservation - should this be revisited?
- (It is probably outside the scope of this WG.)

What is next?

- Solicit comments on draft-ietf-nat-arch-00.txt
- Revise based on the comments received.
- Publish as an informational RFC
- Comments?

[Tony Hain - If you want to address NATs, then there is nothing which is outside the
scope. It seems that only the negative opinion comments were quoted in this presentation.]

[Steve D. - Aesthetic judgments are an inherent part of architecture. Taking opinions
out of documents is not necessarily valid.]

Make a document of opinions?

[???? - SSL doesn't help if address is in payload.]

[Steve Bellovin - Addresses in FTP data stream are needed to setup the data channel.
Setup of this type of external data stream cannot be done without addresses. At some
point, you have to make a decision about the best way to do things. IPsec is probably
close to the correct way to handle this. NAT is a serious problem for this.]

You can make a value judgment, but this gets in the way of facts.

[Engineering is about making tradeoffs, and the tradeoff here is between security
and NAT.]

The tradeoffs should be made clear to the customers who can make their own decisions.

[Architecture tends to suffer from this.]

[Steve D. - Questions about whether something is a good architecture is inherently
asking for a value judgment.]

The document only brings up the issue. It doesn't say whether this is good or bad.

[Tony Hain - We can't stand up and ask whether this is a good architecture and then
state that it is outside the scope of the WG.]

This issue is broader than NAT.

[If this WG doesn't address the problem, then why are we making it worse.]

[Pyda Srisuresh - Words such as "NATs are evil" are not appropriate for expressing
an opinion.]

[Bob Moskovitz - If a WG is making a technological kludge and makes the architecture
more difficult than an administrator could manage, then shouldn't we do work to
address this complexity. It would be nice if we could simplify our work by using the
results of other WGs (such as address space conservation).]

[Matt Holdrege - We didn't invent NAT, but are merely documenting it.]

[Vern Paxson - Comments about how the architecture might be revised would
certainly be within the scope of informational documents, if done in an even-handed

[Ross Callon - Perhaps it is helpful to get addresses out of applications. They cause
problems for NAT, and would be a good move to help the migration towards IPv6.
There is usually no benefit of keeping the addresses in applications.]

[Tony Hain - The problem is the collision of address space. NATs tend to aggravate
this problem by making use of the private address spaces more frequently.]

suresh - "WG Goals and Milestones"

Below are the goals for the WG. While we are on-track so far (Aug'98), we are
looking for people to start work on the remaining drafts:


- What is NAT & NAT terminology draft
- Applicability of NATs
- Draft on Basic NAT and NAPT
- NAT limitations & known problematic protocols


- NAT friendly application design guidelines draft
- Multi-homed NAT applications draft
- Security implications of NAT


- Interaction of NATs with IP switching, DNS, roaming IP, mobile IP, IP
multicast, SOCKS,
- Integrated services, RSVP etc.


- MIB for NATs

[Shinwe Yeow - Any comments on NAT for IP mobility draft.]

[suresh - I will review the draft and send my comments.]


DNS extensions to NAT (DNS_ALG)
Illustrations to DNS_ALG
Implications of NATs on the TCP/IP architecture

Attendees List

go to list