Subject: RE: [mobile-ip] RR Last Call issue #3 - AGREE with one ISSUE and CLARIFICATIONs

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 16 May 2002 03:29:05 -0400

Looks good Annika,

AGREE in principle with some more work to do....explained below and in my
response to Issue 2.

-----Original Message-----
From: Annika Jonsson [mailto:[email-masked]]
Sent: 15 May 2002 17:24
To: [email-masked]
Subject: [mobile-ip] Regional Registration Last Call issue #3

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 

AWO>CLARIFICATION
'IF THE MN KNOWS THE HA SUPPORTS REGIONAL REGISTRATION'

, 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.

AWO>CLARIFICATION
The address being sent to the HA is now a CoA between HA and GFA so I would
suggest you send this in a HFAext to be strictly correct and not the
GFAIPext. The HFAext address is not needed by the MN which instead needs the
GFA address from the MN-FA-GFA addressing domain. The HA therefore should
return the HFAext to the GFA to confirm it understood it (see mail on Issues
2), but it is the FA that knows the address it used to send to the GFA so it
is the FA that should add the GFAIPext in the Reply to the MN (the GFA can't
do this because there is maybe no MN-GFA auth ext in place and this address
was allocated by the FA so its communication is rightly the FAs
responsibility). Then of course HFAext and GFAIPext should be sub-types with
a regionally signalling type..as previously mentioned.

- 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

AWO>ISSUE
This does not deal with the case that the default CoA is not within the
addressing domain of the GFA-HA. See Issue 2 mail for conclusions...

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