Subject: Re: (NAT) Re: Host-NAT terminology

From: "Mike Borella" <[email-masked]>
Date: Fri, 8 Jan 1999 18:01:17 -0600

Suresh,

I'm not too set on any particular semantics, but I
found your first paragraph below rather confusing.  Can you
reword it?

-Mike

[email-masked] (Pyda Srisuresh) on 01/08/99 02:55:53 PM

Please respond to [email-masked] (Pyda Srisuresh)

To:   [email-masked]
cc:   [email-masked], Mike Borella/MW/US/3Com, [email-masked]
Subject:  Re: (NAT) Re: Host-NAT terminology

I have issues with the semantics you are assuming.

First, Host-NAT does not mean that the Host-NAT client node is
implementing NAT.  NAT is not delegated from the server to client.
It simply means it has an address (and port, optionally) that belongs
to the same realm its peer belongs to. The address may or may not
have been delegated by a NAT device. A NAT router enroute may simply
be used to facilitate packet routing across and within realms.
Delegation of NAT  functionality is not Host-NAT. It simply is
another NAT, like between 2 backup NAT devices.

Second, Host-NAT does not impose any behaviour on the parner nodes.
I.e., there is no reason to believe that Host-NAT client will not
be communicating with a NAT node on the other end. It could be.

I dont see how Host-NAT is restricting.  If we need to discuss this
some more, I suggest, we do this off-line. Thanks.

cheers,
suresh
>
>
> Suresh,
>
> On behalf of our group working on HNAT/DNAT documentation, may I suggest
> that we use end-to-end NAT (e2eNAT) to replace HNAT/DNAT and to request
> change to the terminology draft? This is because concepts of HNAT/DNAT
> essentially involve delegation of NAT from NAT-Server to NAT-Client,
where
> NAT-Client could be either intermediate entity or end host. We have a
> section detailing a cascaded scenario in our new draft. HNAT seems to
> restrict the concept to end hosts.
>
> Jeff
>
> On Fri, 8 Jan 1999, Pyda Srisuresh wrote:
>
> >
> > Mike,
> >
> > May I suggest we use a single term - "Host-NAT" to discuss Host-NAT
> > issues. It is confusing to use 2 terms (DNAT and Host-NAT) describing
> > the same thing. The NAT terminology draft uses "Host-NAT" term. Unless
> > there are differences in semantics, I suggest retiring the DNAT term.
> > It is particularly important to converge on a single term, as you folks
> > are embarking on a framework document.
> >
> > Thanks.
> >
> > cheers,
> > suresh
> >
> > >
> > > This message reminded me of something I've been
> > > thinking about for a while now.
> > >
> > > There seems to be a need for a generic method with
> > > which a host can "go out and get stuff" where
> > > 'stuff' is configuration info, policy info, security
> > > info, addressing info, AAA, etc.  Most of the
> > > interactions are pull, but some may be push.
> > >
> > > Currently we have BOOTP/DHCP, RADIUS/DIAMETER/IPCP, COPS
> > > and perhaps several others (e.g., IP telephony requires
> > > similar components but the signaling is still being worked
> > > out).  These protocols all try to be (or have been forced
> > > to be) general and extensible.
> > >
> > > In the continuing DNAT/HostNAT work, we are defining
> > > yet another protocol, this one for passing info back to a
> > > NAT-client.  While we will continue developing the
> > > protocol because it will help us determine the parameters
> > > that need to be supported in DNAT/HostNAT, it seems as
> > > if this is getting redundant all over again.
> > >
> > > Obviously, all of these are candidates for whatever RUTS turns out.
> > >
> > > Thoughts and suggestions?
> > >
> > > -Mike
> > >
> > >
> > >
> > > -
> > > To unsubscribe, email [email-masked]' with
> > > 'unsubscribe nat' in the body of the message.
> > >
> >
> > -
> > To unsubscribe, email [email-masked]' with
> > 'unsubscribe nat' in the body of the message.
> >
>
>

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

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

---

From: [email-masked] (Pyda Srisuresh)
Date: Mon, 11 Jan 1999 08:58:22 -0800 (PST)

Mike,

See my response to Brian Carpenter on the rationale behind 
the term "Host-NAT". Hope, that clears up some confusion.
If you still find it confusing, I am afraid, I dont understand
where the confusion might be. 

cheers,
suresh

-