Re: [Mip4] DHCP vs FA

[Hans Sjostrand <[e-mail]>]

There are some other reasons aswell,

1. Speed
The mobile needs to make choices when discovering a visited network. The 
FA solicitation-advertisement is normally a lot faster than the dhcp 
process. So, the mobile of course uses the first available way to 
register and only uses a secondary mechanism such as collocated CoA 
(CCoA) if it has a reason (e.g. fails with the FA with a reason that is 
recoverable).

2. Convenience
Very often where there are a visiting network with DHCP and FA, 
authentication is required. And in quite a few times outside the lab, 
web-authentication is used for the dhcp people, and mip's fa 
authentication is used for the mip capable people. In the fa case the 
authentication is automatic and requires no user intervention. In the 
dhcp case, the mobile doesn't go anywhere until the owner has filled in 
a web form.

So, together with all the other reasons mentioned by the people on the 
list, I see no reason at all for a MN to wait for the CCoA case if there 
are usable FA around.

regards
/// Hasse

Arun SG wrote:
> I thought that the tunnel from HA anyway exists. It's the end point at
> the other end [whether the mobile or the FA] that is negotiated by the
> "R" bit; from Kent's mail, the answer seems to be that the mobile
> prefers the FA to be the end point - the reason for which I'm trying to
> understand...
> Thx,
> Arun
>
> -----Original Message-----
> From: Sri Gundavelli [mailto:[e-mail]] 
> Sent: Monday, January 08, 2007 11:37 AM
> To: Arun SG
> Cc: Kent Leung (kleung); Behcet Sarikaya; [e-mail]
> Subject: RE: [Mip4] DHCP vs FA
>
>
> For CCOA mode, the home agent needs to have a unique tunnel for each
> mobile and that has a bearing on the resources when compared to the
> FA-COA mode. This could be one other reason.
>
> Sri
>
>
> On Mon, 8 Jan 2007, Arun SG wrote:
>
>   
>> Just curious about the probable reason for the typical [or default] 
>> behaviour of the MIP client - why it prefers FA CoA mode over Ccoa, 
>> since if FA does not mandate registration, the MIP Client might very 
>> well register directly at HA. Is it to do with accounting at FA or 
>> something  different?
>>
>> Thanks,
>> Arun
>>
>>
>>
>> -----Original Message-----
>> From: Kent Leung (kleung) [mailto:[e-mail]]
>> Sent: Friday, January 05, 2007 11:48 PM
>> To: Sri Gundavelli (sgundave); Behcet Sarikaya
>> Cc: [e-mail]
>> Subject: RE: [Mip4] DHCP vs FA
>>
>> Right.  Though typically the MIP client tend to favor the FA CoA mode 
>> of operation in this case.
>>
>> Kent
>>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave)
>> Sent: Thursday, January 04, 2007 2:51 PM
>> To: Behcet Sarikaya
>> Cc: [e-mail]
>> Subject: Re: [Mip4] DHCP vs FA
>>
>>
>> If the "R" bit is the agent advertisement is not set, it is up to the 
>> mobile to decide on the FA-COA or CCOA mode of registration.
>>
>> Sri
>>
>> On Thu, 4 Jan 2007, Behcet Sarikaya wrote:
>>
>>     
>>> Hi all,
>>>  I was reading RFC 3344 and noticed that it is not clear on the 
>>> choice
>>>       
>>> between the co-located care-of address mode using DHCP and FA 
>>> provided
>>>       
>> care-of address mode of operation. If MN does get a co-located care-of
>>     
>
>   
>> address and there is an FA what happens then?
>>     
>>> If this had been discussed in the past, I'll appreciate if someone 
>>> can
>>>       
>> summarize the conclusion.
>>     
>>> Regards,
>>>
>>> --behcet
>>>
>>> ----- Original Message ----
>>> From: McCann Peter-A001034 <[e-mail]>
>>> To: [e-mail]
>>> Sent: Thursday, January 4, 2007 4:03:26 PM
>>> Subject: RE: [Mip4] I-D
>>> ACTION:draft-ietf-mip4-mobike-connectivity-02.txt
>>>
>>>
>>> Thanks Vijay for submitting a new version.
>>>
>>> Can the people who raised issues please check this version to see 
>>> that
>>>       
>>> they were addressed?
>>>
>>> If there are no further issues we will proceed to send this version 
>>> up
>>>       
>>> to the IESG.
>>>
>>> -Pete
>>>
>>> [e-mail] wrote:
>>>       
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.
>>>> This draft is a work item of the Mobility for IPv4 Working Group of 
>>>> the IETF.
>>>>
>>>>     Title        : Secure Connectivity and Mobility using Mobile
>>>>         
>>> IPv4 and
>>>       
>>>>     MOBIKE Author(s)    : V. Devarapalli, P. Eronen
>>>>     Filename    : draft-ietf-mip4-mobike-connectivity-02.txt
>>>>     Pages        : 15
>>>>     Date        : 2007-1-4
>>>>
>>>> Enterprise users require mobility and secure connectivity when they
>>>>    roam and connect to the services offered in the enterprise.
>>>>         
>> Secure
>>     
>>>>    connectivity is required when the user connects to the enterprise
>>>>    from an untrusted network.  Mobility is beneficial when the user
>>>>    moves, either inside or outside the enterprise network, and
>>>>    acquires a new IP address.  This document describes a solution
>>>>    using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to
>>>>    provide secure connectivity and mobility.
>>>>
>>>> A URL for this Internet-Draft is:
>>>>
>>>>         
>>> http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivi
>>> t
>>> y-
>>> 02.txt
>>>       
>>>> To remove yourself from the I-D Announcement list, send a message to
>>>>         
>
>   
>>>> [e-mail] with the word unsubscribe in the body 
>>>> of the message.
>>>> You can also visit
>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>> to change your subscription settings.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP. Login with the 
>>>> username "anonymous" and a password of your e-mail address. After 
>>>> logging in, type "cd internet-drafts" and then "get 
>>>> draft-ietf-mip4-mobike-connectivity-02.txt".
>>>>
>>>> A list of Internet-Drafts directories can be found in 
>>>> http://www.ietf.org/shadow.html or 
>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>> Internet-Drafts can also be obtained by e-mail.
>>>>
>>>> Send a message to:
>>>>     [e-mail].
>>>> In the body type:
>>>>     "FILE
>>>>         
>>> /internet-drafts/draft-ietf-mip4-mobike-connectivity-02.txt".
>>>       
>>>> NOTE:    The mail server at ietf.org can return the document in
>>>>     MIME-encoded form by using the "mpack" utility.  To use this
>>>>     feature, insert the command "ENCODING mime" before the "FILE"
>>>>     command.  To decode the response(s), you will need "munpack" or
>>>>     a MIME-compliant mail reader.  Different MIME-compliant mail
>>>>         
>>> readers
>>>       
>>>>     exhibit different behavior, especially when dealing with
>>>>     "multipart" MIME messages (i.e. documents which have been split
>>>>     up into multiple messages), so check your local documentation on
>>>>     how to manipulate these messages.
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader 
>>>> implementation to automatically retrieve the ASCII version of the 
>>>> Internet-Draft.
>>>>         
>>> --
>>> Mip4 mailing list: [e-mail]
>>>    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: [e-mail]
>>    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: [e-mail]
>>    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: [e-mail]
    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/