Latitude and Longitude to IPv6 Address
Server Sky will locate ground antennas using their IPv6 address, geographic mapping, and trigonometry, not routing tables. If a packet must be routed over the horizon, routing choices are made by computing the lowest cost - routing arrays will advertise their availability, latency, listening schedule, and monetary cost.
This page concerns only the mapping of terrestrial latitude and longitude to an IPv6 address. Server sky arrays will have their own IP address space, with an IP address assigned to an orbital location, plus radial displacements and angles for toriodal orbits. Thinsats in the array will each have individual IPv6 addresses for accounting and ownership (not routing), which will be mapped to non-routable subnet addresses within the array for internal communication.
Projecting the Earth's geoid surface onto a sphere with a radius of 6371 kilometers, the area is 510 million square kilometers, mostly ocean. Mapped to one meter resolution, that is 5.1E14 m2, and ln2(5.1E14) is 48.8 . Mapping to one centimeter resolution, that is 5.1E18 cm2, andln2(5.1E14) is 62.1 . IPv6 offers a 128 bit address space, so if we assigned every spot on earth with 1cm accuracy (and mapped altitude to that, needed for beam pointing) we could use a 64 bit subnetwork, there are 18 quintillion of those.
If we assign every 1cm3 voxel (volume element) in the atmosphere up to 100km altitude with its own unique IPv6 address (5.1e25) we get an 85.4 bit address space. This would be useful for pointing laser communications at small drones, many of which might converge on the same lat/long at different altitudes.
Backing off to "mere" 1 m3 voxels, and limiting altitude to +/-64 km for the terrestrial surface, there are 2.1E19 voxels in the atmosphere, 66.8 bits worth. We will actually need 68 bits to encode three coordinates.
Latitude and Longitude, Resolution
The circumference of the equator is 40 075 016 meters, or 111319.49 meters per degree of longitude. Mapping is easier if we use this as our conversion factor for both latitude and longitude, and assign positions from a latitude and longitude position, and elevation relative to sea level. The reference ellipsoid is 6378 km radius at the equator, 6353 km radius at the poles. The longitude range from +/- 180 degrees is +/- 20 037 508 meters, a 26 bit signed integer. The latitude varies by half of that, a 25 bit signed integer. And the altitude can be negative, so we need a 17 bit signed integer for that, for a total of 68 bits of voxel address. The ground station IPv6 address will contain this 68 bit integer, measured and assigned by a national licensing body.
Due to crustal mass concentrations and wind, sea level differs from the reference ellipsoid, perhaps by kilometers. I'm not sure of the conversion factor, but variations in gravity can be measured, the typical units are "milligals", where a gal is 1 cm/s2, corresponding to 3200 meters of vertical change, so a milligal corresponds to 3.2 meters.
An example:
Seattle has a gravitational anomaly of about 50 milligals, which translates
The Seattle Space Needle is at 47.6204N, -122.3491E, and the restaurant deck is 150 meters above the ground, which is 20 meters above mean sea level. The gravitational anomaly at Seattle is around 50 milligals, so presume sea level near Seattle is 160 meters higher than the reference ellipsoid; the correct number will be different and possibly much larger.
So, the Space Needle restaurant deck is 160+20+150 meters or 330 meters above the sphere. -122.3491E is 13619535 meters west of the prime meridian along the equator on the reference sphere, and 47.6204N is 5300960 meters north. The coordinates of center of the restaurant deck are ( -13619535 , 5300960, 330 ). The restaurant deck has a radius of 14 meters and rotates 31 times per day, so very precise pointing must take that into account. 
We can express the longitude with a 26 bit signed integer, the latitude with a 25 bit signed integer, and the altitude with a 17 bit signed integer (which is added to the radius of the reference ellipsoid). A ground station IPv6 address will contain this 68 bit integer, measured and assigned by a national licensing body.
A thinsat array will compute its own cartesian coordinate and array rotation and the ground station coordinate at the beginning of a packet, then compute the elevation and azimuth of the ground station. The ground station will do likewise.
An IPv4 jumbo packet is up to 64 ki octets, and needs 530 microseconds to transmit at 1ns/bit; the array, moving and rotating at 6500 m/s ground spot velocity, moves its 500 meter diameter ground spot 3.5 meters in that time. An IPv6 jumbo packet is up to 4 Gi octets - the ground spot would translate by 223 kilometers, far too much without re-aiming. So, it is reasonable to set the MTU (maximum transmission unit message size ) to perhaps 220 meters of translation, 34 milliseconds, or 4 Mi octets, then dial it down in high noise situations. Note that frequencies and bit rates should be adjusted for doppler shift; this is more practically and securely done on the array, rather than on the ground station.
Security
Since we know precisely which ground station (presumably a cell tower) we are talking to, it will be almost impossible for an impersonator using a different ground station to spoof the routing. Presumably, all packets will be encrypted and known only to the sender and receiver processes, with a "salt" computed from the packet time and the positions of the array and ground station. We can presume the encryption will be broken relatively quickly, server sky will provide vast amounts of computing for decryption, but the decryption will not occur soon enough to inject man-in-the-middle attacks into an ongoing conversation.
Whole message encryption can be computed before packetization and transmission. While the packet encryption will be built into thinsat hardware, the whole message encryption algorithms can be whatever the customer chooses, implemented in software (using some built-in hardware primitives like giant integer arithmetic with modular checksums) and evolve with time.