Authorization by domain name
The NBER likes to authorize entire university campuses and corporations for access to full text downloads of working papers. We don't want users to have to remember login ids or passwords. We want to encourage usage. So most authorizations are based on the domain name of the computer used to access our web site. For example, we can put ``ibm.com'' into our authorization database, so that all computers within the ibm.com domain will be recognized as such and offered full text downloads without any action by the user. You may be surprised to learn that we don't automatically know the domain name for computers accessing our web site. What we do know is the the numeric IP address of the client computer. This is a number of the form nnn.nnn.nnn.nnn (called a ``dotted quad'' in network-speak). For example, one computer's address is 188.8.131.52. Our server can take this number and ask one of the "root servers" who owns that number. We can then issue a request to the nameserver on that network to identify the domain name of that specific computer. A request of that nature is called a ``reverse name lookup'' (RNL) and is a standard part of the networking protocol. It should be completed in a fraction of a second.
With functioning reverse name lookup, users never have to concern themselves with authorization administration. It is all transparent and automatic. Also, we can handle all changes of IP adresses without updating our database, because the new IP address will still resolve to a host name in the authorized domain. With only network numbers, we would have to get the new numeric address.
Many networks do not implement reverse name lookups, and do not respond to such requests. Select here for a reverse name lookup test of your computer. If it doesn't tell you the name of your computer, (in the "Host Name:" field) then you don't have reverse name lookup.
Authorization by network number
If your network doesn't support RNL, there is an alternative: we can put the complete range of numeric internet addresses in our authorization file. Then we can authorize your site from the numeric address, which accompanies every request for a web page.
One disadvantage to this is that most users don't know their IP address, and very few know the range of addresses for their campus. This can be overcome with a bit of information obtained from the user's network administrator or a bit of detective work done here.
The range of addresses assigned to a particular network can be expressed in any of three ways:
You may have noticed something in your network setup starting with one or more 255's. That isn't a network number; it is your network mask. We only in that in the case of a network number (the first case above).
Your campus may have IP addresses in several discontinuous ranges, and your department administrator may only know those for your department. His contact at the central campus network will have a complete list. We want to include the entire campus.
I have run into a few network administrators who claim that it improves security to turn off reverse name lookup. I disagree, and can point to the many very high security sites that do follow this protocol, including the IMF, the Federal Reserve, and IBM.
At many sites, reverse name lookup is incorrectly implemented for at least some of the computers. For example, an alias may be returned instead of the correct name. If the alias does not include the true domain name, authorization will fail.
An additional complication arises from firewalls and proxies, which may substitute their own IP address for the the address of the host. In this case we need the IP address or host name for the firewall or proxy itself, not the address of your machine behind the firewall. The firewall address is the public face of your network. It hides the private IP addresses from public view, but it is not in itself private. Indeed, if the proxy address were private, our web server would have no way of sending replies to queries. Even when a site has a proxy, I try to put the entire network range into our database, so that if a new proxy is installed the IP address is likely to already be in our database.
You can find an IP address for any Windows computer with the `winipcfg' command, but watch out. If the address is in the 192.168.*.* or 10.*.*.* ranges, it is a private address that is valid only within your network. All your requests are handled through a proxy server with a valid public Internet address. The proxy server address is the one we need.
A recent innovation in ISP operation has the ISP cache web pages with a so-called ``transparent cache engine''. It is transparent to the user, but intercepts all traffic from the user's computer to the web port on other hosts. So while users thinks they have sent a request to our machine, the engine intercepts it, and tries to fullfill the request from it's own memory. Only if the page is not available in memory is the request forwarded to our web server. This cache may be shared by multiple customers, some of whom are NBER suscribers and some not. In any case, we would only see the IP address of the ISP cache engine, and would not authorize a download. In most cases we can determine the doamin of the originating request through the "Via" header the cache engine should include with its request. This procedure is new to us (and to most cache engine administrators) and there are probably still some bugs to work out.
(Probably) not a problem
Your network administrator may tell you that your IP address is assigned from a pool, and he can't tell you which one you will have on any given day. This is not a problem if the addresses are assigned from a pool belonging to your institution. We will just put the entire range of addresses in our authorization file. Since we only sell site subscriptions, that would be our preference in any case.
If the pool of addresses is maintained by your ISP and covers multiple customers, that would be a problem. That is quite rare, however, except for very small institutions.
If your network administrator won't help
It is common for users to tell me that they do not have the required information, and that their network administrator will not help them. We can get around this, although users must first affirm that they have asked their network administrator to help, and been ignored or turned down. Here is the procedure:
Please send me the IP address and host name from the table below and I will attempt to look up the network address range on the various Internic ``whois'' servers. This will work for many subscribers, but not if your ISP hasn't registered your network as a separate entity. So please try to pry the information out of your network administrator.
I am always available to discuss this matter with your network administrator, should they have any questions. My email address is feenberg at nber dot org. My phone number is 617-588-0343.
If you need a particular paper ASAP, be sure to include the working paper number with your initial message.