2.7.9 Network Address Translators (nat)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Pyda Srisuresh <srisuresh@yahoo.com>
Matt Holdrege <holdrege@lucent.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

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.


Request For Comments:







IP Network Address Translator (NAT) Terminology and Considerations



DNS extensions to Network Address Translators (DNS_ALG)



Security Model with Tunnel-mode IPsec for NAT Domains

Current Meeting Report

NAT WG meeting minutes - 46th IETF - Washington, DC - Nov 7, 1999

Pyda Srisuresh - srisuresh@yahoo.com
Matt Holdrege - holdrege@lucent.com

Reported by:
George Tsirtsis - gtsirt@hotmail.com
Gabriel Montenegro - Gabriel.Montenegro@Eng.Sun.COM

Prepared by: Suresh & Matt

In order to avoid confusion, the following indentation and format legend should be used as a guide to interpreting the minutes.
<Presenter> - "<presentation/Discussion Topic>"
<Remarks by minutes taker or editors>

Detailed Slides and/or Comments made by the presenter

Matt Holdrege - Agenda

Daniel Senie

Dan Raz

Pyda Srisuresh

Mike Borella, et al

Carmello Zaccone

Matt Holdrege

Vern, Transport Area AD, said that ipr should be disclosed as early as possible. if you can't disclose, you MUST abstain from discussion of the technology. you have a moral obligation to do so. no comments on what would happen if you don't abide by this ietf policy.

daniel senie - nat-app-guide-02.txt

Comments received from Suresh but not from anyone else. More comment are welcome. Will get a new rev of the draft out shortly.

dan raz - nat-snmp-alg-02

defined further problem scope, limitations and alternatives solutions, eliminated snmp discussion

Juergon: There are technical problems (sorry for not having time to do this on the list). Need to discuss snmpv3 (not just v1), also some conclusions and mechanisms are suspect.

answer: we're addressing industry need, and nobody is using v3 today.

suresh: what are the issues?

answer: main concern - we need to know what snmp alg can do and cannot do and impacts/consequences on snmpv1 versus v3

matt: should discuss v3, but v1 is definitely in order.

suresh - nat-interface-framework-00

There is renewed interest in the draft because of (a) mib spec for nat, (b) requirements on how to interface with a NAT as an alg, etc. so revised and reworded the old draft to address these issues specifically. This draft should also help in identifying RSIP protocol requirements.

Also described is how an FTP-ALG would use the interface to influence NAT operation.

FTP-ALG registration process expressed in the context of this framework functions exchanged between the ftp-alg and the nat gw working group polled for any comments.

Elliot Lear: Is there support for moving this forward as an RFC?

No comment from the audience.

Suresh: Anyone who doesnt want the draft move forward?

No comment from the audience.

Elliott: The draft should move forward only if there is explicit request from the work group instead of operating the other way around.

No comment from the audience.

mike borella - RSIP drafts

RSIP framework draft-


This can be addressed in different ways from simple mechanisms to heavy weight (transaction processing type of thing) but it is not critical for RSIP at this stage.

interaction with mobile ip

suresh: it's ok to not finish everything on the first round, as long as you scope clearly what is being solved. Need to finish the framework and basic protocol first. Work on other issues in parallel.

Matt: you can always ask the mobile ip list for comments.

Brian Carpenter:
Need to know if there are show stoppers in mobile IP and any other protocol, details can be worked out later.

Mike continue with the presentation.

next steps - Still need to work on the following:

must scope rsip to be able to finish it (at least partially) within the near future

suresh: is rsip an app specific configuration or host specific on the client? There might be reasons to only use RSIP for a set of applications.

matt: It is stack specific.

Gab: similar problem to mobile ip and ipsec: it's possible to use it selectively

Elliot: Much better than last draft. Still some issues with the draft:

Danny Raz: UDP packet size might be larger than what the spec says.

suresh: Two points:

Elliot lear: Two points.
1. rsip is a remediation. it's got overhead. Applications should be able to do things other than RSIP. Need to discuss on e-mail
2. cascading rsip servers you used public address space, this is the right thing. when you cross realms the recommendation worth restating is that you use public addresses.

Brian Carpenter: on point 2 above, clear conclusion from the iab workshop is that the global address space is a requirement

RSIP protocol draft -

Streamlined. One way of doing rsip. Basic primitives to do rsip. Anything else should go in a separate draft (like rsipsec)

To be done:

What should be the trasport medium for RSIP? - tcp vs udp

Matt: If there are no objection the best thing is to have only one transport protocol and this is TCP. If later we realise that UDP is needed for a case we can do it later.

Mike: I agree

suresh: Server could support both and client should be able to choose between the two since the RSIP protocol does not depend on the underlying transport medium.

Mike: In fact there might be changes in the protocol. E.g some things are not needed if you do TCP.

Eliot: Also agrees that ONE protocol is best but RSIP seams too lightweight for heavy TCP connections.

Mike: Other things constrain RSIP resources before TCP state becomes a problem
Elliot: What are the benefits of TCP?

Mike: better security, reliability
Bernard: TCP also helps with state control since the TCP connection will drop if a client crashes.
Gabriel: Auto-tuning can solve the large number of TCP connections problem.

Matt asked for show of hands: The rough consensus was to use TCP-only as the transport.
UDP may be brought in later on.

Suresh: Couple of other comments.

Mike: Tunnel is the only mechanism we are sure will work at the moment.

RSIP IPsec draft -

Just made the cut-off day. Some work is still needed here.

Gabriel Montenegro: Need discussion on how to handle incoming SAs

Bernard Aboba: There might be an issue with interactions with IPSEC bump-in-the-stack implementations.

carmelo zacconi - RSIP transport (within private realm) framework

Possible extensions on the RSIP framework on the transport of datagrams in a native way without using tunnels.

Enable forwarding of incoming packets without tunneling to the rsip client

How to enable these reverse paths? the other drafts explore specific mechanisms with their tradeoffs. Specific mechanisms to build the reverse path are:

RSIP-gen-arch -

Aim to make RSIP more reliable
De-couple set of functions from RSIP server
Support RSIP multihoming
Offer policy and accounting
Assume multiple ISPs and multiple function blocks building RSIP (Policy Manager, Internet Session Manager and Configuration Manager)

Brian Carpenter:
1. The idea of not using tunnels when you can is good.
2. Multihoming needs to be solved but this seams like a very complex solution because it attempts to define an architecture. IETF only defines tools.
3. Reliability is important but having a lot of stateful boxes is against Internet design principles and may damage the stability of the whole system.

Gabriel Montenegro(Gab):
On the transport alternatives: suggest to have routing ADs look at this, as this is not specific to rsip but may apply in other areas as well, and is hightly routing specific in content.

Eliot Lear: Many interesting points in the draft (not agree with all). Not using tunnelling is also good if you try to do things like Diffserv. The separate Policy Manager is also a good idea.

Suresh: The draft is interesting and may have wider applicability as the draft is really about RSIP route/policy enforcement on the routers in private realm.

Mike Borella: This is interesting for rsip+ but is perhaps not part of rsip first release.

matt holdrege - NAT protocol complications.

Matt will issue an IETF last call after the next rev is posted.

Tony Hain: Scott bradner currently has the pen on the IAB document.
Should get a new rev out in a couple of weeks (by the end of 11/99?)

james kempf (sun) - Using SLP for RSIP server discovery

why not to use DHCP; but use SLP:

Template for rsip servers
template-type = rsip
template-version = 0.0
url-syntax = ;nothing_beyond: host:port
ipsec-support = BOOLEAN
ike-support = BOOLEAN
tunnel-type = STRING L

etc.. draft forthcoming

suresh: seems applicable

Elliot lear: how to handle multiple rsip servers?

jim kempf: slp has a semi-reliable mcast called mcast convergence which can aid in this

Mike borella: looked at dhcp individual submission draft that defines dhcp option for server redirect

suresh: suggests this draft be submitted as working group item. seems like a good idea to have both options - DHCP configuration option as well as SLP.


None received.