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

["Kent Leung \(kleung\)" <kleung at cisco.com>]

Hi Hasse.

The draft is based on the assumption that there are commercial
deployments using Mobile IP implementations which are based on
interpretions of ambiguous specifications in RFC 2794.  Given that, any
changes to the operation of the mobility entities should be backwards
compatible.

How do you interpret when Home Address is non-zero in the RRQ with NAI
extension?  Is it a "hint" like in DHCP or a mandate (which is implied
in the discussions)?  RFC 2794 does not _specify_ which way to go.

Should re-registration include the NAI extension? Is this covered
clearly in an RFC?

I would agree with you if evidence is supplied which has explicit text
in RFC to cover the ambiguities we've identified in the draft.  I'm not
looking for interpretation of the language.  Until then, I believe we do
need new specification to clarify all the scenarios relevant to dynamic
home address assignment.

Kent



 

> -----Original Message-----
> From: Hans Sjostrand [mailto:hans at ipunplugged.com] 
> Sent: Wednesday, March 15, 2006 3:45 AM
> To: Kent Leung (kleung)
> Cc: Chowdhury, Kuntal; naveen Paulkandasamy (naveenpk); mip4 at ietf.org
> Subject: Re: [Mip4] Updated draft for Mobile IPv4 NAI-based 
> Home AddressAssignment...
> 
> 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
> 
> On 2006-03-09 02:17, Kent Leung (kleung) wrote:
> > Hi Kuntal.  Comments below. 
> >
> >   
> >> -----Original Message-----
> >> From: Chowdhury, Kuntal [mailto:kchowdhury at starentnetworks.com]
> >> Sent: Wednesday, March 08, 2006 4:00 PM
> >> To: naveen Paulkandasamy (naveenpk); mip4 at ietf.org
> >> 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: 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/