[go: up one dir, main page]

HK1106637B - Server for routing connection to client device - Google Patents

Server for routing connection to client device Download PDF

Info

Publication number
HK1106637B
HK1106637B HK07111829.7A HK07111829A HK1106637B HK 1106637 B HK1106637 B HK 1106637B HK 07111829 A HK07111829 A HK 07111829A HK 1106637 B HK1106637 B HK 1106637B
Authority
HK
Hong Kong
Prior art keywords
server
relay device
address
network
client
Prior art date
Application number
HK07111829.7A
Other languages
Chinese (zh)
Other versions
HK1106637A1 (en
Inventor
宏树 石田
Original Assignee
飞比特网络股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 飞比特网络股份有限公司 filed Critical 飞比特网络股份有限公司
Priority claimed from PCT/JP2005/009280 external-priority patent/WO2005114926A1/en
Publication of HK1106637A1 publication Critical patent/HK1106637A1/en
Publication of HK1106637B publication Critical patent/HK1106637B/en

Links

Description

Server for routing a connection with a client
Technical Field
The present invention relates to a method for connecting a client and a server, which can perform bidirectional communication between terminals belonging to different home networks via the Internet by a relatively simple means and with high security, in a current infrastructure environment in which IPv4(Internet version4) is widely used, and to a server used for the method, and to a home appliance corresponding to the network.
Background
In general, in a service providing environment through a public network centered on the internet, the value of all information is concentrated not on the client side but on the server side.
That is, each client, i.e., terminal, is basically nothing more than a browser for browsing information on the internet. In addition, each client can make a request for various information to the internet side, and the information of each client can be obtained on the internet side. That is, all information is simply collected on the internet side and the fixed information is unilaterally given from the internet side. Therefore, the manufacturer that manufactures the client terminal is in a situation where it is difficult to generate an additional value.
To change this situation, the server and client must reverse the standpoint of access direction. That is, when there is a home network connected to the internet, it is necessary to generate a state in which access from the internet side to the home network is started and a service is provided from the home network side to the internet side.
For this reason, each machine connected to the home network must be uniquely identifiable from the internet side, and the problem of routing and security in the home must be solved. In response to such a problem, IPv6(Internet protocol version 6: 6 th generation Internet protocol) is known as a technology for finding a solution.
However, in view of the current japanese carrier and the environment around the internet service provider, it is considered that the popularization of IPv6 takes a considerable time. For example, the machine material of IPv4 currently used requires a minimum of 2 to 3 years for degradation, and therefore, only experimental service is performed.
To enable manufacturers to now implement a network corresponding to IPv6 immediately, only services reaching the ISP level are found, but the cost is high and is not practical for most manufacturers. The home networks are diverse in their situations, very different, and have great differences in the structures of carriers and ISP connections, and a structure for absorbing these differences to implement the IPv6 environment in a uniform manner is necessary.
Although the novelty and the advancement of the invention of the present application are not denied, a prior art document related to the above-mentioned situation is disclosed in Japanese patent laid-open No. 2001-274845.
In the conventional IPv4 environment, the following problems arise when bidirectional access is to be achieved between the home network and the internet using the IPv6 network.
For example, in the current IPv4 environment, when a network home appliance is installed in a home, the network home appliance is used by connecting to a router connected to the internet through a home network. Therefore, the IP address of the network home appliance becomes a private address and cannot be accessed from outside the home network.
Therefore, conventionally, in order to access a network home appliance in a home, it is necessary to acquire the information by polling from the network home appliance by using a dedicated router having a function of controlling the network home appliance or by accumulating information for controlling the network home appliance in a data center provided on the internet.
However, when a dedicated router is used, the versatility is reduced. The cost is also increased. When polling is performed to acquire control information, real-time access is not possible, and the load on the network and the server increases.
The present invention has been made in view of the above problems, and an object of the present invention is to provide an internet connection system that enables bidirectional communication between a home network and the internet by relatively simple means, and enables a manufacturer that manufactures a client-side network home appliance and the like to find a unique added value.
Disclosure of Invention
To achieve the above object, according to the 1 st main aspect of the present invention, there is provided a method of connecting a client and a server, which is executed in an internet connection system including a client, a relay device, and a server connected to the internet and connected to the client via the relay device and the internet, the method including (a) a step of notifying the relay device of an IP address of the server; (b) a step in which the relay device establishes a TCP/IP session via a tunnel connection between the relay device and the server using the IP address notified in the step; (c) and a step in which the relay device or the server groups a plurality of relay devices or clients that establish tunnel connections with the server, as devices connected to one virtual private network, based on information from the relay devices or the clients.
With this configuration, all communications of clients relating to network home appliances and the like are performed by the server on the internet regardless of the carrier and ISP. Further, the server can be operated as a hub by managing the relay devices and/or the clients in the same network group, and a plurality of clients at different sites can communicate with each other as a device on a virtual private network group via the server. Further, by assigning the IPv4 global address to the client at the same time, it is possible to solve all the problems of individual identification of the client in the private network from the server on the internet, routing in the home, and security, which have been problems in the past, and it is possible to construct an extremely open and closed network.
According to an embodiment of the present invention, the relay device is installed in each client.
In another embodiment of the present invention, the step (a) is a step in which the relay device is connected to a tunnel broker server provided on the internet, and receives an IP address of the server from the broker server.
According to another embodiment, the step (b) includes: (b-1) a step in which the relay device connects to the server using the IP address of the server assigned thereto; (b-2) notifying the IP address for the relay device to establish a TCP/IP session using a tunnel to the relay device; (b-3) establishing a TCP/IP session using a tunnel between the server and the relay device. In this case, the step (b-1) preferably includes a step of performing connection authentication of the relay device by the server, and the step (b-2) preferably includes a step of generating an IP address of the relay device based on a result of the connection authentication.
According to still another embodiment, the packetizing of the step (c) is performed based on an IP address of the relay device or the client.
Further, according to the 2 nd main aspect of the present invention, there may be provided a network-corresponding home appliance, characterized by comprising: a control unit for receiving a packet including a predetermined command and controlling the network home appliance based on the command; a server address storage unit that stores a global address of a server provided on the internet; a tunnel establishing unit configured to establish a tunnel connection between the home appliance and the server corresponding to the network based on the server address; a group information storage unit for receiving and storing information of other network home appliances belonging to the same group from the server; and a packet processing device for encapsulating/decapsulating a packet communicated between the server and the server connected via the tunnel and routing the packet to the control unit or the other network appliance. Here, the network is preferably provided with an intermediary server address storage unit for storing an address of a tunnel intermediary server provided on the internet, and a server address acquisition unit for accessing the intermediary server based on the intermediary server address and receiving the address of the server from the intermediary server.
Further, according to the 3 rd main aspect of the present invention, there is provided the server for use in an internet connection system including a client, a relay device, and a server connected to the internet and connected to the client via the relay device and the internet, the server including a tunnel establishment unit for establishing a tunnel connection with the relay device, and a terminal group management unit for establishing a network group between another relay device or client which is in tunnel connection with the server based on information of the client or the relay device.
According to one embodiment of the present invention, the server further includes a model determination unit configured to determine whether the client and/or the relay device is of a predetermined model, and the terminal group management unit is configured to construct a network group to which the client of the predetermined model belongs, based on a determination result generated by the model determination unit.
In addition, according to another embodiment of the present invention, the server further includes a command conversion unit that converts a command transmitted to the client into a command of a predetermined format for controlling the client, based on the network group.
According to still another embodiment of the present invention, the client includes a peripheral device which can communicate with the relay device but cannot connect to the internet itself.
According to another embodiment of the present invention, the server further includes a state information acquiring unit that acquires at least one or more of the operating state, the use state, and the position information of the client and/or the relay device.
Other features and advantages of the present invention will be apparent to those skilled in the art from the following detailed description of the preferred embodiments, which is to be read in connection with the accompanying drawings.
Drawings
Fig. 1 is a diagram showing an example of a network configuration according to an embodiment of the present invention.
Fig. 2 is a schematic configuration diagram showing an example of a relay device therein.
Fig. 3A is a schematic configuration diagram showing an example of an InterServer therein.
Fig. 3B is a diagram showing an example of a tunnel session establishment section therein.
Fig. 4 is a diagram showing a schematic configuration of the filter unit.
Fig. 5 is a flowchart showing the processing in the filter portion.
Fig. 6 is a diagram showing a schematic configuration of the network home appliance search unit.
Fig. 7 is a diagram showing an example of the retrieval screen.
Fig. 8 is a diagram showing an example of search result list display regarding the relay apparatus.
Fig. 9 is a diagram illustrating a concept of control by the network home appliance control unit.
Fig. 10 is a functional diagram showing a communication example of the present embodiment.
Fig. 11 is a functional diagram showing another communication example of the present embodiment.
Fig. 12 is a diagram showing an example of the arrangement of the relay device or the network home appliance.
Fig. 13 is a diagram illustrating an example of tunnel connection between a relay device and an InterServer.
Fig. 14 is a step diagram showing a communication sequence of a Microsoft Windows (registered trademark) terminal.
Fig. 15 is a step diagram showing a communication sequence of a Microsoft Windows (registered trademark) terminal.
Fig. 16 is a step diagram showing a communication sequence of the Linux (registered trademark) terminal.
Detailed Description
Embodiments of the present invention will be described below with reference to the drawings.
Fig. 1 is a diagram showing an example of a network configuration of an embodiment of the present invention.
In fig. 1, a home network is connected to a network home appliance 2 (hereinafter referred to as "network home appliance") … and various clients communicating with IPv4 (1 st communication protocol). The home network 1 is constituted by, for example, a LAN introduced into each home. Each network home appliance 2 is provided with the relay device 3 according to the present invention.
The home network 1 is then connected to the internet 4 via a communication carrier/ISP. In the internet 4, communication is performed using IPv4 (2 nd communication protocol).
Then, an InterServer6 (a "server" according to the present invention) for controlling communication of the network home appliance 2 on the home network 1 is connected to the internet 4. As will be described in detail later, the InterServer6 has a function of mediating connection between the network home appliance 2, all the network home appliances 2a (including personal computers) on the internet 4 or other home/global network 1a, the personal computer 2b, and the server 2 c.
Here, the relay device 3 and the InterServer6 are intended to be manufactured by the same manufacturer or under a unified specification, and are designed in advance as a device to be interlocked. Then, as described later, the relay device 3 can communicate by giving a private address and a global address in IPv4 from the InterServer6, and establishing a TCP/IP session with a tunnel connection using the InterServer6 regardless of ISP and bearer. The network home appliance 2 connected to the home network 1 is also intentionally manufactured by the same manufacturer as the relay device 3 or under a unified specification, and for example, although not limited thereto, the IP address of the relay device 3 is uniquely generated based on the model of the network home appliance 2 and other information.
The network home appliance 2 may be a home appliance such as a video recorder or a television which cannot be connected to the internet. In this case, the relay device 3 and the network home appliance 2 are connected via a predetermined communication interface (IEEE1394), and a virtual IPv4 address can be assigned to the ID (unique ID) of each home appliance 2.
Fig. 2 is a schematic configuration diagram showing the network home appliance 2 and the relay device 3.
The relay device 3 includes: a server address storage unit 10 for storing a global address in the IPv4 of the InterServer6, a relay device address storage unit 9 for storing a private address in the IPv4 assigned to the relay device 3, a terminal group storage unit 52 for storing a terminal group "assigned from the InterServer6 to form a virtual private network, a tunnel session establishment unit 11 for establishing tunnel connection with the InterServer6 based on the address of the InterServer6, a packet processing unit 12 for performing tunnel transmission and reception between the packet in the IPv4/IPv6 and the network home appliance side I/F control unit 20 of the InterServer6 by encapsulating/decapsulating the packet using the IPv4, a routing processing unit 13 for routing the decapsulated packet from the InterServer6 side to the network home appliance 2, and a transmission and reception unit 14 for performing transmission and reception of the packet. The relay device 3 is provided with an address generation unit 15 for generating an address (such as a MAC address) of the network home appliance 2.
With this configuration, the packet from the network home appliance 2 or the packet addressed to the network home appliance 2 can be transmitted and received through the IPv4 tunnel established between the InterServer6 and the relay device 3.
Fig. 3 is a schematic configuration diagram showing the InterServer 6.
The InterServer6 includes: an address storage unit 16 for associating the private address 16a (information for specifying the tunnel session) stored in the IPv4 of the relay device 3 with the global address 16b and the network group name 16c in the IPv4/IPv6 of the client; a tunnel speech path establishing unit 17 for establishing a tunnel connection with the relay device 3 based on the address of the relay device 3; an encapsulation processing unit 18 for encapsulating/decapsulating the packets in IPv4/IPv6 in IPv4 so as to enable communication with the network home appliance 2; and a routing unit 19 for routing communications between the network home appliance 2 and other terminals and servers.
The InterServer6 includes a terminal group management unit 54 for managing the network home appliances 2 (clients) as a group. The terminal group management unit has a LAN switch function, and has a function of grouping the network home appliances in accordance with the IP addresses assigned to the network home appliances. Specifically, an appropriate group is selected from among a plurality of groups set in advance, and the network appliance to be matched is included in the group. In this way, the InterServer6 can be used as a hub to construct a virtual network regardless of the physical location of terminals belonging to the same network group. The packetization may be performed in accordance with other attributes of the network appliance, such as MAC addresses and protocols. As described later, the authentication may be performed by user authentication.
The InterServer6 further includes: a model identification unit 21 for identifying the type of the network home appliance 2 based on the IPv4 address of the network home appliance 2 or the relay device 3, a command setting unit 22 for converting a command addressed to the network home appliance 2 into a predetermined command and setting the command based on the identification result, a filtering unit 23 for filtering an IPv4 packet transmitted through a tunnel according to a predetermined rule, and a communication session disconnection unit 24 for disconnecting a communication session in a predetermined case. Then, the transmission/reception processing unit 25 transmits/receives the packet.
The InterServer6 is connected to the user management server 30. As will be described in detail later, the user management server 30 is a device that manages information of users of the relay devices 3 and the network home appliances 2, and includes a user information management DB31 that stores model information, network information (IP address, information of network group), and the like in addition to member information such as ID, password, and billing information of each user.
The information of the user information management DB31 can be used when the tunnel session establishing unit 17 establishes a tunnel session. That is, as shown in fig. 3A, the tunnel session establishing unit 17 is further provided with a user authentication unit 28 for authenticating each user based on the user information, and a relay device IP address assigning unit 29 for assigning an IPv4 private address for tunnel session establishment to the relay device 3. Here, as the IP address assigned to each relay device, any address system may be used as long as it is IPv4/IPv6, and a private address or a global address may be assigned. The information may be generated according to a predetermined rule based on the user, the model, and the network information, or may be specified by the user. The method of generating the address of the relay device 3 is not limited to this.
The InterServer6 has a Web server 32 disclosed on the internet 4(IPv4 network), and can perform various settings in response to requests from users of the relay device 3 and the network home appliance 2. For example, at least a part of the filtering rules of the filtering unit 23 can be changed as appropriate by the user through the Web server 32. The access to the Web server 32 may be via the relay device 3 and the InterServer6, or may be via the internet 4 without passing through these.
As shown in fig. 4, the filter unit 23 includes a filter rule storage unit 33 and a filter rule setting unit 34. The filter rule storage 33 and the filter rule setting unit 34 are connected to the Web server 32 disclosed on the internet, and as shown in fig. 3, an InterServer session interface generation unit 35 is installed in the Web server 32. The user connected to the Web server 32 can input and change the filtering rule by displaying the interface generated by the interface generating unit 35 on his/her own terminal. As the filtering rule that can be set here, for example, a rule relating to security can be considered.
As a filtering rule for security, it can be considered that: (1) no access to the home network from the outside is permitted, (2) no access to the home network from the outside is permitted except from a server (Web site) and a network permitted in advance, and (3) no access to the home network from the outside is restricted. In this case, the filtering method may be a method of not allowing all accesses, or may be a method of passing only a specific port.
Here, when it is possible to restrict access to the set server beforehand for access from the home network 1 to the outside, it is possible to prevent children from accessing harmful contents or prevent a user from accessing a general unfair (troublesome) site.
The setting of the filtering rule is performed after the authentication of the ID and the password by the user authentication unit 36 connectable to the user management server 30, which is provided in the Web server 32.
The filtering rule setting unit 34 has a function of automatically generating a filtering rule based on member information (billing information and terminal model information) stored in the user management server 30 without depending on the setting from the user, in addition to setting the filtering rule based on the input of the user as described above. For example, according to the attributes of the members and the payment status, the connection is not permitted, or a gateway, which is a server capable of only connecting to a specific server, is set.
As a filtering rule for the gateway, it can be used to control the provider that provides charging services through the InterServer 6. For example, as shown in fig. 3, the proxy server 38 may be provided in the InterServer6 to manage the access destination of the user in the DB39, and the user may connect only to the access destination set in the filter rule setting unit 34. In this case, the user management DB31 manages what service (server) the user has signed according to what conditions, in addition to the user ID and password, and desires to install a function for controlling the transaction processing according to the conditions. In addition, the specified supplier may be set such that the user who has not completed the login procedure can only see the sample, but not the subject.
Fig. 5 is a flowchart showing the processing in the filter unit 23. First, after the tunnel session starts, a filtering rule is set based on the member information received from the user management server 30 (step S1). Next, information of the connection request destination of the user (for example, the address of the Web site) is received from the proxy server 38 (step S2). Next, the information on the connection destination is applied to the filtering rule to determine whether or not to allow connection (step S3), and if connection is not permitted, the communication session is cut by the communication session cutting unit 24 (step S4). When connection is permitted, it is determined whether or not the session is still valid (step S5), and when valid, the process returns to the above-described steps S2 to S5. If not, the process is terminated.
The proxy server 38 may measure the amount of data traffic and not allow access from the non-paying user. At this time, the provider is notified of only the ID of the user, and is not notified of the password and IP address of the user. Thus, the user only needs to manage a pair of ID and password for the InterServer 6. Further, since the IP address may be changed depending on the convenience of the user or other reasons, it is preferable that the ID is confirmed by a key every time the ID is confirmed, in terms of system compatibility, and it is preferable that the provider side can eliminate the risk of unauthorized access using data.
The execution of the filtering rule, the disconnection of the communication session and the connection based on the filtering rule are performed by the communication session disconnection unit 24. Further, since a filtering method using a set filtering rule, a gateway method, and other methods are known, their description will be omitted.
The InterServer6 includes a network home appliance search unit 26 (fig. 3) that provides a function for allowing a person who does not know the address of the network home appliance 2 to search for the network home appliance 2. The search unit 26 searches and specifies a desired network home appliance 2 based on information specified by the user, for example, the operating state of the network home appliance 2 and the operating state of the network.
Therefore, as shown in fig. 6, the search unit 26 includes: a status information receiving unit 40 for receiving status information such as the operating status and the network status of the network home appliance 2; a status information storage unit 41 and a network home appliance control unit 42 that store the information in association with the IP address of the network home appliance, the IP address of the relay device 3, and the network group name.
The state information receiving unit 40 receives the state of each network home appliance 2 for each tunnel domain (home network or relay device 3) in which the network home appliance 2 is stored. The state information receiving unit 40 may acquire the state by inquiring the state at a predetermined cycle for each of the domains, or may acquire the state by inquiring when a reference request is made to each domain. In the former method, for example, the inquiry of ON/OFF of the power of each terminal 2 is made for each relay device registered in the relay device address storage unit 16a every minute.
The state information storage unit 41 stores the state information of each network home appliance 2 in association with the network home appliance 2 and the relay device 3. Here, the acquired state information is roughly divided into: at least one or more of the operation state, the use state, the position information, the information indicating the characteristics, the information indicating the information held by the node (the relay device 3 and the network home appliance 2), and the information effective for identifying the other node.
The operation information includes at least one or more of a power supply state, a network connection state, and a communication state. The usage state is at least one or more of information relating to a user, information relating to an operation time, and information relating to a load. The position information is at least geographical position and coordinate information, postal numbers, house numbers and the like. The information indicating the characteristics is one or more of the type, function, shape, color, device information, software information, function, administrator information, and the like of the node.
The model determined by the model determining unit 21 is also stored as status information. The status information receiving unit 40 specifies information obtained from the network home appliance 2 based on the model information, and can acquire necessary information in a form suitable therefor.
The search unit 26 further includes a connection request authentication unit 27 that is connected to the user management server 30 and authenticates a person who performs the search or connection request, permits the search, and requests connection. For example, for the user's home network (relay device 3), search and connection other than the specified user who has permitted connection to the network are not permitted. When the authentication unit 27 determines that the authentication is positive, the search unit 26 accesses the state information storage unit 41 and the address storage unit 16 to search for the address of the desired terminal 2 (identify the relay device 3).
As a result of the search, for example, when the user searches for the relay device 3 of his home network from outside using a personal computer, all the network home appliances 2 connected to the relay device 3 and their statuses may be displayed in a list. Fig. 7 is a diagram showing an example of the retrieval screen, and fig. 8 is a diagram showing an example of list display of the relay apparatus 3/home network 1 determined with respect to the retrieval result. In the example of the interface for search shown in fig. 7, an input field 43 for searching the relay device 3 and an input field 44 for searching the network home appliance 2 are provided, and the search can be performed from any one of them by programming.
In the example of the search result list display in fig. 8, all the terminals 2 connected to the relay device 3 are displayed in a list together with information on the owner, the status, the category, and the model name. Then, by pressing an operation screen display button shown at 45 in the drawing, the network home appliance control unit 42 is activated to display an operation screen (not shown) corresponding to the type and model of the terminal 2.
Fig. 9 is a conceptual diagram illustrating control performed by the control unit 42.
First, the network home appliance 2 notifies the operating state in response to a request from the state information acquiring unit 40 in a state where the relay device 3 is connected to the InterServer6 through a tunnel session (step S11). In this case, the above-described operation state may not be acquired without registering the control unit 42 from the network home appliance 2 side. The operation state is acquired at a constant cycle, and is stored and updated in the state information storage unit 41 (step S12).
Next, the user of the network home appliance 2 logs in from the outside using the ID and the password, specifies a terminal to be controlled from the list as described above, and activates the control unit 42 (step S13). The control unit 42 processes all commands at the server side, and gives appropriate commands to the terminal devices to control them.
Further, the network home appliance 2 related to the selection may be routed and connected by selecting a terminal name from the list. Alternatively, the terminal may be directly connected to the terminal when the terminal is found by searching for the state specified by the search condition input. Even when the terminal is searched for from the outside through the Web server without passing through the tunnel connection of the InterServer6, the connection to the terminal may be made after the tunnel connection is established.
The "tunnel" is a technique for connecting networks (routers) of IPv4 and IPv6 to each other via an IPv4 network, and is particularly a tunnel technique for terminating each of the devices belonging to different networks in a VPN (virtual private network). In this embodiment, IPv4 packets communicated between machines are encapsulated and exchanged by IPv 4.
Each of the components 10 to 42 of the relay device 3 and the InterServer6 actually includes a fixed area secured in a hard disk provided in a computer system, computer software installed in the fixed area, and peripheral devices such as a CPU, a RAM, and other input/output devices for controlling the hard disk to read and execute the programs. In addition, as described above, the network home appliance includes a general-purpose personal computer, and in this case, the respective constituent elements of the present invention are installed as a service program and a virtual ethernet device.
The relay device 3 is preferably configured by one computer system including each network home appliance 2, but the InterServer6 is preferably configured by a plurality of computer systems connected to each other in order to distribute a load. For example, the terminal search unit 26 for managing the states of the relay device 3, the network home appliance 2, and the home network is preferably configured by a server having a dedicated transmission/reception interface and a control unit. This is because it is expected that the speech path for managing the ON/OFF and other states of each device will become enormous, and the load must be distributed. In the case where one InterServer6 is associated with relay devices and network home appliances of a plurality of different manufacturers, a plurality of packet processing units 18, command setting units 22, filtering units 23, and the like may be provided.
Next, the operations of the relay device 3 and the InterServer6 will be described in detail with reference to the communication examples in fig. 10 and the following drawings.
Fig. 10 is a diagram showing a case where the network home appliance 2 of the home network connected to the relay device 3 and another terminal not provided with the relay device 3 communicate via the InterServer 6.
In this figure, a state is shown in which the tunnel session establishing units 17 and 11 establish a communication session in a tunnel connection with the relay apparatus 3 based on the address of the InterServer6, the IP address assigned to the relay apparatus 3, and the address of the network home appliance 2.
When a tunnel communication session is established, the packet addressed to the network home appliance 2 is encapsulated in an IPv4 packet addressed to the relay device 3 by the encapsulation processing unit 18 and transmitted. The relay device 3 decapsulates the packet by the encapsulation processing unit 12, and the routing processing unit 13 performs routing processing for the network appliance 2 based on the address of the network appliance 2 included in the packet. In this way, for example, connection to the network home appliance 2 on the home network in the home can be performed by starting from the external IPv6 server 7.
For example, when the network home appliance 2 is an in-home monitoring camera, the camera can be activated and controlled through the InterServer6 and the relay device 3 by connecting a PDA or the like to an IPv6 network nearby even when the home appliance is out.
In this example, the network home appliance type determination unit 21, the command setting unit 22, and the filter unit 23 provided in the InterServer6 are caused to function in accordance with the type of the network home appliance 2.
The model identification unit 21 is configured to identify the model and the network environment of the network home appliance 2 based on the address (address itself or information associated with the address) of the relay device 3 or the network home appliance 2, for example. In the present embodiment, assuming that the network home appliance 2, the relay device 3, and the InterServer6 are manufactured by the same manufacturer or according to a unified specification, by setting a predetermined rule in advance for an IP address assigned (or generated) to the network home appliance 2 or the relay device 3 connected thereto, it is possible to easily determine the model and the network environment by knowing the address.
When a special command is required for controlling the network home appliance 2, the model other command setting unit 22 converts a command included in the communication from the IPv6 server 7 into a command for the model and sets the command. For example, a prescribed command may be generated using a message described in Html language. Further, the command from one server 7 may be converted into a command for a plurality of network home appliances 2.
The filter unit 23 has a function of filtering packets passing through the InterServer6 according to a predetermined rule. The filtering rule may be set for each connection destination relay device 3 or network home appliance 2, or may be set for each network. The communication session disconnection unit is configured to disconnect the communication session when the model determination unit 21 determines that the model and the network environment are not the predetermined model and when the filtering unit 23 determines that the model and the network environment are inappropriate. When the network home appliance to which the connection is to be made cannot be connected, for example, when the power supply is OFF, if another IPv6 device connected to the same relay device can be used instead, the network home appliance may be connected to the other network home appliance by routing based on the device type and type information.
Fig. 11 shows an example in which IPv6 home networks each having the relay devices 3 and 3' are connected to each other via an InterServer 6. In this example, the networks connecting the network home appliances a and B are physically different networks, but it can be considered that the home appliances a and B are logically connected to the same network by grouping them into the same network group.
In this example, when the network home appliance a and the home appliance B are grouped, a certain rule is given to addresses (IP addresses) assigned to these network home appliances or the same network group name is given in advance. In this way, when the network home appliance is tunnel-connected to the InterServer6, the terminal group management unit 54 associates the home appliances in the same group based on the address or the network group name. When one home appliance is registered in the same group and another home appliance is notified, access to one home appliance from the other home appliance is possible.
Thus, the two network home appliances 2 can communicate with each other via the InterServer 6.
The grouping may be performed based on authentication information of the user by the connection request authentication unit 27. In addition, other information may be used to make a plurality of home appliances belong to the same network group, for example, depending on the same model and the same communication protocol.
With the above configuration, since all communications with the network home appliance 2 can be performed by the InterServer6 regardless of the carrier and ISP, the network home appliance 2 and the server 7 on the home network of the home or work unit can be freely set and controlled by the owner of the InterServer 6. This makes it possible to solve all the problems of individual identification, in-home routing, and security of the network home appliances 2 in the private network from the server on the internet, which have been problems in the past, and to construct an extremely open and closed network.
It is assumed that the owner of the InterServer6 is a manufacturer that is generally a manufacturer of the network home appliance 2. Therefore, the manufacturer can generate an additional value using the internet by preparing the IPv6 equipment series of the local company corresponding to the InterServer 6.
In particular, according to the technique for enabling mutual access between terminals by the above-described grouping, the InterServer6 operates as a hub installed on the internet, and a highly secure VPN can be constructed between terminals belonging to the same network group.
The registration of the network home appliance 2 will be described with reference to fig. 12.
That is, in the above description, it is assumed that the IP address of the network home appliance 2 is received from the relay device 3 side, and actually, various methods other than this method are conceivable. It is considered that the owner of the manufacturer and the InterServer6 want to know information about the owner (user) of the network home appliance 2. As described above, the method of generating the address of the network home appliance 2 may be performed by writing a fixed IPv6 address into a RAM or the like in the network home appliance in advance at the time of shipment, or may be performed by specifying the IPv6 prefix of the relay device 31 connected thereto.
Therefore, in the present embodiment, for example, as shown in fig. 12, the user of the network home appliance 2 or the relay device 3 first connects to the user management server 30 and performs user login. The user registration may be performed by the relay device 3 using the network home appliance 2, or may be performed by an IPv4 communication-supporting device such as an existing personal computer. Here, a case where the network home appliance 2 and the relay device 3 are used will be described. In the following description, a case will be described as an example in which the network home appliance 2 is a terminal that cannot connect to a network, and the address of the network home appliance 2 is generated as a virtual address by the relay device 3 using the MAC address of each network home appliance 2.
In this case, when the user connects the network home appliance to the relay device 3, the relay device 3 is connected to the user management server 30 via the ISP/carrier. In this way, the relay device 3 notifies the user management server 30 of information necessary for tunnel connection with the InterServer 6. The user notifies the user management server 30 of information for specifying the user, the relay device 3, or the network home appliance 2, information on the type of the network home appliance 2, information on the network 1, other information necessary for billing, and the like via the relay device 3. In this example, an ID and a password are issued for the relay device 3 or each user, and the information of the relay device 3 and the user is registered in the database 31 in association with the ID and the password. The information necessary for registration is not limited to this, and other information may be considered necessary, and on the contrary, when a password, billing information, or the like is not necessary, it is not necessary to register the information.
The user management server 30 may be connected to the InterServer6 or may be provided independently on the internet.
On the other hand, fig. 13 and the following drawings show an example of a specific method for establishing a tunnel connection and a communication session therebetween. The symbols from S21 to S21 shown in the figure correspond to the following steps.
First, in the embodiment described above, the network home appliance (relay device 3) stores the IPv4 address of the InterServer6, and this may be a method of recording it in the RAM at the time of shipment from the factory, or a method of setting it by receiving it from another server or the like (including a tunnel broker server) at the time of actual tunnel connection. It is considered that the former method may be used when the InterServer6 is single, and the latter method is more efficient when the InterServer6 is plural.
The example of this figure is the latter case, so tunnel intermediary 52 is set up. In response to this, the IPv4 global address of the tunnel broker 52 is set in advance in the tunnel broker address storage unit of the relay device 3. The relay device 3 is provided with the ID and password set in the above (if necessary) already set.
In fig. 13, for convenience of explanation, each network home appliance A, B is displayed as a computer Operating System (OS)53 such as Microsoft Windows (registered trademark) (hereinafter, the same), a communication application 54 of the network home appliance, a virtual network device 55, and a communication service program 56. When this configuration is made to correspond to the configuration diagram of fig. 2, the application 54 serves as the network home appliance I/F/control unit 20, the virtual network device serves as the packet transmitting/receiving unit 14, and the service program serves as another configuration (9 to 13, 15, 51, etc.). Here, as will be described later, the routing processing unit 15 of fig. 2 first describes a case where the OS is Microsoft Windows, because the operating system of the network home appliance 2 has different functions.
In this case, the relay device 3 is first connected to the tunnel broker 52. The tunnel broker 52 selects an InterServer6 to which a tunnel connection is to be established from the address database, and notifies the relay device 3 of the IPv4 address of the InterServer6 (step S21). In this way, the relay device 3 can recognize the InterServer6 and, after performing user authentication (step S22), can establish a tunnel session using the MAC address and the IP address received from the InterServer6 to perform communication (step S23).
That is, after the relay device is connected to the InterServer6, authentication for connection establishment is performed, and the InterServer6 assigns the MAC address and the IP address for the specified virtual private network to the relay device (these MAC address and IP address may be assigned by the broker server). The inter server6 program may be regarded as a single hub when viewed from the relay device 3. The InterServer6 is configured to assign hubs to each group, and in the present invention, this assignment is referred to as packetization. In addition, when there are a plurality of interservers 6, it is also possible to consider that a network terminal that should belong to the same virtual private network is connected to each of the interservers 6, but in this case, it is preferable to route the connection by using a hub backbone server that manages a plurality of interservers 6 or a plurality of server programs (hub servers) in a lump.
In addition, as for the MAC address, in the present embodiment, two MAC addresses are used in an emulation manner. That is, if the MAC address should be uniquely assigned to one hardware originally, in the Windows version, the same MAC address is assigned to the virtual ethernet devices of the all-relay apparatus (internet appliance) due to software constraints. For example, in the present embodiment, 02: fb: dc:00:03:00 is allocated to the virtual ethernet devices of all the relay devices (internet home appliances). Since this address is a fixed address, it is hereinafter referred to as a "fixed MAC address".
In the ethernet, since a communication destination is specified by using a source MAC address and a destination MAC address of a packet, normal communication cannot be performed when the destination MAC address is unknown and a plurality of terminals having the same MAC address exist. This is also true when using virtual ethernet devices. Therefore, as described above, when the same "fixed MAC address" is assigned to all the relay apparatuses, communication cannot be performed.
In order to solve this problem, in the present embodiment, the address generation unit 15 (fig. 2) performs a MAC address operation. That is, in order to pass the packet flowing through the virtual network through all the service programs 56, the MAC address on the packet is replaced as necessary, thereby ensuring the uniqueness of the MAC address. As described above, the replaced MAC address is notified from the InterServer6 and is stored in the address storage unit 9 upon user authentication. That is, in the present embodiment, there are two addresses, namely, a fixed MAC address (the same for all network home appliances 2) held by the virtual ethernet device 55 and a unique replacement MAC address used for replacement.
When the IP address (for example, 10.10.0.1) for the client is assigned, the service program 56 is received and stored as data in the address storage unit 9, and opens the driver of the virtual ethernet device 55, instead of transmitting the DHCP request packet to the InterServer 6. In addition, at this time, if the DHCP client function of Windows is valid, the core generates a DHCP request packet for the virtual ethernet device. As described above, the IP address of the virtual ethernet device has been accepted at the time of the above authentication. Therefore, the service program 56 (routing processing unit 15) does not send the DHCP request packet to the InterServer6, but extracts the IP address stored in the address storage unit 9 to generate a DHCP request packet and responds.
The address operation at the time of communication is explained below.
In the present embodiment, the InterServer6 functions as a network hub for the network home appliances 2 (relay apparatuses 3) belonging to the same virtual private network group, and performs routing. At this time, since communication between the network home appliances 2 is performed in layer 2 (routing using MAC addresses), the MAC address of the destination network home appliance 2 is required. In the present embodiment, since all the network interfaces of the client are installed as virtual ethernet devices, if the ARP table of the OS does not have a MAC address of a communication destination, the OS generates an ARP request packet and broadcasts it on the network.
However, since communication cannot be performed in this way, in the present embodiment, the MAC address of the ARP packet read from the virtual ethernet device 55 is replaced by the service program 56. That is, the address generating unit 15 has the following two functions.
1) An ethernet frame is read from a virtual ethernet device, the source MAC address of the ethernet frame is replaced with a virtual private network MAC address, and the replaced ARP packet is encapsulated and transmitted to the InterServer (hub).
2) The service program receiving the ethernet packet data from the InterServer replaces the MAC address of the transmission destination of the ethernet packet with the MAC address of the virtual ethernet device.
For example, fig. 14 shows a MAC address processing flow when a communication source network home appliance a communicates with a communication destination network home appliance B whose IP address on a virtual private network is known and executes a PING command in the communication source network home appliance. S31 to S48 in the figure correspond to steps S31 to S48 in the following description.
The service program 56 from S31 to S33 is connected to the InterServer6 via the internet, performs user authentication, establishes a tunnel TCP session, receives a MAC address for a relay device (for example, 00:80:6D:03: EE) and an IP address for a relay device (10.10.0.1), and sets a driver of the virtual ethernet device 55. The TCP session is kept active by the service program transmitting a predetermined packet at a predetermined time interval.
S34 is a process for generating a PING request to the communication destination network home appliance B on the Windows client (network home appliance a), and OS53 (core) broadcasts an ARP request packet to identify the communication destination and writes the ARP request packet into the virtual ethernet device 55 of the client.
The virtual network communication service program 56 activated as the Windows service program at S35 and S33 reads out the ARP request packet from the virtual ethernet device 55, replaces the source fixed MAC address of the ARP request packet with the communication MAC address, encapsulates the ARP request packet, and transmits the encapsulated ARP request packet to the InterServer 6. The InterServer6 routes an ARP request packet received by the communication-destination server 56 to a communication-destination relay device based on the IP address, and writes the ARP request packet to the virtual ethernet device 55.
S37 to S39 are configured such that after the OS53 (core) writes the response packet to the ARP request into the virtual ethernet device 55, the service program 56 reads the ARP response packet from the virtual ethernet device 55, replaces the source MAC address (fixed) of the ARP response packet with the communication MAC address, and encapsulates the ARP response packet to transmit to the InterServer 6.
When the service program of the source receives the ARP reply packet by the routing of the InterServer6, the service program 56 at S40 and S41 writes the source MAC address of the ARP reply packet back to the MAC address of the virtual ethernet device and writes the packet to the virtual ethernet device 55.
S42 accepts the ARP reply, OS53 (core) specifies the destination MAC address, and generates a PING packet.
The S43 service program 56 reads out a PING request packet from the virtual ethernet device 55, replaces the source MAC address of the PING request packet with a communication MAC address, encapsulates the PING request packet, and transmits the packet to the InterServer 6.
S44 is configured such that, when a (packaged) PING request packet arriving at a communication destination via the InterServer6 is received by a service program of the destination, the service program 56 replaces the MAC address of the sending destination of the PING request packet with the MAC address of the virtual ethernet device 55 and writes the packet into the virtual ethernet device 55.
S45 and S46 are configured such that, after the core 53 writes the response packet to the PING request into the virtual ethernet device 55, the service program 56 reads the PING response packet from the virtual ethernet device 55. The service program 56 replaces the source MAC address of the PING response packet with the communication MAC address, encapsulates the PING response packet, and transmits the packet to the InterServer 6.
When a (packaged) PING response packet arriving at the destination of communication via the InterServer6 is received by the destination service program 56 in S47 and S48, the service program 56 replaces the MAC address of the destination of the PING response packet with the MAC address of the virtual ethernet device and writes the packet to the virtual ethernet device 55.
By replacing the MAC address with the service program in this way, communication via the hub becomes possible even if the MAC addresses of the virtual ethernet devices are all the same. As described above, the MAC addresses for replacement (aa: aa: aa: aa: aa: aa, bb: bb: bb: bb: bb, etc.) are allocated and managed by the InterServer 6.
In addition, in the same windiwowss, the program installed in the relay device of the present embodiment can be applied to such PPP connection that does not pass through the hub, and in this case, since only the IP address is used, the MAC address is not required. However, since the windows is installed with the network interfaces of the clients all in the form of virtual ethernet devices, a MAC address solution using ARP is required in a previous stage of arrival to the network. When ignoring the ARP request, the core determines that there is no communication partner and does not transmit the actual packet data, and the request cannot be ignored. Therefore, in this case, the service program 56 (routing processing unit 13) has the following functions.
1) A service program for reading out an ARP request packet from a virtual Ethernet device dynamically generates a dummy MAC address which does not actually exist, generates an ARP response packet, and writes the ARP response packet in the virtual Ethernet device.
2) And the core receiving the ARP response writes the real data frame into the virtual Ethernet device by taking the MAC address as a receiving address.
3) The server reads out the real data frame, removes the ethernet header (MAC address), and sends it to the network.
4) The service program that receives the IP packet data from the network writes a header (MAC address) to the IP packet and writes the IP packet to the virtual ethernet device. The destination MAC address designates a fixed MAC address, and the source MAC address uses a dynamic MAC address dynamically generated by the service program.
For example, in the case where a network home appliance of a communication source and an IP address on a virtual private network communicate with another internet home appliance of a known communication destination, a MAC address processing flow when a PING command is executed in the network home appliance of the communication source is as shown in fig. 15.
The service program 56 from S31 to S33 is connected to the InterServer6 via the internet, performs user authentication, establishes a tunnel TCP session, receives a MAC address for a relay device (for example, 00:80:6D:03: EE) and an IP address for a relay device (10.10.0.1), and sets a driver of the virtual ethernet device 55. The TCP session is kept active by the service program transmitting a predetermined packet at a predetermined time interval.
In S51, when PING is generated for another PPP terminal (another network appliance) in the network appliance 2, the OS53 (core) broadcasts an ARP request packet to identify the communication partner. Thus, the ARP request packet is written to the virtual ethernet device 55 of the client.
S52 shows that the service program 56 started as the Windiws service program reads out the ARP request packet from the virtual ethernet device 55, dynamically generates the ARP request packet in the service program 56, and writes the ARP request packet in the driver. Here, the destination MAC address necessary for the response packet is the MAC address of the virtual ethernet device 55, and the source MAC address is generated in the service program 56 and designates the PPP dynamic MAC address. In the present embodiment, the address is generated with a fixed value of 2 bytes + IP address. For example, when the IP address of the recipient address is 255.255.255.255, the generated MAC address is ac: de: ff: ff: ff: ff. The probability that a network device having a dynamically generated MAC address actually exists is almost 0, and even if it exists, it does not affect actual communication.
S53OS53 (core) receives the ARP reply written to the virtual ethernet device 55, and recognizes that the MAC address (PPP dynamic MAC address) of the communication partner can be acquired.
S54OS53 (core) writes the packet to the PPP dynamic MAC address acquired in the ARP reply to the virtual ethernet device 55.
The service program 56 in S55 and S56 extracts the data packet written in the virtual ethernet device 55, and transmits the data packet to the InterServer (PPP) 6 as data (encapsulated IP packet) by removing the IP packet portion in which the MAC address is described (ethernet header portion).
S57 is such that when IP packet data arriving at a destination of communication via the InterServer (for PPP) 6 is received by a service program of the destination, the service program 56 adds a source MAC address and a destination MAC address to the data, and writes the data in an ethernet frame state into a virtual ethernet device. The destination MAC address is a MAC address of the virtual ethernet device, and the source MAC address is dynamically generated in the service program. The generation logic is the same as S52 described above.
S58 to S64 return PING response packets in the same manner as the above steps S51 to S57.
Thus, by dynamically generating a dummy MAC address by the service program 56, PPP communication can be performed also in Windiws. The MAC address for the replacement is assigned and managed by the InterServer 6.
The following describes a case where the operating system is Linux.
In the internet connection in which the above-described InterServer is changed to a hub, since a communication destination is identified by a source MAC address and a destination MAC address of a packet, normal communication cannot be performed when the destination MAC address is unknown or when a plurality of terminals having the same MAC address exist. In the case of Windiws described above, the same MAC address is assigned to all the virtual ethernet devices due to OS constraints, and therefore, the MAC addresses need to be replaced. In the Linux environment, where restrictions such as Windiws do not exist, each virtual ethernet device may be assigned a unique MAC address.
In this case, when the communication source network home appliance 2 and the IP address on the virtual private network communicate with a known communication destination internet home appliance, the MAC address processing flow when the PING command is executed in the communication source relay apparatus is as shown in fig. 16. In the figure, S31 to S33 and S71 to S74 correspond to the respective steps in the following description.
The service program 56 of S31 to S33 is connected to the InterServer6 via the internet, performs user authentication, and sets the driver of the virtual ethernet device 55 in response to the reception of the MAC address for the relay device (for example, 00:80:6D:03: EB) and the IP address for the relay device (10.10.0.1).
S71 to S74 are, therefore, relay devices establishing communication sessions using the MAC addresses and IP addresses thus set.
In addition, in the Linux environment, since all processing for the MAC address is not necessary when PPP connection is performed, in this case, the MAC address allocation from the InterServer is not necessary. Therefore, when the service program connects to the InterServer6, performs user authentication, and receives an IP address, the service program connects to the destination network home appliance using the IP address.
With this configuration, even when there are a plurality of interservers 6, a tunnel connection can be reliably established with one of them.
The embodiment described above is merely one embodiment of the present invention, and various forms can be adopted without changing the main contents thereof.
For example, in the above-described embodiment, the tunnel connection can be established from both the relay apparatus 3 side and the InterServer6 side, but it is considered that the tunnel connection is generally initiated only from the relay apparatus 3 in an actual commercial service. Since the fixed IP services of IPv4 are inherently scarce. That is, in this case, it is rare that the setting is always reserved after the tunnel is established (actually, the IPv4 is connected to itself), and the IPv4 session is cut off, and thereafter the IPv4 of the relay apparatus 3 is the same, and it is actually impossible to select a route when the IPv4 session itself is cut off.
In the above embodiment, the 1 st protocol is IPv4, and the 2 nd protocol is IPv4 as an example, but the invention is not limited thereto. The 1 st protocol may also be IPv 6. In addition, the 1 st and 2 nd protocols may be both IPv 6. Both protocols may be other than the above.
In the above-described embodiment, the relay device 3 is provided integrally with each network home appliance, but may be provided separately, or one relay device 3 may be shared among a plurality of network home appliances. In addition, the network household electrical appliance and the relay apparatus may be connected via a LAN.

Claims (29)

1. A connection method of a client and a server, which is executed in an internet connection system having the client, a relay device, and a server connected to the internet and connected to the client via the relay device and the internet, comprising:
(a) notifying the relay device of the IP address of the server;
(b) a step in which the relay device establishes a TCP/IP session via a tunnel connection between the relay device and the server using the IP address notified in the step;
(c) a step in which the relay device or the server groups a plurality of relay devices that establish tunnel connections with the server as devices connected to one virtual private network, based on information from the relay device or the client,
the relay devices are installed in the respective clients.
2. The method of claim 1, wherein:
the step (a) is a step in which the relay device is connected to a tunnel broker server provided on the internet, and receives an IP address of the server from the broker server.
3. The method of claim 1, wherein:
the step (b) includes:
(b-1) a step in which the relay device connects to the server using the notified IP address of the server;
(b-2) notifying the IP address for the relay device to establish a TCP/IP session using a tunnel to the relay device;
(b-3) establishing a TCP/IP session using a tunnel between the server and the relay device.
4. The method of claim 3, wherein:
the step (b-2) is a step in which the server notifies the relay device of an IP address for the relay device for establishing a TCP/IP session using a tunnel.
5. The method of claim 3, wherein:
the step (b) further includes:
(b-4) the step of the server generating and notifying the relay device of the MAC address for the relay device.
6. The method of claim 3, wherein:
the step (b-1) includes a step in which the server performs connection authentication of the relay device,
the step (b-2) includes a step of assigning an IP address of the relay device in accordance with a result of the connection authentication.
7. The method of claim 6, wherein:
the step (b-2) may further include a step of assigning a MAC address of the relay device according to a result of the connection authentication.
8. The method of claim 6, wherein:
the packetization in the step (c) is performed based on the connection authentication in the step (b-1).
9. The method of claim 3, wherein:
the step (a) is a step in which the relay device is connected to a tunnel broker server provided on the internet, and receives an IP address of the server from the broker server,
the step (b-2) is a step in which the mediation server notifies the relay device of an IP address for the relay device for establishing a TCP/IP session using a tunnel.
10. The method of claim 9, wherein:
the step (b) further includes:
(b-4) the step of the broker server generating and notifying the relay device of the MAC address for the relay device.
11. The method of claim 1, wherein:
the packetizing in the step (c) is performed based on the IP address of the relay device or the client.
12. The method of claim 1, wherein:
the grouping in the step (c) is performed by assigning a specific virtual server provided in the server to a client connected to the same virtual private network.
13. The method of claim 1, wherein:
the step (c) is a step of determining whether or not the relay device or the client belongs to any one of a plurality of groups based on information from the relay device or the client, and grouping the relay device or the client into a group related to the determination.
14. A network appliance, comprising:
a control unit for receiving a packet including a predetermined command and controlling the network home appliance based on the command;
a server address storage unit that stores a global address of a server provided on the internet;
a tunnel session establishing unit for establishing a tunnel connection between the network home appliance and the server based on the global address of the server;
a group information storage unit which receives and stores information of other network home appliances belonging to the same virtual private network group from the server; and
and a packet processing device for encapsulating/decapsulating a packet communicated with the server connected through the tunnel and routing the packet to the control unit or the other network appliance.
15. The network appliance of claim 14, comprising:
and a relay device address storage unit that performs an authentication connection with the server before the establishment of the tunnel connection by the tunnel session establishment unit, and receives and stores the IP address on the virtual private network from the server.
16. The network appliance of claim 14, comprising:
and a relay device address storage unit that performs an authentication connection with the server before the establishment of the tunnel connection by the tunnel session establishment unit, and receives and stores the MAC address on the virtual private network from the server.
17. The network appliance of claim 14, comprising:
and an address generating unit configured to, when receiving information of another network appliance belonging to the same virtual private network group from the server, replace the MAC address of the virtual network appliance in the address request/response packet with the MAC address received from the server.
18. The network appliance of claim 14, further comprising:
an intermediary server address storage unit for storing the address of a tunnel intermediary server provided on the Internet; and
and a server address acquisition unit that accesses the mediation server based on the mediation server address and receives the address of the server from the mediation server.
19. A server used in an internet connection system including a client, a relay device installed in the client, and a server connected to the internet and connected to the client via the relay device and the internet, the server comprising:
an address storage unit that stores a private address in IPv4 of the relay device, a global address in IPv4/IPv6 of the client, and a network group name in association with each other;
a tunnel session establishing unit for establishing a tunnel connection with the relay device based on the address of the relay device;
an encapsulation processing unit for encapsulating/decapsulating packets in IPv4/IPv6 communicated with the relay device/client connected via the tunnel, in IPv 4;
a routing unit that performs routing of communication between the relay device/client and another terminal and/or a server; and
and a terminal group management unit that constructs a virtual private network group with another relay device or client that is tunnel-connected to the server, based on information from the client or the relay device.
20. The server of claim 19, further comprising:
a model determination unit configured to determine whether the client and/or the relay device is of a predetermined model,
the terminal group management unit manages the discrimination result generated by the model discrimination unit in association with the client.
21. The server of claim 20, further comprising:
and a command conversion unit for converting the command transmitted to the client into a command of a predetermined format for controlling the client, based on the determined model.
22. The server of claim 19, further comprising:
a protocol discriminating section for discriminating a protocol for controlling the client,
the terminal group management unit constructs a network group to which a client using the same protocol belongs, based on the determination result generated by the protocol determination unit.
23. The server according to claim 19, wherein:
the terminal group management unit manages a plurality of virtual private network groups, and selects a group to which a client or the relay device belongs, based on information from the client or the relay device.
24. The server according to claim 19, wherein:
the client includes a peripheral device which can communicate with the relay device but cannot connect to the internet itself.
25. The server of claim 19, further comprising:
and a state information acquiring unit configured to acquire at least one or more of the operating state, the use state, and the position information of the client and/or the relay device.
26. The server according to claim 19, comprising:
and an address management unit that allocates an IP address on the virtual private network to the relay device.
27. The server according to claim 26, wherein:
the address management unit further assigns a unique MAC address to each client and/or each relay device for connection via a virtual private network.
28. A relay device for virtual private network connection, comprising:
the relay device is a relay device having an interface which is regarded as a driver of a virtual network device in a local communication protocol stack, and includes:
a server address storage unit that stores a global address of a server provided on the internet;
a tunnel session establishing unit for establishing a tunnel connection between the relay device and the server by connecting to the server based on the server address;
a relay device address storage unit that stores the private address in IPv4 assigned to the relay device;
a terminal group storage unit for storing a terminal group allocated from the server to construct a virtual private network,
an encapsulation processing unit that encapsulates/decapsulates a packet communicated with the server connected via the tunnel;
a routing processing unit for routing the decapsulated packet from the server to a client; and
and a transmitting/receiving unit for transmitting/receiving packets.
29. The relay device of claim 28, wherein:
the tunnel session establishment unit is a device that also receives a MAC address for virtual network connection from the server,
the relay device further includes:
an address generation unit, when the request received by the interface is an ARP request, replaces the source MAC address in the ARP request with the MAC address received from the server and transmits the request, and writes back the destination MAC address in the ARP response to the original MAC address based on the MAC address received from the server.
HK07111829.7A 2004-05-20 2005-05-20 Server for routing connection to client device HK1106637B (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2004150681 2004-05-20
JP150681/2004 2004-05-20
PCT/JP2005/009280 WO2005114926A1 (en) 2004-05-20 2005-05-20 Server for routing connection to client device

Publications (2)

Publication Number Publication Date
HK1106637A1 HK1106637A1 (en) 2008-03-14
HK1106637B true HK1106637B (en) 2012-10-19

Family

ID=

Similar Documents

Publication Publication Date Title
CN1957566B (en) A server that routes connections to clients
EP2448185B1 (en) Internet connection system and server for routing connections to client device
US20070195804A1 (en) Ppp gateway apparatus for connecting ppp clients to l2sw
WO2007043381A1 (en) Network communication device, network communication method, and address management device
JP3688282B2 (en) Server for routing connections to client devices
KR100818977B1 (en) Server for routing connections to client devices
HK1106637B (en) Server for routing connection to client device
JP4383889B2 (en) Equipment information communication system
HK1173872B (en) A network-enabled home appliance
HK1086683B (en) Server for routing connection to client devise
HK1086963B (en) Internet connection system and server for routing connection to client device