idnits 2.17.1 draft-yan-dprive-local-service-indication-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 21, 2019) is 1731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4339 ** Downref: Normative reference to an Experimental RFC: RFC 8094 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dprive Working Group Z. Yan 3 Internet-Draft G. Geng 4 Intended status: Standards Track CNNIC 5 Expires: January 22, 2020 July 21, 2019 7 Indication of Local DNS Privacy Service During User Access 8 draft-yan-dprive-local-service-indication-00 10 Abstract 12 This document aims to support the indication of privacy service of 13 recursive resolver during the user access. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in [RFC2119] 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 22, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. ICMPv6 based case . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Other configuration cases . . . . . . . . . . . . . . . . . . 2 58 4. Security considerations . . . . . . . . . . . . . . . . . . . 3 59 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 62 1. Introduction 64 In order to enhance the privacy protection in DNS, several solutions 65 have been developed to support the encrypted communications between 66 stub and recursive resolvers, such as DNS-over-DTLS [RFC8094], DNS- 67 over-TLS [RFC7858], DNS-over-QUIC and so on. However, a scheme is 68 needed in order to explicitly make the user aware of the privacy 69 service supported by the recursive resolver in order to avoid the 70 blind attempt by the user and support the user to bootstrap the 71 preferred privacy protocol more easily. This can be achieved during 72 the user initial access, using extended DHCPv6 or ICMPv6 to configure 73 its recursive resolver with related information (only IPv6 scenario 74 is considered here). 76 2. ICMPv6 based case 78 The "Recursive DNS Server Option" is defined in [RFC8106] to support 79 the user to configure DNS recursive resolver in the IPv6 SLAAC mode. 80 Then an x-bit flag in the Reserved field of "Recursive DNS Server 81 Option" can be used to indicate the privacy service of the 82 corresponding recursive resolver specified in the field of "Addresses 83 of IPv6 Recursive DNS Servers". However, if this function is used, 84 the "Addresses of IPv6 Recursive DNS Servers" should contain only one 85 address of recursive resolver. What the size of "x" and how to 86 specify the flag corresponding to the supported privacy service of 87 the recursive resolver will be detailed further. 89 3. Other configuration cases 91 The procedures based on the DHCPv6 or other configuration protocols 92 [RFC3646][RFC4339]will also be considered further. 94 4. Security considerations 96 TBA 98 5. Normative References 100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 101 Requirement Levels", BCP 14, RFC 2119, 102 DOI 10.17487/RFC2119, March 1997, 103 . 105 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 106 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 107 DOI 10.17487/RFC3646, December 2003, 108 . 110 [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server 111 Information Approaches", RFC 4339, DOI 10.17487/RFC4339, 112 February 2006, . 114 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 115 and P. Hoffman, "Specification for DNS over Transport 116 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 117 2016, . 119 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 120 Transport Layer Security (DTLS)", RFC 8094, 121 DOI 10.17487/RFC8094, February 2017, 122 . 124 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 125 "IPv6 Router Advertisement Options for DNS Configuration", 126 RFC 8106, DOI 10.17487/RFC8106, March 2017, 127 . 129 Authors' Addresses 131 Zhiwei Yan 132 CNNIC 133 No.4 South 4th Street, Zhongguancun 134 Beijing 100190 135 China 137 EMail: yan@cnnic.cn 138 Guanggang Geng 139 CNNIC 140 No.4 South 4th Street, Zhongguancun 141 Beijing 100190 142 China 144 EMail: ggg@cnnic.cn