Terminal and communication system

(Problems) By assigning a fixed home address to an MN, Mobile IPv6 assures the arrival of each content at the MN 1. In order to allow the user to receive a Mobile IPv6 service, it is necessary to provide the MN 1 with a Mobile IPv6 function for making applications conform to IPv6. However, there are only few such MNs 1. In addition, the MN 1 does not have a function for implementing an IPsec process repeatedly on a packet transmitted to and received from another apparatus.(technical solution) A scenario processing port 23 employed in the MN 1 includes a means, which is used for selecting a process according to a communication method and carrying out the selected process when a response to a Mobile IPv6 location registration message is received. By providing the scenario processing port 23 with a means for selecting a communication method, a function can be added to the MN 1 with ease. In addition, by providing the MN 1 with a means for implementing an IPsec process a plurality of times, it is possible to provide a communication apparatus according to a security management configuration.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a terminal connected to a network as well as a communication control method and control program of the terminal. In particular, the present invention relates to a mobile terminal as well as a mobile communication control method and control program of the mobile terminal. To be more specific, the present invention relates to a mobile terminal in a mobile communication system adopting a mobile IP (Internet Protocol).

BACKGROUND OF THE INVENTION

In recent years, conversion of the protocol of a mobile communication network into an IP (Internet Protocol) is studied extensively.

An IETF (Internet Engineering Task Force) recommends standardization of Mobile IPv6 specifications. (Refer to non-patent documents 1: Mobility Support in IPv6<draft-ietf-mobile-ipv6-24.txt>, Work in Progress).

Network configuration elements of Mobile IPv6 include an MN (Mobile Node), an HA (Home Agent) and a CN (Correspondent Node).

An MN has a unique IP address (or home address), which does not change even if the MN moves to another location. A link that has the same prefix as the home address is referred to as a home link. In this case, the prefix of an IP address is a network part of the IP address.

When an MN moves to a link other than the home link, in the other link where the MN presently exists, the MN acquires an IP address. This acquired IP address is referred to as a care of address, which is abbreviated hereafter to simply a CoA. When the MN moves to the foreign link defined as a link to which the MN has moved from the home link, the MN receives a router advertisement transmitted periodically by a router existing in the present network. As the MN detects a prefix included in the router advertisement as a prefix different from that of the home address, the MN becomes aware of the fact that the MN has moved from the home link to the foreign link. A message in the router advertisement is prescribed in a neighbor discovery (IETF RFC2461) of the IPv6 specifications. The message is used for informing another node in the same link as the router that the router exists in the same link.

When the MN detects its movement, the MN registers its CoA in the HA. The security of a binding update message and binding acknowledgement message is assured by using IPsec. The HA holds binding information in a binding cache. The binding information is information associating the home address of the MN existing in a foreign link other than the home link with the aforementioned care of address (CoA). Then, operating as a proxy of the MN, the HA multicasts a Gratuitous Neighbor Advertisement in order to intercept a packet transmitted from a CN to the home address of the MN.

A procedure for transmitting a packet from a CN to the home address of an MN is described as follows.

The CN transmits a packet directed to the home address of the MN. The HA intercepts a packet directed to the home address of the MN. The HA searches the binding cache for a CoA associated with the home address of the MN. Then, the HA adds an IP header directed to the CoA to the received packet in an encapsulation process and transmits the encapsulated packet to the CoA. The encapsulated-packet route between the HA and the MN is referred to as a mobile tunnel.

When the MN receives the packet directed to the CoA, the MN removes the IP header added earlier to the packet in a decapsulation process to restore the original packet. Security of the mobile tunnel can be assured by using IPsec. The MN receiving the encapsulated packet may inform the CN of the binding information in order to optimize the route from the CN to the MN.

As a technology for managing local movements based on the Mobile IPv6 specifications, Hierarchical Mobile IPv6 mobility management (HMIPv6) has been proposed. (Refer to non-patent documents 2: Hierarchical Mobile IPv6 mobility management (HMIPv6)<draft-ietf-mobileip-hmipv6-07.txt>, Work in Progress).

HMIPv6 is provided with a MAP (Mobile Anchor Point) between the HA and the MN. The MAP provides a local HA function. The MAP may also have an AR (Access Router) as a subordinate. The MN receives a router advertisement including MAP options from an AR or the MAP and acquires the IP address of the MAP. The MAP options include the global address of the MAP, the prefix of the MAP, a MAP preference and the number of hops along the route to the MAP. The MAP informs the AR of MAP options by adoption of one of the following methods:

(1) Deliver a router advertisement including MAP options to the AR (Access Router).

(2) Have the MAP extend a router renumbering function of IPv6 to notify the AR of MAP options.

Instead of having the MAP inform the AR of MAP options, a person in charge of network management may set information of MAP options in the AR.

Receiving a router advertisement including MAP options, the AR passes on the router advertisement including MAP options to the MN located at a subordinate location.

Receiving the router advertisement including MAP options, the MN conforming to HMIPv6 stores the information of the MAP options. The MN conforming to HMIPv6 then generates an RCoA (Regional Core of Address) from the MAP prefix included in the MAP options and an index identifier of the MN. The MAP prefix is the prefix of a link in which the MAP exists. In addition, the MN conforming to HMIPv6 also generates an LCoA (On-link CoA) by using prefix information included in the router advertisement transmitted by the AR. The prefix information is the prefix of the AR. The LCoA corresponds to the CoA of Mobile IPv6.

First of all, the MN conforming to HMIPv6 registers its CoA in the MAP. The MAP is an element for managing information associating the RCoA of the MN with the LCoA. Then, the MN conforming to HMIPv6 registers its CoA in the HA. When the MN moves inside the MAP, the MN updates only information cataloged in the MAP as information on the CoA of the MN.

In addition, attention is being paid gradually to a network mobility technology for managing mobility in network units by using a mobile router for supporting group movements of nodes. (Refer to non-patent documents 3: Network Mobility Support Goals and Requirements”<draft-ietf-nemo-requirements-01.txt>, Work in Progress). The mobile router has an HA and registers its CoA in the HA. The mobile router is provided with an MN function of the mobile IP and router function. In order to sustain session continuity while the mobile router is moving, a mobile IP technology is applied between the HA of the mobile router and the mobile router itself. The HA intercepts a packet directed to a terminal located at a location subordinate to the mobile router and transfers the packet to the mobile router. Thus, it is possible to sustain the session continuity while the mobile router is moving. An IP header is added to a packet transferred between the HA and the mobile router. A mobile network including a mobile router includes stationary nodes and mobile nodes. A mobile network may include another mobile network. When a node of a mobile network communicates with a node outside the mobile network, all traffics pass through a tunnel between the mobile router and the HA.

A virtual machine exists in a technology for emulating a specific machine architecture and a hardware platform. In general, the virtual machine is implemented by software. Normally, the virtual machine operates on an OS (Operating System) of an apparatus. For this reason, an OS used for executing the virtual machine itself is referred to as a host OS and an OS executed in the virtual machine is referred to a guest OS.

On the other hand, attention is paid to an SIP (Session Initiation Protocol) adopted as a session control protocol in an IP network. For more information on the SIP, refer to non-patent document 4: IETF RFC3261, SIP: Session Initiation Protocol. The SIP is a protocol for controlling sessions of IP multimedia communications made to conform to specifications by IETF. Representative services each adopting the SIP include a VoIP (Voice over IP) service. The VoIP (Voice over IP) service is a service adopting a technology for transmitting and receiving audio information by way of an IP network. In a VoIP communication adopting the SIP, a virtual session is set prior to the start of the communication between apparatus communicating with each other. Then, audio data put in an IP packet is transmitted through the set session. The SIP adopted in the VoIP communication establishes, maintains and terminates a session between the apparatus communicating with each other.

In addition, attention is paid to a TLS (Transport Layer Security) protocol adopted as a protocol for providing a security function on a session layer. For more information on the TLS protocol, refer to non-patent document 5: IETF RFC2246, The TLS Protocol Version 1.0. The TLS protocol is a security protocol positioned between a transport layer and an application layer as a protocol for authentication and encryption.

DISCLOSURE OF THE INVENTION

The conventional technologies described above have the following problems.

When a mobile node MN pertaining to area A moves to area B connected to area A, an HA placed in area A as an agent for holding information on the locations of mobile nodes operates as a proxy of the mobile node MN.

According to Mobile IPv6, by assigning a unique IP address to a mobile node as a home address that remains the same even if the mobile node moves to another location, it is possible to assure arrival of a packet transmitted from a mobile node at the home address. Since the user adopts the mobile IP, however, the mobile node needs to conform to Mobile IPv6. Nevertheless, this conventional technology has a problem that, at the present time, there are only few mobile nodes conforming to the Mobile IPv6 specifications and applications conforming to the Mobile IPv6 specifications.

In addition, in the VoIP service, in order to prevent audio information from being tapped, encryption of audio packets is demanded.FIG. 37is a diagram showing a security application route, which is taken when a mobile node conforming to the Mobile IPv6 specifications utilizes the VoIP service. Security for an audio packet is applied between a mobile node MN1and a correspondent node CN2. This security is referred to as MN-CN security (1). The correspondent node CN2carries out security processing on a packet356directed to the mobile node MN1(typically in an IPsec transport mode). Without route optimization, an audio packet transmitted and received by the mobile node MN1passes through a home agent HA4. By the same token, security for this audio packet is applied between the mobile node MN1and the home agent HA4. This security is referred to as MN-HA security (2). The MN-CN security (1) and the MN-HA security (2) are independent of each other. For this reason, even if the original packet356is subjected to IPsec processing, the HA may add a header357for IPsec to the original packet356in some cases.

The MN receiving the packet needs to carry out security processing of the same layer twice on the received packet. However, an ordinary MN has a problem of not having processing to terminate IPsec doubly for a received packet.

For the above reason, an OSI reference model is explained. The OSI (Open Systems Interconnection) prescribes a reference model in which a network is divided into hierarchical layers. This reference model is expressed as 7 hierarchical layers. In the following description, each of the hierarchical layers is also referred to simply as a layer. The bottom layer is referred to as layer1while the top layer is referred to as layer7. A procedure of communication between layers is defined by a protocol. For example, the IP protocol and IPsec are the protocol of layer3.

In addition, in a network where security is managed in network units, when a mobile network becomes a network nested inside another network, a communication apparatus is required as an apparatus for carrying out IPinIP encapsulation at least doubly. However, an ordinary apparatus does not have processing to terminate the IPinIP encapsulation a plurality of times. That is, the IPinIP encapsulation cannot be carried out unless the communication apparatus is provided with an IP-layer-processing function.

It is thus an object of the present invention to implement a terminal capable of rendering a Mobile IPv6 service.

In particular, it is an object of the present invention to provide a communication method based on the Mobile IPv6 service for a terminal in which an application does not conform to IPv6.

It is another object of the present invention to provide a mobile terminal with communication methods, which can be switched from one to another according to the state of a network connected to the mobile terminal.

It is a further object of the present invention to provide a mobile terminal with a means for carrying out a security function according to a security management configuration a plurality of times.

It is a still further object of the present invention to provide a means for carrying out an encapsulation function.

TECHNICAL SOLUTION

In order to solve the problems described above, the present invention provides the conventional terminal with at least the following means:

(1) An IP-address translation function is provided for a terminal having a Mobile IPv6 function. To be more specific, the terminal is provided with a means for translating an IP address after carrying out Mobile IPv6 processing in a process to receive a packet according to an IPv6-address system and another means for carrying out Mobile IPv6 processing after translating an IP address in a process of transmitting an IP packet.

(2) As an alternative, in the case of a terminal having an IPsec processing function or an IP encapsulation function, the terminal is provided with a means for carrying out IP decapsulation processing or IPsec processing with respect to the mobile IP after carrying out Mobile IPv6 processing in a process to receive a packet and another means for carrying out Mobile IPv6 processing for a packet being transmitted after carrying out the IP encapsulation processing or the IPsec processing with respect to the mobile IP in a process of transmitting an IP packet.

(3) As another alternative, in the case of a terminal having an HMIPv6 function, the terminal is provided with a means for carrying out Mobile IPv6 processing after carrying out HMIPv6 processing in a process to receive a packet and another means for carrying out HMIPv6 processing after carrying out the Mobile IPv6 processing. The HMIPv6 processing includes the IPsec processing or the IP encapsulation processing and IP decapsulation processing.

(4) The terminal may be further provided with a means for detecting a control signal of the mobile IP to select any of the communication methods described in paragraphs (1) to (3).

(5) As a further alternative, the terminal may be provided with a security-processing means separately from the security processing function related to the mobile IP.

As a still further alternative, a communication apparatus in a communication network exhibiting network mobility may be provided with the packet-processing means described in paragraph (2).

EFFECTS OF THE INVENTION

The present invention provides a mobile terminal capable of rendering a Mobile IPv6 service and a mobile-terminal control method for controlling the mobile terminal.

In particular, by providing the terminal with a means for translating an IP address after carrying out Mobile IPv6 processing in a process to receive a packet according to an IPv6-address system and another means for carrying out Mobile IPv6 processing after translating an IP address in a process of transmitting an IP packet, a terminal capable of utilizing the Mobile IPv6 service can be implemented even if an application does not conform to IPv6.

As an alternative, by providing a terminal having an IPsec processing function or an IP encapsulation/decapsulation function with a means for carrying out IP decapsulation processing or IPsec processing after carrying out Mobile IPv6 processing in a process to receive a packet and another means for carrying out Mobile IPv6 processing for a packet being transmitted after carrying out the IP encapsulation processing or the IPsec processing in a process of transmitting an IP packet, a terminal for carrying out more complicated processing can be implemented.

As another alternative, by providing a terminal having an HMIPv6 function with a means for carrying out Mobile IPv6 processing after carrying out HMIPv6 processing in a process to receive a packet and another means for carrying out HMIPv6 processing after carrying out the Mobile IPv6 processing, a terminal compatible with Mobile IPv6 and HMIPv6 can be implemented.

In addition, by providing the terminal with a means for detecting a control signal of the mobile IP to select a proper communication method, a terminal capable of selecting a communication method according to a communication network can be implemented.

Further, by providing the terminal with a security-processing means separately from the security processing function related to the mobile IP, the terminal becomes capable of terminating security processing on the same layer a plurality of times.

Furthermore, by providing an HA in a communication network having a network mobility function with a means for carrying out IP decapsulation processing or IPsec processing after carrying out Mobile IPv6 processing in a process to receive a packet and another means for carrying out Mobile IPv6 processing for a packet being transmitted after carrying out the IP encapsulation processing or the IPsec processing in a process of transmitting an IP packet, an HA having a network mobility function can be implemented.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

First Embodiment

A first embodiment of the present invention is explained by referring to diagrams.

As a typical representative, the following description explains details of a communication method, which is adopted when an MN (mobile node) conforming to the Mobile IPv6 specifications moves to a network outside a home link, which is also referred to hereafter as a home network. In the following description, the network outside the home link is referred to as a visited network.

FIG. 1is a diagram showing a typical configuration of a communication network according to the present invention. The communication network provided by the present invention includes a home network6of an MN (mobile node)1, an IP network7as well as visited networks5(i.e., visited networks5aand5b). In this embodiment, the home network6, the IP network7and the visited networks5are each an IPv6 network. The MN1is a mobile node conforming to the Mobile IPv6 specifications. The visited networks5are each connected to the IP network7by a router or a gateway apparatus. By the same token, the IP network7is connected to the home network6by a router or a gateway apparatus. The visited networks5can also each be connected to the home network6by a router or a gateway apparatus.

The home network6has an HA (home agent)4. The visited networks5(5aand5b) are provided respectively with routers3aand3beach serving as an interface with the IP network7.

The HA4is a home agent conforming to the Mobile IPv6 specifications. The HA4manages information on locations of the MN1existing at locations outside the home network6. The location information managed by the HA4is information binding the home address of the MN to a CoA of the MN. The HA4has a function to intercept a packet transmitted by a CN (correspondent node)2as a packet directed to the home address of the MN1and pass on the packet to the MN1existing in the visited network5b.

FIG. 2is a block diagram showing of a typical configuration of an application implemented by a program stored in typically a memory serving as a storage part employed in the MN1. The MN1includes a host OS13, an application space11on the host OS13and a virtual machine12.

The virtual machine12includes a guest OS17and an application space16on the guest OS17.

The guest OS17includes a IPv6 processing part25, a virtual communication network15and a virtual communication network14. The virtual communication network15is a network for connecting the guest OS17to the host OS13. The virtual communication network14is a network for connecting the guest OS17to an external communication network. Provided with a function of an MN conforming to the Mobile IPv6 specifications, the IPv6 processing part25includes a binding update list management table210and a BA processing routine70.

The application space16includes an IP-packet processing part22, a scenario processing part23, an IPv6-packet processing part24and a scenario policy21. The IP-packet processing part22has a function for inputting a packet from the host OS13and outputting a packet thereto. The IPv6-packet processing part24has a function to exchange packets with an external communication network. The scenario policy21has a function to manage methods of communication with the MN1. The scenario policy21includes a scenario policy management table220. In this embodiment, the MN1includes a virtual machine. However, the MN1may include a program corresponding to the virtual machine in place of the virtual machine.

FIG. 3is a diagram showing the configuration of the binding update list management table210. For each binding update destination address211, the binding update list management table210associates at least the home address212of the MN with a CoA acquired by the MN in a visited network. The binding update list management table210may also include a life time214showing the validity term of a binding cache. If the binding update list management table210includes a life time214, the MN1is capable of deleting an entry with a validity term that has expired.

FIG. 4is a diagram showing a typical configuration of a scenario policy management table220. The scenario policy management table220is a table at least associating a scenario substance222showing the substance of scenario processing with status223for every scenario number221.

FIG. 5is a block diagram showing of a second typical MN1having an IP-address translation function. Every configuration element shown inFIG. 5is implemented by a program stored in a storage part such as a memory. The scenario processing part23has an IPv4-IPv6 translation function and an IPv4-IPv6 translation table230. On the other hand, the IP-packet processing part22has an IPv4 packet input/output function.

FIG. 6is a diagram showing a typical configuration of the IPv4-IPv6 translation table230. The IPv4-IPv6 translation table230is a table at least associating every IPv6 address231with an IPv4 address232. The IPv4-IPv6 translation table230may also includes a life time233for each IPv6 address231. The life time233is a validity term of the translation entry. If the IPv4-IPv6 translation table230includes a life time233, the MN is capable of deleting a translation entry with a validity term that has expired.

According to a sequence shown inFIG. 10, the MN1existing in the visited network5bshown inFIG. 1registers its location in the HA4before exchanging a packet. The sequence shown inFIG. 10is explained as follows.

Assume that, in the scenario policy management table220, the entry ‘IPv4-IPv6 translation (IPsec)’ is effective. In this case, the IPv6-packet processing part24processes all packets received by the MN1.

The MN1receives a router advertisement from the router3bpertaining to the visited network5band acquires a CoA The MN1sets the Care of Address in the interface part18interfacing with the virtual communication network14. That is, a program of the MN1holds information associating the interface part18with the Care of Address.

After acquiring the CoA in the visited network5b, in a step501, the MN1transmits a location-updating message (a binding update message) to the HA4.

Receiving the binding update message, the HA4updates the binding information of the MN1and functions as a proxy of the MN1.

Then, at the next step502, the HA4transmits a binding acknowledgement to the MN1in response to the binding update message.

FIG. 7is a diagram showing the format of an IPv6 packet. The IPv6 packet is composed of an IPv6 basic header41, an extension header42and a payload43. The IPv6 basic header41includes a source address41aand a destination address41b.

FIG. 8is a diagram showing a typical format S1of the binding acknowledgement message. An IPv6 routing header421and an IPv6 mobility header422are stored in an extension header42. The binding acknowledgement message transmitted by the HA4to the MN1is used for storing the following information. A Care of Address acquired in the visited network5bis stored in the destination address41bincluded in the IPv6 packet header. If information other than the home address of the MN1is stored in the destination address41b, the home address of the MN1is stored in a home-address field4211of the IPv6 routing header421.

Receiving the binding acknowledgement indicating that the binding update process has been completed normally, the IPv6 processing part25employed in the MN1catalogs an entry corresponding to the HA4in a binding update list management table in a step503.

The IPv6-packet processing part24determines that a received packet is a binding acknowledgement if the received packet includes an IPv6 mobility header422and a MH type4221of the IPv6 mobility header422is a code indicating a BA. Receiving the binding acknowledgement conforming to the Mobile IPv6 specifications in a step504, the IPv6-packet processing part24adds a header including a scenario identifier to the input packet. The scenario identifier includes the number 10,000 set therein to indicate ‘IPv4-IPv6 translation (No IPsec)’. The IPv6-packet processing part24then supplies the packet with the header included therein to the scenario processing part23.FIG. 11is a diagram showing the format of the packet with the additional header included therein. A UDP header44has been included in the packet. The scenario identifier is set in a destination-part field45of the UDP header44.

By adding the scenario identifier to the header, the MN becomes capable of selecting a program to be activated among a plurality of programs provided in the scenario processing part23. In addition, since it is easy to add a function to the scenario processing part23, the extendibility of the MN1can be enhanced.

In steps61and505, the scenario processing part23activates the BA processing routine60and decides a scenario on the basis of the scenario identifier set in the additional header and then deletes the additional header. In the case of ‘IPv4-IPv6 translation (No IPsec)’, first of all, a status field4222of the binding acknowledgement is referred to in a step62. If the value set in the status field4222is smaller than 128, the scenario processing part23acquires an HA address and a CoA (Care of Address). The HA address is acquired from the source address41aof the received packet. On the other hand, the Care of Address is acquired from the destination address41bof the received packet. Then, in steps63and506, IPinIP tunnel information is set in the IPv6-packet processing part24. The IPv6-packet processing part24holds an interface with an IPinIP tunnel. At least, the start and end addresses of the IPinIP tunnel are associated with the interface with the IPinIP tunnel.

Then, the home address of the MN1is acquired. The home address of the MN1is acquired from the home-address field4211in the IPv6 routing header of the binding acknowledgement message. Then, the scenario processing part23searches the IPv4-IPv6 translation table230for an entry corresponding to the home address of the MN1. If such an entry is found in the search process, the validity term of the entry is updated in steps64and507before terminating the execution of this routine. If such an entry is not found in the search process, on the other hand, the scenario processing part23selects a virtual IPv4 address from a virtual IPv4 address pool and adds a new translation entry to the IPv4-IPv6 translation table230as an entry associating the virtual IPv4 with the home address of the MN1. Then, in the steps64and507, the virtual IPv4 address set in the IPv4 field232of the translation entry is set in the interface part19before the execution of this routine is ended. The virtual IPv4 address pool is a collection of IPv4 addresses allocated to IP-address translation. Since a packet directed to an IPv6 address is recognized by an IPv4 network, a virtual IPv4 address is associated with the IPv6 address. A program of the MN1holds information associating the interface part19with a virtual IPv4 address.

If the value set in the status field4222is found in the step62to be at least equal to 128, on the other hand, the received packet is discarded in a step67and the execution of this routine is then ended. If the IPinIP tunnel information cannot be set in the step63or the translation entry cannot be updated in the step64, on the other hand, the received packet is discarded in the step67and the execution of this routine is then ended. The HA shows the result of the binding update processing as a number set in the status field of the binding acknowledgement message. If the HA permits the binding update processing, the HA sets a value smaller than 128 in the status field of the binding acknowledgement message. If the HA does not permit the binding update processing, the HA sets a value at least equal to 128 in the Status field of the binding acknowledgement message.

The explanation of the sequence to transmit and receive a packet is continued by referring back toFIG. 10as follows.

The CN2transmits a packet to the MN1by directing the packet to the home address of the MN1in a step508. The HA4intercepts the packet and adds an IP header to the packet509. In the following description, the added IP header is referred to as an outer-side IP header. In the destination address field of the outer-side IP address, the CoA acquired by the MN1in the visited network5bis set. In the source address field of the outer-side IP address, on the other hand, the address of the HA4set.

When the IPv6-packet processing part24employed in the MN1receives the packet transmitted in the step509, the IPv6-packet processing part24checks the source address in the outer-side IP header. If the source address in the outer-side IP header is the address of the HA4, the IPv6-packet processing part24deletes the outer-side IP header in a decapsulation process in a step510and outputs the packet to the scenario processing part23.

The scenario processing part23transforms the IP header of the received packet from an IPv6 header into an IPv4 header at the next step511. First of all, the scenario processing part23searches the IPv4-IPv6 translation table230for an entry corresponding to the destination address. If such an entry is found in the IPv4-IPv6 translation table230, the destination address is transformed from an IPv6 address into an IPv4 address on the basis of information described in the entry associating the IPv6 address with the IPv4 address. Then, the scenario processing part23searches the IPv4-IPv6 translation table230for an entry corresponding to the source address. If such an entry is found in the IPv4-IPv6 translation table230, the source address is transformed from an IPv6 address into an IPv4 address on the basis of information described in the entry associating the IPv6 address with the IPv4 address. If such an entry is not found in the IPv4-IPv6 translation table230, on the other hand, the scenario processing part23selects a virtual IPv4 address from a virtual IPv4 address pool and adds a new translation entry to the IPv4-IPv6 translation table230as an entry associating the virtual IPv4 address with the source address.

Then, at the next step512, the scenario processing part23outputs the packet including the IPv4 header to an application11running on the host OS by way of the IP-packet processing part22.

The following description explains a method adopted by the application11running on the host OS to transmit the packet including the IPv4 header to the CN2. The application11running on the host OS transmits the packet including the IPv4 header to the CN2in a step513. To put it in detail, the IP-packet processing part22inputs the packet and passes on it to the scenario processing part23. First of all, the scenario processing part23searches the IPv4-IPv6 translation table230for an entry corresponding to the destination address. If such an entry is found in the IPv4-IPv6 translation table230, the destination address is transformed from an IPv4 address into an IPv6 address on the basis of information described in the entry associating the IPv6 address with the IPv4 address. If such an entry is not found in the IPv4-IPv6 translation table230, on the other hand, the scenario processing part23selects a virtual IPv6 address from a virtual IPv6 address pool and adds a new translation entry to the IPv4-IPv6 translation table230as an entry associating the virtual IPv6 address with the destination address.

Then, in a step514following the IP-header translation, the scenario processing part23supplies the packet to the IPv6-packet processing part24. In a step515, the IPv6-packet processing part24refers to the IPinIP tunnel information set in the step506to add an IP header to the packet in an encapsulation process. Subsequently, in a step516, the IPv6-packet processing part24transmits the packet to the HA4. In a step517, the HA4deletes the encapsulation header from the packet and then transmits the packet to the CN2.

According to the first embodiment of the present invention, even if the host OS of the terminal does not have the function of an MN conforming to the Mobile IPv6 specifications, a Mobile IPv6 service can be rendered to the terminal. In addition, by providing the terminal with an IP-address translation function, a Mobile IPv6 service can be rendered to the terminal in which an application does not conform to the Mobile IPv6 specifications.

Second Embodiment

Next, a second embodiment of the present invention is explained by referring to diagrams. The second embodiment is characterized in that the second embodiment includes a means for rendering a Mobile IPv6 service to a terminal, which includes an application conforming to IPv6 specifications, in addition to the means employed in the first embodiment.

Assume that, in the scenario policy management table220, the entry ‘No IPv4-IPv6 translation function and no IPsec’ is effective. In this case, the IPv6-packet processing part24processes all packets received by the MN1.

According to a sequence shown inFIG. 12, the MN1existing in the visited network5bshown inFIG. 1registers its location in the HA4before exchanging a packet. The sequence shown inFIG. 12is explained as follows.

Processes carried out in steps501to504as processes starting with a process performed by the MN1to acquire a CoA in the visited network and ending with a process performed by the MN1to register its location are the same as those carried out at their respective counterpart steps of the first embodiment.

When the IPv6-packet processing part24receives a mobile-IPv6 binding acknowledgement signal, a scenario identifier is added to the received packet in the step504. The scenario identifier includes the number 10001 set therein to indicate ‘No IPv4-IPv6 translation function and no IPsec’. The IPv6-packet processing part24then supplies the packet with the header included therein to the scenario processing part23.

In steps61and505, the scenario processing part23activates the BA processing routine60, decides a scenario on the basis of the scenario identifier set in the additional header and then deletes the additional header. In the case of ‘No IPv4-IPv6 translation function and no IPsec’, in the same way as the steps62and63of the first embodiment, the status field4222of the binding acknowledgement is checked and a IP in IP tunnel setting process is carried out in steps66and506before terminating the execution of this routine. The IP in IP tunnel setting process carried out in steps66and506is the same as that of the first embodiment.

In the interface part19of the host OS, the home address of the MN1is set. That is, a program of the MN1associates the home address of the MN1with the interface part19.

Next, a method to receive a packet is explained. Processes carried out in steps508to510are the same as those of the first embodiment. In a step512, the IPv6-packet processing part24outputs the packet to the host OS by way of the IP-packet processing part22without carrying out IP-address translation on the packet already subjected to a decapsulation process.

Then, a method to transmit a packet is explained. When the scenario processing part23receives the packet from application11running on the host OS, the scenario processing part23passes on the packet to the IPv6-packet processing part24in a step513without carrying out IP-address traslation on the packet. Processes carried out in steps515to517are the same as those of the first embodiment.

According to the second embodiment of the present invention, even if the host OS of the terminal does not have the function of an MN conforming to the Mobile IPv6 specifications, a Mobile IPv6 service can be rendered to the terminal. In addition, the home address of the MN can be set in the interface part of the host OS running on the terminal.

Third Embodiment

A third embodiment of the present invention is explained by referring to diagrams.

The third embodiment is characterized in that the third embodiment includes a means for rendering a Mobile IPv6 service to a terminal, which applies IPsec to a mobile IP signal, in addition to the means employed in the first embodiment.

IPsec is security functions used in IETF to perform standardization. To be more specific, IPsec has functions to authenticate and encrypt a packet. An IP packet to which the authentication function of IPsec has been applied has an AH (Authentication Header). On the other hand, an IP packet to which the encryption function of IPsec has been applied has an ESP (Encapsulating Security Payload) header.

According to a sequence shown inFIGS. 19 to 22, the MN1existing in the visited network5bshown inFIG. 1registers its location in the HA4before exchanging a packet. The sequence shown inFIGS. 19 to 22is explained as follows.

Assume that, in the scenario policy management table220, the entries ‘IPv4-IPv6 translation’ and ‘IPv4-IPv6 translation and route optimization’ are valid. In this case, the IPv6-packet processing part24processes all packets received by the MN1.

In the third embodiment, the IPv6 processing part25has a BA processing routine70whereas the IPv6-packet processing part24has a packet send processing routine100, a packet receive processing routine120and a binding update list management table210.

First of all, by referring toFIG. 19, the description explains a sequence of operations carried out by the MN1with its location already registered in the HA4to transmit and receive a packet.

Processes carried out in steps501and502as respectively a process performed by the MN1to acquire a CoA in the visited network and a process performed by the MN1to receive a binding acknowledgement message from the HA4are the same as those carried out at their respective counterpart steps of the first embodiment. In the third embodiment, IPsec has been applied to the binding acknowledgement message. That is, an IP packet including a binding acknowledgement message also includes at least an ESP header. This packet may also include an AH header.

FIG. 14is a diagram showing a typical format of the binding acknowledgement message S2. An IPsec header423is set between an IPv6 routing header421and an IPv6 mobility header422. The IPsec header can be the AH header or the ESP header.

Receiving the binding acknowledgement message conforming to the Mobile IPv6 specifications, the IPv6 processing part25activates the BA processing routine70. First of all, in a step71, the IPv6 routing header421is processed. That is, an address set in the IPv6 routing header421as the home address4211of the MN1is replaced with a CoA set in the IPv6 destination address41b. Then, at the next step72, information in the next header of the IPv6 header41is checked in order to produce a result of determination as to whether or not the information indicates IPsec. If the result of the determination indicates that the information in the next header is IPsec, the flow of the routine goes on to a step73at which the SA of the IPsec header is decided and IPsec processing is carried out on the received packet. The IPsec processing is an authentication process and an encryption/decryption process. Then, at the next step74, the SPD is checked in order to produce a result of determination as to whether or not the SPD conforms to a security policy. Later on, in steps75and503, the Mobile IPv6 processing part25searches the binding update list management table210for an entry corresponding to the source address included in the binding acknowledgement message. If such an entry is found in the search operation, the entry is updated. If such an entry is not found in the search operation, on the other hand, a new entry is added to the binding update list management table210.

Then, in steps76,521and522, the IPv6 processing part25supplies a packet, which is obtained as a result of adding a header including a scenario identifier to the received packet, to the scenario processing part23before the execution of this routine is ended. If the source address of the binding acknowledgement message is the address of the HA, the scenario number is set at 10010 indicating IPv4-IPv6 translation.

If the determination result produced in the step72indicates that the information in the next header is not IPsec, on the other hand, the flow of the routine goes on to a step74.

If the IPv6 processing part25is not capable of deciding the SA in the step73, the determination result produced in the step74indicates that the SPD does not satisfy the security policy or the binding update list management table210cannot be updated in the step, on the other hand, the flow of the routine goes on to a step77at which the received packet is discarded. Then, the execution of this routine is ended.

In steps61and505, the scenario processing part23activates the BA processing routine60and decides a scenario on the basis of the identifier in the added header. Then, the scenario processing part23deletes the added header. In the case of ‘IP4-IP6 translation, the scenario processing part23acquires the address of the HA as well as a Care of Address and sets IP in IP tunnel information in the IPv6-packet processing part24in steps81and506. Then, in steps82and507, the home address of the MN1is acquired and either a new translation entry is generated or an existing translation entry is updated. Finally, the execution of this routine is ended. The processes carried out in the steps81and82are the same as respectively those carried out in the steps63and64in the first embodiment.

If the IP in IP tunnel information cannot be set in the IPv6-packet processing part24in the step81or neither a new translation entry can be generated nor an existing translation entry can be updated in the step S82, on the other hand, the flow of the routine goes on to a step67at which the received packet is discarded. Then, the execution of this routine is ended.

Next, the explanation of the sequence of operations to transmit and receive a packet is continued by referring back toFIG. 19.

In a step508, the CN2transmits a packet to the MN1by directing the packet to the home address of the MN1. The HA4intercepts the packet and adds an IP header to the packet in a step509. In the following description, the added IP header is referred to as an outer-side IP header. In the destination address field of the outer-side IP address, the CoA acquired by the MN1in the visited network5bis set. In the source address field of the outer-side IP address, on the other hand, the address of the HA4is set.

When the IPv6-packet processing part24employed in the MN1receives the packet intercepted in the step509, the IPv6-packet processing part24activates the packet-receive processing routine120.

When the IPv6-packet processing part24receives the packet intercepted in the step509, in a step121, the IPv6-packet processing part24also produces a result of determination as to whether or not the MN1exists in the home network. Since the CoA has been acquired in the step506, the determination result produced by the IPv6-packet processing part24indicates that the MN1exists at a location outside the home network. Then, the IPv6-packet processing part24refers to the value of the next header in the received packet. If the value of the next header indicates an IP header, the IPv6-packet processing part24refers to the source address of the outer-side IP header. If the source address of the outer-side IP header is the address of the HA4, the IPv6-packet processing part24deletes the outer-side IP header in a decapsulation process in steps128and510. In a step129, the IPv6-packet processing part24produces a result of determination as to whether or not a security policy exists. If a security policy does not exist, the IPv6-packet processing part24passes on the packet to the scenario processing part23in a step127. Then, the execution of this routine is ended.

If the determination result produced in the step129indicates that a security policy exists, on the other hand, the flow of the routine goes on to a step126to produce a result of determination as to whether or not the received packet satisfies the security policy. If the received packet satisfies the security policy, the value of the next header in the received packet is referred to in a step131. If the value of the next header does not indicate an IP header, the flow of the routine goes on to the step127at which the received packet is passed on to the scenario processing part23. Then, the execution of this routine is ended.

If the determination result produced in the step S126indicates that the received packet does not satisfy the security policy, on the other hand, the flow of the routine goes on to a step130at which the received packet is discarded. Then, the execution of this routine is ended.

If the determination result produced in the step128indicates that the source address of the outer-side IP header is not the address of the HA4, the flow of the routine goes on to a step130at which the received packet is discarded. Then, the execution of this routine is ended.

The processes carried out in the steps511and512are the same as those of the first embodiment.

The following description explains a method adopted by an application11running on the host OS to transmit a packet to the CN2. Processes carried out in the steps513and514are the same as those of the first embodiment.

After IP-header translation carried out in the step514, the scenario processing part23supplies the packet to the IPv6-packet processing part24. The IPv6-packet processing part24activates the packet-send processing routine100.

When the IPv6-packet processing part24receives the packet supplied in the step514, in a step101, the IPv6-packet processing part24produces a result of determination as to whether or not the MN1exists in the home network. Since the CoA has been acquired in the step506, the determination result produced by the IPv6-packet processing part24indicates that the MN1exists at a location outside the home network. Then, at the next step102, the Mobile IPv6-packet processing part24searches the binding update list management table210for an entry corresponding to the destination address41b. If such an entry was not found in the binding update list management table210in the search operation, the flow of the routine goes on to a step108at which the IPv6-packet processing part24produces a result of determination as to whether or not a security policy exists. If a security policy does not exist, in steps515and111, the IPv6-packet processing part24refers to the IP in IP tunnel information set in the step506and adds an IP header to the packet in an encapsulation process. Then, in a step107, the packet is transmitted to the CN2. Finally, the execution of this routine is ended.

Processes carried out in the steps516and517are the same as those of the first embodiment.

If the determination result produced in a step109indicates that the packet is a packet to be discarded or the SA cannot be detected in a step110, the flow of the routine goes on to a step112at which the packet is discarded. Then, the execution of this routine is ended.

FIG. 20is a diagram showing a sequence of operations to transmit and receive a packet with Mobile IPv6 route optimization applied to the route between the MN1and the CN2.

In a step531, the IPv6 processing part25employed by the MN1transmits a binding update message to the CN2in order to inform the CoA of the MN1. Then, at the next step532, the MN1receives a binding acknowledgement message from the CN2. The binding acknowledgement message received in the step532does not include IPsec.

Receiving the Mobile IPv6 binding acknowledgement message, the IPv6 processing part25activates the BA processing routine70. First of all, the routing header421is processed in a step71. That is, an address set in the IPv6 routing header421as the home address4211of the MN1is replaced with a CoA set in the IPv6 destination address41b. Then, at the next step72, information in the next header of the IPv6 header41is checked in order to produce a result of determination as to whether or not the information indicates IPsec. If the result of the determination indicates that the information in the next header does not indicate IPsec, the flow of the routine goes on to a step74, at which the SPD is checked in order to produce a result of determination as to whether or not the SPD conforms to a security policy. Later on, in steps75and533, the Mobile IPv6 processing part25searches the binding update list management table210for an entry corresponding to the source address included in the binding acknowledgement message. If such an entry has been found in the search operation, the entry is updated. If such an entry was not found in the search operation, on the other hand, a new entry is added to the binding update list management table210.

Then, in steps76,534and535, the IPv6 processing part25supplies a packet, which is obtained as a result of adding a header including a scenario identifier to the received packet, to the scenario processing part23before the execution of this routine is ended. The source address of the binding acknowledgement message is the address of the CN and not the address of the HA. Thus, the scenario number is set at 10,011 indicating the case of ‘IPv4-IPv6 translation and route optimization’.

In steps61and536, the scenario processing part23activates the BA processing routine60and decides a scenario on the basis of the identifier in the added header. Then, the scenario processing part23deletes the added header. In the case of ‘IP4-IP6 translation and route optimization’, first of all, the scenario processing part23refers to the MH type4221of the binding acknowledgement message532in a step83. If the MH type4221has a value indicating a binding acknowledgement message, the binding update list management table210of the IPv6-packet processing part24is searched for an entry corresponding to the source address of the binding acknowledgement message. If such an entry is found, the entry is updated in a step84. If such an entry is not found, on the other hand, a new entry is added to the binding update list management table210in the step84. Then, in steps82and537, the home address of the MN1is acquired and either a new translation entry is generated or an existing translation entry is updated in steps82and537. Finally, the execution of this routine is ended.

If neither a new translation entry can be generated nor an existing translation entry can be updated in the step S84, on the other hand, the flow of the routine goes on to a step67at which the received packet is discarded. Then, the execution of this routine is ended.

If the MH type4221referred to in the step83has a value indicating a binding error message, on the other hand, the flow of the routine goes on to a step85at which the entry is deleted from the binding update list management table210. Then, the execution of this routine is ended.

Next, the explanation of the sequence of operations to transmit and receive a packet is continued by referring back toFIG. 20.

When the CN2transmits a packet to the MN1, the binding cache management table is searched for an entry corresponding to the home address of the MN1. The CN2has acquired the binding information for the CN1in a step531. Thus, the CN2sets the CoA of the MN1at the destination address41b, the home address of the MN1in the IPv6 routing header421and the address of the CN2at the source address41abefore transmitting the packet to the MN1in a step538.

Receiving the packet transmitted in the step538, the IPv6-packet processing part24employed in the MN1activates the packet-receive processing routine120.

In a step121, the IPv6-packet processing part24produces a result of determination as to whether or not the MN1exists in the home network. Since the CoA has been acquired in the step506, the determination result produced by the IPv6-packet processing part24indicates that the MN1exists at a location outside the home network. Then, the IPv6-packet processing part24refers to the value of the next header in the received packet in order to produce a result of determination as to whether or not the value of the next header indicates a routing header. If the result of the determination indicates that the value of the next header in the next header indicates a routing header, the routing header is processed in steps123and539. Then, in a step124, the IPv6-packet processing part24refers to the value of the next header of the routing header in order to produce a result of determination as to whether or not the value of the next header indicates IPsec. If the result of the determination indicates that the value of the next header of the routing header indicates IPsec, the flow of the routine goes on to a step125, at which the SA is searched for and IPsec processing is carried out. Then, the flow of the routine goes on to a step126to confirm a security policy. If the determination result produced in the step124indicates that the value of the next header of the routing header does not indicate IPsec, on the other hand, the flow of the routine goes on to a step129to produce a result of determination as to whether or not the security policy exists. If the security does not exist, the flow of the routine goes on to a step127at which the content is transferred to the scenario processing part23. Then, the execution of this routine is ended.

If the determination result produced in the step129indicates that the security policy exists, the flow of the routine goes on to the step126to produce a result of determination as to whether or not the security policy is satisfied. If the security policy is satisfied, the flow of the routine goes on to a step131at which the value of the next header is checked to produce a result of determination as to whether or not the value of the next header indicates an IP header. If the value of the next header does not indicate an IP header, flow of the routine goes on to the step127at which the received content is transferred to the scenario processing part23. Then, the execution of this routine is ended.

If the result of the process carried out in the step126indicates that the security policy is not satisfied, on the other hand, the flow of the routine goes on to a step130at which the received packet is discarded. Then, the execution of this routine is ended.

If the result of the process carried out in the step125indicates that the IPsec process is not completed normally, on the other hand, the flow of the routine goes on to the step130at which the received packet is discarded. Then, the execution of this routine is ended.

If the result of the process carried out in the step123indicates that the home address of the MN1is not set in the home-address field of the routing header, the flow of the routine goes on to the step130at which the received packet is discarded. Then, the execution of this routine is ended.

Processes carried out in steps540and541are the same as respectively the processes carried out in the steps511and512of the first embodiment.

The following description explains a method adopted by the application11, which is running on the host OS, to transmit a packet to the CN2. Processes carried out in steps542and543are the same as the processes carried out at respectively the steps513and514of the first embodiment.

After IP-header translation carried out in the step543, the scenario processing part23supplies the packet to the IPv6-packet processing part24. The IPv6-packet processing part24activates the packet-send processing routine100.

In a step101, the IPv6-packet processing part24produces a result of determination as to whether or not the MN1exists in the home network. Since the CoA has been acquired in the step506, the determination result produced by the IPv6-packet processing part24indicates that the MN1exists at a location outside the home network. Then, at the next step102, the Mobile IPv6-packet processing part24searches the binding update list management table210for an entry corresponding to the destination address41b. The binding update list management table210includes the entry generated in the step537. Thus, in steps103and544, the IPv6-packet processing part24generates a home address option of a destination option header. The home address of the MN1is set in the home address option. On the other hand, the CoA is set in the source address41awhile the address of the CN2is set in the destination address41b.

Then, the flow of the routine goes on to a step104to produce a result of determination as to whether or not a security policy exists. If the result of determination indicates that a security policy does not exist, the IPv6-packet processing part24transmits the packet to the CN2in steps107and545. Then, the execution of this routine is ended.

If the determination result produced in the step104indicates that a security policy exists, on the other hand, the flow of the routine goes on to a step105at which the security policy of the transmitted packet is decided. If IPsec is applied, the flow of the routine goes on to a step106at which the IPv6-packet processing part24searches for an SA and carries out an IPsec process. Then, in a step107, the IPv6-packet processing part24transmits the packet to the CN2. Finally, the execution of this routine is ended.

If the result of the process carried out in the step105indicates that the packet is a packet to be discarded or the SA cannot be found in the step106, on the other hand, the flow of the routine goes on to a step112at which the IPv6-packet processing part24discards the received packet. Then, the execution of this routine is ended.

By referring toFIG. 21, the following description explains a sequence of operations carried out by the MN1with its location registered in the HA4to transmit and receive a packet through an IPsec mobile IP tunnel.

Processes carried out in steps501to507are the same as those explained earlier by referring toFIG. 19.

In a step508, the CN2transmits a packet to the MN1by directing the packet to the home address of the MN1. The HA4intercepts the packet and adds a mobile tunnel header and an IP header having an IPsec function (IPsec mode) to the packet in a step551. In the destination-address fields of the mobile tunnel header and the IP header having an IPsec function, the CoA acquired by the MN1in the visited network5bis set. In the source-address fields of the mobile tunnel header and the IP header having an IPsec function, on the other hand, the address of the HA4is set.

Receiving the packet transmitted in the step551, the IPv6-packet processing part24employed in the MN1activates the packet-receive processing routine120.

In a step121, the IPv6-packet processing part24produces a result of determination as to whether or not the MN1exists in the home network. Since the CoA has been acquired in the step506, the determination result produced by the IPv6-packet processing part24indicates that the MN1exists at a location outside the home network. Then, the IPv6-packet processing part24refers to the value of the next header in the received packet in order to produce a result of determination as to whether or not the value of the next header indicates IP sec. If the result of the determination indicates that the value of the next header in the next header indicates IP sec, in steps125and552, the SA is searched for and IPsec processing is carried out. Then, the outer-side IP header is deleted in a decapsulation process or an IPsec tunnel-mode process. Subsequently, in steps126and553, the content is checked to produce a result of determination whether or not the content satisfies a security policy. If the content satisfies the security policy, the value of the next header of the packet already subjected to the IPsec process is checked.

If the value of the next header indicates an IP header, a process of a step128is activated. First of all, the source address of the outer-side IP header is checked. If the source address of the outer-side IP header is the address of the HA4, in a step510, the IPv6-packet processing part24deletes the outer-side IP header in a decapsulation process. Then, the flow of the routine goes on to a step129to produce a result of determination as to whether or not a security policy exists. If the result of determination indicates that a security policy does not exist, the flow of the routine goes on to a step127at which the IPv6-packet processing part24transfers the packet to the scenario processing part23. Then, the execution of this routine is ended.

If the value of the next header does not indicate an IP header, on the other hand, the flow of the routine goes on to the step127at which the IPv6-packet processing part24transfers the packet to the scenario processing part23. Then, the execution of this routine is ended.

If the determination result produced in the step126indicates that the content does not satisfy the security policy, on the other hand, the flow of the routine goes on to a step130at which the received packet is discarded. Then, the execution of this routine is ended.

If the SA cannot be found in the step125, on the other hand, the flow of the routine goes on to the step130at which the received packet is discarded. Then, the execution of this routine is ended.

Processes carried out in steps511and512are the same as those of the first embodiment.

The following description explains a method adopted by the application11, which is running on the host OS, to transmit a packet to the CN2. Processes carried out in steps513and514are the same as those carried out at their respective counterpart steps of the first embodiment.

After IP-header translation carried out in the step514, the scenario processing part23supplies the packet to the IPv6-packet processing part24. The IPv6-packet processing part24activates the packet-send processing routine100.

When the IPv6-packet processing part24receives the packet supplied in the step514, in a step101, the IPv6-packet processing part24produces a result of determination as to whether or not the MN1exists in the home network. Since the CoA has been acquired in the step506, the determination result produced by the IPv6-packet processing part24indicates that the MN1exists at a location outside the home network. Then, at the next step102, the Mobile IPv6-packet processing part24searches the binding update list management table210for an entry corresponding to the destination address41b. If such an entry was not found in the binding update list management table210in the search operation, the flow of the routine goes on to a step108at which the IPv6-packet processing part24produces a result of determination as to whether or not a security policy exists.

If a security policy exists, in steps109and554, the security policy of the transmitted packet is decided. If IPsec is applied, in steps110and555, the IPv6-packet processing part24searches for an SA and carries out an IPsec process (or a process in an IPsec tunnel mode) and a mobile IP decapsulation process. Then, in steps107and556, the IPv6-packet processing part24transmits the packet to the CN2. Finally, the execution of this routine is ended.

By referring toFIG. 22, the following description explains a second sequence of operations carried out by the MN1with its location registered in the HA4to transmit and receive a packet through an IPsec mobile IP tunnel.

The format of a packet exchanged between the HA and the MN in the operation sequence shown inFIG. 22is different from the format of a packet exchanged between the HA and the MN in the operation sequence shown inFIG. 21.

If the source and destination addresses in the mobile tunnel header are the same as respectively the source and destination addresses in the IP header with an IPsec function (or the IP header in an IPsec tunnel mode), the HA4in the operation sequence shown inFIG. 22intercepts a packet directed to the MN and adds only the IP header with an IPsec function (or the IP header in an IPsec tunnel mode) to the packet as a step557.

In the destination-address field of the IP header with an IPsec function, the CoA acquired by the MN in the visited network5bis set. In the source-address field of the IP header with an IPsec function, on the other hand, the address of the HA4is set.

Receiving the packet transmitted in the step557, the IPv6-packet processing part24employed in the MN1activates the packet-receive processing routine120.

Processes carried out in steps552and553(and steps121,122,125and126) are the same as those carried out at their respective counterpart steps shown inFIG. 21.

Since the determination result produced in the step131indicates that the value of the next header does not indicate an IP header, in the step127, the IPv6-packet processing part24submits the packet to the scenario processing part23. Then, the execution of this routine is ended.

Processes carried out in steps511and512are the same as those carried out at their respective counterpart steps of the first embodiment.

The following description explains a method adopted by the application11, which is running on the host OS, to transmit a packet to the CN2. Processes carried out in steps513and514are the same as those carried out at their respective counterpart steps of the first embodiment.

After IP-header translation carried out in the step514, the scenario processing part23supplies the packet to the IPv6-packet processing part24. The IPv6-packet processing part24activates the packet-send processing routine100.

Processes carried out in steps554and555(and steps101,102,108and109) are the same as those carried out at their respective counterpart steps shown inFIG. 21.

If the source and destination addresses in the mobile tunnel header are the same as respectively the source and destination addresses in the IPsec tunnel mode IP header, in steps110and555, the MN searches for an SA and carries out an IPsec process (or a process in an IPsec tunnel mode) only. Then, in steps107and558, the IPv6-packet processing part24transmits the packet to the CN2. Finally, the execution of this routine is ended.

According to the third embodiment of the present invention, even if the host OS of the terminal is not provided with an MN function conforming to Mobile IPv6 specifications, after the Mobile IPv6 processing part carries out a Mobile IPv6 process, by activating a scenario of the guest OS, it is possible to provide the terminal with a Mobile IPv6 service applying IPsec.

In addition, by providing the IPv6-packet processing part of the guest OS with a binding update list, it is possible to provide the terminal with a Mobile IPv6 route optimization service.

Further, it is also possible to apply IPsec to a mobile tunnel between the terminal and the HA and render a highly safe service.

Furthermore, if the source and destination addresses in the header for the mobile tunnel are the same as respectively the source and destination addresses for IPsec, the header for the mobile tunnel can be eliminated so that the service can be rendered with a higher degree of efficiency.

Fourth Embodiment

A fourth embodiment of the present invention is explained by referring to diagrams.

The fourth embodiment is characterized in that the fourth embodiment includes a means for rendering a Mobile IPv6 service to a terminal, which utilizes applications conforming to IPv6, in addition to the means employed in the third embodiment.

In the scenario policy management table220of the fourth embodiment, the entry ‘No IPv4-IPv6 translation’ or the entry ‘No IPv4-IPv6 translation and with route optimization’ is effective.

In the fourth embodiment, the scenario processing part23activates the BA processing routine shown inFIG. 16. The BA processing routine shown inFIG. 16is different from the routine shown inFIG. 15in that the BA processing routine shown inFIG. 16does not have the step of updating a translation entry. Steps91to94are the same as the step81and the steps83to85of the third embodiment.

According to the fourth embodiment of the present invention, even if the host OS of the terminal utilizing an application conforming to Mobile IPv6 specifications is not provided with an MN function conforming to Mobile IPv6 specifications, after the Mobile IPv6 processing part carries out a Mobile IPv6 process, by activating a scenario of the guest OS, it is possible to provide the terminal with a Mobile IPv6 service applying IPsec to a Mobile IPv6 signal.

In addition, by providing the IPv6-packet processing part of the guest OS with a binding update list, it is possible to provide the terminal with a Mobile IPv6 route optimization service.

Further, it is also possible to apply IPsec to a mobile tunnel between the terminal and the HA and render a highly safe service.

Furthermore, if the source and destination addresses in the header for the mobile tunnel are the same as respectively the source and destination addresses for IPsec, the header for the mobile tunnel can be eliminated so that the service can be rendered with a higher degree of efficiency.

Fifth Embodiment

A fifth embodiment of the present invention is explained by referring to diagrams. The fifth embodiment is characterized in that the fifth embodiment includes a means for utilizing a VoIP service adopting an SIP conforming to IPv6 specifications in the terminal in addition to the means employed in the fourth embodiment. In the scenario policy management table220of the fifth embodiment, the entry ‘No IPv4-IPv6 translation’ or the entry ‘No IPv4-IPv6 translation and with route optimization’ is effective.

FIG. 23is a diagram showing a typical configuration of a communication network according to the fifth embodiment of the present invention. An SIP proxy8is connected to a router.

FIGS. 24,25and26are diagrams each showing a communication sequence of the MN1in the fifth embodiment.

FIG. 24is a diagram showing a sequence of communications carried out by the MN1with IPsec applied to audio packets exchanged between terminals.

Since steps501to506are the same as their respective counterpart steps shown inFIG. 19, only processes carried out in a step561and subsequent steps are explained.

In steps561and562, the CN2transmits an SIP invite message to the MN1by way of the SIP proxy8. An application running on the host OS of the MN1receives the SIP invite message. Receiving the SIP invite message, the application running on the host OS of the MN1transmits an response message (200OK) to the CN2in response to the SIP invite message in steps563and564. This response message includes the home address of the MN1as an IP address used by the MN1for receiving an audio packet.

Receiving the response message, the CN2transmits an acknowledgement message (ACK) to the MN1in steps565and566. In this way, a session between the CN2and the MN1is established.

If the SIP proxy8does not have binding information of the MN1, messages are exchanged between the MN1and the SIP proxy8by way of the HA4.

Then, in a step567, the CN2transmits an audio packet (or an RTP packet) directed to the home address of the MN1. In this case, IPsec of a transport mode is applied to the audio packet.

In a step568, the HA4intercepts the packet, encapsulates the intercepted packet and transmits the encapsulated packet to the CoA of the MN1.

The IPv6-packet processing part24receives the packet transmitted by the HA4. A step510is the same as its counterpart step shown inFIG. 19.

In a step570, the IPv6-packet processing part24transfers the received packet to the host OS by way of the IP-packet processing part22. The step570is different from the step512in that, in the case of the step570, IP sec is applied to the original packet. After carrying out an IPsec process on the original packet, the host OS processes the audio packet.

Next, a procedure for transmitting an audio packet from the MN1to the CN2is explained. In a step571, the MN1carries out an IP sec process on an IP packet including audio data as a packet to be transmitted to the CN2. Subsequently, in a step515, the IPv6-packet processing part24adds a mobile tunnel header to the packet in an encapsulation process. Then, in a step575, the IPv6-packet processing part24transmits the packet to the CN2by way of the HA4denoted by reference numeral574.

FIG. 25is a diagram showing a sequence of communications carried out by the MN1for a case in which IP sec is applied to an audio packet exchanged between terminals and a mobile tunnel between terminals.

It is assumed that the tunnel mode IPsec is applied to the mobile tunnel between the HA4and the MN1.

Since steps561to566are the same as their respective counterparts shown inFIG. 24, only processes carried out in a step567and subsequent steps are explained.

In a step567, the CN2transmits an audio packet to the MN1by directing the packet to the home address of the MN1. In a step581, the HA4intercepts the packet, adding a mobile tunnel header and an IP header with an IPsec function (IPsec tunnel mode) to the packet in a step581. In the destination-address fields of the mobile tunnel header and the IP header with an IPsec function, the CoA acquired by the MN1in the visited network5bis set. In the source-address fields of the mobile tunnel header and the IP header with an IPsec function, on the other hand, the address of the HA4is set.

Receiving the packet, the IPv6-packet processing part24carries out an SA process and a decapsulation process (an IPsec tunnel mode process) in a step568, an SPD checking process in a step569and a decapsulation process in a step510.

Since the processes carried out in the steps568,569and510are the same as those carried out at respectively the steps552,553and510shown inFIG. 21, their detailed explanations are not repeated. In a step570, the IPv6-packet processing part24transfers the packet to the host OS by way of the IP-packet processing part22. Receiving the packet transmitted in the step570, the host OS carries out an IPsec process before processing the audio packet.

Next, a procedure for transmitting an audio packet from the MN1to the CN2is explained. In a step571, the MN1carries out an IPsec process on an IP packet including audio data as a packet to be transmitted to the CN2. Subsequently, the IPv6-packet processing part24carries out an SPD checking process in a step572. Then, the IPv6-packet processing part24carries out an IPsec process (an IPsec tunnel mode process) and a mobile IP encapsulation process in a step573. Since the processes carried out in the steps572and573are the same as those carried out at respectively the steps554and555shown inFIG. 21, their detailed explanations are not repeated. Subsequently, in a step575, the IPv6-packet processing part24transmits the packet to the CN2by way of the HA4denoted by reference numeral582.

FIG. 26is a diagram showing a sequence of communications carried out by the MN1for a case in which IP sec is applied to an audio packet exchanged between terminals and a mobile tunnel between terminals.

Since steps561to566are the same as their respective counterparts shown inFIG. 24, only processes carried out in a step567and subsequent steps are explained.

The format of a packet exchanged between the HA and the MN in the communication sequence shown inFIG. 25is different from that exchanged in the sequence shown inFIG. 26. In a step567, the CN2transmits an audio packet to the MN1by directing the packet to the home address of the MN1. In a step567, the HA4shown inFIG. 26intercepts the packet address to the MN in the step567, adding only an IP header (IPsec tunnel mode) to the packet in a step583. In the destination-address field of the outer-side IP header, the CoA acquired by the MN1in the visited network5bis set. In the source-address field of the outer-side IP header, on the other hand, the address of the HA4is set.

Receiving the packet, the IPv6-packet processing part24carries out an SA process and a decapsulation process (an IPsec tunnel mode process) in a step568and an SPD checking process in a step569.

Since the processes carried out in the steps568and569are the same as those carried out at respectively the steps552and553shown inFIG. 22, their detailed explanations are not repeated. In a step570, the IPv6-packet processing part24transfers the packet to the host OS by way of the IP-packet processing part22. Receiving the packet transmitted in the step570, the host OS carries out an IPsec process before processing the audio packet.

Next, a procedure for transmitting an audio packet from the MN1to the CN2is explained. In a step571, the MN1carries out an IPsec process on an IP packet including audio data as a packet to be transmitted to the CN2. Subsequently, the IPv6-packet processing part24carries out an SPD checking process in a step572. Then, the IPv6-packet processing part24carries out an IPsec process (an IPsec tunnel mode process) in a step573. Since the processes carried out in the steps572and573are the same as those carried out at respectively the steps554and555shown inFIG. 22, their detailed explanations are not repeated. Subsequently, in a step575, the IPv6-packet processing part24transmits the packet to the CN2by way of the HA4denoted by reference numeral584.

According to the fifth embodiment of the present invention, even if the host OS of the terminal utilizing an application conforming to Mobile IPv6 specifications is not provided with an MN function conforming to Mobile IPv6 specifications, after the Mobile IPv6 processing part carries out a Mobile IPv6 process, by activating a scenario of the guest OS, it is possible to provide the terminal with a Mobile IPv6 service applying IPsec to a Mobile IPv6 signal.

In addition, by separating the IPsec processing part of the mobile IP from the IPsec processing part of an application, an application with attached IPsec can be utilized even if IPsec is applied to a mobile tunnel between the terminal and the HA.

Sixth Embodiment

A sixth embodiment of the present invention is explained by referring to diagrams. The sixth embodiment is characterized in that the terminal has a Mobile IPv6 function and an HMIPv6 function. In the scenario policy management table220of the sixth embodiment, entries ‘MAP type1’, ‘MAP type2’ and ‘MAP type3’ are effective.

FIG. 27is a diagram showing a typical configuration of a communication network according to the sixth embodiment of the present invention. A router3has an HMIPv6 MAP function.

FIG. 28is a block diagram showing of typical configuration of a terminal1according to the sixth embodiment of the present invention. The host OS13has a Mobile IPv6 processing part252in addition to functions of the terminal1according to the first embodiment. In addition, the guest OS17has an HMIPv6 processing part251in place of the IPv6 processing part25.

FIG. 29is a diagram showing a typical format of a router advertisement message S4transmitted by a MAP3.

An ICMP packet431including a router advertisement message is included in the payload portion43of an IPv6 packet. A router advertisement S4transmitted by the MAP3includes a MAP option432. The MAP option432includes a mode of registering an HMIPv6 terminal and a function for informing the terminal of a MAP address.

The mode of registering an HMIPv6 terminal is classified into 3 types by values set in I, P and V bits of the MAP option mode432.

Type1indicates a method for transferring a location registering message exchanged between the terminal1and the HA4as an encapsulated packet propagating through an MN-MAP route. Examples of the location registering message are a binding update message and a binding acknowledgement message.

Type2indicates a method for transferring a binding update message directly from the terminal1to the HA4and a binding acknowledgement message from the HA4to the terminal1as an encapsulated packet propagating through an MAP-MN route.

Type3indicates a method for transferring a location registering message directly from the terminal1and the HA4.

By referring toFIGS. 31 to 33, the following description explains sequences of operations carried out by the MN1existing in the visited network5bshown inFIG. 27to register its location in the HA4and operations to exchange packets.

First of all, by referring toFIG. 31, the following description explains a sequence of operations carried out by the MN1receiving a router advertisement message showing aforementioned type1to exchange packets.

In a step601, the MN1receives a router advertisement, generating an RCoA and an LCoA. Then, the MN1sets the LCoA in the interface part18. Subsequently, in a step602, the MN1transmits a location registering message (or a binding update message) to a MAP3b. The MAP3bholds information associating each RCoA with an LCoA. In a step603, the MAP3btransmits a response (or a binding acknowledgement) to the binding update message. The HMIPv6 processing part251has a binding update list management table. In a step604, the HMIPv6 processing part251adds a MAP entry to the binding update list management table. If the MAP entry already exists in the binding update list management table, the HMIPv6 processing part251merely updates the entry.

Then, in steps605and606, the HMIPv6 processing part251adds a header including an identifier to the binding acknowledgement and transfers the binding acknowledgement to the scenario processing part23. The identifier indicates MAP location registration of type1cited above.

In steps61and607, the scenario processing part23activates the BA processing routine60and decides a scenario.

The scenario processing part23acquires the LCoA, the RCoA and the MAP address from the received packet in a step95. To be more specific, the LCoA, the RCoA and the MAP address are acquired from the destination address41b, the IPv6 routing header and the source address41arespectively. If a process result obtained in a step96indicates that the RCoA has been changed, a value indicating MAP location registration of type1is set in the mobility-options field of the mobility header402. In steps97,608and609, the binding acknowledgement including the mobility options is transferred to the Mobile IPv6 processing part252of the host OS by way of the IP-packet processing part22in steps97,608and609. Then, the execution of this routine is ended.

If the RCoA has not been changed, on the other hand, the execution of this routine is just ended. If the process carried out in the step95is not completed normally, on the other hand, the flow of the routine goes on to a step67at which the received packet is discarded. Then, the execution of this routine is ended.

Receiving the binding acknowledgement, the Mobile IPv6 processing part252transmits a binding update message directed to the HA4in a step610.

The binding update message includes the RCoA as the source address41a, the address of the HA4as the destination address41band the home address of the MN1as the home address option of the destination options header. Receiving the binding update message transmitted in the step610, the HMIPv6 processing part251carries out an IPinIP encapsulation process on the packet and then transmits the packet to the HA4by way of the MAP3b.

Receiving a binding acknowledgement transmitted in a step611, the MAP3bcarries out an IPinIP encapsulation process on the acknowledgement and transmits the packet to the MN1. The HMIPv6 processing part251decapsulates the received packet and transfers the packet to the Mobile IPv6 processing part252. The message includes the RCoA as the destination address41b, the address of the HA4as the source address41aand the home address of the MN1as the home-address field of the routing header.

The Mobile IPv6 processing part252carries out the IPsec process on the location registering signal.

Next, a method adopted by the MN1to exchange packets is explained. The Mobile IPv6 processing part carries out MN1-HA4encapsulation and decapsulation processes on packets exchanged by the MN1and, in addition, the HMIPv6 processing part251carries out MN1-MAP encapsulation and decapsulation processes on the packets in steps612and613.

By referring toFIG. 32, the following description explains a sequence of operations carried out by the MN1receiving a router advertisement message showing type2cited above to transmit and receive packets.

Processes carried out in steps601to604are the same as those carried out at their respective counterpart steps shown inFIG. 31.

Then, in steps605and606, the HMIPv6 processing part251adds a header including an identifier to the binding acknowledgement and transfers the acknowledgement to the scenario processing part23. The identifier indicates MAP location registration of type2.

In steps61and607, the scenario processing part23activates the BA processing routine60and decides a scenario.

The scenario processing part23acquires the LCoA, the RCoA and the MAP address from the received packet in a step98. To be more specific, the LCoA, the RCoA and the MAP address are acquired from the destination address41b, the routing header and the source address41arespectively.

If a process result obtained in a step96indicates that the RCoA has been changed, a value indicating MAP location registration of type2is set in the mobility-options field of the mobility header402. In steps97,608and609, the binding acknowledgement including the mobility options is transferred to the Mobile IPv6 processing part252of the host OS by way of the IP-packet processing part22in steps97,608and609. Then, the execution of this routine is ended.

If the RCoA has not been changed, on the other hand, the execution of this routine is just ended. If the process carried out in the step98is not completed normally, on the other hand, the flow of the routine goes on to a step67at which the received packet is discarded. Then, the execution of this routine is ended.

Receiving the binding acknowledgement, the Mobile IPv6 processing part252transmits a binding update message directed to the HA4in a step621.

The binding update message includes the RCoA as the source address41a, the address of the HA4as the destination address41band the home address of the MN1as the home address option of the destination options header. Receiving the binding update message transmitted in the step621, the HMIPv6 processing part251transmits the packet to the HA4.

Receiving a binding acknowledgement transmitted in a step622, the MAP3bcarries out an IPinIP encapsulation process on the acknowledgement and transmits the packet to the MN1. The HMIPv6 processing part251decapsulates the received packet and transfers the packet to the Mobile IPv6 processing part252. The message includes the RCoA as the destination address41b, the address of the HA4as the source address41aand the home address of the MN1as the home-address field of the routing header.

The Mobile IPv6 processing part252carries out the IPsec process on the location registering signal.

A method adopted by the MN1to receive the packet in a step623is the same as the method implemented in the step612shown inFIG. 31.

In a process carried out by the MN1to transmit a packet to the HA, the Mobile IPv6 processing part252carries out an MN-HA encapsulation process on the data being transmitted and transmits the packet to the HA in a step624.

By referring toFIG. 33, the following description explains a sequence of operations carried out by an MIPv6 MN1receiving a router advertisement message showing type3cited above to transmit and receive packets.

Processes carried out in steps601to604are the same as those carried out at their respective counterpart steps shown inFIG. 31.

Then, in steps605and606, the HMIPv6 processing part251adds a header including an identifier to the binding acknowledgement and transfers the acknowledgement to the scenario processing part23. The identifier indicates MAP location registration of type3.

In steps61and607, the scenario processing part23activates the BA processing routine60and decides a scenario.

The scenario processing part23acquires the LCoA, the RCoA and the MAP address from the received packet in a step99. To be more specific, the LCoA, the RCoA and the MAP address are acquired from the destination address41b, the routing header and the source address41arespectively.

If a process result obtained in a step96indicates that the RCoA has been changed, a value indicating MAP location registration of type3is set in the mobility-options field of the mobility header402. In steps97,608and609, the binding acknowledgement including the mobility options is transferred to the Mobile IPv6 processing part252of the host OS by way of the IP-packet processing part22in steps97,608and609. Then, the execution of this routine is ended.

If the RCoA has not been changed, on the other hand, the execution of this routine is just ended. If the process carried out in the step99is not completed normally, on the other hand, the flow of the routine goes on to a step67at which the received packet is discarded. Then, the execution of this routine is ended.

Receiving the binding acknowledgement, the Mobile IPv6 processing part252transmits a binding update message directed to the HA4in a step631.

The binding update message includes the LCoA as the source address41a, the address of the HA4as the destination address41band the home address of the MN1as the home address option of the destination options header. Receiving the binding update message transmitted in the step631, the HMIPv6 processing part251transmits the packet to the HA4.

Receiving a binding acknowledgement transmitted from the HA4in a step632, the HMIPv6 processing part251passes on the message to the Mobile IPv6 processing part252. The message includes the RCoA as the destination address41b, the address of the HA4as the source address41a, the LCoA as the destination address41band the home address of the MN1as the home-address field of the routing header.

The Mobile IPv6 processing part252carries out the IPsec process on the location registering signal.

A method adopted by the MN1to receive the packet in steps633and634is the same as the method implemented in the steps623and624shown inFIG. 32.

In accordance the sixth embodiment of the present invention, an HMIPv6 service can be provided with ease to an MN conforming to the Mobile IPv6 specifications.

In addition, by separating the Mobile IPv6 processing part from the HMIPv6 processing part, the IPinIP capsulation process or IPsec process of a terminal conforming to the HMIPv6 specifications can be carried out with ease.

Seventh Embodiment

A seventh embodiment of the present invention is explained by referring to diagrams.FIG. 34is a diagram showing a typical configuration of a communication network according to the seventh embodiment of the present invention. In the seventh embodiment, mobile routers10(10aand10b) are connected to routers3(3aand3b) respectively. The mobile routers10(10aand10b) are included in mobile networks9(9aand9b) respectively.

FIG. 35is a block diagram showing a typical configuration of the HA4in the home network6of the MN1. The HA4includes interfaces (IF)319a,319b,319mand319n, servers311(311a,311band311m) and switch sections317(317aand317b). The interfaces (IF)319a,319b,319mand319nare connected to lines318a,318b,318mand318nrespectively.

Each of the servers311includes a packet-send/receive processing part313, an IPsec processing part314and a Mobile-IP processing part315.

The Mobile-IP processing part315has a mobile IP protocol processing function and a mobile IP HA (Home Agent) function. The mobile IP HA (Home Agent) function includes a binding cache management table. The binding cache management table is a table of information associating the home address of each MN1with the Care of Address for the MN1. In addition, in this embodiment, the HA4includes the Mobile-IP processing part315having a processing program to be executed for carrying out a mobile-tunnel process a plurality of times.

FIG. 36is a diagram showing a mobile tunnel application route for a case in which the HA4serves as the HA for the mobile router10and the MN1, which exist in the mobile network9.

When the HA4communicates with the MN1, mobile tunnels are set between the MN1and the HA4as well as between the mobile router10and the HA4. The mobile tunnel between the MN1and the HA4is referred to as (1) an MN-HA mobile tunnel whereas the mobile tunnel between the MR and the HA4is referred to as (2) an MR-HA mobile tunnel.

First of all, the HA4refers to binding information for the MN1and adds an IP header352to an original packet351. As the destination address of the IP header352, the Care of Address of the MN1is set. Then, the HA4refers to binding information for the MR (Mobile Router)10and adds an IP header353to the original packet351. As the destination address of the IP header353, the Care of Address of the MR10is set.

In accordance the seventh embodiment of the present invention, it is possible to easily implement an IP in IP encapsulation process or an IPsec process as many times as required by the HA4in rendering a network mobility service.

Eighth Embodiment

An eighth embodiment of the present invention is explained by referring to diagrams.FIG. 38is a diagram showing a typical configuration of a communication network according to the eighth embodiment of the present invention. The eighth embodiment is characterized in that a network361, which includes the home network6of the MN1and the CN2, is connected to the IP network7through a GW362. The GW362has a TLS termination function.

In the eighth embodiment, an application16running on the guest OS of the MN1has a first TLS termination function.

A sequence of communications carried out by the MN1by adopting the TLS protocol is explained by referring toFIG. 39as follows.

When the MN1existing at a location outside the network361communicates with the CN2serving as a communication apparatus existing at a location inside the network361, the TLS session is set between the MN1and the GW362as a communication session.

First of all, a procedure for a setting TLS session between the MN1and the GW362is explained. The procedure begins with a step701at which the application16running on the guest OS of the MN1transmits ‘Client Hello’ message to the GW362. The ‘Client Hello’ message includes usable encryption algorithms, usable compression algorithms and a client random number. Receiving the ‘Client Hello’ message, the GW362decides an encryption algorithm and a compression algorithm. Then, in a step702, the GW362transmits ‘Server Hello’ message to the application16running on the guest OS of the MN1. The ‘Server Hello’ message includes the determined algorithms and a server random number. If necessary, the GW362may attach its own certificate to the transmitted ‘Server Hello’ message. If the GW362also transmits a certificate to the MN1, the MN1is capable of authenticating the GW362by using the certificate. Then, at the next step703, the GW362transmits ‘Server Hello Done’ message to the MN1as an optional message in order to notify the MN1of the end of the message transmission. In a step704, the application16running on the guest OS of the MN1generates pre-master secret information serving as a seed of encryption parameters and transmits the pre-master secret information to the GW362as ‘Client Key Exchange’ message.

Thus, the application16running on the guest OS of the MN1and the GW362are put in a state of being capable of sharing the used algorithms, the server random number, the client random number and the pre-master secret information. The application16running on the guest OS of the MN1and the GW362generate security parameters required in encryption communications between the application16running on the guest OS and the GW362.

In steps705and706, the application16running on the guest OS of the MN1informs the GW362of finished conditions for operations of ‘Change Cipher Specifications’ and new encryption specifications as ends of the process to set the security parameters. By the same token, in steps707and708, the GW362also informs the application16running on the guest OS of the MN1of ‘Finished’ conditions for operations of ‘Change Cipher Specifications’ and new encryption specifications as ends of the process to set the security parameters. After the above processes, a TLS session709is established between the application16running on the guest OS of the MN1and the GW362.

Next, in order for the application11running on the host OS of the MN1to carry out a communication with the CN2by adoption of TLS in a step712, messages are exchanged in a step710and a TLS session711is established between the application11running on the host OS of the MN1and the CN2. Since a procedure for setting the TLS connection711is the same as that carried out in the steps701to708, details of the procedure are not explained. The TLS session711utilizes the TLS709between the application16running on the guest OS of the MN1and the GW362.

According to the eighth embodiment, the MN1is capable of carrying out a TLS process a plurality of times in order to establish a TLS session between 2 communication apparatus.

Ninth Embodiment

The present invention can also be implemented even to the mobile terminal described as follows.

In a communication system including first and second networks connected to each other as well as a home agent connected to the first network, there is a mobile terminal connected to the home agent. The mobile terminal is characterized in that the mobile terminal receives a response from the home agent as a response to a location registration transmitted from the mobile terminal to the home agent and, decides a communication method to be adopted in the mobile terminal on the basis of the response.

As an alternative, the mobile terminal is characterized in that the mobile terminal includes a Mobile IPv6 processing part and an IP-address translation part and, when the mobile terminal receives a packet according to a first address system, after the Mobile IPv6 processing part carries out a Mobile IPv6 process on the received packet, the IP-address translation part transforms the packet already subjected to the Mobile IPv6 process into a packet according to a second address system whereas, before the mobile terminal transmits a packet according to the first address system, after the IP-address translation part transforms the packet to be transmitted into a packet according to the second address system, the Mobile IPv6 processing part carries out a Mobile IPv6 process on the packet according to the second address system.

As another alternative, the mobile terminal is characterized in that the first address system is IPv6 and the second address system is IPv4.

As a further alternative, the mobile terminal is characterized in that the mobile terminal includes a first IPsec processing part and a Mobile IPv6 processing part further having an embedded second IPsec processing part and, when the mobile terminal receives a packet, after the second IPsec processing part carries out a second IPsec process regarding a Mobile IPv6 process on the received packet, the first IPsec processing part further carries out a first IPsec process on the packet already subjected to the second IPsec process.

The communication system is further characterized in that the communication system has a connection apparatus for connecting the first and second networks to each other and the connection apparatus is a MAP of HMIPv6.

INDUSTRIAL FIELD OF APPLICATION

By virtue of the present invention, a communication apparatus is capable of terminating a security process on the same layer or a header process a plurality of times. It is quite within the bounds of possibility that the present invention can be applied to implementation of a communication apparatus for carrying out a process according to a security management configuration.