Paul Stainthorp Schrödinger's cataloguer

This post follows on from my earlier authentication rant – here’s where I try and get a bit more constructive. Starting with the fundamentals:

IP authentication to electronic library resources… ‘s easy, innit? Nothing to worry about. We just give the details of our IP ranges to publishers, and they allow any computer with an address within that range (i.e., one of our on-campus computers or a mobile device connected via our wifi network) to access site content which is otherwise restricted: for example, a full-text PDF journal article.

Some notes:

(Thank you to Elif Varol for chasing down some of these details across the Internet, and to @aekins and others who supplied their expertise via Twitter and email.)

1. There are a few different ways of expressing IP ranges (‘notations’); a publisher may specify we give them our IP range(s) using a particular notation:
   • The standard dotted quad notation a.k.a. dot-decimal notation, made up of four eight-bit numbers (octets), generally expressed as decimal numbers, separated by full stops:
     • Full range e.g. 204.245.240.0-204.245.240.255
     • Range within the last octet e.g. 204.245.240.0-255
     • Wild card within the last octet e.g. 204.245.240.* (N.B. these first three are all equivalent to each other.)
     • Ranges and wild cards within higher octets e.g. 204.245.[8-11].* (The square brackets aren’t always necessary.) Some publishers will not accept these more complex ways of expressing ranges, so we have to list each range separately using wild cards only in the last octet, i.e. 204.245.8.*; 204.245.9.*; 204.245.10.*; etc.
   • CIDR notation (much less frequently asked for):
     • e.g. 204.245.8.0/22 (Where /22 represents the number of most significant bits—i.e. counting from the left—which are common to both the top and bottom ends of the IP range. I’ve not expressed that very well, but that’s how my brain deals with it! In the above example, the range: 204.245.8.0-204.245.11.255 expressed in binary is: 11001100.11110101.00001000.00000000-11001100.11110101.00001011.11111111 (You can see that the 22 most significant bits [in red] are common to the top and bottom addresses of the range. There’s a useful IP-range-to-CIDR converter tool at: ip2cidr.com)
2. But is it safe to hand out the details of our IP address ranges like this? I’ve certainly seen one ICT colleague’s eyelid twitch when I’ve mentioned this is what libraries do (and have been doing so for ages).
3. Some university libraries route all of their web traffic through a small number of proxy servers, so that all users broadcast a handful of individual IP addresses – this reduces the complexity of the information they need to give out to publishers. Apparently (though no-one appears to want to give me a list), the University of Lincoln now has a single ‘apparent‘ external IP address for each University building (i.e. some 45+ buildings, not including agricultural buildings) and one for each wifi network. This ought to make it possible to associate usage with an individual building or group of buildings. Does anyone do this? Strikes me it would be very useful to be able to say, for instance, “X% of usage of ScienceDirect comes from within our Science building”. We have at least one resource where usage is restricted to within libraries only – luckily, we do know the ‘apparent’ IPs of our own buildings.
4. Any change to a library’s IP addresses will have to be communicated to a large number of publishers. We have in our ERM spreadsheet an (almost-certainly incomplete) list of publishers who hold our IP ranges along with their contact details, so that we know who to inform if there’s a change… but this process worries me; it’s asking to have errors and inconsistencies introduced. I’d much rather register or publicise my IP ranges once and centrally (on the University’s own servers, or via a shared registry service like OCLC’s WorldCat Registry) and have all publishers pick them up from there.
5. The vast majority of IP-authenticated resources perform this authentication automatically, but a tiny few oddities (including the handful of engineering journals we take via the IEEE, I think) seem to require that the user clicks on an explicit ‘authenticate via IP’ link first. Why?
6. There’s an obvious problem for users who move between on-campus and off-campus computers (i.e., most users!); they will not get the same seamless access to restricted content, and some resources (e.g. Index to Theses) may only be available from within our IP range. How do libraries handle the transition between IP and other kinds of authentication for off-campus users? Through ‘user education’ (lovely phrase that, covers up all sorts of system difficulties!), or by trying to design a system that recognises the user’s location (“geoaware”) and routes accordingly to hide the transition? There was a useful JISC Publisher Interface Study (2009) which explored some of these issues
7. Proxy tools such as the much-vaunted EZProxy or our own dear LibResProxy (which I’ve been informed are both actually ‘reverse’ proxies [edit: or possibly some other flavour of URL-writing proxy??] – my eyes started to glaze over at that point…) are a useful bodge for providing simple off-campus access on the same basis as on-campus IP lookup: effectively they ‘mask’ the user’s actual, off-campus, out-of-range IP with an in-range, institutional IP address by routing the user (who must log in to the proxy tool first) through a server on the campus network. Libraries that use EZProxy swear that it simplifies things greatly for the user, is very reliable, and reduces the number of support queries compared with e.g. Athens/Shibboleth… but at the same time, proxies seem to be looked down upon by the library/information ‘establishment’. I understand that they don’t offer the same opportunities as federated access for personalising the user experience; they can be slow, too. But my suspicion is that users will go for straightforward, predictable, reliable full-text access over personalisation, nearly every time.
8. All of what I know about IP address authentication applies to IPv4. What, if anything needs to change to take account of IPv6?