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]