Subject: Re: (NAT) Another Question

From: "Mike Borella" <[email-masked]>
Date: Mon, 4 Oct 1999 17:01:06 -0500

The simple answer is to allocate more than one port per request
or to have policy at the server which tries to allocate the same IP
to multiple binds on a client.

Or, wait for the next RSIP protocol draft. :-)

-Mike

"Tang, Tom J" <[email-masked]> on 10/04/99 01:00:53 PM

Please respond to "Tang, Tom J" <[email-masked]>

Sent by:  "Tang, Tom J" <[email-masked]>

To:   "'Mike_Borella @3com.com'" <[email-masked]>
cc:   "'nat @livingston.com'" <[email-masked]> (Mike Borella/MW/US/3Com)
Subject:  (NAT) Another Question

  Mike :

    I have another question which you might have an
  answer for.  It is based on the diagram below :

     -----------               -------------
     | Client  |               |  Gateway  | <---> IP1
     |   One   | <-----------> |  /Server  | <---> IP2
     -----------               -------------

    Say I am using an application (i.e. ftp) which
  has a control channel and a separate data channel.
  Say the following occurs :

  * Client requests resources
  * Server assigns resources based on IP1
  * Client establishes control channel
  * Client tries to establish data channel, runs
    out of ports
  * Client requests more resources
  * Server assigns resources based on IP2
  * Client tries to establish data channel using
    IP2 resources.
  * Ftp would see two separate IP addresses.
    Not acceptable ?

    This is a potential problem for any application
  which tries to establish multiple flows.  Is there
  a solution for this ?

-
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: Pyda Srisuresh <[email-masked]>
Date: Fri, 8 Oct 1999 07:23:39 -0700 (PDT)

Hi,

Sorry to chime-in a bit late on this thread. I was out of town past
few days. I fully agree with Gabriel. I do believe, the RSIP protocol 
should allow requests for specific attributes. 

<draft-ietf-nat-api-00.txt>, titled "IP Network Address Translator 
Application Programming Interface" does describe function calls a NAT 
device could provide to address this type of specific as well as generic
requests. (Note, this draft has expired from the drafts directory a couple
of months ago. So, you wont find one now. I will try to send a new rev out
shortly. However, if you do need a copy of this draft, send me an e-mail 
and I could mail you a copy)

You might want to take a look at this draft for some thoughts on the nature
of requests that might be required to be supported in the RSIP protocol. 

cheers,
suresh  

--- Gabriel Montenegro <[email-masked]> wrote:
> again, if the client is allowed to suggest values at the same time it
> requests them, this problem should go away, i think. this is a simple
> change to the protocol. actually, i suggested it a few months back
> but the idea was to postpone such things for later. perhaps now
> is the time?
> 
> the dialog would be augmented thus:
> 
> ...and suggests IP1 as the ip address assigned along with the new
> 	resources
> 
>     * Server heeds client's hint and assigns resources
> 	based on IP1.
>     * all is cool, 
> 
>     or:
> 
>     * Client goes back to step above requesting new
>       resources based on IP1 (see above)...
> 
> steps below would not occur:
>                                   

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: [email-masked]
Date: Fri, 8 Oct 1999 09:38:47 -0500

The next verison of the protocol (-03) will allow this.  Tune in next week.

-Mike

Pyda Srisuresh <[email-masked]> on 10/08/99 09:23:39 AM

Please respond to Pyda Srisuresh <[email-masked]>

Sent by:  Pyda Srisuresh <[email-masked]>

To:   Gabriel Montenegro <[email-masked]>, "Tang, Tom J" <[email-masked]>
cc:   "'nat @livingston.com'" <[email-masked]> (Mike Borella/MW/US/3Com)
Subject:  Re: (NAT) Another Question

Hi,

cheers,
suresh

=====

-