Subject: [mobile-ip] Regional Registration Last Call issue #3

From: Annika Jonsson <[email-masked]>
Date: Wed, 15 May 2002 09:53:51 +0200

Hi

Here are my conclusions and proposals for additions/changes to solve most 
of  the technical  issues raised during last call of Regional 
Registrations. I have excluded the issues around multiple levels of 
hierarchies, which will be dealt with separatley.

Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the 
recommendation. And on the response put in the subject line, CLARIFICATION 
if you have a clarification to recommend, or ISSUE if you have an issue to 
raise.

A. Differnet addressing realms.

The issues raised about supporting different addressing realms between 
FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those 
addressing realms). The basic problem is how to allow for flexibility in 
addressing between FA-GFA and GFA-HA, which does not work with the way the 
draft specifies the use of GFA CoA today. To allow this, it should be the 
GFA that decides wich CoA to use, possibly individually for each MN. To 
support this, the following changes are proposed:

- clarify that a MN that supports regional registrations SHOULD send home 
registrations with a zero CoA, to allow the GFA to allocate CoA. (it is 
SHOULD and not MUST, because if the MN's HA doesn't support regional 
registrations, it should be allowed to use an advertised CoA, see mail on 
issue #2). An FA can force the use of zero CoA by not advertising any CoA 
address, but it will then not be backwards compatible (see mail on issues 
#2). This will be clarified in section 4.1.

- change the allocation of CoA if the MN uses zero COA in the registration: 
in the draft right now, it is the FA that decides what CoA the MN gets. 
This should be changed so that the FA only forwards the registration to a 
GFA node (using an address in the address realm between the FA-GFA). Then 
the GFA selects the CoA (possibly based on the MN:s HA address, or  MN-NAI 
if present, or information from AAA server etc...), adds GFA IP extension, 
protects it with FA-HA auth- extension and sends it to the HA. This will be 
changed in section 4.2, 4.3 and 8.1.

- clarifiy that if the FA advertises a GFA CoA, this is regarded as a 
"default" CoA that could be used, especially by MN:s that supports regional 
registrations, but have HA:s that don't. If this CoA is not within the same 
addressing realm as the FA-GFA, the FA needs to have a mapping to the 
address that it should use to communicate with the GFA. This will be added 
to section 4.2

B. too many options.

Some people commented that it is a problem with too may optional ways to do 
things, since it would be difficlut to imlement and can create problems for 
interoperability.

- Most of the options are around the advertised addresses and what address 
the mobile node uses in registration messages. Hopefully this is much 
better now that we clarifies the use of those addresses both for backwards 
compatibility and for different addressing realms, so I consider this issue 
solved

C. protection of the GFA IP address extension

It was pointed out that the GFA IP address extension needs to be protected 
by an authentication extension.

- this should be clarified in section 4.3.

D. reverse tunnelling clarification

It was pointed out that if reverse tunnelling is used, the FA must use the 
address in the registration request (from the HFA extension) as source for 
the tunnel.

- this should be clarified in section 4.2 and 4.3.

E. Generalized NAI extension

There was a question about why the Generalized NAI extension is needed, why 
not use an FA-NAI extension directly?

- RFC3220 recommends that new extensions should be in this format if 
possible. Therefore I propose that we keep this.

F. added delay with extra round-trip

It was pointed out that if the FA is allowed to deny a regional 
registration because it doesn't support that GFA, this means one extra 
round-trip before the registration is completed, which could lead to extra 
delay for traffic.

- That is true, but I still think we should allow this feature because:
*  the first "round-trip" is very short, only to the FA and back.
* FAs in the same domain should in most cases support the same GFAs so this 
would not happen very often.
* allowing an FA to deny the use of a specific GFA would be useful, for 
example if a GFA breaks down, since it would force the MN to register a new 
GFA with it's HA.
* the FA needs a way to deny unvalid registrations, in this case if a 
mobile node uses a non-existent CoA in the registration request.

Therefore I propose that we don't change this.

Regards,
Annika

---

From: "Emad Qaddoura" <[email-masked]>
Date: Wed, 15 May 2002 22:18:18 +0200

Pls see comments below on issue F.

> -----Original Message-----
> From: [email-masked] [mailto:owner-mobile-
> [email-masked]] On Behalf Of Annika Jonsson
> Sent: Wednesday, May 15, 2002 9:54 AM
> To: [email-masked]
> Subject: [mobile-ip] Regional Registration Last Call issue #3
> 
> Hi
> 
> protects it with FA-HA auth- extension and sends it to the HA. This
will
> be
> Some people commented that it is a problem with too may optional ways
to
> do
> things, since it would be difficlut to imlement and can create
problems
> for
> There was a question about why the Generalized NAI extension is
needed,
> why
[<<<EQ>>>] I don't agree with this justification. Every MS adds up.

> example if a GFA breaks down, since it would force the MN to register
a
> new
[<<<EQ>>>] I agree it would help and handling such case should be part
of the protocol. But, the key here, as stated in sec 5.0 (4th
paragraph), the GFAs are in the SAME DOMAIN, and may be the protocol
should allow a re-direction of the request to another GFA within the
domain, update the MN with the new address in the reply and allow the
transaction to continue without the additional delay.

---

From: Annika Jonsson <[email-masked]>
Date: Fri, 17 May 2002 13:18:58 +0200

Hi Emad,

>transaction to continue without the additional delay.

But this would be worse because it would take longer time. The reason why 
the MN need to know that a GFA is not available is that it must then 
perform a new home registration to update it's HA (section 5 is about 
_regional_ registrations). To redirect to a new GFA, without involving the 
MN, takes longer time that just denying the registration at the FA, and no 
traffic can reach the MN before it has completed a home registration 
anyway. Therefore the goal is to get the MN to send a new home registration 
as soon as possible. But what this discussion shows is that we should 
clarify how _home_ registrations are handled.

Regards,
Annika