idnits 2.17.1 draft-song-dnsop-dualstack-ecs-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([Dualstack-ECS-GitHub]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2007 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Dualstack-ECS-GitHub' ** Downref: Normative reference to an Informational RFC: RFC 7871 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Song 3 Internet-Draft Beijing Internet Institute 4 Intended status: Standards Track W. Liao 5 Expires: April 25, 2019 Tencent 6 October 22, 2018 8 Client Dualstack Subnets in DNS Queries 9 draft-song-dnsop-dualstack-ecs-00 11 Abstract 13 During the period of IPv6 transition, IP-based Geolocation (GeoIP) 14 applications are identified as a challenge and speed bump for ICPs 15 (Internet Content Providers) to migrating their service to IPv6. 16 Some studies and operational experiences show that the accuracy of 17 IPv6 GeoIP is relatively poor in comparison to their IPv4 18 counterparts. This memo proposed to include client's dualstack 19 subnets into DNS queries to provide better IPv6 GeoIP. 21 REMOVE BEFORE PUBLICATION: The source of the document with test 22 script is currently placed at GitHub [Dualstack-ECS-GitHub]. 23 Comments and pull request are welcome. 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 April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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. GeoIP and its Challenge in IPv6 . . . . . . . . . . . . . . . 3 61 3. Methodology and targeted Senarios . . . . . . . . . . . . . . 4 62 4. Dual-stack EDNS Client Subnet . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 During the period of IPv6 transition, IP-based Geolocation (GeoIP) 72 applications are identified as a challenge and speed bump for ICPs 73 (Internet Content Providers) to migrating their service to IPv6. The 74 key issue on GeoIP is the accuracy which however vary between IPv4 75 and IPv6. Some studies and operational experiences [ipv6geo] show 76 that the accuracy of IPv6 GeoIP is relatively poor in comparison to 77 their IPv4 counterparts. 79 One typical example of GeoIP application in DNS field is that many 80 authoritative nameservers today return different and tailored 81 responses based on the perceived topological location of the users. 82 If IPv6 GeoIP is not precise enough, the performance of topology- 83 sensitive authoritative nameserver is poorer in IPv6 than IPv4. 84 Users' experience is impacted , and it may end up with hesitation for 85 the authoritative DNS operator to update its DNS to Dual Stack. It 86 is a problem. 88 To provide a better IPv6 tailored DNS response in dual-stack 89 environment, this memo proposes to enable recursive server and Client 90 to include their IPv4 and IPv6 subnets into ECS Option [RFC7871] in 91 DNS queries. Authoritative nameservers can make a better use of this 92 dual-stack subnet information for a tailored response. 94 2. GeoIP and its Challenge in IPv6 96 Knowing where your customer access your Internet service is very 97 important in modern Internet. It can be used for geolocation-aware 98 application to achieve service efficiency such as Ads pushing and 99 service recommendation. It is useful for Global Server Load Balance 100 (GSLB) such as DNS-based Content Distribution to achieve better 101 network utilization and users experience. It is also vital for 102 security policy and service access control usually referred as to 103 Geoblocking. 105 One important geolocation used in Internet is IP-based Geolocation 106 (GeoIP) which is usually collected and maintained by RIRs and ISPs 107 when IP address block are registered, deployed and even traded. 108 Generally there are mainly two categories of GeoIP: location of 109 physical geography and location of network topology (or ISP network 110 information). The former usually includes the country, region, city 111 ZIP code, longitude and latitude of a particular IP. The later is 112 mainly network information attached to a IP address like ISP 113 registration information and AS number. Usually they are combined to 114 generate a appropriate result for location-based application. For 115 example, only knowing the ISP information of a IP address is not 116 enough. GSLB application may have many servers located in the same 117 ISP network but in different physical location. Precise physical 118 location like city or street is of great help for this case. 120 The network information of IP address is accurate and deterministic 121 which can be easily learnt from Whois database, route reviews and 122 CIDR reports. However, the accuracy of physical location vary 123 between IPv4 and IPv6 based on our experience. Since IPv4 has been 124 used for many years, IPv4 GeoIP is relatively more accurate 125 especially in the aspect of accuracy of physical geography location. 126 In contrast IPv6 is newly deployed. The network information of a new 127 IPv6 block may not be well documented or updated. Some evidence and 128 study shows [ipv6geo] that the accuracy of IPv6 GeoIP is relatively 129 poor in comparison to their IPv4 counterparts. 131 In addition, the huge space of IPv6 address, as the major merit of 132 IPv6, however makes it impossible to gain precise location of each IP 133 block by tracing them (tracert on each IP subnet). This approach is 134 very common and efficient in IPv4 network for GSLB of large Internet 135 company. 137 To the best knowledge of the authors, no evidence shows the available 138 open GeoIP service providers take advantage of connection between 139 IPv6 and IPv4 GeoIP , or try something like translating IPv6 GeoIP 140 lookup to IPv4 GeoIP queries. Some GeoIP providers (like Maxmind) 141 only go with IPv6 addresses that contain an embedded IPv4 address. 143 It is most likely that the Regional Whois Registry, online lookup 144 services(like IP2Location.com) and off-line database (MaxMind GeoIP2) 145 build separate systems between IPv4 and IPv6 without any reference or 146 mapping. 148 3. Methodology and targeted Senarios 150 It is a intuition that if IPv6 GeoIP is not as good as IPv4 GeoIP 151 especially in terms of accuracy of physical location, why not take 152 the physical location of client's IPv4 subnet into consideration for 153 the client's IPv6 GeoIP purpose? 155 There are two valid assumptions for this approach. One is that the 156 lack of accurate physical location of IPv6 address is the main cause 157 for poor IPv6 GeoIP. The second assumption is that the dual-stack 158 host assigned with both IPv6 and IPv4 addresses has only one physical 159 location which should be tied to its IPv4 and IPv6 GeoIP. Since IPv4 160 GeoIP database is relatively stable and more accurate, it is wise to 161 map IPv6 and IPv4 subnet, and take IPv4 subnet as a certain key to 162 search the IPv4 GeoIP database (especially for physical location) to 163 deliver a better result as one optional result of IPv6 GeoIP 164 information. 166 To take advantage of IPv4 GeoIP for IPv6 GeoIP purposed, the basic 167 approach is to make IPv4 subnet visible for IPv6 geolocation-based 168 applications. Existing practice shows that a topology-sensitive 169 authoritative nameservers may receive a AAAA query from IPv4 170 transport, or receive a AAAA query with a ECS option FAMILAY=1. It 171 can utilize the perceived IPv4 subnet to response a appropriate AAAA 172 record according to client's geolocation information based on IPv4 173 GeoIP database. However, when authoritative server received a AAAA 174 query from IPv6 transport or a AAAA query with ECS option FAMILAY=2, 175 it can only rely on less accurate IPv6 GeoIP available. 177 Multihoming is a issue for client using dual-stack ECS, because IPv4 178 and IPv6 addresses of a client or a site may be assigned by different 179 upstream ISPs. However the physical location of IPv4 still 180 informative and useful to enhance the accuracy of IPv6 GeoIP. For 181 example, Client lived in city_1 (or street_1) may have two upstream 182 ISP, ISP_1 for IPv6 network and ISP_2 for IPv4 network. The 183 authoritative server can generate tailored AAAA response according to 184 the location of ISP1 and city_1 (or street_1) which are retrieved 185 from both IPv4 and IPv6 GeoIP database. 187 Different from ECS mainly applied on public DNS, the scenarios of 188 Dual-stack ECS are mainly on stub-resolver and ISP's resolver who are 189 able to include their IPv4 and IPv6 subnet into DNS queries. 191 4. Dual-stack EDNS Client Subnet 193 Note that Dual-stack ECS is to be define, extend existing ECS or 194 defined a new one. More effort should also be put on the behavior of 195 authoritative server if the community think dual-stack ECS is a good 196 idea. 198 5. Security Considerations 200 TBD 202 6. IANA considerations 204 No IANA considerations for this memo 206 7. Acknowledgments 208 8. References 210 [Dualstack-ECS-GitHub] 211 BII, "GitHub Repository of Dual-stack ECS", 212 . 214 [ipv6geo] "Comparing the Accuracy of IPv4 and IPv6 Geolocation 215 Databases", January 2016, . 218 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 219 Kumari, "Client Subnet in DNS Queries", RFC 7871, 220 DOI 10.17487/RFC7871, May 2016, 221 . 223 Authors' Addresses 225 Linjian Song 226 Beijing Internet Institute 227 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA 228 Beijing 100176 229 P. R. China 231 Email: songlinjian@gmail.com 232 Weijian Liao 233 Tencent 234 9th Floor, Fiyta Building, Nanshan District 235 Shenzhen, Guangdong 518000 236 P. R. China 238 Email: jewforice@gmail.com