[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                  L. Song
Internet-Draft                                Beijing Internet Institute
Intended status: Standards Track                                 W. Liao
Expires: April 25, 2019                                          Tencent
                                                        October 22, 2018


                Client Dualstack Subnets in DNS Queries
                   draft-song-dnsop-dualstack-ecs-00

Abstract

   During the period of IPv6 transition, IP-based Geolocation (GeoIP)
   applications are identified as a challenge and speed bump for ICPs
   (Internet Content Providers) to migrating their service to IPv6.
   Some studies and operational experiences show that the accuracy of
   IPv6 GeoIP is relatively poor in comparison to their IPv4
   counterparts.  This memo proposed to include client's dualstack
   subnets into DNS queries to provide better IPv6 GeoIP.

   REMOVE BEFORE PUBLICATION: The source of the document with test
   script is currently placed at GitHub [Dualstack-ECS-GitHub].
   Comments and pull request are welcome.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 25, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Song & Liao              Expires April 25, 2019                 [Page 1]


Internet-Draft   Client Dualstack Subnets in DNS Queries    October 2018


   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  GeoIP and its Challenge in IPv6 . . . . . . . . . . . . . . .   3
   3.  Methodology and targeted Senarios . . . . . . . . . . . . . .   4
   4.  Dual-stack EDNS Client Subnet . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   During the period of IPv6 transition, IP-based Geolocation (GeoIP)
   applications are identified as a challenge and speed bump for ICPs
   (Internet Content Providers) to migrating their service to IPv6.  The
   key issue on GeoIP is the accuracy which however vary between IPv4
   and IPv6.  Some studies and operational experiences [ipv6geo] show
   that the accuracy of IPv6 GeoIP is relatively poor in comparison to
   their IPv4 counterparts.

   One typical example of GeoIP application in DNS field is that many
   authoritative nameservers today return different and tailored
   responses based on the perceived topological location of the users.
   If IPv6 GeoIP is not precise enough, the performance of topology-
   sensitive authoritative nameserver is poorer in IPv6 than IPv4.
   Users' experience is impacted , and it may end up with hesitation for
   the authoritative DNS operator to update its DNS to Dual Stack.  It
   is a problem.

   To provide a better IPv6 tailored DNS response in dual-stack
   environment, this memo proposes to enable recursive server and Client
   to include their IPv4 and IPv6 subnets into ECS Option [RFC7871] in
   DNS queries.  Authoritative nameservers can make a better use of this
   dual-stack subnet information for a tailored response.







Song & Liao              Expires April 25, 2019                 [Page 2]


Internet-Draft   Client Dualstack Subnets in DNS Queries    October 2018


2.  GeoIP and its Challenge in IPv6

   Knowing where your customer access your Internet service is very
   important in modern Internet.  It can be used for geolocation-aware
   application to achieve service efficiency such as Ads pushing and
   service recommendation.  It is useful for Global Server Load Balance
   (GSLB) such as DNS-based Content Distribution to achieve better
   network utilization and users experience.  It is also vital for
   security policy and service access control usually referred as to
   Geoblocking.

   One important geolocation used in Internet is IP-based Geolocation
   (GeoIP) which is usually collected and maintained by RIRs and ISPs
   when IP address block are registered, deployed and even traded.
   Generally there are mainly two categories of GeoIP: location of
   physical geography and location of network topology (or ISP network
   information).  The former usually includes the country, region, city
   ZIP code, longitude and latitude of a particular IP.  The later is
   mainly network information attached to a IP address like ISP
   registration information and AS number.  Usually they are combined to
   generate a appropriate result for location-based application.  For
   example, only knowing the ISP information of a IP address is not
   enough.  GSLB application may have many servers located in the same
   ISP network but in different physical location.  Precise physical
   location like city or street is of great help for this case.

   The network information of IP address is accurate and deterministic
   which can be easily learnt from Whois database, route reviews and
   CIDR reports.  However, the accuracy of physical location vary
   between IPv4 and IPv6 based on our experience.  Since IPv4 has been
   used for many years, IPv4 GeoIP is relatively more accurate
   especially in the aspect of accuracy of physical geography location.
   In contrast IPv6 is newly deployed.  The network information of a new
   IPv6 block may not be well documented or updated.  Some evidence and
   study shows [ipv6geo] that the accuracy of IPv6 GeoIP is relatively
   poor in comparison to their IPv4 counterparts.

   In addition, the huge space of IPv6 address, as the major merit of
   IPv6, however makes it impossible to gain precise location of each IP
   block by tracing them (tracert on each IP subnet).  This approach is
   very common and efficient in IPv4 network for GSLB of large Internet
   company.

   To the best knowledge of the authors, no evidence shows the available
   open GeoIP service providers take advantage of connection between
   IPv6 and IPv4 GeoIP , or try something like translating IPv6 GeoIP
   lookup to IPv4 GeoIP queries.  Some GeoIP providers (like Maxmind)
   only go with IPv6 addresses that contain an embedded IPv4 address.



Song & Liao              Expires April 25, 2019                 [Page 3]


Internet-Draft   Client Dualstack Subnets in DNS Queries    October 2018


   It is most likely that the Regional Whois Registry, online lookup
   services(like IP2Location.com) and off-line database (MaxMind GeoIP2)
   build separate systems between IPv4 and IPv6 without any reference or
   mapping.

3.  Methodology and targeted Senarios

   It is a intuition that if IPv6 GeoIP is not as good as IPv4 GeoIP
   especially in terms of accuracy of physical location, why not take
   the physical location of client's IPv4 subnet into consideration for
   the client's IPv6 GeoIP purpose?

   There are two valid assumptions for this approach.  One is that the
   lack of accurate physical location of IPv6 address is the main cause
   for poor IPv6 GeoIP.  The second assumption is that the dual-stack
   host assigned with both IPv6 and IPv4 addresses has only one physical
   location which should be tied to its IPv4 and IPv6 GeoIP.  Since IPv4
   GeoIP database is relatively stable and more accurate, it is wise to
   map IPv6 and IPv4 subnet, and take IPv4 subnet as a certain key to
   search the IPv4 GeoIP database (especially for physical location) to
   deliver a better result as one optional result of IPv6 GeoIP
   information.

   To take advantage of IPv4 GeoIP for IPv6 GeoIP purposed, the basic
   approach is to make IPv4 subnet visible for IPv6 geolocation-based
   applications.  Existing practice shows that a topology-sensitive
   authoritative nameservers may receive a AAAA query from IPv4
   transport, or receive a AAAA query with a ECS option FAMILAY=1.  It
   can utilize the perceived IPv4 subnet to response a appropriate AAAA
   record according to client's geolocation information based on IPv4
   GeoIP database.  However, when authoritative server received a AAAA
   query from IPv6 transport or a AAAA query with ECS option FAMILAY=2,
   it can only rely on less accurate IPv6 GeoIP available.

   Multihoming is a issue for client using dual-stack ECS, because IPv4
   and IPv6 addresses of a client or a site may be assigned by different
   upstream ISPs.  However the physical location of IPv4 still
   informative and useful to enhance the accuracy of IPv6 GeoIP.  For
   example, Client lived in city_1 (or street_1) may have two upstream
   ISP, ISP_1 for IPv6 network and ISP_2 for IPv4 network.  The
   authoritative server can generate tailored AAAA response according to
   the location of ISP1 and city_1 (or street_1) which are retrieved
   from both IPv4 and IPv6 GeoIP database.

   Different from ECS mainly applied on public DNS, the scenarios of
   Dual-stack ECS are mainly on stub-resolver and ISP's resolver who are
   able to include their IPv4 and IPv6 subnet into DNS queries.




Song & Liao              Expires April 25, 2019                 [Page 4]


Internet-Draft   Client Dualstack Subnets in DNS Queries    October 2018


4.  Dual-stack EDNS Client Subnet

   Note that Dual-stack ECS is to be define, extend existing ECS or
   defined a new one.  More effort should also be put on the behavior of
   authoritative server if the community think dual-stack ECS is a good
   idea.

5.  Security Considerations

   TBD

6.  IANA considerations

   No IANA considerations for this memo

7.  Acknowledgments

8.  References

   [Dualstack-ECS-GitHub]
              BII, "GitHub Repository of Dual-stack ECS",
              <https://github.com/songlinjian/dualstack-ECS>.

   [ipv6geo]  "Comparing the Accuracy of IPv4 and IPv6 Geolocation
              Databases", January 2016, <https://pdfs.semanticscholar.or
              g/0705/1014673302f97a762e74b795b70efdd74a1c.pdf>.

   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
              Kumari, "Client Subnet in DNS Queries", RFC 7871,
              DOI 10.17487/RFC7871, May 2016,
              <https://www.rfc-editor.org/info/rfc7871>.

Authors' Addresses

   Linjian Song
   Beijing Internet Institute
   2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA
   Beijing  100176
   P. R. China

   Email: songlinjian@gmail.com










Song & Liao              Expires April 25, 2019                 [Page 5]


Internet-Draft   Client Dualstack Subnets in DNS Queries    October 2018


   Weijian Liao
   Tencent
   9th Floor, Fiyta Building, Nanshan District
   Shenzhen, Guangdong  518000
   P. R. China

   Email: jewforice@gmail.com












































Song & Liao              Expires April 25, 2019                 [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/