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 18:16:00 -0600

Hello Pete/Kent;

I agree, however some fine tuning to a simpler text below.

> 
> 
> 
> Pete McCann wrote:
> 
> > If I may summarize, you are proposing that the HA base its 
> decision on
> > whether to accept or reject the request not only on the contents of
> > the HA field but also on the contents of the IP destination 
> address of
> > the Registration Request.  Both the existing and proposed texts
> > mandate that an HA reject requests that were subnet-directed
> > broadcast, if they contain an HA address that doesn't match 
> one of the
> > unicast interfaces of the HA.  However, you are proposing 
> that the HA
> > be allowed to respond successfully to Registration Requests 
> no matter
> > what the content of the HA field, as long as they were not
> > subnet-directed broadcast.  I am not sure this is entirely safe.
> >
> 
> Thanks for the clarification.  Though just a little disagreement over
> the intention.  :)
> 
> To keep scheme safe, my proposal follows below.
> 
> 
> >
> > Rather, I would propose something like the following:
> >
> >    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 Home Agent can
> >    determine by means outside the scope of this document (e.g., by
> >    receiving the Registration Request from a trusted authenticating
> >    entity) that it has been allocated to service the 
> registration and
> >    that no other Home Agent will receive the same request.  This
> >    will prevent the mobile node from possibly being simultaneously
> >    registered with two or more home agents.  In case such a
> >    determination is made, the Home Agent MAY respond successfully if
> >    the Registration Request is otherwise valid.
> >
> 
>    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.
> 
> How does this sound?  Was this the intent?
> 
> Kent
> 
> 

   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.

Ahmad Muhanna

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Apr 2002 10:14:36 -0600 (CST)

Hi,

Kent Leung writes:

 >    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

Ahmad Muhanna writes:

 >   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

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

---

From: kleung <[email-masked]>
Date: Wed, 03 Apr 2002 08:59:42 -0800

Pete McCann wrote:

> along with this text.

Agreed.

> Question for the group: is this enough to
> prevent simultaneous registration with two or more home agents?

Using a unicast destination IP address in the Registration Request
with non-unicast HA address field is already being used in
implementations.
This scheme should not result in multiple HAs being registered
since mobility entity directing the Registration Request via a unicast
destination IP address either knows or was told which specific HA
is anchoring the MN.

> The

I think the original focus was subnet directed broadcast scheme.  This
translated to subnet directed broadcast destination IP address, which
meant that multiple HAs will receive the same Registration Request.
And it made more sense for each HA to reject so MN can select one
from the subnet.

Now, folks have gotten shrewder with schemes that select the HA
via the unicast destination IP address.  At that point, it seems senseless

to reject the request which creates 2 trips needlessly.

Kent