Subject: [Geopriv] Add IP address prefixes in held-identity-extensions?

From: Richard Barnes <[email-masked]>
Date: Tue, 06 Oct 2009 11:52:52 +0100

Hey all,

I'm at RIPE this week, and it's becoming increasingly clear that in the 
IPv6 environment, it's going to be common for sites/customers to be 
assigned a prefix (e.g., /56 to /64 seem to be common).  To some extent, 
this logic extends down to hosts as well, since a single interface can 
have multiple IPv6 addresses.  Would it make sense to add a v4/v6 prefix 
identifier type to the HELD identity extension?

<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
   <ip-prefix v="4">192.1.0.0/16</ip-prefix>
   <ip-prefix v="6">2001:DB8:1::/64</ip-prefix>
</device>

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Oct 2009 19:42:55 -0500

I can't think of a reason to object to this.  It has somewhat limited applicability in v4, but as you say, v6 addressing is a somewhat more liberal.

Unless I hear arguments to the contrary, I'll include something like this in the next revision of the doc.  I'm holding that update on the open issue.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Tuesday, 6 October 2009 9:53 PM
> To: 'GEOPRIV'
> Subject: [Geopriv] Add IP address prefixes in held-identity-extensions?
> 
> Hey all,
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Oct 2009 09:17:10 -0400

Isn't this making a huge assumption from the location determination POV?
How does the LIS/LS know that a location request for a network prefix
applies to a single target?  Is it assumed the resultant location
determination will understand the complete IP addressing scheme?

-Marc-

On 10/6/09 8:42 PM, "Thomson, Martin" <[email-masked]> wrote:

> I can't think of a reason to object to this.  It has somewhat limited
> applicability in v4, but as you say, v6 addressing is a somewhat more liberal.
> 
> Unless I hear arguments to the contrary, I'll include something like this in
> the next revision of the doc.  I'm holding that update on the open issue.
> 
> --Martin
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 07 Oct 2009 16:12:41 +0100

I think the level of knowledge/risk is about the same as for IP 
addresses in the IPv4 context.

v4: Assign addresses to customer sites with the assumption that there 
will be a NAT and a network behind it.

v6: Assign prefixes to customer sites with the assumption that hosts 
within the customer site will use addresses within that prefix.

In either case, under the assumption that the customer network is 
reasonably small, the location of the customer site that was assigned 
the address/prefix is not a terrible estimate of a host that's visible 
as that address.

--Richard

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Oct 2009 11:46:31 -0400

I think the assumption is the problem.  There may be, in fact, use cases
where a prefix belongs to a host, but it is unknown how the location
determination process knows/discovers such.

Even if each location request for every host address in a subnet returns the
exact same location value, one shouldn't assume that there is a single host
that owns the prefix/subnet.

What is your use case where a 3rd party would know that a host owns a
subnet?  It seems the location requester is more likely to know the target
by a host address that is derived from some service/application interaction
with the target and the requester would have zero knowledge of the subnet
architecture.

-Marc-  

On 10/7/09 11:12 AM, "Richard Barnes" <[email-masked]> wrote:

>>> ----------------------------------------------------------------------------
>>> --
>>> ------------------
>>> ----------------------------------------------------------------------------
>>> --
>>> ------------------
>>> [mf2]

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Oct 2009 15:39:58 -0400

> determination process knows/discovers such.

In the case where it's the local network operator operating the LIS,
this is no problem -- he knows how he's addressing his network.  If you 
were a LIS, you could also build this information up incrementally, 
taking unions over locations of hosts or more-specific prefixes.

> that owns the prefix/subnet.

There's not a real requirement that a location (or an identifier) 
correspond to to a single host -- it's not even the case today, with 
many-to-one NATs, that a single address maps to a single host.  If all 
the hosts that map to an identifier (with a subnet, or behind a NATted 
address) are in the same building, it makes sense to return that 
building as the location for the identifier.

> with the target and the requester would have zero knowledge of the subnet

The use case that got me started was that a lot of entities nowadays use 
the WHOIS databases as an approximate geolocation tool for IP address 
allocations.  You could replace this functionality with a real location 
service using a combination of HELD servers that know about prefixes and 
lis-discovery records in the reverse-DNS trees.  More generally, there 
are lots of routing and routing-management entities that know about the 
prefix-level structure of the Internet; allowing the use of a prefix as 
an identifier would enable these things to be geolocation-aware.

--Richard

---

From: [email-masked]
Date: Fri, 16 Oct 2009 23:45:39 +0100

> lis-discovery records in the reverse-DNS trees.

And we do of course already have a draft [
draft-thomson-geopriv-res-gw-lis-discovery] which describes using the 
reverse-DNS trees to find HELD servers...

Ray