Reminder: Working Group Last Call fordraft-ietf-mip4-mobike-connectivity-00]

Hi,

The document looks OK to me. So it should progress as
intended.

One comment: having the MN send MIPv4 registration request
outside of
the VPN tunnel may increase setup time. This will happen if
the MN has
moved into an un-trusted network.

If the MN has a VPN tunnel, why not having it send MIP4 RRQ
over the VPN
tunnel? 

Thanks,
Kuntal


> -----Original Message-----
> From: Henrik Levkowetz [mailto:henriklevkowetz.com]
> Sent: Monday, April 24, 2006 8:50 AM
> To: MIP4 Mailing list
> Subject: [Mip4] Reminder: Working Group Last Call
fordraft-ietf-mip4-
> mobike-connectivity-00]
> 
> Hi,
> 
>   This is a reminder regarding the WG last call on the
mip4-mobike-
> connectivity
> draft, which ends this Friday.
> 
> Please indicate whether you support sending this draft
up for
publication
> or not.
> 
> Regards,
> 
> 	Henrik
> 
> 
> -------- Original Message --------
> Subject: [Mip4] Working Group Last Call
for	draft-ietf-mip4-mobike-
> connectivity-00
> Date: Fri, 14 Apr 2006 12:25:27 -0500
> From: Pete McCann <mccaplucent.com>
> To: Mobile IPv4 Mailing List <mip4ietf.org>
> 
> This message announces a WG last call on:
> 
>   "Secure Connectivity and Mobility using Mobile
IPv4 and MOBIKE"
>   - draft-ietf-mip4-mobike-connectivity-00
> 
> The last call will conclude at 24:00 UTC on Friday, 28
April 2006.
> 
> draft-ietf-mip4-mobike-connectivity-00 describes the
use of IKEv2 and
> MOBIKE in conjunction with Mobile IPv4 to offer secure
connectivity to
a
> protected network along with mobility.
> 
> A URL for this Internet-Draft is:
> 
>
<http://www.ietf.org/internet-drafts/draft
-ietf-mip4-mobike-connectivity
-
> 00.txt>
> 
> 
> Please respond to this WG last call:
> 
> * If you have no comments on the draft, and support its
advancement,
>    simply respond with a line containing something like
> 
>     "I support the advancement of this document
to the IESG with a
>      request for publication as proposed
standard."
> 
>    If you have comments, please use a line similar to
the one above,
and
>    supplement this with your comments.
> 
> 
> * If you *don't* support its advancement, respond with
a line
containing
>    something like the following, supplemented by your
comments -
> 
>     "I don't support the advancement of this
document to the IESG with
>      a request for publication as proposed standard,
for the following
>      reasons:"
>     ...
> 
> 
>      Pete & Henrik
> 
> --
> Mip4 mailing list: Mip4ietf.org
>     Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
>      Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/



-- 
Mip4 mailing list: Mip4ietf.org
    Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
     Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

hi Kuntal,

Chowdhury, Kuntal wrote:
> Hi,
> 
> The document looks OK to me. So it should progress as
intended.
> 
> One comment: having the MN send MIPv4 registration
request outside of
> the VPN tunnel may increase setup time. This will
happen if the MN has
> moved into an un-trusted network.

the MOBIKE update message and the registration
request without VPN encapsulation to i-HA
will be done in parallel. if the i-HA replies
with a registration reply, then it means the
MN is attached to the trusted network.

> If the MN has a VPN tunnel, why not having it send MIP4
RRQ over the VPN
> tunnel? 

once the MOBIKE update is done, a registration
request is sent over the VPN tunnel too.

security boundary detection based on i-HA
reachability is described in more detail in
draft-ietf-mip4-vpn-problem-solution-02.txt.
see section 3.3.

Vijay

-- 
Mip4 mailing list: Mip4ietf.org
    Web interface: https://w
ww1.ietf.org/mailman/listinfo/mip4
     Charter page: h
ttp://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/