A Technical Overview of Novell TCP/IP in NetWare 6
Articles and Tips: article
Technical Writer
Novell, Inc.
SSamandeep@novell.com
01 Apr 2002
This AppNote is adapted from the Novell TCP/IP FAQ (Frequently Asked Questions) document. It provides a technical overview of the various protocols that make up the TCP/IP protocol suite (IP, TCP, UDP and others), as well as the new features that are available in the latest release. It also provides some implementation details on NetWare, specifically NetWare 6.
- Introduction
- General Features
- Load Balancing and Fault Tolerance
- SACK and Large Windows
- Multiple Default Gateways and Dead Gateway Detection
- Path MTU Black Hole Router Detection and Recovery
- Protection Against SYN and FIN Attacks
- Other Notable Features Related to Novell TCP/IP
- Conclusion
|
Topics |
TCP/IP, network protocols |
|
Products |
Novell TCP/IP |
|
Audience |
network administrators, consultants, integrators |
|
Level |
beginner |
|
Prerequisite Skills |
familiarity with TCP/IP |
|
Operating System |
NetWare 6, 5.1 |
|
Tools |
none |
|
Sample Code |
no |
Introduction
Novell's NetWare 6 operating system completely supports Native IP. The Novell TCP/IP stack that ships with NetWare 6 has been enhanced over the TCP/IP stack provided with previous versions of NetWare. The new stack includes features such as:
NIC-level load balancing and fault tolerance
Selective Acknowledgement (SACK) and Large Windows
Dead Gateway Detection and Multiple Default Gateways
Path MTU Black Hole detection and recovery for TCP connections
Defense against SYN, FIN, and similar denial-of-service attacks
This AppNote provides a technical overview of the Novell TCP/IP stack, with emphasis on the new features listed above.
The latest Novell TCP/IP stack is available with NetWare 6. You can also download it at http://www.novell.com/products/netware. The new features are also available for NetWare 5.1 in Support Pack 4 (NW5SP4.EXE), released in January 2002.
General Features
The Novell TCP/IP protocol suite is contained in the following NetWare Loadable Module (NLM) programs:
TCP.NLM (provides Transport-layer TCP and UDP interfaces)
TCPIP.NLM (provides IP, ICMP, IGMP, Routing, and other Network-layer protocols)
BSDSOCK.NLM (provides the BSD standard sockets interface)
NETLIB.NLM (a library of the entire stack-one version which runs with both the secure and non-secure versions of the above NLMs)
These TCP/IP binaries reside in the SYS:SYSTEM directory on the NetWare server.
MP-Enabled TCP and UDP
For NetWare 6 and NetWare 6 SP1 (but not for NetWare 5.1 SP4), the Novell TCP/IP software is multiprocessor (MP)-enabled and multithreaded. The Transport-layer modules (TCP and UDP) are completely MP-enabled so that the stack can process any TCP/UDP connections on any processor. This enhances performance and helps the stack scale more than it does on a single-processor machine.
Configuration Utilities
The following NLMs are used to configure the TCP/IP stack:
INETCFG.NLM (Internetworking Configuration utility, used for configuring network adapters, protocols, and bindings)
TCPCFG.NLM (a companion utility used to configure the TCP/IP stack)
Note: Currently, there are no Web-based tools for configuring the TCP/IP stack. However, this is planned for a future release.
Diagnostic Tools
To check network connectivity, the Novell TCP/IP stack provides the PING and TPING utilities. It also comes with a trace route utility called IPtrace. The new version of this utility has additional options that were not in the previous version. These include:
PMTUBHR (used for detecting a Path MTU Black Hole router)
STARTHOP (used for initializing a Time To Live value)
PKT (used to set the number of packets sent for each hop; the default is 3)
You can also change the Hops option with the new version of IPTrace.
Monitoring Utilities
To monitor the statistical variables of the TCP/IP stack, you can use the MONITOR and TCPCON utilities, which list all the sub-options of the stack.
IP Addressing
In addition to assigning a primary IP address on a NetWare server, you can assign secondary IP addresses to create multiple logical hosts that belong to the same network. In a multihoming setup where multiple network adapters (NICs) are grouped to support a single network, the secondary IP address supports an option to select one of the NICs in the group. By using the non-ARPable option, these addresses can be used as virtual IP addresses for load balancing solutions. The same IP address can be configured on all servers and the load balancer can distribute the client load across these servers.
This section presents basic IP addressing information for both primary and secondary IP addresses. Multihoming, load balancing and fault tolerance are explained in more detail later in this AppNote.
Configuring the Primary IP Address of a NetWare Server. Once you have installed and configured the network cards in the server, load the INETCFG utility at the server console. Select the Bindings option and bind IP to the desired IP address with the appropriate mask.
You can also do this at the command line by entering the following command:
bind ip <driver_name> address = <ip_address> mask = <netmask>
Note: NetWare 6 supports subnetting; however, supernetting is supported only on end nodes (hosts). You cannot make a NetWare server a router when supernetting is enabled.
An ARP-able primary IP address is the one that responds to an ARP request; a non-ARP-able address does not propagate the Media Access Control (MAC) address outside. If an IP address is bound with no-ARP option, a new IP address will be created on the basis of the MAC address where it is bound.
Secondary IP Addresses. A secondary IP address can be used to configure the NetWare server as a multihomed host. The client will then see each secondary IP address as a logical host. Secondary IP address can also be used to launch different services on different IP addresses. Another benefit that secondary IP addresses provide is that they can be configured as virtual IP addresses using the NoArp option which is useful for load balancing in a clustering environment.
To add a secondary IP address, enter the following command at the server console prompt:
add secondary ipaddress <ip_address>
When you use this command to add a secondary IP address, the address information will be lost when the server is rebooted or if the interface the address is bound to is deleted or disabled. To configure a secondary IP address that will be re-established after a server reboot, you can manually add the following command to the server's AUTOEXEC.NCF file (after the SYS:ETC\INISYS.NCF line):
add secondary ip address a.b.c.d
If you re-run the AUTOEXEC.NCF file to re-establish the secondary IP address after an interface is disabled or deleted, there must be another interface with the same network in the server.
Another option is to place the commands for adding secondary IP addresses into a separate .NCF file. To recover lost secondary IP addresses after a server reboot or deletion/disabling of an interface, you can execute the .NCF file from the server console by simply typing the .NCF file name.
You can add a non-ARPable secondary IP address by entering the following command at the server console prompt:
add secondary ipaddress <ip_address> noarp
A non-ARP-able secondary IP address will not reply to any of the ARP requests coming from the network, nor will it not propagate the MAC address outside. The IP address will remain the same in case of no-ARP.
To add a secondary IP address to a specific network adapter in a multihoming server, enter the following command at the server console prompt:
add secondary ipaddress <ip_address> prompt
You will then be prompted to select the card you want to specify.
To display a secondary IP address, enter the following command at the server console prompt:
display secondary ipaddress
To remove a secondary IP address, enter the following command at the server console prompt:
delete secondary ipaddress <ip_address>
Load Balancing and Fault Tolerance
On a NetWare server/router, load balancing and fault tolerance is possible through the use of a multihoming configuration. Multihoming enables an interface to assume multiple IP addresses on the same network. It is typically used for all IP networks bound to a router, regardless of whether the networks are bound to the same interface or to different interfaces.
The multihoming feature of Novell TCP/IP in NetWare 6 has been extended to help configure the stack for load balancing and fault tolerance at the NIC/Link level. The TCP/IP stack also supports interface or NIC grouping to facilitate load balancing and fault tolerance across multiple network adapters.
Load balancing is an enhancement of what load sharing gives you. It uses an intelligent algorithm that is helpful when the drivers are heavily loaded. Load balancing can also be configured alone, without fault tolerance on. While load balancing exacts a slight overhead as you increase the number of network adapters, the benefits it provides are well worth it.
Note: The Load Balancing and Fault Tolerance feature is supported on all Ethernet network adapters and drivers that strictly follow ODI specifications. Support for token ring and FDDI is planned for future releases.
Multihoming
NetWare 6 supports two different kinds of multihoming combinations: between Single/Multiple NICs and between Single/Multiple IP Addresses. In all cases, the secondary IP address can be configured on the same interface that has the primary IP address. Or the secondary address can be configured on a different interface. When there are multiple interfaces, the secondary address is associated with the interface that is bound to the network that uses the same address. If the secondary addres is not valid on any of the networks bound to existing interfaces, the address is rejected and an error message is produced.
To verify successful primary bindings when there are multiple IP addresses on same NIC, use the TCPCON utility to check the relevant interface. After loading the utility, select Protocol Information | IP | IP Addresses. (This information is not correctly available through the CONFIG and INETCFG utilities.)
Interface Grouping
Interface or NIC grouping is the process of selecting the NICs you want from the available set of multihomed NICs so you can enable them for load balancing and fault tolerance. These NICs should be bound to the same subnet.
In NetWare 6, two types of groupings enable you to optimize the load balancing and fault tolerance feature:
Single IP Address/Multiple NICs (grouped automatically)
Multiple IP Addresses/Multiple NICs (can be manually grouped and later ungrouped as needed)
The advantage of grouping in NetWare 6 is that once you group the NICs, load sharing is automatically enabled. The NICs are visible as a group of network adapters for a group of IP addresses or for a single IP address. This group would have a singular identity, with its own set of properties, and the properties of individual NICs in this group would no longer be valid. After that, each IP address looks like it is associated with more than one network adapter. This is the basis of load balancing and fault tolerance. To optimize the advantages of this feature, all of the NICs to be grouped must lie on the same LAN segment.
You can group Interfaces with multiple IP addresses, provided all the IP addresses belong to the same subnet. You cannot group interfaces bound to different networks. You can group adapters from different vendors with different capacities and properties (such as hardware checksumming support and so on).
In a load balancing and fault tolerance group, one interface will automatically become the primary interface (although you have the option to select another NIC to be the primary interface). The primary interface in a group handles all the routing-related issues for the group. It also handles all broadcast packets (otherwise, all interfaces receive broadcast packets). Multicast packets are handled by every interface.
In NetWare 6, grouping is done in such a way that all the MAC addresses are visible to the outer world, and they can therefore be used to send requests. Once the NICs are grouped, their individual identities are no longer valid. If you want to preserve the individual identity of a particular NIC, NetWare provides you the option of ungrouping the NIC (see "Ungrouping a NIC" below). Ungrouping is most advantageous when you want to configure a particular NIC differently from rest of the group.
A grouped interface will participate in load sharing, load balancing and fault tolerance, while ungrouped interfaces cannot participate in these features. Ungrouping can be done for Multiple IP addresses/Multiple NICs groups.
Grouped interface adapters will have same properties, while ungrouped adapters may have different properties. The following properties are in common when multiple interfaces are grouped:
Subnet Mask
Frame type
RIP options
OSPF options
Broadcast address
Multicast override IP address
TOS
ARP options
Router Discovery options
NAT options
Load Balancing and Fault Tolerance options
To check the multihoming configuration of a NetWare 6.0 server, use the "Display secondary IP address" console command. (In NetWare 6.1, this information will be available in the CONFIG command.)
Ungrouping a NIC. Ungrouping is the process of removing a particular NIC from a grouped set. Ungrouping can be done for the Multiple IP addresses/Multiple NICs type of groups. The NICs are LAN segment-independent. Such types of ungrouping can be used for security purposes, for QoS, or if you want to have a different configuration for a particular NIC.
How Load Balancing and Fault Tolerance Work
Thanks to the fault tolerance feature in the Novell TCP/IP stack, TCP connections remain intact when one of the adapters fails-another adapter simply takes over without interruption to the users. When load balancing across different NICs, a reply is sent to the ARP request of the client containing the less-loaded NIC's MAC address; for send packets, any of the grouped interfaces can be used, depending on the load.
There could be a minor packet drop during adapter failover. Connection-oriented applications such as TCP won't experience any interruption, whereas datagram applications such as UDP will see a packet drop based on the configured fault tolerance interval.
When an adapter fails, a Gratuitous ARP packet is sent to all clients that were connected to that adapter. This packet advertises the new adapter's MAC address, so the clients know they have to start sending requests to the new adapter. Older ARP entries are flushed at the router.
Note: This solution is different from other vendors' solutions in that the MAC addresses are visible to clients and multiple configurations are possible. This is not the case in products such as the Compaq NIC teaming solution. Novell's teaming solution is vendor-independent and operates from Layer 3. NetWare 6 Support Pack 1 includes configuration support in INETCFG for third-party vendor solutions for Load Balancing and Fault Tolerance at the NIC level.
The Fault Tolerance feature also sends an alert message to the logger screen. It will appear as a "display secondary IP address" message indicating that the interface is DOWN.
To view the IP address-to-MAC address mappings on your network, load the TCPCON utility and select Protocol Information | IP | IP Address Translations.
Configuring Load Balancing and Fault Tolerance
To configure load balancing and fault tolerance in NetWare 6, you must use the INETCFG utility-it cannot be done from the command line. You can verify the configuration using the TCP/IP protocol configuration menu.
Using INETCFG, you must enable Load Balancing and Fault Tolerance for both the system and the group. When the same IP address is bound to multiple interfaces, load sharing and fault tolerance is enabled by default.
If any one of the two duplicate bindings in a group is deleted, the group information for Load Balancing and Fault Tolerance is not automatically set to No in INETCFG. This has to be manually done, if required. However, if it is not manually set to No there is no impact on the Load Balancing and Fault Tolerance configuration.
Note: Load balancing is not available for gateways. The NetWare 6 TCP/IP stack provides only fault tolerance between gateways.
Monitoring Load Balancing and Fault Tolerance
Currently, the load balancing statistics can be viewed from the Novell Remote Manager utility. Another method of verification would be to capture packets and check the source MAC addresses of the outgoing packets.
For more information about load balancing and fault tolerance configurations, see "Link Level Load Balancing and Fault Tolerance in NetWare 6" in the March 2002 issue of Novell AppNotes, available online at http://developer.novell.com/ research/appnotes/2002/March/03/a020303.htm.
SACK and Large Windows
This section describes the Selective Acknowledgement (SACK) and Large Windows features of the Novell TCP/IP stack.
Selective Acknowledgement (SACK)
Selective Acknowledgment (SACK) is a mechanism that includes a retransmission algorithm which helps overcome weak links on the TCP/IP stack. The selective acknowledgment extension uses two TCP options. The first is a two-byte enabling option, SACK-permitted, which can be sent in a SYN segment to indicate that the SACK option can be used once the connection is established. The second option is the SACK option itself, which can be sent over an established connection once both the sender and the receiver have successfully negotiated the SACK-permitted option. Whenever there is loss of data, the data receiver can send the SACK option to acknowledge the out-of-order segments.
The Novell TCP/IP stack supports SACK per RFC 1323. The use of SACK is helpful in a scenario where there is a heavy flow of traffic and some packets are getting lost. With SACK, the sender doesn't have to resend all the packets that were sent after one lost packet. He can selectively resend only the packets that were lost. SACK has no impact on a LAN connection's performance.
To enable or disable this feature, enter the following command at the server console prompt:
Set tcp sack option = On | Off
The default setting is On (enabled).
Large Windows
The Large Windows option defines an implicit scale factor, which is used to multiply the window size value found in a TCP header to obtain the true window size. The TCP/IP stack supports a maximum window size of 1 GB. This Large Window option is negotiated when the TCP connection is established.
The TCP Large Windows size is useful on fast networks (such as Gigabit Ethernet) with large round-trip times. To understand how this works, think of a water hose. To achieve maximum water flow, the hose should be full. As the hose increases in diameter and length, the volume of water necessary to keep it full increases. In networks, diameter equates to bandwidth, length is measured as round-trip time, and the volume of water is analogous to the TCP window size. On fast networks with large round-trip times, the TCP window size must be increased to achieve maximum TCP bandwidth.
TCP performance depends not upon the transfer rate itself, but rather upon the product of the transfer rate and the round-trip delay. This "bandwidth delay product" measures the amount of data that would fill the pipe. It is the buffer space required at the sender and the receiver to obtain maximum throughput on the TCP connection over the path-in other words, the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. So on fast networks with large round-trip times, having a large TCP Window helps by allowing for a greater amount of unacknowledged data.
The TCP SET command for enabling or disabling Large Windows is:
set tcp large window option = On | Off
The default setting is On (enabled).
An application can take advantage of Large Windows by using the SO_SNDBUF and SO_RCVBUF TCP socket options.
Multiple Default Gateways and Dead Gateway Detection
This section describes the Multiple Default Gateways and Dead Gateway Detection features of the Novell TCP/IP stack.
Multiple Default Gateways
This feature extends the existing Default Gateway (Default Router) feature by allowing you to have more than one default gateways to your system. This provides greater robustness in case of any failures. If a default gateway goes offline, the Dead Gateway Detection feature detects this and uses the Multiple Default Gateway list to switch to the next preferred default gateway, thus making your network fault tolerant.
To configure Multiple Default Gateways, load INETCFG and select Protocols | TCPIP. Select the "Static Routing" option and add default route entries.
In a Multiple Default Gateway scenario, first preference is given to the Static Default Gateways, second to RIP, and third to ICMP. If there is more than one Static Default Gateway, then the priority is decided on the basis of the configured metric for the route. RIP has its own algorithm for updating the Default Gateways.
Dead Gateway Detection
This feature is used with the Multiple Default Gateway feature. When the current default gateway goes offline, this feature detects the failure and automatically enables the next preferred default gateway from the Multiple Default Gateway list to act as the current default gateway. When a dead default gateway with a higher preference is again online, this feature detects this and switches back to the default gateway with the higher preference.
To configure and use Dead Gateway Detection, load INETCFG and select Protocols | TCPIP and Timeout. The Probe Interval parameters lets you fine-tune the performance of the Dead Gateway Detection feature by modifying the time interval (in seconds) at which probes are sent to the default gateway to determine whether it is functional. The Probe Timeout parameter sets the time interval (in seconds) after which the next probe is sent to the default gateway when no reply is received by the gateway for the previously sent probe.
Dead Gateway Detection does add overhead to the system, but its benefits offset any resource hit that it may be causing.
Path MTU Black Hole Router Detection and Recovery
This feature detects a connection failure caused by "black hole routers" and helps to recover such connections. To understand how this feature works, you need some background information on Path MTU and the Don't Fragment bit.
The MTU (maximum transfer unit) is the maximum size of data packets that can be transferred across a given physical network. For local area networks, such as Ethernet, the MTU is determined by the network hardware. For wide area networks that use serial lines to interconnect packet switches, the MTU is determined by the software. The Path MTU is the smallest of all MTUs, for the hops along a path from the source host to the destination host. It governs the size of the largest IP packet that can be sent across the path without fragmentation. This feature conforms to RFC 1191.
When a router receives an IP datagram with a Don't Fragment (DF) bit set in its header and the packet size is greater than the next MTU, the router cannot forward the packet because its maximum segment size is too large for the receiving server. Normally, the router sends an ICMP "destination unreachable DF bit set" message to the host.
Sometimes, however, routers do not send this message and simply ignore these datagrams. Some routers might silently drop large frames, even when the DF bit is not set. Such routers are called PMTU Black Hole routers. Firewalls are often misconfigured to suppress all ICMP messages.
To respond effectively to black hole routers, the Novell TCP/IP stack provides a Path MTU Black Hole Detect feature. Path MTUBH Detect recognizes repeated unacknowledged transmissions and responds by turning off the Don't Fragment bit. After a datagram is transmitted successfully, the Path MTUBH Detect feature reduces the maximum segment size and turns the Don't Fragment bit on again.
Enabling and Disabling Path MTUBH Detect
To enable or disable the Path MTUBH Detection and Recovery option, enter the following command at the server console prompt:
set tcp path mtu black hole detection and recovery = On | Off
The default setting is Off (disabled). With the Path MTUBH Detect feature enabled, you may experience a slight performance penalty when there are multiple retransmissions.
Finding Black Hole Routers
You can find a black hole router between any two hosts by using the PMTU option in IPTrace. You could also do it with the tping utility by using different packet sizes along with the '"set don't fragment bit" option.
Protection Against SYN and FIN Attacks
This section describes the Novell TCP/IP stack's features for protecting your network against SYN, FIN, and similar denial-of-service attacks.
SYN Attacks
A SYN attack is one in which the TCP connection initiation stage is misused by an attacker. The attacker sends faked or spoofed connection requests called the SYN packets with a non-existing source address. On receiving such packets, the stack allocates resources for this connection and responds with a SYN Ack. Because the source address is non-existent, nobody would respond to this SYN Ack. This causes the resources to be blocked for a long period of time, until the connections time out. If an attacker floods your system with a large number of packets, legitimate users would not be able to access your system. This is known as a "denial of service" attack.
There is a two-pronged strategy to protect NetWare 6 from a SYN attack:
As the number of connection requests grows, the TCP/IP stack allows less time than the usual 75 seconds to the client side, after allocating the resources, to complete the three-way handshake (by sending the third ACK). In the event of a moderate attack, this gives legitimate users some possibility for getting a connection through.
When the number of connection requests grows beyond a predicted threshold, there is greater possibility of denial-of-service activity. In a typical SYN attack, the third ACK never comes through, thereby blocking the resources for that period; the attack is repeated to prevent any legitimate requests from getting through.
To handle such a situation, the stack does not block its resources before the three-way handshake is complete. It is done by the server sending a cookie (derived from secrets and sequence number information) to the client. All legitimate clients will send the third ACK back, so after the cookie verification, resources will be allocated and the connection is put directly in the Established state. Therefore, the SYN attack packets are handled without using any memory resources.
To enable or disable this feature, enter the following command at the server console prompt:
Set tcp defend syn attacks = On | Off
The default is Off (disabled).
FIN Attacks
A FIN attack is an attack that targets the connection end states of TCP. A connection is established without any data transfers. The connection is then closed immediately, overwhelming the server with close requests and forcing the server to keep track of a large number of graceful closure states.
This feature provides a simple, single tuning option: the Minimum Threshold parameter. In the TCP stack, the wait states (FIN_WAIT1, FIN_WAIT2, CLOSED_WAIT, LAST_ACK, and CLOSING) are arranged in ascending order of importance by determining which of the states are less risky to terminate. The order is static.
The stack assumes that there is no risk in terminating all connections in a less important state. According to the arrangement of states, if a less important connection is overusing resources, then it is selected. Alternately, if an important state is overusing resources and the less important states do not dominate, it would be selected for reset only. At any given point in time, a Minimum Threshold number of connections will be permitted.
To enable this feature adn set the maximum number of wait states, enter the following command at the server console prompt:
Set maximum wait states = n (1 to 100000)
The default is 0 (disabled). The maximum number of wait states could be 1000 (depending on how many connections should be there in the closing states of TCP). Tuning can be done by observing the number of connections in different states using the _tcp command. If too many connections are present in FIN_WAIT_1 states and any other connection states associated with TCP connection closure, the value should be set appropriately.
Other Notable Features Related to Novell TCP/IP
This section lists some other notable features related to the Novell TCP/IP stack.
Dial-Up WAN Connectivity
To support dial-up WAN connections to a NetWare server, you need the Novell Internet Access Server (NIAS) software. NIAS ships with NetWare 5.1, but for NetWare 6, it is a standalone product which must be downloaded separately. It is available as a patch for the NetWare Small Business Suite.
With NIAS 4.1 running on it, a NetWare server can be configured as a Remote Access Server. With a modem and a phone line, a PPP connection can be established, thus providing an entry point to the WAN. The following interfaces are supported for PPP:
RS232
Async Modems (Raise DTR, Hayes, and V34)
You can have either a Dial-on-Demand connection or a permanent leased connection. NetWare supports both.
You can set up a dial backup in case one channel goes bad by configuring two primary call destinations in the WAN Call Directory option and defining the backup associations.
The dial-up services provide QoS; VJ header compression is available for slow serial links. You can use either PAP or CHAP for authentication to make the dial-up connection secure.
Migrating from IPX to IP
If you have an IPX network and would like to migrate to NetWare 6 and Pure IP, you can use the Server Compatibility Mode Driver (SCMD). This is different from Novell's NetWare/IP solution in that NetWare/IP provides IP connectivity in IPX networks, whereas SCMD is used for IPX-to-IP migrations.
For more details, see the NetWare 6 online documentation at http://www.novell. com/documentation/lg/nw6p/.
Application Interfaces and Support
The following application interfaces are supported to use the TCP/IP services:
BSDSOCK interface is supported for all socket operations
Winsock 2 interface is supported
TLI is supported but not recommended
Native interface is supported but not recommended
Currently, Novell BorderManager supports IP address and port redirection for proxy applications in a NetWare environment.
Miscellaneous
Checksumming Offload. If a NIC supports hardware checksumming, the Novell TCP/IP stack will offload checksumming onto the NIC by default.
DSR Support. Direct Server Return (DSR) can be configured using non-ARPable secondary IP addresses.
Routing Protocols. The Novell TCP/IP stack provides the following routing protocols: RIP I and RIP II, OSPF, EGP, and ICMP Router Discovery.
IPsec Support. The Novell TCP/IP stack that comes with NetWare 6 supports IPsec.
CIDR Support. The Novell TCP/IP stack implements Classless Inter-Domain Routing (CIDR). This makes is possible to bind to supernetted addresses with non-natural subnet masks. CIDR also allows binding to one or more interfaces. In the current stack, the NetWare system bound to a system in a supernetted IP address environment acts as an end host. In such a scenario, forwarding is disabled.
Proxy ARP. NetWare 6 supports proxy ARP.
Duplicate IP Address Detection. NetWare 6 can detect duplicate IP addresses on the network. It displays an alert message, along with the MAC address, on the server console.
UDP Features. The UDP included in the Novell TCP/IP stack can transmit a maximum packet size of 36992 bytes. It does not currently support multiple listeners on the same IP address and port, but that enhancement is planned for a future release.
Path MTU Discovery. The Path MTU Discovery feature (as outlined in RFC 1191) is available on the Novell TCP/IP stack.
Conclusion
This AppNote has provided a technical overview of the Novell TCP/IP stack that is available with NetWare 6 and for NetWare 5.1 in Support Pack 4. For more information about Novell TCP/IP and its features, refer to the following resources:
NetWare TCP/IP Administration Guide (http://www.novell.com/documentation/lg/nw6p)
TCP/IP developer information (http://developer.novell.com/ndk - search for the Server Protocol Libraries for C)
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.