Subject: RE: (NAT) RSIP Port Usage Question

From: [email-masked]
Date: Mon, 4 Oct 1999 07:03:22 -0500

RSIP is meant to be as transparent as possible to anything above
layer 3.  There will never be an application-specific messages, unless
the face of application writing changes so dramatically that something
like that is warranted.

Tom, unless you can provide a compelling example of a real, deployed
protocol that requires the feature that you suggest, I don't see support
being built into RSIP.  We're considering more general messaging which
may happen to help, but nothing specific.

Playing devil's advocate for a moment, why would anyone want a protocol
that can only use ports above or below a certain number?  Isn't this an
example of inflexible design which may lead to more problems down the
road?  Are we talking client or server ports?

-Mike

"Tang, Tom J" <[email-masked]> on 10/02/99 04:30:49 PM

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

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

To:   "'Gabriel Montenegro'" <[email-masked]>
cc:   "'nat @livingston.com'" <[email-masked]> (Mike Borella/MW/US/3Com)
Subject:  RE: (NAT) RSIP Port Usage Question

  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

-
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: Michael Richardson <[email-masked]>
Date: Mon, 04 Oct 1999 14:27:11 -0400

>>>>> "Mike" == Mike Borella <[email-masked]> writes:
    Mike> Playing devil's advocate for a moment, why would anyone want a
    Mike> protocol that can only use ports above or below a certain number?
    Mike> Isn't this an example of inflexible design which may lead to more
    Mike> problems down the road?  Are we talking client or server ports?

  My understanding of the problem was that this was just an example.
  The problem was that one needs two ports with the same IP address. A
general RSIP server might be willing to map to multiple public IP addresses 
(M:N mapping), and the protocol might require that the control and data ports
appear to originate from the same host.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.