Re: (no subject)

Hi Jan,

see my comments in-line.

Best regards
Michael

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

> 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.
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.
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/sigtran