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.
datatracker.ietf.org