Connected: An Internet Encyclopedia
RFC 1519 - 7.2 Procedural changes for class-A subnetting

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1519
Up: 7. Domain Service considerations
Prev: 7.1 Procedural changes for class-C supernets
Next: 8. Transitioning to a long term solution

### 7.2 Procedural changes for class-A subnetting

Should it be the case the class-A network numbers are subdivided into blocks allocated to transit network providers, it will be similarly necessary to relax the restriction on how IN-ADDR.ARPA naming works for them. As an example, take a provider is allocated the 19-bit portion of address space which matches 10.8.0.0 with mask 255.248.0.0. This represents all addresses which begin with the prefixes 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, an 10.15 and requires the following IN-ADDR.ARPA delegations:

               8.10.IN-ADDR.ARPA.      IN      NS      NS1.MOBY.NET.

               9.10.IN-ADDR.ARPA.      IN      NS      NS1.MOBY.NET.

                       ....

               15.10.IN-ADDR.ARPA.     IN      NS      NS1.MOBY.NET.

To further illustrate how IN-ADDR.ARPA sub-delegation will work, consider a company named "FOO" connected to this provider which has been allocated the 14-bit piece of address space which matches 10.10.64.0 with mask 255.255.192.0. This represents all addresses in the range 10.10.64.0 through 10.10.127.255 and will require that the provider implement the following IN-ADDR.ARPA delegations:

               64.10.10.IN-ADDR.ARPA.  IN      NS      NS1.FOO.COM.

               65.10.10.IN-ADDR.ARPA.  IN      NS      NS1.FOO.COM.

                       ....

               127.10.10.IN-ADDR.ARPA. IN      NS      NS1.FOO.COM.

with the servers for "FOO.COM" containing the individual PTR records for all of the addresses on each of these subnets.

Next: 8. Transitioning to a long term solution

Connected: An Internet Encyclopedia
RFC 1519 - 7.2 Procedural changes for class-A subnetting