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

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

Hi Kuntal.

So let me try explain our original goal in the draft, which was
published back in 
Mar 25, 2004.

The draft clarified some of the ambiguities in RFC 2794.  Since we
weren't clear how the spec was interpreted in implementations, we
decided to introduce the new extension to specify exactly how the
mobility entities should operate for dynamic home address assignment and
still be backward compatible to existing behavior.  Nothing in RFC 2794
say that that HA couldn't assign a different Home Address when the
requested one is in use.  If someone was already taking advantage of
such a feature, we didn't want to break that.

I'm fine with avoiding the new extension if we can still achieve
backward compatability.  Suggestions welcomed and always appreciated. :)

Kent 

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:kchowdhury at starentnetworks.com] 
> Sent: Wednesday, March 15, 2006 1:28 PM
> To: Kent Leung (kleung); Hans Sjostrand
> Cc: naveen Paulkandasamy (naveenpk); mip4 at ietf.org
> Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-based 
> Home AddressAssignment...
> 
> Kent,
> 
> Please see my comments inline...
> 
> > -----Original Message-----
> > From: Kent Leung (kleung) [mailto:kleung at cisco.com]
> > Sent: Wednesday, March 15, 2006 12:18 PM
> > To: Hans Sjostrand
> > Cc: Chowdhury, Kuntal; naveen Paulkandasamy (naveenpk); 
> mip4 at ietf.org
> > Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-based Home 
> > AddressAssignment...
> > 
> > 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.
> > 
> [KC>] Yes, breaking existing/deployed implementations should 
> be avoided.
> 
> > 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.
> > 
> [KC>] NAI extension should be included regardless of the 
> value in the HoA field, IMHO. NAI is a good way to identify 
> the user, simply including HoA may not be sufficient to 
> identify the user. So, I would prefer to de-couple the use of 
> NAI from HoA value in the MIP messages.
> Regarding HoA,
> HoA=0.0.0.0 means: the MN is requesting a dynamic HoA 
> assignment. HoA= non-zero address means: the MN is requesting 
> the HA to assign the specified non-zero address. 
> 
> I am OK if you want to clarify this in the I-D. Do you need 
> anything more for the purpose of clarification?
> 
> > Should re-registration include the NAI extension? Is this covered 
> > clearly in an RFC?
> > 
> [KC>] Yes. It is OK to clarify this in an IETF document.
> 
> > 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.
> > 
> [KC>] Sure, if something is ambiguous, we should clarify it. 
> But, we should be very careful about not introducing new 
> concepts along with this clarification exercise.
> 
> 
> > 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
> > > >
> > > >
> > >
> 
> 
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> postmaster at starentnetworks.com -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
> 

--
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/