Subject: (NAT) RSIP Port Usage Question

From: "Tang, Tom J" <[email-masked]>
Date: Fri, 1 Oct 1999 09:45:58 -0700

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.

---

From: Jeffrey Lo <[email-masked]>
Date: Fri, 1 Oct 1999 11:08:19 -0700 (PDT)

Hi Tom,

It's true to for any protocol extension base on RSIP, the protocol field
would have to be added as a tuple to the demultiplexing fields. Please
refer to draft-ietf-nat-rsip-ipsec-00.txt as an example. What comes after
that is totally up to the protocol, e.g in IPSEC protected data traffic,
it could be the SPI and not port, as long as this field serves to further
de-multiplex the traffic within its own protocol domain. 

It would be useful to discuss this in the framework and protocol
drafts. 

Jeff Lo

-

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 1 Oct 1999 15:14:47 -0700 (PDT)

tom,

would this problem be helped by perhaps *allowing* the 
client to suggest hints as to the assignments it would like to get?

basically, the client asks:

	"hi, i'd like to eventually reach <ultimate_destination>
	and in order to do so i need port(s) and here are some
	hints as to those values"

benefit of allowing the client to suggest port number hints:

	the server would know which port numbers/ranges are likely
	to be usable by the client (the example you brought up)

benefit of allowing the client to specify who the ultimate destination is:

	besides the network interface closest to the client, the server may '
	have several interfaces on the "other" side(s). this hint may be, in
	fact, a requirement in order to know which outgoing interface
	must be used. if each interface is connected to a separate address
	space, the rsip server needs to lend the rsip client an address on
	the right address space. [this is not nearly as urgent a need as
	the previous item on port assignment, though].

-gabriel

-

---

From: Jeffrey Lo <[email-masked]>
Date: Fri, 1 Oct 1999 15:59:58 -0700 (PDT)

How about defining a new RSIP method for the protocol you want to use?

----

Jeffrey Lo
C&C Research Labs,
NEC USA, Inc.
Tel : (408) 943 3033
Fax : (408) 943 3099

-