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

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 17 May 2002 08:33:53 -0500

Hello Annika;

> 
> 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?
> 
I am sorry I forgot to comment on this one. I think I am the one who raised
this clarification.
I did not mean that you SHOULD NOT use GNAI. What I meant:
Why do we need to have a special section about GNAI for this extension.
GNAI already presented some where else. You can just say that we are using 
GNAI extension with this type and subtype. No more no less. 

What do you think?

> - 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: Annika Jonsson <[email-masked]>
Date: Tue, 21 May 2002 10:11:25 +0200

Hi Ahmad,

>I am sorry I forgot to comment on this one. I think I am the one who 
>raised this clarification.

We had to add that in this draft, because the draft where it was specified 
before is now deprecated.

/Annika