Method of processing NAT64 prefix, network equipment and DHCPv server

Abstract

Provided are a method for processing a NAT64 prefix, a network device and a DHCPv6 server. The method comprises: acquiring synthetic IPv6 prefixes corresponding to various network configuration information options; and sending a DHCPv6 message to a DHCPv6 server, the DHCPv6 message carrying one or more options of the synthetic IPv6 prefixes. By means of the present invention, various problems occurring due to the fact that some servers are still deployed in an IPv4 network in the IPv6 / IPv4 network intercommunication process are solved; and configurations in the network are reduced; and at the same time, after NAT64 services are upgraded and are all upgraded to an IPv6 network in the later period, the network configurations are flexibly adjusted, thereby effectively reducing the complexity of system maintenance so that the maintenance becomes simple.

Description

technical field [0001] The present invention relates to the communication field, in particular to a method for processing NAT64 prefixes, network equipment and a DHCPv6 server. Background technique [0002] At present, Network Address Translation (NAT for short) in related technologies belongs to the technology of accessing the wide area network (WAN), and is a conversion technology for converting private (reserved) addresses into legal Internet Protocol (IP) addresses. It is widely used in various types of Internet access methods and various types of networks. NAT can solve the problem of lack of IP addresses. [0003] With the exhaustion of IPv4 (Internet Protocol Version 4) address resources and the gradual deployment of IPv6 (Internet Protocol Version 6) networks, the large-scale IPv4 networks and newly established IPv6 networks in the network make it urgent for operators to solve IPv6 problems. Mutual access between various IPv6 networks and IPv4 networks when / IPv4 c...

AI Technical Summary

Problems solved by technology

On the one hand, the client device cannot obtain the IPv6 address corresponding to the DNS Server. Furthermore, even if the client obtains the IPv6 address corresponding to the DNS Server, the client device still cannot obtain the AAAA record corresponding to the destination IPv4 Server. Therefore, for the case where NAT64 works independently , there needs to be a corresponding technical solution presented to solve the problem in this scenario

[0011] Currently, there is a technical solution for obtaining NAT64's pref64:: / n through PCP (Port Control Protocol): draft-ietf-pcp-nat64-prefix64-04, which expands the PCP protocol and adds PREFIX64Option to enable PCP Client (client) Obtain information such as pref64:: / n, IPv6Suffix, and IPv4Prefix List from the NAT64-Controlled PCP Server; however, this technical solution requires users and NAT64 devices to enable the PCP protocol, and the PCP protocol itself is not widely used in the network. For personal PCs as PCP In the case of Client, it is necessary to upgrade the operating system of the personal PC to support the PCP protocol, which obviously covers a wider range of implementation and is more difficult

[0012] Further, at figure 1 , you can configure DNS64Server to work with NAT64 to solve the scenario where the original DNS Server is still deployed in the IPv4 network; but for the existing IPv4 network, in addition to the DNS server, there are also: log server, cookie server, resource Location server, policy filtering server, etc., these server parameters are sent to IPv4 client devices through DHCPv4 options; furthermore, there is no general solution for how to obtain various network parameters in IPv4 networks for IPv6-Only client devices so that The IPv6-Only client device obtains the IPv6 address of each IPv4 server

Images