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

[Hans Sjostrand <hans at ipunplugged.com>]

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


On 2006-03-16 00:22, Kent Leung (kleung) wrote:
> 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/