Internet Draft L. Huang ZST University Category: Informational Expires October 2007 April 8, 2007 Distributed DNS Implementation in IpV6 Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This file is a proposal for P2P based Domain Name 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. 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 October 2007 FORMFEED[Page 1] Internet Draft DNS Impl in IPv6 April 8, 2007 Table of Contents 1. Introduction ................................................2 2. Virtual Hierarchical Overlay Network for DNS ................2 2.1 DNS Query Strategy ......................................3 2.2 Route Table Definitions..................................5 2.3 On-demand Domain Names...................................5 2.4 Hierarchical Management of Domain Name in IpV6...........5 2.5 Reverse Resolution.......................................7 2.6 Message..................................................8 3. Some Notes ..................................................11 4. Appendix A: protocols of establishment and lookup ...........12 4.1 Primitives and Functions ................................12 4.2 Protocol of Network Establishment........................13 4.3 lookup protocol..........................................13 5. References ..................................................15 1. Introduction 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. 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 use case for multi domain names associated with a sigle IP address. 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. 2. Virtual Hierarchical Overlay Network for DNS 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. 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. Huang, Lican Expires October 2007 FORMFEED[Page 2] Internet Draft DNS Impl in IPv6 April 8, 2007 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 take 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 node role which takes part in routing functions in several different layers of virtual groups. Gateway uppermost layer (denoted by GUL ) is the uppermost virtual group layer that the gateway is in. The layers are ordered from root layer which is labelled as level 1. 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 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. 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 Foreign Name Servers which are refreshed by TTL rule. The Huang, Lican Expires October 2007 FORMFEED[Page 3] Internet Draft DNS Impl in IPv6 April 8, 2007 query process is shown as the following figure. +---------+ |Domain | |Name | |Cache | +---------+ | DN cache operations A | | Foreign | | | Local Host | | | | V | +-------+ +--------+ | +-------+ +-------+ | | user queries | |queries | | | | | |User |------------->| |---------|->|Foreign|-->| Tree +| |Program| |Resolver| | | Name | | Cache | | |<-------------| |<--------|--| Server|<--|(route | | |user responses| |responses| | | | table)| +-------+ +--------+ | +-------+ +-------+ | A A | | Route cache operations | | |___________|____ | | | | | | V | | | V +----------------+ | +--------+ +------+ | Tree + | | |Foreign | | | | Cache | | | Name |-->| RR | | (route table) | | | Server|<--| | +----------------+ | | | | | | +--------+ +------+ The query process is as the following: User program sends QUERY MESSAGE to Name Server (called as Resolver), If Resolver is the authoritive Domain Name Server, then the resolver will check its RR to resolve the request Domain name. Otherwise,Resolver routes to the Foreign Domain Name Server which is closer to the authoritive Domain Name Server by calculating theoretical hops. Then the Foreign Domain 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 resolver. The latter will forward the response to the User Program. The details of the algorithm can be found in Appendix A. Huang, Lican Expires October 2007 FORMFEED[Page 4] Internet Draft DNS Impl in IPv6 April 8, 2007 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) | +------------+------------------------------------------------------+ |GUL |the value of gateway upmost layer of Domain Server | +------------+------------------------------------------------------+ |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 On-demand Domain Names Domain Names are introduced as a name that identifies a IP address for easy to remember. When a Domain Name for a IP is accessed frequently, more IP addresses are mapped into this Domain Name. In IpV6, there are so huge IP addresses that every device has at least one static IP address. There are also the cases that more Domain Names are mapped into one IP address. It is reseanable to think that IP address is the identification for a device. But,Domain Names are the roles the device plays in various organizations or activities. When a device with a IP address joins several virtual organizations, it will have several different Domain Names. For example, a machine is the provider of Song of Britney and Madanna, this machine may use www.Britney.popular.music and www.Madonna .popular.music as its Domain Names. This is called as On-demand Domain Names. 2.4 Hierarchical Management of Domain Name in IpV6 In IpV6,there are so many IP addresses, and even more, more than one Huang, Lican Expires October 2007 FORMFEED[Page 5] Internet Draft DNS Impl in IPv6 April 8, 2007 On-demand Domain Names for a IP; therefore,there may be huge number of Domain Names. Moreover, when we think Domain Names as roles involved with activities or virtual organizations, we should permit users to use whatever Domain Names. In such case of huge number of Domain Names, it is a reasonable way to manage Domain Name Registration in a hierarchical way. The Internet Corporation for Assigned Names and Numbers (ICANN) may govern the root of Domain Names. Other level Domain Name may be controlled by virtual organizations organized by the users automatically. For example, in Domain Name www.Madonna.popular.music, music Domain is managed by music virtual organization, which reports to ICANN to approve, popular.music Domain is controlled by popular music virtual organization,which reports to music virtual organization to approve. The request of Domain Name www.Madonna.popular.music is sent to virtual organization of popular music to be approved. In Domain Name www.Beethoven.classic.music, classic.music Domain is controlled by classic music virtual organization, which reports to music virtual organization to approve. The request of www.Beethoven.classic.music is managed by virtual organization of classic music. The Domain Names with binding of IP addresses are registered into dasebases of Domain Name Servers which are nodes containing leaves in Domain Name tree. These nodes containing leaves in Domain Name tree are Domain Name Servers. For example, www.Madonna.popular.music and www.Britney.popular.music are registered into resource records of database of their Domain Name Server--popular.music as following: www.Madonna.popular.music 3600 IN AAAA 2001:200:0:8002:203:47ff:fea5:3085 www.Britney.popular.music 2600 IN AAAA 1002:c18:107:1235:983:102:12:2031 The registration of Domain Names can be registered by users automatically. When users try to register Domain Names into their Domain Name Servers, the Domain Name Servers check the corresponding virtual organizations to see whether the Domain Names are valid; if the Domain Names are valid, then these Domain Names are registered into the Resource Records of databases of the Domain Name Servers. 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. Huang, Lican Expires October 2007 FORMFEED[Page 6] Internet Draft DNS Impl in IPv6 April 8, 2007 2.5 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 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. Huang, Lican Expires October 2007 FORMFEED[Page 7] Internet Draft DNS Impl in IPv6 April 8, 2007 2.6 Message 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 information | +---------------+-----------+---------------------------------------+ |Answer |variable |resource records matchmaking questions | +---------------+-----------+---------------------------------------+ |Additional |variable |Conveys one or more resource records | | | |relative to the query | +---------------+-----------+---------------------------------------+ |ResolverIP |variable |Resolver IP address used for sending | | | |back the anwser from any DN server | +---------------+-----------+---------------------------------------+ |AuthoritiveDSNE|variable |Node entity of the authoritive Domain | | | |Server used for caching routetable | +---------------+-----------+---------------------------------------+ |JoinDSNE |variable |Joining Domain Server Node Entity | +---------------+-----------+---------------------------------------+ |AcceptDSNE |variable |Node Entity of Domain Server accepting | | | |joining Domain Server | +---------------+-----------+---------------------------------------+ Huang, Lican Expires October 2007 FORMFEED[Page 8] Internet Draft DNS Impl in IPv6 April 8, 2007 DNS Message Header Format +----------+-----------+--------------------------------------------+ |Field Name|Size(bytes)| Description | +----------+-----------+--------------------------------------------+ |ID | 2 |Identifier generated by the device which | | | |origins the message | +----------+-----------+--------------------------------------------+ |MT |1/2(4bits) |Message Type Flag. 0 for query; 1 for | | | |response; 2 for join; 3 for approve | +----------+-----------+--------------------------------------------+ |Opcode |1/2(4bits) |specifies the type of query about the | | | |message | +----------+-----------+--------------------------------------------+ |Flags |1 |Flags reserved; | +----------+-----------+--------------------------------------------+ |RIPFlag |1/8(1bit) |0 for no ResolverIP section in Message; | | | |1 for having ResolverIP section in Message | +----------+-----------+--------------------------------------------+ |AUDSNEFlag|1/8(1bit) |0 for no AuthoritiveDSNEsection in Message; | | | |1 for having AuthoritiveDSNE section in | | | |the Message | +----------+-----------+--------------------------------------------+ |JDSNEFlag |1/8(1bit) |0 for no JoinDSNE section in Message; | | | |1 for having JoinDSNE section in Message | +----------+-----------+--------------------------------------------+ |ADSNEFlag |1/8(1bit) |0 for no AcceptDSNE section in Message; | | | |1 for having AcceptDSNE section in Message | +----------+-----------+--------------------------------------------+ |Z |1/2(4bits) |Zero: Four reserved bits set to zero. | +----------+-----------+--------------------------------------------+ |RCode |1 |Response Code | +----------+-----------+--------------------------------------------+ |QDCount |2 |Question Count: the number of questions | | | |in the Question section of the message | +----------+-----------+--------------------------------------------+ |ANCount |2 |Answer Record Count: the number of resource | | | |records in the Answer section of the message| +----------+-----------+--------------------------------------------+ |ARCount |2 |Additional Record Count: the number of | | | |resource records in the Additional section | | | |of the message | +----------+-----------+--------------------------------------------+ Huang, Lican Expires October 2007 FORMFEED[Page 9] Internet Draft DNS Impl in IPv6 April 8, 2007 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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | GUL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 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 October 2007 FORMFEED[Page 10] Internet Draft DNS Impl in IPv6 April 8, 2007 3. Some Notes 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. The time complexity, space complexity and message-cost of the proposed architecture is O(log N), where N is the total number of Domain Name Servers in the network. Therefore, domain name query is effective. Huang, Lican Expires October 2007 FORMFEED[Page 11] Internet Draft DNS Impl in IPv6 April 8, 2007 4. Appendix A: protocols of establishment and lookup 4.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 Huang, Lican Expires October 2007 FORMFEED[Page 12] Internet Draft DNS Impl in IPv6 April 8, 2007 4.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 accept, the Message is callaed as APPROVEMESSAGE. 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.APPROVEMESSAGE, P_join); (pi (- joinGroup).RouteTableAdd(P_join.DSNE,TREE); 5. P_join.RouteTableAdd((pi (- joinGroup).NSNE,TREE); 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. 4.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, resolver) Step 2 authoritiveDNServer = resolver.lookup_location(QUERYMESSAGE.DomainName) Step 3 RESULTMESSAGE= authoritiveDNServer.checkupRRs(QUERYMESSAGE); Step 4 authoritiveDNServer=send(RESULTMESSAGE, resolver); Step 5 resolver.send(RESULTMESSAGE, UserProgram); Step 6 resolver.RouteTableAdd(authoritiveDNServer.DSNE,CHACHE); Huang, Lican Expires October 2007 FORMFEED[Page 13] Internet Draft DNS Impl in IPv6 April 8, 2007 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); 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: Huang, Lican Expires October 2007 FORMFEED[Page 14] Internet Draft DNS Impl in IPv6 April 8, 2007 Function p.hopDistance2object(pi,requestDomainName) if LengthOfSamePrefix(pi.DNSI, requestDomainName) ==1 return LengthOfDomainName(requestDomainName)+pi.GUL -3; elseif pi.GUL < LengthOfSamePrefix(pi.DNSI, requestDomainName) return LengthOfDomainName(requestDomainName) - LengthOfSamePrefix(pi.DNSI, requestDomainName)-1; else return LengthOfDomainName(requestDomainName)+pi.GUL - 2*LengthOfSamePrefix(pi.DNSI,requestDomainName)-1 5. References 5.1. Informative 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. [VIRGO] Huang, L., "VIRGO: Virtual Hierarchical Overlay Network for Scalable Grid Computing ",Proc. European Grid Conference(EGC2005), in LNCS 3470, p911-921, 2005. Authors' Addresses Lican Huang Current Address: Institute of Network & Distributed Computing, Zhejiang Sci_Tech University, Hangzhou, P.R.China EMail: licanhuang@zist.edu.cn; huang_lican@yahoo.co.uk Huang, Lican Expires October 2007 FORMFEED[Page 15] Internet Draft DNS Impl in IPv6 April 8, 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Huang, Lican Expires October 2007 FORMFEED[Page 16]