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

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
>>
>> I think it should say 'Discover ... address of the LIS', right?   And
>> not 'of the end point'(?)
>>
> No; it really means that you learn your own public IP address. That's no 
> problem if you already have one but you might also be behind a NAT 
> (which is extremely common in a DSL network). Hence, knowing your 
> private IP address is not very useful for the discovery of the LIS since 
> you will not find a LIS in your own home network.

But you're sure that it's necessary to discover my IP address when I'm 
behind NAT?  Does the LIS need to contact me without me needing to 
contact it first?

>> [...]
>>> We have investigated other solutions as well (see Section 4 of 
>>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt)
>>>  but the group (or at least a few folks) believes that this is a 
>>> "good" approach.
>>
>> Section4:
>>> DHCP-based discovery, DNS-based discovery, Redirect [HTTP or AAA] 
>>> rule, multicast DNS queries, anycast and Teredo discovery.
>>
>> That's fine it covers all I could think of, but there's (1) the
>> EXPERIMENTAL IPv6 Node Information Queries RFC4620 as well.  It's
>> limited to link-local multicast but I think that would be an advantage
>> (and not an inconvenient) because one would want that LIS server to be
>> as close to the querier, for geographical precision, I think.
> I can certainly list it as an option but the fact that it is restricted 
> to a link-local multicast does not make it very attractive for our usage 
> environment.

Ok.  I thought the reverse but anyways.

>> Some IKEv2 extension possibility for discovering parameters too, and
>> BOOTP and last but not least Service Location Protocol RFC2165.
> Yep. I could also mention these.
> 
> I have to refresh my memory about SLP but IKEv2 is certainly not very 
> useful in our environment.

Well, at some point you talk using DNS in a secure manner (in the 
security section)...

Anyways, thanks.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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