Subject: RE: [Mip4] HoA=0.0.0.0 question

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 21 Jun 2005 14:34:32 -0400

> -----Original Message-----
> From: Kent Leung (kleung) [mailto:[email-masked]]
> Sent: Tuesday, June 21, 2005 11:12 AM
> To: Chowdhury, Kuntal; Pete McCann; Avi Lior
> Cc: [email-masked]; Henrik Levkowetz; Charles E.Perkins
> Subject: RE: [Mip4] HoA=0.0.0.0 question
> 
> 
>  
> 
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:[email-masked]] 
> > Sent: Tuesday, June 21, 2005 8:22 AM
> > To: Kent Leung (kleung); Pete McCann; Avi Lior
> > Cc: [email-masked]; Henrik Levkowetz; Charles E.Perkins
> > Subject: RE: [Mip4] HoA=0.0.0.0 question
> > 
> > > So maybe a better scheme to deal with this is using RFC 
> > 3543?  When MN 
> > > is truly disconnected, FA sends revocation to the HA to 
> remove the 
> > > binding.  Then it's always clear when there is a NEW 
> > session since old 
> > > bindings don't hang around long.
> > 
> > As always, there are holes in every proposal. What if the 
> > revocation message is lost (never reached the HA)? 
> > 
> 
> The messages support ack/retransmissions.
> 

That does not guarantee anything. Links can be in a down state for a while, right?

> 
> > > Note that I would still set HoA=0 for every RRQ on the MN 
> > to save some 
> > > $ for time-based billing.  :)
> > 
> > Yes, you can...but if you do that you run the risk of getting 
> > a different address (HoA) every time you send an RRQ. This is 
> > because, the HAs may treat the HoA=0 as a new registration, 
> > therefore tear down the old binding and admit a new binding 
> > and assign a new HoA. This may break your 
> > applications/sessions. To save a few cents you will cause 
> > yourself more pain in that case. Besides, it does not take 
> > too much time for the operators to figure out revenue leaks.
> > 
> 
> But since the MN knows the reg lifetime, it can send RRQ with HoA=0
> before expiration so the chance is good that mobility binding 
> exists if
> HA is functioning properly.  And HA has to consider the case when MN
> moves to a black-out area and provide the same HoA to MN whenever
> possible - the benefits of same HoA.
> 

MN's knowledge of the reg-lifetime won't save it from getting a new HoA if it uses HoA=0 in every RRQ. Please note that this discussion did not start based on how HAs should do address management. Rather the aim here is to define a way to distinguish registrations from re-registrations so that the HAs can apply N-number of local policies (including interaction with the AAA) on the MIP sessions.

> Kent
> 
> 
> > Ideally, what MIP4 WG should do, IMHO:
> > 
> > a. Define a reliable way to distinguish registrations from 
> > re-registrations.
> > b. Define a reliable way to distinguish registrations from 
> > retransmitted registrations when Timestamp based ID is used. 
> > (In some situations, the network nodes (FA, HA, AAA) get 
> > pounded due to too frequent retransmissions of RRQs.
> > 
> > -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/

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 21 Jun 2005 21:59:15 +0200

[Kent]
>>>> $ for time-based billing.  :)

This is a good point, and underlines the fact that it's pretty
absurd to leave it up to the MN to signal, directly or indirectly,
how and when it will be authenticated or billed.

[Kuntal]
>>> Yes, you can...but if you do that you run the risk of getting a
>>> different address (HoA) every time you send an RRQ. This is 
>>> therefore tear down the old binding and admit a new binding and
>>> assign a new HoA. This may break your applications/sessions. To
>>> save a few cents you will cause yourself more pain in that case.
>>> Besides, it does not take too much time for the operators to
>>> figure out revenue leaks.
>>> 

You only run that risk with a fairly incompetent implementation of
dynamic HoA assignment.  An implementation which e.g. uses the
mechanisms defined by and for DHCP will not make this mistake, and
re-designing Mobile-IP because it would be possible to implement the
dynamic address assignment feature in an incompetent manner seems
a bit unnecessary.

[Kent]
>> exists if HA is functioning properly.  And HA has to consider the
>> case when MN moves to a black-out area and provide the same HoA to
>> MN whenever possible - the benefits of same HoA.
>> 

Correct

[Kuntal]
> MN's knowledge of the reg-lifetime won't save it from getting a new
> HoA if it uses HoA=0 in every RRQ. Please note that this discussion
> did not start based on how HAs should do address management. Rather
> the aim here is to define a way to distinguish registrations from
> re-registrations so that the HAs can apply N-number of local policies
> (including interaction with the AAA) on the MIP sessions.
> 

I'm sorry to say this, but it seems to me, Kuntal, that you've decided
that you want a certain solution, without being willing to take a step
back and look at the broader picture and re-evaluate your options.

As said above, a good implementation of dynamic address allocation will
provide the same address if at all possible, even if the registration
has lapsed meanwhile.

However, your statement that the aim is to define a way to distinguish
registrations from re-registrations is based on a belief that 1) this
makes sense, and 2) it is possible.

I've tried to say that both of these may be false, and in order to
progress, could you please explain in more detail what it is you
actually require?  

Could it be that doing something as simple as monitoring the CoA, and
apply certain policies every time the CoA changes, would help you?

Or maybe it is more appropriate to apply a policy every time a
registration is done when there is no currently active binding?

I believe there are many valid state changes available to trigger
policy application off, without redesigning the protocol.

	Henrik