JP4595647B2 - Translator - Google Patents

Description

  The present invention relates to an address conversion method between an Internet Protocol Version 4 (IPv4) address and an Internet Protocol Version 6 (IPv6).

  NAT-PT (http: //www.ietf) is a method for connecting a network using Internet Protocol version 4 (hereinafter referred to as IPv4 network) as a protocol and a network using Internet Protocol version 6 (hereinafter referred to as IPv6 network). pp6-18 in .org / rfc / rfc2766.txt and pp9-22 in rfc2765.txt), SOCKS64 (http://search.ietf.org/internet-drafts/draft-ietf-ngtrans-socks-gateway- 05.txt) is known.

  In both cases, the IP packet format is basically converted between IPv4 and IPv6. For example, conversion between an IPv4 address and an IPv6 address is performed. Hereinafter, a device that performs this conversion is called a translator. The translator must maintain the correspondence between IPv4 addresses and IPv6 addresses. When this correspondence is dynamically created each time communication occurs, domain name system (DNS) name resolution is used as a trigger (see ASCII Publishing, Internet RFC Encyclopedia, pp323-329).

  DNS is a system that converts human-friendly names (strings) such as web URLs to IP addresses. Hereinafter, the operation of converting a name to an IP address is called name resolution. Today, almost every application on the Internet uses this DNS to obtain the IP address of the other party.

  The Tonlas lator constantly monitors DNS messages exchanged at the start of communication, and uses name resolution request messages as a trigger for creating translation information (IP address correspondences, etc.). Specifically, when name resolution is performed for a certain name of an IPv6 terminal, if the IP address as a response is an IPv4 address, the IPv4 address is rewritten to an IPv6 address and sent back to the IPv6 terminal. Then, associate the rewritten IPv4 address with the rewritten IPv6 address. In other words, the name resolution response message is intercepted and rewritten, and conversion information is created based on the information before and after the rewriting. Since the dynamically created conversion information is temporary, it is discarded when communication is completed.

See ASCII Publishing, Internet RFC Encyclopedia, pp323-329

  In the above prior art, since it is not assumed that the terminal moves, the correspondence relationship between the IPv4 address and the IPv6 address is managed only within the translator, and these correspondence relationships cannot be exchanged between a plurality of translators.

  Each translator has a certain service area and cannot exchange the correspondence between the IPv4 address and IPv6 address that each device has. Therefore, if a terminal receiving a translation service moves across the service area of each translator, communication is possible. It will break off.

  Also, as already explained, the correspondence between IPv4 addresses and IPv6 addresses is discarded when communication ends, and a different one is used for each communication. That is, the content of rewriting the name resolution response message differs for each communication. Therefore, when viewing from the terminal that requested name resolution, different IP addresses are acquired for the same name. Normally, DNS has a cache function that stores the IP address for a name that has been resolved once, but the IP address for the name is different for each name resolution in the conventional protocol conversion method. This cache function cannot be used.

Therefore, in the present invention, when the protocol of the network to which a certain terminal belongs and the network to which the communication partner's terminal belongs are different, and protocol conversion is necessary at the connection point of both networks, even if one or both terminals move. Allows communication to continue without interruption.
In addition, the DNS cache function can be used for name resolution using DNS, which is a trigger for dynamically creating conversion information necessary for protocol conversion.

  In one embodiment of the present invention, a translator includes a first network that transfers data according to a first protocol, a second network that transfers data according to a second protocol, and a conversion server to which another translator is connected. And holds conversion information for performing protocol conversion between the first protocol and the second protocol. When the translator detects an address inquiry of the terminal accommodated in the second network from the first mobile terminal accommodated in the first network, the translator in the second protocol given to the terminal A second address in the first protocol corresponding to the first address is generated. Then, the correspondence between the first address and the second address is held as the conversion information, and the correspondence between the first address and the second address is registered in the conversion server.

As a result of the movement of the second mobile terminal that has communicated with the terminal via the other translator, a source address is given to the second terminal from the second mobile terminal. When an address in the protocol 1 and the destination address is a packet having the second address, the translator inquires the address information of the terminal from the translation server. The translator receives the correspondence between the first address and the second address registered by the other translator from the server, and rewrites the destination address to the first address.
The rewritten packet is transmitted to the terminal.

  In another embodiment of the present invention, the address translation server connected to the first network for transferring data according to the first protocol is accommodated in the second network for transferring data according to the first protocol. A table that holds the correspondence between the name of the terminal, the address in the second protocol corresponding to the name, and the address in the first protocol generated corresponding to the address is held.

  When the address translation server receives an address query for the name from a terminal accommodated in the first network, the address translation server transmits an address in the first protocol to the terminal.

  Other solutions are described in detail in the section of the embodiment of the invention.

  According to the present invention, when the mobile terminal is IPv4 or IPv6, it is possible to continue communication after moving while converting the protocol. In addition, when the mobile terminal makes a call, the communication can be continued after the movement while converting the protocol in any case where the mobile terminal makes a call. In addition, when the mobile terminal is in the home network or in the visited network, it is possible to continue communication after moving while converting the protocol. Furthermore, even when route optimization is performed in conjunction with Mobile IP, communication can be continued after moving while converting the protocol.

  In addition, when a DNS server is used as the conversion server, the DNS cache can be used even when protocol conversion is required.

  FIG. 1 is a diagram for explaining the configuration of a network in which an IPv6 network and an IPv4 network are connected. Network 1 and network 2 are IPv6 networks, and network 3 is an IPv4 network. Network 1 is the home network of IPv6 mobile terminal 41, and when mobile terminal 41 moves to position q, network 2 becomes the visited network of mobile terminal 41. Hereinafter, network 1 is referred to as a home network, network 2 is referred to as a visited network, and network 3 is referred to as an IPv4 network. Reference numerals 11, 12, and 13 are translators, 21 is a translation server, 22, 23 and 24 are DNS servers, 31 is a home agent (HA), and 42 is an IPv4 terminal. The DNS servers 22 and 23 and the translators 11, 12 and 13 can communicate with both IPv4 and IPv6, and are given an IPv4 address and an IPv6 address. The translation server 21 and the DNS server 24 are given IPv4 addresses, and the home agent 31 is given an IPv6 address. Each of the translators 11, 12, and 13 has a service area. For example, the service for the terminal at position p is performed by the translator 11, and the service for the terminal at position q is performed by the translator 12.

  One embodiment of the translators 11, 12 and 13 is shown in FIG. FIG. 19 shows a functional block diagram of the translator. Although not shown, the translator has a processor, a storage device, and a communication control device for connecting to a network as hardware. Input packet selection processing, conversion server inquiry processing 100, DNS message conversion / processing 102, Mobile IP message conversion processing 103, and data packet conversion / processing 104 are configured by software and executed by the processor. It is also possible to configure these with hardware. The conversion table 101 and the conversion server address are held in the storage device. In the input packet selection process, the input packet is distributed to the conversion server inquiry process 100, the DNS message conversion / process 102, the Mobile IP message conversion process 103, or the data packet conversion / process 104. FIG. 22 shows an example of the conversion table 101. The conversion table 100 and other processing performed by the translator will be described later.

  An embodiment of the conversion server 21 is shown in FIG. FIG. 20 shows a functional block diagram of the conversion server. Although not shown, the conversion server 21 includes a processor, a storage device, and a communication control device for connecting to a network as hardware. The input packet selection process, the conversion information registration request process 111, and the conversion information inquiry process 112 are configured by software and executed by the processor. It is also possible to configure these with hardware. The conversion information 110 is held in the storage device. In the input packet selection process, the input packet is distributed to the conversion information registration request process 111 or the conversion information inquiry process 112. The conversion information 110 is a collection of the contents of the conversion table 100 held in each translator, and the items described in the table are the same as the items of the conversion table 100 shown in FIG. Therefore, the conversion information 110 table is not shown. How to register the conversion information 110 and other processes performed by the conversion server 21 will be described later.

  The DNS servers 22, 23 and 24 have the same configuration as that of the prior art.

FIG. 2 shows a communication path when the mobile terminal 41 starts communication with the IPv4 terminal 42 in the visited network 2. A packet addressed to the terminal 42 transmitted from the terminal 41 reaches the terminal 42 via the translator 12. On the other hand, a packet addressed to the terminal 41 transmitted from the terminal 42 is transmitted to the terminal 41 via the translator 12 and the home agent 31. Since the home address of the mobile terminal 41 (a care-of address when the terminal 41 moves to the visited network) is registered in the home agent 31, the terminal 42 to the terminal 41 are excluded except when route optimization described later is performed. The addressed packet always passes through the home agent. FIG. 3 shows a communication path when the mobile terminal 42 moves from the position q to the position r.
The packet addressed to the terminal 42 transmitted from the terminal 41 reaches the terminal 42 via the translator 13. On the other hand, the packet addressed to the terminal 41 transmitted from the terminal 42 is transmitted to the terminal 41 via the translator 13 and the home agent 31. Communication paths when the communication path is optimized in the states of FIGS. 2 and 3 are shown in FIGS. 4 and 5, respectively. When the communication path is optimized, the packet addressed to the terminal 41 transmitted from the terminal 42 reaches the terminal 41 without passing through the home agent 31. Note that the process of performing route optimization after the terminal 41 starts transmission to the terminal 42 in the visited network and the process of performing route optimization when the terminal 41 moves from the home network 1 to the visited network 2 are the same. Therefore, FIG. 4 shows the latter example.

  The operation procedure in FIGS. 2, 3 and 5 is shown in FIGS. In FIGS. 24, 25 and 26, the three squares above the arrow represent IP packets, and each square represents the destination IP address, source IP address, and IP payload in order from the beginning of the packet in the direction of travel. ing. When five squares are arranged, each square represents a care-of IP address, a home agent IP address, a destination IP address, a source IP address, and an IP payload in order from the top. For example, as shown in FIG. 24, the terminal 41 has two IP addresses, t6 and p6, but the left address is the home IP address (IPv6 address) given to the terminal 41. The address on the right side is a care-of address (IPv6 address) given from the visited network 2. X4 (IPv4 address) for the translation server 21, v6 (IPv6 address) and v4 (IPv4 address) for the DNS server 23, c4 (IPv4 address) for the DNS server 24, and n6 (IPv6 address) for the translator 11 And n4 (IPv4 address), l12 (IPv6 address) and l4 (IPv4 address) for translator 12, m6 (IPv6 address) and m4 (IPv4 address) for translator 13, and r4 (IPv4 address) for terminal 42 Is given.

  FIG. 24 shows an operation procedure for the mobile terminal 41 to communicate with the IPv4 terminal 42 in the visited network 2. The translator 12 monitors all DNS queries (see ASCII Publishing, Internet RFC Encyclopedia, pp323-329) in the DNS message conversion / processing 102. At the start of communication, the terminal 41 makes a DNS inquiry to the DNS server 23 in order to obtain an IPv6 address from the name (R) of the terminal 42. Since the DNS server 23 does not know the IP address corresponding to the name R, it makes a DNS inquiry to the DNS server 24. This packet format is shown in FIGS. The translator 12 detects this inquiry packet (sequence 300) and waits for a response from the DNS server 24. 55, 56, and 58 show the format of the DNS response packet. In the present embodiment, in the response packet from the DNS server 24, the name R is described in the head part of FIG. 58, and the IPv4 address r4 corresponding to the name is described in the last part. When the translator 12 detects the response packet from the DNS server 24, it rewrites the IPv4 address r4 to the IPv6 address s6 for subsequent translation (sequence 301). Since this IPv6 address is a virtual address for the name R, it will be called a destination virtual address hereinafter. This processing is performed by the DNS message conversion / processing 102 in the translator 12. At the time of this rewriting, an entry for associating r4 and s6 is prepared in the conversion table 101 in the translator 12 (see entry # 1 in FIG. 22). The DNS response packet rewritten from the actual destination address r4 to the destination virtual address s6 reaches the terminal 41 via the DNS server 23.

  The terminal 41 that has received the DNS response packet starts to transmit an IP packet to the terminal 42. The destination address of these packets is s6, and the source address is t6, which is the IPv6 address of the terminal. When the IP packet transmitted by the terminal 41 arrives at the translator 12, the packet is sent to the data packet conversion / process 104 in the translator 12. The data packet conversion / processing 104 searches the conversion table management unit 101 using the destination address s6 as a search key. Then, since the entry prepared earlier (entry # 1 in FIG. 22) is found, the source address t6 of this packet, the IPv4 address l4 of the translator 12, the source port number, the destination port number, etc. are written in the relevant entry ( Entry # 1 in Figure 22). l4 is a virtual address for the source address t6 and is hereinafter referred to as a source virtual address. Thus, the creation of the conversion rule is completed (sequence 302). The item “remaining entry lifetime” of the conversion table 101 indicates how long the entry is retained. In addition, the items “source port number” and “destination port number” in the conversion table 101 indicate that the packet is a Web access from the port number described in the header of the packet transmitted from the terminal 41, for example. If found, it can be used for processing such as sending the packet to a proxy server. Such information may be omitted. In this embodiment, “transmission source port number” and “destination port number” are not used.

  The translator 12 stores the conversion rule thus created in the conversion table 101 and registers the conversion rule in the conversion server 21 (sequence 303). This registration process is performed by the conversion server inquiry process 100 in the translator 12. At this time, how to know the address of the conversion server becomes a problem. In this embodiment, it is assumed that initialization is performed when the apparatus is started. 59 and 62 show the format of this registration message. The created conversion rule is described in the conversion information 251 part of FIG.

  In the conversion server 21 that has received the registration message, the conversion information registration request processing 111 extracts the conversion information and stores it in the conversion information storage unit 110.

  In the data packet conversion / processing 104 of the translator 12, the IPv6 addresses t6 and s6 in the packet are rewritten to l4 and r4, respectively (sequence 304), and sent to the terminal. At the time of conversion, not only the IP address but also the packet format is converted from the IPv6 packet format to the IPv4 packet format. This format conversion is also performed by the data packet conversion / processing 103 in the translator 12. For reference, Fig. 49 shows the IPv6 packet format, and Fig. 46 shows the IPv4 packet format.

  On the other hand, for the IPv4 packet sent from the terminal 42, the translator 12 rewrites the source address r4 to s6 and the destination address l4 to t6 according to the created conversion rule, and converts the IPv4 packet to an IPv6 packet. (Sequence 305). The converted packet is transmitted to the terminal 41.

  FIG. 25 shows an operation procedure until the terminal 41 and the terminal 42 communicate after the terminal 41 moves to the position r. Along with the movement, the terminal 41 is given a new care-of address q6 (IPv6) from the visited network 2. The translator 13 performs a conversion service for the terminal located at the position r.

The terminal 41 first performs location registration with the Mobile IP home agent 31 (see pp9-11 in http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-13.txt). . This packet format is shown in FIGS. The terminal 41 registers the care-of IPv6 address q6 in the home agent 31 as the current position. Thereafter, the terminal 41 transmits a packet toward the terminal 42. This packet reaches the translator 13 and is sent to the data packet conversion / process 104 in FIG. The data packet conversion / processing 104 searches the conversion table 101 using the destination virtual address s6 as a search key.
However, at this time, since there is no conversion rule in the translator 13, the IP address cannot be rewritten (sequence 306). When this is transmitted to the conversion server inquiry process 100 in the translator 13, the conversion server inquiry process 100 makes an inquiry about conversion information to the conversion server 21 (sequence 307). 60, 63 and 64 show an embodiment of the inquiry packet format. In the first part of FIG. 60, the destination virtual address s6, which is a search key for conversion information to be queried, is described. In the data packet conversion / processing 104, packets that cannot be converted are held for a certain period.

  The conversion information inquiry process 112 in the conversion server 21 extracts the search key s6 from the inquiry packet. Next, the conversion information 110 is searched using s6 as a search key. As described above, in the conversion information 110, conversion rules (correspondence between t6 and l4, correspondence between s6 and r4, etc.) corresponding to the destination virtual address s6 are registered. The conversion information retrieved from the conversion information 110 is returned to the conversion information inquiry process 112. In the conversion information inquiry process 112, the received conversion information is stored in the format shown in FIGS. 61, 63 and 65, and responded to the translator 13 (sequence 308). The conversion information is stored in the last part of FIG.

  The translator 13 extracts the conversion information from the response from the conversion server 21 by the conversion server inquiry processing 100 and stores it in the conversion table 101. Thereafter, the data packet conversion / processing 104 rewrites the held packet according to the conversion information, rewrites the IPv6 addresses t6 and s6 to l4 and r4 (sequence 304), and sends them to the terminal 42. At the time of conversion, not only the IP address but also the packet format is converted from the IPv6 packet format to the IPv4 packet format. This format conversion is also performed by the data packet conversion / processing 103 in the translator 12.

  On the other hand, the translator 13 rewrites the source address r4 to s6 and the destination address l4 to t6 according to the conversion table 101 for the IPv4 packet sent from the terminal 42, and converts the IPv4 packet to an IPv6 packet. (Sequence 305). The converted packet is transmitted to the terminal 41 via the home agent 31.

  Fig. 26 shows the operation procedure when the route optimization described in Fig. 6 is performed (see pp87-89 in http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-13.txt) Indicates.

  After the procedure of FIG. 25 is completed, the mobile terminal can select whether or not to perform route optimization. If route optimization is performed, the care-of IPv6 address q6 given from the visited network 2 is registered as the current location for the terminal 42 as the communication partner in the same manner as when the current location is registered for the HA. To do. The translator 13 monitors the location registration message addressed from the terminal 41 to the terminal 42 as in the case of the DNS message. When the translator 13 detects a location registration message described in IPv6 addressed to the terminal 42 from the terminal 41, the message is sent to the Mobile IP message conversion process 103 by the input packet selection process. The Mobile IP message conversion process 103 associates the source virtual address m4 with the pair of the source address t6 and the care-of address q6, creates a conversion rule that correlates s6 and r4, and stores the conversion rule in the conversion table 101 (See entry # 4 in Figure 22.) At the same time, the Mobile IP message conversion process 103 converts the care-of address q6 described in the location registration message into m4 and transmits it to the terminal 42. The current location information is described in the packet payload in IPv4 Mobile IP, but is described in the packet header in IPv6 Mobile Ip. Therefore, the Mobile IP message conversion process 103 transmits a location registration message to the terminal 42 after not only rewriting the address but also converting the format.

  After performing route optimization, the mobile terminal 41 uses the care-of address q6 as the source address when transmitting a packet to the terminal 42. The original address is described in the IPv6 extension header (FIG. 49). The translator 13 converts not only the source address (care-of address) and destination address (destination virtual address) of the IP header but also the address in the extension header (original The conversion table 100 is searched using the (source address) as a search key. This prevents searching for the entry before route optimization. Whether or not to use the address in the extension header as a search key is determined by whether or not there is an extension header. That is, if the original source address is included in the extension header, it must be added to the search key. Thus, packets can be converted according to the conversion information even if the terminal moves.

In the above embodiment, the case of transmitting from the mobile terminal 41 to the terminal 42 has been described.
FIG. 27 shows the procedure when the terminal 42 starts communication with the terminal 41 located at the position q. This procedure can be easily understood from the procedure described with reference to FIG. 24, although the DNS server to which the terminal 42 inquires is different, and detailed description thereof will be omitted. Since the IP address corresponding to the name T of the terminal 41 is associated with the home address t6, the DNS inquiry from the terminal 42 goes to the DNS server 22 via the DNS server 24. Therefore, the translator 11 , T6 and the destination virtual address f4 are associated with a translation rule, and the packet addressed from the terminal 41 to the terminal 42 passes through the translator 12, so that the translator 11 sends the transmission rule when creating the translation rule. The virtual address is the IPv6 address l6 of the translator 12, and r4 and l6 are associated with each other. In FIG. 27, the DNS server 22 is given i6 (IPv6 address) and i4 (IPv4 address).

  FIG. 28 shows an operation procedure until the terminal 42 and the terminal 41 communicate after the terminal 41 moves to the position r. This procedure can be easily understood from the procedure described with reference to FIG.

  FIG. 29 shows a procedure for optimizing the route after the procedure of FIG. 28 is completed. Since this procedure can be easily understood from the procedure described in FIG. 26, a detailed description thereof will be omitted. In the procedure described in FIG. 26, the terminal 41 registers the current position with the terminal 42 via the translator 13 and then starts transmitting a packet addressed to the terminal 42. In the procedure shown in FIG. The registration message is transmitted together with the packet addressed to the terminal 42. Then, the translator 13 registers the current position in the terminal 42 by the same process as described in FIG. 26, and then rewrites the transmission source address of the packet and transmits it to the terminal 42.

  FIG. 6 is a diagram illustrating a communication path when the mobile terminal 41 starts communication with the IPv4 terminal 42 in the home network 1.

  FIG. 7 shows a communication path when the mobile terminal moves to the visited network 2 (position q). 30 and 31 show the communication procedures of FIGS. 6 and 7, respectively. FIG. 24 shows an operation procedure from when the terminal 41 starts communication until data is actually exchanged with the terminal 42. FIG. 25 shows an operation procedure from when the terminal 41 moves to when data is exchanged. These procedures are the same as those described with reference to FIGS. 24 and 25, although there are differences in the DNS servers and translators involved. As a precaution, in these procedures, the home address t6 and the IPv4 address n4 of the translator are associated with each other. Therefore, the packet transmitted from the terminal 42 to the terminal 41 passes through the translator 11 as shown in FIG. And the procedure is different from that explained in FIG.

  FIG. 8 shows a communication path when the terminal 41 moves from the position q to the position p. FIG. 32 shows an operation procedure in that case. This procedure is the same as that described in FIG. 25, although there are differences in the translators involved.

  FIG. 4 described above also shows a communication path when the terminal 41 performs route optimization after moving from the position p to the position q. In addition, FIG. 5 described above also shows a communication path when moving from the position q to the position r after the path optimization. FIG. 33 and FIG. 34 show the operation procedure in each case. The procedure is the same as that described in FIG. 26, although there are differences in the translators involved.

FIG. 35 shows a communication procedure when communication is started from the terminal 42 to the mobile terminal 41 in FIG. FIG. 36 shows an operation procedure for communicating from the terminal 42 to the mobile terminal 41 when the terminal 41 moves as shown in FIG. FIG. 37 shows an operation procedure for communicating from the terminal 42 to the mobile terminal 41 when the terminal 41 moves from the state of FIG. 7 to the position shown in FIG.
FIG. 38 shows an operation procedure of communication from the terminal 42 to the mobile terminal 41 when route optimization is performed from the state of FIG. 7 to the state of FIG. FIG. 39 shows an operation procedure of communication from the terminal 42 to the mobile terminal 41 when route optimization is performed from the state of FIG. 8 to the state of FIG. Since these procedures are almost the same as the procedures described in FIGS. 27 to 29, the description thereof will be omitted.

  Next, when the IPv4 mobile terminal starts communicating with the IPv6 terminal in the visited network and moves, and when the path is optimized (http://search.ietf.org/draft-ietf-mobileip-optim-10 (See pp1-4 for .txt and pp24-32 for http://www.ietf.org/rfc/rfc2002.txt).

  FIG. 9 is a diagram for explaining the configuration of a network in which the IPv4 networks 4 and 5 and the IPv6 network 6 are connected. Network 4 is the home network of the IPv4 mobile terminal 43, and network 5 is the visited network of the mobile terminal 43. Other configurations are the same as in FIG.

  FIG. 10 shows a communication path when the IPv4 mobile terminal 43 starts communication with the IPv6 terminal 44 at the position q. FIG. 11 shows a communication path when the terminal 43 moves from the position q to the position r. Communication paths when communication paths are optimized in the states of FIGS. 10 and 11 are shown in FIGS. 12 and 13, respectively. Note that the process of performing route optimization after the terminal 41 starts transmission to the terminal 42 in the visited network and the process of performing route optimization when the terminal 41 moves from the home network 1 to the visited network 2 are the same. Therefore, FIG. 13 shows the latter example.

  40, 41 and 42 show communication procedures when communication is performed via the communication paths shown in FIGS. 10, 11 and 13, respectively. Hereinafter, FIGS. 40, 41 and 42 will be described.

  FIG. 40 shows the procedure when an IPv4 mobile terminal is in a visited network and communicates with an IPv6 terminal. The procedure when an IPv6 mobile terminal communicates with an IPv4 terminal (FIG. 24) is exactly the same. In terms of translation information, the IPv4 and IPv6 addresses are completely interchanged. That is, the translator 12 assigns an IPv6 source virtual address to the IPv4 source address, and assigns an IPv4 destination virtual address to the IPv6 destination address.

FIG. 41 shows the procedure when the IPv4 mobile terminal moves after the procedure of FIG. 40 is completed.
This is exactly the same procedure as in the case of an IPv6 mobile terminal (FIG. 25) except that the address in the translation information is switched between IPv4 and IPv6.

  FIG. 42 shows a procedure for route optimization after the procedure of FIG. It differs from the IPv6 mobile terminal in that the home agent, not the mobile terminal, performs location registration when performing route optimization. Therefore, when the conversion information is created by the translator 13 in the sequence 310 of FIG. 42, it is not related to the communication of the mobile terminal at all. However, not only the conversion information of the mobile terminal is created but also the conversion information for the home agent is required. , Created at the same time. Others are the same as in the case of the IPv6 mobile terminal.

  FIG. 14 shows a communication path when the mobile terminal 43 communicates with the home network 4. On the way, the translator 11 converts between IPv4 and IPv6. Here, when the mobile terminal 43 moves to the visited network 5, the communication path after the movement is as shown in FIG. 15 by the conversion method according to the present invention. When the route is optimized in this state, the result is as shown in FIG. Further, the communication path when the terminal 43 moves is as shown in FIG. 16, and when the path is optimized from that state, the communication path is as shown in FIG. These procedures are the same as those shown in FIGS.

  Next, an example in which the conversion server has a DNS server function serving as a telephone directory (large-scale distributed database) on the Internet will be described.

  FIG. 21 shows an embodiment of the DNS server built-in conversion server. FIG. 21 is a functional block diagram of the DNS server built-in conversion server. Although not shown, the DNS server built-in conversion server has, as hardware, a processor, a storage device, and a communication control device for connecting to a network. The input packet selection process, the conversion information registration request process 111, the conversion information inquiry process 112, and the IP address inquiry process 113 are configured by software and executed by the processor. It is also possible to configure these with hardware. The name, IP address, and conversion information 114 are held in the storage device. In the input packet selection process, the input packet is distributed to the conversion information registration request process 111, the conversion information inquiry process 112, or the IP address inquiry process 113. The conversion information registration request processing 111 processes the conversion information registration request and stores the extracted conversion information in the name, IP address, and conversion information storage unit 114. The IP address inquiry processing 113 processes a DNS name resolution request, searches the name, IP address, and conversion information storage unit 114 with the extracted name, and transmits the obtained IP address to the request source. Also, in the conversion information inquiry process 112, the conversion information inquiry is processed, the name, IP address, conversion information storage unit 114 is searched with the extracted destination virtual IP address and the like, and the obtained conversion information is transmitted to the request source. .

  FIG. 43 shows an operation procedure diagram when the IPv6 mobile terminal is in the visited network and communication starts when the DNS server built-in conversion server is used.

  Comparing FIG. 43 to the case of using a normal conversion server (FIG. 24), the conversion server 21 and the DNS server 23 become the DNS server built-in conversion server 23-1. Change to server 23-1. In addition, FIG. 23 shows an example of conversion information registered in this sequence and held by the DNS server built-in conversion server 23-1, combining the correspondence between the name and the IP address (entry # 1).

  In general, DNS caching is prohibited for name resolution when protocol conversion is required. That is, in FIG. 34, the DNS server 23 always makes an inquiry to the DNS server 24, and the result must not be held by itself. This is because the translator 12 in the middle rewrites the DNS response, so that the sameness of the IP address rewrite information held by the translator 12 and the IP address information of the cache held by the DNS server 23 is not guaranteed.

  On the other hand, the DNS server built-in conversion server 23-1 according to the present invention enables the DNS cache function by returning the destination virtual IPv6 address s 6 in response to the name resolution request for the name R. The reason for this is that each translator creates new conversion information, which is always registered in the DNS server built-in conversion information server 23-1. Therefore, if there is a change in the conversion information, be sure that the DNS server built-in conversion information server 23-1 Because the conversion information is updated and the lifetime of the conversion information can be managed, the conversion information discarded by each translator can be discarded even in the DNS server built-in conversion server 23-1. By doing so, the IP address for a certain name R becomes one destination virtual address until the lifetime of the conversion information is exhausted and discarded.

  For names that do not require protocol conversion (virtual address field is blank), the address for the name is returned in the same way as for a normal DNS server. For inquiries about conversion information, the destination virtual address and source address are searched. Returns the destination address and the source virtual address.

  As described above, the DNS server built-in conversion information server 23-1 can realize both functions of the DNS server and the conversion server.

It is a figure for demonstrating the structure of the network to which the IPv6 network and the IPv4 network were connected. It is a figure for demonstrating a communication path | route when an IPv6 mobile terminal starts communication in a visited network. FIG. 3 is a diagram for explaining a communication path when an IPv6 mobile terminal moves from the position shown in FIG. A diagram for explaining the communication path when an IPv6 mobile terminal moves from a home network to a visited network and performs route optimization, or when an IPv6 mobile terminal performs route optimization after starting communication in the visited network is there. FIG. 5 is a diagram for explaining a communication route when an IPv6 mobile terminal further moves after the route optimization shown in FIG. 4 is performed. It is a figure for demonstrating a communication path | route when an IPv6 mobile terminal starts communication in a home network. It is a figure for demonstrating the communication path | route when an IPv6 mobile terminal moves from a home network to a visited network. FIG. 8 is a diagram for explaining a communication path when an IPv6 mobile terminal further moves from the position shown in FIG. It is a figure for demonstrating the structure of the other network to which the IPv4 network and the IPv6 network were connected. FIG. 6 is a diagram for explaining a communication path when an IPv4 mobile terminal starts communication in a visited network. FIG. 11 is a diagram for explaining a communication path when an IPv4 mobile terminal moves from the position of FIG. A diagram for explaining communication routes when an IPv4 mobile terminal moves from a home network to a visited network and performs route optimization, or when an IPv4 mobile terminal performs route optimization after starting communication in the visited network. is there. FIG. 13 is a diagram for explaining a communication route when an IPv4 mobile terminal further moves after the route optimization shown in FIG. 12 is performed. It is a figure for demonstrating a communication path | route when an IPv4 mobile terminal starts communication in a home network. It is a figure for demonstrating the communication path | route when an IPv4 mobile terminal moves from a home network to a visited network. FIG. 16 is a diagram for explaining a communication path when an IPv4 mobile terminal further moves from the position shown in FIG. It is a figure for demonstrating a communication path | route when an IPv6 mobile terminal starts communication in a visited network at the time of using the DNS server built-in conversion server. FIG. 18 is a diagram for explaining a communication path when an IPv6 mobile terminal moves from the position shown in FIG. It is a block diagram for demonstrating one Example of the translator of this invention. It is a block diagram for demonstrating one Example of the conversion server of this invention. It is a block diagram for demonstrating one Example of the DNS server built-in conversion server of this invention. It is a figure for demonstrating the Example of the conversion table. It is a figure for demonstrating the Example of the conversion information hold | maintained at the DNS server built-in conversion server of this invention. FIG. 10 is a sequence diagram when an IPv6 mobile terminal in a visited network transmits. FIG. 25 is a sequence diagram when an IPv6 mobile terminal moves after the procedure of FIG. 24 ends. It is a sequence diagram in the case of route optimization when an IPv6 mobile terminal moves in a visited network. FIG. 10 is a sequence diagram when an IPv6 mobile terminal in a visited network receives a call. FIG. 10 is a sequence diagram when an IPv6 mobile terminal in a visited network moves. FIG. 29 is a sequence diagram for route optimization after the procedure shown in FIG. 28 is completed. FIG. 6 is a sequence diagram when an IPv6 mobile terminal originates in a home network. FIG. 5 is a sequence diagram when an IPv6 mobile terminal moves from a home network to a visited network. It is a sequence diagram when the IPv6 mobile terminal further moves in the visited network. FIG. 32 is a sequence diagram for route optimization after the procedure in FIG. 31 is completed. FIG. 33 is a sequence diagram for route optimization after the procedure in FIG. 32 is completed. FIG. 6 is a sequence diagram when an IPv6 mobile terminal in a home network receives a call. FIG. 36 is a sequence diagram when an IPv6 mobile terminal moves to a visited network after the procedure of FIG. 35 is completed. FIG. 37 is a sequence diagram when an IPv6 mobile terminal further moves within a visited network after the procedure of FIG. 36 is completed. FIG. 37 is a sequence diagram for route optimization after the procedure of FIG. 36 is completed. FIG. 38 is a sequence diagram for route optimization after the procedure in FIG. 37 is completed. FIG. 10 is a sequence diagram when an IPv4 mobile terminal in a visited network starts communication. FIG. 41 is a sequence diagram when an IPv4 mobile terminal moves after the procedure of FIG. 40 ends. FIG. 42 is a sequence diagram for route optimization after the procedure in FIG. 41 is completed. It is a sequence diagram when the IPv6 mobile terminal in the visited network starts communication when using the DNS server built-in conversion server. FIG. 44 is a sequence diagram when an IPv6 mobile terminal moves after the procedure of FIG. 43 ends. FIG. 45 is a sequence diagram when a new communication is started with the same partner from the IPv6 mobile terminal after the procedure of FIG. 44 is completed. It is a figure which shows an IPv4 packet format. It is a figure which shows a Mobile IPv4 Registration Request message format. It is a figure which shows a Mobile IPv4 Registration Reply message format. It is a figure which shows an IPv6 packet format. It is a figure which shows the IPv6 Destination Options Header format. It is a figure which shows a Mobile IPv6 Binding Update message format. It is a figure which shows a Mobile IPv6 Binding Acknowledge message format. It is a figure which shows a Mobile IPv6 Binding Request message format. It is a figure which shows a DNS inquiry message structure. It is a figure which shows a DNS response message structure. It is a figure which shows a DNS header part (inquiry, response common) message format. FIG. 43 is a diagram showing a message format of a DNS inquiry part (FIG. 42). FIG. 44 is a diagram illustrating a message format of a DNS response unit (common to R1, R2, and R2 in FIG. 43). It is a figure which shows a conversion information registration message structure. It is a figure which shows a conversion information inquiry message structure. It is a figure which shows the Example of a conversion information response message structure. It is a figure which shows the Example of a conversion information registration message header part message format. Conversion information query, response message header part message format It is a figure which shows the conversion information inquiry part message format. FIG. 62 is a diagram showing a conversion information response unit (common to R1, R2, and R3 in FIG. 61) message format.

Explanation of symbols

1 ... IPv6 home network, 2 ... IPv6 visited network, 3 ... IPv4 network, 4 ... IPv4 home network, 5 ... IPv4 visited network, 6 ... IPv6 network, 11. ··· Home translator (XLT H), 12 · · · Regional translator 1 (XLT V1), 13 · · · Regional translator 2 (XLT V2), 21 · · · Conversion server, 22 · · · Home DNS server ( DNS server H), 23 ... Regional DNS server (DNS server V), 23-1 ... Regional DNS server built-in conversion server, 24 ... DNS server (DNS server C), 31 ... Home Agent (HA), 41, 44 ... Mobile IPv6 terminal, 42, 43 IPv4 terminal.

Claims (4)

A first network for transferring data according to a first protocol;
A second network for transferring data according to a second protocol; and
Connected to the first network, the second network, a third network for transferring data according to a first protocol, and another torsionator connected to the second network and the third network A translator connected to the conversion server,
An interface for transmitting and receiving packets between the first network, the second network, and the conversion server;
When a terminal of a first terminal that communicates with a second terminal of the second network via the other translator in the first network moves to the third network,
The first address is a first address whose destination address is the address of the second terminal in the first protocol from the first terminal, and is given to the first terminal in the first network. Receiving a first packet including a third address in one protocol and a fourth address in the first protocol given to the first terminal in the third network;
Query the conversion server for the address information of the second terminal,
A processor for generating a fifth address in the second protocol corresponding to the fourth address;
A second address in the second protocol received from the translation server in response to the query, which is given to the second terminal in the second network, registered in the translation server by the other torrentor And first conversion information indicating correspondence between the first address and the first address,
A storage unit that holds second conversion information in which the third address, the fourth address, and the fifth address are associated with each other;
further,
When a second address is received from the first terminal, the destination address is the first address, the source address is the fourth address, and the third address is included.
The processor is
Using the first, third, and fourth addresses contained in the second packet as search keys Search the second conversion information held in the storage unit,
Rewriting the source address of the second packet from the fourth address to the fifth address based on the second translation information;
A translator that transmits the rewritten second packet to the second terminal via the interface. The translator according to claim 1,
The translator, wherein the first protocol is IPv6 and the second protocol is IPv4. The translator according to claim 1,
A translator, wherein a third address in the second packet is stored in an extension header of the second packet. The protocol conversion method according to claim 3, wherein
The translator may further include a step of determining whether to include the third address in the search key according to whether the second packet has an extension header.

Images