Hubbry Logo
Internetwork Packet ExchangeInternetwork Packet ExchangeMain
Open search
Internetwork Packet Exchange
Community hub
Internetwork Packet Exchange
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Internetwork Packet Exchange
Internetwork Packet Exchange
Internetwork Packet Exchange
View on Wikipedia
from Wikipedia

Internetwork Packet Exchange (IPX) is the network-layer protocol in the IPX/SPX protocol suite. IPX is derived from Xerox Network Systems' IDP. It also has the ability to act as a transport layer protocol.

The IPX/SPX protocol suite was very popular through the late 1980s and mid-1990s because it was used by Novell NetWare, a network operating system. Due to Novell NetWare's popularity, IPX became a prominent protocol for internetworking.

A big advantage of IPX was a small memory footprint of the IPX driver, which was vital for DOS and Windows up to Windows 95 due to the limited size at that time of conventional memory. Another IPX advantage was easy configuration of its client computers. However, IPX does not scale well for large networks such as the Internet.[1] As such, IPX usage decreased as the boom of the Internet made TCP/IP nearly universal.

Computers and networks can run multiple network protocols, so almost all IPX sites also ran TCP/IP, to allow Internet connectivity.[2] It was also possible to run later Novell products without IPX, with the beginning of full support for both IPX and TCP/IP by NetWare version 5[3] in late 1998.

Description

[edit]

A big advantage of IPX protocol is its little or no need for configuration. In the time when protocols for dynamic host configuration did not exist and the BOOTP protocol for centralized assigning of addresses was not common, the IPX network could be configured almost automatically. A client computer uses the MAC address of its network card as the node address and learns what it needs to know about the network topology from the servers or routers – routes are propagated by Routing Information Protocol, services by Service Advertising Protocol.

A small IPX network administrator had to care only

  • to assign all servers in the same network the same network number,
  • to assign different network numbers to different frame formats in the same network,
  • to assign different network numbers to different interfaces of servers with multiple network cards (Novell NetWare server with multiple network cards worked automatically as a router),
  • to assign different network numbers to servers in different interconnected networks,
  • to start router process on nodes with multiple network cards in more complex networks.

IPX packet structure

[edit]

Each IPX packet begins with a header with the following structure:

Octets Field
2 Checksum (always 0xFFFF – no checksum)
2 Packet Length (including the IPX header)
1 Transport Control (hop count)
1 Packet Type
12 Destination address
12 Source address

The Packet Type values are:

Value Meaning/Protocol
0 Unknown
1 RIP (Routing Information Protocol) (RFC 1582, RFC 2091)
2 Echo Packet
3 Error Packet
4 PEP (Packet Exchange Protocol), used for SAP (Service Advertising Protocol)
5 SPX (Sequenced Packet Exchange)
17 NCP (NetWare Core Protocol)
20 Broadcast[4]

IPX addressing

[edit]

An IPX address has the following structure:

Octets Field
4 Network number
6 Node number
2 Socket number

Network number

[edit]

The network number allows to address (and communicate with) the IPX nodes which do not belong to the same network or cabling system. The cabling system is a network in which a data link layer protocol can be used for communication. To allow communication between different networks, they must be connected with IPX routers. A set of interconnected networks is called an internetwork. Any Novell NetWare server may serve as an IPX router. Novell also supplied stand-alone routers. Other vendors ' multiprotocol routers often support IPX routing. Using different frame formats in one cabling system is possible, but it works similarly as if separate cabling systems were used (i.e. different network numbers must be used for different frame formats even in the same cabling system and a router must be used to allow communication between nodes using different frame formats in the same cabling system).

  • Logical networks are assigned a unique 32-bit address in the range 0x1 to 0xFFFFFFFE (hexadecimal).
  • Hosts have a 48-bit node address, which is by default set to the 6 bytes of the network interface card MAC address. Network addresses, which exist in addition to the node address but are not part of the MAC layer, are assigned only if an IPX router is present or by manual configuration in the network. The network address covers every network participant that can talk to another participant without the aid of an IPX router. In combination, both network and node address form an 80-bit unique identifier for each IPX node across connected logical networks. The node number itself is unique to the logical network only.
  • Network number 00:00:00:00 refers to the current network, and is also used during router discovery. It's also the default in case no router is present, but can be changed by manual configuration, depending on the IPX implementation.
  • Broadcast network number is FF:FF:FF:FF.

Node number

[edit]

The node number is used to address an individual computer (or more exactly, a network interface) in the network. Client stations use its network interface card MAC address as the node number.

The value FF:FF:FF:FF:FF:FF may be used as a node number in a destination address to broadcast a packet to "all nodes in the current network".

Socket number

[edit]

The socket number serves to select a process or application in the destination node. The presence of a socket number in the IPX address allows the IPX to act as a transport layer protocol, comparable with the User Datagram Protocol (UDP) in the Internet protocol suite.

Socket number Protocol
0x0001–0x0BB8 Registered by Xerox
0x0001 Routing Information Packet
0x0002 Echo Protocol Packet
0x0003 Error Handling Packet
0x0020–0x003F Experimental
0x0BB9–0xFFFF Dynamically Assigned
0x0451 NetWare Core Protocol (NCP – used by Novell NetWare servers)
0x0452 Service Advertising Protocol (SAP)
0x0453 Routing Information Protocol (RIP)
0x0455 NetBIOS
0x0456 Diagnostic Packet
0x0457 Serialization Packet (used for NCP as well)
0x4000–0x4FFF Dynamically Assigned Socket Numbers
0x4003 Used by Novell NetWare Client
0x8000–0xFFFF Statically Assigned Socket Numbers
0x8060 LLC[4]
0x9091 TCP over IPXF
0x9092 UDP over IPXF
0x9093 IPXF, IPX Fragmentation Protocol

Comparison with IP

[edit]

The IPX network number is conceptually identical to the network part of the IP address (the parts with netmask bits set to 1); the node number has the same meaning as the bits of IP address with netmask bits set to 0. The difference is that the boundary between network and node part of address in IP is variable, while in IPX it is fixed. As the node address is usually identical to the MAC address of the network adapter, the Address Resolution Protocol is not needed in IPX.

For routing, the entries in the IPX routing table are similar to IP routing tables; routing is done by network address, and for each network address a network:node of the next router is specified in a similar fashion an IP address/netmask is specified in IP routing tables.

There are three routing protocols available for IPX networks. In early IPX networks, a version of Routing Information Protocol (RIP) was the only available protocol to exchange routing information. Unlike RIP for IP, it uses delay time as the main metric, retaining the hop count as a secondary metric. Since NetWare 3, the NetWare Link Services Protocol (NLSP) based on IS-IS is available, which is more suitable for larger networks. Cisco routers implement an IPX version of EIGRP protocol as well.[5]

Frame formats

[edit]

IPX can be transmitted over Ethernet using one of the following 4 frame formats or encapsulation types:

  • 802.3 (raw) encapsulation comprises an IEEE 802.3 frame header (destination MAC, source MAC, length) immediately followed by IPX data. It is used in legacy systems, and can be distinguished by the first two bytes of the IPX header always containing a value of 0xFFFF, which cannot be interpreted as valid LLC Destination and Source Service Access Points in this location of the frame.
  • 802.2 (LLC or Novell) comprises an IEEE 802.3 frame header (destination MAC, source MAC, length) followed by an LLC header (DSAP 0xE0, SSAP 0xE0, control 0x03) followed by IPX data. The 0xE0 fields of the LLC header indicate "NetWare".
  • 802.2 (SNAP) comprises an IEEE 802.3 frame header, an LLC header (DSAP 0xAA, SSAP 0xAA, control 0x03), a SNAP header (OUI 0x000000, type 0x8137), and IPX data. The 0xAA fields of the LLC header indicate "SNAP", and the OUI 0x000000 in the SNAP header indicates an encapsulated EtherType.
  • Ethernet II encapsulation comprises an Ethernet II frame header (destination MAC, source MAC, EtherType 0x8137) followed by IPX data.

In non-Ethernet networks, only 802.2 and SNAP frame types are available.

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Internetwork Packet Exchange

View on Grokipedia
from Grokipedia
Internetwork Packet Exchange (IPX) is a connectionless protocol operating at the network layer of the , developed by , Inc., for and addressing packets across interconnected local area networks (LANs) and wide area networks (WANs) in environments. It forms the core of the IPX/SPX protocol suite, where IPX handles datagram delivery without establishing connections, while the companion Sequenced Packet Exchange (SPX) protocol provides reliable, sequenced transport services similar to TCP. IPX uses a 12-byte addressing scheme consisting of a 4-byte network number, a 6-byte node address (typically the ), and a 2-byte socket number to identify endpoints, enabling efficient packet in hierarchical networks. IPX originated in the early 1980s when Novell adapted the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP), developed by Xerox in the late 1970s as part of an open networking standard for office environments. Novell enhanced IDP by renaming it IPX and modifying its metrics—replacing XNS's hop-count routing with a delay-based system measured in ticks (1/18th of a second)—to better suit file and print serving in NetWare, Novell's dominant network operating system released in 1983. IPX retained the XNS capability for packet sizes up to 65,535 bytes and integrated with NetWare's service-oriented architecture, where protocols like Routing Information Protocol (RIP) and Service Advertising Protocol (SAP) broadcast network topology and available services every 60 seconds. In operation, IPX packets feature a 30-byte header including fields for , packet length, transport control, packet type, and the source and destination addresses, followed by up to bytes of (though routed packets were historically limited to 576 bytes). Routing decisions rely on RIP for basic path selection (limited to 15 hops) or the more advanced NetWare Link Services Protocol (NLSP), a link-state protocol introduced in NetWare 4.0 that supports up to 127 hops, faster convergence, and features like load balancing across up to eight equal-cost paths. For WAN extensions, IPX employs the IPXWAN protocol to encapsulate packets over media like X.25 or , using initial information exchange packets to negotiate parameters such as header compression and timers before standard routing begins. This design prioritized simplicity and low overhead, making IPX ideal for the client-server model prevalent in enterprise LANs during its peak. IPX saw widespread adoption in the late 1980s and 1990s, powering a dominant share of over 70% of corporate networks through 's market leadership in file and print services, with millions of installations worldwide. Its integration with enabled seamless resource sharing without the complexity of TCP/IP at the time, and vendors like provided robust support for IPX routing, including Enhanced IGRP for scalable environments. However, the protocol's nature and lack of native compatibility contributed to its decline starting in the mid-1990s, as TCP/IP became the standard with the World Wide Web's rise; by the early 2000s, shifted to TCP/IP support, and discontinued IPX routing in IOS releases around 2011. Today, IPX persists in legacy systems and niche applications like gaming or industrial controls, but its influence endures in the evolution of modern networking protocols.

Overview

Description

Internetwork Packet Exchange (IPX) is a connectionless protocol that forms the core of the IPX/SPX protocol suite, primarily designed for packets across interconnected area networks (LANs). Developed by , IPX was adapted from the ' (XNS) Protocol (IDP), retaining a similar structure while introducing modifications such as Ethernet encapsulation and the use of ticks as a metric. As a network-layer protocol, it operates without establishing connections between nodes, enabling efficient transmission of individual packets in environments like . The core function of IPX involves delivering datagrams between nodes with minimal configuration requirements, leveraging the host's for the 48-bit node identification within its 80-bit addressing scheme (combining a 32-bit network number and the node part). This automatic node addressing eliminates the need for protocols like ARP, simplifying deployment in LANs, while dynamic routing is supported via protocols such as (RIP). IPX packets include a compact 30-byte header, contributing to its low overhead and suitability for resource-constrained systems. IPX gained significant popularity from the late through the mid-1990s, powering a majority of enterprise networks through its integration with , which dominated networked /DOS-based environments with 60 to 70 percent market share before the widespread adoption of TCP/IP. Its advantages included a low due to the small header size, automatic node addressing for plug-and-play operation, and ease of setup in segmented networks, making it ideal for early client-server architectures without extensive manual addressing.

Key Features

Internetwork Packet Exchange (IPX) provides a connectionless service at the network layer, analogous to that of the (IP), wherein packets are transmitted without establishing a connection, offering no guarantees for delivery, ordering, or error correction. This design choice prioritizes efficiency in (LAN) environments by minimizing overhead, allowing for rapid without session management. The IPX header is fixed at 30 octets, contributing to its simplicity and performance compared to protocols like IP, which feature variable-length headers due to optional fields. Key header fields include a 2-octet , which is always set to 0xFFFF to disable verification for simplicity; a 2-octet packet length indicating the total size including the header; a 1-octet transport control field serving as a hop count to prevent loops; and a 1-octet packet type field specifying the protocol, such as 0x05 for Sequenced Packet Exchange (SPX) or other values for and error packets. For applications requiring reliability, IPX relies on higher-layer protocols like SPX, which adds sequencing, acknowledgments, and retransmission atop the base service. Addressing in IPX eliminates the need for an (ARP) equivalent, as node addresses are directly derived from the 6-octet MAC addresses of network interfaces, simplifying resolution on shared media. The protocol further supports broadcast transmission to all nodes on a network (using the all-ones MAC address 0xFFFFFFFFFFFF) and for targeted service announcements, enhancing discovery in dynamic LAN topologies without additional infrastructure.

Historical Development

Origins and Influences

The Internetwork Packet Exchange (IPX) protocol originated from the (XNS) architecture developed in the late 1970s by Corporation's Palo Alto Research Center (PARC). XNS was designed as an for local area networks (LANs), building on earlier work like the PARC Universal Packet (PUP) internetwork architecture from the mid-1970s. A core component of XNS was the Internet Datagram Protocol (IDP), a connectionless network-layer protocol specified in Xerox documentation from November 1979, which provided unreliable delivery across heterogeneous networks using a 32-bit and 48-bit host address scheme. In the early , Novell's engineering team adapted IDP as the foundation for IPX to support their emerging network operating system. This adaptation retained IDP's core structure and addressing concepts, enabling efficient and of diverse LAN technologies like Ethernet and without the complexity of emerging standards like TCP/IP. Minor modifications were made, such as changes to the and packet length fields, but IPX remained largely identical to IDP in functionality. The primary motivation for developing IPX was to provide a simple, routable protocol for file and print sharing services in environments during the pre-TCP/IP era of the , when proprietary LANs required straightforward for resource access across multiple sites. By leveraging XNS's proven model, addressed the need for low-overhead communication in client-server networking, facilitating rapid deployment in business settings without relying on connection-oriented overhead. This design choice positioned IPX as a practical alternative for early enterprise networks, emphasizing ease of integration over advanced reliability features.

Adoption in Novell NetWare

IPX was integrated into from its initial release in 1983 with , establishing it as the core network protocol for client-server communications in local area networks. This early adoption leveraged IPX for efficient file and print sharing, enabling seamless connectivity across PC-based networks without the overhead of more complex protocols, supporting and basic bindery services for user authentication and resource management. NetWare 2.0, released in 1986, further enhanced IPX implementation on dedicated file servers. Subsequent enhancements in the NetWare 3.x series, spanning 1989 to 1993, improved IPX's routing capabilities to accommodate larger, segmented networks. NetWare 3.0, released in September 1989, introduced better handling of IPX traffic through enhanced internal mechanisms, while versions like 3.11 and 3.12 further optimized performance for multi-server environments using protocols such as IPX for segmentation. The pinnacle of IPX's role came with NetWare 4.0 in April 1993, which introduced Novell Directory Services (NDS) as a hierarchical directory over IPX, facilitating centralized management of users, printers, and files across wide-area networks. This integration solidified IPX as the backbone for NDS queries and authentication, with service discovery via enabling clients to locate servers dynamically. By the mid-1990s, IPX with dominated enterprise networking, capturing nearly 70% of the network operating system market and powering installations that served millions of users for file and print services. Its compatibility with prevalent data link technologies like Ethernet and , combined with lower implementation costs relative to emerging TCP/IP infrastructures, drove widespread enterprise adoption. These factors made IPX/ a cost-effective choice for organizations building scalable LANs, often outperforming alternatives in speed and simplicity for internal communications. The trajectory shifted with 5.0 in October 1998, which introduced comprehensive native TCP/IP support alongside IPX, allowing servers to operate exclusively on TCP/IP and signaling a move away from IPX's exclusivity in Novell's ecosystem. This addition enabled hybrid environments, reflecting broader industry convergence on internet standards while maintaining for legacy IPX-based applications.

Protocol Architecture

Packet Structure

The Internetwork Packet Exchange (IPX) packet format comprises a fixed 30-octet header followed by a variable-length payload, enabling efficient and delivery across networks. The header encapsulates essential control information, addressing details, and type indicators, while the payload carries upper-layer protocol such as that from Sequenced Packet Exchange (SPX) or Core Protocol (NCP). The IPX packet format supports a theoretical maximum total size of 65,535 octets via the 16-bit packet length field. The standard (MTU) is 576 octets (30-byte header + 546 bytes of ) for interoperability across routed networks, but on Ethernet LANs, packets can reach up to 1,500 octets to match the frame capacity. The header fields are laid out in the following byte order, with big-endian (network byte order) for multi-octet values:
BytesFieldPurpose
0-1Checksum2 octets; provides packet integrity verification. Typically set to 0xFFFF to disable checksum (common in early implementations), but when enabled, it is the one's complement of the sum of all 16-bit words in the packet, similar to XNS IDP. Often bypassed in favor of transport-layer checks like those in SPX.
2-3Packet Length2 octets; specifies the total length of the packet in octets, including the header and payload (minimum 30 octets).
4Transport Control1 octet; acts as a time-to-live (TTL)-like hop count, initialized to 0 by the sender and incremented by each router (typically discarded after 16 hops).
5Packet Type1 octet; identifies the upper-layer protocol or packet purpose (e.g., 0x01 for RIP, 0x04 for SAP, 0x05 for SPX, 0x11 for NCP, 0x14 for NetBIOS).
6-17Destination Address12 octets; comprises a 4-octet network number, 6-octet node address, and 2-octet socket identifier for the target.
18-29Source Address12 octets; structured identically to the destination address, indicating the sender's network, node, and socket.
Following the header, the data payload varies in length based on the application, accommodating protocols like NCP requests or SPX segments while adhering to the overall packet size limits. In Ethernet environments, the IPX header typically follows (LLC) or Subnetwork Access Protocol (SNAP) encapsulation for compatibility.

Addressing Scheme

The Internetwork Packet Exchange (IPX) addressing scheme employs a 12-byte (96-bit) composed of three distinct components: a 32-bit network number, a 48-bit node number, and a 16-bit socket number. The network number identifies the specific logical network segment, enabling across the internetwork; valid values range from 0x00000001 to 0xFFFFFFFE for routable networks, while 0x00000000 designates local or non-routed (internal) networks that do not propagate beyond the local segment. Network numbers are manually configured by administrators on routers and servers during network setup, ensuring uniqueness across the entire IPX internetwork to prevent routing conflicts. For internal virtual networks, such as those within a server or on unnumbered WAN links, the value 0x00000000 is used, confining traffic to the local device or link without requiring external routing. The node number, typically derived from the device's 48-bit (e.g., an Ethernet hardware address like 00:11:22:33:44:55), ensures host identification within a single . This direct mapping provides uniqueness on local area networks (LANs) where MAC addresses are inherently unique, but global uniqueness requires the accompanying network number prefix, as node numbers alone do not span multiple segments. Sockets serve to demultiplex incoming IPX packets to specific applications or processes on the destination node, functioning analogously to transport-layer ports but without dedicated protocols for dynamic allocation. Well-known sockets are statically assigned for core services, such as 0x0451 for NetWare Core Protocol (NCP) communications, while dynamic sockets in the range 0x4000 to 0x7FFF are assigned by the local IPX stack for temporary use by client applications. Address resolution in IPX bypasses the need for a separate protocol like ARP, as the node number directly corresponds to the underlying , allowing immediate frame construction and delivery on local segments without additional mapping queries. For inter-network communication, routers use the network number to forward packets, embedding the full in IPX headers to guide delivery.

Network Operations

Routing Protocols

The primary routing protocol for Internetwork Packet Exchange (IPX) networks is IPX , a distance-vector protocol that exchanges routing information using hop count as its sole metric, without considering bandwidth or other link characteristics. Routers running IPX broadcast update packets every 60 seconds to advertise known network numbers and their associated hop counts, enabling path determination based on the lowest hop value. These updates use IPX packet type 0x01 for both requests and responses, where each entry includes a 4-byte network number and an 8-bit hop count field, allowing up to 50 routes per packet to minimize overhead. IPX RIP imposes a maximum hop count of 15, with 16 designated as unreachable (infinity), which limits its effective use to small- to medium-sized networks and prevents loops by discarding packets exceeding this threshold. The protocol's reliance on periodic broadcasts introduces challenges in large networks, as frequent updates generate significant overhead, particularly on wide-area links, leading to congestion and slow convergence during changes. To address IPX RIP's limitations, introduced the Link Services Protocol (NLSP) in 1994 as a Loadable Module (NLM) for 3.11 and later, a link-state protocol designed for larger IPX internetworks. NLSP builds on the ISO framework, flooding link-state advertisements to compute shortest paths using a composite metric that includes delay, throughput, and hop count, while supporting configurable hop limits from 8 to 127 for greater flexibility. NLSP also provides service location capabilities, supplanting SAP's periodic broadcasts with targeted link-state advertisements for improved efficiency. This enables faster convergence and reduced broadcast traffic compared to IPX RIP, making it suitable for enterprise-scale deployments. Cisco provided an alternative through Enhanced Interior Gateway Routing Protocol (EIGRP) support for IPX, introduced as a hybrid protocol that enhances distance-vector efficiency with partial updates and the Diffusing Update Algorithm (DUAL) for loop prevention. EIGRP for IPX uses a composite metric incorporating bandwidth, delay, reliability, load, and hop count (capped at 255), allowing automatic redistribution with IPX routes while minimizing update frequency to only changed information.

Service Discovery

In IPX networks, the primary mechanism for advertising and locating services such as file servers and printers is the , which enables servers to periodically broadcast their availability and details to clients across the network. Servers transmit SAP packets every 60 seconds by default, containing information about their services, allowing clients and routers to maintain a database of available resources. This broadcast-based approach facilitates dynamic discovery without requiring prior configuration of service locations. SAP packets include key fields such as the service type (2 octets, for example, 0x0004 indicating a ), a 48-byte server name, and the full IPX address comprising the 4-byte network number, 6-byte node address, and 2-byte socket number. These packets are sent to IPX socket 0x0452. For queries, clients can issue a Get Nearest Server request ( type 17), which is broadcast to solicit responses from the closest available server, determined by the lowest hop count metric. The responding server includes its service details and distance in the reply, enabling the client to connect to the nearest resource. In large IPX networks, the frequent SAP broadcasts can generate significant overhead, flooding routers with traffic and consuming bandwidth, particularly over wide-area links. To mitigate this, later implementations introduced SAP filters on routers, which selectively propagate or block advertisements based on service types or networks, reducing unnecessary propagation while preserving essential discovery functions. Prior to the introduction of Directory Services (NDS), SAP integrated with the NetWare bindery to allow clients to locate and access resources like file and print servers without a centralized directory.

Frame Formats

Internetwork Packet Exchange (IPX) packets are encapsulated within various frame formats to support transmission over different , with Ethernet being the most common. These formats allow IPX to coexist with other protocols on shared networks by using specific identifiers in the frame headers. The supported formats include Ethernet II, raw, with LLC, and SNAP for Ethernet interfaces, each preceding the IPX packet structure in the payload field. In the Ethernet II format, IPX uses the field set to 0x8137 to identify the protocol, distinguishing it from other network protocols like IP. This format follows the original Ethernet specification and supports a payload of 46 to 1500 octets, accommodating the IPX header and data while adhering to the standard minimum and maximum frame sizes (including padding if necessary). It is particularly useful in environments requiring compatibility with Ethernet standards. The raw format, often referred to as Novell's proprietary encapsulation, omits an explicit protocol type field and instead relies on the length field in the 802.3 header followed directly by the IPX header, where the IPX field is set to 0xFFFF to signal an IPX packet. This was the default for early versions, such as NetWare 3.11, and supports the same 46 to 1500 octet payload range, though it lacks formal IEEE standardization for protocol identification. For with LLC, an 802.3 MAC header is extended with an 802.2 (LLC) header where both the Destination (DSAP) and Source (SSAP) are set to 0xE0 to denote IPX, without requiring a Subnetwork Access Protocol (SNAP) extension. This format became the default in later releases, like NetWare 4.0, and maintains the 46 to 1500 octet payload capacity while providing standardized LLC-based identification. The IEEE 802.2 SNAP format combines an 802.3 MAC header with an 802.2 LLC header (DSAP and SSAP both 0xAA, control field 0x03) followed by a SNAP header featuring an Organizational Unit Identifier (OUI) of 0x000000 and a protocol identifier of 0x8137 for IPX. This enables multiprotocol support on IEEE 802 networks and uses the standard Ethernet payload size of 46 to 1500 octets. It is commonly employed for interoperability with other protocols. On non-Ethernet media, IPX adapts similarly using standards. For (.5), it employs the 802.2 LLC header with SNAP encapsulation (DSAP/SSAP 0xAA, OUI 0x000000, protocol ID 0x8137) to carry IPX packets. (FDDI) follows a comparable approach, integrating IPX via 802.2 SNAP over its MAC layer for consistent protocol identification across ring topologies.

Encapsulation Methods

Internetwork Packet Exchange (IPX) employs media-specific encapsulation methods to transmit packets over diverse physical layers, ensuring compatibility while optimizing for performance and (MTU) constraints. Over Ethernet, the preferred method is raw 802.3 encapsulation, which directly follows the Ethernet MAC header with the IPX packet, bypassing the (LLC) header to eliminate overhead and enhance efficiency. This approach supports an IPX payload of up to 1500 octets, the standard Ethernet MTU; for WAN links, the MTU is often limited to 576 octets to ensure compatibility without fragmentation. For Token Ring networks, IPX encapsulation integrates with the IEEE 802.5 MAC layer, appending either LLC Type 2 or Subnetwork Access Protocol (SNAP) headers to the IPX packet. within the Token Ring frame enables bridging across multiple rings, supporting paths of up to 13 intermediate bridges. This configuration leverages 's larger frame capacity, accommodating IPX packets up to 4464 octets, which facilitates higher-throughput transfers in environments with extended topologies. Similarly, adaptations for (FDDI) and Token Ring (802.5) utilize SNAP encapsulation following the respective MAC headers, with the SNAP header identifying the IPX protocol ( 0x8137). FDDI's inherent support for larger frames allows IPX packets to reach MTUs of up to 4352 octets, making it suitable for high-speed backbone connections. In (WAN) scenarios, IPX extends encapsulation over protocols like (PPP) and to maintain connectivity across asynchronous and switched links. For PPP, as specified in RFC 1552, IPX datagrams are embedded directly in the PPP Information field using protocol identifier 0x002B, with a minimum supported size of 576 octets to avoid fragmentation issues. Network numbers are propagated during link establishment via the IPX Control Protocol (IPXCP) or the IPXWAN protocol, which negotiates parameters like compression and node addressing. Over , IPX adheres to RFC 1490 encapsulation within frames, initiating IPXWAN exchanges on active permanent virtual circuits () to assign and share network numbers dynamically, ensuring seamless propagation without media-dependent alterations. Regardless of the encapsulation method, the IPX header's Transport Control field—initially set to 0 by the source—is incremented by 1 at each router hop to count traversals, with packets discarded upon reaching 16 (under RIP) to prevent indefinite looping; this hop-tracking mechanism operates uniformly across all media types.

Comparisons and Evolution

Relation to IP

Internetwork Packet Exchange (IPX) and the (IP) share fundamental similarities as connectionless, datagram-based protocols designed for routing packets across internetworks. Both operate without establishing connections prior to data transmission, relying instead on where higher-layer protocols handle reliability if needed. In terms of addressing, IPX's 32-bit network number functions analogously to the network or portion of an , identifying the logical , while the 48-bit node address corresponds to the host identifier, often derived from the device's , similar to how IP uses host portions within subnets. Despite these parallels, IPX and IP diverge significantly in design and capabilities. IPX employs a fixed 30-byte header, which includes fields for , packet length, transport control, packet type, and source/destination addresses, contrasting with IP's variable header length of 20 to 60 bytes that accommodates options like timestamps or parameters. Unlike IP, which supports fragmentation and reassembly at the network layer to handle varying path MTUs, IPX lacks built-in fragmentation; any necessary segmentation is managed by the protocol SPX, potentially simplifying implementation but limiting adaptability to diverse network conditions. in IPX primarily relies on the hop-limited (), which broadcasts updates every 60 seconds and caps networks at 15 hops, whereas IP supports a broader array of protocols such as OSPF for link-state routing or BGP for inter-domain , enabling more efficient convergence in large topologies. Additionally, IPX addressing is non-hierarchical and flat, without support for masks, (), or (), unlike the hierarchical structure of IPv4 (32-bit) and (128-bit) addresses that facilitates aggregation and address conservation. Migration from IPX to IP was facilitated by tools integrated into versions 4 and later, including IPX-to-IP gateways that allowed IPX-only clients to access IP-based services like the without immediate protocol replacement. In 5 and beyond, IP Compatibility Mode enabled seamless encapsulation of IPX traffic within IP packets, supporting legacy applications via on-demand translation of protocols like SAP, RIP, and NCP, while permitting dual-stack operation over PPP links through the IPX Control Protocol (IPXCP). These mechanisms ensured backward compatibility during transitions, such as synchronizing directory services across mixed environments. IPX's broadcast-heavy operations, including frequent RIP and SAP advertisements, made it well-suited for small local area networks (LANs) but less scalable for wide area networks (WANs) or the global , where IP's hierarchical and reduced broadcast overhead better accommodate expansive, interconnected topologies.

Decline and Legacy Usage

The decline of Internetwork Packet Exchange (IPX) began in the mid-1990s amid the rapid standardization of TCP/IP during the boom, as IPX's nature limited its with emerging wide-area networks. Novell's 5 release in 1998 introduced IP Compatibility Mode to facilitate migration from IPX/SPX to TCP/IP, marking a strategic shift as the company recognized TCP/IP's dominance for connectivity. This transition accelerated around the late 1990s. Unlike TCP/IP, which evolved with for enhanced address space and extensibility, IPX remained constrained by its fixed 32-bit addressing, contributing to its obsolescence in scalable networks. Novell discontinued IPX support in its (OES) platform starting in the mid-2000s, with no plans to port the protocol to Linux-based OES releases, effectively ending native integration in modern products. , which acquired , ended extended support for v6.5—and thus official IPX support—on December 31, 2016. Similarly, announced the discontinuation of IPX routing support in future releases due to diminishing demand, with the protocol removed from Release 3S in , following earlier deprecations in IOS 12.x versions around 2008. As of , IPX persists in niche legacy applications through emulation on virtualized environments for maintaining access to older systems. Hobbyist networks occasionally employ IPX-over-IP tunneling techniques, such as encapsulating IPX packets in UDP for transport across modern TCP/IP infrastructures, as outlined in RFC 1234. There is no ongoing development for IPX, and its unencrypted broadcasts and lack of modern security features—exemplified by vulnerabilities like denial-of-service attacks via malformed IPX pings—render it unsuitable for contemporary networks. Usage has significantly declined, with production environments limited to isolated, air-gapped setups outside retro contexts like emulated Doom multiplayer gaming via .

References

  1. https://www.novell.com/documentation/nw6p/pdfdoc/ipx_enu/ipx_enu.pdf
  2. https://www.cisco.com/c/en/us/td/docs/ios/novipx/configuration/guide/12_2sx/ipx_12_2sx_book/overview_novellipx.pdf
  3. https://support.novell.com/techcenter/articles/ana19900903.html
  4. https://www.rfc-editor.org/rfc/rfc1362.txt
  5. https://www.novell.com/documentation/nw6p/?page=/documentation/nw6p/ipx_enu/data/hc1w6pvi.html
  6. https://www.networkworld.com/article/716525/data-center-novell-through-the-years.html
  7. https://www.rfc-editor.org/rfc/rfc1553.txt
  8. https://www.cisco.com/c/en/us/td/docs/ios/novipx/configuration/guide/15-sy/ipx_15_sy_book/overview_novellipx.html
  9. http://www.novell.com/it-it/documentation/nias42/itcomm/rtcn_ita/data/hofxxkto.html
  10. https://wiki.wireshark.org/IPX
  11. https://ptgmedia.pearsoncmg.com/images/0735709777/samplechapter/0735709777.pdf
  12. https://www.faqs.org/docs/linux_network/x11684.html
  13. http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReports/CSL-79-10_Pup_An_Internetwork_Architecture_Jul79.pdf
  14. https://www.abortretry.fail/p/the-history-of-novell
  15. https://www.os2museum.com/wp/1987-networking-els-netware-286-level-i-2-0a/
  16. https://www.os2museum.com/wp/netware-history/netware-timeline/
  17. https://ftp.zx.net.nz/pub/archive/novell/servers/3.12/ENH312.PS.pdf
  18. https://www.pearsonhighered.com/assets/samplechapter/0/7/8/9/0789727870.pdf
  19. http://www.novell.com/news/press/pressroom/milestones2001.pdf
  20. https://www.os2museum.com/wp/netware-2-x-notes/
  21. https://support.novell.com/techcenter/articles/nc1998_05a.html
  22. https://www.rfc-editor.org/rfc/rfc1234.txt
  23. http://osr507doc.xinuos.com/en/netguide/dipxD.ipx_packet_struct.html
  24. https://www.cisco.com/c/en/us/td/docs/ios/novipx/command/reference/ipx_book/ipx_a1.html
  25. https://www.cisco.com/c/en/[us](/page/United_States)/td/docs/ios/novipx/configuration/guide/15-sy/ipx_15_sy_book/novellipx_cfg_expls.html
  26. https://www.rhyshaden.com/ipx.htm
  27. https://www.cisco.com/c/en/us/td/docs/ios/novipx/configuration/guide/15-sy/ipx_15_sy_book/novellipx_cfg_expls.html
  28. http://www.cisco.com/en/US/docs/security/vpn5000/manager/reference/guide/IPXfiltr.html
  29. https://www.novell.com/documentation/nw6p/?page=/documentation/nw6p/ipx_enu/data/hx3eg5x7.html
  30. https://support.novell.com/techcenter/articles/ana19951101.html
  31. https://www.cisco.com/c/en/us/td/docs/ios/novipx/command/reference/ipx_book/ipx_i2.html
  32. https://support.novell.com/docs/Tids/Solutions/10022605.html
  33. https://support.novell.com/techcenter/articles/ana19940504.html
  34. https://support.novell.com/techcenter/articles/ana19930905.html
  35. https://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1908.html
  36. https://datatracker.ietf.org/doc/html/rfc1791
  37. https://support.novell.com/techcenter/articles/ana19910501.html
  38. https://datatracker.ietf.org/doc/html/rfc1390
  39. https://www.rfc-editor.org/rfc/rfc1552.html
  40. https://www.rfc-editor.org/rfc/rfc1551.html
  41. https://community.cisco.com/t5/other-network-architecture-subjects/about-ipx-address-question/td-p/283710
  42. https://support.novell.com/techcenter/articles/ana19980302.html
  43. https://support.novell.com/techcenter/articles/ana19980904.html
  44. https://datatracker.ietf.org/doc/html/rfc1552
  45. https://www.linkedin.com/pulse/tcpip-protocols-won-were-ipxspx-better-sanjay-basu-phd-5likc
  46. https://www.novell.com/documentation/oes11/pdfdoc/upgrade_to_oes_lx/upgrade_to_oes_lx.pdf
  47. https://www.channele2e.com/post/we-kid-you-not-novell-netware-support-set-to-end-sort-of
  48. https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/novipx/configuration/guide/xe_3s/ipx_xe_3s_book/Novell_IPX_Discontinuation_xe.html
  49. https://www.reddit.com/r/sysadmin/comments/1hgmzlk/does_anyone_know_how_to_get_files_off_an_novell/
  50. https://datatracker.ietf.org/doc/rfc1234/
  51. https://nvd.nist.gov/vuln/detail/CVE-2000-0742
  52. https://www.doomworld.com/forum/topic/105786-vanilla-ipx-multiplayer/
Add your contribution
Related Hubs
User Avatar
No comments yet.