Subject: (NAT) Host NAT issues

From: "Mike Borella" <[email-masked]>
Date: Thu, 3 Dec 1998 13:27:58 -0600

A couple of notes regarding the recent host NAT draft:

- We presented distributed NAT (DNAT) at the Chicago IETF in the
  ngtrans WG.  Host NAT is DNAT with only some very minor modifications.
  Interested parties should look at:

     http://search.ietf.org/internet-drafts/draft-borella-aatn-dnat-01.txt

- DNAT has been implemented (from the draft description) by a third party.
  It works quite well.

- The draft makes some incorrect comments about DNAT.  In particular,
  the authors claim that DNAT does not allow the sharing on multiple IP
  addresses, but it does.  This misconception seems to be the motivating
  factor of the (very minor) differences between DNAT and host NAT.

In case it isn't obvious, my point is that this scheme has already
been proposed and presented at IETF.  I do not think that host NAT is
significantly different from DNAT, though I'll happily entertain
arguments to the contrary.

-Mike

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Jeffrey Lo <[email-masked]>
Date: Fri, 4 Dec 1998 14:21:58 -0800 (PST)

Hi, 

This is sent in response to a recent comment about HNAT draft proposed to
NAT workgroup. 

We are particularly interested larger scale deployment of private
addressing. A case where a band of global IP addresses are managed by the
address manager, which may or may not reside on the Host-NAT-Server. We
realised the existence of DNAT draft and attempted to apply Port
Distribution Protocol (PDP) proposed in draft-borella-aatn-dnat-01.txt in
our scenario. It is during this attempt that we find PDP insufficient and
does not support dynamic global IP address assignment. Hence our primary
motivation is to propose a more generic protocol that serves a
greater majority of the NAT community. As a result, we are proposing 
Dynamic Bindings Acquisition Protocol (BDAP). Having said these, we do not
deny the fact that DBAP support port assignment as well and could be used
in places where PDP is used. 

Another motivation for our draft is the fact that we feel PDP lacks many
important features which are fundamental for larger scale operation. We
don't see our differences as being minor but rather fundamental. To state
some of the differences:

Error Reporting
It is important for accurate error reporting so that Host-NAT-Clients know
about source of error. For example, is a request denied due to resource
reasons, policy reasons or other miscellaneous reasons. This is not
possible with PDP.

Max. Leased Time
It is important for Host-NAT-Client to be able to negotiate a lease time
interval with Host-NAT-Server. This is especially important in scenarios
where address management and NAT are performed by different authority.
One example is the case when private addressing is adopted by an ISP and
it wishes to delegate global address lease on an enterprise basis. In
this case, Host-NAT-Clients deamons may not be situated in end host but
may be some access routers. In this case, such global leasing may be directly
connected to billing. In the current PDP, it is  unclear how this is done
apart from some default interval pre-selected during  configuration.

BindID
This is vital for both efficient indexing and serves as an identifier if a
Host-NAT-Client requests for more than one binds from a Host-NAT-Server.
For example, we know that IPSEC ESP does not work with NAPT, a Host-NAT-Client
may be using a port range for IPSEC AH. When an application is started
requiring ESP security, a global address needs to be acquired. BindID is
required to correctly identify bindings on Host-NAT-Server. It
seems to us that PDP only supports a single port range bind at
this moment. Although not a major motivation, BindID also introduces a
layer of protection against security attacks.
 
If you have some ideas or implementations that suits our purpose, we would
be glad to hear about it. We feel that it is unfair for the authors to
claim something that has not being documented.

Thanks.

Jeff

-