Re: [Mip4] Updated draft for Mobile IPv4 NAI-based Home AddressAssignment...

[Naveen Paulkandasamy <naveenpk at cisco.com>]

Hi George,

appreciate your comments on the draft!

please see inline at [NAV]...

Tsirtsis, George wrote:

> Hi Naveen/Kent, 
>
> This is a good and well overdue draft...we have been dancing around
> these issues in the field for long time and it will be good to have at
> last some clarity.
>
> In section 7.1.2 you require that the MN includes the Dynamic-HoA
> extension in all re-registrations. Why is that? This makes it hard for
> the HA to differentiate between the MN requesting address allocation
> with a preferred address from the case where the MN has already been
> allocated an address.
>
>
> For example consider Case 2 of Section 6.1:
>
> "    Scenario    : HA reboots after a MN successfully registered and 
>                  then receives a re-registration from the MN and the 
>                  HA is unable to assign the RRQ(HoA) to the MN.."
>
> In this case you say:
>
> "    HA Behavior : The HA MUST try to assign an alternative address and 
>                  if successful, it MUST create a new binding entry and 
>                  MUST return a RRP with HoA containing the alternative 
>                  address. If the HA is unable to assign an alternative 
>                  address, it MUST return a RRP with the code 
>                  ADDR_ALLOC_FAILED and RRP(HoA) set to 0.0.0.0.   "
>
> Changing the address of the MN when the MN has not explicitly requested
> such action sounds like a bad idea to me.  
>
> Have you considered immediately returning a RRP with a different error
> code, say something like "ADDR_UNAVAILABLE", instead of attempting to
> reallocate an address? If the HA indicates what happened, the MN is then
> free to do as it sees fit, including going through another registration
> in which it includes the Dynamic-HoA extension leading to the desired
> result. 
>
>  
[NAV] the idea behind including the Dynamic-HoA extension in all 
re-registrations is
as follows. basically in the HA reboot case, there are two possible 
actions that the MN can take,
when the HA informs the MN that it cannot support the MN's old HoA anymore:

(i) the MN can request a new HoA from the HA using Dynamic-HoA as per 
this draft.
(ii) the MN can resort to some other means and prefers not to get its 
HoA from the HA immediately ?

we felt that, case (i) might be more common than (ii) and so, we 
preferred to optimize case (i)
to avoid the extra RRQ round trip by just letting the HA allocate the 
address if the old HoA
is not available. and in the case where the MN received a new HoA but 
wants to follow case (ii),
it can deregister the new HoA with an additional deregistration, which 
we felt was okay, if this
does not happen to be in the majority of the cases.

so, we think, it would be helpful to know more opinions from you and the 
group on
- what are the possible other actions that the MN can resort to, in the 
case (ii) scenario ? and,
-  which scenario (case (i) or (ii)) would be the most common scenario 
so that we can optimize
or default to it?

also, if there is a consensus that, we want the MN to choose  the HA 
behavior and make
case (ii) as the default , then we can  change the MN behavior  to :

(i) can include the Dynamic-HoA extn in the RRQ, if it wants it address 
reassigned whenever
the HA cannot support the MN's old HoA.

(ii) can exclude the Dynamic-HoA extn in the RRQ and follow the default 
RFC 3344 behavior,
if it wants the HA  to reject the  RRQ with a error code (as per rfc 
3344 for downward
compatibility since the HA would not know if the MN is compliant with 
this draft, if it
has lost its previous binding ?) and the MN can then send a RRQ again with
Dynamic-HoA if  needed ?

please let us know what you think...

thanks,
naveen.

> Thoughts?
>
> George
>
> -----Original Message-----
> From: Naveen Paulkandasamy [mailto:naveenpk at cisco.com] 
> Sent: Wednesday, March 08, 2006 5:14 PM
> To: mip4 at ietf.org
> Cc: Kent Leung
> Subject: [Mip4] Updated draft for Mobile IPv4 NAI-based Home
> AddressAssignment...
>
> Hi All,
>
> we have submitted the updated draft for Mobile IPv4 NAI-based Home 
> Address Assignment
> based on the comments received for the last version... please let us 
> know your comments...
>
> http://www.ietf.org/internet-drafts/draft-paulkandasamy-mobileip-nai-bas
> ed-home-addres-01.txt
>
> Abstract 
>  
>    With the introduction of NAIs for identifying Mobile Nodes, RFC 
>    2794 also enabled the Home Agents to be able to assign IP addresses 
>    to Mobile Nodes during their initial registration. Though the 
>    concept of NAI-based home address assignment is referenced in both 
>    RFC 2794 and RFC 3344, a comprehensive procedure for achieving such 
>    a NAI-based home address assignment has not been outlined. More 
>    particularly, the Home Agent and Mobile Node behaviors including 
>    the error recovery mechanisms for various scenarios related to NAI-
>    based home address assignment have not yet been specified. This 
>    document specifies a procedure that the Mobile IP entities should 
>    follow in order to facilitate NAI-based home address assignment 
>    under various circumstances. 
>
> thanks,
> naveen.
>
>  

--
Mip4 mailing list: Mip4 at ietf.org
   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/