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