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.
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.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
