Subject: AW: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP

From: Schruefer Wolfgang <[email-masked]>
Date: Tue, 15 Feb 2005 03:38:21 -0800 (PST)

Melinda,

I think it is useful that you state that we have at least two different 
problems.

But I think it is not useful to close a discussion about one problem by 
refering to the unsolved other problem. 
I am afraid then we spin round ...

Please remember the history of this thread:

> Qiaobing,
> why do you think an extension for multiple destination ports 
> would make SCTP a different protocol? 
> Please consider that the SCTP protocol would remain untouched 
> for all existing scenarios. 
> Only if NAPT is involved such an SCTP extension may be used.
> ...
> Wolfgang
> 
> Qiaobing Xie wrote:
> > Luca,
> > Using a single port is a design decision made at a very early 
> > stage in SCTP development. Of 
> > cause it can be changed, but that would make it into a 
> > different protocol. 
> > -Q
> > 
> > Luca Laurenzi wrote:
> > > Quiaobing,
> > > You say that its not possible to extend SCTP to use 
> > > multiple ports in a single endpoint...
> > > but what is the problem?
> > > way SCTP cant work this way?..
> > > regards,
> > > Luca

Actually the discussion was about an extendend port number usage.
Personally I think this is an improtant requirement for a future use of NAPT 
and it may be solved ... e.g. by an SCTP extension ...

The second problem is the detection of external addresses:
Here I agree that the existing method by an address list within the 
INIT/INIT_ACK seems to cause problems, but there might be alternatives ...

Best regards,
Wolfgang

> -----Ursprüngliche Nachricht-----
> Von: Melinda Shore [mailto:mshore@xxxxxxxxx] 
> Gesendet: Montag, 14. Februar 2005 15:05
> An: Schruefer Wolfgang
> Cc: Ietf-behave@xxxxxxxxxxxxxxxxxxx
> Betreff: Re: AW: [Ietf-behave] Ietf-behave] Re: NATting SCTP
> 
> On Monday, February 14, 2005, at 08:36 AM, Schruefer Wolfgang wrote:
> > Please consider that the SCTP protocol would remain 
> untouched for all 
> > existing scenarios.
> > Only if NAPT is involved such an SCTP extension may be used.
> 
> I think that might be the more typical case.  Regardless, there
> are two problems here: 1) port reuse, and 2) "knowledge" of external
> addresses.  Even if the port problem were solved there's the other
> problem, in which the fellow sending out the INIT or INIT-ACK needs
> to be able to place the correct addresses in the address list or
> the NATs need to be able to do the appropriate fixup.  I think the
> latter is out of the question because it makes topological demands
> that are impossible to satisfy reliably.  If the problem is pushed
> back out to the endpoints (which arguably is the "correct" way to
> do things in IP networking, anyway), each host participating in
> the SCTP endpoint would be able to acquire knowledge of its external
> address using mechanisms already under development, but there is
> no existing mechanism for that information to be communicated to
> the host that sends the address list.  Possibly that information could
> be communicated using the same magic by which the host sending the
> INIT knows that there are other hosts participating in the endpoint,
> but wow - I wonder if there are any limits to how far we're willing
> to go to get stuff to work across NATs.
> 
> Melinda
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 Feb 2005 05:29:11 -0800 (PST)

On Tuesday, February 15, 2005, at 06:38 AM, Schruefer Wolfgang wrote:
But I think it is not useful to close a discussion about one problem 
by refering to the unsolved other problem.
To the contrary - I think that in the past the IETF has made
some big balls of wax by failing to consider the larger context
when attacking problems as if they're unrelated.  In this case
SCTP is the most difficult protocol I've encountered to get across
NATs, and I'm wondering just how far we're willing to go to get
it to work.  Only changing the handling of port numbers is
not sufficient.
Melinda