Internet DRAFT - draft-eromenko-ipff-dns
draft-eromenko-ipff-dns
INTERNET-DRAFT
"Internet Protocol Five Fields - Domain Name System extensions",
Alexey Eromenko, 2016-09-29,
<draft-eromenko-ipff-dns-02.txt>
expiration date: 2017-03-29
Intended status: Standards Track
A.Eromenko
September 2016
DNS Extensions to Support IP Version 5
(a.k.a Internet Protocol "Five Fields")
Specification Draft
Abstract
This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 5 (IPFF). The
changes include a resource record type to store an IPFF address, a
domain to support lookups based on an IPFF address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. New resource record definition and domain. . . . . . . . . . . 2
2.1. AA record type . . . . . . . . . . . . . . . . . . . . . 3
2.2. AA data format . . . . . . . . . . . . . . . . . . . . . 3
2.3. AA query . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4. Textual format of AA records . . . . . . . . . . . . . . 3
2.5. Reverse Lookups and PTR records. . . . . . . . . . . . . 3
3. Modifications to existing query types. . . . . . . . . . . . . 4
4. Enforcing 999-per-field limit. . . . . . . . . . . . . . . . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 4
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Contacts . . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Current support for the storage of Internet addresses in the Domain
Name System (DNS) cannot easily be extended to support IPFF
addresses [IPFF-Addressing-RFC-draft] since applications assume that
address queries return 32-bit IPv4 or 128-bit IPv6 addresses only.
To support the storage of IPFF addresses in the DNS, this document
defines the following extensions:
o A resource record type is defined to map a domain name to an
IPFF address.
o A domain is defined to support lookups based on address.
o Existing queries that perform additional section processing to
locate IPFF addresses are redefined to perform additional
section processing on both IPv4 and IPFF addresses.
The changes are designed to be compatible with existing software.
The existing support for IPv4 addresses is retained.
The IP protocol version used for querying resource records is
independent of the protocol version of the resource records; e.g.,
IPv4 or IPv6 transport can be used to query IPFF records and vice
versa.
2. New resource record definition and domain
A record type is defined to store a host's IPFF address. A host that
has more than one IPFF address must have more than one such record.
AA explanation:
"AA record" was chosen, as it mimics the idea behind "A" being a
32-bit value of IPv4, compared to "AAAA" (Quad A) being a 128-bit
value of IPv6. Since internal representation of 50-bit addresses in
IPFF are pre-padded to full 64-bits, double A, or "AA" seems
appropriate.
The proposed draft value is to be determined...
2.1 AA record type
The AA resource record type is a record specific to the Internet
class that stores a single IPFF address.
2.2 AA data format
A 50 bit IPFF address is encoded in the data portion of an AA
resource record in network byte order (high-order byte first),
pre-padded by a set of 14-bit zeros, forming an internal 64-bit data
structure.
2.3 AA query
An AA query for a specified domain name in the Internet class
returns all associated AA resource records in the answer section of
a response.
A type AA query does not trigger additional section processing.
2.4 Textual format of AA records
The textual representation of the data portion of the AA resource
record used in a master database file is the textual representation
of an IPFF address as defined in [IPFF-Addressing-RFC-draft].
2.5 Reverse Lookups and PTR records
A special domain is defined to look up a record given an IPFF
address. The intent of this domain is to provide a way of mapping an
IPFF address to a host name, although it may be used for other
purposes as well. The domain is proposed to be IP5.ARPA.
An IPFF address is represented as a name in the IP5.ARPA domain by a
sequence of decimal digits separated by dots with the suffix
".IP5.ARPA". The sequence of digits is encoded in reverse order,
i.e., the low-order digit is encoded first, followed by the next
low-order digit and so on.
For example, the reverse lookup domain name corresponding to the
address
382.21.968.2.133
would be
3.3.1.2.0.0.8.6.9.1.2.0.2.8.3.IP5.ARPA
3. Modifications to existing query types
All existing query types that perform type A additional section
processing, i.e., name server (NS), location of services (SRV) and
mail exchange (MX) query types, must be redefined to perform both
type A and type AA additional section processing. These
definitions mean that a name server must add any relevant IPv4
addresses and any relevant IPFF addresses available locally to the
additional section of a response when processing any one of the above
queries.
4. Enforcing 999-per-field limit
IP-FF, be design has 10-bits per field, which theoretically allows
to put any values between 0 and 1023 into any field.
The valid addresses, however, are only up to 999.
Both DNS resolvers (DNS clients), and DNS servers MUST enforce this
limit; DNS Servers by refusing to write it, and clients by refusing
to accept resource records with field values higher than 999.
5. Security Considerations
This specification is not believed to cause any new security
problems, nor to solve any existing ones.
Acknowledgments
Thanks to all previous DNS and DNSv6 developers, paricularly those
people, "Susan Thomson", "Christian Huitema", "Vladimir Ksinant",
"Mohsen Souissi", whom written RFC-3596 (DNSv6).
Authors' Contacts
Alexey Eromenko
Israel
Skype: Fenix_NBK_
EMail: al4321@gmail.com
Facebook: https://www.facebook.com/technologov
INTERNET-DRAFT
Alexey
expiration date: 2017-03-29
