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

[Hannes Tschofenig <[e-mail]>]

Hi Alex,

Alexandru Petrescu wrote:
> Hi Hannes, let me try to give some thoughts.  But your mail is such a
> concentrate of information to newcomers to GEOPRIV.
>
> I'm not sure I get everything right, but anyways, here goes.
>
> Hannes Tschofenig wrote:
>
>>
>> A year ago I lead a design team that captured the problem statement
>> and requirements. The document is available here: 
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt
> draft-ietf-geopriv-l7-lcp-ps-05.txt:
>> 3.2.  Moving Network
>>
>>    An example of a moving network is [...]
>
> (As a side note, I'm happy that the GEOPRIV L7 PS and reqs document 
> mentions moving networks and describes them.  I'm already happy with 
> the terminology, because many people I'm talking to seem to refuse to 
> accept this 'moving network' term and prefer 'mobile network' ignoring 
> the potential clash with 'mobile networks' that don't move but support 
> mobility of hosts.
>
> One would also maybe cite "mobile network" of RFC4885 "Network 
> Mobility Support Terminology" and "Mobility Terminology" RFC3753 and 
> last but not least rfc2002 Mobile IPv4 probably the first to mention 
> "mobile networks" in its section 4.5.  I think MANET documents may too.
>
Yep. I could cite that RFC.

> Technically, the 'moving networks' you describe are a little bit 
> different than the 'mobile networks' which run Mobile IP NEMO 
> extensions.  Your movnets have the LFN (your Ethernet laptop) do the 
> PPPoE game and use the MR (your NTE) as a modem I believe.  A 
> multi-host WiMax deployment.  The 'mobile networks' have the Mobile 
> Router (your NTE) do the dialup, eventually PPPoE but any other PtP or 
> shared media, for the access.
>
> But, I think 'moving networks' per your definition and 'mobile 
> networks' per Mobile IP stuff are conceptually the same thing.  I'd 
> like to be able to call the Mobile IP NEMO-based 'mobile networks' - 
> 'moving networks'.
>
> Anyways, just a digression.)
>
>>  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.

> [...]
>> 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.

>
> 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.


>
> draft-thomson-geopriv-lis-discovery-02:
>> 1.2. U-NAPTR Discovery
>>
>> Where DHCP is not available, the DNS might be able to provide a URI.
>
> If DHCP is not available then the host doesn't have the DNS Server
> address either, thus no way to obtain that URI, right?
DHCP is available but you will only learn the information obtained from 
your DSL router (which plays the role of the DHCP server for your home 
network).
This DSL router will, however, not forward information from the DSL 
operator. It is somewhat independent.

>
> If I can manually configure the DNS Server address then I can manually
> configure its location info as well, right?

Ciao
Hannes

>
> Alex
>
>>
>> I had a chat with Jari and we both agree that this topoic falls into 
>> the expertise of the Internet Area. Hence, I would like to solicit 
>> feedback from you.
>>
>> Ciao Hannes
>>
>>
>>
>> _______________________________________________ Int-area mailing list
>>  [e-mail] https://www1.ietf.org/mailman/listinfo/int-area
>>
>
>
> ______________________________________________________________________
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area