Subject: Re: [MOBILE-IP] Private FA address [was RE: [MOBILE-IP] Darwinian evolution of proxy tunnelling...]

From: Patrice Calhoun <[email-masked]>
Date: Mon, 20 Sep 1999 14:26:12 -0700

>> I think this is a fine idea (and I don't even have to change my implementation
>:)
>>
>> PatC
>
>I tend to agree - if the NAI provides cost-efficient uniqueness.  To
>easily obtain a unique NAI with minimal consultation of central
>authorities, there might be a recommendation (algorithm) on how to
>independently generate a unique NAI. Maybe use a FQDN of the closest
>connecting public network in the realm and a string generated from the
>address(es) of the FA(s), that is(are) on the path to the public
>network, in the NAI username part, to maximize FA address reuse within
>and among organizations. This, on the other hand, starts to resemble
>the use of a list of regional FA IP source addresses when exposed to a
>regional-aware MN in an agent advertisement.. Is there a trivial way
>to locally guarantee NAI uniqueness?

Of course, we cannot guarantee anything but RFC 2486 (NAI) states:

   "NAI realm names are required to be unique and the rights to use a
   given NAI realm for roaming purposes are obtained coincident with
   acquiring the rights to use a particular fully qualified domain name
   (FQDN).  Those wishing to use an NAI realm name should first acquire
   the rights to use the corresponding FQDN. Using an NAI realm without
   ownership of the corresponding FQDN creates the possibility of
   conflict and therefore is to be discouraged."

PatC

>
>Still, a NAI could be required in an agent advertisement e.g. only if
>the advertised FA address is private. But, this would complicate FA
>configuration, and we might want to avoid all extra administrative burden.
>
>> >> Also to require strictly correct use of leaf FA addressing makes it
>> >> hard to do large picocellular environments with Mobile IPv4 due to the
>> >> need for either customization of all the leaf routing engines or too
>> >> many public addresses. I could imagine using a private/local network
>> >> among my desktop IrDA devices (without having a customized routing
>> >> engine on all those with FA) if I can guarantee no conflicting
>> >> addresses exist there.
>> >>
>> >>
>> >We were discussing in Poole (3GPP MIP ad hoc) a
>> >few days ago which the most appropriate IP level
>> >movement detection mechanism would be.
>> >Charlie mentioned checking the IP source address
>> >in MIP agent advertisements as a good way to support
>> >movement detection.
>> >
>> >In my opinion this, as much as the subnet prefix
>> >based movement detection, which I believed to be
>> >good until that discussion, suffers in the case of
>> >lack of coordination between administrative
>> >domains: in case a MN moves from a FA in domain A
>> >to FA in domain B, both with the same private address
>> >on the interface used to send advertisements, the
>> >mobile would not detect movement unless
>> >a FA NAI extension is used.
>> >
>> >Note that in some environment such as cellular environments
>> >it is not possible to send periodic advertisements with a
>> >sufficiently high frequency to make Advertisement Lifetime
>> >based movement detection feasible.
>> >
>> >Therefore, my suggestion would be to incorporate a FA NAI
>> >extension in any MIP advertisement, so that each FA
>> >is uniquely identified and movement detection easy.
>> >
>> >Is it an appropriate thing to be added when MIP will be moved
>> >to draft std?
>> >
>> >alessio
>
>--jari
>
>Jari Malinen
>Researcher, HUT/CS Lab.

---

From: Jari T Malinen <[email-masked]>
Date: Tue, 21 Sep 1999 20:55:17 +0200

>    conflict and therefore is to be discouraged."

This paragraph makes one slightly hesitate calling the use of NAIs an
ideal solution for disambiguating private address leaf FAs. It sounds
like human interaction, i.e. administrative cost, to get the NAIs.
Ideally, autoconfiguration of such small scale FAs might be desirable.
Another easier means for finding the disambiguating token might then
be worth considering, such as the use of a FA IP address path,
perhaps. But, if NAIs for other reasons become important enough to be
required, this private address issue could then be nicely solved
as a side effect.

--jari

Jari Malinen
Researcher, HUT/CS Lab.