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

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 13 Mar 2006 09:57:52 -0800

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. 

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-bas
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: Naveen Paulkandasamy <[email-masked]>
Date: Mon, 13 Mar 2006 17:56:04 -0800

Hi George,

appreciate your comments on the draft!

please see inline at [NAV]...

>in which it includes the Dynamic-HoA extension leading to the desired
[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)
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 ?

please let us know what you think...

thanks,
naveen.