Patent Application
20060075138
This invention relates generally to Internet Protocol (IP) version 6 (IPv6) and more particularly to Domain Name Server (DNS) requests.
Domain Name Servers are known in the art. Such network elements typically map names to Internet Protocol addresses and vice versa. For example, Domain Name Servers maintain central lists of domain name/Internet Protocol address and utilize such lists to map the domain names contained in submitted Internet requests to other servers on the Internet until, for example, a specified web site is located. Internet Protocol version 4 addresses for such Domain Name Servers are typically provided to a mobile node via Internet Protocol Control Protocol (IPCP, which typically specifies the control protocol used to support the Internet Protocol on Point-to-Point Protocol links) attributes.
Internet Protocol version 6 has been defined to be supported on a Packet Data Serving Node (PDSN). Notwithstanding several proposals, however, no standard method presently exists to provide a mobile node with the Internet Protocol version 6 address (or addresses) of one or more Domain Name Servers. Though the Internet Protocol version 4 approach described above has been proposed, it appears unlikely to be accepted as a standard methodology.
Another proposed but unlikely approach would add Domain Name Server Internet Protocol version 6 addresses to Internet Control Message Protocol version 6 router advertisements. This approach is unlikely because Dynamic Host Configuration Protocol (DHCP) version 6 appears to be the overall solution of choice. Unfortunately, not all mobile nodes are presently, or likely, to be compatible with DHCP v6. For example, CDMA2000 mobile nodes do not presently support DHCP v6 nor is this likely as DHCP v6 is otherwise unnecessary in CDMA2000.
The above needs are at least partially met through provision of the method and apparatus to facilitate IPv6 DNS requests described in the following detailed description, particularly when studied in conjunction with the drawings, wherein:
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will also be understood that the terms and expressions used herein have the ordinary meaning as is usually accorded to such terms and expressions by those skilled in the corresponding respective areas of inquiry and study except where other specific meanings have otherwise been set forth herein.
Generally speaking, pursuant to these various embodiments, a Packet Data Serving Node serves both as an ordinary Packet Data Serving Node and, on occasion, as a Domain Name Server proxy. So configured, upon receiving an Internet Protocol version 6 communication other than a Domain Name Server request from an Internet Protocol version 6 mobile node, the Packet Data Serving Node forwards a corresponding Internet Protocol version 6 message on behalf of the Internet Protocol version 6 mobile node in ordinary course. Upon receiving a Domain Name Server request from an Internet Protocol version 6 mobile node, however, the Packet Data Serving Node interacts with the Internet Protocol version 6 mobile node as a proxy for at least one Domain Name Server.
Pursuant to some approaches, this can comprise receiving Domain Name Server requests that use link local. Those skilled in the art will recognize, however, that various other approaches can be utilized, including but not limited to global version 6 addressing, and these teachings are not limited to link local usage alone. Internet Protocol version 6 addressing to present a Domain Name System identifier and modifying that Domain Name System identifier to provide a modified Domain Name System identifier. This, in turn, can preferably comprise mapping the modified Domain Name System identifier to at least one (and possibly all) of a Domain Name System identifier, an Internet Protocol version 4 address as corresponds to a selected Domain Name Server, and a Point-to-Point Protocol context. Pursuant to some approaches, such a map may only be maintained for no more than a predetermined period of time (such as, for example, a user-selectable predetermined period of time).
So configured, an Internet Protocol version 6 mobile node, such as a CDMA2000 mobile node, can readily achieve the desired Domain Name Server interaction without requiring modifications to the mobile node and in a manner that is readily supported by existing infrastructure with only minimal modification.
These and other benefits may become more evident upon making a thorough review and study of the following detailed description. Referring now to the drawings, and in particular to
This same process 10, upon receiving 13 a Domain Name Server request from such an Internet Protocol version 6 mobile node, will facilitate interaction 14 with that Internet Protocol version 6 mobile node as a proxy for a Domain Name Server. More particularly, when the enabling platform comprises a Packet Data Serving Node, this process 10 enables the Packet Data Serving Node to behave as a Domain Name Server proxy in contrast to ordinary prior art practice. This reception 13 of a Domain Name Server request can comprise, for example, a Domain Name Server request that uses link local Internet Protocol version 6 addressing. In a preferred approach this request comprises, at least in part, a Domain Name System identifier.
The above referenced interaction 14 can comprise, for example, modifying a Domain Name System identifier as was received 13 from the mobile node to provide a modified Domain Name System identifier. This interaction can further comprise mapping the modified Domain Name System identifier to one or more (and preferably all) of the original Domain Name System identifier, an Internet Protocol version 4 address as corresponds to a selected Domain Name Server, and/or a Point-to-Point context as characterizes and identifies the present link between the Packet Data Serving Node and the mobile node.
Depending upon the needs and/or requirements of a given application, it may not be desirable to retain such mapping information in perpetuity. In such a case, this interaction 14 can further comprise only maintaining the resultant map (or some portion thereof) for no more than a predetermined period of time (such as a few seconds, minutes, hours, days, and the like). If desired, the predetermined period of time can comprise a user-selectable predetermined period of time (for example, to permit a system administrator to modify this value to better comport with local needs or sensitivities). It would also be possible to provide a dynamic mechanism to vary the period of time as a function of one or more monitored events, conditions, settings, or the like. For example, a shorter period of time may be used during times of the day when system usage places greater needs upon the memory resources of the system infrastructure.
Those skilled in the art will understand that a Domain Name Server response may not always be received following transmission of a Domain Name Server request as described above. This can occur for various reasons. Pursuant to one approach, upon determining that a first Domain Name Server has failed to respond to such a request, the enabling platform can then automatically select a second Domain Name Server to which a subsequent Domain Name Server request shall be sent. Such a second Domain Name Server can be selected, for example, from a list of available Domain Name Servers using, if desired, a round robin or other circular queue approach or some other selection criteria or technique of choice. In general, when such a failure to respond occurs, the enabling platform will preferably not provide information to the Internet Protocol version 6 mobile node regarding such a failure to respond. Instead, if and when the mobile node resends its original request, the enabling platform can operate as described above, using the next selectable Domain Name Server from its list.
Referring now to
These teachings can be implemented via a variety of enabling platforms though, as already noted, these teachings have particular benefit when applied in conjunction with a Packet Data Serving Node. Regardless, and referring now to
These actions and reactions preferably correspond to the above-described processes and in particular will preferably encompass the above-described Domain Name System identifier modification and mapping activity to thereby facilitate the above-described Domain Name Server and mobile node interaction.
An illustrative series of communications and actions as correspond to these teachings appear in
A receiving Domain Name Server provides a Domain Name Server reply 44 that also uses that same identifier “Y” and Internet Protocol version 4 addressing (or other corresponding addressing scheme as is relevant to a specific application). Upon receiving this reply 44, the Packet Data Serving Node uses 45 its previously formulated mapping to correlate Domain Name Server identifier “Y” (and, optionally, the Internet Protocol version 4 destination address) with Domain Name Server identifier “X” and the existing Point-to-Point Protocol context. The Packet Data Serving Node then uses this recovered Domain Name Server identifier “X” and Point-to-Point Protocol context to facilitate provision of a Domain Name Server reply 47 to the mobile node that uses Domain Name Server identifier “X” and link local Internet Protocol version 6 addressing.
So configured, the Packet Data Serving Node serves both as a traditional Packet Data Serving Node while also serving as a Domain Name Server proxy to facilitate the corresponding needs of its mobile node population. Those skilled in the art will appreciate that these teachings permit successful interaction between Internet Protocol version 6 mobile nodes and Internet Protocol version 4 Domain Name Servers without requiring modification of either endpoint.
Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.
