Subject: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA?

From: Pat Calhoun <[email-masked]>
Date: Tue, 6 Nov 2001 17:07:03 -0800

All,

While looking at solving this issue, we have two options:

1. Require that the AAAH perform the Server Discovery procedures in
   section 5.2 to determine the URL of the Home Agent.

2. Create a new Mobile IP extension, and associated AVP, which the Mobile
   Node must include in its registration requests. This means that once the
   mobile has been initially registered by the HA, the HA would include its
   identity in the registration reply.

My preference is to go with option #1. I see no reason why this cannot be 
required for inter-domain mobility. It would, however, break if either the
FA or the HA were using private addresses, but then again, Mobile IP between
such nodes (across domains) wouldn't work anyways. Option #2 will require
a new document to be introduced in the MIP WG, more editorial work, 
WG consensus gathering, etc. Not something that can be achieved in the short
term.

So, I vote for option 1.

Thoughts?

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 8 Nov 2001 10:21:34 +0100

can you describe how you will do that. Given that all you have is an Ip
address of a mobile ip interface on the HA, I can't see how you can retrieve
the HA URI for some other interface on the HA. It might be really easy, but,
if so, I believe that some extra clarifications is needed in 5.2.

/Fredrik

---

From: Johan Johansson <[email-masked]>
Date: Thu, 08 Nov 2001 11:23:26 +0100

I'm sorry, but I really fail to see how this could map from the ip 
address of the mobile ip interface of a specific HA to that HA's 
diameter URI. What am I missing?

j

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 8 Nov 2001 08:27:44 -0500

Hi Pat,

>    section 5.2 to determine the URL of the Home Agent.

A while back someone told me the following (I hope I am recalling this
correctly):

A home agent is sometimes multi-homed.  It has one IP interface over
which it communicates with the AAAH.  It has another "mobility subnet"
IP interface over which it communicates with the FA and MN.  The IP
address of the first interface can be retrieved by a DNS lookup, but
sometimes the mobility subnet IP address is considered private and not
returned by the DNS.

The FA gets the Home Agent's IP address from the Home Agent Address
field in the Registration Request, and conveys this value in the
MIP-Home-Agent-Address AVP.  This IP address is the HA's mobility subnet
IP address, and is not necessarily the same IP address that the AAAH
uses to communicate with the HA.

Question 1: Is this correct or am I full of baloney?

Question 2: I don't know much about server discovery, but if the above
is true, does the fact that the HA's mobility subnet IP address isn't
necessarily known by DNS cause server discovery problems?

Bob K.

---

From: Johan Johansson <[email-masked]>
Date: Thu, 08 Nov 2001 15:43:48 +0100

Bob,

You are at least correct. We consider this a very likely deployment 
scenario.

j

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 8 Nov 2001 06:27:33 -0800

> if so, I believe that some extra clarifications is needed in 5.2.

Huh? What do you mean by "mobile ip interface on the HA" and "some other
interface on the HA". Why is the mobile ip interface on the HA different
from the normal routed interface which is connected to the home network. If
it is because the HA is multi-homed, then it simply has aliases. Nothing
innovative there.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 8 Nov 2001 06:29:36 -0800

> diameter URI. What am I missing?

You perform a reverse DNS lookup to get the FQDN. Section 5.2 then explains
how either SLP or DNS can be used to identify the remaining information,
such as transport used.

It seems simple to me, so perhaps I'm the one missing someting :(

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 8 Nov 2001 06:33:58 -0800

> sometimes the mobility subnet IP address is considered private and not

What does "private" mean? Non-routable address? If that's the case, then 
there is no way to route packets there anyways. Otherwise, if we are just
talking about private in the sense of not registered with the DNS server,
I don't understand why this is a problem. It's sure simpler than any other
protocol work we could ever come up with.

> uses to communicate with the HA.

A DNS name can have many IP addresses assigned. So a reverse DNS lookup of
the subnet address would return the correct name.

> Question 1: Is this correct or am I full of baloney?

I believe you are incorrect (but perhaps I am)

> necessarily known by DNS cause server discovery problems?

If SLP is used, then DNS isn't needed. Of course, the same argument that the
HA doesn't register all of its addresses with SLP could be made as well. 
Unfortunately, I just don't understand the problem with having all of a
multi-homed HA register its addresses with either DNS or SLP.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 8 Nov 2001 06:34:48 -0800

> You are at least correct. We consider this a very likely deployment 

Why not require the HA to register all of its addresses with DNS? What is
the "technical" problem in doing this?

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 8 Nov 2001 10:09:40 -0500

Hi Pat,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Pat Calhoun
> Sent: Thursday, November 08, 2001 9:34 AM
> To: Bob Kopacz
> Cc: Pat Calhoun; [email-masked]
> Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the
> Destination-Host of a previously assigned foreign HA?
>

Sorry for being unclear.  By "private", I meant a real routable IP address
that isn't registered with the DNS.  So the DNS reply indicates a
single-homed HA.

> > uses to communicate with the HA.

A secondary note...

I guess this does mean that for an HA in the home realm, that the AAAH,
when receiving an AMR in which the HA's IP address is specified, must compare
the AMR's HA IP address against all known IP addresses for the HA (in order
to send the HAR to the specified local HA), and not just compare with
the IP address that the AAAH himself uses to communicate with the HA.

> multi-homed HA register its addresses with either DNS or SLP.

I don't either.  Perhaps the context of my recollection was that it was
a testing situation where the HA's 2nd IP address wasn't registered with the
DNS,
rather than a real-life situation.  If there isn't a real-life reason
for the HA to not register its 2nd IP address, then my question isn't pertinent.

Just asking the questions.

Bob K.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 8 Nov 2001 07:05:35 -0800

> that isn't registered with the DNS.  So the DNS reply indicates a

right, and I think that the problem I have is "why"? Registering a secondary
address isn't rocket science, and is supported today in DNS.

> the IP address that the AAAH himself uses to communicate with the HA.

If done using IP addresses, then yes. If done by performing a reverse DNS
lookup (whose results are cached locally, btw), this is a non-issue.

> Just asking the questions.

It's a valid question, but my point is that this is a trivial problem to
resolve when using existing tools. We are being asked to solve it another
way, which is more complex, requires code on the mobile node, requires
standards efforts, consensus gathering, IESG review, etc. 

Make sense?

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Nov 2001 14:54:41 -0500

O.k., so we agree that option 1 could be made to work.  But option 1
requires an independent mechanism (DNS and server discovery) to retrieve
information that used to be known by the Diameter nodes.  If everything
isn't consistently configured among the directories and config files of
different protocols, the exchange will fail.  Option 2, on the other hand,
avoids such consistency assumptions and is therefore preferable.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Nov 2001 16:24:17 -0800

The use of DNS and/or SLP is already specified in the base protocol.

I would also argue that deploying, debugging, etc will be faster than
trying to change the MIP protocol (which is what option 2 would mean, and
you read the MIP chair's comments).

PatC
> >    identity in the registration reply.
Content-Description: Card for David Spence

---

From: Johan Johansson <[email-masked]>
Date: Tue, 13 Nov 2001 13:29:30 +0100

The base draft - correct me if I'm wrong - doesn't actually specify when 
to use server discovery. Does alternative 1 mean "use server discovery 
in this particular case" or does it mean "add server discovery to 
section 6.1.6/6.1.2 as a last-ditch effort"?

Which comments are you referring to btw?

j

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Nov 2001 09:34:54 -0800

yes, I am proposing to add some text stating when to use server discovery in
the areas where this issue is concerned.

PatC