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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 15 Mar 2006 15:22:45 -0800

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:[email-masked]] 
> Sent: Wednesday, March 15, 2006 1:28 PM
> To: Kent Leung (kleung); Hans Sjostrand
> Cc: naveen Paulkandasamy (naveenpk); [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, March 15, 2006 12:18 PM
> > To: Hans Sjostrand
> > Cc: Chowdhury, Kuntal; naveen Paulkandasamy (naveenpk); 
> [email-masked]
> > 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:[email-masked]]
> > > Sent: Wednesday, March 15, 2006 3:45 AM
> > > To: Kent Leung (kleung)
> > > Cc: Chowdhury, Kuntal; naveen Paulkandasamy (naveenpk);
> [email-masked]
> > > 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:[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
> > > >
> > > >
> > >
> 
> 
> 
> "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 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
> 

-- 
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: Tue, 21 Mar 2006 11:13:44 +0100

Hi Kent,

I do not think that the draft clarified some ambiguities, instead it
created ambiguities. I believe that the RFC3344 is quite clear and
leaves no ambiguity on "that HA couldn't assign a different Home Address
when the requested one"

3.7.3.1. Validity Checks
>    When a foreign agent receives a Registration Reply message, it MUST
>    search its visitor list for a pending Registration Request with the
>    same mobile node home address as indicated in the Reply.  If no such
>    pending Request is found, and if the Registration Reply does not
>    correspond with any pending Registration Request with a zero mobile
>    node home address (see section 3.7.1), the foreign agent MUST
>    silently discard the Reply. 

If you want to create another draft to clarify this again, please feel
free. But do not alter the MUST statements in RFC3344.

Best regards
/// Hasse

---

From: Hans Sjostrand <[email-masked]>
Date: Tue, 21 Mar 2006 11:31:14 +0100

Hi Kent,

After re-reading my message I noticed that the tone was very harsh. That
was not my intention and I apologize for it.

I just wanted to clarify my position on HoA==0 and HoA!=0 and I think
that it's important that we don't re-classify those basic indicators.

I think it's admirable to do an effort to clarify, educate and improve
interoperability. Sorry if I just complained, instead of contributing.

Best regards
/// Hasse