> where a prefix belongs to a host, but it is unknown how the location
> 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.
> 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.
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.
> 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.
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
>
> -Marc-
>
>
>
> On 10/7/09 11:12 AM, "Richard Barnes" <rbarnes@bbn.com> wrote:
>
>> 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
>>
>>
>>
>>
>> Marc Linsner wrote:
>>> 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" <Martin.Thomson@andrew.com> 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
>>>>
>>>>> -----Original Message-----
>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] 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,
>>>>>
>>>>> 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
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> 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]
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> Geopriv@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
