Subject: Re: (NAT) RSIP Port Usage Question

From: "Mike Borella" <[email-masked]>
Date: Fri, 1 Oct 1999 20:19:14 -0500

This message didn't seem to make it the first time, so I'm
resending it.

-Mike

---------------------- Forwarded by Mike Borella/MW/US/3Com on 10/01/99 08:22 PM
---------------------------

Mike Borella/MW/US/3Com
10/01/99 01:28 PM

Sent by:  Mike Borella   -  Senior Engineer, Carrier R&D

To:   "Tang, Tom J" <[email-masked]>
cc:   "'mike_borella, "[email-masked]'" <[email-masked]>
Subject:  Re: (NAT) RSIP Port Usage Question  (Document link not converted)

Tom,

In particular what protocol do you have in mind?  Is it in general
use in the Internet?

This issue has come up before in different forms.  Basically, it will
be useful to enable the client to "suggest" certain parameters to the
server, such as ports or an IP address.  I'm currently considering a number
of changes to the protocol which would make it more flexible and easier
to parse, and this may become one of them.

Naturally, the server is still the policy enforcement point and may not
listen to the client's suggestions.

-Mike

"Tang, Tom J" <[email-masked]> on 10/01/99 11:45:58 AM

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) RSIP Port Usage Question

  Hello Mike :

     I have a question on how RSIP allocates ports.  While
  working on an implementation,  we ran across a problem
  which the protocol does not address.  Say there
  exists a protocol running over IP which states that ports
  below X are invalid.  The gateway does not know this and
  allocates the client a range of ports below X for use.  When
  someone tries to communicate using this protocol, failure
  will result.
     We propose to solve this problem by separating port
  requests into different protocol types.  It would solve
  the problem described, as the gateway would be aware of
  individual protocol requirements.  In addition, if port requests
  were separated, different types of traffic could use the
  same port number (thus saving ports).  On the flipside,
  RSIP would not be protocol agnotic anymore.  Is there
  a better solution to this problem ? Thanks.

----------------------------------------------------------------------------
---------
Tom Tang                         Telephone : (503) 712-1791
Software Engineer             Office Fax : (503) 264-3843
Intel Architecture Labs       Email : [email-masked]

Disclaimer :  Any views expressed within belong to the
                   author and is not endorsed by my employer.
----------------------------------------------------------------------------
---------

-
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: "Tang, Tom J" <[email-masked]>
Date: Sat, 2 Oct 1999 14:30:49 -0700

Gabriel :

    I am just bringing this matter out so that it might
  be addressed in the RFC.  There might be protocols 
  developed in the future which could have such issues. 
  Also, if you are adding additional messages which are 
  protocol specific, that's what I meant when I said
  message differentiation.  Sorry if I wasn't clear.
  
                                               - Tom 

>     This is exactly what I am suggesting.  But it would
>   require the differentiation of messages sent 
>   between the server and client when using different protocols.

why? if the client wants a port in the 500-1000 range, and
if the rsip server grants him one, what else is needed?
i can see adding a new type of rsip message if a new type
of demultiplexing tuple needs to be negotiated, but in your
case, that does not seem to be the case as the demultiplexing
fields are still

	port number
	ip address

right? or is there any additional field that needs to be negotiated?

-gabriel

-