1. Field of the Invention
The invention relates generally to network connectivity for guest entities existing on a shared host. More particularly, embodiments of the invention enable network connectivity for entities without implementing network address translation.
2. Background Art
There are several commercial virtualization environments such as VMWARE® and MICROSOFT® VITRUALPC®. These environments allow multiple guest entities running on a single host, wherein each guest entity can establish a network connection with the outside network and with other entities using an Internet Protocol (IP) or similar protocol. To support connectivity between entities, these environments typically assign one or more addresses to the entities, and resolve data transfers involving the entities via network address translation (NAT).
In a virtualized environment, NAT relies on the host machine having its own Media Access Control (MAC) and Internet Protocol (IP) addresses, usually assigned by a Dynamic Host Configuration Protocol (DHCP) server in the network. The host machine sets up its own internal network, wherein each guest entity may be assigned internal MAC and IP addresses. When a connection is needed to send a data packet from one guest entity to a target external to the host machine, the connection may be assigned to a port on the host to distinguish it from other connections. Before the packet is sent to the outside network, the internal MAC and IP addresses of the source entity may be replaced in the data packet with the MAC and IP addresses of the host, the checksum recalculated and the translation recorded in a translation table so that the return packet can be routed to the correct entity.
When a data packet is returned on a specific port, the packet's target may be looked up in a translation table and the internal MAC and IP addresses of the target entity are replaced in the data packet. After replacing the addresses, the checksum is again recalculated before forwarding the packet to its target entity. When a connection on the host is closed, the entry in the translation table is deleted. For connections solely between two entities residing on the host, data packets are forwarded without the need to modify the addresses or checksum value.
The NAT has several limitations. It has to fix addresses for each and every outbound or inbound data packet, and recalculate checksum accordingly. Usually the NAT in an internal network resides on the router, so its effect on the system performance is minimal. In a virtualized environment, however, it is implemented in software which runs on the host and consumes significant system resources. NAT also breaks some end-to-end protocols such as Virtual Private Network (VPN) tunnels that use the authentication header for verification. Furthermore, users of a guest entity will not be able to see or use their “real”, i.e. public, IP address for troubleshooting purposes.
When two (or more) guest entities use port routing to divide network traffic between them, each is assigned a range of ports and all traffic in that range is assigned to that guest entity. In port routing, packets from one guest entity cannot be sent to another guest entity since it will have the same MAC and IP in both the source and the target fields of its Ethernet header. This is called a loopback packet and some intermediate drivers will block such packets from going to the miniport, by reverting them to the network stack. This limits the capabilities of the system since, for example, if the service operating system (OS) has a web based configuration page, so one can configure the machine behavior with it, it will only be accessible from an external computer and not from the capability OS.
USPTO Backgrounds
USPTO Backgrounds