Classless IN-ADDR.ARPA delegation
RFC 2317

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                         H. Eidnes
Request for Comments: 2317                                 SINTEF RUNIT
BCP: 20                                                     G. de Groot
Category: Best Current Practice          Berkeley Software Design, Inc.
                                                               P. Vixie
                                           Internet Software Consortium
                                                             March 1998

                   Classless IN-ADDR.ARPA delegation

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

2. Introduction

   This document describes a way to do IN-ADDR.ARPA delegation on non-
   octet boundaries for address spaces covering fewer than 256
   addresses.  The proposed method should thus remove one of the
   objections to subnet on non-octet boundaries but perhaps more
   significantly, make it possible to assign IP address space in smaller
   chunks than 24-bit prefixes, without losing the ability to delegate
   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
   method is fully compatible with the original DNS lookup mechanisms
   specified in [1], i.e. there is no need to modify the lookup
   algorithm used, and there should be no need to modify any software
   which does DNS lookups.

   The document also discusses some operational considerations to
   provide some guidance in implementing this method.

3. Motivation

   With the proliferation of classless routing technology, it has become
   feasible to assign address space on non-octet boundaries.  In case of
   a very small organization with only a few hosts, assigning a full
   24-bit prefix (what was traditionally referred to as a "class C
   network number") often leads to inefficient address space
   utilization.

Eidnes, et. al.          Best Current Practice                  [Page 1]
RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

   One of the problems encountered when assigning a longer prefix (less
   address space) is that it seems impossible for such an organization
   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
   use of the reverse delegation method described below, the most
   important objection to assignment of longer prefixes to unrelated
   organizations can be removed.

   Let us assume we have assigned the address spaces to three different
   parties as follows:

           192.0.2.0/25   to organization A
           192.0.2.128/26 to organization B
           192.0.2.192/26 to organization C

   In the classical approach, this would lead to a single zone like
   this:

   $ORIGIN 2.0.192.in-addr.arpa.
   ;
   1               PTR     host1.A.domain.
   2               PTR     host2.A.domain.
   3               PTR     host3.A.domain.
   ;
   129             PTR     host1.B.domain.
   130             PTR     host2.B.domain.
   131             PTR     host3.B.domain.
   ;
   193             PTR     host1.C.domain.
   194             PTR     host2.C.domain.
   195             PTR     host3.C.domain.

   The administration of this zone is problematic.  Authority for this
   zone can only be delegated once, and this usually translates into
   "this zone can only be administered by one organization."  The other
   organizations with address space that corresponds to entries in this
   zone would thus have to depend on another organization for their
   address to name translation.  With the proposed method, this
   potential problem can be avoided.

4. Classless IN-ADDR.ARPA delegation

   Since a single zone can only be delegated once, we need more points
   to do delegation on to solve the problem above.  These extra points
   of delegation can be introduced by extending the IN-ADDR.ARPA tree
   downwards, e.g. by using the first address or the first address and
   the network mask length (as shown below) in the corresponding address

Eidnes, et. al.          Best Current Practice                  [Page 2]
RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

   space to form the the first component in the name for the zones.  The
   following four zone files show how the problem in the motivation
   section could be solved using this method.

   $ORIGIN 2.0.192.in-addr.arpa.
   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
   ;...
   ;  <<0-127>> /25
   0/25            NS      ns.A.domain.
   0/25            NS      some.other.name.server.
   ;
   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
   ;
   ;  <<128-191>> /26
   128/26          NS      ns.B.domain.