idnits 2.17.1 draft-xli-behave-dns46-for-stateless-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 17, 2017) is 2373 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bao 3 Internet-Draft X. Li 4 Intended status: Informational CERNET Center/Tsinghua 5 Expires: April 20, 2018 University 6 Y. Ma 7 Beijing University of Post and 8 Telecommunication 9 October 17, 2017 11 DNS46 for the IPv4/IPv6 Stateless Translator 12 draft-xli-behave-dns46-for-stateless-07 14 Abstract 16 The stateless translator can support IPv6-initiated communications as 17 well as IPv4-initiated communications for IPv6 hosts using IPv4- 18 translatable addresses. DNS support for the IPv6-initiated 19 communication is defined in the DNS64 specification. This document 20 defines the DNS46 function for the stateless translator. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 20, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 58 3. DNS46 for the IPv4/IPv6 Stateless Translator . . . . . . . . . 3 59 3.1. Authoritative DNS server . . . . . . . . . . . . . . . . . 3 60 3.1.1. Static AAAA record . . . . . . . . . . . . . . . . . . 3 61 3.1.2. Varying AAAA record . . . . . . . . . . . . . . . . . . 4 62 3.2. DNS resolver . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2.1. DNS resolver for scenario 6 . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 DNS mechanism is one of the functions model for the IPv4/IPv6 73 transition [RFC6144]. DNS64 allows IPv6 hosts to resolve names of 74 IPv4 hosts whereas DNS46 allows IPv4 hosts to resolve names of IPv6 75 hosts. 77 General DNS46 is considered harmful, as NAT-PT was deprecated by IETF 78 [RFC4966]. However, stateless translators can support IPv6-initiated 79 communications (scenario 1 and 3) which requires the DNS64 support 80 [RFC6146] [RFC6145], as well as IPv4-initiated communications 81 (scenario 2 and 4) which requires the DNS46 support [RFC6145]. 83 DNS64 is used for both stateful and stateless translators and it is 84 defined in [RFC6147]. DNS46 is only used for the stateless 85 translators and it is defines in this document. 87 2. Notational Conventions 89 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 90 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 91 document, are to be interpreted as described in [RFC2119]. 93 3. DNS46 for the IPv4/IPv6 Stateless Translator 95 The DNS46 for stateless IPv4/IPv6 translation is for the following 96 scenarios: 98 o Scenario 2: The IPv4 Internet to an IPv6 network. 100 o Scenario 6: An IPv4 network to an IPv6 network. 102 3.1. Authoritative DNS server 104 Since the destination is "an IPv6 network", DNS46 can be deployed as 105 an authoritative DNS server [RFC1035] in an IPv6 network. 107 3.1.1. Static AAAA record 109 This is very similar to the authoritative DNS configuration of dual- 110 stack hosts. The only difference is that in the dual-stack case, the 111 A record and AAAA record are independent, while in stateless 112 translation case, the hosts are typically IPv6 single stack (or for 113 some reason incapable of using IPv4 on a particular network) using 114 IPv4-translatable addresses and the A record MUST be derived from the 115 AAAA record based on the algorithm and the PREFIX information 117 [RFC6052]. 119 3.1.2. Varying AAAA record 121 If an IPv6 host has a varying AAAA record (that is, it could change 122 due to the IPv6-only host changing its IPv6 address and registering 123 its new address via, for example, DNS Dynamic Updates [RFC2316]), 124 then the dynamic DNS46 function is required. However, it is still 125 the authoritative DNS. When the authoritative DNS receives a dynamic 126 update containing AAAA record, it MUST synthesize corresponding A 127 record before signing the zone, which can be derived based on the 128 algorithm and the PREFIX information [RFC6052]. 130 3.2. DNS resolver 132 For scenario 2 (the IPv4 Internet to an IPv6 network) the 133 implementation of DNS46 resolver is almost impossible, since the IPv4 134 hosts are in the IPv4 Internet. 136 3.2.1. DNS resolver for scenario 6 138 However, for scenario 6 (an IPv4 network to IPv6 network) [RFC6144], 139 it is possible to use DNS resolver in an IPv4 network to synthesize A 140 records from the AAAA records based on the algorithm and the PREFIX 141 information [RFC6052]. 143 4. Security Considerations 145 When DNS46 function is provided by authoritative DNS server, DNS46 146 can support DNSSEC without problem. 148 When DNS46 function is provided by authoritative DNS server, the 149 reverse DNS is also under the same network operator's control which 150 may provide additional validation function for the IPv4-translatable 151 IPv6 addresses. 153 5. IANA Considerations 155 This memo adds no new IANA considerations. 157 Note to RFC Editor: This section will have served its purpose if it 158 correctly tells IANA that no new assignments or registries are 159 required, or if those assignments or registries are created during 160 the RFC publication process. From the author's perspective, it may 161 therefore be removed upon publication as an RFC at the RFC Editor's 162 discretion. 164 6. Acknowledgments 166 The authors would like to acknowledge the following contributors of 167 this document: Branimir Rajtar, Dan Wing and Kevin Yin. 169 7. Normative References 171 [RFC1035] Mockapetris, P., "Domain names - implementation and 172 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 173 November 1987, . 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 177 RFC2119, March 1997, 178 . 180 [RFC2316] Bellovin, S., "Report of the IAB Security Architecture 181 Workshop", RFC 2316, DOI 10.17487/RFC2316, April 1998, 182 . 184 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 185 Address Translator - Protocol Translator (NAT-PT) to 186 Historic Status", RFC 4966, DOI 10.17487/RFC4966, 187 July 2007, . 189 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 190 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 191 DOI 10.17487/RFC6052, October 2010, 192 . 194 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 195 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 196 April 2011, . 198 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 199 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 200 . 202 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 203 NAT64: Network Address and Protocol Translation from IPv6 204 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 205 April 2011, . 207 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 208 Beijnum, "DNS64: DNS Extensions for Network Address 209 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 210 DOI 10.17487/RFC6147, April 2011, 211 . 213 Authors' Addresses 215 Congxiao Bao 216 CERNET Center/Tsinghua University 217 Room 225, Main Building, Tsinghua University 218 Beijing 100084 219 CN 221 Phone: +86 10-62785983 222 Email: congxiao@cernet.edu.cn 224 Xing Li 225 CERNET Center/Tsinghua University 226 Room 225, Main Building, Tsinghua University 227 Beijing 100084 228 CN 230 Phone: +86 10-62785983 231 Email: xing@cernet.edu.cn 233 Yan Ma 234 Beijing University of Post and Telecommunication 235 Mailbox 121, Beijing University of Post and Telecommunication 236 Beijing 100876 237 CN 239 Phone: +86 10-62283044 240 Email: mayan@bupt.edu.cn