KR20030075237A - Method and system for communicating with host having applications using heterogeneous internet protocols and target platform - Google Patents

Abstract

The present invention relates to a method and system for a host having an application using different Internet Protocols to communicate with a destination platform. The communication method is based on the step of the host acquiring information about the Internet protocol of the destination platform, and based on the obtained information, the destination platform in different ways depending on the result of whether the Internet protocol of the destination platform and the Internet protocol of the local application are the same. Communicating with the. The communication system includes a host in which a communication network using IPv4 and an IPv6 communication network are connected through a router, and are provided on a communication network using IPv6. This host can communicate with any destination platform connected to a communication network using IPv4 and IPv6.

Description

METHOD AND SYSTEM FOR COMMUNICATING WITH HOST HAVING APPLICATIONS USING HETEROGENEOUS INTERNET PROTOCOLS AND TARGET PLATFORM}

The present invention relates to a method and apparatus for interworking a communication network using different Internet protocols (IP), and more particularly, to a host having an application using different internet protocols. Relates to a method and system for communicating with a destination platform.

Since the Internet became available to the general public since the 1990s, its use has rapidly expanded and continues to be developed. The use of the Internet has been a driving force for the growth of Internet-related technologies, but problems such as communication speed degradation, connection bottlenecks, and routing overload have occurred. In addition, the use of the Internet, which was monopolized by a small number of users, resulted in an unforeseen lack of host IP addresses. In addition, security problems due to multiple user accesses have emerged, and in the future, Internet use will evolve from data-centered to real-time streaming such as Internet broadcasting, video conferencing, and telemedicine. Protocol version 4 has a problem in that it is difficult to implement various applications in real time data use which must guarantee the quality of service. Accordingly, researches on new Internet protocol technologies have been conducted to solve this problem, and IPv6 has been standardized as an Internet protocol to be applied to the next generation Internet.

The features of IPv6 can be summarized into three major categories. The first feature is that the IP address expands significantly, and by adopting a 128-bit addressing scheme from the existing 32-bit addressing scheme of IPv4, it is theoretically possible to allocate almost unlimited Internet addresses. In addition, since Internet addresses are assigned in the form of unicast, anycast, and multicast rather than class-specific assignment such as the conventional A, B, C, and D classes, they are allocated as in IPv4. The effect is that there is no waste of addresses.

The second feature is that it is possible to process multimedia data in real time, and it is possible to secure bandwidth so that multimedia data can be processed smoothly even at different bandwidths. In detail, the introduction of the concept of service transmission quality using the newly added flow label function according to the change of the header structure of IPv6 allows two addresses between subscribers requiring a certain level of service quality or higher. By specially processing packets transmitted between the servers, services such as video conferencing can be naturally processed without damaging the screen.

The third feature is that it provides enhanced security / authentication. The existing Internet protocol, IPv4, was not designed with a focus on security features. For example, it was necessary to install separate security-related protocols called Internet Protocol Security (IPSec) to provide security services at the IP layer. It is designed to mount related protocols in itself. In other words, in relation to security, IPv6 provides a secure communication function, a message source verification function, and an encryption function.

In addition, IPv6 supports extended routing by hierarchical structure, efficient use of header space, and efficient forwarding by simplified header format. In addition, IPv6 reduces complexity by allowing fragmentation only on hosts, not routers, and provides new plug-and-paly, or auto-configuration, capabilities. It also supports mobility.

As mentioned above, although IPv6 can provide enhancements over the existing Internet protocol, IPv4, it is currently very costly and time consuming to replace the entire existing IPv4 network with IPv6. Protocols must coexist. As a result, there is a need for a method and apparatus for allowing a host on an IPv6 network connected to a network using IPv4 to simultaneously use an IPv4 application and an IPv6 application.

Accordingly, an object of the present invention is to provide a method and apparatus for introducing IPv6 while using IPv4, which is an existing Internet protocol.

1 is a schematic diagram of a dual stack host including a BIA (Bump-in-the-API) mechanism;

2 is a diagram for explaining an operation when a dual stack host requests communication to Host 6 using a BIA mechanism.

3 is a diagram showing a schematic configuration of a dual stack transition mechanism (DSTM) system.

4 is a view for explaining the operation of the DSTM system.

5 is a schematic structural diagram of a system to which a BIA / DSTM extension mechanism is applied.

FIG. 6 is a diagram for explaining a process of acquiring information for selecting a native IPv6 connection, BIA, and DSTM in a BIA / DSTM extension mechanism; FIG.

FIG. 7 illustrates a process performed when DSTM is selected in a BIA / DSTM extension mechanism. FIG.

8 is a view for explaining a process when the BIA mechanism is selected in the BIA / DSTM extension mechanism.

9 is a schematic diagram of an architecture for implementing a BIA / DSTM extension mechanism.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

Bump-in-the-API Mechanism

In the present invention, only the core algorithm of the BIA (IPv4 to IPv6) is described, but when the BIA is actually implemented, an algorithm related to a native connection from IPv4 to IPv4 and IPv6 to IPv6 is also included.

The BIA mechanism is used when an application of a dual stack host provided on an IPv6 network is an IPv4 application, and similarly, a platform of a counterpart application provided on an IPv6 network is an IPv6 platform. An API translator is inserted between the socket application programming interface (API) module and the Transmission Control Protocol / Internet Protocol (TCP / IP) module within the stack host. It translates the socket API functionality so that local applications can make appropriate connections between platforms. This BIA mechanism performs translation between IPv4 and IPv6 without changing the IP header. For the BIA mechanism, both TCP (UDP) / IPv4 stack and TCP (UDP) / IPv6 stack must exist in one host. That is, it must be dual stack.

1 shows a schematic structure of a dual stack host 100 with a BIA mechanism. When an IPvX (eg, IPv4) application 102 in a dual stack host 100 on an IPv6 network communicates with a host that uses IPv6 (hereinafter referred to as host6), the API translator 106 may use IPv4 Detect socket API functions from application 102 and call IPv6 socket API functions to communicate with host6. In order for the IPv4 application 102 and Host 6 to communicate, pooled IPv4 addresses will be assigned via a name resolver 106_2 provided in the API translator 106. The API translator 106 is composed of an address mapper 106_4 and a function mapper 106_6 as well as the name resolver 106_2 described above.

The name resolver 106_2 returns an appropriate response to the request of the IPv4 application 102 to the IPv4 application 102. For example, if IPv4 application 102 sends a query of type "A" record to a name server (not shown), name resolver 106_2 detects the query. In order to resolve both types of records "A" and "AAAA" for the corresponding host, we create a new query and send it to the name server. If only addresses of the "AAAA" record type are available, the name resolver 106_2 requests the address mapper 106_4 to assign an IPv4 address corresponding to the IPv6 address. Name resolver 106_2 then generates an “A” record for the assigned IPv4 address from address mapper 106_4 and returns it to IPv4 application 102.

The address mapper 106_4 has provided a table of pairs of IPv4 addresses and IPv6 addresses therein. IPv4 addresses representing IPv6 addresses of the partner platform, which the address mapper 106_4 sends to the name resolver 106_2, are allocated from an IPv4 address pool (not shown). The IPv4 address thus allocated is one of addresses not used in the public network (eg, the Internet), such as "0.0.0.0" to "0.0.0.255". When the name resolver 106_2 or the function mapper 106_6 requests an IPv4 address corresponding to an IPv6 address, the address mapper 106_4 selects the IPv4 address from the IPv4 pool and returns it, and then dynamically converts the new value into a table. Register with This registration results in the case where the name resolver 106_2 has only resulted in a "AAAA" record type for the corresponding host and there is no mapping entry for that IPv6 address, and the function mapper 106_6 has received from the received data. Occurs when a socket API function call is received but does not have a mapping entry for an IPv6 source address.

The function mapper 106_6 converts socket API functions between IPv4 / IPv6. That is, if it detects an IPv4 socket API function from the IPv4 application 102, the function mapper 106_6 intercepts the function call and matches the IPv4 socket API function with the IPv4 socket API function to communicate with Host6. Call API function.

FIG. 2 is a diagram for describing an operation when the dual stack host 100 requests communication to a counterpart host, that is, host 6. FIG.

If the IPv4 application 102 on the dual stack host 100 sends a Domain Name Server (DNS) query to the name server, the name resolver 106_2 intercepts the query (transaction T201), and "A" and "AAAA". "Create a new query to try to resolve all record types and send it to the name server (transaction T202).

If the name server only resolves "AAAA" record types by responding only to "AAAA" records (transaction T203), the name resolver 106_2 requests the address mapper 106_4 for the IPv4 address corresponding to that IPv6 address. (I.e., assigning the IPv4 address of the partner platform used only internally) (transaction T204).

The address mapper 106_4 generates an IPv4 address corresponding to the IPv6 address and sends it to the name resolver 106_2 (transaction T205).

In response, name resolver 106_2 generates a record of type “A” for the assigned IPv4 address and returns it to IPv4 application 102 (transaction T206).

To send IPv4 packets to Host6, IPv4 application 102 calls the IPv4 Socket API function to function mapper 106_6 (transaction T207). The function mapper 106_6 then detects the socket API function from the IPv4 application 102. If the detected socket API function call is from an IPv6 application, no conversion occurs.

Alternatively, if the detected socket API function call was sent from the IPv4 application 102, the function mapper 106_6 needs an IPv6 address to call the IPv6 socket API function. Thus, the function mapper 106_6 requests the address mapper 106_4 for an IPv6 address corresponding to the IPv4 address (transaction T208).

In response to an IPv6 address request from the function mapper 106_6, the address mapper 106_4 selects an IPv4 address from a table of IPv4 and IPv6 address pairs and selects the corresponding destination IPv6 address from the function mapper 106_6. (Transaction T209). In other words, an IPv4 address is translated into an IPv6 address.

The function mapper 106_6 calls the IPv6 socket API function corresponding to the IPv4 socket API function for the host 6 using the destination IPv6 address sent from the address mapper 106_4 (transaction T210).

Host 6 then responds to the dual stack host 100 with an IPv6 socket API function call in an IPv6 packet (transaction T211).

When the function mapper 106_6 receives an IPv6 function call, the function mapper 106_6 requests the address mapper 106_4 for the corresponding IPv4 address to convert the IPv6 socket API function to an IPv4 socket API function ( Transaction T212).

In response to the IPv4 address request of the function mapper 106_6, the address mapper 106_4 sends the corresponding IPv4 address to the function mapper 106_6 (transaction T213).

After receiving the IPv4 address from the address mapper 106_4, the function mapper 106_6 calls an IPv4 socket API function for the IPv4 application 102 (transaction T214).

Dual Stack Transition Mechanism (DSTM)

Early IPv6 must use IPv6 address and IPv4 address in parallel to support IPv6 and IPv4 interoperability in IPv6 network. This is because hosts on an IPv6 network must be connected to IPv4 hosts on an IPv4 network that still do not support IPv6. To this end, DSTM provides dual-stacked hosts over the native IPv6 network by means of dynamic tunneling within the IPv6 network for transmitting IPv4 packets, the structure required for the transition mechanism, and the defined process. A method of allocating a global IPv4 address, that is, a method for interworking a conventional IPv4 communication network and an IPv6 communication network is provided.

This DSTM assigns the required IPv4 address to dual stack hosts, allowing dual stack hosts to communicate with IPv4-only hosts and allowing IPv4-only applications to be used unmodified on dual stack hosts. The DSTM uses a method of dynamically encapsulating IPv4 packets in IPv6 packets so that IPv4 native packets are not exposed in the IPv6 network, that is, the DSTM domain. Therefore, routers on an IPv6 network need only IPv6 routing table for IPv4 packets passing through the IPv6 network, which simplifies network management following the introduction of IPv6, and the network manager provides a separate IPv4 for DSTM. Does not require routing

DSTM not only assumes the introduction of IPv6 networks to reduce the need and dependency of IPv4 in their networks, but also the temporary IPv4 addresses that are needed (as needed only) due to the lack of global IPv4 addresses available on those networks. (Don't use DHCPv4), but it is assumed to be allocated from a DSTM server using DHCPv6 or the like. The DSTM client process for assigning temporary IPv4 addresses, along with the Dynamic Tunneling Interface (DTI) mechanism for encapsulating IPv4 packets into IPv6 packets, must function as a daemon.

The DSTM architecture includes a DSTM server that provides global IPv4 addresses to IPv6 hosts. The DSTM server allocates global IPv4 addresses to IPv6 nodes and manages mapping information (ie, binding information) between the assigned IPv4 address and the IPv6 address of the host. Here, a DHCPv6 server can be used as the DSTM server.

3 shows a schematic configuration of a DSTM system 300. As shown in FIG. 3, the DSTM domain 302, i.e., the IPv6 communication network, is a DSTM (accessible to the IPv6 host, i.e., the dual stack host node 306, included in the DSTM system 300). It is connected to the DHCPv6) server 310 and represents a communication network region on an intranet that does not require IPv4 routing. The border router 312 is located between the DSTM domain 302 and the IPv4-only domain 304 and can access both networks simultaneously. The dual stack host node 306 includes the dual IP layer and the DTI of the IPv4 / IPv6 stack, and has a DHCPv6 client process in daemon form. The global IPv4 address is an IPv4 address that can be routed in an IPv4-only domain 404. Tunnel End Point (TEP) indicates the destination of an IPv6 packet generated by the DTI by encapsulating the IPv4 packet, and refers to the boundary router 412 here.

4 illustrates a diagram for describing an operation of the DSTM system 300. In FIG. 4, the solid arrows (transactions T402 and T404) represent DNS queries or responses thereto, and the dashed dashed arrows (transactions T406 and T408) represent the movement of IPv6 packets, and the dashed arrows (transactions T410 and T416) IPv4 packets encapsulated in IPv6 packets indicate tunneling, and dashed-dotted arrows (transactions T412 and T414) indicate the movement of IPv4 packets. Among the solid arrows, the V6 transport DNS query and the dotted arrow are also included in the transport of the IPv6 packet.

The dual stack host node 306 is a DNS server (here, the V6 transport DNS server 308 or the V4 transport DNS server 314, i.e. the location and type of the DNS server is not taken into account). ) Is requested (transaction T402).

In response to a request from dual stack host node 306 for an IPv4-only node 316 address, the DNS server responds with an IPv4 address corresponding to IPv4-only node 316 (transaction T404).

Then, since the destination address of the packet to be transmitted is an IPv4 address, the dual stack host node 306 prepares for delivering the packet by connecting an IPv4 session. The dual stack host node 306 requests the DSTM server 310 for global IPv4 address information and TEP information for itself (transaction T406).

The DSTM server 310 responds to the request for information from the dual stack host node 306 in the case of DHCPv6, and converts an IPv4 address and related information (hereinafter referred to as IPv4 address information) to an IPv4-mapped IPv6 address. Respond in the form of. At this time, the DSTM server 310 also provides TEP information using the TEP option of DHCPv6 (transaction T408).

The dual stack host node 306 uses the IPv4 address received from the DSTM server 310 to create an IPv4 packet to be transmitted through the DTI, encapsulates it into an IPv6 packet, and transmits the packet to the edge router 312 (transaction T410). ). That is, the IPv4 packet tunneling process is performed on the IPv6 communication network.

The border router 312 decapsulates the encapsulated IPv6 packet from the dual stack host node 306 and then sends the original IPv4 packet to the IPv4-only node 316 of the IPv4 address contained within the decommissioned IPv6 packet. Transmit (transaction T412). The edge router 312 then generates and manages a mapping table of IPv6 addresses and IPv4 addresses.

IPv4-only node 316 on IPv4-only domain 304 sends an IPv4 packet to border router 312 for a response to transaction T412 (transaction T414).

The border router 312 communicates by retrieving the IPv6 address corresponding to the IPv4 packet received from the IPv4-only node 316 in the mapping table, encapsulating it into an IPv6 packet, and transmitting it to the dual stack host node 306 (transaction T416). To complete.

BIA / DSTM extension mechanism

The BIA / DSTM extension mechanism determines the network protocol version (i.e. IPv4 or IPv6) of the local application and the partner application platform, and selects one of the BIA mechanism, the DSTM, and the native IPv6 connection mechanism to match the local application and the partner. It is the mechanism that completes the communication of platform application.

5 shows a system 500 to which this BIA / DSTM extension mechanism is applied. As shown in FIG. 5, in the BIA / DSTM extension mechanism system 500, an IPv6 communication network 502 and an IPv4 communication network 504 are connected through a V4 / V6 gate 514. Server 506, V4 Client 508, V4 / V6 Client 510 (i.e. Dual Stack Client), DSTM (DHCPv6) Server 512, V6 Transport DNS Server 522 are connected, IPv4 communication network A V4 transport DNS server 518 and a V4 server 520 are connected to 504. Here, "V6" and "V4" means using IPv6 and IPv4, respectively, where the V6 server 506, V4 client 508, V4 / V6 client 510, V4 server 520 is an application It should be noted that this indicates. Also, the most important thing is that V4 and V4 / V6 clients can co-exist in one host.

The BIA / DSTM extension mechanism is a BIA if the local application is an IPv4 application and the partner application's platform is an IPv6 platform on an IPv6 network, that is, when the V4 client 508 and the V6 server 506 communicate over the IPv6 network 502. Choose a mechanism. In addition, the BIA / DSTM extension mechanism is used when the local application is an IPv4 / IPv6 dual stack application and the counterpart application's platform is the IPv6 platform of the IPv6 network, that is, the V4 / V6 client 510 and the V6 server ( 506 selects a native IPv6 connection when communicating.

In addition, the BIA / DSTM extension mechanism is a V4 application in which the local application can handle IPv4 packets and the partner application's platform is the IPv4 platform of the IPv4 communication network, that is, the interconnection between the IPv6 communication network 502 and the IPv4 communication network 504. If the V4 client 508 and the V4 server 520 and the V4 / V6 client 510 and the V4 server 520 communicate through the / V6 gate 514, select DSTM. Note that the DSTM used in the BIA / DSTM extension mechanism is a variant that is not exactly the same as the DSTM described with reference to FIG.

9 illustrates an architecture 900 for implementing the BIA / DSTM extension mechanism. This architecture 900 includes IPv4 applications 902, IPv4 / IPv6 applications 904, DSTM clients (DHCPv6 clients) 906, socket layers 908, BIA modules 910 with control functions, socket tables ( 912, TCP / UDP 914, IPv4 stack 916, DTI 918, IPv6 stack 920, data link & physical layer 922.

The BIA module 910 adds a function of selecting one of a native IPv6 connection mechanism, a DSTM, and a BIA mechanism by identifying a partner's address information and a related information of a local application to the BIA mechanism described with reference to FIG. 2. In addition, even in an environment in which a DNS server is provided on an IPv6 communication network, that is, a V6 transport DNS server is provided, but a DNS resolver for DNS queries using an IPv6 transport is not provided, the BIA module 910 is configured to perform IPv6 transport. There is a mechanism for enabling DNS queries.

If the DSTM usage is determined, the BIA module 910 sends a request event to the DSTM client 906, which causes the DSTM client 906 to begin by requesting an IPv4 address from the DSTM server 512. . The BIA module 910 operates a list that manages the number of sockets when the socket is created at the bottom at the start of communication. The BIA module 910 cleans up the socket information associated with the application by considering the case where the application calls the "Socket close ()" function or closes the application window, for example, as the end point of using the network. This is to clarify when the client returns an address. There is one such BIA module 910 per application.

The DSTM client 906 receives a local IPv4 address from the DSTM server (here DHCPv6 server) 512 when requested by the BIA module 910, sets the IPv4 address, and then provides the TEP router information and the local IPv6 provided together. Creates a DTI using an address. In addition, the DSTM client 906 grasps the existence of an existing socket at intervals based on life time information provided from the DSTM (DHCPv6) server 512. If the socket exists, the DSTM client 906 requests the DSTM server 512 to extend the allocation of the IPv4 address currently in use. Alternatively, if no socket exists, the DSTM client 906 will request an address return.

The DTI 918 provides a virtual tunneling interface configured using its own IPv6 address and the IPv6 address of the TEP border router.

FIG. 6 is a diagram for describing a process of acquiring information for selecting any one of a native IPv6 connection, a BIA mechanism, and a DSTM in a BIA / DSTM extension mechanism. Here, the thick solid line represents the inter-module flow in the client host 900, the dotted line represents the flow of IPv4 packets encapsulated in the IPv6 packet, the dashed dashed line represents the flow of IPv4 packets, the dashed dotted line represents the IPv6 packet It should be noted that this represents the flow of.

The name interpreter and the function mapper of the BIA module 910 modify the operation described with reference to FIG. 2 to grasp the network version of the opponent's platform as follows, and determine the mechanism using the information of the person and the opponent as follows.

The IPvX application 902 or 904 sends a DNS query to the name resolver of the BIA module 910 to determine the partner's address (transaction T602).

The name resolver determines whether the name server is a V4 transport DNS server 518 or a V6 transport DNS server 522. Specifically, when the BIA module 910 has name server address information separate from the platform's name server address information, the name resolver uses this instead of the name server of the platform address information to send a DNS query. If the final name server address information is that of the V6 transport DNS server 522, it performs transaction T604; if it is that of the V4 transport DNS server 518, it performs transaction T612. Currently, Microsoft's Windows 2000 uses only the V4 transport DNS server 518 regardless of IPv4 and IPv6. To use the V6 transport DNS server 522, this method can be used. When the IPvX application 902 or 904 receives a query of the "A" record type (transaction T602), it sends a query of the "A" record type (transaction T604 or T612), and when it receives a query of the "AAAA" record type ( Transaction T602) Send a query of record type "AAAA" (transaction T604 or T612).

Queries to the V6 transport DNS server 522 are sent to the V6 transport DNS server 522 via typical IPv6 socket processing in the name resolver (transaction T604). That is, it uses native IPv6 communication. Since the configuration for the IPv6 communication network 502 has been previously made, query transmission is possible immediately. Transactions T604 through T610 represent the query to and response from the V6 transport DNS server 522 at the name resolver.

On the other hand, a query to the V4 transport DNS server 518 is a kind of IPv4 application and assumes the use of DSTM. In other words, the name resolver determines whether the local platform is bound to an IPv4 address. If not, the name resolver obtains and binds a local IPv4 address and then forms a DTI. The query is then sent (transaction T612). This will be described in detail later. Transactions T612 through T618 represent the query to and response from the V4 transport DNS server 518 in the name resolver.

The most important directions are determined by the response to the query (transactions T606 and T614). In the case of a result of a query of record type "A", if the address information is received, the result is transmitted to the application 902 or 904 as it is. This means that both local and counterpart applications are IPv4 applications, so they will later operate in DSTM mode. If the address information is not received, the name resolver sends back a query of the "AAAA" record type (transactions T608 and T616).

If the response of the query is a result of a query of record type "AAAA", the result is passed to the application 902 or 904 as it is (transaction T624). If address information is passed, the application 902 or 904 will use a native IPv6 connection, and if it is delivered with no address information, the application 902 or 904 will again request a query of the "A" record type.

If the result of the "AAAA" record type query sent back in transactions T608 and T616 (transactions T610 and T618) has address information, the local resolver is an IPv4 application, but the application of the other party is an IPv6 application. Perform transaction T620 as a task to operate as a mechanism. Alternatively, if the result of the "AAAA" record type query sent back does not have address information, the name resolver passes the result to the application 902 or 904 (transaction T624). In this case, the application 902 or 904 will treat it as having no corresponding platform.

To operate as a BIA mechanism, the name resolver requests a private IPv4 address from the address mapper (transaction T620). Here, the private IPv4 address is an address that can be used arbitrarily in a predetermined communication network. The address mapper generates a private IPv4 address corresponding to the IPv6 address of the partner application's platform, constructs a table, and sends the generated private IPv4 address to the name resolver (transaction T622). The name resolver then produces a result of record type "A" and passes the result to the application (transaction T624).

Since the application knows the platform of the partner application as a result of the name resolver, communication with the platform starts (transaction T626). The functional mapper determines one of the native IPv6 connectivity mechanism, the BIA mechanism, and the DSTM from the BIA / DSTM extension mechanism. Specifically, when the application requests communication while providing information such as a source and destination address through the socket API 908, the function mapper looks at the address information and selects one of IPv6 native, DSTM, and BIA mechanisms.

If the destination address of the request information is an IPv6 address, the function mapper selects an IPv6 native mechanism to perform the IPv6 native mechanism in transaction Q. Since the IPv6 native mechanism is well understood by those skilled in the art, a description thereof will be omitted here.

If the destination address of the request information is an IPv4 address, the function mapper checks whether there is an IPv6 address corresponding to the address mapper (transactions T628 and T630). If there is a corresponding IPv6 address, the function mapper selects the BIA mechanism to perform the BIA mechanisms (transactions T802 to T810) shown in FIG. 8 in transaction Q. Alternatively, if the corresponding address does not exist, the function mapper selects the DSTM mechanism to perform the DSTM mechanism (transactions T702 to T732) shown in FIG. 7 in transaction Q.

FIG. 7 illustrates a process performed when DSTM is selected in a BIA / DSTM extension mechanism.

The key criterion for choosing DSTM is whether local and counterpart applications can handle IPv4 packets. This is done by confirming that the other party's address is an IPv4 address. DSTM is also used in transactions T612 and T616 in FIG. 6 described above. In this case, the name resolver should be considered an application. Here, the case where the application uses DSTM after transaction T630 described above (that is, in transaction Q) will be described.

The function mapper, which has received the information in transaction T630 and selects the DSTM mechanism, first transmits the socket information generated by the application to the socket table 912 (transaction T702). The socket table 912 registers socket information generated by the application and transmits the result to the function mapper (transaction T704). There is only one socket table 912 on the corresponding local platform of the local platforms and later the DSTM client 906 is used for the life cycle management of IPv4 addresses.

Next, the function mapper checks whether the IPv4 address is bound to the local platform. If it is bound, it means that another application of the corresponding local platform has already performed transactions T706 to T716 for IPv4 address binding. In this case, the functional mapper immediately performs transaction T718. Alternatively, if no IPv4 address is bound to the corresponding local platform, the functional mapper assigns an IPv4 address and assigns an IPv4 address for that local platform to the DSTM client 906, which sets up the DTI with IPv6 tunnel information. Request (transaction T706).

The DSTM client 906 is an IPv4 address and IPv4 default routing information for setting the address of the local platform corresponding to the DSTM server 512 and the relative tunnel point between the IPv6 network 502 and the IPv4 network 504 ( Request IPv6 TEP information (TEP) (transaction T708). Here, a DHCPv6 server may be used as the DSTM server 512.

The DSTM server 512 allocates an IPv4 address corresponding to the IPv6 of the DSTM client platform from the pool for the service of the DSTM client 906 and then sends it to the DSTM client 906 who requested the IPv4 address information and the TEP information. Pass it (transaction T710).

Receiving information for the DSTM from the DSTM server 512, the DSTM client 906 performs an IPv4 address binding and sets up a dynamic virtual DTI for encapsulating and transmitting the IPv4 packet into the IPv6 packet (transaction T712).

After confirming the DTI setting (transaction T714), the DSTM client 906 starts a timer and returns the result of the operation so far to the function mapper (transaction T716).

Function mappers continue to work like IPv4 native communication. The IPv4 packet is then encapsulated in an IPv6 packet and sent to the V4 / V6 gate 714. The V4 / V6 gate 714 tears down the encapsulated IPv6 packet and sends the original IPv4 packet to the destination node, ie, host 4 520, via the IPv4 network 504 (transaction T718).

The response from host 4 520 goes back to the transaction described above. In detail, when an IPv4 packet from the host 4 520 arrives at the V4 / V6 gate 514, the V4 / V6 gate 514 has destination address information of the IPv4 response packet, and thus it is encapsulated as an IPv6 packet and transmitted. . The encapsulated IPv6 packet then arrives at the DSTM client 906 via the IPv6 network 502 and is then broken up and returned to the application through the IPv4 stack of the host node 508 or 510 (transaction T720).

As shown in area A of FIG. 7, when the corresponding application completes communication and closes the socket, the function mapper requests the socket table 912 to delete the socket information (transaction T722), and when the socket information is deleted, Close the corresponding socket (transaction T724). Deleting the socket information in the socket table 912 is also performed when the application cleans up the socket while terminating.

As shown in area B of FIG. 7, the DSTM client 906 which started the timer checks whether there are any sockets left in the socket table 912 that need to use DSTM after an appointment with the DSTM server 512. (Transactions T726 and T728). If the check indicates that a socket using the DSTM remains, the DSTM client 906 requests the DSTM server 512 to extend the use of the IPv4 address currently assigned to the local platform (transactions T730 and T732). Alternatively, if no sockets using DSTM remain, the DSTM client 906 returns the IPv4 address assigned to the local platform to the DSTM server 512 (transactions T730 and T732). Upon returning the assigned IPv4 address, the DSTM client 906 is again ready to receive an IPv4 address assignment request for DSTM from a functional mapper belonging to all applications on that local platform. Here, it should be noted that the transactions shown in each of areas A and B of FIG. 7 are not continuous with each other, and are not transactions that proceed sequentially from the above-described transactions T630 to T720.

FIG. 8 is a diagram for describing a process when a BIA mechanism is selected in a BIA / DSTM extension mechanism.

In the above-described transaction T630 of FIG. 6, when the function mapper selects the BIA mechanism, the same transaction as that of the transactions T210 to T214 of FIG. 2 is performed.

The address mapper forwards the IPv6 address information of the destination corresponding to the IPv4 address to the function mapper (transaction T630). Upon receiving this, the function mapper continues the BIA mechanism and transmits an IPv6 packet to the destination node, that is, the host 6 506 through the IPv6 stack, using the IPv6 socket based on the received IPv6 address information (transaction T802).

The response from host 6 506 proceeds inversely to the process described above. IPv6 packets sent from host 6 506 arrive at the functional mapper over the interface (transaction T804).

The functional mapper requests the address mapper for temporary IPv4 address information corresponding to the source IPv6 address (transaction T806).

The address mapper returns the IPv4 address in the address table to the function mapper (transaction T808).

The functional mapper translates the IPv6 address information into IPv4 information and forwards the packet from Host6 506 to IPv4 application 902 via IPv4 socket API 1008 (transaction T810).

While the invention has been described and illustrated through preferred embodiments, it will be apparent to those skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the appended claims.

As described above, according to the present invention, an IPv4 application and an IPv6 application can be used simultaneously in one host. In other words, regardless of whether the application provided on the local host is an IPv4 application or an IPv6 / IPv4 dual stack application, even if the application on the other platform is an IPv4 application that processes only IPv4 packets or an IPv6 application that processes only IPv6 packets, it may communicate with each other. Can be. Moreover, the local host can use the DNS service regardless of whether the DNS server is present on the IPv4 network or the IPv6 network. In addition, in the DSTM environment, when the end point of the network use of the local host is identified by each application, it is possible to accurately identify the time point of the use of global IPv4 addresses in one platform, thereby effectively managing the lifecycle of such global IPv4 addresses. Therefore, a host on an IPv6 communication network connected to an IPv4 communication network may simultaneously use IPv4 applications and IPv6 applications while increasing utilization of IPv4 addresses.

Claims (19)

A method for communicating with a destination platform by a host having first and second applications using different Internet Protocols, a) the host obtaining information regarding an internet protocol of the destination platform; b) based on the acquiring information, if the internet protocol used by one of the first and second applications generating the communication packet and the internet protocol of the destination platform are the same, the host may perform a first process. Selecting the step, c) based on the acquiring information, if the internet protocol used by one of the first and second applications generating the communication packet and the internet protocol of the destination platform are not the same, the host may initiate a second process. Step to choose Including, The first application uses a first internet protocol, the second application uses a second internet protocol, and the host is connected to a first communication network that uses the first internet protocol. The method of claim 1, Step a) is a1) transmitting, by the host, a DNS query for the destination platform to a Domain Name System (DNS) server on a communication network to which the destination platform is connected; a2) the host receiving a response to the DNS query from the DNS server; a3) if the response to the DNS query is a response associated with the first internet protocol, the host determining that the destination platform is connected to the first communication network; a4) if the response to the DNS query is a response associated with the second internet protocol, the host determining that the destination platform is connected to a second communication network using the second internet protocol Including, And said first and second communication networks are interconnected by a router, said router converting and processing communication packets of said first and second internet protocols. The method of claim 2, And when the response to the DNS query is a response associated with the first internet protocol, the DNS server is provided on the first communication network. The method of claim 2, If the response to the DNS query is a response associated with the second internet protocol, then the DNS server is provided on the second communication network. The method of claim 2, The first process is, If the destination platform is connected to the first communication network and the first application generates the communication packet, performing a first process mode; Performing a second process mode when the destination platform is connected to the second communication network and the second application generates the communication packet Communication method comprising a. The method of claim 6, And the first process mode is a native connection mode. The method of claim 5, The second process mode, a) generating, by the second application, socket information used to transmit a communication packet of a second Internet protocol to the destination platform; b) the host storing the socket information in a predetermined place and receiving address information and routing information associated with the destination platform; c) the host encapsulating a communication packet of the second internet protocol into a communication packet of the first internet protocol based on the address information and the routing information; d) the host sending the encapsulated communication packet to the router; e) the router receiving, decapsulating and encapsulating the encapsulated communication packet into a communication packet of the second internet protocol and transmitting it to the destination platform via the second communication network; Communication method comprising a. The method of claim 7, wherein The step b) further comprises receiving address information regarding the router and binding information between an address of the first Internet protocol format and an address of the second Internet protocol format corresponding thereto. The method of claim 7, wherein The communication packet of the second internet protocol includes an address for the destination platform, and the encapsulated communication packet includes an address of the router. The method of claim 9, The address for the destination platform is an address in the second internet protocol format, and the address of the router is an address in the first internet protocol format. The method of claim 2, The second process, a) when the destination platform is connected to the first communication network, and the second application generates the communication packet, the host converts the destination address of the communication packet generated by the second application to the address of the destination platform; Converting to, b) the host sending the communication packet to the translated address Including, The destination address of the communication packet is an address of the second internet protocol format, the address of the destination platform is an address of the first internet protocol format, and the translated address is an address of the destination platform. In a communication system, A first communication network using a first internet protocol, A second communication network using a second internet protocol, A router connecting the first and second communication networks; Hosts with first and second applications using different internet protocols and communicating with the destination platform Including, The host is connected to the first communication network, obtains information about an internet protocol of the destination platform, and communicates with the destination platform based on the acquisition information. The method of claim 12, The host, First programming code for obtaining information about an Internet protocol of the destination platform, Based on the acquiring information, second programming code that is executed when an internet protocol used by one of the first and second applications generating a communication packet and the internet protocol of the destination platform are the same; Third programming code that is executed when the internet protocol used by one of the first and second applications that generate a communication packet and the internet protocol of the destination platform are not identical based on the acquisition information Including, The first application uses a first internet protocol and the second application uses a second internet protocol. The method of claim 13, The first programming code is, A first code segment for transmitting a DNS query about the destination platform to a DNS server on a communication network to which the destination platform is connected; A third code segment for determining that the destination platform is connected to the first communication network when the response to the DNS query from the DNS server is a response associated with the first internet protocol; A third code segment that determines that the destination platform is connected to a second communication network using the second internet protocol when the response to the DNS query is a response associated with the second internet protocol. Communication system comprising a. The method of claim 13, The second programming code is, A first code segment that is performed when the destination platform is connected to the first communication network and the first application generates the communication packet; A second code segment that is performed when the destination platform is connected to the second communication network and the second application generates the communication packet Communication system comprising a. The method of claim 15, And wherein the first code segment performs native connection. The method of claim 15, The second code segment is, A first code word for generating socket information used for transmitting a communication packet of a second internet protocol from the second application to the destination platform; A second code word for storing the socket information in a predetermined place and receiving address information and routing information associated with the destination platform; A third code word for encapsulating a communication packet of the second internet protocol into a communication packet of the first internet protocol based on the address information and the routing information Communication system comprising a. The method of claim 17, The second code word further includes a code word for receiving address information about the router and binding information between an address of the first Internet protocol format and an address of the second Internet protocol format corresponding thereto. Communication system. The method of claim 13, The third programming code is, And when the destination platform is connected to the first communication network and the second application generates the communication packet, converting a destination address of the communication packet generated by the second application into an address of the destination platform. 1 code segment, Second code segment for transmitting the communication packet to the translated address Including, The destination address of the communication packet is an address of the second internet protocol format, the address of the destination platform is an address of the first internet protocol format, and the translated address is an address of the destination platform.