Subject: Re: (NAT) Re: Comments on RSIP

From: [email-masked]
Date: Mon, 8 Jan 2001 13:51:18 -0600

The first issue is a misunderstanding (or perhaps a lack of clarity on our
part...).
The draft specifically states that an RSIP server address can be
passed to a client with the DHCP next server *option* which has been
defined in another (now expired) draft.  If anyone would like to see
the draft, I can forward a copy.

The second issue is one that we were aware of, but it never was
specifically brought to our attention, flagged by the WG, a showstopper
in any way, shape or form, nor (IMO) is it major.  To the best of my
knowledge, there are no well known ports for which one application
uses TCP and another uses UDP.  So I'm not sure of the point of
say, giving TCP port X to one host and UDP port X to another. Not saying
that it can't be done, but any advantage of doing so would be minimal.

Thanks for the comments,
-Mike

Pyda Srisuresh <[email-masked]> on 01/06/2001 01:25:21 PM

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

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

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

Folks,
Folks,

There has apparently been a problem with the NAT mailing list
([email-masked]) and people havent been able to post messages
to the list. My apologies. I will send an e-mail out to
the list administrator about the problem and hopefully have it
fixed. In the mean time, if any of you have had faced this
problem with posting, please submit your message to
[email-masked]. Thanks.

Below, I am reposting a message concerning some issues raised
with the RSIP documents. The message had apparently not showed
up on the mailing list. Please review the message and add your
input to the authors and the list. Thanks.

cheers,
suresh

--- Patrick Bihan-Faou <[email-masked]> wrote:
> From: "Patrick Bihan-Faou" <[email-masked]>
> To: <[email-masked]>,
>    <[email-masked]>,
>    <[email-masked]>,
>    <[email-masked]>,
>    <[email-masked]>
> Subject: Questions about RSIP
> Date: Wed, 13 Dec 2000 15:28:32 -0500
>
> Hi,
>
>
> First of all, excuse me for sending you this email directly. I subscribed to
> the NAT IETF mailing list, and sent that message there originally, but it
> never showed up on the list. If you could tell me where is the best place to
> hold this discussion, I'd appreciate it.
>
>
> Now onto my questions/remarks about RSIP...
>
> First, draft-ietf-nat-rsip-framework-05.txt indicates that the RSIP gateway
> address should be indicated using the "next-server" field of the DHCP
> packets. Why was such a decision made ? More precisely, wouldn't an DHCP
> option be better suited for that ? I feel that using the "next server" field
> would cause interaction problems with older DHCP implementations (which
> could understand the "next server" as being the one that will provide a boot
> file for example). Also it does not provide the same level of flexibility as
> an option would: with an option one could specify multiple possible RSIP
> gateways either by IP address of by name to be resolved using DNS.
>
>
> Second, I have a question related to the RSAP-IP mode as described in "".
>
> In the RSIP protocol definition (using RSAP-IP), a host can request a set of
> ports. These ports are supposed to be the de-multiplexing information used
> by the RSIP gateway to forward the traffic to the proper destination (RSIP
> Host). The information used for multiplexing/demultiplexing IP traffic
> largely depends on the protocol used (TCP, UDP can use ports, ESP or AH
> could use the SPI, other protocols may rely on other "unique"
> identifications). However I am surprised that nowhere in the RSIP protocol,
> the IP protocol that will be used is indicated. Namely, the RSIP parameter 2
> is used to indicate what port numbers have been assigned but without
> specifying if these are for UDP or TCP. The way I understand this is that
> once a port number is assigned to a host, it is reserved on the RSIP gateway
> for both UDP and TCP. This seems to be a waste of resources on the RSIP
> gateway. Also it is definitely protocol dependent (it can be used only for
> UDP and TCP), and is not applicable for a ESP/AH connection (there may be
> other issues with ESP/AH, I just mention that as an example). Shouldn't
> there be a protocol identifier in the RSIP message indicating which protocol
> the multiplexing info is requested for. This identifier can take the
> protocol value for which the request is made (UDP, TCP, ESP, AH, whatever
> else) and would add semantic to the current "port" parameter (context for
> interpretation: UDP => port #, ESP => SPI #). This way the "port" parameter
> would be more general (i.e. "multiplexing ids"), and could be used in more
> applications than just UDP/TCP. Also it would limit the resource waste on
> the RSIP host (no need to tie UDP port 80, because a host requested usage of
> TCP port 80 for a web server).
>
> If I missed an important fact, please enlight me!
>
> Patrick.
>

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
-
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.
List archive: <URL:http://www.portmasters.com/archives/>
<<  END
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 19 Jan 2001 09:00:00 -0800

At 04:47 PM 1/18/2001, Patrick Bihan-Faou wrote:

>"Matt Holdrege" <[email-masked]> wrote in message
>news:<[email-masked]>...
> >
> > > > Shouldn't there be a protocol identifier in the RSIP message
>indicating
> > >which protocol
> > > > interpretation: UDP => port #, ESP => SPI #).
> >
> > Seeing as how this is proposed as an experimental RFC, I think such input
> > would be useful during the experimentation of this protocol. As for now,
> > I'm inclined to letting the RSIP experimenters play with the protocol as
> > is. Your suggestion is a good one and I wish we had heard it a year ago.
> > But I expect many more useful comments as folks continue to experiment
>with
> > RSIP.
> >
>
>Well since we can already identify these shortcommings is it completely
>reasonable to say "go ahead implement this" knowing very well that we will
>have to change this later.
>
>I can see people in the future saying "well we already have implementations
>out there, we can not break them, so we have to keep supporting this broken
>scheme". Do we really want to face that situation by publishing the current
>"broken" (in quotes) document as a RFC ?

This is precisely the reason that the IETF has a classification for 
Experimental RFC's. That way everyone knows that it is highly likely the 
protocol will change.

-