US20140344417A1 - Facilitating content accessibility via different communication formats - Google Patents

Abstract

Methods and systems for facilitating content accessibility via different communication formats are provided. According to one embodiment, a method is provided for directing content requests to an appropriate content delivery network. A content request is received from a client. The content request relates to web page content published by a content publisher in an Internet Protocol version 4 (IPv4) format or an Internet Protocol version 6 (IPv6) format that is obtained by the content delivery network from the content publisher and is translated to the other format by the content delivery network prior to receiving any content requests for the web page content. A communication format through which the client is capable of communicating is determined. The content request is directed to a content delivery network that supports the communication format through which the client is capable of communicating.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 13/194,826 filed on Jul. 29, 2011, which is hereby incorporated by reference in its entirety for all purposes.
COPYRIGHT NOTICE
• Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright © 2011-2014, Fortinet, Inc.
BACKGROUND
• 1. Field
• Embodiments of the present invention generally relate to facilitating content accessibility via different communication formats. In particular, embodiments of the present invention relate to proactively translating content originally received from an IPv4 enabled server in IPv4 format to an IPv6 format to facilitate accessibility via IPv6.
• 2. Description of the Related Art
• Despite the commencement of a shift towards IPv6 (Internet Protocol version 6), many Internet resources are still only accessible via IPv4 (Internet Protocol version 4) due to the complexity and expense of transitioning to IPv6.
SUMMARY
• Methods and systems are described for facilitating content accessibility via different communication formats. According to one embodiment, a method is provided for directing content requests to an appropriate content delivery network. A content request is received from a client. The content request relates to web page content published by a content publisher in an Internet Protocol version 4 (IPv4) format or an Internet Protocol version 6 (IPv6) format that is obtained by the content delivery network from the content publisher and is translated to the other format by the content delivery network prior to receiving any content requests for the web page content. A communication format through which the client is capable of communicating is determined. The content request is directed to a content delivery network that supports the communication format through which the client is capable of communicating.
• Other features of embodiments of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
• Embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
• FIG. 1 is a block diagram illustrating an example of native IPv6 traffic communications between an IPv6 enabled client and server.
• FIG. 2 is a block diagram illustrating an example of IPv6 communications via an IPv6 tunnel over an IPv4 backbone.
• FIG. 3 is a block diagram illustrating an embodiment of a network environment in which clients are intelligently directed to servers capable of servicing client requests.
• FIG. 4 is a flow chart illustrating an embodiment of a process for directing a client.
• FIG. 5 is a block diagram illustrating an embodiment of a network environment in which a proxy server is employed to translate content from a first format into a second format.
• FIG. 6 is a flow chart illustrating an embodiment of a process for translating IPv4 content into IPv6 content.
DETAILED DESCRIPTION
• Methods and systems are described for facilitating content accessibility via different communication formats. Embodiments of the present invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
• A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims, and the invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example, and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
• As the long-anticipated address exhaustion of IPv4 (Internet Protocol version 4) becomes imminent, mechanisms to transition to IPv6 (Internet Protocol version 6) have become increasingly prevalent. Although many networking devices are now dual stack and support both IPv4 and IPv6, most existing ISP (Internet Service Provider) networks still only support native IPv4 connectivity. As a result, a very small percentage of existing Internet traffic comprises solely native IPv6 traffic. Rather, a significant portion of existing IPv6 traffic employs a tunneling mechanism to carry IPv6 traffic over an IPv4 network.
• FIG. 1 is a block diagram illustrating an example of native IPv6 traffic communications between an IPv6 enabled client and server. As depicted, a request from IPv6 enabledclient102 is received by IPv6 enabledserver104 viaIPv6 network106, and a response to the request from IPv6 enabledserver104 is received by IPv6 enabledclient102 viaIPv6 network106. The communications betweenclient102 andserver104 are facilitated by one or more ISPs that are natively connected toIPv6 backbone106. Although described as IPv6 enabled,client102 andserver104 may also be enabled to communicate via one or more other protocol stacks such as IPv4. Similar communications as those described with respect toFIG. 1 occur with respect to native communications using other protocol stacks such as IPv4.
• In contrast,FIG. 2 is a block diagram illustrating an example of IPv6 communications via an IPv6 tunnel over an IPv4 backbone. Tunneling effectively facilitates encapsulation of IPv6 packets within IPv4 so that existing IPv4 infrastructure may be employed to carry IPv6 packets to reach an IPv6 network. In the given example,dual stack client202 is IPv6 capable but limited, for example, by an associated ISP, to IPv4 network connectivity.Client202 employs a tunnel broker service that enables connectivity toIPv6 network204 via atunnel206 overIPv4 network208. Specifically, a request to an IPv6 destination fromclient202 is tunneled206 overIPv4 network208 to adual stack router210 of the tunnel broker service, which provides connectivity toIPv6 network204 and which directs the request fromclient202 viaIPv6 network204 toIPv6 server212. A response to the request fromIPv6 server212 is received viaIPv6 network204 bydual stack router210 and directed viatunneling206 overIPv4 network208 toclient202.
• In many cases, IPv6 tunneling over an IPv4 network introduces performance degradations, for example, due to the latency inherent in the extra transmissions as well as performance limitations imposed by tunnel broker service gateways (e.g.,router210 ofFIG. 2) that facilitate communications with an IPv6 network. Due to the poor performance typically resulting from such tunneling techniques, IPv6 has yet to receive more widespread deployment. Despite the performance limitations, many Internet resources (e.g., websites) have nevertheless become IPv6 enabled, for example, due in part to a desire to be at the forefront of migration to IPv6. As a result, many domain names are accessible via both IPv4 and IPv6 addresses. In DNS (Domain Name System), domain names are mapped to an IPv4 address using an A record and to an IPv6 address using an AAAA (quad A) record. In some cases, default and/or user configurations of client hardware and/or software have resulted in domain names being automatically resolved into IPv6 addresses, if available, regardless of whether native IPv6 network connectivity exists at the client. Such indiscriminate use of IPv6 has in many cases detrimentally impacted end user experience, especially for clients that are not natively connected to an IPv6 network.
• Techniques for more intelligently routing or directing traffic based on expected performance are disclosed herein. Although dual stack devices capable of communicating using IPv4 and/or IPv6 are described in some of the given examples, the techniques disclosed herein may be employed with respect to any device capable of communicating using any one or more protocol stacks or communication formats.
• FIG. 3 is a block diagram illustrating an embodiment of a network environment in which clients are intelligently directed to servers capable of servicing client requests. The various components comprisingnetwork environment300 communicate via one or more private and/or public networks using any appropriate communication protocols and comprise devices that are capable of communicating using any one or more communication formats. For instance, one or more of components302-306 may comprise dual stack devices that are enabled for both the IPv4 and IPv6 protocol stacks. Such a dual stack device may be configured, for example, to automatically communicate via IPv4 or IPv6 depending on whether the IP address of a destination device comprises an IPv4 or IPv6 address. Although components may be depicted as single blocks in the accompanying figures, in various embodiments, a block may comprise any number of interconnected physical and/or logical components. For instance, in some embodiments,traffic manager302 comprises a plurality of networked devices located in different geographical regions.
• Traffic innetwork environment300 is managed bytraffic manager302. In some embodiments,traffic manager302 comprises a redirection node or host configured to direct aclient304 to anappropriate server306 capable of servicing a client request.Traffic manager302 may be employed by a publisher to manage client requests for content published by the publisher. In such cases, client requests for content published by the publisher may be directed or redirected totraffic manager302, for example, via a CNAME (Canonical Name) record of DNS.Traffic manager302, in turn, redirectsclients304 toappropriate servers306 to service client requests. For example,traffic manager302 may redirect a client in a manner that strives to optimize performance in servicing the client request and/or according to a traffic management policy specified by an associated publisher whose content is being requested. In some embodiments,traffic manager302 is natively connected to a plurality of networks and/or capable of communicating via a plurality of communication formats such as IPv4 and IPv6. Although described as a centralized, web-based service with respect to the example ofFIG. 3, the functionality described herein as being performed bytraffic manager302 may in other embodiments be implemented as a host-based solution, for example, onservers306.
• Server306(a) and server306(b) are configured to serve content. For example, server306(a) and server306(b) may be configured to serve content published by a publisher. In such cases, servers306(a) and306(b) may belong to the publisher (e.g., the servers may comprise publisher origin servers), a content delivery network (CDN) contracted by the publisher, or another third party entity employed to serve content on behalf of the publisher. Each of servers306(a) and306(b) is configured to communicate via a prescribed communication format. In the given example, server306(a) is configured to communicate via IPv4 while server306(b) is configured to communicate via IPv6. Although depicted inFIG. 3 as separate blocks or devices, in other embodiments, servers306(a) and306(b) may comprise a single device, such as a dual stack device configured to communicate natively with both IPv4 and IPv6 networks.
• In some embodiments,traffic manager302 takes into consideration the communication format that gives a client the best expected performance when making a redirection decision. In some cases, for example, better performance may be expected by redirecting a client to a server connected to a network to which the client is natively connected. For instance, better performance may be expected by redirecting a native IPv4 client304(a) to a native IPv4 server306(a) and similarly a native IPv6 client304(b) to a native IPv6 server306(b) to avoid the performance degradations inherent in tunneling communications over otherwise incompatible networks. In some embodiments,traffic manager302 is configured to determine whether a communication received from a client has been tunneled using a tunneling service. A tunneled communication may be identified, for example, by comparing a source IP address of the communication with a list or database of known IP addresses associated with tunneling services. In some embodiments, a client identified bytraffic manager302 to be using a tunneling service may be redirected bytraffic manager302 to a server connected to a network to which the client has native connectivity so that further tunneling can be avoided.
• As an example, consider a dual stack client304(a) natively connected to only an IPv4 network but configured to communicate via IPv6 whenever an IPv6 destination is available, e.g., whenever a destination domain name is resolvable into an IPv6 address. In this example, client304(a) connects to an IPv6 destination using a tunneling service that directs IPv6 communications to and from client304(a) via an IPv6 tunnel over an IPv4 network and via a dual stack router of the tunneling service that is natively connected to both IPv4 and IPv6 networks as described above with respect toFIG. 2. An IPv6 communication from client304(a) is received bytraffic manager302 via a native IPv6 network. The source IPv6 address of such a communication from the client, however, comprises the IPv6 address of the tunneling service router. By comparing the source IP address of a received communication from client304(a) against a list of known IP addresses of tunneling service routers,traffic manager302 is able to deduce the use of a tunneling service and that client304(a) does not have native connectivity to an IPv6 network. If the performance of tunneled communications is expected to be inferior to communications over a native network,traffic manager302 may choose to redirect client304(a) to IPv4 server306(a) so that further tunneling can be avoided. In some such cases, a redirect response fromtraffic manager302 to client304(a) may be tunneled, but subsequent request and response communications between client304(a) and server306(a) occur over a native network of both devices. A similar decision bytraffic manager302 to prevent further tunneling may arise in the inverse scenario. For example, a client304(b) natively connected to only an IPv6 network and communicating with IPv4 using a tunneling service that directs IPv4 communications to and from client304(b) via an IPv4 tunnel over an IPv6 network and via a dual stack router of the tunneling service that is natively connected to both IPv6 and IPv4 networks may be redirected bytraffic manager302 to IPv6 server306(b) so that tunneling can be avoided during client-server communications.
• In some embodiments, a determination bytraffic manager302 of the manner in which to redirect aclient304 is generally based on optimizing expected performance. Although in some cases avoiding tunneling may be expected to optimize performance, tunneling may offer improved performance in some scenarios. For example, tunneling may be expected to provide improved performance when a native network is experiencing outages or is congested, or, for instance, if the nodes involved in tunneled communications are all geographically located in closer proximity than the nodes involved in corresponding native communications. Thus, if tunneled communications are expected to result in improved performance,traffic manager302 may redirect a client to a server that entails tunneled communications between the two devices. For example, IPv4 client304(a) may be redirected bytraffic manager302 to IPv6 server306(b) and likewise an IPv6 client304(b) may be redirected bytraffic manager302 to IPv4 server306(a).
• In various embodiments,traffic manager302 may facilitate and/or mediate client-server communications with respect to any communication protocols such as HTTP (Hypertext Transfer Protocol), SSL (Secure Sockets Layer), FTP (File Transfer Protocol), RTMP (Real Time Messaging Protocol), RTMP-E (Encrypted Real Time Messaging Protocol), RTMP over HTTP, torrent style protocols, DNS protocols, etc. In some embodiments,traffic manager302 is at least in part configured with DNS functionality. For example,traffic manager302 may be employed to resolve or aid in resolving DNS requests fromclients304. In some such cases, an expected optimal protocol stack for communication may be selected bytraffic manager302 for aclient304 at the DNS level, andtraffic manager302 may accordingly respond to a DNS request from aclient304 with an appropriate DNS response such as an A record or an AAAA record for IPv4 and IPv6, respectively.
• Most existing network devices are dual stack and capable of communicating via both IPv4 and IPv6. However, all devices may not be dual stack in the future once migration to IPv6 is complete. In such cases, any appropriate techniques to determine whether a device is dual stack may be employed. Such techniques may generally be employed to determine whether a device supports any one or more communication formats. In some embodiments, test content accessible only via a prescribed communication format is embedded in a resource such as a web page accessed by a client to determine whether the client is capable of accessing the test content and thus to deduce whether the client is capable of communicating using the prescribed communication format. For example, IPv4 and/or IPv6 test content may be embedded into a web page accessed by a client to determine whether the client is capable of communicating via IPv4, IPv6, or both. The results of such tests may be stored in one or more browser cookies at the client so that the tests do not have to be repeatedly performed for the same client at least until the cookies expire. A client is intelligently redirected to an appropriate server based on the communication format or protocol stack via which it is capable of most efficiently communicating.
• In some embodiments, various types of information may be learned and/or stored bytraffic manager302. For example, lists of known or determined native IP (e.g., IPv4 and IPv6) addresses may be maintained in databases. Such databases of native IP addresses may be employed, for example, when determining whether client communications comprise native or tunneled communications. In some cases, client information such as IP addresses and compatible protocol stacks may be learned and stored for future use so that such information does not have to be repeatedly determined for a particular client and may only periodically be re-checked for changes. In various embodiments, any other appropriate metrics may be tracked and later used for making more dynamic and granular redirection decisions.
• FIG. 4 is a flow chart illustrating an embodiment of a process for directing a client. In some embodiments,process400 is employed by a traffic manager, such astraffic manager302 ofFIG. 3. Process400 starts atstep402 at which a request is received from a client. In various embodiments, the request received atstep402 may comprise a request for any appropriate resource such as a content request or a DNS request and may be communicated via any appropriate communication protocol. Atstep404, a set of one or more supported communication formats via which the client is capable of communicating are determined. For instance, step404 may include various techniques for determining whether the client is IPv4 enabled, IPv6 enabled, or dual stack. In some embodiments,step404 includes determining whether the source IP address of the received request is part of a list of IP addresses associated with tunneling services and/or a list of known native IP addresses. In some such cases, if the source IP address is found to be associated with a tunneling service, it is deduced that the client is dual stack. In some embodiments,step404 includes determining the ability of the client to access a set of test content each of which is accessible via a prescribed communication format as described above. Atstep406, a communication format that is expected to give the client the best performance is selected from the set of supported communication formats determined atstep404. For example, a communication format that allows the client to communicate via a network to which it is natively connected may be selected atstep406 if communication via a native network is expected to provide better performance. Alternatively, a communication format that requires a client to communicate via tunneling may be selected atstep406 if communication via a native network is expected to provide inferior performance. Atstep408, the client is directed or redirected to a node capable of servicing the client request via the communication format selected atstep406.
• As a result ofprocess400, for example, a native IPv4 client (including a native IPv4 client communicating via IPv6 tunneling) may be redirected to a native IPv4 server, and a native IPv6 client (including a native IPv6 client communicating via IPv4 tunneling) may be redirected to a native IPv6 server. Alternatively, if tunneling is expected to provide better performance than communications over a native network, a client may be redirected usingprocess400 to a server that entails tunneled communications between the devices. For example, a native IPv4 client (including a native IPv4 client already communicating via IPv6 tunneling) may be redirected to a native IPv6 server, and a native IPv6 client (including a native IPv6 client already communicating via IPv4 tunneling) may be redirected to a native IPv4 server. In general,process400 may be employed to select and direct a client via one of a plurality of possible network routes that is expected to give optimal performance.
• Numerous existing Internet resources such as web servers are only IPv4 enabled. It may be desirable for such resources to be IPv6 enabled as well. For example, a server associated with a publisher may only be capable of natively communicating via an IPv4 network, but the publisher may desire that its content also be natively accessible via IPv6. In some embodiments, a proxy server that translates content defined in a first format into a second format is employed to make a resource natively accessible in the second format. For example, a proxy server natively connected to both IPv4 and IPv6 networks may be employed to proxy content from an IPv4 server over an IPv4 network, translate the content into IPv6, and natively serve the IPv6 content to IPv6 users over an IPv6 network.
• FIG. 5 is a block diagram illustrating an embodiment of a network environment in which a proxy server is employed to translate content from a first format into a second format. For example,network environment500 may be employed to make the content of an IPv4 accessible website also accessible via IPv6.IPv4 server502 is connected to and configured to serve content published by a publisher via an IPv4 network. In various embodiments,server502 may belong to the publisher (e.g., the server may comprise a publisher origin server), a content delivery network contracted by the publisher, or another third party entity employed to serve content on behalf of the publisher.IPv4 server502 responds to an IPv4 request from client504(a) with an appropriate IPv4 response. In the given example,IPv6 proxy server506 comprises a dual stack device that is connected to and configured to natively communicate via both IPv4 and IPv6 networks. In various embodiments,proxy server506 may belong to the publisher or a third party contracted by the publisher. On its backend,proxy server506 is configured to proxy content fromIPv4 server502 via an IPv4 network.Proxy server506 may seed content fromserver502 to facilitate site and/or cache acceleration.Proxy server506 in some cases includes appropriate buffers for translating IPv4 packets obtained fromserver502 into IPv6 packets. On its frontend,proxy server506 is connected to and configured to serve IPv6 content natively via an IPv6 network.IPv6 proxy server506 responds to an IPv6 request from a client504(b) with an appropriate IPv6 response. In various embodiments, aclient504 may be redirected toIPv4 server502 orIPv6 proxy server506 by a traffic manager such astraffic manager302 ofFIG. 3.Proxy server506 may in some embodiments also be configured to receive client requests for and serve IPv4 content. In some embodiments, a special server may be interposed betweenserver502 andproxy server506 that obtains data fromserver502 using a protocol (e.g., UDP (User Datagram Protocol)) that is more amenable to packet fragmentation and that provides data toproxy server506 in a format that facilitates accelerated packet translation atproxy server506. Although the example provided with respect toFIG. 5 describes IPv4 to IPv6 translation,proxy server506 may similarly be employed to translate between any other formats. For instance,proxy server506 may similarly be employed for IPv6 to IPv4 translation.
• FIG. 6 is a flow chart illustrating an embodiment of a process for translating IPv4 content into IPv6 content. Although IPv4 to IPv6 translation is described,process600 may be similarly employed to translate content between any formats. In some embodiments,process600 is employed byproxy server506 ofFIG. 5. Process600 starts atstep602 at which IPv4 content is received from an IPv4 server. Such IPv4 content may be received, for example, via an IPv4 network. In some embodiments,step602 includes appropriately buffering the received IPv4 content. Atstep604, the IPv4 content received atstep602 is translated into IPv6. The resulting IPv6 content may be employed to service client requests over an IPv6 network. In various embodiments, IPv4 content may be obtained and translated into IPv6content using process600 prior to receiving any client requests for the content or in response to a client request for the content. In some embodiments, the IPv4 content received atstep602 may be employed to service client requests over an IPv4 network.Process600 may be used, for example, to make IPv4 content also available via IPv6.
• Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims (20)

What is claimed is:

1. A system, comprising:

one or more processors; and

a non-transitory storage device, coupled to the one or more processors, embodying a set of instructions, which when executed by the one or more processors perform a method comprising:

receiving a content request from a client;

determining a communication format through which the client is capable of communicating; and

directing the request to a content delivery network that supports the communication format through which the client is capable of communicating; and

wherein the content request relates to web page content published by a content publisher in an original format comprising an Internet Protocol version 4 (IPv4) format or an Internet Protocol version 6 (IPv6) format that is obtained by the content delivery network from the content publisher and is translated from the original format to a translated format comprising the IPv6 format or the IPv4 format, respectively, by the content delivery network prior to receiving any content requests for the web page content.

2. The system ofclaim 1, wherein the system provides dual-stack support.

3. The system ofclaim 1, wherein the system is natively connected to both an IPv4 network and an IPv6 network.

4. The system ofclaim 1, wherein the one or more processors are configured to communicate with an IPv4 enabled server natively via an IPv4 network.

5. The system ofclaim 1, wherein the one or more processors are configured to communicate with an IPv6 enabled client natively via an IPv6 network.

6. The system ofclaim 1, wherein the method further comprises directing the content request based on performance of the content delivery network in servicing the client request.

7. The system ofclaim 1, wherein the method further comprises directing the content request based on a traffic management policy specified by the content publisher.

8. The system ofclaim 1, wherein the system facilitates accessibility of content from an IPv4 enabled server via IPv6.

9. A method, comprising:

receiving, at a traffic manager device, a content request from a client;

determining, by the traffic manager device, a communication format through which the client is capable of communicating; and

directing, by the traffic manager, the content request to a content delivery network that supports the communication format through which the client is capable of communicating;

wherein the content request relates to web page content published by a content publisher in an original format comprising an Internet Protocol version 4 (IPv4) format or an Internet Protocol version 6 (IPv6) format that is obtained by the content delivery network from the content publisher and is translated from the original format to a translated format comprising the IPv6 format or the IPv4 format, respectively, by the content delivery network prior to receiving any content requests for the web page content.

10. The method ofclaim 9, wherein the traffic manager device is a dual stack network device.

11. The method ofclaim 9, wherein the traffic manager device is natively connected to both an IPv4 network and an IPv6 network.

12. The method ofclaim 9, wherein the traffic manager is configured to communicate with an IPv4 enabled server natively via an IPv4 network.

13. The method ofclaim 9, wherein the traffic manager is configured to communicate with an IPv6 enabled client natively via an IPv6 network.

14. The method ofclaim 9, further comprising directing, by the traffic manager device, the content request based on performance of the content delivery network in servicing the client request.

15. The method ofclaim 9, further comprising directing, by the traffic manager device, the content request based on a traffic management policy specified by the content publisher.

16. The method ofclaim 9, further comprising facilitating, by the traffic manager, content from an IPv4 enabled server to be accessible via IPv6.

17. A non-transitory computer-readable storage medium tangibly embodying a set of instructions, which when executed by one or more processors of a traffic manager device, cause the one or more processors to perform a method comprising:

receiving a content request from a client;

determining a communication format through which the client is capable of communicating; and

directing the content request to a content delivery network that supports the communication format through which the client is capable of communicating;

wherein the content request relates to web page content published by a content publisher in an original format comprising an Internet Protocol version 4 (IPv4 ) format or an Internet Protocol version 6 (IPv6) format that is obtained by the content delivery network from the content publisher and is translated from the original format to a translated format comprising the IPv6 format or the IPv4 format, respectively, by the content delivery network prior to receiving any content requests for the web page content.

18. The non-transitory computer-readable storage medium ofclaim 17, wherein the traffic manager device is a dual stack network device.

19. The non-transitory computer-readable storage medium ofclaim 17, wherein the traffic manager device is natively connected to both an IPv4 network and an IPv6 network.

20. The non-transitory computer-readable storage medium ofclaim 17, wherein the traffic manager is configured to communicate with an IPv4 enabled server natively via an IPv4 network and is configured to communicate with an IPv6 enabled client natively via an IPv6 network.

Images