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