Subject: [Sigtran] (no subject)

From: "Jan Scheurich \(AC/EDD\)" <[email-masked]>
Date: Thu, 29 Mar 2007 12:00:58 +0200

Hi,

Rfc 2960 explicitly foresees the possibility to respond to an INIT
packet with an INIT ACK from a source IP address that differs from the
destination address of the INIT packet. Motivation being to support
establishment of MH associations in hosts where the SCTP user cannot
fully control the source IP address.

Apparently this has been the subject of some debates a couple of years
ago and I wonder what the status is in todays SCTP implementations. Do
clients support that kind of server behaviour?

I would like to go one step further and ask if the following scenario is
legal from SCTP perspective and would be supported by common client
implementations:

                                +--------+
                            +---|Server 1|
+------+         +------+   |   +--------+
|Client|---------|Router|---|      ...
+------+         +------+   |   +--------+
                            +---|Server N|
                                +--------+

The SCTP server is a cluster with N (single-homed) servers having
individual public IP addresses. The SCTP client is provisioned with a
virtual cluster IP address and server port number only. The cluster
router performs load sharing of incoming SCTP INIT packets destined to
the virtual cluster IP address among the servers. 

The selected server would reply with INIT ACK without including any
explicit IP addresses. The source IP address would be the server's
individual IP address rather than the cluster IP address. The client
would establish the SCTP association between its own SCTP EP and the
remote EP on the selected server, disregarding the originally
provisioned cluster IP address.

If this scenario is not legal, what would be the alternative? Would the
cluster router have to do SCTP NAT based on remote IP address/port
number? Would that work in redundant configurations (i.e. with
replicated routers)?

Any feedback is welcome.

Regards, Jan
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 Mar 2007 12:25:50 +0200

Hi Jan,

see my comments in-line.

Best regards
Michael

On Mar 29, 2007, at 12:00 PM, Jan Scheurich (AC/EDD) wrote:

> packet with an INIT ACK from a source IP address that differs from  
> the destination address of the INIT packet. Motivation being to  
> support establishment of MH associations in hosts where the SCTP  
> user cannot fully control the source IP address.
>
> Apparently this has been the subject of some debates a couple of  
> years ago and I wonder what the status is in todays SCTP  
> implementations. Do clients support that kind of server behaviour?
>
> I would like to go one step further and ask if the following  
> scenario is legal from SCTP perspective and would be supported by  
> common client implementations:
>
>                                 +--------+
>                             +---|Server 1|
> individual public IP addresses. The SCTP client is provisioned with  
> a virtual cluster IP address and server port number only. The  
> cluster router performs load sharing of incoming SCTP INIT packets  
> destined to the virtual cluster IP address among the servers.
So the client sends the INIT to A_R (router address). The INIT-ACK  
comes from A_j (where A_j is
the address of Server j). Does the Server list A_R in the INIT-ACK?
If not, the client should discard the INIT-ACK.
If yes, the client should build the association and uses both  
addresses (A_R and A_j)
to reach the Server.

To get what you want you could use ADD-IP to remove A_R from the  
association after setting
it up or use something I call INIT-FORWARDING, where the router  
forwards the INIT to Server_j,
which responds from his address and puts a new parameter in the INIT- 
ACK which says, that
the INIT was sent to address A_R, but this should not be used anymore.

This is written up, but not yet submitted to the IETF as an Internet  
Draft. Basically it
gives you support for anycast like services.

BTW: The list to discuss SCTP questions is now tsvwg, that is why I'm  
CCing it.
> individual IP address rather than the cluster IP address. The  
> client would establish the SCTP association between its own SCTP EP  
> and the remote EP on the selected server, disregarding the  
> originally provisioned cluster IP address.
>
> If this scenario is not legal, what would be the alternative? Would  
> the cluster router have to do SCTP NAT based on remote IP address/ 
> port number? Would that work in redundant configurations (i.e. with  
> replicated routers)?
>
> Any feedback is welcome.
>
> Regards, Jan
>