Classless IN-ADDR.ARPA delegation (RFC2317)
Original Publication Date: 1998-Mar-01
Included in the Prior Art Database: 2019-Feb-15
Internet Society Requests For Comment (RFCs)
H. Eidnes: AUTHOR [+2]
This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
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 (C) The Internet Society (1998). All Rights Reserved.
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 , 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.
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...