NetWare Over TCP/IP: Integrating NetWare Services into the TCP/IP Environment
Articles and Tips: article
Senior Manager, Server Communications
Novell Internet Access Division
ROGER HOLM
Client Architect, NetWare Client Group
Novell Internet Access Division
EDWARD LIEBING
Senior Research Engineer
Novell Developer Information
01 Mar 1997
To make it easier to build and manage heterogeneous networks with connections to the Internet, Novell has embarked on a project to make NetWare services equally available in both IPX and TCP/IP environments. This AppNote gives you a sneak peak at this exciting technology.
- Introduction
- The Changing Context of Networking
- The Evolution of IntranetWare Communications
- Open Standards and NetWare Core Services
- Integrated Network Services Discovery
- Increased Developer Support
- Moving Into the Future
- Benefits of NetWare Over TCP/IP
- Conclusion
Introduction
Over the past few years, as businesses have enthusiastically embraced the Internet, Novell has provided its customers with a variety of products to allow existing LANs and WANs to participate in the TCP/IP-based Internet environment. To better meet the needs of our customers who are supporting heterogeneous networks and multiple protocols, Novell is taking the next logical step through an initiative known as "NetWare Over TCP/IP." The primary goal of this initiative is to provide NetWare services directly to nodes on the Internet.
This AppNote introduces NetWare Over TCP/IP and provides an overview of the technologies and components that are involved. It covers:
The changing context of networking and the resulting evolution of NetWare communications
Novell's plan for combining NetWare core services and open standards
The integration of Novell Directory Services with various Internet standard technologies to provide network services discovery in TCP/IP networks
Developer support for NetWare Over TCP/IP
Benefits to be derived from providing NetWare services over TCP/IP
This information will benefit network designers, administrators, and developers who want to reduce the number of protocols they have to support or who are looking for easier ways to manage heterogeneous networks.
The Changing Context of Networking
With the arrival of the Personal Computer in the business world in the 1980s, Novell assumed a leadership role in the development of PC networks. The initial focus was on small or medium-sized commercial networks. These early commercial LANs had to handle dynamic information, yet be easy to use since they had limited IS support. It was during this time that NetWare and its IPX family of protocols became the standard for corporate LANs.
As LANs grew into WAN configurations to support larger businesses, the networking focus widened to include more traffic management and interaction with mainframe and Unix systems which were usually based on the TCP/IP protocols. Accordingly, Novell implemented technologies such as the NetWare Link State Protocol (NLSP) for filtering and redirecting IPX Service Advertising Protocol (SAP) traffic, multiprotocol routing, NFS services, and gateways to DECNet and SNA networks to introduce NetWare networks into mainframe and Unix environments.
Novell has been active in the TCP/IP market for many years. In addition to providing the standard NetWare services in the IPX environment, Novell has provided an infrastructure for client access into the TCP/IP environment and has made TCP/IP stacks available on both client and server. Novell's LAN Workplace product, for example, allows NetWare clients to access Unix servers and provided common utilities such as a Browser, FTP, Telnet, Gopher, Finger, Ping, and an X Window server. Novell has also introduced products to support the coexistence of the IPX and TCP/IP environments: NetWare/IP allows IPX services to work in a TCP/IP environment while maintaining full backwards compatibility with IPX-based applications and networks; MultiProtocol Router routes both IP and IPX protocols and provides SLIP and PPP serial connections; and Dynamic Host Configuration Protocol (DHCP) services provide IP address leasing.
While the commercial sector was busy implementing LANs and WANs, government and educational research agencies were linking sites together to form the worldwide network known today as the Internet. Over the last few years there has been a tremendous push to connect corporate LANs and WANs with the TCP/IP-based Internet and to use its standards to form in-house "intranets." As a result, many businesses are building and maintaining heterogeneous, multiprotocol computing environments that combine LAN, WAN, Internet, and intranet operations and require multi-level security and multiple resource discovery and naming systems.
Novell wants to make it easy and efficient for our customers to build and maintain these heterogeneous networks. We are working to bring together the four architectural platforms of LAN, WAN, Internet, and Intranet into a single, integrated environment in which users with sufficient rights on one platform will be able to easily go to the other platforms for the information they need.
In this environment, a fifth platform will become more feasible: the "Extranet" or "virtual corporation." An Extranet is a method of allowing individual businesses, business groups, and consultants from around the world to work together on a project without having to leave their home offices. Members of this virtual corporation might be linked together through a variety of methods such as a T1 line, an Internet Service Provider (ISP), or the Internet itself. The virtual corporation exists for the duration of the given project, and can be modified when necessary as different portions of the project unfold.
The Evolution of IntranetWare Communications
A key part of Novell's initiative to simplify heterogeneous networking is to provide all of the core services currently available in NetWare in a TCP/IP-only environment. Given the vast installed base of servers and applications that depend on the IPX protocols, Novell and its partners must make sure that the rapid deployment of Internet technology does not disrupt the operation of existing networks.
Building from IPX Roots
In moving toward TCP/IP, Novell is not abandoning its IPX roots. Rather, we are evolving IntranetWare to serve more customers. Both open and de facto standards find a home in the Novell environment. Novell's solutions will leverage standards-based technologies such as DHCP and Domain Name System (DNS) to work with generally-accepted standards such as Novell Directory Services (NDS) and WinSock. Backwards compatibility and peaceful coexistence of the old and the new are prime directives for Novell.
NetWare/IP for IPX Compatibility
As mentioned previously, the NetWare/IP product was Novell's initial solution for mixed IPX and IP networks. Two critical elements of NetWare/IP allow an IPX client or server to function within a TCP/IP network: IPX encapsulation and Domain SAP/RIP Services (DSS).
Through IPX encapsulation, NetWare/IP allows existing NetWare technology to remain IPX-based. NetWare Loadable Modules (NLMs), NetWare Core Protocol (NCP) requests, applications, and utilities designed for the IPX environment can continue to function as they always have. The IPX information is captured at the last moment, placed inside an IP packet, and sent through the TCP/IP stack and onto the wire. Thus NetWare/IP allows IPX-based operations to exist in a TCP/IP environment without forcing them to be aware of it.
IPX-based software uses SAP to advertise and locate network services; in the TCP/IP environment, DNS and manual configuration are used for this type of information. To enable coexistence, Novell created the Domain SAP/RIP Services technology to provide service addresses for NetWare/IP. DSS captures SAP and RIP traffic and places the service addresses in the DSS database, which is then accessed by NetWare/IP.
With Novell's push to more fully integrate NetWare networks into the Internet and to provide Internet technology in corporate intranets, it became clear that we needed to make NetWare services, particularly NCP and NDS, available to TCP/IP nodes without the complications imposed by NetWare/IP. Of course, NetWare/IP remains an important product to provide compatibility with the many existing applications that require IPX. We recognized that whatever new TCP/IP technology we were to develop had to coexist with NetWare/IP.
NetWare Over TCP/IP: A Native IP Solution
With these objectives in mind, Novell embarked on a Native IP project to make IntranetWare more useful and efficient for Internet customers. Among the results of this effort is the NetWare Over TCP/IP feature which makes both NCP and NDS application-layer protocols in the Internet protocol suite without the need for IPX encapsulation or special naming support.
Phase One. The first phase of the project is to allow NetWare services to become part of the TCP/IP environment. Our main goals are to maintain full support for existing IPX-based applications while providing an easy migration path for developers. This can be accomplished by modifying some of the existing Novell technologies and combining them with TCP/IP standards, as follows:
Retain the existing NetWare/IP product to allow coexistence of IPX- based services in an IP environment.
Modify our NCPs to use both TCP and UDP (User Datagram Protocol) transports.
Modify the NetWare operating system to remove all IPX dependencies (the operating system already supports a TCP/IP protocol stack that can be loaded concurrently with the IPX/SPX stack).
Have DHCP broker IP addresses and help the Novell client requester locate an NDS server.
Use NDS to provide the naming service.
Use the proposed IETF (Internet Engineering Task Force) Service Location Protocol (SLP) to provide the service discovery function to replace SAP.
The switch to using TCP/IP protocols to send and receive NCP packets across the wire has a minimal impact on the NetWare communications architecture. The current request/reply communication remains unchanged. Some NCPs that are relevant only in an IPX environment are being modified to prevent their use in a TCP/IP environment.
As noted above, NetWare Over TCP/IP makes use of both TCP and UDP transports. Larger NCP transactions-for example, a read request that results in numerous large reply packets are placed in TCP packets to take advantage of the "sliding window" efficiencies in TCP/IP. This is similar to using the IPX Packet Burst protocol to improve performance for large NCP read and write requests over slow WAN links. To further improve WAN throughput, NCP now supports messages of up to 64KB in size.
UDP is similar in concept to a basic connectionless IPX datagram. It is useful for the efficient exchange of small packets and functions very much like IPX. Thus, in the TCP/IP environment, small "control" types of NCPs can be placed inside UDP packets. The IANA (Internet Assigned Numbers Authority) has assigned port 524 to Novell for NCP over UDP and TCP.
Note: Although UDP can be used for NCPs, it is not required. NetWare Over TCP/IP can operate in a TCP-only environment if the customer site has turned off UDP. |
Phase Two. In the next phase of this project, Novell will implement a number of other technologies and services to complement and expand beyond the TCP/IP-based NCP offering. These include:
Implementation of additional open and de facto standards
Integrated network services discovery
Increased developer support
In IPX networks, Novell designed its services to be as dynamic and self- configuring as possible. Resources can easily be added to or removed from the network without the administrator having to manually reconfigure service address and routing tables. The traditional TCP/IP environment has evolved along a more static model that requires a significant amount of manual configuration. In all phases of the NetWare Over TCP/IP project, Novell is looking to extend its ease-of-use technology into IP networks and make them easier to manage and use.
Open Standards and NetWare Core Services
NetWare Over TCP/IP accommodates both open standards and de facto industry standards. These include:
Dynamic Host Configuration Protocol (DHCP)
Service Location Protocol (SLP)
TCP/IP (both IPv4 and IPv6)
WinSock 2
Novell Directory Services (NDS)
Domain Name System (DNS)
Secure Sockets Layer (SSL) and IPSec security
Network Time Protocol (NTP)
Novell will also take the native NetWare services that we are known for fast file and print, directory services, security, GroupWise and ManageWise services and make them available to users on a wide variety of computing platforms.
The following sections outline how the NetWare Over TCP/IP project is making use of the standards listed above.
Dynamic Host Configuration Protocol (DHCP)
The answer to the automatic configuration question is found in DHCP technology. DHCP can be used to tell a client the address of an NDS server, the NDS tree name the client should operate in, and the client's default NDS context. Once the client knows this, it can gain access to the general naming service NDS provides.
Service Location Protocol (SLP)
The Service Location Protocol is somewhat similar to the Service Advertising Protocol (SAP) in IPX, in that it provides for the discovery of services in a TCP/IP environment. However, SLP doesn't require the background broadcast traffic that SAP uses. It is intended to replace the service discovery function of SAP, which allows you to query the network and obtain a quick list of the services that are available.
The Service Location Protocol is currently before the Internet Engineering Task Force as a draft proposal. Novell is a member of the IETF SrvLoc working group.
IPv4 and IPv6
The NetWare Over TCP/IP feature has been designed to allow Novell and IntranetWare developers to support both IPv4 and IPv6 with little or no additional effort. The foundation laid in Phase One of the NetWare Over TCP/IP project provides all of the changes necessary to seamlessly add IPv6 to the environment. We are currently working on an IPv6 stack and related technologies as part of Phase Two.
WinSock 2
WinSock 2 is one of the most popular APIs in the industry. By writing to this public standard, developers can provide access to IPX/SPX, IPv4, and IPv6. This will also help minimize the impact of implementing IPv6 in IntranetWare.
NDS and DNS
Novell Directory Services provides an improved naming system that is more easily managed and scales better in large networks. Novell is integrating its DNS server into NDS so that the NDS database can be used as the single source for a company's naming information. The DNS-NDS integration is discussed in more detail under "Integrated Network Services Discovery" later in this AppNote.
By integrating access and updates between NDS and DNS, Novell will offer the same management and support benefits to TCP/IP administrators and users that 17 million NDS users worldwide are now enjoying. Novell has also entered into agreements with Sun, Hewlett-Packard, IBM, and SCO to broaden the platform base of NDS and expand its usefulness. This will strengthen Internet access and make TCP/IP management easier for companies of all sizes.
SSL and IPSec Security
Users of NetWare services have become accustomed to the security features currently provided by NetWare servers and clients. They will expect the same or better levels of security when using TCP/IP networks. The first phase of NetWare Over TCP/IP provides security features that are equivalent to those currently available for IPX networks, as well as Secure Sockets Layer (SSL) security. During the coming year, more comprehensive security will be made available through the use of the IPSec Authentication Header.
Novell has always supported multiple security levels. Both NetWare and IntranetWare feature NCP-based Packet Signing, which offers NCP packet-level security. Future releases of the NetWare operating system will take advantage of IPSec security at the IP transport level, which provides a security authentication header with each IP packet. (IPSec is an IETF-proposed standard for encryption and authentication at the IP layer, which would provide a secure way to exchange data regardless of whose firewall is installed.) If customers want to move up to the application level and run SSL-type security, they can do that too. Customers will thus be able to freely choose what type of security to implement for their needs.
Multi-level security becomes increasingly important as "virtual corporations" are created with one company doing business with another. This scenario raises important issues, such as what security levels must be in place to protect each company's interests, and how can the participating companies "negotiate" for their need-to-know information.
Novell is also working on a Controlled Modular Cryptography (CMC) project that will help overcome some of the current obstacles to sharing data securely across international boundaries. Given that various countries have different cryptography laws, CMC will make it possible for developers to simply provide a "hook" in their networking solutions for whatever encryption engine the customer requires.
Network Time Protocol
The NetWare 4.x operating system currently uses the Timesynch protocol to synchronize time between NetWare 4 servers. As Novell moves into the TCP/IP community and starts putting NetWare services on other platforms, IntranetWare will need to synchronize time with a variety of disparate servers from Sun Microsystems, Hewlett-Packard, IBM, SCO, and others. To accommodate this kind of time coordination, Novell will adopt the IETF Network Time Protocol (NTP) standard in our next generation of products. Through this standard, Novell will be able to synchronize its services no matter where they reside.
Integrated Network Services Discovery
The largest impact of the NetWare Over TCP/IP project is in the area of naming and discovery. In the IPX architecture, SAP was available to take care of initial service discovery. Services could advertise their presence on the network and dynamically populate the bindery tables on every server. Clients could either interrogate the tables or listen to the wire for SAP traffic. As NetWare moves into large-scale implementations, these ease-of-use advantages are offset by the increased costs of bandwidth. Additionally, many companies want only TCP/IP traffic on the wire. Thus SAP functionality must be accomplished without the traditional IPX SAP component.
Novell's NDS is the foundation for the integrated network services discovery that will operate with the TCP/IP protocols. On IPX networks, SAP will continue to perform the services discovery function. On the Internet where SAP isn't available, Novell will use the more advanced protocols of the Internet for service advertisement and automated network-based client configuration. The key facets of this new technology are:
The use of the DHCP standard for the initial client configuration process.
The continued development of the Service Location Protocol (SLP) which will coordinate with NDS to provide service discovery.
DHCP and the Client Configuration Process
Novell will use DHCP as part of the client initialization process. Instead of the NetWare client broadcasting a General Services query when it wants to establish an initial connection to the network, the client will use DHCP to locate a server running NDS. The DHCP server will pass back the address of the NDS server and the context the client should use to log into the server. Figure 1 diagrams how this will work.
Figure 1: DHCP initial client configuration process.
As shown in this diagram, a DHCP client first discovers a DHCP server and sends it a message requesting an IP address and an NDS server address. The DHCP server returns an IP address and NDS server address, along with the NDS context in which the user resides. With this information, the client's TCP/IP stack is initialized. It passes the NDS server address and context to the NetWare client requester, which then authenticates to NDS. Once the user is located in the proper NDS context and authenticated, NDS can handle everything from there.
This scenario replaces the traditional method of the NetWare client broadcasting to a server, getting a preferred server, and then connecting to that server. It also allows for optional IP address leasing for customers who prefer to dynamically assign IP addresses rather than manually configuring them. Typically a number of users exist in the same context in an NDS tree. Instead of the administrator having to set up and configure IP services on every workstation, IP addresses and common tree contexts can be configured on the DHCP server and distributed from there to single users or groups of users.
The Role of SLP
SLP works in much the same way as SAP in terms of registering information in a database and allowing clients to look in that database to find services. However, there are two principal differences between SAP and SLP. First, SLP does not aim at maintaining a global database of services, but only of services in the local area. It discovers services in the local area via multicast requests which are forwarded from network to network within a site. Second, SLP assumes that the client will be able to locate either the services themselves, or a database server representing those services, using these pan-network multicasts.
Through Novell's integration of SLP with DNS and NDS, which will compile the local SLP information to provide a global representation of all available services on the network, customers gain the benefits of dynamic discovery locally plus scalability in large networks.
Figure 2 illustrates how SLP registers a service provider on a local segment. Each agent must register its own services. Whether the User Agent is on the server or on a workstation, it can register as a client after it communicates with the Directory Agent to see what services are available. Once the service is registered with the Directory Agent or Service Agent, you can register or deregister the service.
Figure 2: SLP agent relationships.
Once the application has registered with the SLP User Agent, it can look up a service or get a list of services and read the attributes of a service. In the NetWare Over TCP/IP environment, this information is pulled out of the Directory Agent and put into NDS so that users and administrators can know what services are available in this local area, provided the proper security rights are granted.
In the scenario shown in Figure 3, a NetWare client can use the User Agent to go into an SLP Directory Agent or Service Agent, or into NDS to reach out to other LAN or WAN segments.
This method does not rely on service information obtained from routers. Instead, NDS is used for global communication of information. Through this method, service updates on local segments are just as reliable and dynamic as in today's SAP-based networks.
Figure 3: Integrated network services discovery.
IP Configuration Options
Using these technologies, network administrators will be able to implement whichever IP configuration method best meets their business needs. Three possible choices are described below.
Static Configuration Option. IP-based name resolution in NetWare can follow the existing conventions used in many TCP/IP and Unix environments. In this case, naming is a manual process involving the workstation and the Domain Name Server. NetWare already provides a method for workstations to access manually-configured IP information including the IP gateway server, the subnet mask, the router address, the workstation IP number, and the address of a Domain Name Server. The address of one or more NDS servers could also be included with this existing information. Rather than using SAP to discover the NDS tree, the client could use these manually-configured addresses. Once connected to the NDS tree, the client would use NDS to obtain the addresses of other resources and services.
DHCP Configuration Option. This option allows the system administrator to implement DHCP services and provide IP address leasing. This technology would work with the NDS naming technology, thus retaining NDS as the single name repository and using a DHCP service module to access that name base.
SLP-DHCP-NDS Configuration Option. The combination of these technologies provides the opportunity to take advantage of NetWare's traditional dynamic service discovery in a non-SAP TCP/IP environment. DNS is global, but it is a flat domain that must be manually managed and is hard to administer globally. The integration of NDS, DNS, DHCP, and SLP provides a unified, global naming solution that leverages Novell's key NDS technology. With SLP feeding local service information to NDS, and with NDS integrated with DNS and DHCP, Novell will bring all of the naming services together into one space. This integrated network services discovery schema will prove invaluable to LAN/WAN/Internet/intranet customers.
Increased Developer Support
Having addressed NCP, SAP, NDS naming, and IPX support issues, it is time to consider what general communication interfaces will be offered for future releases of IntranetWare. The Novell API sets must support existing developers who will continue to use IPX, SAP, and NetWare/IP, while providing access to IP services for developers who want to use TCP/IP, UDP, NCP/IP, DHCP, and NDS. They must also provide a foundation for the communication needs of the Java class libraries.
CLIB and Cross-Platform Libraries
All of the existing Novell API sets will continue to receive support, as there is a great deal of IPX-based software written to each of these. The function calls within CLIB will not have to change to support both IPX and TCP/IP protocols. Rather, developers will be provided an optional protocol selection mechanism within the existing function calls. If this setting is left at the default, the library will decide whether it needs IPX or IP. Thus developers don't have to make that decision unless they choose to by setting the library call parameter to something other than the default.
Figure 4 presents a chart of the API support for IntranetWare servers. This chart shows the API libraries that Novell has available, including CLIB, SLP, WinSock, TLI/Streams, and BSD Sockets.
Figure 4: IntranetWare server API.
Developers don't need to be concerned with anything below the NCP API level. If you are making only NCP calls using the CLIB API library, everything below the NCP level is taken care of for you. The same thing occurs on the client side, as illustrated in Figure 5.
Figure 5: IntranetWare client API.
As you can see, the WinSock 2 API used in Microsoft's Windows 95 and Windows NT (and in some Unix implementations) has been implemented on the IntranetWare server and client platforms. This API framework provides a uniform access to transport, naming, and security services. Because of the Service Provider Interface capability within WinSock 2, additional protocols, name services, or security services can be developed and exposed at any time without requiring code changes in applications. The WinSock 2 implementation on IntranetWare currently supports IPX, SPX, SPX2, UDP, and TCP. IPv6 support will be added later this year. Service Provider Interfaces are being written for SLP and NDS.
By supporting WinSock 2, Novell gives developers another popular industry standard API for using the NetWare protocol stacks. This way, developers won't have to write directly to IPX, IPv4, IPv6, or any other stack. Moreover, excellent training information on WinSock 2 is readily available from a variety of sources.
Moving Into the Future
In embracing open industry standards, Novell is taking advantage of numerous opportunities to provide additional functionality to IntranetWare networks, while continuing to meet the needs of the large installed base of NetWare users. Further development of the NetWare Over TCP/IP feature is occurring in "Internet time." As of this writing, Novell has implemented 32-bit client technologies running on both Windows 95 and Windows NT, each of which supports WinSock 2. NCP now runs over both IPX and TCP/IP, and the initial integration of DHCP, DNS, and NDS is complete. The SLP User and Service agents are up and running. The SLP interface into NDS is scheduled for completion within the next few months. Novell is also planning to have an IPv6 stack available for use with a future release of IntranetWare, which will also be working under WinSock 2.
Protecting Existing Investments
Through all these new product developments, Novell will continue to provide full support for existing IPX-based software. This is in keeping with Novell's overall approach of providing multiple solutions that allow the business needs to dictate the network configuration, rather than the network needs to dictate the business configuration.
NetWare/IP. If your company requires IPX products and support, Novell will provide that support through products such as NetWare/IP, which currently ships with IntranetWare. NetWare/IP is the compatibility module for supporting IPX-specific applications in a TCP/IP-only environment. No changes are required to the applications. The DSS technology in NetWare/IP captures SAP and RIP packets and places the information into a name base, from which NetWare/IP can extract it for its own use.
IPX/IP Gateway. Many Novell customers who choose to remain with their tried-and-true IPX implementation also want seamless access to the TCP/IP-based Internet. To provide for this, Novell has developed an IPX/IP gateway. This gateway allows the IPX implementation to remain undisturbed, while providing a gateway into a TCP/IP environment.
Migration and Coexistence. Novell recognizes that it takes time to migrate a network to a new platform. To accommodate the needs of customers who must maintain old and new platforms during a migration process, Novell has designed NetWare Over TCP/IP so that the IPX and TCP/IP protocol stacks can coexist both at the client and at the server. Connectivity to NetWare 3.x and 4.1 servers is maintained because only the transports are being changed. Any program written to NCP should continue to work with NetWare Over TCP/IP.
The vast majority (90% or more) of traffic on a network is file system reads and writes performed through NCP access. If the customer so desires, these will all take place using the TCP/IP transport via NetWare Over TCP/IP. For those customers who require IPX compatibility, the NCP reads and writes are not encapsulated, but are placed directly within IP packets. The remaining IPX packets, which are encapsulated into IP packets, constitute a fairly small percentage of the total network traffic.
Benefits of NetWare Over TCP/IP
Through the technologies described above and others currently in development, Novell is refocusing on what has made our products successful from the beginning: freedom of choice. Unlike many of our competitors, Novell allows customers to choose what hardware they will buy, what workstation platforms they will use, and which applications they will run, rather than locking them into a specific paradigm and product family.
True Heterogeneous Networking
In building heterogeneous networks, Novell allows the customer to select the configurations that make business sense without forfeiting functionality or revenue. Some customers will want to remain on an IPX-only implementation. Others will want to move quickly to a TCP/IP-only network implementation. Undoubtedly there will be many implementations with both protocols present, especially where large implementations pursue a lengthy transition from IPX to TCP/IP. The mixed IPX-IP environment also makes sense in cases where some services are available from an IP segment while others can be accessed only through an IPX segment.
With NetWare Over TCP/IP, Novell offers mixed network support so you can run IPX and TCP/IP protocols on the same backbone. This native IP solution also offers standard IPX and TCP/IP naming technologies. This also provides more fault tolerance by opening multiple paths for users to locate the information they need. As Novell moves NDS to different platforms, such as Windows NT and various Unix servers, NDS on NetWare will be able to communicate with NDS on NT and NDS on Unix. To get to other naming services such as DNS and X.500, NetWare will use the Lightweight Directory Access Protocol (LDAP).
Easier Network Management
With these Internet-standard interfaces and NDS as the core management technology, Novell can provide the tools necessary for easier management of WAN communications within an efficient TCP/IP environment. One of the ways the integrated TCP/IP solution makes multiprotocol networking easier is by providing NetWare's self- configuring "plug and play" technology on local IP segments. This significantly lowers the administrative burden, especially for customers with Novell networks already implemented.
Lower Networking Costs
The components Novell is offering--an IPX/IP gateway for bringing together heterogenous networks, local plug-and-play feeding a secure global naming service, integrated network services discovery, integrated NDS-DNS-DHCP technologies, and integrated Java-based installation and configuration utilities --will help reduce the cost of implementing the network. Training costs are reduced as well, since administrators can build on the knowledge base they already have in the TCP/IP environment, while users can interact seamlessly with users of other networks.
Conclusion
This AppNote has introduced Novell's NetWare Over TCP/IP feature, one of the most exciting developments to come out of the Native IP project. It has outlined the various components being developed and discussed the developer support that is available, as well as some of the benefits for network administrators, developers, and users.
Novell's product development plans encompass other technologies which help bring together the benefits of the Internet with the daily business operations of the corporate LAN or WAN. This set of services, which includes Novell's Web Server, Proxy Server, and Firewall technology, will be discussed in future AppNotes.
* 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.