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

From: Schruefer Wolfgang <[email-masked]>
Date: Mon, 14 Feb 2005 05:36:34 -0800 (PST)

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.

Please consider that only the DESTINATION transport addresses should be allowed 
to contain multiple port numbers. For the LOCAL address handling the design 
with a unique port remains untouched.

Multiple destination ports would affect only the addressing of outgoing packets 
to an multihomed peer behind a NAPT. 
Before the packets arrive at the peer NAPT would retranslate the addresses back 
to an unique port number. This is the reason why SCTP would not need to handle 
multiple local port numbers. 

Best regards,
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
> > 
> >

---

From: Melinda Shore <[email-masked]>
Date: Mon, 14 Feb 2005 06:05:00 -0800 (PST)

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: "Spencer Dawkins" <[email-masked]>
Date: Mon, 14 Feb 2005 21:14:53 -0800 (PST)

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.
OK, I'll bite...

I was assuming (bad assumption?) that two different IP addresses might 
very well be on two different physical interfaces, on two separate 
subnets, so a single NAPT won't be on both paths in the general case. 
So a single NATP can't diddle with with the port numbers for both IP 
addresses, right? So if you're going to use two separate interfaces 
through multiple NAPTs, you're going to have to tell your peer about 
two different ports, and that will require mods to the peer - a much 
tougher deployment scenario than just me talking to my local NATP.

My copy of RFC 2960 shows these options for the INIT chunk:

        Variable Parameters                  Status     Type Value
        -------------------------------------------------------------
        IPv4 Address (Note 1)               Optional    5
        IPv6 Address (Note 1)               Optional    6
        Cookie Preservative                 Optional    9
        Reserved for ECN Capable (Note 2)   Optional    32768 
(0x8000)
        Host Name Address (Note 3)          Optional    11
        Supported Address Types (Note 4)    Optional    12

So there's no way to tell a peer about two different ports without an 
extension, yes?

What am I not understanding?

Spencer

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 15 Feb 2005 12:03:19 -0800 (PST)

(added Randy to the cc list since he's not seeing email on behave list)

Hi, Wolfgang,

Please see my comments in-line.

Schruefer Wolfgang wrote:

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.

Please consider that only the DESTINATION transport addresses should be allowed to contain multiple port numbers. For the LOCAL address handling the design with a unique port remains untouched.

Multiple destination ports would affect only the addressing of outgoing packets to an multihomed peer behind a NAPT. 
Before the packets arrive at the peer NAPT would retranslate the addresses back to an unique port number. This is the reason why SCTP would not need to handle multiple local port numbers. 
I guess I still do not fully understand what you are proposing. Let's see the following 
example - an INIT/INIT-ACK exchange through a NAPT. Which one would be the DESTINATION 
transport address that you would like to see with multiple port numbers?

  End A                       NAPT                        End B
{IP-A, IP-B/p1}                ##                      {IP-X, IP-Y/p3}
INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3)
    (dst: IP-X/p3)                  (dst:IP-X/p3)
(p1)<---INIT_ACK(src:IP-X,IP-Y/p3) ##<------INIT_ACK(src:IP-X,IP-Y/p3)
                (dst: IP-A/p1)                      (dst:IP-M/p2)
regards,
-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Tue, 15 Feb 2005 12:27:01 -0800 (PST)

Q:

Ok, I give up... I will subscribe to behave kicking and screaming
to try to avoid one more mailing list :-D
Comments below..

Qiaobing Xie wrote:

Hi, Wolfgang,

Qiaobing,

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.

Please consider that only the DESTINATION transport addresses should 
be allowed to contain multiple port numbers. For the LOCAL address 
handling the design with a unique port remains untouched.

Multiple destination ports would affect only the addressing of 
outgoing packets to an multihomed peer behind a NAPT. Before the 
packets arrive at the peer NAPT would retranslate the addresses back 
to an unique port number. This is the reason why SCTP would not need 
to handle multiple local port numbers. 

I too, like Q, am a bit confused.. and I have probably missed
some of the discussion.. yes.. I know I should go back and
read the archive.. but alas .. I have not the cycles..
What Wolfgang could be advocating is something more like:

host-a          NATP                              host-z

----IP-a --INIT--->
----IP-b
    (src-port:1)
                IP-A:src-P2
                IP-B:src-P3 ------->
But unless you had yet another NATP at the other side then host-z's
SCTP stack would need to be aware of the multiple ports... which
would be confusing and more complex..

I guess I still do not fully understand what you are proposing. Let's 
see the following example - an INIT/INIT-ACK exchange through a NAPT. 
Which one would be the DESTINATION transport address that you would like 
to see with multiple port numbers?

  End A                       NAPT                        End B
{IP-A, IP-B/p1}                ##                      {IP-X, IP-Y/p3}
INIT(src:IP-A,IP-B/p1)------>## INIT(src:IP-M,IP-N/p2)------->(p3)
    (dst: IP-X/p3)                  (dst:IP-X/p3)
(p1)<---INIT_ACK(src:IP-X,IP-Y/p3) ##<------INIT_ACK(src:IP-X,IP-Y/p3)
                (dst: IP-A/p1)                      (dst:IP-M/p2)
The above looks to me like what a regular NAPT does.. i.e. End-A gets
p1 and yet End B sees p2... this is no problem without changing
the protocol... only if multiple addresses are involved is
there an issue I think... and this may be what Wolfgang is trying
to solve..
Wolfgangs.. clearfications for Q and I would be most welcome .

R

regards,
-Qiaobing

--
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222