IP Host Network Address (and Port) Translation

Document Type Expired Internet-Draft (nat WG)
Last updated 1998-11-23
Stream IETF
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


Network Address Translation has become a popular technique that allows private addresses unregistered with Internet Assigned Number Authority (IANA) to be used by organizations within a private routing realm. These private addresses must not be advertised in the public Internet. Hence network address translator (NAT) are placed at the private routing realm border to translate private addresses to globally unique addresses and vice versa before packets are exchanged between the disparate routing realms. These modifications of the packet header by the NAT cause problems with the use of end-to-end security protocols such as IPSec and DNSSEC because network address translation does exactly what the security protocols are trying to prevent. Host Network Address Translation (HNAT) and Host Network Address Port Translation (NAPT), on the other hand, enable end hosts to carry out address (and port) translations before applying security algorithms. To make dynamic HNAT and HNAPT possible, three conditions are essential. First, there must exist a way for end hosts to discover the IP address of Host-NA(P)T-Server. Second, there must be a way for externally destined packets to be routed in the private domain between the Host -NA(P)T-Client and Host-NA(P)T-Server. Lastly, Host-NA(P)T-Client must be able to obtain an address (and port) binding from the Host-NA(P)T -Server dynamically. This draft aims to address these issues to a considerable extent. Methods suggested are by no means exhaustive in coverage and implementation specifics may vary from vendor to vendor.


Kunihiro Taniguchi (taniguti@ccrl.sj.nec.com)
Jeffrey Lo (jlo@ccrl.sj.nec.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)