@techreport{ietf-nat-hnat-00, number = {draft-ietf-nat-hnat-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-nat-hnat/00/}, author = {Kunihiro Taniguchi and Jeffrey Lo}, title = {{IP Host Network Address (and Port) Translation}}, pagetotal = 14, year = 1998, month = nov, day = 23, abstract = {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.}, }