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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 8 Mar 2006 17:17:39 -0800

Hi Kuntal.  Comments below. 

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 4:00 PM
> To: naveen Paulkandasamy (naveenpk); [email-masked]
> Cc: Kent Leung (kleung)
> Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-based 
> Home AddressAssignment...
> 
> "
> If the home address field is 0.0.0.0 and the request has a NAI 
>     extension as well the Dynamic-HoA extension, indicating that the 
>     mobile node is capable of dynamic home address 
> assignment, then the 
>     home agent tries to assign a new address for the mobile node and 
>     return a reply with the home address field containing the 
> assigned 
>     address. If the home agent is unable to assign an address, it 
>     rejects the request with the code ADDR_ALLOC_FAILED. 
> "
> 
> HoA=0.0.0.0 in the RRQ means the MN is dynamic HoA capable. 
> So, why any other extension would be needed for the HA to 
> figure it out? 
>     

The HoA field was overloaded with both dynamic address assignment flag
and HoA of the MN.  The new extension is used to specify the logic
described in this draft for dynamic address assignment, and be backward
compatible since there are implementations based on interpretation of
RFC 2794, which lacked some details.  These were identified in the
draft.

> "
>     If the home address field is non-zero and the request has a NAI 
>     extension as well as the Dynamic-HoA extension, 
> indicating that the 
>     mobile node is capable of dynamic home address 
> assignment, the home 
>     agent tries to assign the requested address specified in the home 
>     address field and return the same address in the reply. 
> If the home 
>     agent is unable to assign the requested address, the home agent 
>     tries to assign an alternative address and return the alternative 
>     address in the reply. If the home agent is unable to assign an 
>     alternative address, it rejects the request with the code 
>     ADDR_ALLOC_FAILED.  
> 
> "
> 
> It seems you are proposing to piggyback MN's capability hint 
> with Dynamic-HoA extension. But, the I-D is about using NAI 
> extension to assist HA to process the RRQ. Hence, I am 
> confused about the role of NAI here. If the NAI is known, the 
> HA can contact the AAA to and download user/MN specific info 
> which may very well include MN's capability (i.e.
> whether the MN can handle dynamically assigned HoA). That is 
> more in-line with the goal of the I-D, I think.
> 

The intent is not the MN's capability.  I think the confusion is the
wording of "
mobile node is capable of dynamic home address".  What's meant is that
MN is requesting dynamic home address assignment as indicated in the
Dynamic-HoA extension.

Kent

-- 
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: Hans Sjostrand <[email-masked]>
Date: Wed, 15 Mar 2006 12:44:30 +0100

Hi Kent,

I agree with Kuntal, I can't see any reason why adding a new extension
is needed  ?

There are a problem, and that is that there are no specific error code
for address management errors. Henrik started to address that problem
last year when requested additional error codes. Don't know exactly what
happened with the code points after that.

But a new extension is a overkill solution to a problem that atleast I
can't understand from reading the draft. The existing 3344 and 2794
mechanisms are enough in the cases I've seen. Although the RFC's lack
some implementation detail on how this could be achieved. Thats
understandable.

Starting to assign new addresses instead of the ones requested, thus
breaking RFC3344, is a bad idea for a number of reasons. Using some 
"ADDR_ALLOC_FAILED" error code and then let the MN retry with 0.0.0.0 is
a lot better. And no new extension or new specification at all is needed.

Regards
/// Hasse