CN101237410A - A Communication Method for Realizing Mobile Nodes in IPv4/v6 Mixed Network - Google Patents

Abstract

The present invention relates to a communication method for a mobile node in an IPv4/v6 hybrid network. The method specifically implements mobile communication in an IPv4/v6 hybrid network by setting a mobile IPv4/v6 conversion gateway between the IPv4 network and the IPv6 network. The mobile IPv4/v6 conversion gateway includes a NAT-PT gateway and a mobile IP application layer gateway set on it, wherein DNS-ALG is configured on the NAT-PT gateway. The present invention can make full use of the existing MIPv4 (RFC3344) and MIPv6 (RFC3775) technologies, effectively solve the problems of the mobile communication of the mobile node in the IPv4/v6 hybrid network, and realize the compatibility of the MIPv4 technology and the MIPv6 technology, The synchronization of mobile communication and network transition from IPv4 to IPv6 is realized, and at the same time, the present invention requires that existing mobile communication equipment does not need to be upgraded too much, and has great practical value.

Description

A Communication Method for Realizing Mobile Nodes in IPv4/v6 Mixed Network

technical field

The invention relates to the field of network and mobile communication, in particular to a communication method of a mobile node in an IPv4/v6 mixed network.

Background technique

Currently, mobile communication is the most important application carried by the Internet. Mobile IP studies the problem of Internet carrying mobile communication. Specifically, Mobile IPv4 studies the problem of IPv4 network carrying mobile communication. Mobile IPv6 studies the problem of IPv6 network carrying mobile communication. Mobile IPv4/v6 is the study of IPv4/v6 network carrying mobile communication. .

Figure 1 is a schematic diagram of the basic principles of the Mobile IPv4 technology described in RFC3344, and its key steps are as follows:

(1) The mobile node moves from the local network to the foreign network;

(2) Foreign agents indicate their existence through Agent Advertisement Message;

(3) The mobile node can also optionally request the mobile agent on the link to send an agent advertisement message to it through an agent request message (Agent Solicitation Message);

(4) The mobile node receives the mobile agent advertisement message, and judges whether it is in the home network or the foreign network according to the message;

(5) If the mobile node finds itself moving to a foreign network, it obtains a care-of address from the foreign network. The care-of address can be assigned by the foreign agent, or can be obtained through DHCP, etc.;

(6) The mobile node sends a registration request message to the home agent to register its care-of address. The format of the registration request message is shown in Figure 2A, which contains data such as the home address of the mobile node, home agent address, care-of address, identifier, and the extension part contains authentication data between the mobile node and the home agent. When the registration request message When the foreign agent needs to be passed, the extension part will also include the authentication data between the mobile node and the foreign agent; the registration request message and the registration response message generally need to pass through the foreign agent;

(7) The home agent processes the above registration request message, creates or updates its binding cache, and sends a registration response message to the mobile node to notify the mobile node of the registration result. The format of the registration response message is shown in Figure 2B, which includes data such as the home address of the mobile node, the home agent address, and the identifier, and in addition, some authentication data is included in the extended part;

(8) When the correspondent node sends a data message to the mobile node, the source address is the address of the correspondent node, and the destination address is the home address of the mobile node. When the data message passes through the home network, it is intercepted by the home agent and sent to the care-of address of the mobile node through a tunnel;

(9) When the mobile node sends a data message to the correspondent node, the source address is the home address of the mobile node, and the destination address is the address of the correspondent node, so the data message does not need to go through the home network.

Figure 3 is a schematic diagram of the basic principles of the Mobile IPv6 technology described in RFC3775, and its key steps are as follows:

(1) The mobile node moves from the local network to the foreign network;

(2) After the mobile node moves to a foreign network, it will obtain a care-of address in a stateful or stateless manner;

(3) The mobile node registers its care-of address with the home agent by sending a binding update message to the home agent, and the format of the binding update message is shown in Figure 4A;

(4) The home agent processes the above-mentioned binding update message, creates or updates its binding cache, and sends a binding confirmation message to the mobile node to notify the mobile node of the registration result, the format of the binding confirmation message is as shown in Figure 4B;

(5) The mobile node initiates the Return Routability Procedure (RRP) process. The RRP process includes 4 messages, namely the Home Test Init and Care-of Test Init messages sent by the mobile node to the correspondent node, and their respective response messages Home Test and Care -of Test message, wherein, the HomeTest Init message and the Home Test message are forwarded through the home agent. The purpose of the RRP process is to ensure that the home address of the mobile node and its care-of address are reachable. FIG. 5 is a flowchart of RRP in the mobile IPv6 technology described in RFC3775.

(6) After the RRP process ends, the mobile node sends a binding update message to the correspondent node;

(7) The communication node creates or updates its binding cache, and sends a binding confirmation message to the mobile node;

(8) There are two ways of communication between the mobile node and its correspondent node:

The first is the "two-way tunnel" approach. The data message sent by the communication node is routed to the home network, and the home agent intercepts the data message and sends the data message to the care-of address of the mobile node through the tunnel; while the data message sent by the mobile node is sent to the home network through the reverse tunnel. home network, and then sent from the home network to the correspondent node. In this way, the communication node does not need to know the current location information of the mobile node.

The second is the "route optimization" approach. This communication method allows the correspondent node to send data packets directly to the care-of address of the mobile node. The prerequisite is that the mobile node must register with the correspondent node so that the correspondent node knows the binding relationship between its home address and the care-of address.

The solution to move IPv4/v6 depends on how the IPv4 network is mixed with the IPv6 network. Currently, IETF recommends three methods: tunnel (RFC3053), dual stack (RFC2893) and NAT-PT (RFC2766). The mobile IPv4/v6 solution proposed by the invention is based on NAT-PT.

NAT-PT is a network layer device that can maintain mutual transparency between IPv4 and IPv6. In particular, NAT-PT provides a mechanism to maintain the mutual transparency of the same application carried by the IPv4 network and the IPv6 network by adding an application layer gateway on it. At present, ftp-ALG and DNS-ALG have become the standard configuration of NAT-PT.

FIG. 6 is a schematic diagram of the working principle of implementing DNS query in an IPv4/v6 hybrid network by using a NAT-PT gateway plus a DNS-ALG. As shown in Figure 6, it is a key step to realize DNS query of IPv4/v6 hybrid network with NAT-PT gateway plus DNS-ALG, as follows:

(1) An IPv6 host wants to establish a connection with an IPv4 host, but it does not know what the IPv6 address of the IPv4 host is. Then a DNS request message is sent to ask for the IPv6 address of IPv4.com, and the DNS request message is sent to the DNS server A in the IPv6 network, but the record of the IPv4 host cannot be found in the DNS server A in the IPv6 network (the record of IPv6 is A6 or is AAAA, and the IPv4 record is A);

(2) IPv6DNS then forwards the request message and is intercepted by DNS-ALG;

(3) DNS-ALG changes A6 or AAAA in the request message to A, and forwards it to the IPv4 network;

(4) DNS server B in the IPv4 network receives the request message, and replies that the address of the IPv4 host is 202.116.78.11;

(5) After receiving the address information, DNS-ALG adds a 96-bit prefix to the IPv4 address to become the IPv6 address prefix::202.116.78.11;

(6) DNS-ALG changes A to A6 or AAAA and then continues to send the DNS response message back to the DNS server A in the IPv6 network, and then passes it to the IPv6 host;

(7) The IPv6 host thinks that the address of IPv4.com is prefix::202.116.78.11, so it sends an IPv6 packet whose source address is 3FFE:3600:B::2 and whose destination address is prefix::202.116.78.11;

(8) When the packet passes through the conversion gateway, it first checks whether there is an entry with a source address of 3FFE:3600:B::2 in its address mapping table, if there is, use it directly, if not, from the IPv4 address pool Assign an IPv4 address to this IPv6 host, and add an entry 3FFE:3600:B::2-203.69.0.1 to the address mapping table while assigning the IPv4 address, and at the same time, the NAT-PT gateway removes the 96-bit prefix of the destination address to obtain a IPv4 address, that is, the IPv4 address of the IPv4 host;

(9) The conversion gateway performs address and semantic conversion according to the established address mapping relationship, and the group header is converted into a packet header of IPv4. The source address in the packet header is "203.69.0.1", and the destination address is "202.116.78.11", and then Send packets to IPv4 network.

Conversely, the reason for an IPv4 host to query the IPv4 address of an IPv6 host is the same, and the communication process is basically the same.

Currently, IETF has promulgated mobile IPv4 solutions (RFC3344) and mobile IPv6 solutions (RFC3775), which provide relatively complete solutions for the application of mobile IP in pure IPv4 networks and pure IPv6 networks. However, neither of the above two RFCs involves the situation of IPv4/v6 hybrid network. With the transition from IPv4 network to IPv6 network, it is necessary to study the mobile communication issues of IPv4/v6 hybrid network. The mobile communication of IPv4/v6 hybrid network Communication problems can be divided into the following 16 sub-problems from static and dynamic perspectives:

A1. First, from a static point of view, according to the position of the home agent and the communication node in the IPv4/v6 hybrid network, the problem of mobile IPv4/v6 is divided into four basic problems, and step A1 specifically includes:

A11. Both the home agent and the communication node are located in the IPv6 network, and the problem of mobile IPv4/v6 when the mobile node moves in the IPv4/v6 mixed network;

A12. The home agent and the communication node are both located in the IPv4 network, and the problem of mobile IPv4/v6 when the mobile node moves in the IPv4/v6 mixed network;

A13. The problem of mobile IPv4/v6 when the home agent is located in the IPv6 network, the communication node is located in the IPv4 network, and the mobile node moves in the IPv4/v6 mixed network;

A14. The home agent is located in the IPv4 network, the communication is located in the IPv6 network, and the problem of mobile IPv4/v6 when the mobile node moves in the IPv4/v6 mixed network.

A2. Secondly, from a dynamic point of view, according to the mobile situation of the mobile node in the IPv4/v6 hybrid network, each basic problem described in the step A1 is further divided into four sub-problems, and its step A2 specifically includes:

A21. The problem of mobile IPv4/v6 when the mobile node moves in the IPv4 network;

A22. The problem of mobile IPv4/v6 when the mobile node moves in the IPv6 network;

A23. The problem of mobile IPv4/v6 when the mobile node moves from IPv4 network to IPv6 network;

A24. The problem of mobile IPv4/v6 when the mobile node moves from IPv6 network to IPv4 network.

In addition, in order to facilitate the expression of the core idea of the present invention, the present invention defines the expressions of some terms, and FIG. 7 shows the abbreviations and explanations of some terms used in the present invention. The column on the left of the figure is the original term, and the column on the right of the figure is the abbreviation of the term. The present invention uses the abbreviation of the term to describe the content of the invention. At the same time, the present invention represents version 4 or version 6 by adding "v4" or "v6" after the above term. For example, MIPv4 means Mobile IPv4, CNv6 means CN in IPv6 network, and HoAv6 means MN's home address in IPv6 format.

In addition, the NAT-PT gateway will handle different addresses differently. If NAT-PT adds "#" after an IPv4 address, it means that this address is an address in the IPv4 address pool in NAT-PT and forms a mapping relationship with an IPv6 address. For example, CNAv4# is an address in the IPv4 address pool in NAT-PT, which forms a mapping relationship with CNAv6, and is the address identifier of CNv6 in the IPv4 network. The data packet in IPv4 format with CNAv4# as the destination address will be routed to NAT-PT. If NAT-PT adds "*" after an IPv6 address, it means that this address is composed of an IPv4 address and the 96-bit address prefix of NAT-PT. For example, CoAv6 ^* is composed of the 96-bit address prefix of CoAv4 and NAT-PT, and is the address identifier of MNv4 on the IPv6 network. The data packets in IPv6 format with CoAv6 ^* as the destination address will be routed to NAT-PT.

Contents of the invention

The purpose of the present invention is to overcome the deficiencies in the prior art, provide a kind of communication method that realizes the mobile node in the IPv4/v6 mixed network, this method effectively solves the problem that the mobile node exists in the mobile communication of the IPv4/v6 mixed network problems, and at the same time, the present invention requires that the existing mobile communication equipment does not need to be upgraded too much, and has great practical value.

In order to achieve the above-mentioned technical purpose, the technical solution of the present invention: a kind of communication method that realizes mobile node in IPv4/v6 hybrid network, realizes IPv4/v6 hybrid by arranging mobile IPv4/v6 conversion gateway between IPv4 network and IPv6 network For mobile communication in the network, the mobile IPv4/v6 conversion gateway includes a NAT-PT gateway and a mobile IP application layer gateway arranged on it, wherein DNS-ALG is configured on the NAT-PT gateway.

The steps of the communication method of the mobile node in the IPv4/v6 hybrid network are:

Step A is: the mobile IPv4/v6 conversion gateway acts as different entities described in RFC3344 and RFC3775 in the IPv4 network and IPv6 network respectively, and realizes the mutual transparency of RFC3344 and RFC3775 by performing conversion between entities within the gateway. Specifically, this step A specifically includes:

A1. The mobile IPv4/v6 conversion gateway acts as an entity described in RFC3344 on the side of the IPv4 network. This entity and other entities in the IPv4 network form a mobile IP model described in RFC3344. This mobile IP model is described in RFC3344 Mobile IPv4 protocol for communication and update;

A2. The mobile IPv4/v6 conversion gateway acts as an entity described in RFC3775 on the side of the IPv6 network. This entity and other entities in the IPv6 network form a mobile IP model described in RFC3775. This mobile IP model is described in RFC3775 Mobile IPv6 protocol for communication and update;

A3. The mobile IPv4/v6 conversion gateway realizes the conversion from an IPv4 form entity to an IPv6 form entity through the internal conversion between entities, from an IPv6 form entity to an IPv4 form entity, and realizes similar The conversion between entities, so as to finally realize the mutual transparency of RFC3344 and RFC3775.

Step B is: the mobile IPv4/v6 conversion gateway is responsible for converting various messages and data packets related to mobile IP sent from the IPv4 network to the IPv6 network, and responsible for converting the messages and data packets related to mobile IP sent from the IPv6 network to the IPv4 network. related to various messages and datagrams for conversion. Specifically, this step B includes:

B1. The mobile IPv4/v6 conversion gateway is responsible for converting the registration request message described in RFC3344 into the binding update message described in RFC3775, and converting the registration response message described in RFC3344 into the binding confirmation message described in RFC3775;

B2. The mobile IPv4/v6 conversion gateway is responsible for converting the binding update message described in RFC3775 into the registration request message described in RFC3344, and converting the binding confirmation message described in RFC3775 into the registration response message described in RFC3344;

B3. The mobile IPv4/v6 conversion gateway is responsible for address protocol conversion of the data message, and when sending and receiving data messages on the IPv6 network side, according to the requirements described in RFC3775, the care-of address in the IP header of the data message in IPv6 format Exchange with the home address in the extension header.

Step C is: the mobile IPv4/v6 conversion gateway intercepts messages and data packets related to mobile IP according to the following principles: when updating, intercept the message according to the type of the message; when communicating, intercept the data according to the destination address of the data packet message; specifically, this step C includes:

C1. During communication, the mobile IPv4/v6 conversion gateway acts as different entities according to different communication situations. Since the data packets with the IP addresses of these entities as the destination address will be routed to the mobile IPv4/v6 conversion gateway, therefore, the mobile The IPv4/v6 conversion gateway will intercept the data packets with the IP addresses of these entities as the destination address;

C2. When updating, the mobile IPv4/v6 conversion gateway intercepts the message according to the type of the message, and the method further specifically includes:

C21. In the IPv4 network, the messages that the mobile IPv4/v6 conversion gateway needs to process include the registration request message and registration response message described in RFC3344 and the newly defined proxy request message and proxy response message in the present invention. For these four kinds of messages, mobile The IPv4/v6 conversion gateway intercepts the message according to the UDP encapsulation and destination port number of the message at the network layer, and distinguishes it according to the load type value of the message at the application layer;

C22. On an IPv6 network, the messages that the mobile IPv4/v6 conversion gateway needs to process include binding update messages, binding confirmation messages, Home Test Init messages, Home Test messages, Care of Test Init messages, and Care of Test messages described in RFC3775. ; For these messages, the mobile IPv4/v6 conversion gateway intercepts the message at the network layer according to the next header number of the mobile extension header of the message as 135 as a sign, and distinguishes the message at the application layer according to the MH value in the load.

Step D is: the mobile IPv4/v6 conversion gateway adopts the security mechanism provided by RFC3344 when processing IPv4 format messages and data packets, and adopts the security mechanism provided by RFC3775 when processing IPv6 format messages and data packets; this step D is specific yes:

D1. When the mobile IPv4/v6 conversion gateway receives a message or data message, it will perform authentication according to the authentication algorithm described in RFC3344 or RFC3775 according to whether the message or data message is in IPv4 format or IPv6 format;

D2. When the mobile IPv4/v6 conversion gateway sends a message or data message, it will generate authentication data according to the authentication algorithm described in RFC3344 or RFC3775 according to whether the message or data message is in IPv4 format or IPv6 format, and this authentication data will be as part of this message or datagram.

Step E is: the requirements for the home agent and the communication node in the method for realizing the communication of the mobile node in the IPv4/v6 hybrid network proposed by the present invention are consistent with the requirements described in RFC3344 and RFC3775, but the requirements for the mobile node are increased. The step E is specifically: the step E specifically includes:

E1. The mobile node can meet the requirements of mobile nodes described in RFC3344 and RFC3775;

E2. The mobile node can record the domain names of the home agent and the communication node, can discover the mobile IPv4/v6 conversion gateway through DNS query, and obtain the addresses of the home agent and the communication node;

E3. The mobile node can support the extension of the registration request message and the registration response message, and can generate and process the proxy request message and the proxy response message.

Step F is: when the home agent is located in the IPv4 network, the communication node is located in the IPv6 network, and the key steps of moving IPv4/v6 when the mobile node moves in the IPv4/v6 hybrid network include:

F1. When the mobile node moves from the IPv6 network to the IPv4 network, the mobile node sends a proxy request message to the mobile IPv4/v6 conversion gateway, requesting the mobile IPv4/v6 conversion gateway to act on behalf of the mobile node to initiate its home address to the communication node in the IPv6 network Binding update with care-of address;

F2. After the mobile IPv4/v6 conversion gateway receives the proxy request message, the proxy mobile node will initiate an update process to the communication node in the IPv6 network. At this time, the mobile IPv4/v6 conversion gateway will act as the IPv6 format on the IPv6 network side. Home agent and the mobile node in IPv6 format, after the mobile IPv4/v6 conversion gateway receives the binding confirmation message, it sends an agent response message to the mobile node in the IPv4 network;

F3. The format of the proxy request message is the same as that of the registration request message in RFC3344, and the format of the proxy response message is the same as that of the registration response message in RFC3344, wherein the type value of the proxy request is tentatively set to 7, and the proxy response The type value of the message is tentatively set to 8.

Compared with prior art, the advantage of the present invention is:

It can make full use of the existing MIPv4 (RFC3344) and MIPv6 (RFC3775) technologies to realize the mobile communication of mobile nodes in the IPv4/v6 hybrid network, and realize the compatibility of MIPv4 technology and MIPv6 technology, and realize the mobile communication and network from IPv4 The synchronicity of the transition to IPv6, and at the same time, the present invention requires that the existing mobile communication equipment does not need to be upgraded too much, and has great practical value.

Description of drawings

Fig. 1 is a schematic diagram of the basic principle of the Mobile IPv4 technology described in RFC3344;

FIG. 2A is a schematic diagram of the format of a registration request message;

FIG. 2B is a schematic diagram of the format of the registration response message;

Fig. 3 is a schematic diagram of the basic principle of the Mobile IPv6 technology described in RFC3775;

FIG. 4A is a schematic diagram of the format of a binding update message;

FIG. 4B is a schematic diagram of the format of a binding confirmation message;

Fig. 5 is the flowchart of RRP in the Mobile IPv6 technology described in RFC3775;

Fig. 6 is a schematic diagram of the working principle of DNS query of IPv4/v6 network with NAT-PT gateway plus DNS-ALG;

Fig. 7 is the abbreviation and explanation thereof of some terms used among the present invention;

Fig. 8 is a schematic diagram of MIPv4/v6-TG acting as different entities for a specific communication situation in the present invention;

Figure 9 is a schematic diagram of the layout where both the HA and the CN are located in the IPv6 network and the MN moves in the IPv4/v6 hybrid network;

Figure 10 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv6 network and the MN moves in the IPv6 network;

Figure 11 is a schematic diagram of the address configuration of MIPv4/v6-TG when both HA and CN are located in the IPv6 network and the MN moves in the IPv4 network;

Fig. 12 is the communication flowchart when both HA and CN are located in the IPv6 network and the MN moves in the IPv4 network;

Fig. 13 is the update flowchart when both HA and CN are located in the IPv6 network and the MN moves in the IPv4 network;

Fig. 14 is the update flowchart when both HA and CN are located in the IPv6 network and the MN moves from the IPv6 network to the IPv4 network;

Figure 15A is a schematic diagram of the extended format of the registration request message when both the HA and the CN are located in the IPv6 network and the MN moves from the IPv6 network to the IPv4 network;

15B is a schematic diagram of the format of the registration response message when both the HA and the CN are located in the IPv6 network and the MN moves from the IPv6 network to the IPv4 network;

Figure 16 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv6 network and the MN moves from the IPv4 network to the IPv6 network;

Figure 17 is a schematic diagram of the layout where both the HA and the CN are located in the IPv4 network and the MN moves in the IPv4/v6 hybrid network;

Figure 18 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv4 network and the MN moves in the IPv4 network;

Figure 19 is a schematic diagram of the address configuration of MIPv4/v6-TG when both HA and CN are located in the IPv4 network and the MN moves in the IPv6 network;

Fig. 20 is the communication flowchart when both HA and CN are located in IPv4 network and MN moves in IPv6 network;

Figure 21 is an update flowchart when both HA and CN are located in the IPv4 network and the MN moves in the IPv6 network;

Figure 22 is an update flow chart when both HA and CN are located in the IPv4 network and the MN moves from the IPv4 network to the IPv6 network;

Figure 23 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv4 network and the MN moves from the IPv6 network to the IPv4 network;

Figure 24 is a schematic diagram of the layout where the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4/v6 hybrid network;

Figure 25 is a schematic diagram of the address configuration of MIPv4/v6-TG when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv6 network;

Fig. 26 is a communication flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv6 network;

Figure 27 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv6 network;

Figure 28 is a schematic diagram of the address configuration of MIPv4/v6-TG when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4 network;

Fig. 29 is a communication flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4 network;

Figure 30 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4 network;

Figure 31 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves from the IPv6 network to the IPv4 network;

FIG. 32A is a schematic diagram of the extended format of the registration request message when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves from the IPv6 network to the IPv4 network;

32B is a schematic diagram of the format of the registration response message when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves from the IPv6 network to the IPv4 network;

Figure 33 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves from the IPv4 network to the IPv6 network;

Figure 34 is a schematic diagram of the layout where the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4/v6 hybrid network;

Figure 35 is a schematic diagram of the address configuration of MIPv4/v6-TG when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4 network;

Fig. 36 is a communication flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4 network;

Figure 37 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4 network;

Figure 38 is a schematic diagram of the address configuration of MIPv4/v6-TG when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv6 network;

Fig. 39 is a communication flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv6 network;

Figure 40 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv6 network;

Figure 41 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves from the IPv4 network to the IPv6 network;

Figure 42 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves from the IPv6 network to the IPv4 network;

Figure 43A is a schematic diagram of the format of the proxy request message when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves from the IPv6 network to the IPv4 network;

Fig. 43B is a schematic diagram of the format of the proxy response message when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves from the IPv6 network to the IPv4 network.

Detailed ways

The invention relates to a communication method for realizing a mobile node in an IPv4/v6 mixed network, and the communication method is to solve sixteen sub-problems existing in the mobile IPv4/v6.

Detailed description will be given below with reference to the drawings and specific embodiments.

As shown in Figure 8, the home agent is located in the IPv4 network (denoted as HAv4), the communication node is located in the IPv6 network (denoted as CNv6), the mobile node moves within the IPv4 network (denoted as MNv4), and MIPv4 is set between the IPv4 network and the IPv6 network. /v6-TG. In this case, MIPv4/v6-TG acts as a communication node (denoted as CNv4) on the side of the IPv4 network, and communicates with HAv4 and MNv4 according to the MIPv4 technology described in RFC3344. MIPv4/v6-TG acts as a mobile node (marked as MNv6) on the side of the IPv6 network, and communicates with CNv6 according to the MIPv6 technology described in RFC3775. MIPv4/v6-TG converts between CNv4 and MNv6 internally.

As shown in Figure 9, both the HA and the CN are located in the IPv6 network, and the MN moves in the IPv4/v6 hybrid network. The whole process can be divided into the communication between the MN and the CN when the MN moves in the IPv6 network, the communication between the MN and the CN when the MN moves in the IPv4 network, and the MN Communication with CN when moving from IPv6 network to IPv4 network, communication with CN when MN moves from IPv4 network to IPv6 network. The communication in these situations will be described in detail below.

Fig. 10 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv6 network and the MN moves in the IPv6 network. When the MN moves in the IPv6 network, the MN, HA and CN are all in the IPv6 network. This is a typical MIPv6 problem. It will communicate and update according to the MIPv6 technology described in RFC3775. The specific implementation process is shown in Figure 3.

Fig. 11 is a schematic diagram of address configuration of MIPv4/v6-TG when both the HA and the CN are located in the IPv6 network and the MN moves in the IPv4 network. When the MN moves on the IPv4 network, MIPv4/v6-TG acts as MNv6 on the side of the IPv6 network, and constitutes two entities of the MIPv6 technology described in RFC3775 with CNv6, and communicates according to the MIPv6 technology described in RFC3775. In order to make MIPv4/v6 -TG can replace the home address and the care-of address when sending data packets to CNv6 on the IPv6 network side, and the MIP-ALG in MIPv4/v6-TG must maintain the binding of the home address and the care-of address in IPv6 format: HoAv6 CoAv6 ^* .

On the IPv4 network side, MIPv4/v6-TG acts as HAv4 when sending data packets, and acts as CNv4 when receiving data packets, and MNv4 constitutes three entities of the MIPv4 technology described in RFC3344, according to the MIPv4 technology described in RFC3344 to communicate. In order to act as HAv4, the NAT-PT in MIPv4/v6-TG must maintain two address mappings of HAAv6HAAv4# and HoAv6HoAv4#, and MIP-ALG must maintain the binding of the home address and the care-of address in IPv4 format: HoAv4# CoAv4. In order to act as CNv4 when receiving data packets, the NAT-PT in MIPv4/v6-TG must maintain the address mapping of CNAv4#CNAv6.

Fig. 12 is a communication flowchart when both the HA and the CN are located in the IPv6 network and the MN moves in the IPv4 network. The specific communication steps include:

(1) According to the MIPv4 technology described in RFC3344, MNv4 sends a data packet in IPv4 format to CNv6, its source address is HoAv4#, and its destination address is CNAv4#. According to the destination address, such data packets are sent to MIPv4/v6-TG.

(2) The NAT-PT in the MIP-ALG performs address protocol conversion on the data message, the source address of the converted data message is HoAv6, and the destination address is CNAv6. According to the MIPv6 technology described in RFC3775, MIP-ALG in MIPv4/v6-TG extracts CoAv6 ^* from the address binding HoAv6CoAv6 ^* maintained by itself, and replaces the destination address of the data packet after NAT-PT conversion with HoAv6 It is CoAv6 ^* , and fill HoAv6 in the home address option of the data packet. According to the destination address, such data packets are sent to CNv6.

(3) According to the MIPv6 technology described in RFC3775, CNv6 sends a data message in IPv6 format to MNv4, its source address is CNAv6, and its destination address is CoAv6 ^* , and inserts a second-type routing header in the data message, which includes HoAv6. According to the destination address, such data packets are sent to MIPv4/v6-TG.

(4) According to the MIPv6 technology described in RFC3775, the MIP-ALG in MIPv4/v6-TG takes out HoAv6 from the second-type routing header of the received data message, and replaces the destination address with HoAv6 from CoAv6 ^* . The NAT-PT in MIPv4/v6-TG performs address protocol conversion on the data message processed by MIP-ALG, and the source address of the converted data message is CNAv4#, and the destination address is HoAv4#. Such data packets are sent to MNv4 through the tunnel, the source address of the tunnel is HAAv4#, and the destination address is CoAv4.

Figure 13 is an update flowchart when both HA and CN are located in the IPv6 network and the MN moves in the IPv4 network. When the MN moves in the IPv4 network and obtains a new care-of address, the MN needs to initiate an update process. During the update process, MIPv4/v6-TG acts as HAv4 on the side of the IPv4 network, and MNv4 performs the binding update of the home address and the care-of address according to the MIPv4 technology described in RFC3344, that is, updates the home address maintained in the MIP-ALG Binding to the care-of address. Then, MIPv4/v6-TG acts as MNv6 on the side of the IPv6 network, and performs binding update of the home address and the care-of address with HAv6 and CNv6 according to the MIPv6 technology described in RFC37755. The specific update steps include:

(1) According to the MIPv4 technology described in RFC3344, MNv4 generates a registration request message. The source address of the registration request message is CoAv4, the destination address is HAAv4#, and the payload includes HoAv4#. According to the destination address, the registration request message is sent to MIPv4/v6-TG.

(2) MIPv4/v6-TG converts the received registration request message into a binding update message. The source address of the binding update message is CoAv6 ^* , the destination address is HAAv6, and the payload includes HoAv6. According to the destination address, the binding update message is sent to HAv6.

(3) After receiving the binding update message, HAv6 first updates the binding between the home address and the care-of address maintained by itself, and then replies a binding confirmation message to MIPv4/v6-TG.

(4) According to RFC3775, before MNv6 initiates a binding update to CNv6, RRP authentication must be performed. At this time, MIPv4/v6-TG will act as MNv6 to initiate RRP authentication to CNv6. RRP authentication is performed according to the process described in RFC37755. The specific steps of RRP are as follows: MIPv4/v6-TG first sends the Home Test Init message and Care-of Test to CNv6 at the same time. Init message, where the Home Test Init message needs to go through HAv6, and the Care-of Test Init message is sent directly to CNv6; CNv6 replies Home Test message and Care-of Test message respectively after receiving the HomeTest Init message and Care-of Test Init message, and the Home Test messages and Care-of Test messages are returned in the same way.

(5) After the RRP authentication is completed, MIPv4/v6-TG sends a binding update message to CNv6.

(6) After CNv6 receives the binding update message, it first updates the binding between the home address and the care-of address maintained by itself, and then replies a binding confirmation message to MIPv4/v6-TG.

(7) MIPv4/v6-TG updates the binding between the home address and the care-of address maintained by the MIP-ALG after receiving the binding confirmation message. Then, according to the MIPv4 technology described in RFC3344, MIPv4/v6-TG generates a registration response message. The source address of the registration response message is HAAv4#, the destination address is CoAv4, and the payload includes HoAv4#. According to the destination address, the registration response message is sent to MNv4.

Fig. 14 is an update flowchart when both the HA and the CN are located in the IPv6 network and the MN moves from the IPv6 network to the IPv4 network.

As shown in Figure 14, there are two main tasks in the update process at this time. Firstly, the binding update between the home address and the care-of address maintained by HAv6 and CNv6 should be realized; secondly, the MIPv4/v6-TG should be discovered and MIPv4/v6-TG performs address configuration. In this update process, on the IPv4 network side, MIPv4/v6-TG acts as HAv4, and on the IPv6 network side, MIPv4/v6-TG acts as MNv6. The specific update steps include:

(1) The MNv4 discovers the MIPv4/v6-TG through domain name query, and obtains the address HAAv4# of the IPv4 format of the HAv6. During this process, NAT-PT in MIPv4/v6-TG establishes address mapping: HAAv6HAAv4#.

(2) MNv4 discovers MIPv4/v6-TG through domain name query, and obtains the address CNAv4# of CNv6 in IPv4 format. During this process, NAT-PT in MIPv4/v6-TG establishes address mapping: CNAv4#CNAv6.

(3) According to the MIPv4 technology described in RFC3344, MNv4 generates a registration request message. The source address of the registration request message is CoAv4, and the destination address is HAAv4#. Since MNv4 does not know HoAv4#, the home address field of the registration request message is set to zero, and HoAv6 is placed in the extended field. In addition, in order to enable MIPv4/v6-TG to act as MNv6 on the side of the IPv6 network, and update the home address and care-of address maintained by CNv6 with HAv6 and CNv6 according to the MIPv6 technology described in RFC3775, CNAv4# is also placed in the extension field middle. The extended registration request message is shown in Figure 15A. According to the destination address, the registration request message is sent to MIPv4/v6-TG.

(4) MIPv4/v6-TG obtains HoAv6 from the registration request message received, obtains CNAv6 and HAAv6 by looking up the address mapping table, and obtains CoAv6 ^* by adding a 96-bit NAT-PT gateway prefix before CoAv4. Then, according to the MIPv6 technology described in RFC3775, MIPv4/v6-TG generates a binding update message, the source address of the binding update message is CoAv6 ^* , the destination address is HAAv6, and the payload includes HoAv6. According to the destination address, the binding update message is sent to HAv6.

(5) After receiving the binding update message, HAv6 updates the binding between the home address and the care-of address maintained by itself, and returns a binding confirmation message to MIPv4/v6-TG.

(6) According to RFC3775, before MNv6 initiates a binding update to CNv6, RRP authentication must be performed. At this time, MIPv4/v6-TG will act as MNv6 to initiate RRP authentication to CNv6. RRP authentication is performed according to the process described in RFC37755. The specific steps of RRP are as follows: MIPv4/v6-TG first sends the Home Test Init message and Care-of Test to CNv6 at the same time. Init message, where the Home Test Init message needs to go through HAv6, and the Care-of Test Init message is sent directly to CNv6; CNv6 replies Home Test message and Care-of Test message respectively after receiving the HomeTest Init message and Care-of Test Init message, and the Home Test messages and Care-of Test messages are returned in the same way.

(7) After RRP authentication ends, MIPv4/v6-TG sends a binding update message to CNv6.

(8) After CNv6 receives the binding update message, it first updates the binding between the home address and the care-of address maintained by itself, and then replies a binding confirmation message to MIPv4/v6-TG.

(9) After MIPv4/v6-TG receives the binding confirmation message, NAT-PT in MIPv4/v6-TG establishes address mapping: HoAv6HoAv4#, and MIP-ALG establishes address binding: HoAv4#CoAv4 and HoAv6 CoAv6 ^* . Then the MIPv4/v6-TG replies the Registration Reply message to the MNv4. MIPv4/v6-TG provides HoAv4# to MNv4 in the registration response message. At this time, the format of the registration response message is shown in FIG. 15B .

Fig. 16 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv6 network and the MN moves from the IPv4 network to the IPv6 network.

When the MN moves from the IPv4 network to the IPv6 network, the MN, HA and CN are all in the IPv6 network. This is a typical MIPv6 problem. Communication and updates will be performed according to the MIPv6 technology described in RFC3775. The specific implementation process is shown in Figure 3.

Figure 17 is a schematic diagram of the layout where both the HA and the CN are located in the IPv4 network, and the MN moves in the IPv4/v6 hybrid network.

As shown in Figure 17, both the HA and the CN are located in the IPv4 network, and the MN moves in the IPv4/v6 hybrid network. The whole process can be divided into the communication between the MN and the CN when the MN moves in the IPv4 network, and the communication between the MN and the CN when the MN moves in the IPv6 network. Communication with CN when moving from IPv4 network to IPv6 network, communication with CN when MN moves from IPv6 network to IPv4 network. The communication in these situations will be described in detail below.

Fig. 18 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv4 network and the MN moves in the IPv4 network.

When the MN moves in the IPv4 network, the MN, HA and CN are all in the IPv4 network. This is a typical MIPv4 problem. It will communicate and update according to the MIPv4 technology described in RFC3344. The specific implementation process is shown in Figure 1.

Fig. 19 is a schematic diagram of address configuration of MIPv4/v6-TG when both the HA and the CN are located in the IPv4 network and the MN moves in the IPv6 network.

When the MN moves on the IPv6 network, MIPv4/v6-TG acts as MNv4 on the side of the IPv4 network, and constitutes three entities of the MIPv4 technology described in RFC3344 with CNv4 and HAv4, and communicates according to the MIPv4 technology described in RFC3344. In order to make MIPv4 /v6-TG acts as MNv4 on the side of the IPv4 network, and the NAT-PT in MIPv4/v6-TG must maintain the address mapping of CoAv4#CoAv6.

On the IPv6 network side, MIPv4/v6-TG acts as CNv6, and MNv6 constitutes two entities of the MIPv6 technology described in RFC3775, and communicates according to the MIPv6 technology described in RFC3775. In order to act as CNv6, the MIP-ALG in MIPv4/v6-TG must maintain the address binding of HoAv6*CoAv6.

Fig. 20 is a communication flowchart when both the HA and the CN are located in the IPv4 network and the MN moves in the IPv6 network. The specific communication steps include:

(1) According to the MIPv6 technology described in RFC3775, MNv6 sends a data message in IPv6 format to CNv4, its source address is CoAv6, and its destination address is CNAv6 ^* , and at the same time, it is included in the home address option of the destination option extension header of the data message Insert Home Address HoAv6 ^* . According to the destination address, such data packets are sent to MIPv4/v6-TG.

(2) The NAT-PT gateway on the MIPv4/v6-TG intercepts the data message according to the characteristic that the destination address of the data message is CNAv6 ^* and sends it to the MIP-ALG for processing. MIP-ALG extracts HoAv6 ^* from the home address option of the destination option extension header of the data message, and uses this HoAv6 ^* as the new source address of the data message, so that the movement of the mobile node remains transparent to the upper-layer services. Then, the MIP-ALG sends the data message to the NAT-PT gateway for processing, and the NAT-PT gateway performs address protocol conversion on the data message. The source address of the converted data message is HoAv4, and the destination address is CNAv4. According to the destination address, such data packets are directly sent to CNv4.

(3) According to the MIPv4 technology described in RFC3344, CNv4 sends a data message in IPv4 format to MNv6, its source address is CNAv4, and its destination address is HoAv4. According to the destination address, the data message is sent to MIPv4/v6-TG.

(4) Such data packets are intercepted when passing through HAv4, and then sent to MIPv4/v6-TG through a tunnel through HAv4. The source address of the tunnel is HAAv4, and the destination address is CoAv4#.

(5) The MIP-ALG in MIPv4/v6-TG first decapsulates the received data message, and then sends it to the NAT-PT gateway for address protocol conversion. The source address of the converted data message is CNAv6 ^* , and the purpose The address is HoAv6 ^* . According to RFC3775, in order to make the movement of the mobile node transparent to the upper-layer business, MIP-ALG in MIPv4/v6-TG extracts CoAv6 from the address binding HoAv6 ^* CoAv6 maintained by itself, and converts the data converted by NAT-PT The destination address of the message is replaced with CoAv6, and HoAv6 ^* is filled in the second type routing header of the data message. According to the destination address, such data packets are sent to MNv6.

Fig. 21 is an update flowchart when both the HA and the CN are located in the IPv4 network and the MN moves in the IPv6 network.

When MNv6 moves in the IPv6 network and obtains a new care-of address, in order to maintain normal communication, according to RFC3775, MNv6 needs to update the binding between the home address and the care-of address maintained by HAv6 and CNv6. Here, the update to HAv6 is actually an update to HAv4 in the IPv4 network, and the update to CNv6 is actually an update to the address binding maintained by MIP-ALG in MIPv4/v6-TG. The specific update steps include:

(1) According to RFC3775, MNv6 generates a binding update message, the source address of which is CoAv6, the destination address is HAAv6 ^* , and the payload includes MNv6's home address HoAv6 ^* . According to the destination address, the binding update message is sent to MIPv4/v6-TG.

(2) MIPv4/v6-TG converts the received binding update message into a registration request message, the source address of which is CoAv4#, the destination address is HAAv4, and the load includes HoAv4. According to the destination address, the registration request message is sent to HAv4.

(3) HAv4 updates the address binding according to the received registration request message: HoAv4CoAv4#, and generates a registration response message. The source address of the registration response message is HAAv4, the destination address is CoAv4#, and the payload includes HoAv4. According to the destination address, the registration reply message is sent to MIPv4/v6-TG.

(4) MIPv4/v6-TG converts the received registration response message into a binding confirmation message, the source address of which is HAAv6 ^* , the destination address is CoAv6, and the payload includes HoAv6 ^* . According to the destination address, the binding confirmation message is sent to MNv6. MNv6 receives the binding confirmation message, and completes the binding update between the home address and the care-of address maintained by HAv4.

(5) According to RFC3775, before MNv6 initiates a binding update to CNv6, RRP authentication must be performed. The specific steps of RRP are as follows: MNv6 generates a Home Test Init message, the source address of the Home Test Init message is HoAv6 ^* , and the destination address is CNAv6 ^* . The Home Test Init message is sent to MIPv4/v6-TG through the tunnel. At this time, MIPv4/v6-TG acts as HAv6, and the tunnel crossing addresses are CoAv6 and HAAv6 ^* respectively. MIPv4/v6-TG replies the Home Test message to MNv6 through the tunnel. The source address of the Home Test message is CNAv6 ^* , and the destination address is HoAv6 ^* . The MNv6 generates a Care of Test Init message, the source address of the Care of Test Init message is CoAv6, and the destination address is CNAv6 ^* . According to the destination address, the Care of Test Init message is sent to MIPv4/v6-TG, and MIPv4/v6-TG acts as CNv6 at this time. MIPv4/v6-TG replies the Care of Test message to MNv6. The source address of the Care of Test message is CNAv6 ^* , and the destination address is CoAv6.

(6) After the RRP authentication is completed, according to RFC3775, MNv6 generates and sends a binding update message. The source address of the binding update message is CoAv6, the destination address is CNAv6 ^* , and the payload includes HoAv6 ^* . According to the destination address, the binding update message Sent to MIPv4/v6-TG.

(7) When the binding update message is intercepted when passing through the MIPv4/v6-TG, the MIPv4/v6-TG updates the address binding HoAv6*CoAv6 maintained by the MIP-ALG. Then, MIPv4/v6-TG will reply a binding confirmation message to MNv6.

Fig. 22 is an update flowchart when both the HA and the CN are located in the IPv4 network and the MN moves from the IPv4 network to the IPv6 network.

As shown in Figure 22, the update process at this time mainly has two tasks. One is to realize the binding update between the home address and the care-of address maintained by HAv4; the other is to discover MIPv4/v6-TG through domain name query and update the MIPv4/v6-TG performs address configuration. In this update process, on the IPv4 network side, MIPv4/v6-TG acts as MNv4, and on the IPv6 network side, MIPv4/v6-TG acts as HAv6 and CNv6 respectively. The specific update steps include:

(1) The MNv6 discovers the MIPv4/v6-TG through domain name query, and obtains the IPv6 address HAAv6 ^* of the HAv4.

(2) The MNv6 discovers the MIPv4/v6-TG through domain name query, and obtains the address CNAv6 ^* of the CNv4 in IPv6 format.

(3) MNv6 sends a binding update message, the source address is CoAv6, the destination address is HAAv6 ^* , and the load includes HoAv6 ^* , and HoAv6 ^* is composed of HoAv4 and the 96-bit NAT-PT address prefix taken from HAAv6 ^* . According to the destination address, the binding update message is sent to MIPv4/v6-TG.

(4) MIPv4/v6-TG will establish address mapping in the NAT-PT gateway after receiving the binding update message: CoAv4#CoAv6. At the same time, the received binding update message is converted into a registration request message. The source address of the registration request message is CoAv4#, the destination address is HAAv4, and the payload includes HoAv4. According to the destination address, the registration request message is sent to HAv4.

(5) After receiving the registration request message, HAv4 will update the address binding between the home address and the care-of address it maintains, and reply a registration response message to MIPv4/v6-TG.

(6) MIPv4/v6-TG converts the received registration response message into a binding confirmation message and replies to MNv6.

(7) According to RFC3775, before the MNv6 initiates a binding update to the CNv6, RRP authentication must be performed. The specific steps of RRP are as follows: MNv6 generates a Home Test Init message, the source address of the Home Test Init message is HoAv6 ^* , and the destination address is CNAv6 ^* . The Home Test Init message is sent to MIPv4/v6-TG through the tunnel. At this time, MIPv4/v6-TG acts as HAv6, and the tunnel crossing addresses are CoAv6 and HAAv6 ^* respectively. MIPv4/v6-TG replies the Home Test message to MNv6 through the tunnel. The source address of the Home Test message is CNAv6 ^* , and the destination address is HoAv6 ^* . The MNv6 generates a Care of Test Init message, the source address of the Care of Test Init message is CoAv6, and the destination address is CNAv6 ^* . According to the destination address, the Care of Test Init message is sent to MIPv4/v6-TG, and MIPv4/v6-TG acts as CNv6 at this time. MIPv4/v6-TG replies the Care of Test message to MNv6. The source address of the Care of Test message is CNAv6 ^* , and the destination address is CoAv6.

(8) After the RRP authentication is completed, according to RFC3775, MNv6 generates and sends a binding update message. The source address of the binding update message is CoAv6, the destination address is CNAv6 ^* , and the payload includes HoAv6 ^* . According to the destination address, the binding update message Sent to MIPv4/v6-TG.

(9) When the binding update message is intercepted through MIPv4/v6-TG, MIP-ALG establishes address binding HoAv6*CoAv6. Then, MIPv4/v6-TG will reply a binding confirmation message to MNv6.

Fig. 23 is a schematic diagram of a mobile IPv4/v6 solution when both the HA and the CN are located in the IPv4 network and the MN moves from the IPv6 network to the IPv4 network.

When the MN moves from the IPv6 network to the IPv4 network, the MN, HA, and CN are all in the IPv4 network. This is a typical MIPv4 problem. It will communicate and update according to the MIPv4 technology described in RFC3344. The specific implementation process is shown in Figure 1 .

Fig. 24 is a schematic diagram of the layout where the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4/v6 hybrid network.

As shown in Figure 24, the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4/v6 hybrid network. The whole process can be divided into the communication between the MN and the CN when the MN moves in the IPv6 network, and the communication between the MN and the CN when moving in the IPv4 network. , the communication between the MN and the CN when the MN moves from the IPv6 network to the IPv4 network, and the communication between the MN and the CN when the MN moves from the IPv4 network to the IPv6 network. The communication in these situations will be described in detail below.

Fig. 25 is a schematic diagram of address configuration of MIPv4/v6-TG when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv6 network.

When the MN moves in the IPv6 network, MIPv4/v6-TG acts as CNv6 on the side of the IPv6 network, and MNv6 constitutes two entities of the MIPv6 technology described in RFC3775, and communicates according to the MIPv6 technology described in RFC3775. In order to make MIPv4/v6 -TG can convert home address and care-of address when sending data packets to MNv6 on the side of IPv6 network. MIP-ALG in MIPv4/v6-TG must maintain the binding of home address and care-of address in IPv6 format: HoAv6 CoAv6.

On the IPv4 network side, MIPv4/v6-TG acts as MNv4 when sending data packets, and acts as HAv4 when receiving data packets, and CNv4 constitutes three entities of the MIPv4 technology described in RFC3344, according to the MIPv4 technology described in RFC3344 to communicate. In order to act as MNv4, the NAT-PT in MIPv4/v6-TG must maintain the address mapping of HoAv6HoAv4#.

Fig. 26 is a communication flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv6 network. The specific communication steps include:

(1) According to the MIPv6 technology described in RFC3775, MNv6 sends a data message in IPv6 format to CNv4, its source address is CoAv6, and its destination address is CNAv6 ^* , and at the same time insert the home address HoAv6 in the home address option of the destination option extension header . According to the destination address, such data packets are sent to MIPv4/v6-TG.

(2) According to RFC3775, MIP-ALG in MIPv4/v6-TG takes out HoAv6 from the home address option of the received data message, and replaces the source address of the data message from CoAv6 to HoAv6. Then, the NAT-PT gateway in the MIPv4/v6-TG performs address protocol conversion on the data message, and the source address of the converted data message is HoAv4#, and the destination address is CNAv4. According to the destination address, such data packets are directly sent to CNv4.

(3) According to the MIPv4 technology described in RFC3344, CNv4 sends a data packet in IPv4 format to MNv6, the source address of which is CNAv4, and the destination address is HoAv4#. According to the destination address, such data packets are sent to MIPv4/v6-TG.

(4) The NAT-PT in MIPv4/v6-TG performs address protocol conversion on the received data message, and the source address of the converted data message is CNAv6 ^* , and the destination address is HoAv6. According to RFC3775, MIP-ALG in MIPv4/v6-TG extracts CoAv6 from the address binding HoAv6CoAv6 maintained by itself, replaces the destination address of the data packet after NAT-PT conversion from HoAv6 to CoAv6, and A second-type routing header is inserted into the message, which contains HoAv6. According to the destination address, such data packets are sent to MNv6.

Fig. 27 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv6 network.

When MNv6 moves in the IPv6 network and obtains a new care-of address, in order to maintain normal communication, according to RFC3775, MNv6 needs to update the binding between the home address and the care-of address maintained by HAv6 and CNv6. During the update process, MIPv4/v6-TG acts as CNv6 on the side of the IPv6 network, and constitutes three entities during MIPv6 update with HAv6 and MNv6. According to RFC3775, the binding between the home address and the care-of address maintained by HAv6 and CNv6 is updated. Wherein, updating the binding between the home address and the care-of address maintained by CNv6 is to update the binding between the home address and the care-of address maintained by the MIP-ALG. The specific update steps include:

(1) According to RFC3775, MNv6 generates a binding update message, the source address of which is CoAv6, the destination address is HAAv6, and the payload includes MNv6's home address HoAv6. According to the destination address, the binding update message is sent to HAv6.

(2) After receiving the binding update message, HAv6 updates the binding between the home address and the care-of address maintained by itself, and then replies a binding confirmation message to MNv6. The source address of the binding confirmation message is HAAv6, and the destination address is CoAv6.

(3) According to RFC3775, before the MNv6 initiates a binding update to the CNv6, RRP authentication must be performed. During this process, MIPv4/v6-TG will act as CNv6. RRP authentication is carried out according to the process described in RFC37755. The specific steps are as follows: MNv6 first sends a HomeTest Init message and a Care-of Test Init message to MIPv4/v6-TG at the same time, and the Home Test Init message needs to go through HAv6, Care-of Test Init The message is directly sent to MIPv4/v6-TG; MIPv4/v6-TG replies Home Test message and Care-of Test message respectively after receiving Home TestInit message and Care-of Test Init message, and Home Test message and Care-of Test message follow the Backtrack.

(4) After the RRP authentication is completed, according to RFC3775, MNv6 generates and sends a binding update message. The source address of the binding update message is CoAv6, the destination address is CNAv6 ^* , and the payload includes HoAv6. According to the destination address, the binding update message is sent to To MIPv4/v6-TG.

(5) When the binding update message is intercepted when passing through the MIPv4/v6-TG, the MIPv4/v6-TG updates the address binding HoAv6CoAv6 maintained by the MIP-ALG. Then, MIPv4/v6-TG will reply a binding confirmation message to MNv6.

Fig. 28 is a schematic diagram of address configuration of MIPv4/v6-TG when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4 network.

When the MN moves on the IPv4 network, MIPv4/v6-TG acts as HAv4 on the side of the IPv4 network, and constitutes three entities of the MIPv4 technology described in RFC3344 with CNv4 and MNv4, and communicates according to the MIPv4 technology described in RFC3344. In order to make MIPv4 /v6-TG acts as HAv4 on the IPv4 network side, and the NAT-PT in MIPv4/v6-TG must maintain the address mapping of HAAv6HAAv4#; MIP-ALG must maintain the address binding of HoAv4#CoAv4.

According to RFC3344, in order to make the movement of MNv4 transparent to CNv4, MNv4 sends data packets with the home address in IPv4 format. Therefore, the NAT-PT in MIPv4/v6-TG must maintain the address mapping of HoAv6HoAv4#.

Fig. 29 is a communication flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4 network. The specific communication steps include:

(1) According to the MIPv4 technology described in RFC3344, MNv4 sends a data packet in IPv4 format to CNv4, its source address is HoAv4#, and its destination address is CNAv4. According to the destination address, such data packets are sent to CNv4.

(2) According to the MIPv4 technology described in RFC3344, CNv4 sends a data message in IPv4 format to MNv4, the source address of which is CNAv4, and the destination address is HoAv4#. According to the destination address, such data packets are sent to MIPv4/v6-TG.

(3) According to RFC3344, MIPv4/v6-TG forwards the received data message to MNv4 through the tunnel, the source address of the tunnel is HAAv4#, and the destination address is CoAv4.

Fig. 30 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves in the IPv4 network.

When the MN moves in the IPv4 network and obtains a new care-of address, in order to maintain normal communication, according to RFC3344, the MN needs to update the binding between the home address and the care-of address maintained by HAv4. During this update process, MIPv4/v6-TG acts as HAv4 on the side of the IPv4 network, and constitutes two entities during MIPv4 update with MNv4. According to the MIPv4 technology described in RFC3344, the hometown maintained by MIP-ALG in MIPv4/v6-TG The binding between the address and the care-of address is updated; MIPv4/v6-TG acts as MNv6 on the side of the IPv6 network, and constitutes two entities during MIPv6 update with HAv6. According to the MIPv6 technology described in RFC3775, the home address and care-of address maintained by HAv6 The bindings are updated. The specific update steps include:

(1) MNv4 generates a registration request message, the source address is CoAv4, the destination address is HAAv4#, and the payload includes HoAv4#. According to the destination address, the registration request message is sent to MIPv4/v6-TG.

(2) MIPv4/v6-TG converts the received registration request message into a binding update message. The source address of the binding update message is CoAv6 ^* , the destination address is HAAv6, and the payload includes HoAv6. According to the destination address, the binding update message is sent to HAv6.

(3) After receiving the binding update message, HAv6 updates the binding between the home address and the care-of address and generates a binding confirmation message to reply to MIPv4/v6-TG.

(4) After receiving the binding confirmation message, MIPv4/v6-TG updates the address binding HoAv4#CoAv4 maintained by MIP-ALG, and generates a registration response message to reply to MNv4.

Fig. 31 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves from the IPv6 network to the IPv4 network.

As shown in Figure 31, there are two main tasks in the update process at this time. One is to update the binding between the home address and the care-of address maintained by HAv6; /v6-TG for address configuration. In this update process, on the IPv4 network side, MIPv4/v6-TG acts as HAv4, and on the IPv6 network side, MIPv4/v6-TG acts as MNv6. The specific update steps include:

(1) The MNv6 discovers the MIPv4/v6-TG through domain name query, and obtains the address HAAv4# of the IPv4 format of the HAv6. During the domain name query process, the NAT-PT in MIPv4/v6-TG establishes address mapping: HAAv6HAAv4#.

(2) MNv6 discovers MIPv4/v6-TG through domain name query, and obtains the address CNAv4 of CNv4 in IPv4 format.

(3) MNv4 generates a registration request message, the source address is CoAv4, and the destination address is HAAv4#. But, because MNv4 does not know HoAv4# yet, but only knows HoAv6, therefore, MNv4 sets the home address field in the registration request message to zero, and fills HoAv6 in the extended field. At this time, the format of the extended registration request message is shown in FIG. 32A. According to the destination address, the registration request message is sent to MIPv4/v6-TG.

(4) MIPv4/v6-TG converts the received registration request message into a binding update message. The source address of the binding update message is CoAv6 ^* , the destination address is HAAv6, and the payload includes HoAv6. According to the destination address, the binding update message is sent to HAv6.

(5) After receiving the binding update message, HAv6 updates the binding between the home address and the care-of address and generates a binding confirmation message to reply to MIPv4/v6-TG.

(6) After receiving the binding confirmation message, MIPv4/v6-TG establishes address mapping in NAT-PT: HoAv6HoAv4#, establishes address binding in MIP-ALG: HoAv4#CoAv4, and generates a registration response message Reply to MNv4. The Registration Reply message includes HoAv4#. At this time, the format of the registration response message is shown in FIG. 32B.

Fig. 33 is an update flowchart when the HA is located in the IPv6 network, the CN is located in the IPv4 network, and the MN moves from the IPv4 network to the IPv6 network.

As shown in Figure 33, the update process at this time mainly has two tasks. One is to realize the binding update between the home address and the care-of address maintained by HAv6; the other is to discover MIPv4/v6-TG through domain name query and update MIPv4/v6-TG performs address configuration. The specific update steps include:

(1) The MNv6 obtains the address HAAv6 of the IPv6 format of the HAv6 through domain name query.

(2) The MNv6 discovers the MIPv4/v6-TG through domain name query, and obtains the address CNAv6 ^* of the CNv4 in IPv6 format.

(3) According to RFC3775, MNv6 generates a binding update message, the source address of which is CoAv6, the destination address is HAAv6, and the payload includes MNv6's home address HoAv6. According to the destination address, the binding update message is sent to HAv6.

(4) After receiving the binding update message, HAv6 updates the binding between the home address and the care-of address maintained by itself, and then replies a binding confirmation message to MNv6. The source address of the binding confirmation message is HAAv6, and the destination address is CoAv6. The payload includes the home address HoAv6 of MNv6.

(5) According to RFC3775, before MNv6 initiates a binding update to CNv6, RRP authentication must be performed. During this process, MIPv4/v6-TG will act as CNv6. RRP authentication is carried out according to the process described in RFC37755. The specific steps are as follows: MNv6 first sends a HomeTest Init message and a Care-of Test Init message to MIPv4/v6-TG at the same time, and the Home Test Init message needs to go through HAv6, Care-of Test Init The message is directly sent to MIPv4/v6-TG; MIPv4/v6-TG replies Home Test message and Care-of Test message respectively after receiving Home TestInit message and Care-of Test Init message, and Home Test message and Care-of Test message follow the Backtrack.

(6) After the RRP authentication is completed, according to RFC3775, MNv6 generates and sends a binding update message. The source address of the binding update message is CoAv6, the destination address is CNAv6 ^* , and the payload includes HoAv6. According to the destination address, the binding update message is sent to To MIPv4/v6-TG.

(7) After receiving the binding update message, MIPv4/v6-TG establishes address mapping in NAT-PT: HoAv6HoAv4#, and establishes binding between home address and care-of address in MIP-ALG: HoAv6CoAv6. Then, MIPv4/v6-TG generates a binding confirmation message and replies to MNv6.

Fig. 34 is a schematic diagram of the layout where the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4/v6 hybrid network.

As shown in Figure 34, the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4/v6 mixed network. The whole process can be divided into the communication between the MN and the CN when the MN moves in the IPv4 network, and the communication between the MN and the CN when moving in the IPv6 network. , the communication between the MN and the CN when the MN moves from the IPv4 network to the IPv6 network, and the communication between the MN and the CN when the MN moves from the IPv6 network to the IPv4 network. The communication in these situations will be described in detail below.

Fig. 35 is a schematic diagram of address configuration of MIPv4/v6-TG when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4 network.

When the MN moves on the IPv4 network, MIPv4/v6-TG acts as CNv4 on the side of the IPv4 network, and constitutes three entities of the MIPv4 technology described in RFC3344 with HAv4 and MNv4, and communicates according to the MIPv4 technology described in RFC3344; MIPv4/v6 - TG acts as MNv6 on the IPv6 network side, and CNv6 constitutes two entities of the MIPv6 technology described in RFC3775, and communicates according to the MIPv6 technology described in RFC3775.

In order to make MIPv4/v6-TG act as CNv4 on the IPv4 network side, the NAT-PT in MIPv4/v6-TG must maintain the address mapping of CNAv4#CNAv6. In order to make MIPv4/v6-TG act as MNv6 on the IPv6 network side, the MIP-ALG in MIPv4/v6-TG must maintain the address binding of HoAv6 ^* CoAv6 ^* .

Fig. 36 is a communication flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4 network. The specific communication steps include:

(1) According to the MIPv4 technology described in RFC3344, MNv4 sends a data packet in IPv4 format to CNv6, the source address is HoAv4, and the destination address is CNAv4#. According to the destination address, such data packets are sent to MIPv4/v6-TG.

(2) NAT-PT in MIPv4/v6-TG converts the data message in IPv4 format sent by MNv4 into a data message in IPv6 format. The source address of the converted data message is HoAv6 ^* , and the destination address is CNAv6. According to RFC3775, in order to make the movement of the mobile node transparent to the upper-layer business, the MIP-ALG in MIPv4/v6-TG extracts CoAv6 ^* from the address binding HoAv6 ^*  CoAv6 ^* maintained by itself, and converts it through NAT-PT The source address of the data message is replaced by CoAv6 ^* , and HoAv6 ^* is filled in the home address option of the destination option extension header of the data message. According to the destination address, such data packets are sent to CNv6.

(3) According to the MIPv6 technology described in RFC3775, CNv6 sends a data message in IPv6 format to MNv4, the source address is CNAv6, the destination address is CoAv6 ^* , and HoAv6 ^* is stored in the second type of routing header in the data message. According to the destination address, such data packets are sent to MIPv4/v6-TG.

(4) The MIP-ALG in MIPv4/v6-TG takes out the home address HoAv6 ^* from the second-type routing header of the received data packet in IPv6 format according to RFC3775, and replaces CoAv6 ^* as the destination address. The NAT-PT in MIPv4/v6-TG converts the converted data message into a data message in IPv4 format, the source address is CNAv4#, and the destination address is HoAv4. According to the destination address, such data packets are sent to HAv4.

(5) According to RFC3344, HAv4 forwards the received data message to MNv4 through the tunnel. The source address of the tunnel is HAAv4, and the destination address is CoAv4.

Fig. 37 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv4 network.

According to RFC3344, after the MN moves in the IPv4 network, it will obtain a new care-of address, and the MNv4 needs to update the binding between the home address and the care-of address maintained by HAv4. In addition, although both CNv6 and MIP-ALG maintain the binding of the home address and the care-of address in IPv6 format: HoAv6 ^* CoAv6 ^* , however, CoAv6 ^* is composed of the 96-bit IPv6 address prefix of CoAv4 and NAT-PT. During the process, data packets are routed to MIPv4/v6-TG according to the 96-bit IPv6 address prefix of NAT-PT in CoAv6 ^* . CoAv4 does not play any role in essence. Therefore, there is no need to bind the addresses maintained by CNv6 and MIP-ALG. will be updated. The specific update steps include:

(1) MNv4 generates and sends a registration request message to HAv4, the source address of which is CoAv4, the destination address is HAAv4, and the load includes HoAv4.

(2) After receiving the registration request message, HAv4 updates the binding between the home address and the care-of address maintained by itself, and then replies a registration response message to MNv4.

Fig. 38 is a schematic diagram of address configuration of MIPv4/v6-TG when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv6 network.

According to RFC3775, direct communication between MNv6 and CNv6. However, HAv4 must maintain the binding HoAv4CoAv4# of the home address in IPv4 format and the care-of address in order to know the specific location of MNv6. Therefore, the NAT-PT in MIPv4/v6-TG needs to maintain the address mapping of CoAv4#CoAv6 .

Fig. 39 is a communication flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv6 network. The specific communication steps include:

(1) According to the MIPv6 technology described in RFC3775, MNv6 sends a data message in IPv6 format to CNv6, the source address of the data message is CoAv6, the destination address is CNAv6, and the home address option in the destination option extension header of the data message Store HoAv6 ^* in it.

(2) According to the MIPv6 technology described in RFC3775, CNv6 sends a data message in IPv6 format to MNv6, the source address of the data message is CNAv6, the destination address is CoAv6, and HoAv6 ^* is stored in the second type routing header of the data message.

Fig. 40 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves in the IPv6 network.

When the MN moves in the IPv6 network and obtains a new care-of address, in order to maintain normal communication, it is necessary to update the binding between the home address and the care-of address maintained by HAv4 and CNv6. When updating, MIPv4/v6-TG acts as HAv6 on the side of the IPv6 network, updates the home address and care-of address with MNv6 and CNv6 according to RFC3775, and acts as MNv4 on the side of the IPv4 network, and performs home address and care-of address update with HAv4 according to RFC3344. Updates to the care-of address. The specific update steps are as follows:

(1) MNv6 generates a binding update message. The source address of the binding update message is CoAv6, the destination address is HAAv6 ^* , and the payload includes HoAv6 ^* . According to the destination address, the binding update message is sent to MIPv4/v6-TG.

(2) The MIP-ALG in MIPv4/v6-TG converts the received binding update message into a registration request message. The source address of the registration request message is CoAv4#, the destination address is HAAv4, and the payload includes HoAv4. According to the destination address, the registration request message is sent to HAv4.

(3) HAv4 updates the binding between the home address and the care-of address according to the received registration request message, and generates a registration response message. The source address of the registration response message is HAAv4, the destination address is CoAv4#, and the payload includes HoAv4. According to the destination address, the registration reply message is sent to MIPv4/v6-TG.

(4) After MIPv4/v6-TG receives the registration response message, NAT-PT updates the address mapping: CoAv4#CoAv6, and MIP-ALG converts the registration response message into a binding confirmation message. The source address of the binding confirmation message is HAAv6 ^* , the destination address is CoAv6, and the payload includes HoAv6 ^* . According to the destination address, the binding confirmation message is sent to MNv6. MNv6 receives the binding confirmation message, and completes the binding update of the home address and care-of address maintained by HAv4.

(5) According to RFC3775, before MNv6 initiates a binding update to CNv6, RRP authentication must be performed. During this process, MIPv4/v6-TG will act as HAv6. RRP authentication is carried out according to the process described in RFC37755, and the specific steps are as follows: MNv6 first sends a HomeTest Init message and a Care-of Test Init message to MIPv4/v6-TG at the same time, and the Home Test Init message needs to pass through MIPv4/v6-TG and then Forward to CNv6, the Care-of Test Init message is sent directly to CNv6; CNv6 replies Home Test message and Care-of Test message, Home Test message and Care-of Test message respectively after receiving Home Test Init message and Care-of Test Init message The message is returned in the same way.

(6) After the RRP authentication is completed, according to RFC3775, MNv6 generates and sends a binding update message. The source address of the binding update message is CoAv6, the destination address is CNAv6, and the payload includes HoAv6 ^* . According to the destination address, the binding update message is sent to To CNv6.

(7) After CNv6 receives the binding update message, it updates the binding between the home address and the care-of address: HoAv6 ^* CoAv6. Then, CNv6 generates a binding confirmation message and replies to MNv6.

Fig. 41 is an update flowchart when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves from the IPv4 network to the IPv6 network.

As shown in Figure 41, there are two main tasks in the update process at this time. One is to realize the binding update between the home address and the care-of address maintained by HAv4 and CNv6; the other is to discover MIPv4/v6-TG through domain name query. And perform address configuration on MIPv4/v6-TG. During this update process, on the IPv6 network side, MIPv4/v6-TG acts as HAv6, and constitutes three entities during MIPv6 update with CNv6 and MNv6. According to the MIPv6 technology described in RFC3775, the home address maintained by CNv6 and the care-of address The binding is updated; on the side of the IPv4 network, MIPv4/v6-TG acts as MNv4, and updates the home address and care-of address with HAv4 according to RFC3344. The specific update steps include:

(1) The MNv6 discovers the MIPv4/v6-TG through domain name query, and obtains the IPv6 address HAAv6 ^* of the HAv4.

(2) The MNv6 obtains the IPv6 address CNAv6 of the CNv6 through domain name query.

(3) MNv6 sends a binding update message, the source address is CoAv6, the destination address is HAAv6 ^* , the load includes HoAv6 ^* , and HoAv6 ^* is formed by adding the 96-bit IPv6 address prefix of NAT-PT to HoAv4. According to the destination address, the binding update message will be sent to MIPv4/v6-TG.

(4) After MIPv4/v6-TG receives the binding update message, NAT-PT establishes address mapping: CoAv4#CoAv6, then, MIP-ALG converts the binding update message into a registration request message, and its source address is CoAv4# , the destination address is HAAv4, and the payload includes HoAv4. According to the destination address, the registration request message is sent to HAAv4.

(5) After receiving the registration request message, HAv4 updates the binding between the home address and the care-of address, and generates a registration response message, whose source address is HAAv4, destination address is CoAv4#, and the payload includes HoAv4. According to the destination address, the registration reply message is sent to MIPv4/v6-TG.

(6) After MIPv4/v6-TG receives the registration request message, MIP-ALG converts the registration response message into a binding confirmation message. The source address of the binding confirmation message is HAAv6 ^* , the destination address is CoAv6, and the load is HoAv6 ^* . According to the destination address, the binding confirmation message is sent to MNv6. MNv6 receives the binding confirmation message, and completes updating of the binding between the home address and the care-of address maintained by HAv4.

(7) According to RFC3775, before the MNv6 initiates a binding update to the CNv6, RRP authentication must be performed. During this process, MIPv4/v6-TG will act as HAv6. RRP authentication is carried out according to the process described in RFC37755, and the specific steps are as follows: MNv6 first sends a HomeTest Init message and a Care-of Test Init message to MIPv4/v6-TG at the same time, and the Home Test Init message needs to pass through MIPv4/v6-TG and then Forward to CNv6, the Care-of Test Init message is sent directly to CNv6; CNv6 replies Home Test message and Care-of Test message, Home Test message and Care-of Test message respectively after receiving Home Test Init message and Care-of Test Init message The message is returned in the same way.

(8) After the RRP authentication is completed, according to RFC3775, MNv6 generates and sends a binding update message. The source address of the binding update message is CoAv6, the destination address is CNAv6, and the payload includes HoAv6 ^* . According to the destination address, the binding update message is sent to To CNv6.

(9) After receiving the binding update message, CNv6 updates the address binding maintained by itself: HoAv6*CoAv6. Then, CNv6 generates a binding confirmation message and replies to MNv6.

Fig. 42 is an update flowchart illustrating when the HA is located in the IPv4 network, the CN is located in the IPv6 network, and the MN moves from the IPv6 network to the IPv4 network.

As shown in Figure 42, the update process at this time mainly has two tasks. One is to realize the binding update between the home address and the care-of address maintained by HAv4 and CNv6; the other is to discover MIPv4/v6-TG through domain name query. And perform address configuration on MIPv4/v6-TG. During the update process, since the MN is in the IPv4 network at this time, according to RFC3344, the MN only needs to update the binding maintained by HAv4, but when the MN moves from the IPv6 network to the IPv4 network and obtains a new care-of address, CNv6 still maintains the original Some address bindings, therefore, the address bindings maintained by CNv6 need to be updated. But the problem is that according to RFC3344, the MN does not initiate an update to the CN. The solution proposed by the invention expands the functions of the MN, enabling the MN to request the MIPv4/v6-TG agent to initiate an update to CNv6 by itself. In order to achieve this purpose, two messages, proxy request and proxy response, are introduced. At the same time, in order to be compatible with RFC3344 as much as possible, the format of proxy request/proxy response message is consistent with that of registration request/registration response message. In addition, in order to distinguish messages, type values are defined for proxy request messages and proxy reply messages. The specific update steps include:

(1) MNv4 generates and sends a registration request message to HAv4, the source address of which is CoAv4, the destination address is HAAv4, and the load includes HoAv4. According to the destination address, the registration request message is sent to HAv4.

(2) After receiving the registration request message, HAv4 updates the binding between the home address and the care-of address maintained by itself, and then replies a registration response message to MNv4.

(3) MNv6 discovers MIPv4/v6-TG through domain name query, and obtains the address CNAv4# of CNv6 in IPv4 format. In the process of domain name query, NAT-PT in MIPv4/v6-TG establishes address mapping: CNAv4#CNAv6.

(4) MNv4 sends a proxy request message to MIPv4/v6-TG, the source address of the proxy request message is CoAv4, the destination address is CNAv4#, and the payload includes HoAv4. According to the destination address, the proxy request message is sent to MIPv4/v6-TG. In the present invention, the type value of the proxy request message is defined as 7, and the format of the proxy request message is shown in FIG. 43A.

(5) MIPv4/v6-TG will proxy MNv4 to initiate an update process to CNv6 after receiving the proxy request message. According to RFC3775, before initiating an update to CNv6, RRP authentication is required. RRP authentication is performed according to the process described in RFC37755, and the specific steps are as follows: MIPv4/v6-TG acts as HAv6 on the IPv6 network side, and sends a Home Test Init message to CNv6. The source address of the Home Test Init message is HoAv6 ^* , and the destination address is CNAv6. After receiving the Home Test Init message, CNv6 will respond to the Home Test message to MIPv4/v6-TG. At the same time, MIPv4/v6-TG acts as MNv6 and sends a Care of Test Init message to CNv6. The source address of the Care of Test Init message is CoAv6 ^* , and the destination address is CNAv6. After receiving the Care of Test Init message, CNv6 will respond to the Care of Test message to MIPv4/v6-TG.

(6) After RRP authentication ends, MIPv4/v6-TG acts as MNv6 and generates a binding update message according to RFC3775. The source address of the binding update message is CoAv6 ^* , the destination address is CNAv6, and the payload includes HoAv6 ^* . According to the destination address, the Binding Update messages are sent to CNv6.

(7) After CNv6 receives the binding update message, it updates the address binding it maintains: HoAv6 ^*  CoAv6 ^* . Then, CNv6 generates a binding confirmation message and replies to MIPv4/v6-TG.

(8) After MIPv4/v6-TG receives the binding confirmation message, first, MIP-ALG establishes address binding: HoAv6 ^*  CoAv6 ^* . Then, MIPv4/v6-TG sends a proxy response message to MNv4. The source address of the proxy reply message is CNAv4#, the destination address is CoAv4, and the payload includes HoAv4. In the present invention, the type value of the proxy response message is defined as 8, and the format of the proxy response message is shown in FIG. 43B.

The present invention realizes the mobile communication in the IPv4/v6 hybrid network by setting the MIPv4/v6-TG between the IPv4 network and the IPv6 network, and also realizes the mutual transparency of RFC3334 and RFC3775, and can meet the needs of the network during the transition from IPv4 to IPv6 Requirements; and the present invention only needs to upgrade the mobile node to a certain extent, but does not need to improve the home agent and the communication node, so the present invention can make full use of the existing mobile communication equipment and has great practical value.

Claims (8)

1. realize the communication means of mobile node in the IPv4/v6 hybrid network for one kind, it is characterized in that: by the mobile communication in mobile IPv 4/v6 transfer gateway realization IPv4/v6 hybrid network is set between IPv4 network and IPv6 network, described mobile IPv 4/v6 transfer gateway comprises the NAT-PT gateway and establishes thereon mobile IP ALG, wherein disposes DNS-ALG on the NAT-PT gateway.

2. the communication means of mobile node according to claim 1 in the IPv4/v6 hybrid network is characterized in that:

A. mobile IPv 4/v6 transfer gateway is by serving as RFC3344 and the described different entity of RFC3775 respectively in IPv4 network and IPv6 network, and realizes that by the conversion of carrying out at intra-gateway between the entity RFC3344 and RFC3775's is transparent mutually;

B. mobile IPv 4/v6 transfer gateway is responsible for changing send to various message and data message the IPv6 network, relevant with mobile IP from the IPv4 network, is responsible for changing send to various message and data message the IPv4 network, relevant with mobile IP from the IPv6 network;

C. mobile IPv 4/v6 transfer gateway is intercepted and captured message and the data message relevant with mobile IP according to following principle: when upgrading, intercept and capture message according to the type of message; When communication, according to the destination address intercepted data message of data message;

D. mobile IPv 4/v6 transfer gateway security mechanism of when the message of process IP v4 form and data message, adopting RFC3344 to provide, the security mechanism that when the message of process IP v6 form and data message, adopts RFC3775 to provide;

E. in the described communication means of claim 1, the requirement of describing among the requirement of home agent and communication node and RFC3344 and the RFC3775 is consistent, but increases requirement mobile node.

3. the communication means of mobile node according to claim 2 in the IPv4/v6 hybrid network, it is characterized in that: described steps A specifically comprises:

(1) mobile IPv 4/v6 transfer gateway serves as a described entity of RFC3344 in IPv4 network one side, this entity constitutes the described mobile IP model of RFC3344 with other entity that is in the IPv4 network, and this moves IP model and communicates according to the mobile IPv 4 agreement described in the RFC3344 and upgrade;

(2) mobile IPv 4/v6 transfer gateway serves as a described entity of RFC3775 in IPv6 network one side, this entity constitutes the described mobile IP model of RFC3775 with other entity that is in the IPv6 network, and this moves IP model and communicates according to the mobile IPv 6 protocol described in the RFC3775 and upgrade;

(3) mobile IPv 4/v6 transfer gateway is realized the conversion of own entity from an IPv4 form to the entity of an IPv6 form by the internal conversion between the entity, from the conversion of the entity of an IPv6 form to the entity of an IPv4 form, and realize conversion between the similar entity, thereby realize that finally RFC3344 and RFC3775's is transparent mutually.

4. the communication means of mobile node according to claim 2 in the IPv4/v6 hybrid network, it is characterized in that: described step B specifically comprises:

(1) mobile IPv 4/v6 transfer gateway is responsible for the described login request message of a RFC3344 and is converted the described binding update messages of RFC3775 to, and the described registration reply message conversion of RFC3344 is become the described binding acknowledgement message of RFC3775;

(2) mobile IPv 4/v6 transfer gateway is responsible for the described binding update messages of a RFC3775 and is converted the described login request message of RFC3344 to, and the described binding acknowledgement message conversion of RFC3775 is become the described registration reply message of RFC3344;

(3) mobile IPv 4/v6 transfer gateway is responsible for the data message is carried out the address protocol conversion, and when IPv6 network one side transceive data message, according to the described requirement of RFC3775, Care-of Address in the data message IP head of IPv6 form and the home address in the extension header are exchanged.

5. the communication means of mobile node according to claim 2 in the IPv4/v6 hybrid network, it is characterized in that: described step C specifically comprises:

(1) when communication, mobile IPv 4/v6 transfer gateway serves as different entities according to different signal intelligences, owing to can be routed to mobile IPv 4/v6 transfer gateway as the data message of destination address with the IP address of these entities, therefore, will to intercept and capture the IP address with these entities be the data message of destination address to mobile IPv 4/v6 transfer gateway;

(2) when upgrading, mobile IPv 4/v6 transfer gateway is intercepted and captured message according to the type of message, and this method further specifically comprises:

(21) at the IPv4 network, the message that mobile IPv 4/the v6 transfer gateway need be handled has the described login request message of RFC3344 and registration reply message and Agent Solicitation that defines and proxy response message in the described communication means of claim 1, to these four kinds of message, mobile IPv 4/v6 transfer gateway is intercepted and captured according to the UDP encapsulation and the destination slogan of message in network layer, distinguishes according to the loadtype value of message in application layer;

(22) at the IPv6 network, the message that mobile IPv 4/the v6 transfer gateway need be handled has the described binding update messages of RFC3775, binding acknowledgement message, Home Test Init message, Home Test message, Careof Test Init message, Care of Test message; To these message, mobile IPv 4/v6 transfer gateway is numbered 135 in network layer according to the mobile prolate-headed next header of message and as a token of intercepts and captures message, application layer according to load in the MH value distinguish message.

6. the communication means of mobile node according to claim 2 in the IPv4/v6 hybrid network, it is characterized in that: described step D specifically comprises:

(1) when mobile IPv 4/v6 transfer gateway receives message or data message, will be IPv4 form or IPv6 form, authenticate according to RFC3344 or the described identifying algorithm of RFC3775 according to this message or data message;

(2) when mobile IPv 4/v6 transfer gateway sends message or data message, to be IPv4 form or IPv6 form according to this message or data message, produce verify data according to RFC3344 or the described identifying algorithm of RFC3775, this verify data will be as the part of this message or data message.

7. the communication means of mobile node according to claim 2 in the IPv4/v6 hybrid network, it is characterized in that: described step e specifically comprises:

(1) mobile node can satisfy the requirement of RFC3344 and the described relevant mobile node of RFC3775 simultaneously;

(2) mobile node can write down the domain name of home agent and communication node, can find mobile IPv 4/v6 transfer gateway by the mode of DNS inquiry, and obtain the address of home agent and communication node;

(3) mobile node can be supported the expansion to login request message and registration reply message, can produce and handle Agent Solicitation and proxy response message.

8. the communication means of mobile node according to claim 7 in the IPv4/v6 hybrid network, it is characterized in that: home agent is positioned at the IPv4 network, communication node is positioned at the IPv6 network, and the committed step of mobile node mobile IPv 4/v6 when mobile in the IPv4/v6 hybrid network comprises:

(1) when mobile node when the IPv6 network moves to the IPv4 network, mobile node sends Agent Solicitation to mobile IPv 4/v6 transfer gateway, and the request mobile IPv 4/communication node of v6 transfer gateway proxy mobile node in being in the IPv6 network initiated the Binding Update of its home address and Care-of Address;

(2) after mobile IPv 4/the v6 transfer gateway is received Agent Solicitation, the communication node of proxy mobile node in being in the IPv6 network initiated renewal process, this moment, mobile IPv 4/v6 transfer gateway will serve as the home agent of IPv6 form and the mobile node of IPv6 form respectively in IPv6 network one side, after mobile IPv 4/v6 transfer gateway was received binding acknowledgement message, the mobile node in being in the IPv4 network sent proxy response message;

(3) form of the login request message among the form of described Agent Solicitation and the RFC3344 is identical, the form of the registration reply message among the form of proxy response message and the RFC3344 is identical, wherein the types value of proxy requests is 7 by fixing tentatively, and the types value of proxy response message is 8 by fixing tentatively.

Images