Network Working Group Yongping Diao Internet-Draft China Telecom-Guangzhou Institute Expires: July 04, 2007 January 04, 2007 DNS Extension for EIPv4 draft-diao-eipv4-dns-extension-00.txt Status of this Memo 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/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 04, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract Source route based Extensible IP Network(EIPv4) implementation can efficiently resolve the problem of IP address shortage. It is necessary to provide domain name service in EIPv4 to make it suitable for practical application. Here provides a way to DNS extension for EIPv4. It discusses how to extend the architecture of DNS into two-level extensible IP network architecture to provide query between domain name and IP node position denotation. And a new DNS RR type has been defined for this purpose. Diao Expires July 04, 2007 [Page 01] Internet-Draft January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 03 1.1. Glossary of Terms . . . . . . . . . . . . . . . . . . . . 03 1.2. Conventions used in this document . . . . . . . . . . . . 03 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 04 2.1. EIPv4 Background . . . . . . . . . . . . . . . . . . . . . 04 2.2. DNS Requirement For EIPv4 . . . . . . . . . . . . . . . 05 3. DNS Architecture Extension For EIPv4 . . . . . . . . . . . . . 05 4. The DNS IPD RR . . . . . . . . . . . . . . . . . . . . . . . . 06 5. IPD-to-name Mapping Using the PTR RR . . . . . . . . . . . . . 08 6. Master File Format . . . . . . . . . . . . . . . . . . . . . . 09 7. Security Considerations . . . . . . . . . . . . . . . . . . . 09 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Diao Expires July 04, 2007 [Page 02] Internet-Draft January 2007 1. Introduction Rapid development of Internet has cause severe deficiency of IP address. And it would retard all-IP application service development. Source route based extensible IP network(EIPv4) scheme makes the existing IP version 4 network extend flexibility. Enough IP address is provided. There is no so much difficulty in upgrade or transition. The extensible IP network provides good network infrastructure and help develop all-IP network application service. In order to fluently popularize the deployment of EIPv4, it is necessary to advance an issue about DNS extension for EIPv4. It includes DNS architecture extension, new defined DNS Resource Record, etc. In EIPv4 communication, IP node can easily find another IP node in the other end with the mapping between domain name and IP node position denotation. With this people would not even aware any change in their daily Internet access. 1.1. Glossary of Terms EIPv4 - Source Route Based Extensible IP Network version 4 IPD - IP Node Position Definition 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Diao Expires July 04, 2007 [Page 03] Internet-Draft January 2007 2. Background 2.1. EIPv4 Background Extensible IP network architecture includes Public IP Address Domain, Private IP Address Domain, Border Gateway between Public IP Address Domain and Private IP Address Domain. The existing Internet (Public IP Address Domain) Keep unchanged, and it can be expanded by attaching Private IP Address Domain through Border Gateway. Because any different Border Gateway can be attached a whole Private IP Address Domain, it means that tens of millions IP nodes are expanded through single Border Gateway. In traditional Internet only public IP address is legal, so each Internet IP node can be located uniquely by public IP address. In this extensible IP network architecture, public IP address is still unique in the whole network, but the Private IP Address Domain can be reused. So a method named "IP Node Position Definition(IPD)" is adopted to uniquely locate IP node in the extensible IP network architecture. We find that any IP node in this extensible IP network architecture can be uniquely located either by IP node's public IP address or by IP node's private IP address with correlated public IP address. IP node position denotation is show as: (public IP address)[:private IP address] Then, we can use this method to locate any IP node: * IP node in Public IP Address Domain has position denotation: its public IP address. * IP node in Private IP Address Domain has position denotation: its correlated Border Gateway's public IP address:its private IP address. * IP node as Border Gateway between Public IP Address Domain and Private IP Address Domain has position denotation:its public IP address, or its public IP address:its private IP address. Diao Expires July 04, 2007 [Page 04] Internet-Draft January 2007 2.2. DNS Requirement For EIPv4 In EIPv4, in order to transport datagram using source route method, source route should be prepared. We should identify the source IP node and destination IP node at first. Then we can get source IP node position denotation and destination IP node position denotation with above IP node position definition. Now according to the denotation of source IP node and destination IP node, we can predefine the "Path" which datagram should pass through. Namely, reverse address sequence of source IP node position denotation connects with address sequence of destination IP node position denotation in series, which constitutes "Path Address Sequence" of datagram. It is the source defined path. According to the source route theory and the method defined in EIPv4, source IP node MUST fill in Source Address Field, Destination Address Field, Loose Source and Record Route Option Field with "Path Address Sequence". Then source IP node can make up the IP header so that its datagram can reach destination IP node according to the predefine "Path". It is obvious that DNS requirement for EIPv4 is different. It would not be manpping between domain name and IP address, but mapping between domain name and IP node position denotation. If the source IP node know the domain name of another IP node which is the intended destination, source IP node can initiate a name-to-IPD DNS query. Related resolver can return a destination IPD through a query to EIPv4 based DNS server. Then source IP node is ready to communicate with destination IP node using its own IPD and destination's IPD. 3. DNS Architecture Extension For EIPv4 In EIPv4, it should be ensured that DNS running mechanism in Internet is protected and there is not change to DNS server deployment and configuration. So public IP address domain of EIPv4 reserves the Internet DNS system unchanged. In EIPv4, any individual Border Gateway can attach a whole Private IP Address Domain. And any this Private IP Address Domain should be managed as a DNS sub-tree independently from Public IP Address Domain, namely a zone. Once an authorized organazation is assigned to operate such zone, it would provide one or more DNS servers to the zone. The operator of the DNS zone applys a name and IPD for each new comer and adds these information to the name server. Diao Expires July 04, 2007 [Page 05] Internet-Draft January 2007 Each Private IP Address Domain is delegated from some edge position of Public IP Address Domain. Public IP Address Domain should provide one "Border DNS Server" nearby for each Private IP Address Domain. Each of the Border DNS Server is in charge of the whole individual Private IP Address Domain. In practice, a Private IP Address Domain zone might further delegate new sub-zone under it if need. Then authorized name servers in Private IP Address Domain would provide DNS service according to the corresponding domain level. Host software MUST support LSRR option in EIPv4. In order to advoid possible affection to exist DNS system, or make network transit smoothly, we can use the "Border DNS Server" as mediated DNS server. When DNS query packet need go into a Private IP Address Domain, firstly it should be sent to relative "Border DNS Server" of the Private IP Address Domain. Then the "Border DNS Server" would forward the packet to its delegated sub-zone name server in Private IP Address Domain. Similarly, when DNS query packet need go out to Internet, firstly it should be sent to relative "Border DNS Server" of the Private IP Address Domain. Then the "Border DNS Server" would forward the packet to some name server in Internet. 4. The DNS IPD RR In EIPv4, IP node can find any IP node in extensible IP version 4 network through IP node Position Definition(IPD). Then they can communicate freely to each other. In order to provide usual Internet name service, it is necessary to add mapping between IP node name and IP node position denotation. The IPD RR is defined with mnemonic "IPD" and TYPE code ?? (decimal, to be assigned) and is used to map from domain names to IPDs. Name-to-IPD mapping in the DNS using the IPD RR operates analogously to IP address lookup. A query is generated by the resolver requesting an IPD RR for a provided domain name. Diao Expires July 04, 2007 [Page 06] Internet-Draft January 2007 IPD RRs conform to the top level RR format and semantics as defined in Section 3.2.1 of RFC 1035. Its format is defined as following: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = IPD | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: * NAME: an owner name, i.e., the name of the node to which this resource record pertains. * TYPE: two octets containing the IPD RR TYPE code of ?? (decimal, to be assigned by IANA). * CLASS: two octets containing the RR IN CLASS code of 1. * TTL: a 32 bit signed integer that specifies the time interval in seconds that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. * RDLENGTH: an unsigned 16 bit integer that specifies the length in octets of the RDATA field. Diao Expires July 04, 2007 [Page 07] Internet-Draft January 2007 * RDATA: a variable length string of octets containing the IPD address sequence, namely, IP address sequence in (public IP address)[:private IP address]. According to IPD definition, IPD RR will store one or two IP addresses, which has a length of 4 octets or 8 octets. For example, an IP node S1, its IPD is 202.99.0.9:172.18.10.8. For this IPD, RDLENGTH is 8 (decimal); A typical RDATA example of such an IPD (in decimal) is shown below. ":" and "."s have been omitted to emphasize that they don't appear in the DNS packets. 202 99 0 9 172 18 10 8 IPD RRs cause no additional section processing. 5. IPD-to-name Mapping Using the PTR RR The PTR RR is defined in RFC 1035. This RR is typically used under the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names. Similarly, the PTR RR is used to map from IPDs to domain names under the "IPD.INT" domain. A domain name is generated from the IPD according to the rules described below. A query is sent by the resolver requesting a PTR RR for the provided domain name. A domain name is generated from an IPD by reversing the hex nibbles of the IPD address sequence, treating each nibble as a separate subdomain, and appending the top-level subdomain name "IPD.INT" to it. For example, the domain name used in the reverse lookup for the IPD 202.99.0.9:172.18.10.8 would appear as 8.10.18.172.9.0.99.202.IPD.INT [Implementation note: For sanity's sake user interfaces should be designed to allow users to enter NSAPs using their natural order, i.e., as they are typically written on paper. Also, arbitrary "."s should be allowed (and ignored) on input.] Diao Expires July 04, 2007 [Page 08] Internet-Draft January 2007 6. Master File Format The format of IPD RRs (and IPD-related PTR RRs) in Master Files conforms to Section 5, "Master Files," of RFC 1035. Below are examples of the use of these RRs in Master Files to support name-to- IPD and IPD-to-name mapping. S1.example.com. IPD 202.99.0.9:172.18.10.8 8.10.18.172.9.0.99.202.IPD.INT PTR S1.example.com. 7. Security Considerations Security issues are not discussed in this memo. Diao Expires July 04, 2007 [Page 09] Internet-Draft January 2007 8. Acknowledgments Author likes to thank everybody for their valuable opinion and evaluation to this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 791] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, September 1981. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC1706] B. Manning, and R. Colella, "DNS NSAP Resource Records", RFC 1706, October 1994. [RFC3596] S. Thomson, C. Huitema, V. Ksinant, and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [RFC2782] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 9.2. Informative References [Intenet draft] "draft-diao-eipv4-01.txt", work in progress, http://www.ietf.org/internet-drafts/draft-diao-eipv4-01.txt Diao Expires July 04, 2007 [Page 10] Internet-Draft January 2007 Authors' Addresses Diao Yongping China Telecom-Guangzhou Institute 109 West Zhongshan Ave Guangzhou, China. 510630 Phone: +86 20 38639732 Email: diao@gsta.com, diaoyp@yahoo.com Diao Expires July 04, 2007 [Page 11] Internet-Draft January 2007 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Diao Expires July 04, 2007 [Page 12]