Re: [Int-area] Discovering a Location Server in the Access Network

Hi Pekka,

thanks for your response.

Pekka Savola wrote:
> On Fri, 14 Sep 2007, Hannes Tschofenig wrote:
>> In short, the current proposal (see 
>> http://tools.ietf.org/html/draft-thomson-geopriv-lis-discovery-02.txt; 
>> ignoring Section 2 which defines the DHCP portion) essentially does 
>> the following:
>>
>> * Discover the public IP address of the end point
>> * Perform a reverse DNS lookup to learn the domain
>> * Lookup the LIS for that domain
>> * Contact the LIS
>
> 2-3 years ago we had the similar problem with IPv6-in-IPv4 tunnel 
> endpoint discovery, only that the endpoint could reside outside the 
> L2/L3 network as well.  The approaches identified then were described at:
>
> http://tools.ietf.org/html/draft-palet-v6ops-tun-auto-disc-03

Thanks for the pointer to this document.
I will go through it.

>
> Personally, I thought anycast made most sense.
I will evaluate whether it can be used for our usage scenario.

>
> Some other folks preferred reverse DNS population (e.g. [1]), but that 
> also has problems with private address use of a more recent approach 
> to try to push the NAT boxes to act as authoritative for private 
> address spaces [2] in which case the ISP could not populate its DNS 
> resolvers for private addresses either.
>
> In your case where the L2/L3 provider is required to provide this 
> information in order for the methodology could work, though personally 
> I'm somewhat concerned about 1) how reliable the public IP address 
> discovery could be,
That's something I was concerned about as well.

> 2) what happens if the ISP doesn't provide reverse DNS entry for the 
> public IP,

Obviously if you don't implement important parts of the solution then 
the solution will not work.

> and 3) whether the operator who's providing L3 service and public IP 
> does in fact even know where the user is located (if the user's ADSL 
> session is provided by a L2 provider and just tunneled - in bulk - 
> using L2TP to L3 provider).
The ISP may, in some cases, not be able to know it. There is also a 
story for this, see.
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-lis2lis-req-00.txt
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-identity-extensions-02.txt
*
*
>
> The last issue is probably the biggest and you may need to consider in 
> more detail how such "L2 different from L3" network would work. 
> Realistically any solution I could think of that doesn't involve DHCP 
> or PPP is likely to require coordination in this case.  Would it 
> required that the local regular requires L3 provider to also keep 
> track of the physical location?
So far, I haven't mentioned the usage scenarios. Some of us are 
particularly interested in emergency services. The regulator is already 
in the progress of placing requirements on the access network provider 
to make location information available (in case of emergency services).

Ciao
Hannes

>
> [1] 
> http://tools.ietf.org/html/draft-yamamoto-naptr-service-discovery-01 
> [2] http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-02
>

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area