Subject: [mobile-ip] Mipv6 issue #197: Appendix B.5 update

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Dec 2002 12:17:48 +0200

Hi,

Antti brought up an issue with appendix B.5 of the MIPv6 draft. This
appendix does not seem to be in sync with the current requirement that
HAOs must be used in MPS. As a solution I'm proposing that the
order of prefix discovery and home registration be reversed, and
that the first home address configuration be based on DHAAD results
and the MN's IID. New text below:

	- Generate a care-of address.

	- Query DNS for the home network's mobile agent
	  anycast address.

	- Perform home agent address discovery, and select a home
	  agent.

	- Configure one home address based on the selected home
	  agent's subnet prefix and the interface identifier of the
	  mobile node.

	- Create security associations and security policy database
	  entries for protecting the traffic between the selected home
	  address and home agent.

	- Perform a home registration to the selected home agent.

	- Perform prefix discovery.

	- Make a decision if further home addresses need to be
           configured.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Dec 2002 09:05:24 -0800

Jari,

> - Query DNS for the home network's mobile agent

What exactly would be the query?

Presuming it is a standard query for the address associated with an FQDN, I
believe there are a set of assumptions here: a) that the home agent will have an
FQDN which the home network operator is willing to expose to the Internet, b)
that the FQDN won't change while the mobile node is asleep.

Both of these seem broadly reasonable, but also liable to break down in certain
situations.

> - Make a decision if further home addresses need to be

            jak

---

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Dec 2002 22:24:49 +0200

> Both of these seem broadly reasonable, but also liable to break down in certain

I agree. (OTOH, this is in an appendix and not expected to be a part of the
normative text.)

I think we should fix the text to "Query DNS for an anycast address
associated with the FQDN of the home agent(s).".

Overall, DHAAD and related functionality is just shifting the requirement
for something stable from one place to another. From home agent addresses
to stable anycast addresses, from stable anycast addresses to stable FQDNs
etc. This is probably all we can specify now, some say even this is too much.
It would be an interesting exercise to see if we could do without any stable
identifier, or whether we could use some general purpose framework for
locating services from the global Internet.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Dec 2002 13:18:35 -0800

> associated with the FQDN of the home agent(s).".

Sounds OK.

> locating services from the global Internet.

I think a case can be made for using DNS SRV RRs for HA discovery, but I don't
think that needs to be done right now. There is an issue with identifying which
HA to use, based on the home subnet prefix (SRV RRs don't support discovery by
attribute) but I think it might be finnessed by using a naming convention,
something like ENUM does. I'd like to include MAP discovery into this as well,
so it is on my list of New Year's resolutions to write a draft about this.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Dec 2002 17:22:24 -0800

>           agent's subnet prefix and the interface identifier of the

I am not sure the above step will work. the MN does not know the 
prefix length of the home agent's subnet prefix. so it cannot 
figure out the home prefix based on just the home agent's address.

right?

>         - Make a decision if further home addresses need to be

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Dec 2002 13:00:16 +0200

> figure out the home prefix based on just the home agent's address.

Right, but I'm not sure I see a way around this. I'll add a note
to the beginning of B.5:

    "This procedure is restricted to those situations where the
     home prefix is 64 bits and the mobile node knows its own interface
     identifier of also 64 bits."

Jari