Skip to main content

IPv6 only iterative resolver utilising NAT64
draft-momoka-v6ops-ipv6-only-resolver-00

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".
Authors Momoka Yamamoto , Toyota Yasunobu
Last updated 2022-10-05
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-momoka-v6ops-ipv6-only-resolver-00
v6ops                                            山本 桃歌 (M. Yamamoto)
Internet-Draft                      The University of Tokyo/WIDE Project
Intended status: Informational                                 Y. Toyota
Expires: 8 April 2023                       Keio University/WIDE Project
                                                          5 October 2022

              IPv6 only iterative resolver utilising NAT64
                draft-momoka-v6ops-ipv6-only-resolver-00

Abstract

   By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers
   can operate in an IPv6-only environment.  When a specific DNS zone is
   only served by an IPv4-only authoritative server, the iterative
   resolver will translate the IPv4 address to IPv6 to access the
   authoritative server's IPv4 address via NAT64.  This mechanism allows
   IPv6-only iterative resolvers to initiate communications to IPv4-only
   authoritative servers.

Discussion Venues

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

   Discussion of this document takes place on the IPv6 Operations
   Working Group mailing list (v6ops@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/v6ops/.

   Source for this draft and an issue tracker can be found at
   https://github.com/momoka0122y/draft-momoka-ipv6-only-resolver.

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 8 April 2023.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 1]
Internet-Draft             IPv6 only Resolver               October 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 (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation and Problem Solved . . . . . . . . . . . . . . . .   3
   4.  Solution with existing protocols  . . . . . . . . . . . . . .   4
     4.1.  Finding an Authoritative server with only IPv4
           addresses . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Generation of the IPv6 Representations of IPv4
           Addresses . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.1.  Obtaining the Pref64::/n of the NAT64 . . . . . . . .   4
       4.2.2.  Performing the Synthesis  . . . . . . . . . . . . . .   5
     4.3.  Use of the iterative resolver as DNS64  . . . . . . . . .   5
   5.  Deployment Notes  . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Deployment Scenarios and Examples . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document describes how an IPv6-only iterative resolver can use
   NAT64 [NAT64] to connect to an IPv4-only authoritative server by
   performing IPv4 to IPv6 translation [RFC6052].  When a specific DNS
   zone is only served by an IPv4-only authoritative server (which has
   only an A record), an IPv6-only iterative resolver cannot resolve
   that zone due to having no access to an IPv4 network.  However, by
   performing IPv4 to IPv6 translation and utilizing the NAT64,
   accessing an IPv4-only authoritative server will be possible.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 2]
Internet-Draft             IPv6 only Resolver               October 2022

2.  Terminology

   *  Iterative resolver: A DNS server that repeatedly makes non-
      recursive queries and follows referrals and/or aliases.  The
      iterative resolution algorithm is described in Section 5.3.3 of
      [RFC1034]

   *  IPv6-only iterative resolvers: Iterative resolvers that only have
      IPv6 connectivity.

   *  IPv6/IPv4 translator: A device that translates IPv6 packets to
      IPv4 packets and vice versa.  It is only required that the
      communication initiated from the IPv6 side be supported.

   *  IPv4-only authoritative server: An authoritative server with only
      IPv4 connectivity, or an authoritative server with only an A
      record registered so it can only be accessed by IPv4.

3.  Motivation and Problem Solved

   Over the past decade, IPv6 capabilities have been widely deployed,
   and IPv6 traffic is growing faster than IPv4 traffic.  An overview of
   IPv6 deployment status and how network operators are implementing
   IPv6 is provided by the document [ietf-v6ops-ipv6-deployment].  Most
   IPv6 deployments as of 2022 use a dual-stack strategy [RFC4213].
   However, the deployment of IPv6-only networks is also in progress, as
   demonstrated by [draft-XIE-v6ops-framework-md-ipv6only-underlay].  By
   operating an IPv6-only network and limiting IPv4 reachability to
   NAT64 devices, operators can reduce IPv4 usage and concentrate on
   IPv6 operations, which is generally believed to lower operational
   costs and optimize operations compared to a dual-stack environment.

   An iterative resolver is one of the applications that require IPv4
   connectivity.  As stated in BCP91 [RFC3901], "every recursive name
   server SHOULD be either IPv4-only or dual stack."  This is because
   some authoritative servers do not support IPv6.  As of 2022, even
   some of the most frequently queried authoritative servers cannot be
   accessed via IPv6.  Without the utilization of NAT64, IPv6-only
   recursive resolvers need to forward queries to a dual-stack recursive
   name server performing the iterative queries.

   The current situation where an iterative resolver cannot be operated
   without IPv4 reachability may hinder the operation of a network's own
   iterative resolver in an IPv6-only network.  Therefore, this document
   describes how iterative resolvers can be used without issues in
   IPv6-only networks by utilizing NAT64.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 3]
Internet-Draft             IPv6 only Resolver               October 2022

   The NAT64/DNS64 mechanism enables IPv6-only clients in a network to
   communicate with remote IPv4-only nodes.  However, using literal IPv4
   addresses instead of DNS names will fail (unless 464XLAT [RFC8683] is
   used).  An iterative resolver cannot use the DNS64 because it is a
   service that uses literal IP addresses (and also because the DNS64
   may depend on the resolver itself).  This problem can be solved by
   the iterative resolver converting IPv4 addresses to IPv6 by adding
   the Pref64::/n prefix, which instructs the NAT64 to convert the IPv6
   packets to IPv4 packets.  With this implementation, an iterative
   resolver can be operated even inside an IPv6-only network.

4.  Solution with existing protocols

   This section provides the mechanism of an IPv6-only resolver
   utilizing the NAT64.  We'll assume we have one or more IPv6/IPv4
   translator boxes [NAT64] connecting an IPv6 network to an IPv4
   network.  The NAT64 device provides translation service and bridges
   the two networks, allowing communication between IPv6-only hosts and
   IPv4-only hosts.  The IPv6-only resolver proposed in this document
   performs the IPv4 to IPv6 synthesis for the resolver to communicate
   with IPv4 servers via NAT64.  By using NAT64, this IPv6-only
   iterative resolver can be considered dual stack in the sense of
   [RFC3901].

4.1.  Finding an Authoritative server with only IPv4 addresses

   Before the server sends queries, it may sort the SLIST data structure
   described in [RFC1034] to use the servers with IPv6 addresses first
   and use servers with only an IPv4 address to be used later.  If the
   resolver only finds an A record for the authoritative server, the
   resolver should perform address synthesis to the IPv4 address of the
   authoritative server.  It is not recommended to synthesize IPv4
   addresses of an authoritative server if it also has an IPv6 address.

4.2.  Generation of the IPv6 Representations of IPv4 Addresses

4.2.1.  Obtaining the Pref64::/n of the NAT64

   The iterative resolver can obtain the Pref64::/n used by the NAT64 of
   the network by either static configuration or by using discovery
   mechanisms.  Static configuration may be the most likely scenario,
   given that the iterative resolver server may also serve as a DNS64
   server.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 4]
Internet-Draft             IPv6 only Resolver               October 2022

   The Port Control Protocol [RFC7225] or Router Advertisements
   [RFC8781] are two options the resolver has if it wants to use a
   discovery mechanism to find the Pref64::/n.  Using the mechanisms
   described in [RFC7050] or [draft-hunek-v6ops-nat64-srv] may not
   function because these need a resolver to work.

4.2.2.  Performing the Synthesis

   The address translation can be performed by following Section 2.3 of
   [RFC6052].  After the synthesis is done, the IPv6-only iterative
   resolver can send a query to the converted IPv6 address.

4.3.  Use of the iterative resolver as DNS64

   Since the iterative resolver will be used inside an IPv6-only
   network, the server can also perform DNS64 [DNS64] when an AAAA
   record is queried from a STUB resolver but the domain only has an A
   record.

5.  Deployment Notes

   TODO

5.1.  Deployment Scenarios and Examples

   In examples of past RFCs, name resolvers have always had an IPv4
   address.  For example, all three use cases for DNS64 in RFC 6147 are
   dual-stack name servers.

   However, it is necessary to consider the existence of an IPv6 single-
   stack full-service resolver with DNS64 capabilities.

               +---------------------+         +---------------+
               |IPv6 network         |         |    IPv4       |
               |           |  +-------------+  |  Internet     |
               |           |--| Name server |--|               |
               |           |  | with DNS64  |  |  +----+       |
               |  +----+   |  +-------------+  |  | H2 |       |
               |  | H1 |---|         |         |  +----+       |
               |  +----+   |   +------------+  |  192.0.2.1    |
               |           |---| IPv6/IPv4  |--|               |
               |           |   | Translator |  |               |
               |           |   +------------+  |               |
               |           |         |         |               |
               +---------------------+         +---------------+

      Figure 1: Example network setup of the use of DNS64 described in
                             RFC6147 Section7.1

Yamamoto & Toyota         Expires 8 April 2023                  [Page 5]
Internet-Draft             IPv6 only Resolver               October 2022

               +---------------------+         +---------------+
               |IPv6 network         |         |    IPv4       |
               |           |     +--------+    |  Internet     |
               |           |-----| Name   |----|               |
               | +-----+   |     | server |    |  +----+       |
               | | H1  |   |     +--------+    |  | H2 |       |
               | |with |---|         |         |  +----+       |
               | |DNS64|   |   +------------+  |  192.0.2.1    |
               | +----+    |---| IPv6/IPv4  |--|               |
               |           |   | Translator |  |               |
               |           |   +------------+  |               |
               |           |         |         |               |
               +---------------------+         +---------------+

      Figure 2: Example network setup of the use of DNS64 described in
                             RFC6147 Section7.2

   However, in this document we consider an IPv6-only network where the
   iterative resolver is inside the IPv6-only network and does not have
   an IPv4 address.  This is to contain IPv4 management to only the
   NAT64 device.

         +--------------------------+         +----------------------+
         | IPv6 network             |         |    IPv4              |
         |                          |         |  Internet            |
         |                          |         |                      |
         | +----------+             |         |  +--------------+    |
         | |IPv6-only |   |         |         |  |Authoritative |    |
         | |Iterative |   |         |         |  |server        |    |
         | |resolver  |---|   +------------+  |  +--------------+    |
         | +----------+   |---| IPv6/IPv4  |--|  192.0.2.1           |
         |                |   | Translator |  |                      |
         |                    +------------+  |                      |
         |                          |         |                      |
         +--------------------------+         +----------------------+

            Figure 3: A network example this document refers to

6.  Security Considerations

   TODO Security

   Write about DNSSEC Validators and DNS64.

   This algorithm does not alter any part of the DNS message but only
   changes the packet type from IPv4 to IPv6 and the destination IP
   Address from an IPv4 address to the synthesized IPv6 address, so
   there shouldn't be any problems with DNSSEC.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 6]
Internet-Draft             IPv6 only Resolver               October 2022

7.  IANA Considerations

   This document has no IANA actions.

8.  Implementation Status

   TODO: write this part and mail BIND.

   Bind has an WIP branch.

   https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6334/
   commits

   Unbound has a PR from a contributor.
   https://github.com/NLnetLabs/unbound/issues/721

9.  References

9.1.  Normative References

   [DNS64]    Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              DOI 10.17487/RFC6147, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6147>.

   [NAT64]    Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/rfc/rfc6146>.

   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
              Guidelines", BCP 91, RFC 3901, DOI 10.17487/RFC3901,
              September 2004, <https://www.rfc-editor.org/rfc/rfc3901>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <https://www.rfc-editor.org/rfc/rfc6052>.

9.2.  Informative References

   [draft-hunek-v6ops-nat64-srv]
              Huněk, M., "NAT64/DNS64 detection via SRV Records", Work
              in Progress, Internet-Draft, draft-hunek-v6ops-nat64-srv-
              03, 12 June 2022, <https://datatracker.ietf.org/doc/html/
              draft-hunek-v6ops-nat64-srv-03>.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 7]
Internet-Draft             IPv6 only Resolver               October 2022

   [draft-XIE-v6ops-framework-md-ipv6only-underlay]
              Xie, C., Ma, C., Li, X., Mishra, G. S., Boucadair, M., and
              T. Graf, "Framework of Multi-domain IPv6-only Underlay
              Networks and IPv4 as a Service", Work in Progress,
              Internet-Draft, draft-xie-v6ops-framework-md-ipv6only-
              underlay-04, 14 September 2022,
              <https://datatracker.ietf.org/doc/html/draft-xie-v6ops-
              framework-md-ipv6only-underlay-04>.

   [ietf-v6ops-ipv6-deployment]
              Fioccola, G., Volpato, P., Elkins, N., Martinez, J. P.,
              Mishra, G. S., and C. Xie, "IPv6 Deployment Status", Work
              in Progress, Internet-Draft, draft-ietf-v6ops-ipv6-
              deployment-07, 29 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
              ipv6-deployment-07>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/rfc/rfc1034>.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213,
              DOI 10.17487/RFC4213, October 2005,
              <https://www.rfc-editor.org/rfc/rfc4213>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/rfc/rfc7050>.

   [RFC7225]  Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
              Port Control Protocol (PCP)", RFC 7225,
              DOI 10.17487/RFC7225, May 2014,
              <https://www.rfc-editor.org/rfc/rfc7225>.

   [RFC8683]  Palet Martinez, J., "Additional Deployment Guidelines for
              NAT64/464XLAT in Operator and Enterprise Networks",
              RFC 8683, DOI 10.17487/RFC8683, November 2019,
              <https://www.rfc-editor.org/rfc/rfc8683>.

   [RFC8781]  Colitti, L. and J. Linkova, "Discovering PREF64 in Router
              Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
              2020, <https://www.rfc-editor.org/rfc/rfc8781>.

Yamamoto & Toyota         Expires 8 April 2023                  [Page 8]
Internet-Draft             IPv6 only Resolver               October 2022

Acknowledgments

   TODO acknowledge people.

   Thank you for reading this draft.

Authors' Addresses

   Momoka Yamamoto
   The University of Tokyo/WIDE Project
   Email: momoka.my6@gmail.com

   Additional contact information:

      山本 桃歌
      The University of Tokyo/WIDE Project

   Toyota Yasunobu
   Keio University/WIDE Project
   Email: yasnyan@sfc.wide.ad.jp

Yamamoto & Toyota         Expires 8 April 2023                  [Page 9]