(no subject)
"Jan Scheurich \(AC/EDD\)" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <425A3BC99494A4409BEF99524478ED5201F342E3@esealmw103.eemea.ericsson.se> |
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 protected]
https://www1.ietf.org/mailman/listinfo/sigtran