Subject: RE: [Mip4] HoA=0.0.0.0 question

From: Avi Lior <[email-masked]>
Date: Thu, 16 Jun 2005 15:34:33 -0400

Hi Charlie,

Actually I am not sure it's a AAA problem either.  The original scenario
Kuntal raises can happen with or without the presence of a AAA function
right?  

The side-effect (Kuntal's explaination) is what can happen with a AAA.

IMO therefore, MIP needs to be more explicit as to what happens eventhough
at the pure MIP context it may not make a difference.

That is, we need to resolve Kuntal's original question in the MIP context:
 "when the HA receives a RRQ with HoA=0.0.0.0 does 
it always treat that as a NEW registration request even if 
there is an unexpired mobility binding for the same NAI in the HA?"

We can either require the mobile to use an HoA when re-registering or only
use the NAI to index the binding cache.

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Thursday, June 16, 2005 1:31 PM
> To: Chowdhury, Kuntal
> Cc: [email-masked]
> Subject: Re: [Mip4] HoA=0.0.0.0 question
> 
> 
> 
> Hello Kuntal,
> 
> Based on your example, I do not believe that the distinction 
> would case any change to the base Mobile IPv4 specification. 
> Would this be a new document within the aaa working group?
> 
> Regards,
> Charlie P.
> 
> Chowdhury, Kuntal wrote:
> 
> >Hi Charlie,
> >
> >Based on local policy the HA may have to process a new RRQ 
> differently 
> >than a re-registration. For example, the local policy may 
> not require 
> >the HA to perform AAA auth (i.e. process MN-AAA) every time the MN 
> >performs re-registration (i.e. when it has a valid binding) but the 
> >local policy requires AAA auth when there is no active binding (new 
> >RRQ).
> >
> >This is an example scenario. Is there any RFC/ID that explains the 
> >HoA=0.0.0.0 behavior for MIPv4?
> >
> >Regards,
> >Kuntal
> >
> >
> >
> >  
> >
> >>-----Original Message-----
> >>From: Charles E. Perkins [mailto:[email-masked]]
> >>Sent: Thursday, June 16, 2005 12:14 PM
> >>To: Chowdhury, Kuntal
> >>Cc: [email-masked]
> >>Subject: Re: [Mip4] HoA=0.0.0.0 question
> >>
> >>
> >>
> >>Hello Kuntal,
> >>
> >>Can you explain what difference it would make
> >>one way or the other?
> >>
> >>Regards,
> >>Charlie P.
> >>
> >>
> >>Chowdhury, Kuntal wrote:
> >>
> >>    
> >>
> >>>Hi all,
> >>>
> >>>I have a question on MIP RRQ with HoA=0.0.0.0. It is a
> >>>      
> >>>
> >>common practice in the industry today to use HoA=0.0.0.0 in
> >>the RRQ to request for a dynamic HoA assignment. The question 
> >>I have is: when the HA receives a RRQ with HoA=0.0.0.0 does 
> >>it always treat that as a NEW registration request even if 
> >>there is an unexpired mobility binding for the same NAI in the HA?
> >>    
> >>
> >>>Thanks,
> >>>Kuntal
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>
> >>    
> >>
> 
> 
> 
> -- 
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Charles E.Perkins" <[email-masked]>
Date: Thu, 16 Jun 2005 13:11:17 -0700

Hello Avi,

> at the pure MIP context it may not make a difference.

If you want to propose some text, then maybe I would
understand what the problem is.  If it doesn't make
any difference in the "pure MIP context", then I am
reluctant to make any further specification for
it within the "pure MIP context" document.

> there is an unexpired mobility binding for the same NAI in the HA?"

As far as I can tell from the discussion, a competent
engineer could build an excellent system regardless of
whether the registration request was considered "new" or not.

> use the NAI to index the binding cache.

Either of these solutions sound overly restrictive
to me, of course depending on the restraints posed
by the legacy systems involved.

Regards,
Charlie P.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Jun 2005 22:50:54 +0200

Hi Avi,

> at the pure MIP context it may not make a difference.

I think here we're at the crux of the matter: Not only doesn't it make
a difference, there really isn't a difference at the MIP level, I believe.

> there is an unexpired mobility binding for the same NAI in the HA?"

Well, since there really isn't any difference between "re-registration"
and "new registration" in MIP4, there really isn't a distinction,
protocol-wise...

> use the NAI to index the binding cache.

This seems to argue for creating a distinction, based on the value of the
HoA field, between some "new registrations" and other "re-registrations".

I'm not convinced that this is wise, and I'm not convinced it is necessary.

Possibly it could be argued that it would be advantageous to add to the
specification that:

"If there exists an active binding for the MN when a registration request
with the Home Address field set to 0.0.0.0 is received by the HA, the HA
SHOULD return the same Home Address as for the already existing binding."

But that is maybe a different matter ?

(As some background to this discussion, I coded the HA side of dynamic
address assignment some 2-3 years ago.  I found that since the HA can never
know whether the MN has been turned on and off between registrations, and
the MN really can't assume that the HA hasn't had a power outage,
malfunction, or what-not, it turned out that you really have to find a
way to handle a lot of different combinations of existing and non-existing
active bindings, 0.0.0.0 requests, and requests with old, timed-out HoAs.

Any attempt at specifying that the MN "must" use an assigned HoA when
"re-registering" ran smack into the realities of things which said that
there were no way of guaranteeing that behaviour, in the face of everything
that might happen with the MN, the HA, and the link between them ...

Or to put it in a completely different way - the randomness and
unpredictability of changing wireless links makes it a strong protocol
feature that there indeed is no difference between "new registration" and
"re-registration".)

	Henrik