


Network Working Group                                         A.Eromenko
Category: Proposed Standard                                November 2015


                 DNS Extensions to Support IP Version 5 
                (a.k.a Internet Protocol "Five Fields")
                        Specification Draft

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) by Alexey Eromenko (2015), based on RFC3596 of 
   The Internet Society (2003).  All Rights Reserved.

Abstract

   This document defines the changes that need to be made to the Domain
   Name System (DNS) to support hosts running IP version 5 (IPv5).  The
   changes include a resource record type to store an IPv5 address, a
   domain to support lookups based on an IPv5 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.

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.  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 IPv5
   addresses [IPv5-Addressing-RFC-draft] since applications assume that 
   address queries return 32-bit IPv4 or 128-bit IPv6 addresses only.

   To support the storage of IPv5 addresses in the DNS, this document
   defines the following extensions:

      o A resource record type is defined to map a domain name to an
        IPv5 address.

      o A domain is defined to support lookups based on address.

      o Existing queries that perform additional section processing to
        locate IPv5 addresses are redefined to perform additional
        section processing on both IPv4 and IPv5 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 IPv5 records and vice versa.

2. New resource record definition and domain

   A record type is defined to store a host's IPv5 address.  A host that
   has more than one IPv5 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 IPv5 are pre-padded
   to full 64-bits, double A, or "AA" seems appropritate.

   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 IPv5 address.

2.2 AA data format

   A 50 bit IPv5 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 IPv5 address as defined in [IPv5-Addressing-RFC-draft].

2.5 Reverse Lookups and PTR records

   A special domain is defined to look up a record given an IPv5
   address.  The intent of this domain is to provide a way of mapping an
   IPv5 address to a host name, although it may be used for other
   purposes as well.  The domain is proposed to be IP5.ARPA.

   An IPv5 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 IPv5 addresses available locally to the
   additional section of a response when processing any one of the above
   queries.

4. 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 
   written RFC-3596 (DNSv6).
   
Authors' Contacts

   Alexey Eromneko
   Israel

   Skype: Fenix_NBK_
   EMail: al4321@gmail.com


Full Copyright Statement

   Copyright (C) Alexey Eromenko (2015), based on the previous work of
   The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
