Disputed[edit]

Because of what appeared in the IPX/SPX page to be an inconsistency, I have looked around a little for IPX/SPX information and found some conflicting references. It seems like what we have about NetWare protocols and their corresponding OSI layers is probably wrong. IPX does do port multiplexing itself and so is largely also a layer 4 protocol, and SPX only appears to do a subset of TCP's work, so our comparisons to TCP/IP are misleading if not significantly wrong.

See: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/netwarep.htm

I plan to do more reading but would really appreciate input from someone who knows more. --Heywood 00:48, 12 July 2006 (UTC)[reply]

I'm not sure what your problem with that is. It's the base protocol of IPX/SPX, running directly over the link layer, and as such it's the network layer. SPX runs on it just as TCP runs on IP. However, IPX doesn't need a transport layer running over it; unadorned, it sends datagram packets which can be used without the aid of an additional transport layer. So just as both articles state, it is analagous to both IP and UDP, where SPX is analagous to TCP. There really isn't a dispute here, so I'll remove the tags. Kundor 22:32, 17 September 2006 (UTC)[reply]

Advantage over TCP/IP?[edit]

is there any advantage of IPX over TCP/IP?? — Preceding unsigned comment added by Efren (talk • contribs) 08:24, 24 October 2004‎ (UTC)[reply]

No. Its only reason for existence is that, at the time it was originally developed and deployed, the correct protocol choice was still unclear. (Recall that this was the heyday of both OSI and ATM standards development, both of which at various times seemed to have legitimate claim to being "the protocol of the future".) Novell took a well-known, simple protocol suite with multiple pre-existing implementations, XNS, and modified it slightly to suit their more limited goals. In hindsight, we could wish that they had chosen the Internet protocol suite instead, but at the time it was a sensible decision -- and Novell was far from the only company to do so. 18.26.0.18 05:52, 1 Jan 2005 (UTC)
I disagree. It's reason for existence is that, at the time it was originally developed and deployed, there was no such thing as a single "correct" protocol choice. The mid to late 80s (and into the early 90s) were the age of multi-protocol networking. When did a TCP stack finally ship with Windows? Not until 1994 with WfW 3.11, and even in Win95 TCP was not a default; IPX was. Every computer and OS vendor had their own protocols; that's how the world was then. It is also incorrect to say there are "no advantages" to IPX. It is more correct to say that the advantages are not enough to outweigh the disadvantages today. IPX has a larger address space: 48 bits (or is it 64?) instead of 32 bits in IPv4. IPX addresses incorporate the local MAC address: there is no "address assignment" like with IPv4. There is no such thing as BootP or DHCP in IPX, because none is needed. One of the reasons DHCP was invented from BootP was because IPv4 couldn't do what IPX did: allow "plug-and-go" network addressing. Guess what feature was added in IPv6? Including the MAC address in the internetwork address, just like IPX. Other things declared "bad" about IPX are bad about IP also, and most of the improvements made to the TCP/IP world in the last 10 years could have been made to the IPX world also. A good example is RIP broadcasting. It has the same problems in IPv4 as in IPX. OSPF was invented to fix it in the IPv4 world, and Novell came up with a similar link-state routing protocol for IPX also. The real advantage of TCP/IP is vendor-independent open standards and interoperability, not raw technical superiority. IP may have that now, which is still debatable with some parts of IPv4, but it didn't at the time it competed with IPX. --Amillar 09:06, 2 Jan 2005 (UTC)

READING NEEDS TO BE DONE[edit]

I'm not going to try and take everyone to school so I'm going to tell you where to get the info needed on this. There is a text book called Networking Concepts written by James L. Antonakos and Kenneth C. Mansfield Jr. and, for that reason, I don't want to use their work and get Wikipedia in trouble. But I will say this: they're NOT the same and don't help each other either. IPX/SPX protocol and TCP/IP protocol are different, similar, but different. Comparing them should only be done in the sense of showing their similarities. Any further than that and you're just giving your opinion.

Sorry to upset you but people vote with their feet: note the industry stampede away from ipx and away from SNA, arcnet, NetBIOS, token ring, dlc, et al. Ergo hardware and software vendors stopped supporting it. Unfortunate because Shjacks45 (talk) 17:26, 22 February 2020 (UTC)[reply]

Unfortunate because noise resistant token passing networks are more determinate (access within given time) than IP. Important if you have dozens of machines on a factory floor all requiring time sensitive control. Shjacks45 (talk) 17:30, 22 February 2020 (UTC)[reply]

Disambiguation Needed?[edit]

It turns out there is another meaning for IPX. It's a rating system for levels of waterproofing, related to IEC 60529.

Examples are given at IPX Waterproof Specifications and IEC 60529 Ingress Protection .PeterBrooks 21:45, 18 January 2006 (UTC)[reply]

i agree. i actually got to this page looking for information on the waterproof standard. maybe we don't need a disambiguation page, but one of those one-liners. --21:53, 27 June 2006 (UTC)

Support of IPX....[edit]

It says the following systems do not support the protocol .... Does that mean that every other os supports the protocol? Needs to be cleared up. Unless it means what it says, that every other system supports IPX Maybe saying the following systems are confirmed as not supporting the protocol. IMBlackMath (talk) 08:22, 28 April 2009 (UTC)[reply]

OSI vs TCP/IP[edit]

Should the article really reference which layer in the osi model it's in when it shows a box of the tcp/ip model on the right? I don't mind which but i'd prefer to reference and show only ONE. 86.44.153.109 (talk) 04:53, 15 December 2010 (UTC)[reply]

IPX doesn't scale well?[edit]

Radia Perlman disagrees in her book "Interconnections":

9.6.2 Ugly Rumors about IPX People believe, for some reason, that IPX is "unroutable", "doesn't work on WANs" or "doesn't scale." IPX is actually a wonderful network layer protocol, better than IP in almost every way (except for little things such as having a hop count that increments rather than decrements). Why do many people believe bad things about it? The answer is that there is a germ of truth in what they are saying, but it has nothing to do with IPX. IPX is, as I said, quite wonderful: it has large addresses, it is autoconfiguring, it is simple to implement, and it requires low overhead. But unfortunately, IPX hangs out with some unsavory company, such as SPX, a protocol just like TCP but with a window size of 1;...... — Preceding unsigned comment added by 88.159.13.2 (talk) 08:38, 23 August 2012 (UTC)[reply]

We had a call center with several hundred techs per floor. We were getting network saturation issues and seemed be packet storm from ipx. FYI, the original internet protocol (tests in 1971) was network core protocol, an ipx precursor. Shjacks45 (talk) 17:15, 22 February 2020 (UTC)[reply]

This is more likely a RIP problem, because IPX stations don't do much traffic by themselves. This problem in some IPX networks arises because the routing is determined by the RIP protocol, and if these routes are regularily announced, and the logical network is heavily fragmented, the announcements can take up some of the available network bandwidth. Another factor may be SAP, which announces and responds to GNS request. For most other purposes, a RIP request isn't much more expensive than a DNS query in IP networks (because the route nodes can be cached locally at the next router). Another problem in LANs might be the lack of multi port bridges/switches, because you only have few collision domains - but theses latter problems are the same for TCP/IP networks, which were established after hubs were replaced with switches around the same time the Internet became so important that terminals and client computers switched to TCP/IP. 212.12.37.98 (talk) 12:09, 6 September 2022 (UTC)[reply]

EtherType[edit]

There are at least two EtherType]s assigned to Novel for IPX: 0x8137 and 0x8138. Anyone know which is used and when? -—Kvng 14:34, 16 January 2013 (UTC)[reply]

Thought at first that it related to the old "802.3" Novell framing vs proper 802.2 framing but it doesn't seem to be related. "802.3" isn't really indicated at all which is the main problem. EtherType 0x8137 is usually mentioned as "old" and that may be all there is to it. Zac67 (talk) 19:41, 16 January 2013 (UTC)[reply]
0x8137 shows up more frequently in searches than 0x8138 but I have not found any refs that explain why there are two EtherTypes. -—Kvng 14:44, 17 January 2013 (UTC)[reply]

Could it be BigEndian vs LittleEndian? (I too am unable to find any documentation, but I also find no reference for distinguishing the byte order) — Preceding unsigned comment added by Ntrcessor (talk • contribs) 15:11, 6 February 2015 (UTC)[reply]

As it is, EtherTypes 0x8137 & 0x8138 are assigned to Novell. Since there's no Novell doc any more, we'll probably never know for sure. However, I found this an interesting read (search Google groups for "novell.com 1993sep17"): 0x8137 indicate IPX over Ethernet_II (which probably only few people ever used) but we already have that. Designing Large Scale LANs by Kevin Dooley (2002) says "Type 8137 designates an older version of IPX that is not widely used anymore, while 8138 is the most typical for modern IPX installations." -- Zac67 (talk) 18:29, 6 February 2015 (UTC)[reply]

IPX[edit]

IPX within windows was disallowed by Microsoft Dod in any Microsoft software, due it's use to partition internal data traffic and external internet IP routing. IE: The Dod could NOT enter an internal network purely by using/upsurping domain servers and using IP.

That same for Apples protocole. — Preceding unsigned comment added by 186.88.226.115 (talk) 01:31, 24 March 2017 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Internetwork Packet Exchange. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template ((source check)) (last update: 18 January 2022).

Cheers.—InternetArchiveBot (Report bug) 15:29, 15 November 2017 (UTC)[reply]

ipx was the first internet protocol[edit]

UC Santa Barbara was involved wit the first internet tests in 1971. XNS based Network Core Protocol was used for the first few tests. Microsoft's MSN in Windows 95 requires ipx in the protocol stack to log in. MSN used unix servers. At the time AOL had Compaq unix servers, but AOL interserver communication was not IP. (Co-wrote knowledge base articles). Early Unix, e.g. Xenix, had ipx as available protocol, but not IP. Doubts? Read "Lions' Commentary on Unix" for Unix v6 source code. Shjacks45 (talk) 17:05, 22 February 2020 (UTC)[reply]

Merge with Article IPX/SPX[edit]

There is a huge overlap with the article IPX/SPX. Perhaps they should be merged and one of them should be deleted. 2001:9E8:E18A:C300:851B:34E2:7BF5:7EB1 (talk) 12:46, 6 September 2022 (UTC)[reply]

Categories