METHOD AND DEVICE FOR OBTAINING AN IP ADDRESS

Description

Technique antérieure

[0001] The present invention relates to the general field of telecommunications and more particularly to value-added IP (Internet Protocol) services.

[0002] IP networks have become the backbone of a multitude of services and applications. To anticipate the increased need for IP addresses, operators, network equipment manufacturers, and academics collaborated to specify the new version of the IP protocol, designated IPv6 (Internet Protocol version 6). The IPv6 specifications are now sufficiently mature. As a result, IPv6 is operationally deployed in most networks operated by operators. However, the introduction of this new version of the IP protocol raises interoperability and interworking challenges with the IPv4 version by design.

[0003] IPv4 is still the predominantly used Internet resource (approximately 75% of traffic), but the pool of IPv4 addresses has now dried up. As a reminder, IPv4 addresses are encoded on 32 bits (compared to 128 bits for IPv6 addresses). The exhaustion of IPv4 addresses therefore makes the deployment of IPv6 a major challenge for operators and IP service providers.

[0004] However, implementing a migration strategy is complicated by two major constraints: the need to ensure continuity of IPv4 services during the transition period despite the inability to provide a public IPv4 address to every customer; and the incompatibility between IPv4 and IPv6 protocols which complicates the interconnection of the two worlds.

[0005] In addition, operators and service providers must also take into account various constraints for the introduction of IPv6 in networks and service infrastructures, but also design new architectures taking advantage of the new intrinsic functions of IPv6.

[0006] The activation of IPv6 should therefore not be seen as the establishment of an Internet network parallel to the IPv4 Internet network but should be conceived as an evolution of the current Internet network. However, in a context where both IPv4 and IPv6 protocols coexist, communications between heterogeneous nodes having only a single IP stack (i.e. either an IPv4 stack or an IPv6 stack) and therefore only a single type of IPv4 or IPv6 connectivity must in particular be supported. In addition, the protocol version used for establishing a given session must ideally be transparent to the end user.Note that a node that has only one IP stack, i.e. only an IPv4 stack (we then speak of an IPv4-only node) or only an IPv6 stack (we then speak of an IPv6-only node), is only capable of sending, receiving or processing packets that conform to the protocol version implemented by this IP stack, in other words only packets that conform to the IPv4 protocol for an IPv4-only node or only packets that conform to the IPv6 protocol for an IPv6-only node.

[0007] IPv4-IPv6 interconnection mechanisms must therefore be deployed to ensure global connectivity. Global accessibility does not only concern destinations with an address belonging to the same address family (IPv4 or IPv6) as that of the source but also destinations belonging to heterogeneous domains (i.e. any destination with an IPv4 address or an IPv6 address).

[0008] Since IPv6 is not compatible with IPv4, network operators that have opted for a deployment based solely on IPv6 (i.e. "IPv6-only") use, to ensure continuity of IPv4 services, a function for converting IPv6 packets into IPv4 packets and vice versa, including a function for translating IPv4 addresses into IPv6 addresses (and vice versa). This function, commonly referred to as NAT64 (also called IPv4 packet translation function into IPv6 packets), is described in the document RFC 6146 published by the IETF (Internet Engineering Task Force) in April 2011 and entitled "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers".

[0009] In reference to the figure 1 , we consider: an IPv6-only N1 network in which only an IPv6 connectivity service is enabled for the transfer of IP packets, and to which a terminal TERM is connected that only has an IPv6 stack; and an IPv4-only N2 network in which only an IPv4 connectivity service is enabled for the transfer of IP packets and to which a remote server SERV is connected that is therefore only accessible in IPv4.

[0010] To allow the terminal TERM to access the remote server SERV, a NAT64 function is requested to, on the one hand, use an external IPv4 address (and an external port number) which allows communication to be established with the remote server SERV, and on the other hand, maintain the association between this external IPv4 address and the source IPv6 address (as well as the source port number) used by the terminal TERM. For this purpose, the NAT64 function uses specific IPv6 addresses which contain IPv4 addresses, and as defined by the IETF in the document RFC 6052 entitled "IPv6 Addressing of IPv4 / IPv6 Translators", October 2010. Such IPv6 addresses can be of different types, and more particularly: of type “IPv4-embedded IPv6” designating an IPv6 address comprising 32 bits corresponding to an IPv4 address among its 128 bits; of type “IPv4-converted IPv6” (variant of the address of type “IPv4-embedded IPv6”) designating an IPv6 address representing an IPv4 node in an IPv6 network (in other words, an IPv4 node will be accessible with this address from an IPv6-only node); and of type “IPv4-translatable IPv6” designating an IPv6 address assigned to an IPv6 node allowing a stateless IPv6-IPv4 interconnection.

[0011] To transform an IPv4 address into an "IPv4-embedded IPv6" address (and vice versa), operators can use a so-called NSP (for "Network Specific Prefix") prefix as part of their global IPv6 prefix or a so-called WKP (for "Well-Known Prefix") prefix allocated by the IETF, for example the prefix "64:ff9b:: / 96" (other WKP prefixes have been reserved by the IETF such as the prefix "64:ff9b:: / 48"). Note that when the length of the prefix used is less than 96, a hexadecimal notation is preferred to represent the IPv6 address thus constructed (in other words, the included IPv4 address will not be represented in decimal). So, for illustration purposes, "2001:db8:122:344:c0:2:2100::" is the result of constructing a "fictitious" IPv6 address from the address "192.0.2.33" using an NSP prefix "2001:db8:122:344:: / 64"; "64:ff9b::192.0.2.33" is the result of constructing a "fictitious" IPv6 address from the address 192.0.2.33 using a WKP prefix of 64:ff9b:: / 96. NAT64 is configured with the NSP or WKP prefix in different ways to construct IPv6 addresses based on IPv4 addresses and vice versa. The term "fictitious" here refers to IPv4 addresses translated into IPv6 addresses by the DNS server as opposed to "native" IPv6 addresses that are allocated to resources with IPv6 connectivity.

[0012] The paper by M. Bagnulo et al., "The NAT64 / DNS64 Tool suite for IPv6 transition", IEEE Communication Magazine, July 2012, pages 177-183, describes the NAT64 and DNS64 functions used for the IPv4 to IPv6 transition by enabling communications between unmodified IPv4 and IPv6 nodes.

[0013] As is known per se, a DNS (Domain Name System) service allows a user's terminal (or applications embedded in this terminal), connected to an IP network, to obtain from a domain name, the IP address(es) (IPv4 and / or IPv6) of the network resource designated by this domain name. A network resource is understood to mean any type of device or equipment benefiting from IP connectivity and reachable via an IP address, such as for example a server. Several transport modes can be considered for the exchange of DNS messages including those recently defined by the IETF as DNS-over-TLS, DNS-over-DTLS or DoH (DNS-over-HTTP).

[0014] Document FR 3 023 098 describes a method and a system for processing a request for resolving a name from a server sent by a client application on a communications network.

[0015] A network resource with IPv4 connectivity and therefore reachable via an IPv4 address can publish a DNS A record (or A RR (Resource Record)) to the DNS service, establishing the correspondence between the domain name associated with it and its IPv4 address. A network resource with IPv6 connectivity and therefore reachable via IPv6 can publish an AAAA record (or AAAA RR). A network resource with IPv4 connectivity and IPv6 connectivity, and therefore reachable via an IPv4 address and via an IPv6 address, can publish two records of type A and AAAA respectively. The RR records of type A and AAAA are described respectively in the IETF documents RFC1035 and RFC3596. The publication of DNS records is carried out by the network resource (for example, by means of the "Dynamic DNS" mechanism) or by another entity (for example, administrator).In the following, no assumption is made as to the method used for the publication of such recordings.

[0016] According to the current mode of operation of DNS services, when a terminal wishes to reach a network resource such as a server, it sends the DNS service a request to resolve the domain name it has in order to access the server. In this request to resolve the domain name, the terminal must specify the type of record (A or AAAA) it wants in response to its request.Thus, a terminal that supports both the IPv4 protocol and the IPv6 protocol must send two requests to the DNS service: a first request indicating a type A record and intended to obtain one or more IPv4 addresses of the network resource (also referred to as a “DNS request to obtain an IPv4 address” or more simply as a “DNS request of type A” in the remainder of the description), and a second request indicating a type AAAA record and intended to obtain one or more IPv6 addresses of the network resource (also referred to as a “DNS request to obtain an IPv6 address” or more simply as a “DNS request of type AAAA” in the remainder of the description). Activating IPv6 in a network therefore has implications for the sizing of DNS servers, because two domain name resolution requests can be issued for the same network resource.These implications are all the more important if these two requests must be issued simultaneously (and not sequentially) in order to optimize communication establishment times.

[0017] IP connectivity providers that have chosen to deploy NAT64 functions in their networks almost systematically deploy a DNS64 function, configured with the same prefixes as those used by the NAT64 function, in order to construct "IPv4-converted IPv6" IPv6 addresses based on the IPv4 addresses of IPv4-only servers. This engineering, which is based on the use of NAT64 and DNS64 functions, assumes in theory that an IPv6 terminal only sends DNS requests of type AAAA (IPv6) to the DNS service and not type A (IPv4). However, in practice, current deployments reveal suboptimal behavior of terminals that systematically send two DNS requests of type A and type AAAA, for the same network resource.As previously indicated, this behavior of the terminals has important implications on the sizing of the DNS servers (doubling of the processing load due to the two requests issued for each resolution, impact on the volume of DNS traffic), but also on the latency induced when establishing user connections, which can lead to a degradation of the quality of the connectivity service as perceived by the terminal users.

[0018] One solution to this problem could be to configure the type of DNS queries that endpoints connected to an IPv6-only network make. However, this is not a viable solution.

[0019] Indeed, more and more third-party operators (distinct from the operators providing IP connectivity services) are now offering terminal users public DNS services. According to these third-party operators, these public DNS services improve the quality of user experience compared to the DNS servers operated by IP connectivity service operators, and / or offer advanced security and confidentiality features. For example, some third-party operators report providing a response to a DNS query in 11 ms, while the average observed among IP connectivity service operators is 68 ms. Faced with such arguments, more and more users are replacing the nominal DNS service configuration provided by their IP connectivity operator on their terminals (whether fixed or mobile) with a configuration using a public DNS server.

[0020] In this context, restricting DNS queries issued by terminals connected to an IPv6-only network to a single type of query, in this case AAAA, would have the consequence of prohibiting access to these terminals by IPv4-only servers, which is neither desirable nor acceptable. Exposé de l'invention

[0021] The invention makes it possible in particular to overcome the drawbacks of the state of the art by proposing a method for obtaining by a client device, according to claim 1, an IP address to access a network resource (associated for example with a domain name) via at least one network providing an IP connectivity service to the client device, this method being implemented by the client device and comprising: a step of inserting, in a request to obtain an IPv6 address to access the network resource intended for the DNS server (in other words, in a DNS request of type AAAA as mentioned previously), information representative of a type of IP address expected by the client device of the DNS server in response to the request to obtain if the network resource has IPv4 connectivity; and a step of sending the request to the DNS server.

[0022] Correlatively, the invention also relates to a client device according to claim 16 connected to at least one network providing the client device with an IP connectivity service, this client device comprising: an insertion module, configured to insert into a request to obtain an IPv6 address to access a network resource via the network, intended for a DNS server, information representative of a type of IP address expected by the client device of the DNS server in response to the obtaining request if the network resource has IPv4 connectivity; and a sending module, configured to send the obtaining request to the DNS server.

[0023] For example, in a particular embodiment, the information representative of the expected IP address type and as inserted in the DNS query may be at least one IPv6 prefix or at least one IPv6 address comprising at least one IPv6 prefix, if the expected IP address type is a fictitious IPv6 address formed by the DNS server from said at least one IPv6 prefix and an IPv4 address of the target network resource. The IPv6 prefix may in particular be a prefix used by a function (e.g. NAT64) for converting IPv4 packets (data) into IPv6 packets (data) (and vice versa) implemented by the network that the client device plans to use to access the network resource, or an IP address comprising such a prefix.

[0024] Alternatively, the inserted information may be a predefined value (e.g., a null value or another prefix dedicated to this purpose), known to the DNS server, if the expected IP address type is an IPv4 address of the network resource.

[0025] Correlatively, the client device according to the invention may further comprise a module for translating IPv4 addresses into IPv6 addresses activated upon receipt of a response from the DNS server to said obtaining request and comprising an IPv4 address of said network resource, said translation module being configured to translate said IPv4 address into an IPv6 address using said IPv4 address and an IPv6 prefix used by a function for converting IPv4 packets into IPv6 packets implemented by the network.

[0026] The information inserted by the client device in the request to obtain an IPv6 address therefore allows the latter to specify whether it expects, in response to this request to obtain an IPv6 address (in other words in the response to the request to obtain an IPv6 address, i.e. in the “Answer Section” of an AAAA type response if the request to obtain is a DNS AAAA request), a fictitious IPv6 address or an IPv4 address when the network resource has IPv4 connectivity.

[0027] It is noted that the invention applies advantageously regardless of the DNS server with which the client device is configured: it may be the DNS server that is designated here by “nominal” provided by the operator offering the IP connectivity service to the client device, for example when it is attached to the network or during a prior configuration (for example, a “factory” configuration), or an alternative DNS server, such as for example a public DNS server that the user of the client device has chosen to use in replacement of the nominal DNS server provided by its operator. This is made possible thanks to the information provided by the client device to the DNS server when it queries it to obtain the IP address of the network resource that it wishes to access.

[0028] Furthermore, the invention is described with reference to a network providing an IP connectivity service to the client device. It should be noted that the client device may simultaneously have several active connection interfaces allowing access to different networks, each of these networks providing it with IP connectivity; the invention then applies to each DNS server configured for each of these active connection interfaces. The same DNS server may be used for several active connection interfaces, or each active connection interface may use a separate DNS server.

[0029] The invention provides a mechanism that allows reconciling the needs of service providers (IP connectivity providers and public DNS providers), the needs of users, but also those of terminal manufacturers.

[0030] Indeed, the mechanism proposed by the invention allows a client device, by means of a single AAAA type request (request to obtain an IPv6 address to access the network resource within the meaning of the invention), to obtain different types of IP addresses depending on whether the network resource it seeks to access benefits from IPv4, IPv6 or both connectivity, depending on the capabilities of the client device which sets the type of IP address it wishes to receive if the network resource has IPv4 connectivity. The invention thus allows an IPv6-only client device to access IPv4-only, IPv6-only or IPv4 / IPv6 network resources, without unnecessarily overloading the DNS server requested by the client device and while saving the resources of the client device (in particular its battery if it is a mobile device).The traffic carried by access networks, and more specifically the volume of DNS traffic, is optimized, and, consequently, the communication setup times are also optimized. This results in an improvement in the quality of experience as perceived by users of client devices.

[0031] Furthermore, the invention provides freedom to the user of the client device who can either use the nominal DNS server of his IP connectivity operator or configure his client device with a DNS server provided by a third-party operator, such as for example a public DNS server as mentioned above. Thanks to the invention, there is thus a form of functional parity between client devices using the nominal DNS servers offered by their IP connectivity providers and client devices that decide to use alternative DNS services offered by third-party providers.

[0032] The invention also makes it possible to manage different possible configurations of the network and in particular of the DNS server used for this network which may or may not include a DNS64 function for translating IPv4 addresses into IPv6 addresses to facilitate continuity of services.

[0033] It should be noted that some client devices may themselves incorporate an address translation module, also known as a CLAT (for "Customer side (Address) Translator") or BIH (Bump-in-the-Host) module or function, for example to allow an application installed on the client device and which can only operate on an IPv4 stack to send messages to IPv4 addresses even when the client device only has IPv6 connectivity. Such a module is described in the IETF document RFC 6877 entitled "464XLAT: Combination of stateful and stateless translation", April 2013. When a DNS64 function is implemented by the DNS server consulted by the client device to access a resource, this DNS64 function and the CLAT module of the client device are then redundant if they are activated simultaneously. The invention makes it possible to avoid such redundancy and in particular to minimize the use of the CLAT module.

[0034] In particular, in the example of information that can be inserted into the get request provided above, the predefined value makes it possible to handle the case where no DNS64 function is implemented by the DNS server consulted by the client device or to disable the use of a DNS64 function supported by this DNS server. In this case, if the client device implements a CLAT module, it can use the IPv4 address returned to it to translate this IPv4 address into an IPv6 address itself.

[0035] Ainsi, the invention offers the possibility of avoiding redundancy in the case where the DNS64 function is also supported by the DNS server, but also of allowing the client device to directly manage the construction of IPv6 addresses.

[0036] If the DNS server implements a DNS64 function, the client device can provide the DNS server with the prefix to use to generate a dummy IPv6 address for the IPv4-only or dual-stack (IPv4-IPv6) network resource from its IPv4 address. The IPv6 address thus formed by the DNS64 server is then returned to the client device in the DNS64 server's response. The prefix provided is typically the one used by a NAT64 function for converting IPv4 packets to IPv6 packets present in the network through which the client device wishes to access the network resource.

[0037] The invention therefore also applies in the case of networks not implementing a DNS64 function and relying on an implementation of such a function by the client devices themselves.

[0038] The invention is therefore particularly advantageous in the current IPv4 to IPv6 migration context described above.

[0039] In a particular embodiment, the obtaining request may further comprise: an instruction to generate said address in IPv6 format only if the network resource has only IPv4 connectivity; or an instruction to generate said address in IPv6 format if the network resource has IPv4 connectivity even if it also has IPv6 connectivity.

[0040] Thanks to this additional instruction inserted in the request obtained by the client device when it expects an address in IPv6 format, we can more optimally manage the case where an IPv4-only application configured to communicate with an IPv4-IPv6 network resource is embedded on an IPv6-only client device (which then also embeds a CLAT module). Indeed, the client device can ask the DNS server to send it in response to its request not only the native IPv6 address of the network resource (which will do by default the DNS server upon receipt of an AAAA type request when the network resource has IPv6 connectivity), but also its IPv4 address that the client device can then provide directly to the application without needing to activate a NAT46 function to transform the native IPv6 address of the network resource into an IPv4 address that the application can use.It is noted that the client device is able to distinguish a fictitious IPv6 address generated (i.e. formed) by the DNS server for the network resource from a native IPv6 address of this network resource in the event of dual connectivity of the network resource, since it has the prefixes used to form the fictitious IPv6 addresses.

[0041] In another embodiment, the get request may further include other indications intended for the DNS server such as for example: an instruction to execute a specific algorithm to form an IPv6 address from an IPv4 address of the network resource (for example the algorithm defined in the IETF RFC 6052 document); and / or an instruction to use a well-known prefix (WKP for Well-Known Prefix) to form an IPv6 address from an IPv4 address of the network resource; and / or an instruction to use a suffix that guarantees the neutrality of a “checksum” (integrity control mechanism) of a pseudo header of a transport layer; and / or an instruction to return one or more IPv4 addresses in an additional section of a response to the obtain request.

[0042] The instruction to use the WKP prefix may be useful in particular in an embodiment in which it is desired that the IPv4 address of the network resource, if any, be transmitted to the client device in the body of the DNS server response. In this embodiment, the IPv4 address may then be encoded in an IPv6 format using the WKP prefix.

[0043] As a reminder, the TCP pseudo-header also covers the source and destination addresses of the IP layer. Therefore, any modification of these addresses makes the control verification based on the pseudo-header (called "checksum") obsolete. The instruction to use a suffix makes it possible to avoid recalculating the TCP "checksum" when transforming IPv4 packets into IPv6 packets and vice versa by a NAT64 (or CLAT) function. If this instruction is not used, the NAT64 function must recalculate the "checksum" based on the new pseudo-header.

[0044] In a particular embodiment, the method further comprises a step of determining whether the network implements a function for converting IPv4 packets to IPv6 packets (and vice versa) (i.e., a NAT64 function).

[0045] Where appropriate, the method may further comprise a step of obtaining at least one IPv6 prefix used by said conversion function (i.e., NAT64).

[0046] This allows the client device to dynamically discover for itself whether the network to which it is connected and which it intends to use to access the network resource implements a NAT64 function or not. This embodiment has a particular advantage when the client device has several active network interfaces or when it changes network interfaces. It should be noted that there is no limitation associated with the portion of the network implementing the NAT64 function: this function can be located in the access network, the core network, or in an interconnection network, etc.

[0047] Alternatively, the client device can be configured with this information independently of the implementation of the method according to the invention, for example in the context of a “factory” configuration. This variant is particularly suitable for client devices such as CPEs (for “Customer Premises Equipment” in English).

[0048] To find out whether or not the network implements an IPv4 packet conversion function to IPv6 packets, various techniques can be considered.

[0049] Ainsi, in a particular embodiment, the DNS server to which the client device sends the obtain request is a server distinct from a so-called “nominal” DNS server with which the client device has been configured by a network operator, and: the determining step comprises a step of sending to a home DNS server a request to obtain an IPv6 address to access a given network resource known to have only IPv4 connectivity; and if a positive response is received from the home DNS server comprising an IPv6 address to be used to access the given network resource, the client device determines that the IP network implements a function for translating IPv4 packets into IPv6 packets (NAT64 function).

[0050] In this embodiment, the method may further comprise a step of obtaining an IPv6 prefix used by the function of converting IPv4 packets into IPv6 packets from the IPv6 address contained in the positive response received from the nominal DNS server.

[0051] This embodiment requires the client device to store information about the nominal DNS configuration provided by the network operator providing its IP connectivity to access the network resource if the client device is subsequently configured with an alternative DNS server. However, it provides a very simple solution for the client device to dynamically discover whether the IP network has a NAT64 function, without involving said NAT64 function.

[0052] In another embodiment, the determining step may be implemented using the Port Control Protocol (PCP).

[0053] The PCP protocol is known in itself and described in particular in the IETF RFC 7225 document entitled "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", May 2014.

[0054] This embodiment has the advantage of being reliable and deterministic because the information on the presence of a NAT64 function, as well as the prefixes used by this function, are provided where appropriate by the NAT64 function itself which is on the path of the messages sent by the client device. In addition, it makes it possible to manage the case where several NAT64 functions are implemented by the network operator.

[0055] In yet another embodiment, the obtaining method according to the invention comprises: a step of receiving an announcement message from the network comprising at least one IPv6 prefix used by a function for converting IPv4 packets into IPv6 packets implemented by the network; and a step of storing said at least one IPv6 prefix contained in the announcement message.

[0056] In this embodiment, the client device uses the information announced by the network itself to deduce whether the latter uses a NAT64 function, and if so to obtain the prefix(es) that this function uses.

[0057] Furthermore, this embodiment does not involve the NAT64 function in the discovery process and relies on configuration mechanisms known per se.

[0058] In a particular embodiment, the determining step is repeated for the network upon detection of a change affecting a network configuration of the client device for said network.

[0059] Such a change is, for example, a change in the DNS server queried by the client device to access a resource via this network or a connection to a new network. The invention thus makes it possible to adapt dynamically and transparently for the user of the client device to changes in the configuration of the client device, and in particular to the DNS configuration (for example, when the user decides to use an alternative DNS server to replace his or her nominal DNS server or if a change in DNS configuration is decided by the network operator).

[0060] In view of the above, the invention relies on the client device and the obtaining method implemented by it, but also on the DNS server which processes the DNS requests coming from the client device and the processing method executed by the latter.

[0061] Thus, the invention also relates to a processing method according to claim 11, by a DNS server associated with a network providing an IP connectivity service to at least one client device, this method comprising: a step of receiving, from a client device, a request to obtain an IPv6 address to access a network resource, a request in which information representative of a type of IP address expected by the client device from the DNS server is inserted in response to the request to obtain if the network resource has IPv4 connectivity; if the network resource has IPv6 connectivity, a step of sending to the client device, in response to the request, an IPv6 address of said network resource; if the network resource has IPv4 connectivity: a step of obtaining an IPv4 address of the network resource; and a step of sending a response to the request to obtain containing at least one IP address to access the network resource determined by the DNS server from the IPv4 address obtained and corresponding to the type of IP address expected by the client device.

[0062] Correlatively, the invention relates to a DNS server according to claim 18 comprising: a receiving module, capable of receiving from a client device connected to a network providing the client device with an IP connectivity service, a request to obtain an IPv6 address to access a network resource via said IP network; a detection module, configured to detect in the obtaining request, information representative of a type of IP address expected by the client device from the DNS server in response to the obtaining request if the network resource has IPv4 connectivity; a sending module, activated if the network resource has IPv6 connectivity, and configured to send to the client device, in response to the obtaining request, an IPv6 address of the network resource; modules, activated if the network resource has IPv4 connectivity, comprising: an obtaining module configured to obtain an IPv4 address of the resource;and a sending module, configured to send a response to the obtaining request containing at least one IP address to access the network resource determined by the DNS server from said obtained IPv4 address and corresponding to the type of IP address expected by the client device indicated by the information inserted in the obtaining request.;

[0063] The processing method and the DNS server according to the invention benefit from the same advantages cited above as the obtaining method and the client device according to the invention.

[0064] The invention further provides the ability for a DNS server to respond to a request to obtain an IPv6 address with an IPv4 address when the network resource from which the client device is seeking to obtain an address has IPv4 connectivity, and the client device indicates that it expects an IPv4 address in response to its request to obtain an IPv6 address.

[0065] In a particular embodiment, the information inserted in the obtaining request comprises at least one IPv6 prefix or at least one IPv6 address comprising at least one IPv6 prefix and said at least one IP address determined by the DNS server comprises at least one IPv6 address formed by the DNS server from said at least one IPv6 prefix and the IPv4 address of the network resource obtained.

[0066] Alternatively, the information inserted in the obtain request may have a predefined value known to the DNS server, and said at least one IP address determined by the DNS server is then the IPv4 address of the obtained network resource.

[0067] Note that the IPv4 address of the network resource can be sent in the DNS server response encoded according to the IPv4 format in an additional section of the response.

[0068] Alternatively, the IPv4 address can be passed in the body of the DNS server's response, encoded in IPv6 format, for example using the prefix "::ffff:0:0 / 96".

[0069] In a particular embodiment, the sending step and the obtaining step are implemented by the DNS server only if the network resource has only IPv4 connectivity. In other words, if the network resource also has IPv6 connectivity in addition to IPv4 connectivity, it is the IPv6 address of the network resource that is sent by default in response to the AAAA type obtaining request to the client device.

[0070] In another embodiment, the sending and obtaining steps are implemented whenever the network resource has IPv4 connectivity, even if it also has IPv6 connectivity. The advantage of this embodiment has been described previously and is not repeated here.

[0071] In a particular embodiment, the obtaining method and / or the processing method are implemented by a computer.

[0072] The invention also relates to a first computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a client device in accordance with the invention and comprising instructions adapted to the implementation of a obtaining method as described above.

[0073] The invention also relates to a second computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a DNS server in accordance with the invention and comprising instructions adapted to the implementation of a processing method as described above.

[0074] Each of these programs may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0075] The invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of the first or second computer program mentioned above.

[0076] The information or recording media may be any entity or device capable of storing programs. For example, the media may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a hard disk, or a flash memory.

[0077] On the other hand, the information or recording media may be transmissible media such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other means.

[0078] The programs according to the invention can in particular be downloaded from an Internet-type network.

[0079] Alternatively, each information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the obtaining method according to the invention or the processing method according to the invention.

[0080] According to another aspect, the invention relates to a communication system comprising: at least one client device according to the invention connected to at least one IP network via a connection interface; and at least one DNS server according to the invention to be used by the client device in association with said connection interface.

[0081] In a particular embodiment, the DNS server is a public server distinct from a so-called nominal DNS server with which the client device has been configured by the IP network operator.

[0082] The communication system according to the invention benefits from the same advantages cited previously as the obtaining method, the processing method, the client device and the DNS server according to the invention.

[0083] It is also possible to envisage, in other embodiments, that the obtaining method, the processing method, the client device, the DNS server and the communication system according to the invention have in combination all or part of the aforementioned characteristics. Brève description des dessins

[0084] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting character. In the figures: [ Fig. 1 ] there figure 1 , already described, represents in its environment, a communication system of the state of the art in which a NAT64 function is implemented between an IPv6-only network and an IPv4-only network; [ Fig. 2 ] there figure 2 represents in its environment, a communication system in accordance with the invention, in a particular embodiment, this system comprising a client device and a DNS server in accordance with the invention; [ Fig. 3 ] there figure 3 schematically illustrates the hardware architecture of the client device of the figure 2 ; [ Fig. 4 ] there figure 4 schematically illustrates the hardware architecture of the DNS server of the figure 2 ; [ Fig. 5 ] there figure 5 represents, in the form of a flowchart, the main steps of a obtaining method according to the invention as they are implemented by the client device of the figure 2 ; [ Fig. 6 ] there figure 6 represents a first possible format for the information inserted in accordance with the invention in its DNS requests by the client device of the figure 2 ; [ Fig. 7 ] there figure 7 represents a second possible format for the information inserted in accordance with the invention in its DNS requests by the client device of the figure 2 ; [ Fig. 8 ] there figure 8 represents, in the form of a flowchart, the main steps of a processing method according to the invention as implemented by the DNS server of the figure 2 ; [ Fig. 9 ] there figure 9 illustrates the consequences on the quality of experience of communication between a client device and a network resource of using an IPv6 address for the network resource returned by the DNS server and not corresponding to the network connection interface for which it was generated; and [ Fig. 10 ] there figure 10 illustrates another example of the impact on the quality of experience of communication between a client device and a network resource of using an IPv6 address for the network resource returned by the DNS server that does not match the network connection interface for which it was generated. Description de l'invention

[0085] There figure 2 represents, in its environment, a communication system 1 in accordance with the invention, in a particular embodiment.

[0086] The communication system 1 comprises at least one client device T, in accordance with the invention. In the example envisaged here, the client device T is a terminal of a user, such as for example a smart phone or smartphone, a digital tablet, a laptop, etc. It should be noted that no limitation is attached to the nature of the client device T. It may alternatively be a router or CPE (for "Customer Premises Equipment") connected to a local network, a USB key or a dongle attached to user equipment, etc.

[0087] According to the invention, the client device T has at least one active connection interface through which it is connected to at least one network providing it with an IP connectivity service (referred to for the sake of simplification in the following as “IP network”). In the example of the figure 2 , the client device T has two active connection interfaces I1 and I2, via which it is connected respectively to the IP network NW1 and to the IP network NW2. The networks NW1 and NW2 both provide the client device T with IP services and in particular IP connectivity allowing the client device T to connect to the public Internet network. No limitation is attached to the nature of the IP services provided by the networks NW1 and NW2 to the client device (IP connectivity, voice over IP service, etc.), nor to the nature of the networks NW1 and NW2. These may be fixed or mobile networks, such as for example 3G, 4G or 5G networks, compliant with any of the versions of the 3GPP standard (Release 15, 16, and following), WLAN (Wireless Local Access Network) networks, etc.

[0088] As mentioned above, the invention facilitates the migration of IP networks to support communications established according to the IPv6 protocol. For the sake of simplification, it is assumed here that the networks NW1 and NW2 provide the client device T with only IPv6 connectivity. In other words, the networks NW1 and NW2 are assumed here to be IPv6-only. Alternatively, another configuration of the networks NW1 and NW2 could be envisaged, such as a dual-stack IPv4-IPv6 configuration. Furthermore, for the sake of simplification, it is also assumed that the client device T is IPv6-only, in other words, it has only IPv6 connectivity and no IPv4 connectivity.

[0089] In the example of the figure 2 , the networks NW1 and NW2 each host a DNS server allowing the resolution of domain names, referenced respectively by DNS# 11 for the network NW1 and DNS#21 for the network NW2, and in accordance with the invention. These DNS servers are referred to as “nominal” in the remainder of the description, in the sense that they are DNS servers provided by the networks NW1 and NW2 and with which the operators of these networks have initially configured the client device T to allow it to access network resources S via their networks, such as for example a remote server. No limitation is associated with the nature of the network resources that the client device wishes to access (server, terminal, application, etc.). It is assumed here that the remote server S is connected to the Internet network via an IP network NW3. The IP network NW3 can be IPv6-only, IPv4-only or dual-stack IPv4-IPv6.

[0090] This configuration was carried out by the operators of the NW1 and NW2 networks, for example when attaching the client device T to the NW1 and NW2 networks, or during a prior step (for example as part of a "factory" configuration). It can be carried out in a manner known per se by the operators of the NW1 and NW2 networks using the PCO (Protocol Configuration Option) protocol for 3GPP networks, or options of the DHCPv6 (Dynamic Host Configuration Protocol for IPv6) protocol for fixed networks.

[0091] In this configuration, the operator of the network NW1, respectively of the network NW2, has provided the client device T with accessibility information of the nominal DNS server DNS#11 (i.e., information allowing access to the DNS server# 11), respectively to the nominal DNS server DNS# 21. Such accessibility information may be an IP address of the nominal DNS server. As a result of this configuration, when the client device T wishes to access a network resource (for example, the server S) via the network NW1, respectively NW2, it uses its connection interface I1, respectively I2, to send a DNS query to the nominal DNS server DNS# 11, respectively DNS#21, using the accessibility information communicated to it to access this nominal DNS server. The client device thus contacts the DNS server in order to obtain an IP address allowing it to access this network resource.

[0092] Table 1 below provides an illustrative excerpt of a DNS configuration reflecting information received from a 3GPP network by a client device such as client device T using the PCO protocol. [Table 1] ... Access Point Name Length: 4 APN: myipv6onlyapn PDN address Length: 9 0000 0... = Spare bit(s): 0x00 PDN type: IPv6 (2) PDN IPv6 if id: 0000000000000011 ESM cause Element ID: 0x58 Cause: PDN type IPv6 only allowed (51) Protocol Configuration Options ... Protocol or Container ID: DNS Server IPv6 Address (0x0003) Length: 0x10 (16) IPv6: 2001:db8::1

[0093] The information provided by the 3GPP network reported in Table 1 indicates to the client device T that only IPv6 connectivity is supported by the network (ESM cause 51 “PDN type IPv6 only allowed”), and that a DNS server is provided by the network whose IPv6 address is “2001:db8::1”.

[0094] The client device T retrieves the nominal DNS configuration information associated with each of its active connection interfaces (in other words for each IP network to which it is connected via a connection interface), in this case its connection interface I1 to the network NW1 and its connection interface I2 to the network NW2. It stores the retrieved information in a local configuration file called CONFIG-DNS. Note that the same nominal DNS server can be defined for connection interfaces to distinct IP networks. In the embodiment described here, each nominal DNS server (i.e. chosen by the IP network operator for its users) is associated in the local configuration file CONFIG-DNS with a parameter called NOMINAL-RESOLVER here, and valued at 1 to indicate that it is a nominal DNS server.Each nominal DNS server is also associated with a parameter called here NETWORK-ID allowing to unambiguously link this nominal DNS server to the IP network via which said DNS server was configured, or equivalently to the connection interface used by the client device T to access the IP network. The structure of the NETWORK-ID parameter is local to each client device. For example, the NETWORK-ID parameter can be valued with an identifier of the connection interface used to connect to the IP network supporting the nominal DNS server (and hosting it here) or an identifier of the IP network supporting the nominal DNS server. In the example considered here, for illustrative purposes, the NETWORK-ID parameter is valued at NW1 for DNS server# 11 and at NW2 for DNS server# 21.

[0095] It should be noted that the list of nominal DNS servers maintained in the local configuration file CONFIG-DNS may be subject to modifications at the initiative of the IP networks to which the client device T is connected and may be updated according to the instructions received from these IP networks. This may be the case, in particular, when one of the IP networks to which the client device T is connected wishes the client device T to use a new nominal DNS server to resolve its DNS queries (for example, for the IP network NW1, a DNS server # 12 instead of the DNS server # 11), or in the event of roaming of the client device T ("handover") between several IP networks. In this case, the client device T replaces the now obsolete nominal DNS server in the local configuration file CONFIG-DNS with the new nominal server provided by its operator.

[0096] In the example envisaged here, the communication system 1 further comprises an alternative DNS server, referenced by DNS# 2, in accordance with the invention (also more commonly referred to as a public DNS server) and located in the public Internet network. It is assumed that this alternative DNS server can be used independently of the connection interface selected by the client device T for routing its DNS requests. By alternative DNS server, it is meant here that it is not hosted by the networks NW1 and NW2 but by a third-party network. Such a DNS server is then qualified as public. The Google Public DNS, Cloudflare or QUAD9 servers are examples of such public DNS servers.

[0097] It is assumed here that the client device T is provided with an application module that allows its user, manually or via a trusted application, to configure the use of one (or more) alternative DNS servers as described above to replace the nominal DNS servers provided to the client device T by the operators of the networks to which it is connected. In the example considered, the client device T is thus configured with the public alternative DNS server DNS#2; it is assumed here that the DNS server#2 can be used regardless of the connection interface used by the client device T (i.e. its connection interface I1 to the network NW1 or its connection interface I2 to the network NW2), and that the client device T is configured to use this alternative DNS server DNS#2 to replace the DNS servers #11 and DNS#21.In other words, the client device T is configured via the application module to address its DNS requests to the public DNS server DNS#2 when it wishes to access a network resource (for example server S) using its connection interface I1 or its connection interface I2.

[0098] Alternatively, a different alternate DNS server may be used for each active connection interface of the client device T.

[0099] As for the nominal DNS servers, the configuration of the client device T with the alternative DNS server #2 consists in particular of storing at the client device T accessibility information of the alternative DNS server DNS #2, for example its IP address. This configuration is stored here in the local configuration file CONFIG-DNS of the client device T. In the embodiment described here, although the alternative DNS server is intended to be used as a replacement for the nominal DNS servers DNS # 11 and DNS # 21, the accessibility information of the nominal DNS servers is kept in the configuration file.

[0100] To distinguish in the CONFIG-DNS configuration file the alternative DNS server DNS#2 used by the client device T to resolve its DNS queries from the nominal DNS servers DNS# 11 and DNS# 21 initially provided by the operators of the networks NW1 and NW2, the alternative server DNS# 2 is associated with a NOMINAL-RESOLVER parameter set to 0.

[0101] Furthermore, since DNS server#2 can be used by client device T regardless of the active connection interface used by the latter (i.e., I1 or I2), no NETWORK-ID parameter is associated with DNS server#2 in the CONFIG-DNS configuration file.

[0102] Alternatively, DNS server #2 may be associated with a NETWORK-ID parameter set to NW1 and NW2. If a separate alternate DNS server is used for each active connection interface, each alternate DNS server is associated with a NETWORK-ID parameter identifying the connection interface used by client device T to access that alternate DNS server.

[0103] Table 2 below shows an excerpt from the CONFIG-DNS configuration file. [Table 2] DNS# 11 NOMINAL-RESOLVER= 1 NETWORK-ID= NW1 DNS# 21 NOMINAL-RESOLVER= 1 NETWORK-ID= NW2 DNS# 2 NOMINAL-RESOLVER= 0

[0104] Note that the NETWORK-ID parameter can also be omitted when the client device T is single-interface, i.e. it has a single active connection interface and is connected to only one IP network. In this case, the absence of the NETWORK-ID parameter for the nominal DNS server (i.e. for the DNS server associated with a NOMINAL-RESOLVER= 1 parameter) indicates that it is the nominal DNS server provided or hosted by the network operator associated with this single connection interface.

[0105] Alternatively, separate files can be used to store the nominal DNS servers provided by the operators on the one hand, and the alternative DNS servers on the other.

[0106] Furthermore, in the embodiment described here, only the servers in the CONFIG-DNS configuration file associated with a NOMINAL-RESOLVER parameter set to 0 are used by the client device T to resolve its DNS queries. The other servers associated with a NOMINAL-RESOLVER parameter set to 1 are used here to discover the IP networks NW1 and NW2 that implement a NAT64 function, and where applicable the IPv6 prefix(es) used by this function. Note that if no alternative DNS server is associated with a connection interface, the client device T is configured to use by default the nominal DNS server provided by the network operator associated with this connection interface.

[0107] In the embodiment described herein, the client device T has the hardware architecture of a computer, as schematically illustrated in figure 3 It includes in particular a processor 2, a RAM 3, a read-only memory 4, a non-volatile flash memory 5 in which is stored for example the local configuration file CONFIG-DNS, as well as communication means 6 including in particular the connection interfaces I1 and I2 and an IPv6 protocol stack.

[0108] The read-only memory 4 is a recording medium according to the invention, readable by the processor 2 of the client device T, and on which is recorded a computer program PROG1 according to the invention, which comprises instructions for implementing an obtaining method according to the invention. In other words, the computer program PROG1 defines different functional modules of the client device T allowing it to implement the obtaining method according to the invention. In the embodiment described here, these modules comprise (cf. figure 2 ) an insertion module M1 configured to insert in accordance with the invention a specific option in the DNS requests that the client device T addresses to the DNS servers with which it has been configured, this option being named PREFIX64 here and described later, a sending module M2 configured to send these DNS requests to the DNS servers concerned, and a module M3 configured to determine whether or not the IP networks with which it has an active connection interface implement a NAT64 function for converting IPv4 packets into IPv6 packets and vice versa. In the remainder of the description, for the sake of simplification, such a function is referred to as a function for converting IPv4 packets into IPv6 packets, although it is also capable of converting IPv6 packets into IPv4 packets. The conversion of the packets requires a function for translating IPv4 addresses into IPv6 addresses.

[0109] The functions of modules M1, M2 and M3 are described in more detail later with reference to the steps of the production method according to the invention.

[0110] In the embodiment described here, the DNS#11, DNS#21, DNS#2 servers according to the invention also have the hardware architecture of a computer, as schematically illustrated in figure 4 . Each DNS server comprises a processor 7, a RAM 8, a ROM 9, a non-volatile flash memory 10, as well as communication means 11 and one or more connection interfaces depending on the IP network in which it is hosted.

[0111] The read-only memory 9 is a recording medium according to the invention, readable by the processor 7 of the server, and on which is recorded a computer program PROG2 according to the invention, which comprises instructions for implementing a processing method according to the invention. In other words, the computer program PROG2 defines different functional modules of the DNS server allowing it to implement the processing method according to the invention, and more particularly in the embodiment described here (cf. figure 2 ), a reception module M4 capable of receiving DNS requests from client devices conforming to the invention, a detection module M5, configured to detect whether the DNS requests it receives contain the specific PREFIX64 option, a resolution module M6 for the DNS requests it receives, and a sending module M7 configured to develop and send to the client devices that request it responses to their DNS requests, taking into account, where appropriate, the indications conveyed by the PREFIX64 option.

[0112] The functions of modules M4, M5, M6 and M7 are described in more detail later with reference to the steps of the processing method according to the invention.

[0113] We will now describe, with reference to the figures 5 à 10 the main steps of the obtaining method and the processing method implemented respectively, in a particular embodiment, by the client device T and by the public alternative DNS server DNS#2.

[0114] As mentioned previously, the invention is particularly advantageous in that it allows an IPv6-only client device (for example the client device T) seeking to access a network resource (for example the server S), without knowing in advance what connectivity this network resource benefits from (IPv4-only, IPv6-only, or IPv4 / IPv6) and whatever this connectivity, to obtain an IP address for this network resource by querying a DNS server with which it is configured by means of a single DNS query requiring an AAAA type record for the network resource, in other words by means of a request to obtain an IPv6 address to access this network resource within the meaning of the invention.According to the invention, this single AAAA type request allows it, thanks to the information it contains, to obtain either a fictitious IPv6 address or an IPv4 address when the network resource has IPv4 connectivity, depending on the expectations of the client device (these may result for example from preferences or the configuration of the client device). This avoids overloading the DNS servers of the communication system 1 since the client device T only issues one type of DNS request. Furthermore, very advantageously, the invention makes it possible to manage several IP network configurations, and applies whether or not these networks implement a DNS64 type function. It is also suitable when an address translation function is available at the client device T (for example a CLAT function).

[0115] In reference to the figure 5 , in the embodiment described here, the client device T first determines, via its module M3, whether the IP networks to which it is connected (NW1 and NW2 in the example considered) and which it is likely to use to access network resources implement or not a NAT64 function for converting IPv4 addresses into IPv6 addresses (step E10). It makes this determination for each IP network with which it has an active connection interface. We are interested here in a NAT64 function configured to transform an IPv4 address into an “IPv4-embedded IPv6” address (and vice versa), using an NSP prefix or a WKP prefix as discussed previously. It should be noted that in the example considered here, we are more particularly interested in an address of type "IPv4-converted IPv6" which is a particular variant of the addresses "IPv4-embedded IPv6" applying to addresses representing IPv4 network resources in an IPv6 world.

[0116] To this end, the client device T can proceed in different ways.

[0117] Thus, according to a first embodiment, the client device T can detect that an IP network to which it is connected implements (or activates) a NAT64 function because the client device T has been previously configured by the IP network operator with various elements used by such a NAT64 function, such as typically the NAT64 prefixes (i.e. IPv6 prefixes of the NSP or WKP type) used by the NAT64 function. This configuration of the client device T can be carried out by the IP network operator via the explicit announcement by the IP network of the NAT64 prefix(es) using, for example, a dedicated DHCPv6 option, or an RA (for Router Advertisement) option as described in the IETF RFC 4861 document entitled “Neighbor Discovery for IP version 6”, September 2007, or even an object of the PCO protocol.Upon receipt of such an announcement, the client device T stores the NAT64 prefixes in the CONFIG-DNS configuration file in association with the corresponding IP network (i.e. corresponding to the connection interface via which it received the announcement), for example in the form of a pair comprising the NETWORK-ID parameter and a parameter called PREFIX64.

[0118] Note that multiple NAT64 prefixes can be configured within the same IP network. A single NAT64 prefix can also be used by multiple distinct IP networks. As a result, the client device T can maintain one or more {NETWORK-ID, PREFIX64} pairs listing, where appropriate, the NAT64 prefixes used by the IP networks to which it is connected.

[0119] According to a second embodiment variant, the client device T automatically discovers the presence of NAT64 functions in the IP networks with which it has active connection interfaces by requesting the nominal DNS servers stored in the CONFIG-DNS configuration file (i.e. the DNS servers associated in the file with a NOMINAL-RESOLVER parameter set to 1).

[0120] More specifically, in this second variant, the client device T sends a DNS query to obtain an IP address corresponding to an AAAA type record (also more simply referred to herein as a AAAA type DNS query) for a given network resource (referred to as a “test” network resource in the following) known to have only IPv4 connectivity. This “test” network resource is for example a server known to be IPv4-only. For illustration purposes, herein considered as a test network resource is a “test” server corresponding to a domain name “myserver.example” having the IPv4 address “192.0.2.33” as its IP address.

[0121] This AAAA type DNS query constitutes a request to obtain an IPv6 address for the “test” network resource within the meaning of the invention. Such a DNS query is sent by the client device T using IPv6 to each nominal DNS server DNS# 11 and DNS# 21.

[0122] If, in response to this AAAA DNS query, the client device T receives a positive response from a nominal DNS server including an IPv6 address for the "test" server, this means that a DNS64 function is enabled at this nominal DNS server and therefore that the IP network hosting this nominal DNS server implements a NAT64 function. Furthermore, the IPv6 address contained in the response received by the client device T was formed by the nominal DNS server for the IPv4-only test server from its IPv4 address and the NAT64 prefix with which the nominal DNS server was configured, which coincides, as previously highlighted, with the NAT64 prefix used by the NAT64 function implemented by the IP network. The client device T can therefore extract the NAT64 prefix in question from this IPv6 address; for this purpose, it uses, for example, the algorithm specified in section 2.3 of RFC 6052.

[0123] Thus, for illustration purposes, if the nominal DNS server DNS# 11 returns a positive response including the IPv6 address "2001:db8:122:3c0:0:221:: / 128" for the "test" server "myserver.example", knowing the IPv4 address associated with the "test" server and the algorithm described in RFC 6052, the client device T extracts the corresponding NAT64 prefix: "2001:db8:122:300:: / 56". The client device T then saves this prefix for the IP network NW1, for example in the form of a pair {NETWORK-ID=NW1, PREFIX64= 2001:db8:122:300:: / 56}.

[0124] The client device T can also, instead of extracting the NAT64 prefix at this stage, directly save the IPv6 address returned by the DNS server# 11 in the PREFIX64 parameter and store the pair {NETWORK-ID=NW1, PREFIX64=2001:db8:122:3c0:0:221:: / 128}.

[0125] According to a third embodiment, the client device T uses the PCP protocol and in particular the mechanism described in the RFC 7225 document to discover the presence of NAT64 functions in the IP networks with which it has active connection interfaces. This mechanism allows the client device T to retrieve the list of NAT64 prefixes associated with the connection interface that it uses when implementing the mechanism. If it retrieves at least one NAT64 prefix during this implementation, this means that the IP network corresponding to the connection interface used implements a NAT64 function.

[0126] The procedure for discovering the presence of a NAT64 function in an IP network implemented during step E10 can also be executed recursively. Such recursive execution is of interest in particular when the client device T is connected via intermediate equipment to the IP network, such as a CPE. In this case, the CPE executes the discovery procedure by implementing one of the techniques mentioned above, then communicates to the client device T the NAT64 prefixes discovered during this procedure. The CPE can use for this purpose in particular an RA type announcement message as mentioned above.

[0127] If, during step E10, the client device T detects the activation of a NAT64 function in one of the IP networks to which it is connected, it associates with this IP network, in the CONFIG-DNS configuration file, a parameter called NAT64_ENABLED valued at 1. Thus, in the CONFIG-DNS configuration file, the NAT64_ENABLED parameter is valued at “1” for IPv6-only networks for which at least one NAT64 prefix was discovered during step E10. The NAT64_ENABLED parameter is, however, valued at “0” for IPv4-only networks, for IPv4 / IPv6 “dual-stack” networks, and for IPv6-only networks without NAT64 function.

[0128] It is noted that, in the embodiment described here, the client device T re-executes the procedure for detecting the presence of a NAT64 function which has just been described each time it detects a change in the network configuration provided by the operator of a network and which may have an impact on the DNS services. Such a change in network configuration may take place in particular, as mentioned previously, when the client device T is in a roaming situation. It may result in an update of the NAT64 prefix(es) used by the NAT64 function implemented by the network where applicable or by maintaining or, on the contrary, changing the value of the NAT64_ENABLED parameter depending on whether or not the network in question implements a NAT64 function, or a change in the nominal DNS server associated with the network, etc.

[0129] We now assume that the client device T wishes to access a network resource S, for example the server S (step E20).

[0130] To this end, in a manner known per se, it sends, via one of its active connection interfaces and its sending module M2, a DNS query for resolving the domain name of the server RM to the DNS server associated with this connection interface (step E70). In the illustrative example envisaged here, the client device T is configured to request the alternative server DNS#2 to resolve its DNS queries, regardless of the connection interface used by the client device T.

[0131] According to the invention, the client device T is configured to send only to the DNS server with which it is configured (DNS server # 2 here), DNS queries of type AAAA, regardless of the connectivity (IPv4, IPv6 or IPv4 / IPv6) enjoyed by the network resource S that it wishes to access, in other words, only DNS queries to obtain an IPv6 address to access this network resource. This DNS query, noted R-AAAA, contains in a conventional manner (in accordance with what is described in the IETF RFC1035 document), the domain name associated with the network resource S that it seeks to resolve as well as the desired type of registration, i.e. AAAA.

[0132] To manage in particular the cases where the network resource S is not associated with a AAAA type record because it only has IPv4 connectivity (and therefore only an IPv4 address), the invention advantageously provides for the insertion of additional information into the R-AAAA request by the insertion module M1 of the client device T before it is sent to the DNS server# 2 (step E60). This information is inserted, in the embodiment described here, in an option of the EDNS(0) extension of the DNS protocol introduced for this purpose, which is called PREFIX64 in this description. It is representative of the type of IP address expected by the client device T from the DNS server#2, in response to the R-AAAA request, if the network resource S targeted by this request has IPv4 connectivity. This type of IP address expected by the client device T can be either a fictitious IPv6 address, formed by the DNS server for example, or an IPv4 address as detailed below.

[0133] In the embodiment described here, the PREFIX64 option is defined (and recognized as such by the DNS server receiving the DNS query containing this option) such that it is representative of the type of IP address expected by the client device of the DNS server that it queries with an R-AAAA query containing this option, in the response of the DNS server to the R-AAAA query, if the network resource S targeted by this query has only IPv4 connectivity. In other words, the DNS server detecting the PREFIX64 option in the DNS query addressed to it is not required to apply the type of IP address defined by the latter if the network resource has dual IPv4 and IPv6 connectivity.

[0134] In another embodiment, care may be taken to define the PREFIX64 option (and thus ensure that it is recognized as such by the DNS server receiving the DNS query containing this option) so that it is representative of the type of IP address expected by the client device of the DNS server queried in response to its R-AAAA query, as soon as the network resource targeted by this query has IPv4 connectivity. In other words, the DNS server queried is required to apply the type of IP address defined by the PREFIX64 option if the network resource has IPv4 connectivity, even if it has dual IPv4 and IPv6 connectivity.

[0135] Different scenarios may arise and impact the value of the information inserted by the client device T in the PREFIX64 option of the DNS query.

[0136] More precisely, if the connection interface that the client device T intends to use to access the network resource S is associated with a NAT64-ENABLED parameter valued at 1 and at least one NAT64 prefix (response "yes" to the test step E30), the client device T fills in the PREFIX64 option with the value of the NAT64 prefix or the IPv6 address associated with the connection interface and determined during the step E10 (and stored in one of the pairs (NETWORK-ID, PREFIX64) maintained by the client device T and associated with the connection interface in question) (step E40).By filling in the PREFIX64 option of the R-AAAA query in this way, the client device T indicates to the DNS server# 2 that if the network resource S has IPv4 connectivity, and that consequently the resolution of the domain name associated with this network resource S results in obtaining an IPv4 address, the client device T wishes to receive from the DNS server# 2 an IPv6 address formed by the latter from the IPv4 address of the network resource S and the NAT64 prefix filled in the PREFIX64 option, or if this option contains an IPv6 address, from the NAT64 prefix extracted from this IPv6 address, for example using the algorithm described in the RFC 6052 document mentioned above.

[0137] If, on the contrary (response "no" in test step E30), the connection interface that the client device T plans to use to access the network resource S is associated with a NAT64-ENABLED parameter set to 0, the client device T sets a predefined value in the PREFIX64 option of the R-AAAA query, namely here the null value "::ffff:0:0" (step E50). This null value indicates to the DNS server # 2 that the IP address expected in response to the R-AAAA query is an IPv4 address, in this case the IPv4 address of the resource S. The example given of a null value is provided for illustrative purposes only: alternatively, another predefined value can be considered to indicate to the DNS server # 2 that the IPv4 address of the resource S is expected in response to the R-AAAA query, provided that this predefined value is recognized as having this meaning by the DNS server # 2.

[0138] It is noted that advantageously, the client device T can also insert a null value (or more generally a predefined value) in the PREFIX64 option if, although it has determined that the connection interface that it plans to use allows access to a network that implements a NAT64 function, it wishes to form an IPv6 address itself from the IPv4 address of the resource S (it is for example equipped for this purpose with a CLAT function described previously), and does not wish to request the DNS server# 2 to form this address, or if it is informed that the DNS server# 2 does not implement a DNS64 function.

[0139] There figure 6 illustrates a first format that can be considered for the PREFIX64 option inserted by the client device in the R-AAAA request.

[0140] This format includes three fields: an “Option Code” field including a code identifying the PREFIX64 option; an “Option Length” field indicating, in bytes, the size of the data included in the PREFIX64 option. In the embodiment described here, a data size equal to 16 has a special meaning: this means that the PREFIX64 field contains an IPv6 address and not a NAT64 prefix; and a PREFIX64 field containing information representative of the type of IP address expected by the client device. In the embodiment described here, the PREFIX64 field may contain a NAT64 prefix, an IPv6 address or the null value (i.e., the value “::ffff:0:0”).

[0141] There figure 7 represents a second format that can be considered for the PREFIX64 option, and allows for the inclusion of one or more NAT64 prefixes (or IP addresses from which to extract NAT64 prefixes). The size of each prefix is ​​governed by the "Prefix Length" field; if this field is set to 16, this means that the associated PREFIX64 field contains an IPv6 address and not a prefix. The "Option Length" field corresponds to the sum of the lengths of the different prefixes provided in the PREFIX64 option.

[0142] Of course, these format examples are given for illustrative purposes only and other information may be included in the PREFIX64 option.

[0143] Note that when the value of the PREFIX64 field includes a NAT64 prefix or an IPv6 address allowing such a NAT64 prefix to be extracted, it must be the NAT64 prefix used, if applicable, by the IP network associated with the connection interface that the client device T plans to use to access the network resource S (i.e. to send and / or receive data from this network resource). If the client device T plans to use all its active connection interfaces and distinct NAT64 prefixes have been discovered for these different connection interfaces during step E10, the client device T includes several PREFIX64 options in the R-AAAA request which each contain a NAT64 prefix, for example by using the option format proposed in figure 7 . In an alternative embodiment, the client device T may send multiple DNS queries to the DNS server# 2, each containing a PREFIX64 option identifying a distinct NAT64 prefix.

[0144] It is further noted that a client device T that has multiple active connection interfaces, in other words a multi-interface client device, may choose any of its active connection interfaces for sending an AAAA request carrying a PREFIX64 option. For example, the terminal may send the AAAA request via the same network that supports the NAT64 service associated with the NAT64 prefix(es) included in the AAAA request or via a different network.

[0145] After inserting the PREFIX64 option in the R-AAAA DNS query, the client device T sends the R-AAAA query to the DNS server# 2 via one of its active connection interfaces (step E70).

[0146] In another embodiment, the PREFIX64 option is defined to be generally representative of the type of IP address expected by the client device from the DNS server in response to its R-AAAA query when the network resource has at least IPv4 connectivity, and the client device T inserts into its R-AAAA DNS query, in addition to the PREFIX64 option and before sending it to the DNS server#2, an additional instruction to indicate to the DNS server#2, when the PREFIX64 option contains an IPv6 prefix or an IPv6 address comprising such a prefix, whether it should generate an address according to the IPv6 format from this prefix and the IPv4 address of the resource only if the network resource has only IPv4 connectivity, or if the network resource has IPv4 connectivity regardless of whether it also has IPv6 connectivity.This instruction can be included in an optional parameter of the R-AAAA DNS query (for example in a field of the PREFIX64 option shown for illustration purposes on the . figures 6 et 7 , which can be called "Scheme ID"), intended to communicate to the DNS server indications relating to the method that the DNS server must use to form "fictitious" IPv6 addresses from the IPv4 addresses of the network resources for which it is queried. If we designate this optional parameter by "Scheme ID", we can for example define the following values ​​for this parameter: A value of 0 indicates that the DNS server should generate dummy IPv6 addresses only if the network resource has IPv4 connectivity only; and a value of 1 indicates that the DNS server should generate dummy IPv6 addresses if the network resource has IPv4 connectivity, even if it also has IPv6 connectivity.

[0147] Note that other values ​​can be defined for the Scheme ID parameter to transmit other types of instructions to the DNS server regarding the method of forming fictitious IPv6 addresses. For example: The value 2 may indicate that the DNS server should use to form fictitious IPv6 addresses from IPv4 addresses and according to the algorithm defined in section 2.3 of RFC 6052; the value 3 may indicate that the DNS server should use the WKP prefix to form fictitious IPv6 addresses from IPv4 addresses; the value 4 may indicate that the DNS server should use a suffix that guarantees the neutrality of the transport layer pseudo header checksum; and the value 5 may indicate that the DNS server should return IPv4 addresses associated with the target resource in the additional section.

[0148] These examples are for illustrative purposes only and it is possible to envisage that the client device transmits other instructions to the DNS server via other values ​​of the "Scheme ID" parameter. Alternatively, other instructions may be transmitted by the client device to the DNS server via other media, such as other parameters of the R-AAAA query.

[0149] We will now describe, with reference to the figure 8 , how the DNS requests of type AAAA sent by the client device T, and in particular the R-AAAA request, are processed by the DNS server# 2, or more generally by the DNS servers conforming to the invention.

[0150] Upon receipt of a DNS query of type AAAA via its reception module M4 (step F10), the DNS server# 22 checks, using its detection module M5, whether this query contains a PREFIX64 option (test step F20).

[0151] If the detection module M5 does not detect a PREFIX64 option (response "no" to test step F20), it processes and resolves the received AAAA type DNS query in a conventional manner, as in the prior art (step F30). The mechanism implemented for this resolution is for example described in the IETF documents RFC 1034 and RFC 1035, entitled respectively "Domain names - concept and facilities" and "Domain names - implementation and specification", November 1987.

[0152] More specifically, the DNS server # 22 determines, by means of its M6 module, the IPv6 address of the network resource S. This IP address is noted in the sequence @IP(S).

[0153] If DNS server #2 is the authoritative DNS server for resource S, and if resource S has IPv6 connectivity, DNS server #2 has the IPv6 address of resource S locally, and responds positively to client device T by transmitting this IPv6 address. If it is not the authoritative DNS server for resource S but is a recursive DNS server, DNS server #2 sends a DNS query of type AAAA to the authoritative DNS server (or another recursive DNS server) to obtain the IPv6 address of resource S. If resource S has IPv6 connectivity, a positive response is returned to DNS server #2 containing the IPv6 address of resource S. DNS server #2 then responds positively to client device T by transmitting this IPv6 address in its response to the R-AAAA query.Otherwise a negative response is returned to DNS server#2 which in turn responds negatively to the DNS AAAA query received from client device T.

[0154] In the example envisaged here, the DNS server# 2 receives during step F10 the R-AAAA query concerning the network resource S, and in which the client device T has inserted a PREFIX64 option representative of the type of IP address that it expects in response to its DNS query if the network resource S has IPv4 connectivity (and only such connectivity in the embodiment described here). The detection module M5 detects during step F20 the presence of the PREFIX64 option inserted by the client device T in the R-AAAA query (response “yes” to the test step F20).

[0155] It extracts the value entered by the client device T in the PREFIX64 field of the detected option (step F40).

[0156] Then it determines, by means of its obtaining module M6, the IP address @IP(S) of the network resource S (step F50). As described previously for step F30, if the DNS server # 2 is the authoritative server for the resource S, it locally has the IP address or IP addresses of the latter, whether IPv4 address(es) or IPv6 address(es) or both types of addresses. Otherwise, it obtains the IP address of the resource S recursively by querying the authoritative DNS server of the resource S.

[0157] More precisely, it sends a DNS query of type AAAA to the authoritative DNS server (directly or via an intermediate recursive DNS server) aiming to obtain an IPv6 address for the resource S. If the resource S has IPv6 connectivity, a positive response is then returned by the authoritative DNS server to the DNS server# 2 containing the IPv6 address of the resource S noted @IPv6(S).

[0158] Otherwise, a negative response is returned to DNS server # 2. In this case, in the embodiment described here, DNS server # 2 sends a type A DNS query to the authoritative DNS server (or another intermediate recursive DNS server) to obtain the IPv4 address of resource S. It then receives a positive response from the authoritative DNS server containing the IPv4 address of resource S denoted @IPv4(S).

[0159] Note that DNS server # 2 can alternatively issue both DNS queries of type A and AAAA simultaneously to the authoritative DNS server to anticipate in particular the non-support of IPv6 connectivity by network resource S. The response to the type A query is then only used by DNS server # 2 if the response to the type AAAA query is negative.

[0160] In yet another variant, if the PREFIX64 option is defined so that it is taken into account even when the network resource S has dual connectivity or when the DNS query R-AAAA includes an instruction to this effect (for example a Scheme ID parameter as mentioned previously, set to 1), the DNS server# 2 can issue the two DNS queries of type A and AAAA simultaneously or sequentially to the authoritative DNS server to determine whether the resource S has dual IPv4 and IPv6 connectivity.

[0161] If the @IP(S) address thus determined by the DNS server# 2 is an @IPv6(S) address compliant with the IPv6 protocol (response "yes" to test step F60), the DNS server# 2 responds positively to the R-AAAA query from the client device T by sending it the @IPv6(S) address (step F70). In other words, the @IPv6(S) address is sent to the client device T in the response to the R-AAAA query, this response bearing the type AAAA in accordance with the procedure described in section 2.3 of the RFC 3596 document cited above.

[0162] Otherwise, it means that network resource S only has IPv4 connectivity, and does not have IPv6 connectivity.

[0163] DNS server# 2 then examines the value extracted from the PREFIX64 option inserted into the R-AAAA query by the client device T (step F80).

[0164] If the extracted value is equal to "::ffff:0:0" (in other words to the prefix defining the null value) (branch (1) at the output of step F80), this means that the client device T wishes to receive the @IPv4(S) address of the network resource S conforming to the IPv4 protocol (i.e. according to the IPv4 format and not embedded in an IPv6 address for example), to proceed itself to the formation of an IPv6 address from this IPv4 address, for example by using a CLAT function as mentioned previously.

[0165] DNS server # 2 then responds to the R-AAAA query from client device T, via its sending module M7, by sending it the @IPv4(S) address of network resource S (step F90). In other words, the @IPv4(S) address is sent to client device T in the DNS response to the R-AAAA query, this response having the AAAA type as described in the previously cited RFC3596 document. The @IPv4(S) address can be included in the DNS response in the Additional Section (described in particular in section 3.7 of RFC 1034) of the DNS response (the address is then encoded as is, in its original IPv4 format) or in the body of the response.Note that if the response body is chosen to transmit the @IPv4(S) address to the client device T, the @IPv4(S) address is encoded as an IPv6 address constructed for example using the well-known prefix "::ffff:0:0 / 96" (also called an "IPv4-mapped" IPv6 address and described in RFC 4291). Alternatively, other formats may be considered for encoding the @IPv4(S) address.

[0166] It should be noted that it is equivalent for the client device T, if it wishes to obtain the IPv4 address of the network resource S when the latter benefits from IPv4 connectivity, to transmit in its DNS request a PREFIX64 option valued with the known prefix “::ffff:0:0 / 96” and a PREFIX64 option valued with the null value.

[0167] Thus, for illustration purposes, if the address @IPv4(S)= “198.51.100.1” and the PREFIX64 option inserted in the DNS query R-AAAA has the null value “::ffff:0:0”, the DNS server# 2 can send to the client device T a response to its DNS query containing, in the body of the DNS response, the address @IP(S)=“::ffff:0:0:198.51.100.1” containing the address @IPv4(S).

[0168] If the value extracted from the PREFIX 64 option contains a non-zero IPv6 address (branch (2) at the output of step F80), the DNS server# 2 executes the algorithm described in the RFC 6052 document to extract the NAT64 prefix from which this IPv6 address was formed (step F100). Then it uses the NAT64 prefix thus extracted to form an IPv6 address for the network resource S from its @IPv4(S) address (step F110). It then responds to the R-AAAA query from the client device T by sending it, via its sending module M7, the @IPv6(S) address thus formed for the network resource S (step F120). Note that a classic DNS response to a DNS AAAA query can be used for this purpose.

[0169] If the value extracted from the PREFIX 64 option contains a NAT64 prefix (branch (3) at the output of step F80), DNS server# 2 directly executes steps F110 and F120 without implementing step F100.

[0170] DNS server #2 forms the @IPv6 address for network resource S from its @IPv4(S) address, taking into account any instructions transmitted by client device T regarding the IPv6 address formation method to be applied. Such instructions may be transmitted, as previously mentioned, in the R-AAAA DNS query via a parameter defined for this purpose, such as the Scheme ID parameter described above. If no instructions are defined by client device T in the DNS query, DNS server #2 may apply a default configured IPv6 address formation method (e.g., execution of the algorithm defined in RFC 6052, and only if there are no AAAA records).

[0171] Furthermore, if we consider an embodiment in which the DNS server #2 is configured to apply the type of IP address contained in the PREFIX64 option as soon as the resource S has at least IPv4 connectivity, the response from the DNS server #2 to the client device T may contain several IP addresses if the network resource S has dual IPv4 and IPv6 connectivity. It is recalled that the configuration of the DNS server #2 may result from the very definition of the PREFIX64 option or from an instruction of the client device T inserted in the DNS query R-AAAA as mentioned previously (for example in the Scheme ID parameter).The plurality of IP addresses then obtained by the DNS server# 2 (which then includes at least one IPv4 address and one IPv6 address of the resource) can all be inserted into the body of the response (according to the IPv6 format, including the fictitious IPv6 addresses constructed from the IPv4 addresses), or all inserted into the additional section of the DNS response (the IPv4 addresses as such can then be encoded according to the IPv4 format), or be inserted into the addresses encoded according to the IPv6 format in the body of the response and for the others in the additional section of the DNS response.

[0172] Note that depending on the connection interface used by the client device T to access the network resource S, the IP address (or IP addresses) returned by the DNS server# 2 to the client device T in response to its AAAA query may differ. Thus, two client devices T1 and T2 sending DNS queries of type AAAA to the DNS server# 2 targeting a network resource “myT3.name.example” which only has IPv4 connectivity (@IPv4(S)= “198.51.100.1”, and each including a PREFIX64 option set respectively to “2001:db8:1234:: / 96” for T1 and to “64:ff9b:: / 96” for T2, will receive from the DNS server# 2: for client device T1: a DNS response including the IPv6 address “2001:db8:1234::198.51.100.1”; and for client device T2: a DNS response including the IPv6 address “64:ff9b::198.51.100.1”. Thus, the IPv6 addresses returned by DNS server # 2 to client devices T1 and T2 for the same network resource are not necessarily identical. From these IPv6 addresses, client devices T1 and T2 can establish communications with network resource S, each of these communications passing through the NAT64 function of the IP network to which each client device is connected, that is to say through the NAT64 function configured with the prefix “2001:db8:1234:: / 96” for T1 and through the NAT64 function configured with the prefix “64:ff9b:: / 96” for T2.

[0173] Referring again to the figure 5 , upon receipt of the DNS response from DNS server # 2 to its R-AAAA query (step E70), the client device T extracts the IP address @IP(S) provided in the response for the network resource S, in order to use it to access the resource S (step E80).

[0174] If the client device T had included in its R-AAAA query a null or predefined value in the PREFIX64 option, it uses the @IP(S) address returned by the DNS server# 2 to locally construct a fictitious IPv6 address of the “IPv4-converted IPv6” type for the network resource S, based on a local NAT64 prefix with which it was previously configured. This NAT64 prefix is ​​the one discovered in step E10 by the client device T for the IP network that it plans to use to access the resource S. Then the client device T uses the fictitious IPv6 address that it has constructed locally as the destination address of the packets sent to the network resource S.

[0175] Otherwise, client device T uses the @IPv6(S) address returned by DNS server# 2 as is as the destination address of packets sent to network resource S.

[0176] Note that a multi-interface client device T must select the connection interface to use to send data packets to the network resource S based on the IP address returned by the DNS server# 2. Indeed, if the client device T has several {NETWORK-ID, PREFIX64} pairs, then the client device T selects the NETWORK-ID connection interface whose NAT64 prefix corresponds to the first bits of the IPv6 address returned by the DNS server# 2. For example, if the client device T has two connection interfaces {NETWORK-ID=WLAN, PREFIX64= 2001 :db8:1234 / 96} and {NETWORK-ID= RMNET, PREFIX64=64:ff9b:: / 96} , the connection interface to use to send data to an address “64:ff9b::1.2.3.4” returned by the server DNS# 2 is the RMNET connection interface.

[0177] Furthermore, if multiple NAT64 prefixes are provided in the R-AAAA query by client device T to DNS server # 2 corresponding to distinct connection interfaces of client device T (e.g., prefix “2001:db8:1234 / 96” for network NW1 and prefix “64:ff9b:: / 96” for network NW2), DNS server # 2 transmits as many IPv6 addresses as prefixes in response to client device T (in the example considered, one address “2001:db8:1234::198.51.100.1” and one address “64:ff9b::198.51.100.1”). The client device T must then use the IPv6 address corresponding to the prefix associated with the chosen connection interface to send packets to the network resource, in other words the destination address “2001:db8:1234::198.51.100.1” for packets sent via the NW1 network and the address “64:ff9b::198.51.100.1” for packets sent via the NW2 network.

[0178] Selecting the wrong connection interface can have implications for quality of experience. Choosing which prefix(es) to communicate to the DNS server allows client devices to control how communication will be established to a remote network resource.

[0179] For illustration purposes, with reference to the example of la figure 9 , If the PREFIX64 option contains the prefix "2001:db8:1234 / 96", then the data must be exchanged via the NW1 network. Note that any data packet with the destination address "2001:db8:1234::198.51.100.1" but transmitted via the NW2 network is rerouted to the NW1 network (because this network advertises the prefix "2001:db:: / 32") and risks being rejected by this network because the NAT64 service is not provided on the interface visible from the Internet.

[0180] Referring to the example of the figure 10, if the DNS response contains the prefix "64:ff9b:: / 96", then the data must be exchanged via the NW2 network. Any data packet with the destination address "64:ff9b::198.51.100.1" and transmitted via the NW1 network is rejected by the NW1 network because this network does not have a route (for example, a BGP (Border Gateway Protocol) route) to route the packet.

[0181] In the embodiment described above, the PREFIX64 option is inserted by the client device T in its R-AAAA request. In another embodiment in which the client device T communicates with the IP networks via a CPE, the PREFIX64 option can be inserted by the CPE. The obtaining method according to the invention is then implemented by the CPE (which is then considered to be a client device within the meaning of the invention). More specifically, if the CPE detects the presence of a NAT64 function in an IP network, then upon receipt of a DNS AAAA request from a device in the local network to which the CPE is connected, the CPE modifies the request to include a PREFIX64 option according to the methods just described.

[0182] Furthermore, in the embodiment described, it is the alternative DNS server DNS# 2 which implements the processing method according to the invention. It should be noted that the invention also applies to nominal DNS servers, since the client device T is configured to address its DNS requests to these nominal DNS servers.

Claims

1. Method for a client device (T) to obtain an IP address in order to access a network resource (S) via at least one network (NW1, NW2) providing an IP (Internet Protocol) connectivity service to said client device, said client device having only IPv6 connectivity, said method comprising: - a step of insertion (E60), into a request (R-AAAA), to obtain an IPv6 address in order to access said network resource, intended for a DNS server, of a piece of information representative of a type of IP address expected by said client device from said DNS server in response to said obtaining request if said network resource has IPv4 connectivity, said expected IP address type being able to be an IPv4 address, from which said client device (T) can form an IPv6 address, or a fake IPv6 address; and - a step of sending (E70) said obtaining request to said DNS server.

2. Method according to Claim 1, wherein said piece of information inserted into the obtaining request comprises at least one IPv6 prefix or at least one IPv6 address comprising at least one IPv6 prefix, if said expected IP address type is an IPv6 address formed by the DNS server from said at least one IPv6 prefix and an IPv4 address of said network resource (S).

3. Obtaining method according to Claim 2, wherein said at least one IPv6 prefix is at least one IPv6 prefix used by a function for converting IPv4 packets into IPv6 packets implemented by said network.

4. Obtaining method according to Claim 2 or Claim 3, wherein the obtaining request further comprises: - an instruction to form said IPv6 address only if the network resource has only IPv4 connectivity; or - an instruction to form said IPv6 address if the network resource has IPv4 connectivity even if it also has IPv6 connectivity.

5. Obtaining method according to Claim 1, wherein said piece of information inserted into the obtaining request is a predefined value, known to the DNS server, if said expected IP address type is an IPv4 address of said network resource.

6. Obtaining method according to any one of Claims 1 to 5, wherein the obtaining request further comprises: - an instruction to execute a determined algorithm to form an IPv6 address from an IPv4 address of the network resource; and / or - an instruction to use a WKP (Well-Known Prefix) prefix to form an IPv6 address from an IPv4 address of the network resource; and / or - an instruction to use a suffix which guarantees neutrality of a mechanism for checking integrity of a pseudo-header of a transport layer; and / or - an instruction to insert an IPv4 address into an additional section of a response to the obtaining request.

7. Obtaining method according to any one of Claims 1 to 6, further comprising a step of determining (E10) whether said network implements a function for converting IPv4 packets into IPv6 packets.

8. Obtaining method according to Claim 7, further comprising, if said network implements a function for converting IPv4 packets into IPv6 packets, a step of obtaining at least one IPv6 prefix used by said packet conversion function.

9. Obtaining method according to Claim 7 or 8, wherein: - the DNS server is a server distinct from a so-called "nominal" DNS server with which the client device has been configured by an operator of the network; - the determination step comprises a step of sending, to the nominal DNS server, a request to obtain an IPv6 address in order to access a given network resource known to have only IPv4 connectivity; and - if a positive response is received from the nominal DNS server comprising an IPv6 address for said given network resource, the client device determines that the network implements a function for converting IPv4 packets into IPv6 packets.

10. Obtaining method according to Claim 9, comprising a step of obtaining an IPv6 prefix used by said function for converting IPv4 packets into IPv6 packets from the IPv6 address contained in the positive response received from the nominal DNS server.

11. Processing method, by a DNS server (DNS#2) associated with a network supplying an IP connectivity service to at least one client device (T) having only IPv6 connectivity, said method comprising: - a step of reception (F10), from said client device (T), of a request to obtain an IPv6 address in order to access a network resource, and in which a piece of information is inserted which is representative of a type of IP address expected by said client device from said DNS server in response to said obtaining request if said network resource has IPv4 connectivity, said expected IP address type being able to be an IPv4 address or a fake IPv6 address; - if said network resource has IPv4 connectivity: a step of obtaining (F50) an IPv4 address of said network resource; and a step of sending (F90, F110) a response to said obtaining request containing at least one IP address determined by the DNS server from said IPv4 address obtained and corresponding to the type of IP address expected by the client device.

12. Processing method according to Claim 11, wherein said piece of information inserted into the obtaining request comprises at least one IPv6 prefix or at least one IPv6 address comprising at least one IPv6 prefix and said at least one IP address determined by the DNS server comprises at least one IPv6 address formed by the DNS server from said at least one IPv6 prefix and from said IPv4 address of the network resource obtained.

13. Processing method according to Claim 11, wherein said piece of information inserted into the obtaining request has a predefined value known to the DNS server, and said at least one IP address determined by the DNS server is the IPv4 address of the network resource obtained.

14. Processing method according to Claim 13, wherein said IPv4 address is sent by the DNS server to the client device in the body of the response, coded according to the IPv6 format by using the prefix "::ffff:0:0 / 96".

15. Processing method according to any one of Claims 11 to 14, wherein the sending step and the obtaining step are implemented by the DNS server only if the network resource has only IPv4 connectivity.

16. Client device (T) connected to at least one network supplying an IP connectivity service to the client device, said client device having only IPv6 connectivity and comprising: - an insertion module (M1), configured to insert, into a request to obtain an IPv6 address in order to access a network resource via said network, intended for a DNS server, a piece of information representative of a type of IP address expected by said client device from said DNS server in response to said obtaining request if said network resource has IPv4 connectivity, said expected IP address type being able to be an IPv4 address, from which said client device (T) can form an IPv6 address, or a fake IPv6 address; and - a sending module (M2), configured to send said obtaining request to the DNS server.

17. Client device according to Claim 16, further comprising a module for translating IPv4 addresses into IPv6 addresses activated on reception of a response from the DNS server to said obtaining request comprising an IPv4 address of said network resource, said translation module being configured to translate said IPv4 address into an IPv6 address by using said IPv4 address and an IPv6 prefix used by a function for converting IPv4 packets into IPv6 packets implemented by the network.

18. DNS server (DNS#2) comprising: - a reception module (M4), capable of receiving, from a client device connected to a network supplying an IP connectivity service to said client device, a request to obtain an IPv6 address in order to access a network resource via said network, said client device having only IPv6 connectivity; - a detection module (M5), configured to detect, in said request, a piece of information representative of a type of IP address expected by said client device from said DNS server in response to said obtaining request if said network resource has IPv4 connectivity, said expected IP address type being able to be an IPv4 address or a fake IPv6 address; - modules, activated if said network resource has IPv4 connectivity, and comprising: * an obtaining module (M6) configured to obtain an IPv4 address of the network resource; and * a sending module (M7), configured to send a response to said obtaining request containing at least one IP address in order to access said network resource determined by the DNS server from said IPv4 address obtained and corresponding to the type of IP address expected by the client device indicated by said piece of information inserted into said obtaining request.

19. Communication system (1) comprising: - at least one client device (T) according to Claim 16 or 17 connected to at least one network supplying an IP connectivity service to said client device, said client device having only IPv6 connectivity; and - at least one DNS server (DNS#22) according to Claim 18, intended to be used by the client device to access a network resource via said network.

20. System (1) according to Claim 19, wherein said DNS server is a public DNS server (DNS#2) distinct from a so-called nominal DNS server (DNS#11, DNS#21) with which the client device has been configured by an operator of said network.