[Geopriv] Experiment report: Geopriv at APRICOT 2010

[Richard Barnes <[e-mail]>]

=== Executive Summary ===
At the APRICOT meeting in early March, we deployed LIS discovery  
records in the reverse-DNS tree and demonstrated a basic HELD client  
that supported discovery.   Doing all the coding myself (and borrowing  
some code from Martin Thomson), I was able to put this together in a  
couple of days' time.  In particular, because I wrote the LIS and the  
client was written by Martin, this shows two independent,  
interoperable implementations of HELD.

Slides: <http://meetings.apnic.net/__data/assets/pdf_file/0018/19008/New-Technology-Session_01_IP-Geolocation-and-Location-Based-Services-_Richard-Barnes.pdf 
 >

Code: <http://geopriv.dreamhosters.com/apnic/apnic-geopriv-demo.tar.gz>

Live demo LIS: <http://geopriv.dreamhosters.com/apnic/provision/entry.php 
 >

Live HELD client: <http://geopriv.dreamhosters.com/apnic/view/pidflo.html 
 >


=== Setup ===

I gave a presentation on GEOPRIV at APRICOT in early March, and to  
demonstrate some of the key concepts in GEOPRIV, I worked with the  
conference organizers to HELD-enable the conference network.  The  
experiment system had four basic components:

1. The LIS: I wrote a small perl CGI script that implements a HELD  
server interface to provide location from two sources:
1.1. A database of provisioned prefix-to-location mappings
1.1. The MaxMind GeoLite City database (if not found in DB)
This server only supports location configuration and dereference.  If  
a query comes with a given query parameter, it is handled as a deref  
request and location is pulled from a cache; otherwise location is  
determined based on the source IP address of the request.  In  
particular, it does not support third-party queries.

2. The Reverse DNS Tree: The meeting network was numbered out of a  
169.223.32.0/22, so we just provisioned a LIS-Discovery NAPTR record  
for each corresponding record under 223.169.in-addr.arpa.  The zone  
file with just those records was around 220KB, and the name server was  
running a recent version of BIND 9.

3. The PHP LIS Discovery Service: In order to simplify the  
implementation of a HELD client, we exploited the nice DNS interface  
in PHP to do proxied LIS discovery.  A query to this PHP script will  
return the LIS URI for the source IP address if a NAPTR record is  
present in the reverse DNS for that IP address (no tree climbing);  
otherwise the response will be empty.

4. The AJAX HELD Client: I extended Martin Thomson's online HELD  
client  / PIDF-LO viewer to use the above PHP LIS discovery service.   
This led to a simple, web-based client with
4.1. A button to trigger LIS discovery
4.2. A button to send the HELD query
4.3. A Google Maps display of the returned location

The demo in the meeting proceeded in three steps: First, we did an  
initial HELD discovery and query, showing the location that MaxMind  
had for the meeting network -- not in Kuala Lumpur, the meeting site,  
but in Manila, the location of the last APRICOT meeting.  Second, we  
opened the provisioning page and provisioned geodetic and civic  
location values for the meeting venue (the KL Convention Center).   
Third, we went back to the HELD client and showed that the client was  
able to discover, receive, interpret, and display the location  
information.

=== Results ===

Basically, everything pretty much worked, and wasn't too hard to code  
up:
LIS: 687 lines of Perl
Discovery proxy: 22 lines of PHP
HELD Client: 2113 lines of Javascript
For the HELD Client, all but 16 were due to Martin Thomson (these 16  
lines just sent an AJAX request to the discovery service and stored  
the result).  So since I wrote the LIS, I think this count as  
independent, interoperable implementations.

draft-ietf-geopriv-http-location-delivery
Obviously, XML parsing is kind of a pain, but Perl provided a very  
workable parser.  The most subtle logic ended up being around deciding  
which location types to return -- basically taking the intersection  
between what was available from the location sources and what was  
allowed by "locationType" and "exact".  The LIS completely ignores the  
"responseTime" attribute.

draft-ietf-geopriv-lis-discovery
It was really trivial just to copy the example NAPTR records from the  
draft and customize them with my LIS URI.  Parsing the records in PHP  
was easy because of the constrained format from RFC 4848.

draft-thomson-geopriv-res-gw-lis-discovery
As we can see, provisioning a fairly modest-sized network (/22)  
entailed a zone file of non-trivial size (>200KB), so it looks like  
this direct approach probably doesn't scale.  Dynamically-generated  
DNS mechanisms would probably be better-suited, but the one approach  
we looked at (the BIND $GENERATE statement) did not support generation  
of NAPTR records.  For some reason, one of the secondary name servers  
(which was running on BSD) would not load the zone file, but the  
primary did; we did not investigate this issue further.