DNDOP L. Huang Internet-Draft Hangzhou Domain Zones Tech.Co.,Ltd. Intended status: Standards Track Expires: July 27, 2013 January 28,2013 Distributed DNS Implementation in IpV6 draft-licanhuang-dnsop-distributeddns-13.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 27, 2013 . Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license- info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Huang, Lican Expires July 27,2013 FORMFEED[Page 1] Internet Draft DNS Impl in IPv6 January 28,2013 Abstract This file is a proposal for P2P based Domain Name query strategy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided and more security can be enhanced due to the random lookup paths. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. Huang, Lican Expires July 27,2013 FORMFEED[Page 2] Internet Draft DNS Impl in IPv6 January 28,2013 Table of Contents 1. Introduction ................................................3 2. Virtual Hierarchical Overlay Network for DNS ................3 2.1 DNS Query Strategy ......................................5 2.2 Route Table Definitions..................................6 2.3 Reverse Resolution.......................................6 2.4 Message..................................................7 3. Some Notes ..................................................12 3.1 Complexity...............................................12 3.2 Random trace.............................................12 4. Security Considerations......................................13 5. IANA Considerations..........................................13 6. Acknowledgements.............................................13 7. Appendix A: protocols of establishment and lookup ...........14 7.1 Primitives and Functions ................................14 7.2 Protocol of Network Establishment........................14 7.3 lookup protocol..........................................15 8. References ..................................................17 8.1. Normative References ..................................17 8.2. Informative References ................................17 Author's Address ...............................................17 1. Introduction Because the Webs have large number of Domain name links, DNS becomes a vital component in today's Internetinfrastructure. However, the existing DNS architecture will encounter problems in the future for the growth of the Internet. This file is a proposal for P2P based DNS query stratagy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided and more securtity can be enhanced due to the random lookup paths. This strategy may be used in DNS query in IpV6 for a large number of domain names. There are huge numbers of IP address in IpV6. Moreover, there may be a use case for multi domain names associated with a sigle IP address. Pervasive computing will enlarge the numbers of DNS lookups. DNS implementation currently used may encounter overload traffic in root DNS servers. This document uses VIRGO[VIRGO] overlay network to solve the above problem. VIRGO is a multi-tuple virtual hierarchical overlay network with cached node address. We here change some places to suit the distributed DNS implementation. The lookup protocols of DNS is similar as the protocols in VIRGO[VIRGO], which is illustrated in detail in the paper[P2PSD] titled as A P2P service discovery strategy based on content catalogues. 2. Virtual Hierarchical Overlay Network for DNS Huang, Lican Expires July 27,2013 FORMFEED[Page 3] Internet Draft DNS Impl in IPv6 January 28,2013 Virtual Hierarchical Overlay Network for DNS is a hybrid of unstructured P2P and structured P2P technologies. The DNS servers construct multi-tuple Virtual Hierarchical Overlay Network. Some servers are only leaves of the network, others may coexist in different layers. These servers form a duplicated virtual hierarchical tree, with one root layer, several middle layers, and many leaf virtual nodes. Random connections cached in a DNS server's routing table are maintained. The servers in the same domain are fully connected. Unlike query pathes currently used in Domain Name Systems allways go to root servers, Virtual Hierarchical Overlay Network for DNS routes quest message to the server with theoretical least hops from destination server. The route tables of Domain Name servers contains two kinds of route addresses, tree addresses, which are prerequiste, and cached addresses. The following is some terms related to the Virtual Hierarchical Overlay Network for DNS. Domain Name Server is a node which keeps local domain RRs[RFC1035]. All the Domain Name Servers are the same except some Domain Name Servers taking the function of gateways in the meantime. Every Domain Name Server just controls the leaves of the domain. Every Domain Name Server contains route table. Every Domain Name Server uses its controlled domain name by cutting off leaves as its Identification, which is called as Domain Name Server Identification (DNSI). For example, for Grid.network.computer.science, Wireless.network.computer.science, etc., Domain Name Servers have Identifications -- network.computer.science. It keeps RRs for Grid.network.computer.science,Wireless.network.computer.science,etc. The Domain Name Server can be replicated by machines with different IP addresses, but all with same RRs and route tables. Gateway is a nodee which takes part in routing functions in several different layers of virtual groups. Gateway uppermost layer is the uppermost virtual group layer that the gateway is in. The layers can be calculated by the domain lengths of node ID. Virtual group is formed virtually by the gateways nodes. The Group Name is part of the node's domain name, eg. in the above example, science, science.computer, science.computer.network are group names. N-tuple virtual group tree (denoted by NVGT) is a hierarchical tree formed by virtual groups. Among the nodes of the lower layer virtual groups, N-tuple gateway nodes in each group are chosen to form upper- layer groups, and from the nodes of these upper-layer groups to form upper-upper-layer groups in the same way, and this way is repeated Huang, Lican Expires July 27,2013 FORMFEED[Page 4] Internet Draft DNS Impl in IPv6 January 28,2013 until a root-layer group is formed. In the Virtual Hierarchical Overlay Network for DNS, all Domain Name Servers consist of N-tuple virtual group tree. The Virtual Hierarchical Overlay Network can be established by manual or automatedly by establishment protocol which is shown in Appendix A. Domain Name Servers are virtually architectured as Tree Structure. Some Domain Name Servers takes roles of gateways. When a Domain Name Server joins the network, it first finds one of Domain Name Servers which share the maxmium prefixs with the joining Domain Name Server, then the joining server sends the JOINMESSAGE to the latter, the latter will broadcast the message to all Domain Name Servers in the virtual group. The Network establishment is shown at Appendix 4.2. 2.1 DNS Query Strategy Every DNS server is the same but some coexist in more than one layer. Every DNS Server maintains a route table and a RR record related to its Domain. Route table includes addresses of Foreign Name Servers which are prerequiste for Virtual Hierarchical Overlay Network and cached addresses of Foreign Name Servers which are refreshed by TTL rule. The query process is shown as the following figure. | Foreign | Local Host | | +-------+ +--------+ | +-------+ +-------+ | | user queries | |queries | | | | | |User |------------->| Local |---------|->|Foreign|-->| Tree +| |Program| | Name | | |Name | | Cache | | |<-------------| Server |<--------|--|Server |<--|(route | | |user responses| |responses| | | | table)| +-------+ +--------+ | +-------+ +-------+ | A A | | Route cache operations | | |___________|____ | | | | | | V | | | V +----------------+ | +--------+ +------+ | Tree + | | |Authori-| | | | Cache | | |tive |-->| RR | | (route table) | | |Name |<--| | +----------------+ | |Server | | | | +--------+ +------+ Huang, Lican Expires July 27,2013 FORMFEED[Page 5] Internet Draft DNS Impl in IPv6 January 28,2013 The query process is as the following: User program sends QUERY MESSAGE to Local Name Server. If Local Name Server is the authoritive Domain Name Server, then the Local Name Server will check its RR to resolve the request Domain name. Otherwise, The Local Name Server will routes to the Foreign Name Server which is closer to the authoritive Domain Name Server by calculating theoretical hops. Then the Foreign Name Server routes to the even closer Foreign Domain Name Server. Repeat this process, until the authoritive Domain Name Server has been found. Finally, the authoritive Domain Name Server resolves request Domain Name by check its RR record, and responses to the Local Name Server. The latter will forward the response to the User Program. The details of the algorithm can be found in Appendix A. 2.2 Route Table Definitions All Route Tables have the same top level format shown below, which is also called as Domain Server Node Entity(DSNE): +------------+------------------------------------------------------+ |Section Name| Description | +------------+------------------------------------------------------+ |DNSI |Domain Name Server Indetification of an Domain Server| +------------+------------------------------------------------------+ |TYPE |route TYPE codes (TREE as 0, CHACHE as 1) | +------------+------------------------------------------------------+ |TTL |the time interval that the route record may be cached | | |before the source of the information should again be | | |consulted. | +------------+------------------------------------------------------+ |UTS |Unreachable time stamp.If the route was cached, then | | |reflesh it by TTL rule.If the route is gateway node in| | |virtual tree structure,notice to manager to repair it.| +------------+------------------------------------------------------+ |IPADDRESSes | IP addresses of the replicated Domain Servers | +------------+------------------------------------------------------+ 2.3 Reverse Resolution Reverse Resolution uses .IN-ADDR.ARPA domain today. In IPv6, .IP6.ARPA was defined by [RFC3152], and more detail information can be found in [RFC3596]. Because IPv6 has a huge Name Space, it is difficult to keep reverse RRs in today's architecture. Here, an approach with Virtual Hierarchical Overlay Network for DNS can solve the above problem. Domain Name Servers managing local networks is Huang, Lican Expires July 27,2013 FORMFEED[Page 6] Internet Draft DNS Impl in IPv6 January 28,2013 called as the hierarchical address Domain just like Domain Name Resolution. These Domain Name Servers join the Virtual Hierarchical Overlay Network for DNS. The records of route table is the same as the Domain Name Resolution. DNSI(Domain Name Server Indetification of an Domain Server) is like as: fea5.47ff.203.8002.0.200.2001.IP6.INT with Server IP Address 2001:200:0:8002:203:47ff:fea5:0010 resolutes the Domain Name from 2001:200:0:8002:203:47ff:fea5:0 to 2001:200:0:8002:203:47ff:fea5:ffff. Whereas in Domain Name resolution, popular.music with Server IP Address 2001:200:0:8002:203:47ff:fea5:0010 solutes www.***.popular.music Domain Names. The servers for popular.music and fea5.47ff.203.8002.0.200.2001.IP6.ARPA can be same or different. Reverse Domain Name Servers joins Virtual Hierarchical Overlay Network for DNS is the same as Domain Name Servers , and also use protocol shown at Appendix 4.2. The query protocol is also the same as Domain Name Resolution, which is shown as Appendix 4.3. The Total address space of IPv6 is huge. But, only the Reserve Domain Name Servers managing used IP addresses will join the Virtual Hierarchical Overlay Network for DNS. And the worst maxium query steps are 32. With route cache the query steps will be less than 32. Therefore, this strategy for Reverse Resolution is feasible. 2.4 Message 2.4.1 DNS Message format +---------------+-----------+---------------------------------------+ |Section Name |Size(bytes)| Description | +---------------+-----------+---------------------------------------+ |Header | 12 |indicating the type of message and the | | | |number of entries in the other sections| | | |of the message | +---------------+-----------+---------------------------------------+ |Question |variable |querying or joining information | +---------------+-----------+---------------------------------------+ |Answer |variable |resource records matchmaking questions | | | |or confirmation answer | +---------------+-----------+---------------------------------------+ |Additional |variable |Conveys one or more resource records | | | |relative to the query | +---------------+-----------+---------------------------------------+ |Join |variable |Server's joining information | +---------------+-----------+---------------------------------------+ |Confirmation |variable |Confirmation for server's join | +---------------+-----------+---------------------------------------+ Huang, Lican Expires January 25,2013 FORMFEED[Page 7] Internet Draft DNS Impl in IPv6 January 28,2013 2.4.2 Domain Name Node Entity format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DSNELen | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DNSILen | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / DNSI / / / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | UTS | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NumRDS | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / IPADDRESS1 / / ... / / IPAddressn / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Here, DSNELen is the length of Domain Name Node Entity, and DNSILen is the length of Domain Name Server Identification. NumRDS is the number of replicated Domain Name Server IP Addresses. Huang, Lican Expires July 27,2013 FORMFEED[Page 8] Internet Draft DNS Impl in IPv6 January 28,2013 2.4.3 DNS Message Header Format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA|CA|NF|Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: The items are the same meaning with [RFC1035] except for the following: QR A one bit field that specifies whether this message is a query/join(0), or a response/confirmation(1). OPCODE A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. The values are: 0 a standard query (QUERY) 1 an inverse query (IQUERY) 2 a server status request (STATUS) 3 Server join 4-15 reserved for future use CA Confirmation answer for authoritative server join. NF 0 for RFC 1035, 1 for this specification Z Reserved for future use. Must be zero in all queries and responses. Huang, Lican Expires July 27,2013 FORMFEED[Page 9] Internet Draft DNS Impl in IPv6 January 28,2013 2.4.4 Question section format The question section is used to carry the "question" in most queries, i.e., the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / LocalNSIP / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: The items are the same meaning with [RFC1035] except for the following: LocalNSIP Local Name Server IP address used for sending back the anwser from any zone server. 2.4.5 Answer section format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / RRs / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / AuthoritiveDSNE / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Huang, Lican Expires July 28,2011 FORMFEED[Page 10] Internet Draft DNS Impl in IPv6 January 28,2013 where: The items are the same meaning with [RFC1035] except for the following: AuthoritiveDSNE Node entity of the Authoritive Name Server used for cached routetable 2.4.6 Join section format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / JoinDSNE / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: JoinDSNE Joining Domain Server Node Entity 2.4.7 Confirmation section format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / ConfirmationDSNE / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ConfirmationDSNE Node Entity of Domain Server confirming joining Domain Serve Huang, Lican Expires July 27,2013 FORMFEED[Page 11] Internet Draft DNS Impl in IPv6 January 28,2013 3. Some Notes This specification is compliant with [RFC1035]. High performance and stable computers are chosen as gateway nodes. Because the gateway node not only manages local RRs,but also routes messages. The virtual tree structure requires gateway node stable. Due to the prerequiste tree, every Domain Name Server can reach other ones. Due to redundant gateway nodes, the virtual tree can be allways maintaned. Due to the random cached nodes in the route table of every Domain Name Server, the route paths are randomly chosen. This may avoid the network trafic in tree-like structure. This may also enhance the security of the DNS. 3.1 Complexity The time complexity, space complexity and message-cost of the proposed architecture is O(L), where L is the lengths of Domain Name. Because the DNS server nodes are virtually organized as a tuple virtual tree, every DNS server has a route table which includes prerequisite DNS servers' IP addresses for Tree Paths (TREE portion) and cached DNS servers' IP addresses (CACHED portion). Because the message is routed according to the minimum of theoretical distance from destination node , and the route table contains TREE portion, every hop reduces the distance from destination node by at least one hop, Therefore, hops(a,b) < length(a) + length(b)-1 (1) Where, hops(a,b) is for the hops from node a to node b; length(a),length(b) are for node a domain name lengths and node b domain name lengths respectively. For example, the length of www.nic.fr is 3. So, time complexity = O(L) (2) message_cost = O(L) (3), where L is the length of domain name. Because the route table of the virtual gateway nodes virtually existed from root layer to bottom layer groups has the maximum Huang, Lican Expires July 27,2013 FORMFEED[Page 12] Internet Draft DNS Impl in IPv6 January 28,2013 route items of nodes's information, we have: MaxItems = L*N_tuple*nvg +Max_Cached (4) ,where L is the length of domain name., N_tuple is multiplicity of gateway nodes for virtual tree, nvg is number of virtual groups, Max_Cached is the maximum number of cached records in the route table Therefore, Space Complexity = O(L) (5) Also due to the cached information of DNS servers, the performance of DNS lookups may reach 0(1) due to Zipf's law[VIRGODNS]. 3.2 Random trace Every node has a path to any other node. Supposing a-->b. Every route step has passible paths of the number of elements of route table of the node. Thus, the diffrent numbers of paths is about |routetable(a)| at DNS server a. In the same way, the diffrent numbers of paths can be choosed is about |routetable(vi)| at DNS server vi. Therefore, the totoal number of paths is: |routetable(a)| X ...X|routetable(vi)| X...X |routetable(vn)| . vi...vn are intermediate route nodes. Therefore, the communication path would be random. 4. Security Considerations For security consideration, the DNS servers before joining P2P network MUST be approved by the upper layer organizations. layer organizations should be controlled by trustful communities. 5. IANA Considerations This document consists entirely of DNS IANA Considerations. 6. Acknowledgements Thanks for Luke Kenneth Casson Leighton's valuable opinions. Huang, Lican Expires July 27,2013 FORMFEED[Page 13] Internet Draft DNS Impl in IPv6 January 28,2013 7. Appendix A: protocols of establishment and lookup 7.1 Primitives and Functions sender.send (message,receiver), sender sends message to receiver sender.send(message,receiver (- Set), sender sends message to all the receivers belong to a Set RouteTableAdd(DSNE,type), add DSNE to route table lookup_location(DomainName),find the destination node's location LengthOfSamePrefix(DomainName,DomainName), length of shared prefixes between two nodes LengthOfDomainName(DomainName), the length of DomainName hopDistance2object(pi,DomainName), the theoretical hops from the node to the destination node selectRouteNodeFromRouteTable(DomainName), choose next hop node from route table checkupRRs(QUERYMESSAGE), retrieve RR record in RR database 7.2 Protocol of Network Establishment Here, a new Domain Name Server P_join joins the network. If Header of DNS Message is set to join, the Message is callaed as JOINMESSAGE;if Header of DNS Message is set to confirmation, the Message is callaed as CONFIRMATIONMESSAGE. 1. P_join finds one of Domain Name Servers P_groupToJoin(which belongs to virtual group--joinGroup) sharing maximium prefixs with P_join. 2. P_join.send(JOINMESSAGE, P_groupToJoin); 3. P_groupToJoin.send(JOINMESSAGE, pi (- joinGroup); 4. (pi (- joinGroup).send(pi.CONFIRMATIONMESSAGE, P_join); (pi (- joinGroup).RouteTableAdd(P_join.DSNE,TREE); 5. P_join.RouteTableAdd((pi (- joinGroup).DSNE,TREE); Huang, Lican Expires July 27,2013 FORMFEED[Page 14] Internet Draft DNS Impl in IPv6 January 28,2013 6. set joinGroup to one upper group; 7. set P_groupToJoin = pi (- joinGroup; 8. repeat step 2 to 7 until replicated nodes no less than n-tuple in joinGroup or joinGroup is root group. 7.3 lookup protocol Here, if Header of DNS message is set to query, the DNS Message is callaed as QUERYMESSAGE; if Header of DNS message is set to response, the DNS Message is callaed as RESULTMESSAGE. Step 1 UserProgram.send (QUERYMESSAGE, LocalNameServer) Step 2 authoritiveDNServer = LocalNameServer.lookup_location(QUERYMESSAGE.DomainName) Step 3 RESULTMESSAGE= authoritiveDNServer.checkupRRs(QUERYMESSAGE); Step 4 authoritiveDNServer=send(RESULTMESSAGE, LocalNameServer); Step 5 LocalNameServer.send(RESULTMESSAGE, UserProgram); Step 6 LocalNameServer.RouteTableAdd(authoritiveDNServer.DSNE,CHACHE); Where, function of lookup_location (locates the destination node by the minimum hops) is as following: Function p.lookup_location(QUERYMESSAGE) \{ if LengthOfSamePrefix(p.DNSI,QUERYMESSAGE.DomainName)== LengthOfDomainName(QUERYMESSAGE.DomainName)-1 return p; else \{ routeP = p.selectRouteNodeFromRouteTable(QUERYMESSAGE.DomainName); p.send(QUERYMESSAGE,routeP); Huang, Lican Expires July 27,2013 FORMFEED[Page 15] Internet Draft DNS Impl in IPv6 January 28,2013 if (message sending is successful) routeP.lookup_location(QUERYMESSAGE); else \{ Mark routeP as unreachable in p.routetable; p.lookup_location(QUERYMESSAGE); \} \} \} Where, function selectRouteNodeFromRouteTable(select route with theoretical least hops from destination Domain Name Server) is as following: Function p.selectRouteNodeFromRouteTable(requestDomainName) gnSet = Minimum(p.hopDistance2object(pi (- RouteTable,requestDomainName)); return routeP = random(gnSet); Where, function hopDistance2object (calculating theoretical hops from destination Domain Name Server) is as following: Function p.hopDistance2object(pi,requestDomainName) if LengthOfSamePrefix(pi.DNSI, requestDomainName) ==1 return LengthOfDomainName(requestDomainName)+pi.length -3; elseif pi.length < LengthOfSamePrefix(pi.DNSI, requestDomainName) return LengthOfDomainName(requestDomainName) - LengthOfSamePrefix(pi.DNSI, requestDomainName)-1; else return LengthOfDomainName(requestDomainName)+pi.length - 2*LengthOfSamePrefix(pi.DNSI,requestDomainName)-1 Huang, Lican Expires July 27,2013 FORMFEED[Page 16] Internet Draft DNS Impl in IPv6 January 28,2013 8. References 8.1. Normative References [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",Specification," RFC1035, USC/Information Sciences Institute,November, 1987. [RFC3152] Bush, R., "Delegation of IP6.ARPA," RFC 3152, BCP 49, August 2001. [RFC3596] Thompson, S., C. Huitema, V. Ksinant, M. Souissi, "DNS Extensions to Support IP Version 6," RFC 3596, October 2003. 8.2. Informative References [VIRGO] Huang, L., "VIRGO: Virtual Hierarchical Overlay Network for Scalable Grid Computing ",Proc. European Grid Conference(EGC2005), in LNCS 3470, p911-921, 2005. [P2PSD] Huang, L., "A P2P service discovery strategy based on content catalogues", Data Science Journal, Vol(6), 2007, ppS492-S499. http://www.jstage.jst.go.jp/article/dsj/6/0/S492/_pdf [VIRGODNS] Huang, L.,"VIRGO P2P based distributed DNS framework for IPv6 network",Proc. 4th International Conference on Networked Computing and Advanced Information Management(NCM 2008) [AGENT] Huang, L.,"Constructing Large Scale Cooperative Multi-Agent Systems from Semantic P2P Networks", Springer, ISBN:978-3-642-34952-2, Vol(460),2013, pp257-277 Authors' Addresses Lican Huang Current Address: Hangzhou Domain Zones Technology Co., Ltd. & Hangzhou Domain Search Network Technology Co., Ltd. & Zhejiang Sci_Tech University, Hangzhou, P.R.China EMail: lican.huang.hz@gmail.com; licanhuang@zstu.edu.cn; huang_lican@yahoo.co.uk Huang, Lican Expires July 27,2013 FORMFEED[Page 17]