Skip to main content

Simple Provisioning of Reverse IPv4 Names

Document Type Active Internet-Draft (individual)
Author Michael Richardson
Last updated 2022-12-08
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Homenet                                                    M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                         8 December 2022
Expires: 11 June 2023

               Simple Provisioning of Reverse IPv4 Names


   Merges IPv4 reverse names into IPv6 reverse maps, particularly for
   IPv6 delegations that are managed automatically.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at

   Discussion of this document takes place on the homenet Working Group
   mailing list (, which is archived at  Subscribe at

   Source for this draft and an issue tracker can be found at

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 June 2023.

Richardson                Expires 11 June 2023                  [Page 1]
Internet-Draft                public-names                 December 2022

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Protocol Proposal . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Operator changes  . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Home Naming Architecture (HNA) changes  . . . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Many small offices get customized service from boutique ISPs.  This
   has historically included delegation of one or a small number (8 to
   16) of statically assigned IPv4 addresses.

   Populating the reverse zone for such small delegations has often
   meant using [RFC2317] style delegation.

   [RFC2317] delegation still requires that the ISP delegate the zone to
   the customer, collect NS and DS records, and in most cases, that the
   ISP arranges to become a secondary for the zone.

   Experience by early adopters was that not every stub resolver would
   do a second query when a CNAME record was found in the reverse zone
   rather than a PTR, but if the PTR was returned as additional
   information in the same query, that it would in fact work.  (Later
   specifications make stub resolvers ignore this additional
   information.  Resolvers that paid attention to that update, also
   likely would follow the CNAME in the reverse.)

Richardson                Expires 11 June 2023                  [Page 2]
Internet-Draft                public-names                 December 2022

   This custom configuration required to do [RFC2317] delegation often
   has been a drag for many operators, and in some cases has resulted in
   delays to making IPv6 available to this smaller offices.  The
   rationale is that IPv6 operations can only be scaled well when
   completely automated, and the custom configurations for the IPv4
   delegation gets in the way of such things.

   This document proposes to leverage the work of
   [I-D.ietf-homenet-front-end-naming-delegation] and
   [I-D.ietf-homenet-naming-architecture-dhc-options] to automate the
   delegation of [RFC2317] reverse zones for IPv4 delegations.

2.  Protocol Proposal

   [RFC2317] initially proposes to make the delegated zone a subzone of
   the IPv4 reverse, such as having '128/' be the
   delegation from ''

   (The use of '/' as the separator has become a problem for many
   operators due the way that zone names are translated to file names,
   and has often been replaced with another character like '-')

   In [RFC2317], Section 5.2 suggests putting the reverse names into the
   forward zone.  This document proposes to put the IPv4 reverse names
   into the IPv6 reverse zone, which can be automatically delegated to
   the Home Naming Architecture described in

   All of this can be done today through bilateral convention: as long
   as the HNA and the ISP's IPv4 Address Management system agree to use
   the same names in the CNAMEs, everything works.  This document
   proposes a universal mechanism to enable interoperation without
   bilateral agreement.

   IPv4 reverse names are done by octet in decimal, while IPv6 is done
   by hexadecimal digit by nibble.  In order to allow for the maximum
   interoperation for cases where multiple IPv4 addresses are delegated,
   but not from the same prefix, all IPv4 octets should be included in
   the mapped address.

   It is therefore proposed that the reverse name for an address, where the customer has the IPv6 prefix
   2001:db8:cake::/64 delegated, be mapped as follows: IN CNAME

Richardson                Expires 11 June 2023                  [Page 3]
Internet-Draft                public-names                 December 2022

   Note that the resulting name in the IP6 space will always be shorter
   than any IPv6 name, so even if a number like were mapped
   (which could very well be read as an IPv6 nibble grouping), there
   should never be a conflict.

2.1.  Operator changes

   The only thing that the operator has to do differently is to insert
   the right CNAMEs into its reverse IPv4 DNS.  These can be generated
   by a custom script for their IP Address Manager which will know what
   IPv6 delegations have been made, and which IPv4 static delegations
   are involved.

   All of the DNS operational activities like DNSSEC, NS records, and
   the like would now be handled by the mechanisms of
   [I-D.ietf-homenet-front-end-naming-delegation] and

2.2.  Home Naming Architecture (HNA) changes

   The HNA mechanism responsible for creating the reverse map needs to
   take into account any static IPv4 addresses that are delegated to it.
   This may be via PPP IPCP, or DHCPv4 for the first address, and by
   some IPv4 as a service to get additional addresses.  It is probably
   that the addresses will have to be statically configured for some
   time.  (Note that the services described by [RFC9313] are all
   mechanisms to share an IPv4 among many subscribers, not delegate a
   single IPv4 address)

   For an address like, with a reverse name of
   "webserver.example", then it must create a new PTR record like: IN PTR webserver.example.

3.  Security Considerations

   The presence of the additional PTR records may be easily enumerated
   due to the much smaller IPv4 space.  That will reveal which names are
   active in IPv4 space for the enterprise using this technique.

4.  References

4.1.  Normative References

              Migault, D., Weber, R., Richardson, M., and R. Hunter,
              "Simple Provisioning of Public Names for Residential
              Networks", Work in Progress, Internet-Draft, draft-ietf-

Richardson                Expires 11 June 2023                  [Page 4]
Internet-Draft                public-names                 December 2022

              homenet-front-end-naming-delegation-24, 5 December 2022,

              Migault, D., Weber, R., and T. Mrugalski, "DHCPv6 Options
              for Home Network Naming Authority", Work in Progress,
              Internet-Draft, draft-ietf-homenet-naming-architecture-
              dhc-options-24, 31 October 2022,

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", BCP 20, RFC 2317,
              DOI 10.17487/RFC2317, March 1998,

4.2.  Informative References

   [RFC9313]  Lencse, G., Palet Martinez, J., Howard, L., Patterson, R.,
              and I. Farrer, "Pros and Cons of IPv6 Transition
              Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313,
              DOI 10.17487/RFC9313, October 2022,

Author's Address

   Michael Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7

Richardson                Expires 11 June 2023                  [Page 5]