INTERIM_MEETING_REPORT_

Reported by Paul Francis/Bellcore

Minutes of the Network Address Translators BOF (NAT)



Purpose

The purpose of the meeting was to:


   o Describe Kjeld Egevang's implementation of a simple NAT box.
   o Determine what benefits might come from NAT.
   o Determine what problems exist with NAT.
   o Determine how we might use Kjeld's implementation to learn more
     about NAT.



Kjeld's Implementation

Kjeld's NAT implementation is described in the NAT Internet-Draft.  The
scheme in that document is not dynamic in that the addresses used for
translation are statically assigned to single hosts for long periods of
time.  It is possible, however, to re-assign them to other hosts.
Another aspect of the scheme described is that the addresses on the
backbone side of the translator must be globally unique.  It was pointed
out that other NAT schemes do not have these characteristics (for
instance, one proposed by Van Jacobson).



NAT Benefits

Some of the potential benefits of NAT discussed during the meeting were:


  1. Make number administration of IP addresses generally easier by
     limiting that administration to border routers and DNS,
     particularly the renumbering of IP domains.

  2. Using NAT to aid in address re-use by allowing a small number of
     hosts inside a domain, which have re-used addresses, to be able to
     talk outside through NAT.

  3. Learn more about address translation in general so that we can
     better do translation for IPng (or, so that we can decide not to
     try translation for IPng).

                                   1





There was some opinion that benefit 2 could much better be accomplished
by simply giving the hosts that can talk outside multiple addresses:  a
re-used one for intra-domain use and a globally unique one for
inter-domain use.  There was some opinion that application level
gateways might be a better approach in general.


NAT Problems

A number of NAT problems were discussed.  Some were already known and
described in Kjeld's talk.  For instance, it is necessary for the router
to have to dig into application headers to modify carriage of IP
addresses.  In the case of FTP, this requires that packet lengths be
changed, and that sequence numbers in all subsequent TCP packets be
changed.  This is a heavy processing burden on routers, and requires
router state, with the resulting scaling and reliability problems.

Any encryption of higher layer protocols that rely on IP information,
such as TCP and FTP, will break with NAT. This also breaks Kerberos
authentication.  Any application that depends on carriage of an IP
address that NAT does not account for will break with NAT. There does
not exist a complete list of what applications those are, but it is
clear that a number of things do work with NAT, such as telnet and mail.

It was mentioned that RFC 1006 applications break with NAT, but it is
not clear why and the reasons were not discussed.


Conclusion

It was generally felt that it would be useful to the IP community to
have more knowledge of the pitfalls of NAT. This is particularly true
because anybody can install a NAT box independent of anybody else, and
in the absence of any NAT standard.

Paul Francis was given an action item to find the list of applications
that work over NAT that was generated when he experimented with NAT a
couple of years ago.  It was decided that there should be
experimentation with NAT, with a goal of producing a document describing
completely the characteristics of NAT. Kjeld was given the action item
of coordinating these experiments.  Nobody felt a need to follow up this
BOF near-term with another meeting.  It might be useful to meet once
again after results are obtained, but this was left open until that
time.


Attendees

Nick Alfano              alfano@mpr.ca
Frederik Andersen        fha@dde.dk
Robert Blokzijl          K13@nikhef.nl

                                   2





Jim Bound                bound@zk3.dec.com
Ross Callon              rcallon@wellfleet.com
Richard Colella          colella@nist.gov
Francis Dupont           francis.dupont@inria.fr
Kjeld Borch Egevang      kbe@craycom.dk
Eric Fleischman          ericf@act.boeing.com
Peter Ford               peter@goshawk.lanl.gov
Paul Francis             Francis@thumper.bellcore.com
Terry Gray               gray@cac.washington.edu
Chris Howard             chris_howard@inmarsat.org
Christian Huitema        Christian.Huitema@sophia.inria.fr
Geoff Huston             g.huston@aarnet.edu.au
Bill Manning             bmanning@rice.edu
David Marlow             dmarlow@relay.nswc.navy.mil
Greg Minshall            minshall@wc.novell.com
David Piscitello         dave@mail.bellcore.com
Robert Reschly           reschly@brl.mil
Luc Rooijakkers          lwj@cs.kun.nl
Keith Sklower            sklower@cs.berkeley.edu
Fumio Teraoka            tera@csl.sony.co.jp
Richard Thomas           rjthomas@bnr.ca
Claudio Topolcic         topolcic@cnri.reston.va.us
Noriko Yokokawa          norinori@wide.ad.jp



                                   3