idnits 2.17.1 draft-yan-dprive-local-service-indication-02.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 12, 2020) is 1355 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 13, 2021 Y. Liu 6 CAICT 7 X. Zhang 8 Shandong Computer Science Center 9 July 12, 2020 11 Indication of Local DNS Privacy Service During User Access 12 draft-yan-dprive-local-service-indication-02 14 Abstract 16 This document aims to support the indication of privacy service of 17 recursive resolver during the user access. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119] 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 13, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. ICMPv6 based case . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Other configuration cases . . . . . . . . . . . . . . . . . . 3 62 4. Security considerations . . . . . . . . . . . . . . . . . . . 3 63 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 67 1. Introduction 69 In order to enhance the privacy protection in DNS, several solutions 70 have been developed to support the encrypted communications between 71 stub and recursive resolvers, such as DNS-over-DTLS [RFC8094], DNS- 72 over-TLS [RFC7858], DNS-over-QUIC and so on. However, a scheme is 73 needed in order to explicitly make the user aware of the privacy 74 service supported by the recursive resolver in order to avoid the 75 blind attempt by the user and support the user to bootstrap the 76 preferred privacy protocol more easily. This can be achieved during 77 the user initial access, using extended DHCPv6 or ICMPv6 to configure 78 its recursive resolver with related information (only IPv6 scenario 79 is considered here). 81 2. ICMPv6 based case 83 The "Recursive DNS Server Option" is defined in [RFC8106] to support 84 the user to configure DNS recursive resolver in the IPv6 SLAAC mode. 85 Then an x-bit flag in the Reserved field of "Recursive DNS Server 86 Option" can be used to indicate the privacy service of the 87 corresponding recursive resolver specified in the field of "Addresses 88 of IPv6 Recursive DNS Servers". However, if this function is used, 89 the "Addresses of IPv6 Recursive DNS Servers" should contain only one 90 address of recursive resolver. What the size of "x" and how to 91 specify the flag corresponding to the supported privacy service of 92 the recursive resolver will be detailed further. 94 3. Other configuration cases 96 The procedures based on the DHCPv6 or other configuration protocols 97 [RFC3646][RFC4339]will also be considered further. 99 4. Security considerations 101 TBA 103 5. Normative References 105 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 106 Requirement Levels", BCP 14, RFC 2119, 107 DOI 10.17487/RFC2119, March 1997, 108 . 110 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 111 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 112 DOI 10.17487/RFC3646, December 2003, 113 . 115 [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server 116 Information Approaches", RFC 4339, DOI 10.17487/RFC4339, 117 February 2006, . 119 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 120 and P. Hoffman, "Specification for DNS over Transport 121 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 122 2016, . 124 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 125 Transport Layer Security (DTLS)", RFC 8094, 126 DOI 10.17487/RFC8094, February 2017, 127 . 129 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 130 "IPv6 Router Advertisement Options for DNS Configuration", 131 RFC 8106, DOI 10.17487/RFC8106, March 2017, 132 . 134 Appendix A. Acknowledgments 136 This work was supported by Beijing Nova Program of Science and 137 Technology under grant Z191100001119113. 139 Authors' Addresses 141 Zhiwei Yan 142 CNNIC 143 No.4 South 4th Street, Zhongguancun 144 Beijing 100190 145 China 147 EMail: yan@cnnic.cn 149 Guanggang Geng 150 CNNIC 151 No.4 South 4th Street, Zhongguancun 152 Beijing 100190 153 China 155 EMail: ggg@cnnic.cn 157 Yang Liu 158 CAICT 159 No.52, Huayuanbeilu 160 Beijing 100191 161 China 163 EMail: liuyang7@caict.ac.cn 165 Xinchang Zhang 166 Shandong Computer Science Center 167 No.19 Keyuan Road, Lixia District 168 Jinan, 250014 169 P.R. China 171 EMail: xincha.zhang@gmail.com