Simple Provisioning of Reverse IPv4 Names
draft-richardson-ipv4-reverse-in-v6-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Michael Richardson | ||
Last updated | 2022-12-03 | ||
RFC stream | (None) | ||
Formats | |||
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) |
draft-richardson-ipv4-reverse-in-v6-00
Homenet M. Richardson Internet-Draft Sandelman Software Works Intended status: Standards Track 3 December 2022 Expires: 6 June 2023 Simple Provisioning of Reverse IPv4 Names draft-richardson-ipv4-reverse-in-v6-00 Abstract Merges IPv4 reverse names into IPv6 reverse maps, particularly for IPv6 delegations that are managed automatically. 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 https://datatracker.ietf.org/drafts/current/. 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 6 June 2023. 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 (https://trustee.ietf.org/ 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. Richardson Expires 6 June 2023 [Page 1] Internet-Draft public-names December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Protocol Proposal . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Operator changes . . . . . . . . . . . . . . . . . . . . 3 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, but resolvers that paid attention to that update, also likely would follow the CNAME in the reverse) 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 rational is that IPv6 operations can only be scaled well when completely automated, and the custom configurations for the IPv4 delegation get 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. Richardson Expires 6 June 2023 [Page 2] Internet-Draft public-names December 2022 2. Protocol Proposal [RFC2317] initially proposes to make the delegated zone a subzone of the IPv4 reverse, such as having '128/26.2.0.192.in-addr.arpa' be the delegation from '2.0.192.in-addr.arpa' (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 [I-D.ietf-homenet-front-end-naming-delegation]. 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 192.0.2.234, where the customer has the IPv6 prefix 2001:db8:cake::/64 delegated, be mapped as follows: 234.2.0.192.in-addr.arpa IN CNAME 234.2.0.192.0.0.0.0.e.k.a.c.8.d.b.0.1.0.0.2.ip6.arpa. Note that the resulting name in the IP6 space will always be shorter than any IPv6 name, so even if a number like 8.8.8.8 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. Richardson Expires 6 June 2023 [Page 3] Internet-Draft public-names December 2022 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 [I-D.ietf-homenet-naming-architecture-dhc-options]. 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 192.0.2.234, with a reverse name of "webserver.example", then it must create a new PTR record like: 234.2.0.192.0.0.0.0.e.k.a.c.8.d.b.0.1.0.0.2.ip6.arpa 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. -- back 4. References 4.1. Normative References [I-D.ietf-homenet-front-end-naming-delegation] Migault, D., Weber, R., Richardson, M., and R. Hunter, "Simple Provisioning of Public Names for Residential Networks", Work in Progress, Internet-Draft, draft-ietf- homenet-front-end-naming-delegation-22, 31 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-homenet- front-end-naming-delegation-22>. [I-D.ietf-homenet-naming-architecture-dhc-options] 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, <https://datatracker.ietf.org/doc/html/draft-ietf-homenet- naming-architecture-dhc-options-24>. Richardson Expires 6 June 2023 [Page 4] Internet-Draft public-names December 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, <https://www.rfc-editor.org/rfc/rfc2317>. 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, <https://www.rfc-editor.org/rfc/rfc9313>. Author's Address Michael Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 Canada Email: mcr+ietf@sandelman.ca Richardson Expires 6 June 2023 [Page 5]