RFC 2317 (rfc2317) - Page 2 of 10
Classless IN-ADDR
Alternative Format: Original Text Document
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