CN210867778U - System capable of converting IPv4 and IPv6 addresses - Google Patents

Abstract

The utility model relates to a system capable of carrying out IPv4 and IPv6 address translation, including the data center gateway, OpenFlow controller, protocol translation module and OpenFlow switch, OpenFlow controller and a plurality of OpenFlow switch constitute OpenFlow network system, OpenFlow switch connects the OpenFlow controller, interconnect between the OpenFlow switch, protocol translation module includes NAT64 module, HTTP-ALG uses gateway and FTP-ALG to use the gateway, protocol translation module is through north interface and controller communication, user end and OpenFlow network system are connected to the data center gateway. The utility model has the advantages that: the utility model discloses an application prospect is extensive after successfully releasing the product, can bring more selections for market, and the income can progressively improve. The utility model discloses can further refine LAN network management, realize the optimal treatment that each business system data forwarded. Through the conversion from IPv4 to IPv6 protocol, the bearing capacity of the network to IP equipment is improved, the network equipment is managed more effectively, and the operation and maintenance of the network are simplified.

Description

System capable of converting IPv4 and IPv6 addresses

Technical Field

The utility model relates to an IPv4 and IPv6 address translation especially relate to a system that can carry out IPv4 and IPv6 address translation.

Background

Current corporate information networks face two key challenges in supporting business requirements:

the first is that: with the rapid development of information technology, the informatization degree of each specialty of a power grid company is higher and higher, and a large amount of network equipment, office computers and terminal equipment deployed in each specialty are applied to the company information network. Monitoring and monitoring points of power grid equipment applying the signal source points of the industrial personal computer in the technology of the Internet of things are increased intensively, one equipment often has a plurality of signal collecting probes, and the monitoring and monitoring intensive points of the power grid on the equipment are increased by geometric multiples for new energy stations in Zhangjiakou new energy and flexible direct current demonstration areas. The power grid needs to monitor all operation data quantity to enhance operation control, various data means are enriched on the original basis to provide collection and processing of scheduling, relay protection and remote sensing and telemetering information, one transformer substation needs several IPv4C address sections to cover, and block type chain type system management is difficult to perform. The winter olympic society has gradually failed to meet the growing demand of power grid services due to the traditional IPv4 networking.

Secondly, the following steps: with the improvement of the support degree of each specialty of the information system, the data volume in the network is larger and larger, how to customize the service flow direction according to the service property, how to more simply configure the network protocol, how to more effectively manage the network equipment, and how to simplify the network operation and maintenance are the difficulties of the current information professional work. The traditional network switch is difficult to solve the problems due to the defects of the original design concept.

The current internationally advanced solution to the above problems is to solve the problem of network address tension by the IPv6 technology and solve the problem of network customization by the SDN technology. However, the compatibility problem of the two is lack of an effective solution, because the existing network adopts the IPv4 protocol, and it is unrealistic to completely replace the existing network with the IPv6 protocol, it is necessary to change a part of devices in the network into the IPv6 protocol first, so as to gradually realize the evolution from the whole network to the IPv 6. In the evolution process, conversion of the SDN equipment to IPv4 and IPv6 protocols is urgently needed to be realized, and data forwarding is realized.

SUMMERY OF THE UTILITY MODEL

The utility model aims to solve the technical problem that overcome exist among the prior art not enough, provide a system that can carry out IPv4 and IPv6 address conversion. The utility model discloses a SDN network equipment that supports IPv4 and IPv6 protocol conversion can provide a large amount of IPv6 addresses that can visit each other with current IPv4 address to solve the problem of present stage IPv4 address resource in short supply.

In the last few years, the related technical research of the IPv6 address has been carried out internationally, certain success is achieved, the problem of network address tension can be solved, the technology of developed countries such as the United states and Europe is relatively advanced internationally, the attitude of Asia on IPv6 is more positive than that of Europe and America, and particularly, the prior network is gradually transited to an IPv6 network in Japan, Korea and the like. China is one of the countries with early initiation of IPv6 research work, and high importance is attached to the development of IPv6 in China, but the IPv6 technology is mainly tried in the aspect of education at present and is rarely applied in national network companies.

The SDN is a new technology which is started in recent years, mainly applies an Openflow technology, a control module is independent from a switch and is designed into a controller to serve as a management end of whole network equipment, and the switch only bears a data forwarding function, so that functions of self-defining of network strategies, rapid issuing of the strategies, automatic flow control and the like can be realized. At present, international companies such as google and the like are relatively leading in the technical field, network operators such as domestic telecommunication and the like start to apply the technology, the national network companies develop technical research in two years, and Zhang family power supply companies also serve as test point units for national network related topics, test and test point application of related technologies are performed, but large-scale popularization is not available.

In the aspect of conversion of SDN to IPv6 and IPv4 protocols, related researches are few at present, more research stays in a theoretical stage, and related application cases are few.

The utility model discloses to the not enough and not smooth problem of management of the inside IPv4 address of present state net company, carry out the data forwarding technology research and the application based on IPv6 and SDN, design a SDN network equipment that supports IPv4 and IPv6 protocol conversion, for each user equipment provides more ip address in the network, make the management of maintainer to each equipment in the network simple and convenient more, high-efficient simultaneously.

The utility model discloses a realize through following technical scheme:

a system capable of converting IPv4 and IPv6 addresses comprises a data center gateway, an OpenFlow controller, a protocol translation module and OpenFlow switches, wherein the OpenFlow controller and the OpenFlow switches form an OpenFlow network system, the OpenFlow switches are connected with the OpenFlow controller, the OpenFlow switches are connected with one another, the protocol translation module comprises a NAT64 module, an HTTP-ALG application gateway and an FTP-ALG application gateway, the protocol translation module is communicated with the controller through a northbound interface, and the data center gateway is connected with a user side and the OpenFlow network system.

According to the above technical solution, preferably, the system further comprises a routing subsystem, and the routing subsystem comprises a routing configuration module, a routing device detection module, and a routing information management module.

According to the above technical solution, preferably, the interconnection subsystem further includes a NAT-PT module and a DNS-ALG module.

According to the technical scheme, the ICP server is preferably further comprised, and ICP applications are deployed in the data center server.

According to the technical scheme, preferably, the data center server configures the DNS module when supporting IPv4 and IPv 6.

According to the technical scheme, preferably, the data center server only supports IPv4 and configures a DNS64 module.

The utility model has the advantages that: the utility model discloses an application prospect is extensive after successfully releasing the product, can bring more selections for market, and the income can progressively improve. The utility model discloses can further refine LAN network management, realize the optimal treatment that each business system data forwarded. Through the conversion from IPv4 to IPv6 protocol, the bearing capacity of the network to IP equipment is improved, the network equipment is managed more effectively, and the operation and maintenance of the network are simplified.

Drawings

Fig. 1 shows a functional schematic of an embodiment of the invention.

Fig. 2 shows a working principle diagram of the NAT64/DNS64 of an embodiment of the present invention.

Fig. 3 shows an OpenFlow network schematic diagram according to an embodiment of the present invention.

Fig. 4 shows a processing flow diagram of IPv4/IPv6 protocol conversion based on OpenFlow SDN according to an embodiment of the present invention.

Fig. 5 shows a controller routing flow diagram of an embodiment of the present invention.

Fig. 6 shows an implementation architecture diagram of the interconnection subsystem of an embodiment of the present invention.

Fig. 7 shows a NAT-PT module processing flow diagram according to an embodiment of the present invention.

Detailed Description

In order to make those skilled in the art better understand the technical solution of the present invention, the present invention will be further described in detail with reference to the accompanying drawings and preferred embodiments.

As shown in the figure, the system is composed of hardware SDN equipment and a software network management system, wherein the hardware mainly switches between IPv4 and IPv6 addresses, and the software mainly allocates and manages network addresses, and the two coordinate to solve the problem of insufficient IPv4 address resources.

The IPv4/IPv6 translation techniques can be divided into two categories, network-level translation and application-level translation. The network layer translation only carries out address mapping and protocol conversion on the IPv4 data packet and the IPv6 data at the network layer, and the application layer translation further carries out address mapping to the application layer packet head and the load on the basis of the network layer translation. Currently, the mainstream IPv4/IPv6 translation technology in the industry is network layer translation, wherein NAT64/DNS64 is most widely used.

NAT64 is a stateful network address and protocol translation technology, defined by the two draft standards of RFC6145 and RFC 6146. RFC6145 defines stateless IPv4 and IPv6 translations, developed by RFC2765SIIT (stateless IP/ICMPTranslation algorithm ), describing how to implement the interchange of IPv6/ICMPv6 packet headers with IPv4/ICMPv4 packet headers. Stateless translation does not maintain the state of the session, requiring each host to have an IPv4 address, and does not essentially solve the problem of IPv4 address starvation. RFC6146 describes stateful NAT64 translation, sharing a set of IPv4 addresses among multiple IPv6 hosts by maintaining dynamic address mapping relationships. The NAT64 allows IPv 6-only users to access IPv4 servers via TCP, UDP, and ICMP unicast protocols. The IETF defines an FTP application layer gateway in RF6384 that can implement the conversion to FTP. The NAT64 generally only supports access to IPv4 network side resources by initiating connections through IPv6 network side users. However, the NAT64 also supports manual configuration of static mapping relationships, so that the IPv4 network actively initiates connection and accesses the IPv6 network.

The DNS64 works in cooperation with the NAT64 to automatically synthesize AAAA records according to the A records in the DNS system. When a user initiates an AAAA record request for requesting an IPv6 address, the DNS64 analyzes the request, if no local cache record exists, an A record request and an AAAA record request are sent to a target DNS at the same time, and if the target DNS does not return the AAAA record (namely the target host only supports IPv4), the DNS64 embeds the IPv4 address of the target host into the IPv6 address prefix according to the IPv6 address prefix negotiated with the NAT64 to form an IPv6 address, and the IPv6 address is returned to the IPv6 user. The IPv6 user accesses the IPv4 host through the address. Data packets destined for this address will eventually be routed to the NAT 64. The NAT64 recognizes the address prefix, extracts the destination IPv4 address therefrom, then communicates with the target server using the IPv4 address like a normal NAT, and creates a translation state mapping IPv4 server connection and IPv6 host connection, completing address mapping and protocol conversion. The working principle of the NAT64/DNS64 is shown in FIG. 2.

The NAT64 and DNS64 modules are separate, and DNS64 may not be used if there are other means to generate IPv6 addresses for IPv4 hosts. The DNS64 is usually deployed on the user side, and the conversion of the user IPv4 address to the IPv6 address is completed. One DNS64 may support multiple IPv6 address prefixes, generating different IPv6 addresses for different IPv4 addresses. In this manner, load balancing among multiple NAT64 devices may be achieved.

The software defined network is an emerging technology which is the hottest and the most rapidly developed in the field of network communication in recent years and is regarded as a core technology of the next generation internet. The core idea is to define the network behavior by software programming, so as to improve the network flexibility. OpenFlow is an important branch of SDN, originally proposed by stanford university researchers, with the goal of redesigning the internet in a retrogressive manner to support flexible network innovation. OpenFlow SDN defines a new network architecture that separates control and forwarding. Under the structure, network intelligence is realized by controller software running at a remote end and an application program on the controller software, and network equipment carries out high-speed data forwarding according to a forwarding decision issued by the controller.

The OpenFlow network no longer distinguishes the concepts of switches and routers, but defines a network forwarding device as an OpenFlow switch in a unified manner. The switch forwards the data packets in a mode of 'flow matching', the flow is identified by the input port of the data packet, metadata, the header fields of the packets from L2 to L4, information such as IPv6, MPLS, PBB and tunnel, and the controller defines the forwarding rules based on the flow. In the OpenFlow network, a controller replaces the control plane function of a traditional switch and a traditional router, unified management and centralized control are carried out on forwarding equipment, and the core function of the controller is to maintain the network state and formulate and issue a forwarding strategy according to service requirements. The application operates on the network through the northbound interface of the controller without regard to the specific network implementation. The OpenFlow network is schematically shown in fig. 3.

The OpenFlow SDN breaks a closed architecture of the traditional network with soft and hard integration, so that the network becomes open and programmable. Through the open interface of the controller, the application program can flexibly modify the forwarding behavior of the network. An IPv4/IPv6 protocol conversion system is realized based on an OpenFlow SDN, and a complex protocol translation function can be separated from gateway equipment and is realized by software. The protocol translation module can be integrated in the controller or run as a separate application on the business server with the most obvious benefit of extensibility. The protocol translation function can be flexibly expanded according to actual service requirements, for example, corresponding application gateways are customized according to different ICP, and therefore a better protocol conversion effect is obtained.

The transition of the IPv6 is a complex project, and is particularly true for an operator network, and the method for converting the IPv4/IPv6 protocol based on the OpenFlow SDN proposed by the present solution is applied inside a data center, and is used for assisting the ICP to migrate an application running in the IPv4 network to the IPv6 network on the basis of not modifying or slightly modifying an existing platform, so that the IPv4 application can provide services for IPv6 users. The method is based on the following assumptions: networks from IPv6 users to data centers have been provided with IPv6 bearer capabilities. In fact, after years of transformation, the operator network from the access network, the metropolitan area network to the backbone network has basically the IPv6 bearing capability, and part of the data center internal network has also been transformed to have the IPv6 access capability.

In order to realize software-defined IPv4/IPv6 protocol conversion, an OpenFlow network is required to be deployed in a data center, and a gateway device is required to be deployed at the exit of the data center, so that the intercommunication between the OpenFlow network and a traditional network is realized. Starting from version 1.2, the OpenFlow protocol has added support for IPv6 packet header matching, so an OpenFlow network inside a data center can support both IPv4 and IPv6 data packet forwarding.

The ICP application is deployed inside a data center, and the application only supports IPv4 (pure IPv4 application). The server running the application may support dual stack or only IPv 4. In the dual stack case, since the server already has an IPv6 address, the corresponding AAAA record can be directly added in the DNS without additionally using the DNS 64. For the case of supporting only the IPv4 protocol stack, the synthesis of a records (IPv4 addresses) to AAAA records (IPv6 addresses) needs to be implemented by means of DNS64 services.

In the aspect of protocol translation, a technology of fusing network layer translation and application layer translation is adopted, the network layer translation adopts NAT64 technology which is mainstream in the industry, and the application layer translation comprises standard HTTP-ALG, FTP-ALG application gateway and client application gateway which is customized for ICP application. Various protocol translation techniques are implemented as controller modules or external applications that communicate with the controller via a northbound interface. The protocol translation method proposed herein extends the scenario limitations of NAT64, supporting only IPv6 user-initiated access to IPv4 applications.

The controller is responsible for identifying network traffic and making forwarding decisions, and for cross-network access traffic, the controller is handed to a corresponding protocol conversion gateway for processing. The controller needs to maintain two tables, one is an ICP application address table, which records IPv6 addresses and IPv4 addresses corresponding to pure IPv4 applications (for example, "application a, IPv6 address B, IPv4 address C", which indicates that application a corresponds to IPv6 address B and IPv4 address C), and since the IPv6 address synthesized by DNS64 implicitly indicates the IPv4 address used by the application, the controller only needs to actually maintain the IPv6 addresses and the IPv4 addresses corresponding to the ICP applications running in the dual stack server. This table is used for the controller to identify cross-network traffic and to obtain the actual IPv4 address for the ICP application.

The other table is an application gateway table, which records the corresponding relationship between the ICP application and the application gateway (e.g., "application a, IPv6 address, port, application gateway B", indicating that the application a corresponding to the IPv6 address or port needs to be processed by the application gateway B). FIG. 4 depicts a process flow for OpenFlow SDN based IPv4/IPv6 protocol translation.

When an IPv6 user wants to access an IPv4 application, the IPv6 address corresponding to the IPv4 application is obtained by querying DNS (or DNS 64). And the data packet arrives at the data center gateway through the IPv6 network and enters the OpenFlow network. After the OpenFlow switch receives the data packet, the data packet is forwarded to the controller for processing due to the lack of a corresponding matching flow table. The controller identifies whether the data packet is from the same network (if the destination IPv6 address is a DNS64 synthesized address with prefix, or a corresponding entry exists in an ICP application address table, the data packet is considered to be accessed from a cross network), and if the data packet is accessed from the same network, the controller directly calculates a forwarding path and sends a flow table to an OpenFlow switch, and the switch forwards the data packet to a destination server. If the data packet is from a different network (i.e. the IPv6 user accesses the IPv4 application), the controller further identifies whether the data packet has application gateway processing, and if so, the data packet is handed over to the corresponding application gateway processing; otherwise, the NAT64 module is handed over to carry out network layer translation. For the case of a non-DNS 64 synthesized address, the protocol conversion module queries the target IPv4 address through the ICP application address table, converts the IPv6 data packet into an IPv4 data packet, calls the controller northbound interface to calculate a forwarding path for the new data packet, and issues the flow table. The OpenFlow switch passes the new data packet to the destination server. And after receiving the data packet, the destination server performs corresponding processing. And the processing result is returned to the protocol conversion module through the OpenFlow network, the protocol conversion module carries out protocol translation according to the stored session state, converts the IPv4 data packet into an IPv6 data packet and returns the IPv6 data packet to the IPv6 user.

In this embodiment, each data packet accessed across the network is identified and distributed by the controller, which may cause a processing pressure on the controller to be large and may become a performance bottleneck. The controller is realized by a cluster technology, and the problem can be effectively solved. The protocol conversion module can also be realized by adopting a distributed technology, so that the efficiency of protocol translation is improved.

The SDN equipment selects a path for data communication between the IPv4 network and the IPv6 network, whether a data packet needs to be processed by an internet gateway or an outlet boundary route of the data packet is judged according to an IP address, the SDN equipment only realizes a basic management control function of the SDN network, actually manages a two-layer link network, and does not support a three-layer routing function between different networks. The routing subsystem is thus designed and implemented on the basis of the basic functional architecture of the SDN device, which for other networks connected to the SDN network amounts to connecting to a central router. The routing subsystem comprises three functional modules, namely a routing configuration module, a routing equipment detection module and a routing information management module.

1. A route configuration module: the network administrator configures the boundary routing device and configures the network reachable information of the boundary routing device, namely the routing table of the boundary routing device through the module.

2. Routing equipment detection module: the module is mainly used for detecting specific physical information of the positioning boundary routing equipment in the SDN network.

3. The routing information management module: managing and maintaining known boundary routing devices in the SDN network and network reachable information in the boundary routing devices.

After receiving a data packet which cannot be processed by a switch, if finding that the data packet needs to be translated, the SDN equipment firstly forwards the data packet to an interconnection subsystem for processing. After receiving the data packet, the controller performs protocol translation and address conversion processing on the data packet, and then sends a new data packet after translation and conversion to the network for continuous processing by the controller. The interconnection subsystem comprises two functional modules, namely a DNS-ALG (Domain Name System-application layer Gateway) module and a NAT-PT (Network Address Translation-Protocol Translation) module.

NAT-PT module: mainly realizes the translation conversion between the IPv4 format data packet and the IPv6 format data packet, including protocol translation and address conversion.

DNS-ALG module: on the basis of the NAT-PT module, the mapping between the IPv4 address and the IPv6 address is established through domain name resolution.

The processing flow after the SDN switch added to the routing subsystem receives the data packet that the switch cannot process is shown in fig. 2. The routing subsystem judges whether a target host of the data packet is in the SDN according to the target IP address of the data packet, and if the target host is in the SDN, the routing subsystem can process the data packet according to the conventional equipment processing flow; if not, the routing subsystem traverses all the border routing gateway device instances maintained and managed by the routing subsystem, queries which border routing device can reach the destination network for the data packet, obtains the SDN switch connected with the correct border routing device after finding the correct border routing device, and finally selects a path between the two switches according to the conventional processing flow of the controller and issues a flow table.

The interconnect subsystem behaves as a border route and the networks it reaches include an IPv4 network representing all IPv6 networks and an IPv6 network representing all IPv4 networks. For a packet from an IPv4 network host and a destination host in an IPv6 network, the routing subsystem would consider the packet as passing through the interconnect subsystem to the destination network, and the device would forward the packet to the interconnect subsystem. The interconnection subsystem translates and converts the received IPv4 data packet into an IPv6 data packet and sends the IPv6 data packet back to the SDN network, similar to the previous processing flow, the routing subsystem finds an exit boundary routing device for the new IPv6 data packet, and then the device selects a forwarding path and issues a flow table to a switch on the path.

To implement three-layer routing between different networks, the routing subsystem needs to manage and maintain the logic information of the border routing gateway device and the network reachable information of the border routing gateway device. A network administrator may configure both types of information through a configuration module pair of the routing subsystem. And after the configuration module obtains the configuration information parameters, determining the configuration type according to the specific parameter details. If the routing gateway equipment needs to be configured, a detection module constructs equipment detection information and broadcasts the detection information in an SDN network, and for the IPv4 routing gateway equipment, the detection information is an ARP address request message; for the IPv6 routing gateway device, the probe message is an ICMPv6 neighbor address request message. When the basic function module of the controller receives the reply of the detection message, the registration information including the specific position of the equipment in the network is recorded for the equipment. Then, after receiving the reply of the probe message, the management module of the routing subsystem creates a logic instance for the device, including a routing table and a routing method of the device. And the configuration of the routing gateway equipment is completed. If network reachable information is to be configured for a certain routing gateway device, the management module of the routing subsystem finds a corresponding routing gateway instance according to the specific parameters, and then adds a routing table entry in the routing table.

The routing subsystem solves the network routing problem of communication between different network hosts and determines the transmission path of the data packet. The interconnection subsystem is used for solving the translation and conversion problem of communication data packets between the IPv4 network host and the IPv6 network host. The detailed implementation architecture of the interconnection subsystem is shown in fig. 3. Besides three functional modules, the whole architecture also comprises two message queues, namely an IP message queue and a DNS message queue, an address pool and an address translation table. The interconnection subsystem firstly filters and classifies the received data packet, if the destination IP address of the data packet is the IP address of the interconnection gateway and the source port number or the destination port number of the transmission layer is 53, the data packet is put into a DNS message queue to wait for the DNS-ALG module to process; and if the destination IP address of the data packet is an IPv4 address in the temporary IPv4 address pool or an IPv6 address of a specific 96-bit address prefix, putting the data packet into an IP message queue and waiting for the NAT-PT module to process.

The NAT-PT module mainly obtains a message from the IP message queue, then performs translation and conversion processing according to a specific message type, and performs different processing according to the message type, and a specific processing flow is shown in fig. 7, and can be roughly described in four steps:

(1) the original data packet is obtained from the message.

(2) And inquiring an address translation table according to the IPv4/IPv6 address of the data packet to perform address mapping translation.

(3) And translating and converting the header fields of IPv4/IPv6, ICMPv4/ICMPv6, UDP and TCP according to the actual condition of the data packet.

(4) And directly sending out a new data packet obtained after translation from a link layer, and sending the data packet to a controller by the controller after the data packet reaches a switch of the SDN network because the switch has no flow table item which can be matched.

The DNS-ALG module mainly acquires the message from the DNS message queue and then performs corresponding processing according to the specific message type. Different processing modes are executed according to the type of the message.

(1) DNSv 4: for the DNS request in the IPv4 format, the request type 'A' is changed into 'AAAA', then the destination address is changed into the DNS server address of the IPv6 network, and the source address is changed into the IPv6 address of the device where the interconnection subsystem is located; for the DNS reply in IPv4 format, the request type "a" is changed to "AAAA", and a 96-bit prefix is added to the IPv4 address in the resolution result, as 64 used by the interconnect subsystem: ff9 b: : and/96, and then changing the destination address to the DNS address of the IPv6 network. And finally, sending the data packet after translation conversion to the SDN network for continuous processing by the controller.

(2) DNSv 6: for the DNS request, changing the request type 'AAAA' into 'A', then changing the destination address into the DNS server address of the IPv4 network, and changing the source address into the IPv4 address of the device where the interconnection subsystem is located; for the DNS response in the IPv6 format, the request type 'AAAA' is changed into 'A', a temporarily available IPv4 address is allocated from the address pool for the IPv6 in the resolution result, the IPv4 address and the IPv6 address in the resolution result are recorded into an address mapping conversion table as an address mapping pair, and then the destination address is changed into the DNS address of the IPv6 network. And finally, sending the data packet after translation conversion to the SDN network for continuous processing by the controller.

An OpenFlow network is deployed in a data center, and gateway equipment is deployed at an outlet of the data center, so that the intercommunication between the OpenFlow network and a traditional network is realized. The new generation version of the OpenFlow protocol can support the matching of the IPv6 packet header, so that the OpenFlow network inside the data center can simultaneously support the forwarding of IPv4 and IPv6 data packets.

Each data packet accessed across the network is identified and distributed by the controller, which has a large processing pressure on the controller and may become a performance bottleneck. The controller is realized by a cluster technology, and the problem can be effectively solved.

The utility model has the advantages that: the utility model discloses rely on current network frame, do not change topology and system service, utilize IPv6 and SDN technique, to newly-built IPv6 network and reform transform multiple models such as original IPv4 network, design a SDN network equipment that supports IPv4 and IPv6 protocol conversion, can further refine LAN network management, realize the optimal treatment that each business system data forwarded, improve the bearing capacity of network to IP equipment; the requirements of expansion and upgrading realized due to the technical development requirements can be met; the modular design idea and the flexible interface design are provided, and the targeted secondary function development can be performed on the product in time.

Due to the flexibility of the SDN technology, smooth transition of IPv6 and IPv4 protocols can be realized, the networking requirements of IPv6 are efficiently and cheaply met, the access of two-layer and three-layer network equipment is met, and the problem of insufficient network addresses is solved; under the support of the functions of self-defining of network strategies, rapid strategy issuing, automatic flow control and the like, the convenience of network operation and maintenance is realized, and the operation and maintenance difficulty and workload are reduced; the SDN network equipment supporting IPv4 and IPv6 protocol conversion is designed and researched, and the application capability of a new network management technology of communication professionals is improved; the management and control capability of the communication specialty on each link of information network and system service is improved; and the information network operation and maintenance level of the information operation and maintenance personnel is improved.

The utility model discloses an application prospect is extensive after successfully releasing the product, can bring more selections for market, and the income can progressively improve. The utility model discloses can further refine LAN network management, realize the optimal treatment that each business system data forwarded. Through the conversion from IPv4 to IPv6 protocol, the bearing capacity of the network to IP equipment is improved, the network equipment is managed more effectively, and the operation and maintenance of the network are simplified.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims (6)

1. A system capable of IPv4 and IPv6 address translation, characterized by: the OpenFlow network system comprises a data center gateway, an OpenFlow controller, a protocol translation module and OpenFlow switches, wherein the OpenFlow controller and the OpenFlow switches form an OpenFlow network system, the OpenFlow switches are connected with the OpenFlow controller, the OpenFlow switches are connected with one another, the protocol translation module comprises an NAT64 module, an HTTP-ALG application gateway and an FTP-ALG application gateway, the protocol translation module is communicated with the controller through a northbound interface, and the data center gateway is connected with a user side and the OpenFlow network system.

2. The system according to claim 1, wherein the system is capable of IPv4 and IPv6 address translation: the routing subsystem comprises a routing configuration module, a routing equipment detection module and a routing information management module.

3. The system according to claim 1, wherein the system is capable of IPv4 and IPv6 address translation: the interconnection subsystem comprises a NAT-PT module and a DNS-ALG module.

4. The system according to claim 1, wherein the system is capable of IPv4 and IPv6 address translation: the ICP application system further comprises a data center server, and the ICP application is deployed in the data center server.

5. The system according to claim 4, wherein said system is capable of IPv4 and IPv6 address translation: the data center server configures the DNS module when supporting IPv4 and IPv 6.

6. The system according to claim 4, wherein said system is capable of IPv4 and IPv6 address translation: the data center server only configures the DNS64 module when IPv4 is supported.

Images