Subject: Re: [mobile-ip] I-D ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt

From: "Hiroyuki OHNISHI" <[email-masked]>
Date: Fri, 5 Jul 2002 12:00:06 +0900

Hi  changwen,

Thank you for your comments.
I understand what you are saying.  But this architecture is aiming to be
applied to a VPN model.
I show you our requiements first and reply to your comments.

Our requirements are followings;
Requirement 1: MN outside the Intranet can set up IPsec tunnel between the
MN and the Intranet(VPN GW).  And the IPsec tunnel does not need to be
renegotiated even if the MN changes its CoA.
Requirement 2: To achieve Requirement 1,  the VPN GW has to handle binding
caches for the MN.  And it is better that MN can create binding caches in
VPN GW by using a simple way.

As you mentioned, this draft proposed that MN sends Binding Update to GHA
instead of HA and GHA again sends Binding Update to the HA.  This is because
we want to create binding caches in GHA during registering MN's CoA to HA
(requirement 2).   I think it can be possible that MN sends BU(for HA) over
BU(for GHA) mesasge.  But from the viewpoint of MN,  I think it is too
complex.

GHA has to forward all the traffic from/to MNs.  But it is common senario
that the traffic has to pass through the VPN GW in the VPN senario.  I think
even if MN moves to outside the Intranet,  the MN should be under same
envinronment.  It means that the packets to the MN can pass through a FW
that is located in the Intranet.   If the route optimization is applied in
the VPN scenario,  the packets that can not pass through the FW can also
reach the MN.

Will you give me further comments on this?
Thanks in advance.

Hiroyuki

----- Original Message -----
From: "Liu, Changwen" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 29, 2002 2:28 AM
Subject: RE: [mobile-ip] I-D
ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt

> I read through the draft and here is my quick observation/comment on this
> draft:
> Unlike MIPv4, MIPv6 (as of draft 17) has better authorization
specification
> for binding update. For example, in order to avoid unauthorized binding
> update for a MNv6, "the security policy database entries MUST
unequivocally
> identify a single SA for any given home address and home agent" in MIPv6
> while MIPv4 SA doesn't has this restriction. In other words, if the GHA
can
> send binding update to MIPv6 HA for a MNv6, the MNv6 loses its capability
> for sending binding update to its own MIPv6 HA. Hence no matter where MNv6
> roams to, all MNv6 data traffic has to go through GHA and a lot of traffic
> has to go through the path HA-GHA. The routing for MNv6 can never be fully
> optimized as specified in MIPv6 and triangular routing is unavoidable. If
> one wants support full routing optimization for VPN traversal, it seems
that
> the aforementioned line in MIPv6 specification may need to be changed
> slightly to allow more than one SAs for updating any given home address
and
> home agent pair.
>
> My two cents.
>
> changwen
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, June 28, 2002 3:37 AM
> > Cc: [email-masked]
> > Subject: [mobile-ip] I-D
> > ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> >
> >
> > Title : Mobile IPv6 VPN using Gateway Home Agent
> > Author(s) : H. Ohnishi, K. Suzuki, Y. Takagi
> > Filename : draft-ohnishi-mobileip-v6vpngateway-00.txt
> > Pages : 18
> > Date : 27-Jun-02
> >
> > Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6.  It
> > can also be used for public mobility services.  One of the most
> > important services is the VPN service enabling users to access their
> > Intranets from outside.  Mobile IP does notwork well with VPN,
> > however, and this issue is being discussed in the Mobile IP WG [VPN
> > problem].  This document proposes a simple mechanism that combines
> > VPN and Mobile IP functions. This mechanism uses a hierarchical HA
> > architecture and includes an HA with GW functions, called a Gateway
> > Home Agent (GHA).
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-v6v
> pngateway-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> 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-ohnishi-mobileip-v6vpngateway-00.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:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ohnishi-mobileip-v6vpngateway-00.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.