NAT64/DNS64 detection via SRV Records
draft-ietf-v6ops-nat64-srv-00

Document Type Active Internet-Draft (v6ops WG)
Last updated 2019-03-11
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
IPv6 Operations (v6ops)                                    Martin Hunek
Internet-Draft                          Technical University of Liberec
Intended status: Standards Track                         March 11, 2019
Expires: September 11, 2019

                NAT64/DNS64 detection via SRV Records
                    draft-ietf-v6ops-nat64-srv-00

Abstract

   This document specifies the way of discovering the NAT64 pools in
   use as well as DNS servers providing DNS64 service to the local
   clients. The discovery is done via SRV records, which also allows
   asignment of priorities to the NAT64 pools as well as DNS64 servers.
   It also allows clients to have diferent DNS providers than NAT64
   provider, while providing a secure way via DNSSEC validation of
   provided SRV records. This way, it provides DNS64 service even in
   case where DNS over HTTPS is used.
   
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 September 11, 2019

Copyright Notice

   Copyright (c) 2019 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
   (http://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 Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.
   
Martin Hunek          Expires September 11, 2019               [Page 1]
INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 2019

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    1.1. Requirements Language . . . . . . . . . . . . . . . . . . .  3
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. NAT64 service SRV record . . . . . . . . . . . . . . . . . . .  3
   4. DNS64 service SRV record . . . . . . . . . . . . . . . . . . .  4
   5. Node Behavior  . . . . . . . . . . . . . . . . . . . . . . . .  4
    5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7. Security considerations  . . . . . . . . . . . . . . . . . . .  7
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
    8.1. Normative References  . . . . . . . . . . . . . . . . . . .  7
    8.2. Informative References  . . . . . . . . . . . . . . . . . .  8
    
Martin Hunek          Expires September 11, 2019               [Page 2]
INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 2019

1. Introduction

   The simultaneous use of NAT64/DNS64 and DNSSEC outlined by
   [RFC7050], does not solve all the aspects of such use. Namely
   [RFC7050] does not allow assignment of NAT64 priorities in case when
   multiple network prefixes are in use. [RFC7050] also doesn't work in
   the case when network operator and DNS operator are not the same
   subject, like in the case when the end node is using some public DNS
   resolvers. This document describes the way how to circumvent that
   limitation while maintaining added security provided by DNSSEC.

1.1. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described
   in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in
   all capitals, as shown here.

2. Terminology

   End node: Either DNS stub resolver or the DNS recursive resolver
   serving a local area network or station.

   Pref64::/n: an IPv6 prefix used for IPv6 address synthesis
   [RFC6146].

   Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at
   any of the locations allowed by [RFC6052].

   Well-Known IPv4 Address (WKA): an IPv4 address that is well-known
   and present in an A record for the well-known name. Two well-known
   IPv4 addresses are defined for Pref64::/n discovery purposes:
   192.0.0.170 and 192.0.0.171.

3. NAT64 service SRV record

   This document specifies two new well-known SRV records. The one for
Show full document text