IPX was optimized for LANs. For one thing, IPX addresses are formed using an Ethernet MAC addresses and a 32-bit network ID. This design allowed for “zero configuration” of the IPX nodes in most cases – just plug computer in and it’s on the network. IPv6 with stateless autoconf has the same properties, btw.
SPX (analogue of TCP) was also highly optimized for LANs. For example, it had per-packet nacks instead of per-octet acks in TCP without any explicit window management functions. That allowed file servers to be very simple – just spew file contents into the Ethernet at the top speed. If a client misses a packet then you can re-read it from disk/cache and re-send it.
In contrast, with TCP you have to buffer all the unacknowledged data and re-send all of the data in the send buffer after a lost packet (in case you don’t use selective acknowledgment feature).
However, IPX was not suitable for the WANs at all. For example, it couldn’t cope with different frame sizes. I.e. two networks with different frames (say, Ethernet and Ethernet with jumbo frames) couldn’t interoperate without a proxy server or some form of encapsulation.
Additionally, packet reordering on WANs is ubiquitous but it plays hell with SPX (at least with Novell’s implementation) causing a lot of spurious NAKs.
And of course, IPX addresses were not hierarchical so not very suited for routing. Network ID in theory could be used for this, but even large IPX/SPX deployments were not complex enough to develop rich routing infrastructure.
Right now, IPX is interesting only as a historical curiosity and in maintenance of a small number of VERY legacy systems.
from the discussion HERE