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.
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'(?)
[...]
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.
Some IKEv2 extension possibility for discovering parameters too, and
BOOTP and last but not least Service Location Protocol RFC2165.
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?
If I can manually configure the DNS Server address then I can manually
configure its location info as well, right?
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
[email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
