(12)
`
`United States Patent
`Alkhatib et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,421,732 B1
`Jul. 16, 2002
`
`US006421732B1
`
`(54) IPNET GATEWAY
`
`6,119,171 A * 9/2000 Alkhatib ................... .. 709/245
`6,122,276 A * 9/2000 Boe et a1. ................. .. 370/389
`
`
`
`Inventors: Hasan S_ Wootton, Palo Alto, both of C A (Us) Saratoga; Bruce (:I
`
`
`
`
`
`
`
`. . . .. 6,219,715 B1 * 4/2001 OhIlO 618.1. . . . . . . . . . 6,243,749 B1 * 6/2001 Sitaraman et a1. ........ .. 709/223
`
`(73) Assignee: IP Dynamics, Inc., Santa Clara, CA
`(US)
`
`( * ) NOIiCeI
`
`Subject I0 any disclaimer, the term Of this
`patent iS @Xtended 0r adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl, No; 09/167,709
`_
`(22) Flled:
`
`Oct‘ 6’ 1998
`
`_
`_
`_ Related U‘_S‘ Apphcatlon Data
`_
`(60) Provisional application No. 60/098,205, ?led on Aug. 27,
`1998-
`
`OTHER PUBLICATIONS
`RFC 1541; Dynamic Host Con?guration Protocol; R.
`Droms; pp. 1—34; Oct. 1993*
`Excerpts from the Help section of Microsoft Outlook per
`taining to rules and forwarding email. Microsoft Corpora
`tion.
`Computer Networks, Third Edition, by Andrew S. Tanen
`baum, 1996, pp. 643—670, 685—691.
`Inside Apple Ta1k®, Second Edition, by G. Sidhu, R.
`Andrews, A. Oppenheimer, 1990.
`RFC 1631, The IP Network Address Translator NAT , K.
`Egevang and P. Francis, May 1994.
`(
`)
`
`* cited by examiner
`
`(51) Int. Cl.7 .............................................. .. G06F 13/00
`(52) U-S- Cl- --------------- --
`709/245; 709/227
`(58) Field of Search ................................ .. 709/245, 227
`
`Primary Examiner_Kenneth R_ Conner
`(74) Attorney, Agent, or Firm—Vierra Magen Marcus
`Harmon & DeNiro LLP
`
`(56)
`
`References Cited
`
`(57)
`
`ABSTRACT
`
`U_S_ PATENT DOCUMENTS
`
`5,361,256 A 11/1994 Doeringer et a1. ........ .. 370/390
`5,623,605 A
`4/1997 Ke_shav et a1‘
`709/236
`2
`et a1‘
`370054
`7/1998
`5:777:989 A
`370/401
`7/1998 Templin et a1_ ____ __
`5,781,550 A
`370/401
`8/1998 Sistanizadeh et a1_
`5,790,548 A
`709/224
`9/1998 Perlrnan et a1, ,,,, __
`5,805,818 A
`709/225
`9/1998 Bellovin et a1. ..
`5,805,820 A
`1/ 1999 Gelvais et a1
`5,856,974 A
`-- 370/392
`2/1999 Butman et al- ~~~~~~~~~~~ ~~ 709/249
`578677667 A
`5,884,038 A * 3/1999 Kapoor """"""""""" " 709/226
`5’884’246 A
`3/1999 Boucher et a1‘ "
`"" " 704/2
`5,889,953 A
`3/1999 Thebaut et a1.
`709/221
`5,913,210 A
`6/1999 can _ _ _ _ _ _ _ _ _ _ _ _ _
`_ _ _ _ _ " 707/4
`5,937,162 A
`8/1999 Funk et a1. ............... .. 709/206
`5,937,163 A
`8/1999 Lee et a1. ................. .. 709/218
`6,003,084 A 12/1999 Green et a1. .............. .. 709/227
`
`The IPNet Gateway (IPNGw) is a new technology that maps
`multiple servers on a private IP network to a single IP
`address on the Internet' AS requests Come in for DNS
`resolution of the server’s domain name, the IPNet Gateway
`records the domain of the requesting client and the name of
`the requested server, and returns its own address as the
`destination address for the requested domain name. This
`DNS response is set as non-cacheable to prevent the asso
`ciation between the IPNGw IP address and the domain name
`of the target server beyond the anticipated following trans
`action from the client. As soon as the IPNGw responds to the
`DNS request it enters into a waiting state anticipating a
`connection from the client to the speci?c server identi?ed in
`the DNS request. Subsequently, the client establishes a
`.
`.
`.
`.
`connection with the IPNGw, WhlCh in turn relays the con
`nectlon request to the 569'“
`
`38 Claims, 4 Drawing Sheets
`
`Slate
`1
`incoming
`wailing for an
`DNS Reques1
`
`Corinzctiwn
`Timeout
`
`Cumpletsd Sewer
`cam-mm la 0
`
`DNS Requesi
`
`Connection
`11mm
`
`DNS Request
`iimmui
`
`nus Reques1
`Fmm Same
`N Mark
`B
`.
`Dmpped
`
`Stats 2
`
`nnnnn on
`
`Donnen'un
`Fmm
`umeieni
`Host
`
`State 4
`Making Painter Reques1
`
`DNS Request
`mm Same
`Neiwoik,
`Dnwwd
`
`Connection
`From Same
`Hos!
`
`Slat: 3
`Making Server Connection
`
`Receive
`
`Rsspnnse
`
`sign; 5
`Making Aumurily
`Request
`
`nus Request
`Fmm Sama Nelwclk
`Dmpped
`
`Stale Diagram In! lF'Nel Galeway Connection Esiahlishmenl
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 1
`
`

`
`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 1 0f 4
`
`US 6,421,732 B1
`
`A DNS Sewer
`205.179.62.113
`
`205.179.62.117
`B Requesting Client
`
`C lPNGw
`205.79.62.11
`
`10.1.1.1
`
`Internet
`
`’ """""""""""" $1,051; N'étkék' ' ' "
`
`10.1.1.112
`
`D Server srvr.ttcinc.com
`
`lPNet Gateway Based on Client/Server Network
`
`FIG. I
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 2
`
`

`
`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 2 0f 4
`
`US 6,421,732 B1
`
`B(Client)
`
`A(Client DNS)
`
`Dtserverl
`
`F(|PNGw DNS)
`
`6)
`
`Use IP Network Matching to determine if
`another server from the same network is
`already in the DNSTabel. If so, discard
`DNS request. Othenivise go to 2.
`
`DNS request, "D=?"
`
`DNS ReEiPO"Se
`“D=205.79.62.112
`
`DNS Response. “
`'D=205.79.62.112
`
`TCP Connect
`"205.179.62.1 17 to
`205. 79.62. 1 1 "
`
`@
`
`Use IP Address Matching to determine if an
`entry in DNSTable is from the same network.
`If so, go to 3. Otherwise, continue.
`
`DNS Request
`Pointer Lookup
`"205.179.62. 1 17"
`
`DNS Respoilse _
`"205.179.62.117" is B
`
`DNS Response ‘
`B has authority list L
`
`Use Authority Matching to determine if an entry
`in the DNSTable has the same Authorities as
`the return list L. If not, drop connection and
`go to 1. If so, continue.
`
`(9
`
`IPNet Gateway Timing Diagram
`Client Using a Recursive DNS Server
`FIG. 2
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 3
`
`

`
`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 3 0f 4
`
`US 6,421,732 B1
`
`State 1
`Waiting for an incoming
`DNS Request
`
`Connection
`Timeout
`
`Completed Sewer
`Connection to D
`
`DNS Request
`Timeout
`
`Connection
`'?meout
`
`DNS Request
`
`>
`DNS Request
`From Same
`Network,
`Dropped
`
`State 2
`waiting For Ghent
`Connection
`
`Connection
`State 4
`From
`Making Pointer Request
`Different \_
`Host
`
`DNS Request
`From Same
`Network,
`Dropped
`
`Pointer Response
`
`Connection
`Timeout
`
`Connection
`From Same
`Host
`
`State 3
`Making Sewer Connection
`
`Receive
`Authority
`Response
`
`State 5
`Making Authority
`Request
`
`DNS Request
`From Same Network,
`Dropped
`
`State Diagram for lPNet Gateway Connection Establishment
`
`FIG. 3
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 4
`
`

`
`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 4 0f 4
`
`US 6,421,732 B1
`
`lPNetGateway
`
`Server
`
`\ I
`
`Client Issues dns request
`
`I
`
`"/ff- with own address
`
`lPNetGateway responds __._
`
`\ Client issues https request to
`
`lPNetGateway \
`
`lPNetGateway responds with an
`http redirect to an unused port "
`number. Listens for connect on
`this port.
`
`‘\ Client re-issues https request to
`lPNetGateway on new port \‘
`
`lPNetGateway forwards all
`requests from that port to the
`sewer speci?ed in the original
`dns request
`
`FIG. 4
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 5
`
`

`
`US 6,421,732 B1
`
`1
`IPNET GATEWAY
`
`This Application claims the bene?t of US. Provisional
`Application No. 60/098,205, IPNet Gateway, by Hasan
`Alkhatib and Bruce Wootton, ?led on Aug. 27, 1998.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention is directed to a system for alloWing
`the mapping of multiple entities on a netWork to a single
`address.
`2. Description of the Related Art
`Most machines on the Internet use TCP/IP (Transmission
`Control Protocol/Internet Protocol) to send data to other
`machines on the Internet. To transmit data from a source to
`a destination, the Internet protocol (IP) uses an IP address.
`The Internet protocol has been in use for over tWo decades
`and has Worked Well, as demonstrated by the exponential
`groWth of the Internet. Unfortunately, the Internet is rapidly
`becoming a victim of its oWn popularity. It is running out of
`addresses. Therefore, a system is needed that can effectively
`alleviate the diminishing IP addresses problem.
`
`SUMMARY OF THE INVENTION
`
`The IPNet GateWay (IPNGW) is a neW technology that
`maps multiple servers on a private IP netWork to a single IP
`address on the Internet. The servers are referenced uniquely
`using their Internet domain names. The IPNet GateWay
`offers a solution to the Internet IP address shortage problem.
`It is also being considered as the basis for a secure ?reWall
`design.
`As requests come in for DNS resolution of the server’s
`domain name, the IPNet GateWay records the domain of the
`requesting client and the name of the requested server, and
`returns its oWn address as the destination address for the
`requested domain name. This DNS response is set as non
`cacheable to prevent the association betWeen the IPNGW IP
`address and the domain name of the target server beyond the
`anticipated folloWing transaction from the client. As soon as
`the IPNGW responds to the DNS request it enters into a
`Waiting state anticipating a connection from the client to the
`speci?c server identi?ed in the DNS request. Subsequently,
`the client establishes a connection With the IPNGW, Which in
`turn relays the connection request to the server.
`These and other objects and advantages of the invention
`Will appear more clearly from the folloWing detailed
`description in Which the preferred embodiment of the inven
`tion has been set forth in conjunction With the draWings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram Which depicts an IPNet Gate
`Way and various other entities.
`FIG. 2 is a timing diagram Which describes the operation
`of the IPNet GateWay.
`FIG. 3 is a state diagram for the IPNet GateWay.
`FIG. 4 illustrates the operation of the IPNet GateWay With
`the HTTP protocol.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`DETAILED DESCRIPTION
`
`For a server to become visible on the Internet it has to
`have a unique domain name. It does not need a globally
`unique IP address. Instead, it is assigned a local IP address.
`To alloW access to such a server in a private IP netWork by
`clients on the Internet, a client application has to reference
`
`2
`the server by its domain name. Since the server does not
`have a globally unique IP address corresponding to its
`domain name, no DNS server on the Internet Will have an
`entry for this server’s domain name. The IPNGW is desig
`nated as the DNS authority for such servers in its private IP
`netWork. As a result, the server’s IPNGW Will intercept
`every DNS resolution request for the server domain name.
`As requests come in for DNS resolution of the server’s
`domain name, the IPNGW records the domain of the request
`ing client and the name of the requested server, and returns
`its oWn address as the destination address for the requested
`domain name. This DNS response is set as non-cacheable to
`prevent the association betWeen the IPNGW IP address and
`the domain name of the target server beyond the anticipated
`folloWing transaction from the client. As soon as the IPNGW
`responds to the DNS request it enters into a Waiting state
`anticipating a connection from the client to the speci?c
`server identi?ed in the DNS request. Subsequently, the client
`establishes a connection With the IPNGW, Which in turn
`relays the connection request to the server.
`If the connection made by the client is a TCP connection,
`it is established, maintained and tracked by the IPNGW until
`it is disconnected. During a TCP connection, the IPNGW
`acts as a packet relay on behalf of the client in the Internet
`and the server in the private IP netWork.
`If the packet received from the client is not for a TCP
`connection, such as the case With UDP and ICMP packets,
`the packet is relayed to the server and the IPNGW eXits the
`Waiting state. This action forces the client to make a DNS
`request With every packet that it needs to deliver to the
`server in the private IP netWork.
`Some applications cache the IP address obtained after a
`DNS request and reuse it With multiple TCP connections to
`the same server. In general, the IPNGW Will fail to relay
`packets of the neW connection to the server. This forces the
`application to request a neW DNS resolution for the domain
`name of the target server in the private IP netWork. Each
`application that caches IP addresses and reuses them With
`subsequent TCP connections Will require special treatment
`and the employment of an application speci?c proXy in the
`IPNet GateWay.
`Of particular interest from applications that cache IP
`addresses after DNS requests are Web broWsers. Since Web
`broWsers employ HTTP, and since HTTP includes the
`domain name string of its destination node, the IPNGW
`extracts the domain name of the destination server from the
`HTTP header received With every HTTP packet. Therefore,
`HTTP packets can be relayed from the client to the server
`directly, even if the client caches the IP address received
`from the IPNGW after DNS resolution requests. A special
`proXy server is required for the FTP application.
`FIG. 1 is a block diagram that can be used to illustrate the
`operation protocols designed for the IPNet GateWay. For
`eXample purposes, assume Host A at 205.179.62.113 is the
`DNS server for the client subnet, and Host B at
`205.179.62.117 is the requesting client. Also, Host C at
`205.79.62.11 is the IPNGW and Host D at 10.1.1.112 is the
`server using a private IP address in the private netWork and
`a global domain name ‘srvr.ttcinc.com’.
`The folloWing set of events Will occur if A is a non
`recursive DNS server:
`(1) B requests srvr.ttcinc.com (i.e. D’s) IP address from A.
`(2) A refers B to C as the designated DNS authority for
`srvr.ttcinc.com.
`(3) B requests D’s address from C.
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 6
`
`

`
`US 6,421,732 B1
`
`3
`(4) C records B’s IP address and domain as Well as D’s
`domain name (srvr.ttcinc.com) as the destination. C
`returns its oWn address as the destination address to D.
`C enters into a Waiting state for a connection request
`from B. During this period C Will block from accepting
`any neW DNS requests from B’s domain and IP net
`Work.
`(5) B sends C a request to establish a connection.
`(6) C accepts B’s connection, and checks if B is the same
`node that requested the DNS resolution to srvr.ttcinc
`.com (i.e. D). Since this is the case in this example, then
`C associates the request With the server D. It removes
`the record from the IPNGW’s table to alloW neW
`connection requests from B’s domain and IP netWork.
`(7) C forWards the requests for the connection from B on
`to D and returns responses from D back to B acting as
`a packet relay.
`(8) B ?nishes session With D, shuts doWn connection With
`C. C shuts doWn connection With D.
`If A is a recursive DNS server, the following sequence of
`events is expected:
`(1) B requests srvr.ttcinc.com (i.e. D’s) IP address from A.
`(2) A requests D’s address from C.
`(3) C records B’s IP address and domain as Well as D’s
`domain name (srvr.ttcinc.com) as the destination. C
`returns its oWn address as the destination address to D.
`C enters into a Waiting state for a connection request
`from B. During this period C Will block from accepting
`any neW DNS requests from B’s domain and IP net
`Work.
`(4) A returns C’s IP address as the address for srvr.ttcinc
`.com to B.
`(5) B sends C a request to establish a connection.
`(6) C accepts B’s connection, and ?nds B’s domain. It
`?nds that B’s domain is the same as A’s and thus
`associates the request With the server D. It removes the
`record from the IPNGW’s table to alloW neW connec
`tion requests from B’s domain and IP netWork.
`(7) C forWards the requests for the connection from B on
`to D and returns responses from D back to B acting as
`a packet relay.
`(8) B ?nishes session With D, shuts doWn connection With
`C. C shuts doWn connection With D.
`The IPNGW uses DNS requests to match client connec
`tion requests to private IP netWork servers. A client may
`make a DNS request directly or through a recursive DNS
`server. It is assumed that the client makes recursive DNS
`requests from a DNS server that has the same authority
`listings as the client. It can be checked to see that clients and
`DNS servers are in the same domain using tWo different
`tests: IP NetWork Matching and DNS Authority Matching.
`In IP NetWork Matching, the IP addresses of the tWo hosts
`are masked based on the netWork class. Class AIP addresses
`are masked With 255.00.00.00, class B IP addresses are
`masked With 255 .255 .0.0 and class C addresses are masked
`With 255.255 .255 .0. If the masked addresses are equal, there
`is a match.
`In DNS Authority Matching, the DNS authorities are
`found for the hosts With the tWo IP addresses. This requires
`tWo steps. First, each hosts IP address is resolved to a
`domain name via the “Pointer” DNS request. Second, the
`authorities of the tWo hostnames are found using the “A”
`DNS request Which returns both the IP address and the
`authorities for a given set of hosts. If the tWo hosts have
`overlapping authority records, there is a match.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`Using the above tWo tests, a method can be used to decide
`Where or if We should route a connection. To keep track of
`the state of the potential connections, there are a number of
`tables. The DNSTable keeps track of pending DNS requests.
`The PendingTable keeps track of pending connections.
`There is also a StaticAddressTable Which tells Which hidden
`server addresses are attached to Which domain names.
`typedef struct sdNSTableEntry
`
`int valid;
`struct iniaddr requestingAddress;/*A’s addr in our
`example */
`struct iniaddr forWardingAddress;/*D’s addr in our
`example */
`short ttl;
`} sDNSTableEntry;
`typedef struct spendingTableEntry
`
`struct iniaddr requestingAddress;/*B’s addr in our
`example */
`uishort requestedPort;
`int sdRequestingSocket;
`short ttl;
`unsigned short usMessageID;
`int valid;
`} sPendingTableEntry;
`The basic method, Which is a loop that Waits for connec
`tions and DNS requests, is described by the pseudo-code
`beloW.
`InitialiZe tables;
`While (true)
`
`Listen for data on all sockets;
`if (data is a DNS request)
`
`?nd the local address of the requested server;
`if (requested server cannot be found locally) send
`back “Host does not exist” DNS response;
`
`else
`
`if (DNS table has another pending request from same
`netWork) drop DNS request;
`
`else
`
`add local address of requested server to DNS table;
`add global address of requesting server to DNS table;
`send back IPNGW address in the DNS response;
`
`else if (data is a neW connection request)
`
`add connection information to connection pending
`table;
`send out DNS request to ?nd out the DNS authority for
`the connecting host;
`
`}
`else if (data is a DNS response)
`
`?nd the pending connection request that generated the
`DNS response;
`?nd the entry in the DNS request table that has the same
`requesting address of the returned authority or the
`same requesting address as the host generating the
`connection request;
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 7
`
`

`
`US 6,421,732 B1
`
`5
`remove the DNS request table entry;
`remove the pending connection table entry;
`complete the connection to the local hidden server
`found in the DNS request table.
`
`else if (data is on current connection) forWard data along
`the connection
`
`Note that time-outs are included in each table entry so that
`old requests are dropped from consideration after a reason
`able Wait.
`IPNGW routing decisions are based on matches With
`entries in the tWo state tables listed above. The IPNGW uses
`both IP Network Matching and DNS Authority Matching at
`different times during the method. The timing diagram of
`FIG. 2 outlines the relevant connections and decisions made
`While routing a connection. In step 1, a DNS request is made
`to the IPNGW. The IPNGW uses IPNetWork Matching to
`determine if another server from the same netWork is already
`in the DNSTable. If so, discard the DNS request. OtherWise,
`proceed to step 2. In step 2, the IPNGW responds to the DNS
`request With its oWn IP address. In step 2A, a TCP Connect
`request is made. The IPNGW Will determine if an entry in the
`DNSTable is from the same netWork. If so, proceed to step
`3; otherWise, proceed to step 4. In step 3, a TCP connection
`is established. In step 4, the IPNGW Will perform a DNS
`Pointer lookup and receive an appropriate response. In step
`5, the IPNGW Will perform a DNS request and receive an
`appropriate response. The IPNGW Will use DNS Authority
`Matching to determine if an entry in the DNSTable has the
`same Authorities as the return list A. If not, drop the
`connection and go to step 1; if so, continue to step 3.
`The timing diagram of FIG. 2 shoWs that there are tWo
`phases When neW connection requests Will be denied. First,
`When a DNS request has been made from the same domain
`and no connection has been established and second, When a
`connection has been established and an authority lookup is
`taking place on the connection. Experience shoWs that the
`?rst phase is a very small time period (<1 second) and the
`second phase is someWhat longer (2—6 sec). Connection
`requests from other processes or servers in the domain are
`deferred until the ?rst connection is established or times out.
`FIG. 3 is a state diagram formaliZing the functional
`behavior of the IPNet GateWay for establishing connections
`to servers in a private netWork from clients on the Internet.
`State 1 includes Waiting for an incoming DNS request. State
`2 includes Waiting for a client connection. State 3 includes
`making a server connection. State 4 includes making a
`pointer request. State 5 includes making an authority
`request.
`The IPNet GateWay should have a similar performance to
`other NAT gateWays. Fundamentally, similar operations
`must be performed: a lookup in the routing table of the IPNet
`GateWay folloWed by a Write to the packet header and a
`checksum calculation. HoWever, there is also a performance
`penalty at time of initial connection as established above.
`Basically, each connection must be preceded by 3 DNS
`lookups. Although average lookup time is less than a second
`Within geographical areas, it may Well run multiple seconds
`across continents. Considering that only one connection
`request can be entertained at once, and average time of cross
`continental lookups is 4 seconds. There is a functional limit
`of connections/day from a single domain of
`3 dns lookups*4 seconds=12 seconds/connection (5
`connections/minute)
`5 connections/minute*60 minutes/hour*24 hours/day=
`our minimum connection rate from a given domain is
`7200 connects/day
`
`6
`There are a number of general limitations on the IPNGW
`system. Only one connection request can be accepted from
`a given domain at a time. Because the original DNS request
`may have come from a DNS server instead of the requesting
`computer, there cannot be more than one DNS request
`entertained from the same domain. OtherWise, the request
`ing client Will be ambiguous and a connection may be routed
`to the Wrong server. This constraint lasts until the connection
`is established. At this point, the original request Will be
`removed from the list of pending connections and neW
`requests from the domain Will be entertained. Experimen
`tation has shoWn that the time for connection establishment
`is approximately 4 seconds (dependent on distance and
`traffic). In general, locked out requests Will be dropped
`instead of being explicitly denied so that the locked out
`client Will have another chance to connect When their DNS
`retries. In this case, the only noticeable change in service
`Would be a momentary sloWness during DNS resolution.
`HoWever, if many clients are trying to establish connections
`from the same domain at the same time, it is possible that
`some of these clients Will time-out before a connection slot
`becomes available.
`It is important to note that the total number of simulta
`neous connections is not constrained: only the total number
`of simultaneous neW connections is constrained.
`All connections from a client to a server must be preceded
`by a DNS request. If a client does not make a DNS request
`prior to each connection, the IPNGW Will be unable to
`determine the true destination of the request. If the client
`softWare caches the IP address of the server for use With
`multiple connections, the IPNGW Will generally be unable to
`service the connections. In some cases (notably HTTP) the
`data sent on the connection can be examined to determine its
`destination, but in other cases (particularly S-HTTP and
`most ICMP and UDP services) there is no Way to determine
`the destination of all but the ?rst packet.
`The requesting client must have a valid global name in the
`Domain Name System. A client’s destination is determined
`by associating it With a Domain. This is because a DNS
`server in the client’s domain instead of the client may make
`the DNS request to the IPNGW. If the client’s IP address is
`not reverse query-able, the domain that the client is in cannot
`be determined. In cases Where the client originates the DNS
`request or the recursive DNS server is in the same IP
`netWork of the client, the IPNet GateWay is able to deal With
`the client Without having to have its domain name.
`Anumber of protocols Were examined to determine Which
`protocols can be used directly With IPNGW and Which can
`be used in a specially devised proxy. The folloWing table
`summariZes the ?ndings. Those entries that have One
`Connection/DNS Will Work With the IPNGW unmodi?ed. In
`general, the table has been compiled by observing the
`standard implementations of the clients listed. This means
`that some clients may con?ict With the standard implemen
`tation.
`
`15
`
`25
`
`35
`
`45
`
`55
`
`Application/Protocol
`
`HTTP
`JAVA, HTML etc.
`Telnet
`FTP
`
`65
`
`SMTP
`
`Method With Which application
`is handled
`
`Use HTML Redirect Method
`Travel over HTTP (see above)
`One Connection/DNS
`One Connection From Client to
`Server/DNS . Multiple from Server
`to Client
`One Connection/DNS
`
`Microsoft v. Parallel Networks, IPR2015-00483 and IPR2015-00485
`Petitioner Microsoft Corporation - Ex. 1091, p. 8
`
`

`
`US
`6,421,732 B1
`
`7
`
`-continued
`
`Application/Protocol
`
`POP3
`IMAP 4
`Ping
`Trace-Route
`Real Audio/Video
`
`X-WindoWs
`Use HTML Redirect Method
`
`Method With Which application
`is handled
`
`One Connection/DNS
`One Connection/DNS
`One DNS, many packets
`One DNS, many packets
`can be set to receive through TCP or
`HITP only (bypassing UDP)
`One Connection/DNS
`
`8
`responding to said ?rst address request, including provid
`ing a ?rst address that is not unique to said ?rst entity
`Within said netWork;
`receiving a request for communication With said ?rst
`entity, said request for communication is from a second
`entity; and
`establishing communication betWeen said ?rst entity and
`said second entity if said second entity caused said ?rst
`address request.
`2. A method according to claim 1, Wherein:
`said ?rst address request is a DNS request.
`3. A method according to claim 1, Wherein:
`said step of receiving a request for communication
`includes receiving a request for a TCP connection.
`4. A method according to claim 1, Wherein:
`said step of receiving a request for communication
`includes receiving a UDP packet.
`5. A method according to claim 1, Wherein:
`said step of establishing communication includes estab
`lishing a TCP connection.
`6. A method according to claim 1, Wherein:
`said step of establishing communication includes relaying
`a UDP packet.
`7. A method according to claim 1, Wherein:
`said step of establishing communication includes estab
`lishing a SMTP connection.
`8. A method according to claim 1, Wherein:
`said step of establishing communication includes estab
`lishing a FTP connection.
`9. A method according to claim 1, Wherein:
`said step of receiving a ?rst address request includes
`receiving a DNS request from a DNS server;
`said ?rst address is an IP address for a gateWay; and
`said second entity caused said ?rst address request if said
`second entity requested said ?rst entity’s address from
`said DNS server.
`10. A method according to claim 9, Wherein:
`said step of establishing communication includes deter
`mining Whether said second entity has said DNS server
`as a DNS authority.
`11. A method according to claim 10, Wherein:
`said step of determining Whether said second entity has
`said DNS server as a DNS authority includes sending
`a DNS request to determine said second entity’s DNS
`authority.
`12. A method according to claim 10 Wherein:
`said step of receiving a request for a communication
`includes receiving a requesting address;
`said step of determining Whether said second entity has
`said DNS server as a DNS authority includes sending
`a DNS request for an “A” type record based on said
`requesting address, receiving a response to said DNS
`request for an “A” type record and sending a DNS
`request for a pointer type record based on said response
`to said DNS request for an “A” type record.
`13. A method according to claim 9, Wherein:
`said request for communication originated from said
`second entity; and
`said step of establishing communication includes com
`paring said second entity’s address to said DNS serv
`er’s address.
`14. A method according to claim 1, Wherein:
`said ?rst address request is generated by a source having
`a source address;
`
`In most cases, the protocols listed use the standard One
`connection/DNS. Of those that don’t, three are of interest.
`Although the HTTP protocol does not use a one
`connection/DNS paradigm in its popular clients, routing can
`still be done on the HTTP requests by using HTML redi
`rection. The basic idea in HTML redirection is that HTML
`requests at the knoWn HTML port (usually port 80) can be
`re-directed to an arbitrary port at the time of receipt. The
`redirection can be driven using the normal IPNet Gateway
`approach: looking at the requested DNS entry. Subsequent
`requests to the same server from the same client Will default
`to same (cached) port so neW requests to the server from the
`same client can be tracked by the redirected port number.
`FIG. 4 illustrates the procedure. In step 10, a client issues a
`DNS request. In step 12, the IPNGW responds With its oWn
`address. In step 14, the client issues an HTTP request to the
`IPNGW. In step 16, the IPNGW responds With an HTTP
`redirect to an unused port number. The IPNGW listens for a
`connect on this port. In step 18, the client re-issues the HTTP
`request to the IPNGW on the neW port. In step 20, the
`IPNGW forwards all requests from that port to the server
`speci?ed in the original DNS request.
`In general, the UDP and ICMP utilities (ping, traceroute,
`etc. .
`.
`. ) do not make a DNS request for each packet sent.
`Because UDP and ICMP are connection-less, speci?c pack
`ets cannot be assigned to speci?c established connections. It
`is possible to track connections on a case by case basis if
`some sort of destination or stream ID is located in the packet.
`A separate module Would need to be made for each tracked
`packet.
`FTP makes a single connection from the client to the
`server folloWed by multiple connections from the server to
`the client. In general, the servers are understood to be routed
`through classical NetWork Address Translation, and can
`therefore make multiple connections back to the client.
`The foregoing detailed description of the invention has
`been presented for purposes of illustration and description.
`It is not intended to be exhaustive or to limit the invention
`to the precise form disclosed. Many modi?cations and
`variations are possible in light of the above teaching. The
`described embodiments Were chosen in order to best explain
`the principles of the invention and its practical application to
`thereby enable others skilled in the art to best utiliZe the
`invention in various embodiments and With various modi
`?cations as are suited to the particular use contemplated. It
`is intended that the scope of the invention be de?ned by the
`claims appended hereto.
`We claim:
`1. A method for establishing communication With a ?rst
`entity inside a netWork, comprising the steps of:
`receiving a ?rst address request originating from outside
`said netWork, said ?rst address request includes a
`request for an a