Subject: RE: [mobile-ip] Re: RFC3220 and possible forward compatibility is sue "Dynamic Home Agent Allocation"

From: "Ahmad Muhanna"<[email-masked]>
Date: Tue, 2 Apr 2002 12:21:32 -0600

Hi, Kent,
Thanks for your input.
Please see my comments inserted below.

Regards;
Ahmad Muhanna

> -----Original Message-----
> From: kleung [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2002 11:34 AM
> To: [email-masked]
> Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Pete McCann'; Nickell, Kent
> [RICH2:2Q20:EXCH]; Basavaraj Patil (NTC/Dallas); Phil Roberts
> Subject: Re: [mobile-ip] Re: RFC3220 and possible forward 
> compatibility
> issue "Dynamic Home Agent Allocation"
> 
> 
> Sorry folks.  Somehow I misread the text and assumed it was about
> the unicast IP address.
> 
> Comments below...
> 
> "Charles E. Perkins" wrote:
> 
> > Hello folks,
> >
> > May I assume that this corrective text is acceptable to
> > everyone concerned?  I would like to incorporate the necessary
> > revisions and reissue RFC3220bis soon.  Is there any impact
> > on RFC3012bis?
> >
> > Regards,
> > Charlie P.
> >
> > >      Proposed TEXT:
> > >       Section 3.8.2.2:
> > >      "
> > >         If the Home Agent field in the Registration 
> Request contains a
> > >         unicast address of this home agent, then that 
> field MUST be copied
> > >         into the Home Agent field of the Registration 
> Reply.  Otherwise, the
> > >         home agent MUST set the Home Agent field in the 
> Registration Reply to
> > >         its unicast address.  In this latter case and 
> only if this IP packet
> > >      was distant
> > >         to either the subnet-directed broadcast or 
> 255.255.255.255, the home
> > >      [Muhanna, Ahmad]
> > >      I meant "In this latter case and only if this IP 
> packet was destined to
> > >      either
> > >      the subnet-directed broadcast or 255.255.255.255, 
> the home .."
> > >
> 
> What about 0.0.0.0?
> 
> Isn't the current language already saying that in the non-unicast
> case, set the HA field and reject?  This non-unicast address broadly
> covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0.
> 
> "If the Home Agent field in the Registration Request contains a
> unicast address of this home agent, ....  Otherwise, the
> home agent MUST set the Home Agent field in the Registration Reply to
> its unicast address.  In this latter case, ..."
> 
> I don't have a problem with listing out specific IP addresses 
> in the spec,
> just not sure if it's really needed.
> 
> Thanks.
> 
> Kent

Well, I do not think that we can send any IP packet to a destination IP
address of 0.0.0.0.
It is possible that my text is not very clear. 
What I meant by destined is 
"The destination IP address in the IP packet (which contains the RRQ
message) is set to 
either the subnet-directed broadcast or 255.255.255.255."

I hope this clarifies the issue.
Thanks;

Ahmad
 
> 
> 
> >
> > >         agent MUST reject the registration with a 
> suitable code (e.g., Code
> > >      136)
> > >         to prevent the mobile node from possibly being 
> simultaneously
> > >      registered
> > >         with two or more home agents.
> > >      "
> > >
> > >      Thanks for consideration.
> > >
> > >      Regards;
> > >      Ahmad Muhanna
> 
>

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 3 Apr 2002 11:24:09 -0600

Hello,
> 
> 
> Hi,
> 
> Kent Leung writes:
> 
>  >    If the Home Agent field in the Registration Request contains a
>  >    unicast address of this home agent, then that field MUST be
>  >    copied into the Home Agent field of the Registration Reply.
>  >    Otherwise, the home agent MUST set the Home Agent field in the
>  >    Registration Reply to its unicast address.  In this latter
>  >    case, the Home Agent MUST reject the request with a suitable
>  >    code (e.g., Code 136) unless the destination IP address of the
>  >    Registation Request is an unicast address.  In this case, the
>  >    Home Agent MAY accept the Registration Request.  This will
>  >    prevent the mobile node from possibly being simultaneously
>  >    registered with two or more home agents.
> 
> 
> Ahmad Muhanna writes:
> 
>  >   If the Home Agent field in the Registration Request contains a
>  >   unicast address of this home agent, then that field MUST be
>  >   copied into the Home Agent field of the Registration Reply.
>  >   Otherwise, the home agent MUST set the Home Agent field in the
>  >   Registration Reply to its unicast address.  In this latter case,
>  >   the home agent MUST reject the registration with a suitable code
>  >   (e.g., Code 136) to prevent the mobile node from possibly being
>  >   simultaneously registered with two or more home agents. However,
>  >   if the destination IP address of the Registration Request is
>  >   the unicast IP address of this Home Agent, the Home Agent MAY
>  >   accept the Registration Request.
> 
> I think it is important to at least apply Ahmad's restriction that the
> IP destination address of the RRQ belongs to the HA, so I would go
> along with this text.  Question for the group: is this enough to
> prevent simultaneous registration with two or more home agents?  The
> original logic of rejecting the request if the HA field didn't match a
> unicast address was definitely stronger than this.  Was there a reason
> for that?
> 
> -Pete
> 

The original scenario depends on preventing simultaneous registration by
using a two round trip initial Registration. The objective of these two
trips 
as all of us know are as follows:

First Round Trip:
It addresses the issue of identifying a Dynamically located HA IP address
for the Mobile Node to use
and prevents simultaneous registration.

Second Round Trip:
It is the regular initial Registration the Mobile Node usually does to
establish 
a Mobile IP call.

Now: with the availability of other Helping infrastructure to the Mobility
agents 
(Diameter, RADIUS), it becomes ineffective and expensive to use 
two round trips for establishing a Mobile IP call.

Therefore, I believe that the First Round Trip of the initial Registration
MUST be handled
all together BY the helping infrastructure.
In other words, (DIAMETER, or RADIUS) Dynamically allocate an HA and prevent
simultaneous registration.