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

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 14 Mar 2006 05:20:16 -0800

Hi Naveen, comments inline....look for "GT>"

-----Original Message-----
From: Naveen Paulkandasamy [mailto:[email-masked]] 
Sent: Monday, March 13, 2006 8:56 PM
To: Tsirtsis, George
Cc: Kent Leung; [email-masked]
Subject: Re: [Mip4] Updated draft for Mobile IPv4 NAI-basedHome
AddressAssignment...

Hi George,

appreciate your comments on the draft!

please see inline at [NAV]...

Tsirtsis, George wrote:

>Hi Naveen/Kent, 
>
>This is a good and well overdue draft...we have been dancing around
>these issues in the field for long time and it will be good to have at
>last some clarity.
>
>In section 7.1.2 you require that the MN includes the Dynamic-HoA
>extension in all re-registrations. Why is that? This makes it hard for
>the HA to differentiate between the MN requesting address allocation
>with a preferred address from the case where the MN has already been
>allocated an address.
>
>
>For example consider Case 2 of Section 6.1:
>
>"    Scenario    : HA reboots after a MN successfully registered and 
>                  then receives a re-registration from the MN and the 
>                  HA is unable to assign the RRQ(HoA) to the MN.."
>
>In this case you say:
>
>"    HA Behavior : The HA MUST try to assign an alternative address and

>                  if successful, it MUST create a new binding entry and

>                  MUST return a RRP with HoA containing the alternative

>                  address. If the HA is unable to assign an alternative

>                  address, it MUST return a RRP with the code 
>                  ADDR_ALLOC_FAILED and RRP(HoA) set to 0.0.0.0.   "
>
>Changing the address of the MN when the MN has not explicitly requested
>such action sounds like a bad idea to me.  
>
>Have you considered immediately returning a RRP with a different error
>code, say something like "ADDR_UNAVAILABLE", instead of attempting to
>reallocate an address? If the HA indicates what happened, the MN is
then
>free to do as it sees fit, including going through another registration
>in which it includes the Dynamic-HoA extension leading to the desired
>result. 
>
>  
>
[NAV] the idea behind including the Dynamic-HoA extension in all 
re-registrations is
 as follows. basically in the HA reboot case, there are two possible 
actions that the MN can take,
when the HA informs the MN that it cannot support the MN's old HoA
anymore:

(i) the MN can request a new HoA from the HA using Dynamic-HoA as per 
this draft.
(ii) the MN can resort to some other means and prefers not to get its 
HoA from the HA immediately ?

we felt that, case (i) might be more common than (ii) and so, we 
preferred to optimize case (i)

GT> It is not always a good or necessary to optimize error cases
especially if it obfuscates what happened. The MN may have other choices
e.g, it may have other HAs it can use or who knows what else. We should
not assume we are aware of all possible scenarios here. The e2e
principle says that you do not take decisions on behalf of the end node.
Tell the end node what happened and it will figure it out. This is
always a more robust solution.

to avoid the extra RRQ round trip by just letting the HA allocate the 
address if the old HoA
is not available. and in the case where the MN received a new HoA but 
wants to follow case (ii),
it can deregister the new HoA with an additional deregistration, which 
we felt was okay, if this
does not happen to be in the majority of the cases.

so, we think, it would be helpful to know more opinions from you and the

group on
- what are the possible other actions that the MN can resort to, in the 
case (ii) scenario ? and,
-  which scenario (case (i) or (ii)) would be the most common scenario 
so that we can optimize
or default to it?

also, if there is a consensus that, we want the MN to choose  the HA 
behavior and make
case (ii) as the default , then we can  change the MN behavior  to :

(i) can include the Dynamic-HoA extn in the RRQ, if it wants it address 
reassigned whenever
 the HA cannot support the MN's old HoA.

(ii) can exclude the Dynamic-HoA extn in the RRQ and follow the default 
RFC 3344 behavior,
if it wants the HA  to reject the  RRQ with a error code (as per rfc 
3344 for downward
compatibility since the HA would not know if the MN is compliant with 
this draft, if it
has lost its previous binding ?) and the MN can then send a RRQ again
with
Dynamic-HoA if  needed ?

GT> Yes, this is better than my suggestion of a new code for backward
compatibility reason.

please let us know what you think...

thanks,
naveen.

>Thoughts?
>
>George
>
>-----Original Message-----
>From: Naveen Paulkandasamy [mailto:[email-masked]] 
>Sent: Wednesday, March 08, 2006 5:14 PM
>To: [email-masked]
>Cc: Kent Leung
>Subject: [Mip4] Updated draft for Mobile IPv4 NAI-based Home
>AddressAssignment...
>
>Hi All,
>
>we have submitted the updated draft for Mobile IPv4 NAI-based Home 
>Address Assignment
>based on the comments received for the last version... please let us 
>know your comments...
>
>http://www.ietf.org/internet-drafts/draft-paulkandasamy-mobileip-nai-ba
s
>ed-home-addres-01.txt
>
>Abstract 
>  
>    With the introduction of NAIs for identifying Mobile Nodes, RFC 
>    2794 also enabled the Home Agents to be able to assign IP addresses

>    to Mobile Nodes during their initial registration. Though the 
>    concept of NAI-based home address assignment is referenced in both 
>    RFC 2794 and RFC 3344, a comprehensive procedure for achieving such

>    a NAI-based home address assignment has not been outlined. More 
>    particularly, the Home Agent and Mobile Node behaviors including 
>    the error recovery mechanisms for various scenarios related to NAI-
>    based home address assignment have not yet been specified. This 
>    document specifies a procedure that the Mobile IP entities should 
>    follow in order to facilitate NAI-based home address assignment 
>    under various circumstances. 
>
>thanks,
>naveen.
>
>  
>

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

-- 
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: "Tsirtsis, George" <[email-masked]>
Date: Wed, 15 Mar 2006 04:56:25 -0800

It is true that just with error codes we get most of what is needed
here. 

What the new extension offers is the ability for the MN to request a
specific IP address during address allocation phase. Without the
proposed extension the registration will have to fail and the MN will
have to reregister with HoA=0.0.0.0. This is an optimization that may
not warranty a new extension.

George 

-----Original Message-----
From: Hans Sjostrand [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 6:45 AM
To: Kent Leung (kleung)
Cc: naveen Paulkandasamy (naveenpk); Chowdhury,Kuntal; [email-masked]
Subject: Re: [Mip4] Updated draft for Mobile IPv4 NAI-basedHome
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. 
>
>   
>> 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
>
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 16 Mar 2006 11:20:24 -0800

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 6:23 PM
To: Chowdhury, Kuntal; Hans Sjostrand
Cc: naveen Paulkandasamy (naveenpk); [email-masked]
Subject: RE: [Mip4] Updated draft for Mobile IPv4 NAI-basedHome
AddressAssignment...

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.

GT> I am not sure this is a good idea though. I think Hans argued
against this too. As I said earlier it is better to let the mobile know
that something went wrong and let it decide what to do about it. 

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

GT> I am not sure this can be achieved. 

GT> The only backwards compatible option I can think of is to write a
BCP type section/spec where we indicate how the MN should use the NAI
with HoA==0 and HoA!=0. We should also suggest which of the existing
error codes should be used by the HA if the binding can not be accepted
(e.g., 129 administratively prohibited)

GT> If we introduce a new error code from the HA region (129-192) then
existing mobiles will know that the HA rejected the binding but they
will not know why. Do you have a sense of how current implementations
react in this case?

GT> To truly make this backwards compatible we will need an extension
from the MN to at least indicate that it knows of the new specification
in which case the extension Kent/Naveen propose is as good as anything.

George

> Sent: Wednesday, March 15, 2006 1:28 PM
> To: Kent Leung (kleung); Hans Sjostrand
> Cc: naveen Paulkandasamy (naveenpk); [email-masked]
> Kent,
> Please see my comments inline...
> 
> > 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
> > 
> > 
> > 
> > 
> > 
> > > 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.
> > >
> > > "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
> > >
> > > >> Subject: RE: [Mip4] Updated draft for Mobile IPv4 
> NAI-based Home 
> > > >> AddressAssignment...
> > > >>
> > > >> "
> > > assignment, then
> > > >> the
> > > figure it
> > > >> out?
> > > > backward compatible since there are implementations based on 
> > > > interpretation of RFC 2794, which lacked some details.  
> These were 
> > > > identified in the draft.
> > > >
> > > >
> > > >
> > > >> "
> > > indicating that
> > > >> the
> > > >>     mobile node is capable of dynamic home address assignment,
> the
> > > >> home
> > > >> 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.
> > > >>
> > > >>
> > > >
> "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."
>