idnits 2.17.1 draft-korhonen-edns0-synthesis-flag-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 : ---------------------------------------------------------------------------- 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 date (February 17, 2011) is 4817 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave WG J. Korhonen 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track T. Savolainen, Ed. 5 Expires: August 21, 2011 Nokia 6 February 17, 2011 8 EDNS0 Option for Indicating AAAA Record Synthesis and Format 9 draft-korhonen-edns0-synthesis-flag-02.txt 11 Abstract 13 Advanced hosts and applications benefit of the knowledge of an IPv6 14 address, AAAA record, synthesis taking place in the network. This 15 draft proposes new ENDS0 option for communicating the synthesis is 16 taking place, used address format, and the IPv6 prefix and suffix 17 used by the DNS64. The communicated information enables hosts to 18 perform local IPv6 address synthesis. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 21, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. EDNS0 option for indicating address synthesis . . . . . . . . . 3 58 4. Host behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 As the networks transition to IPv6, connectivity to IPv4-only domains 70 have to be provided. NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] and 71 DNS64 [I-D.ietf-behave-dns64] technologies can be utilized to make 72 IPv4-only peers look like being reachable over IPv6. The DNS64 73 utilizes IPv6 address synthesis to create local IPv6 presentations of 74 peers having only IPv4 addresses. Applications utilizing DNS for 75 resolving peers' IPv6 addresses can work seamlessly through protocol 76 translation taking place at NAT64. 78 The DNS64 cannot serve applications not using DNS, such as those 79 receiving IPv4 addresses as referrals. Such applications could 80 nevertheless be able to work through NAT64, provided they are able to 81 create locally valid IPv6 presentations of peers' IPv4 addresses. 83 This document describes a method for advanced applications to learn 84 the information required to perform local IPv6 address synthesis. 86 The knowledge of IPv6 address synthesizing taking place may also be 87 useful if DNS64 is present in dual-stack network access. In such 88 cases hosts may choose to use IPv4 addresses instead of synthesized 89 IPv6 addresses, and hence avoid traversal through NAT64. 91 2. Requirements and Terminology 93 2.1. Requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. EDNS0 option for indicating address synthesis 101 The mechanism for informing AAAA record synthesis taking place and 102 the used addressing format is communicated in an EDNS0 option in a 103 DNS response. The option has three bits indicating the formats 104 described in [RFC6052]. The option and bits are structured as 105 follows: 107 +0 (MSB) +1 (LSB) 108 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 109 0: | OPTION-CODE | 110 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 111 2: | OPTION-LENGTH | 112 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 113 4: | SY | Reserved | 114 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 116 OPTION-CODE (Assigned by IANA) 118 OPTION-LENGTH 2 (Length of payload in octets) 120 Possible values for SY-bits are: 122 000 reserved 123 001 prefix length /32 124 010 prefix length /40 125 011 prefix length /48 126 100 prefix length /56 127 101 prefix length /64 128 110 prefix length /96 129 111 address is not synthesized 131 Reserved Initialized to zero 133 Figure 1 135 The prefix length corresponds to the address formats documented in 136 "IPv6 Addressing of IPv4/IPv6 Translators document" [RFC6052] section 137 2.2. 139 Absence of EDNS0 option means that either no synthesis took place or 140 the DNS64 does not support this specification. Either way, when the 141 EDNS0 option is missing, the host cannot conclude for certain whether 142 the AAAA response was synthesized or not. The host may additionally 143 utilize method described in 144 [I-D.savolainen-heuristic-nat64-discovery]. 146 4. Host behavior 148 If a host requires information for local IPv6 address synthesis or 149 NAT64 avoidance, it shall send a DNS query for AAAA record of a well- 150 known IPv4-only fully qualified domain name. This well-known name 151 does not have to be in global DNS system. It is enough that DNS64 152 recognizes the name and replies to it. 154 The host may query for well-known IPv4-only name, for example, at the 155 moment the host is configured an IPv6 address of a DNS server. This 156 may also happen at the time first DNS query for AAAA record is 157 initiated. 159 When sending AAAA query for the known name a host MUST set "Checking 160 Disabled (CD)" bit to zero, as otherwise the DNS64 will not perform 161 IPv6 address synthesis hence does not reveal the IPv6 prefix(es) used 162 for protocol translation. 164 If a host receives negative reply, it learns there are no NAT64 in 165 the network. 167 A DNS reply with one or more non-empty AAAA records indicates that 168 the access network is utilizing IPv6 address synthesis. The host 169 reads the flag values on the ENDS0 option to learn the used address 170 format, and with that information fetches from the received IPv6 171 addresses the information used by the network for IPv6 address 172 synthesis (prefix, suffix, u-bit). The host MUST look through all of 173 the received AAAA records to collect all available prefixes. The 174 prefixes may include Well-Known Prefix or one or more Network- 175 Specific Prefixes. 177 In the case only one IPv6 prefix was present in the DNS response: a 178 host shall use that IPv6 prefix for both local synthetization and for 179 detecting synthesis done by the DNS64 entity on the network. 181 In the case multiple IPv6 prefixes were present in the DNS response: 182 a host SHOULD use all received prefixes when determining whether 183 other received IPv6 addresses are synthetic. However, for selecting 184 prefix for the local IPv6 address synthesis host MUST use the 185 following prioritization order, of which purpose is to avoid use of 186 prefixes containing suffixes reserved for the future [RFC6052]: 188 1. Use NSP having /96 prefix 190 2. Use WKP prefix 192 3. Use longest available NSP prefix 194 In the case of NXDOMAIN or empty AAAA reply: the DNS64 is not 195 available on the access network, network filtered the well-known AAAA 196 query on purpose, or something went wrong in the DNS resolution. All 197 unsuccessful cases result in unavailability of a host to perform 198 local IPv6 address synthesis. The host MAY periodically resend AAAA 199 query to check if DNS64 has become available or temporary problem 200 cleared. The host MAY also continue monitoring DNS replies with IPv6 201 addresses constructed from WKP, in which case the host MAY use the 202 WKP as if it were learned during the query for well-known name. 204 The information required for local IPv6 address synthesis should be 205 made available for applications to utilize. 207 Alternatively, the host may learn the required information for the 208 local IPv6 address synthesis or the NAT64 avoidance along with any 209 normal DNS query for an AAAA record. In that case all the above 210 considerations and procedures apply, except for the fact that the 211 fully qualified domain used for the DNS query may or may not be 212 provisioned with an AAAA record. Therefore, if and when the EDNS0 213 option is absent in the reply, the host cannot reliably determine 214 whether the returned IPv6 address is real or synthesized. 216 5. Security Considerations 218 No security considerations have been identified. 220 6. IANA Considerations 222 IANA should define a name and an IPv4 address for a well-known IPv4- 223 only name. 225 IANA should allocate new OPTION-CODE for this option. 227 7. Acknowledgements 229 The authors would like to acknowledge Andrew Sullivan for presenting 230 general idea of ENDS0 option and SY-bit in behave WG mailing list. 232 8. References 234 8.1. Normative References 236 [I-D.ietf-behave-dns64] 237 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 238 "DNS64: DNS extensions for Network Address Translation 239 from IPv6 Clients to IPv4 Servers", 240 draft-ietf-behave-dns64-11 (work in progress), 241 October 2010. 243 [I-D.ietf-behave-v6v4-xlate-stateful] 244 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 245 NAT64: Network Address and Protocol Translation from IPv6 246 Clients to IPv4 Servers", 247 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 248 progress), July 2010. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 254 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 255 October 2010. 257 8.2. Informative References 259 [I-D.savolainen-heuristic-nat64-discovery] 260 Savolainen, T. and J. Korhonen, "Discovery of a Network- 261 Specific NAT64 Prefix using a Well-Known Name", 262 draft-savolainen-heuristic-nat64-discovery-01 (work in 263 progress), February 2011. 265 Authors' Addresses 267 Jouni Korhonen 268 Nokia Siemens Networks 269 Linnoitustie 6 270 FI-02600 Espoo 271 Finland 273 Email: jouni.nospam@gmail.com 275 Teemu Savolainen (editor) 276 Nokia 277 Hermiankatu 12 D 278 FI-33720 Tampere 279 Finland 281 Email: teemu.savolainen@nokia.com