Electrical computers and digital processing systems: multicomput – Computer-to-computer data addressing
Reexamination Certificate
1999-10-26
2004-03-16
Cardone, Jason D. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data addressing
C709S246000, C709S230000
Reexamination Certificate
active
06708219
ABSTRACT:
FIELD OF INVENTION
This invention relates to computer networks. More specifically, it relates to a method and system for dual network address utilization.
BACKGROUND OF THE INVENTION
The Internet Protocol (“IP”) is an addressing protocol designed to facilitate the routing of traffic within a network or between networks. The Internet Protocol is used on many computer networks including the Internet, intranets and other networks. Current versions of Internet Protocol such as Internet Protocol version-4 (“IPv4”) are becoming obsolete because of limited address space. With a 32-bit address-field, it is possible to assign 2
32
different addresses, which is 4,294,967,296, or greater than 4 billion globally unique addresses.
However, with the explosive growth of the Internet and intranets, Internet Protocol addresses using a 32-bit address-field may soon be exhausted. Internet Protocol version-6 (“IPv6”) proposes the use of a 128-bit address-field for Internet Protocol addresses. However, a large number of legacy networks including a large number of Internet subnets will still be using older versions for Internet Protocol with a 32-bit address space for many years to come. As is known in the art, a subnet is smaller of part of a larger network using a similar network addressing scheme.
Network Address Translation (“NAT”) has been proposed to extend the lifetime of Internet Protocol version 4 by allowing subnets with private Internet Protocol addresses to exist behind a single or small number of globally unique Internet Protocol addresses (see e.g., Internet Engineering Task Force (“ITEF”) RFC 2663, “IP Network Address Translator (“NAT”) Terminology and Considerations,” by P. Srisuresh and M. Holdrege, August 1999). Each private host uses a single global Internet Protocol address for communication with external networks such as the Internet.
Internally, a subnet may use local private addressing. Local private addressing may be any addressing scheme that is different from the public Internet Protocol addressing. The local addresses on a subnet are typically not available to the external, global Internet. When a device or node using local addressing desires to communicate with the external world, its local address is translated to a common external Internet Protocol address used for communication with an external network by a network address translation device. That is, network address translation allows one or more global Internet Protocol addresses to be shared among a larger number of two network devices using local private addresses.
There are several problems associated with using network address translation to extend the life of the Internet Protocol version-4. Network address translation interferes with the end-to-end routing principal of the Internet that recommends that packets flow end-to-end between network devices without changing the contents of any packet along a transmission route (see e.g., “Routing in the Internet,” by C. Huitema, Prentice Hall, 1995, ISBN 0-131-321-927).
Current versions of network address translation replace a local network address in a data packet header with an external global network address on outbound traffic, and replace an external global network address in a data packet header with a local private network address on inbound traffic. This type of address translation is computationally expensive, causes security problems by preventing certain types of encryption from being used, or breaks a number of existing applications in a network that cannot coexist with network address translation (e.g., File Transfer Protocol (“FTP”)).
Current versions of network address translation may not gracefully scale beyond a small subnet containing a few dozen nodes or devices because of the computational and other resources required. Network address translation potentially requires support for many different application layer internal network protocols be specifically programmed into a translation mechanism such as a network address translation router.
Computational burdens placed on a network address translation router may be significant and degrade network performance, especially if several network address translation-enabled sub-networks share the same network address translation router. In a worst case scenario, a network address translation router translates every inbound and data packet.
Application Layer Gateways (“ALG”) have also been used at a border between a private network and a public network like the Internet to provide address translation. As is known in the art, a gateway is a device that connects two networks using different communications protocols so that information can be passed from one to the other. A gateway both transfers information and converts it to a form compatible with the protocols used by a receiving network.
However, the Application Layer Gateways complicate the deployment of new applications. Sending and receiving systems need to support the new applications, and any Application Layer Gateways in a routing path must be able to identify new applications to provide network address translation.
Some of the problems associated with network address translation of private network addresses into public network addresses have been overcome with Distributed Network Address Translation (“DNAT”) described in co-pending application Ser. No. 09/035,600 (now U.S. Pat. No. 6,353,614), Ser. Nos. 09/270,967 and 09/271,025 (now U.S. Pat. No. 6,055,236), assigned to the same Assignee as the present application. See also “Distributed Network Address Translation”, by Michael Borella, David Grabelsky, Ikhlaq Sidhu, and Brian Petry, IETF Internet Draft, <draft-borella-aatn-dnat-01.txt>, October 1998. Distributed Network Address Translation is also called “Realm Specific Internet Protocol” (“RSIP”) by the IETF. For more information on Realm Specific Internet Protocol see “Realm Specific IP Framework,” by M. Borella and J. Lo, IETF draft, <draft-ieft-nat-rsip-framework-02.txt>, October 1999, and “Realm Specific IP: Protocol Specification,” by M. Borella and J. Lo, IETF draft, <draft-ietf-nat-rsip-protocol-02.txt>, August 1999.
For Distributed Network Address Translation or Realm Specific Internet Protocol, network devices request a set of locally unique ports from a Distributed Network Address Translation server or a Realm Specific Internet Protocol server for external communications with a public network like the Internet. A network device on a private network replaces default or ephemeral ports (e.g., such as Transmission Control Protocol or User Datagram Protocol) with the locally unique ports. The network device uses a combination network address including a locally unique port and a common external network address (e.g., an IP address) for the Distributed Network Address Translation server for communications with the external networks. The network devices use private network addresses for local communications on the private network.
A Distributed Network Address Translation server or a Realm Specific Internet Protocol server maintains a port-to-private network address table as locally unique ports are allocated to network devices. Network devices send data packets to external networks using a combination network address including a locally unique port and the common external network address via the Distributed Network Address Translation server or Realm Specific Internet Protocol server. For inbound data packets from an external network, the Distributed Network Address Translation server or Realm Specific Internet Protocol uses the port-to-private network address table to route data packets back to the appropriate network device on the private network.
Distributed Network Address Translation or Realm Specific Internet Protocol allows a host to tunnel data packets to/from a network device and a server over a virtual tunnel. As is known in the art, a “virtual tunnel” is created by encapsulating a data packet inside another data packet. The outer header typically identifies the “endpoints” of the tunnel. The inner header typically
Borella Michael S.
Grabelsky David
3Com Corporation
Cardone Jason D.
McDonnell & Boehnen Hulbert & Berghoff
LandOfFree
Method and system for dual-network address utilization does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for dual-network address utilization, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for dual-network address utilization will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3217648