Internet DRAFT - draft-rosenau-dyndns-nat46

draft-rosenau-dyndns-nat46







Network Working Group                                         M. Rosenau
Internet-Draft                                          February 4, 2016
Intended status: Experimental
Expires: August 7, 2016


             IPv4-to-IPv6 translation mechanism with DynDNS
                     draft-rosenau-dyndns-nat46-00

Abstract

   Many devices in private homes can be controlled via Web browser from
   another computer in the internet.  This assumes that the IP address
   of the device is known and that the private internet access has a
   public IP address at all.

   Due to the IPv4 address shortage many internet providers only provide
   IPv6 internet access while many internet accesses (and therefore Web
   browsers) are IPv4-only.

   This document describes a method that allows an internet service
   provider that also provides dynamic DNS to the customers to allow
   accessing IPv6-only devices from IPv4-only Web browsers.

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 http://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 August 7, 2016.

Copyright Notice

   Copyright (c) 2016 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



Rosenau                  Expires August 7, 2016                 [Page 1]

Internet-Draft               DNS46withDynDNS               February 2016


   (http://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.

1.  Introduction

   There are many devices in private homes which can be controlled over
   the internet.  Smart heating installation is one example for this.

   In the past users operating such devices used a "dynamic DNS" service
   because the IPv4 address of the internet access was changing every
   day.  The home router was configured to perform a "port forwarding"
   so incoming TCP connections on a certain port were forwarded to the
   device.

   Using IPv6 the port forwarding is no longer needed because each
   device has its own IPv6 address but the "dynamic DNS" service is
   still required because the IPv6 address prefix of most internet
   accesses is still changing daily (often for privacy reasons).

   Because of the shortage of IPv4 addresses many internet accesses only
   have a public IPv6 address range and no public IPv4 address while
   there are still a lot of internet accesses that are IPv4-only.  If
   the internet access at home is IPv6-only and the web browser is
   connected to an IPv4-only internet access then it is not possible to
   access the device at home using this web browser.

   Some providers of DS-Lite [RFC6333] try to use special protocols that
   allow customers to forward certain ports to their devices.  However
   this has one major drawback: Because the number of IPv4 addresses of
   the provider is limited only a limited number of customers can
   forward a certain port number (such as 80 for HTTP) to their device.

   This document describes a method which bases on a NAT46 (IPv4 to IPv6
   translation) operated by the internet service provider which does not
   have such limitations.  However this method is limited to certain
   protocols (for example HTTP and TLS).

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP




Rosenau                  Expires August 7, 2016                 [Page 2]

Internet-Draft               DNS46withDynDNS               February 2016


   14, RFC 2119 [RFC2119] and indicate requirement levels for compliant
   implementations.

3.  System description

3.1.  Dynamic domain name service

   An essential part of the system is the dynamic domain name service.

   The internet service provider provides a dynamic domain name service
   to the customers.  As the customers have IPv6-only internet access
   they only provide AAAA entries.  Example:

         heater.customer1.example.com AAAA 2001:DB8:1::1234
         heater.customer2.example.com AAAA 2001:DB8:2::5678
         coffeemachine.customer2.example.com AAAA 2001:DB8:2::9ABC

                       Figure 1: Customer addresses

   Let's say the providers AFTR or NAT46 router has the IPv4 address
   192.0.2.1.  Then the provider adds the DNS entries for the IPv4
   addresses: All host names have the IPv4 address of the NAT46 router
   or AFTR:

         heater.customer1.example.com IN A 192.0.2.1
         heater.customer2.example.com IN A 192.0.2.1
         coffeemachine.customer2.example.com IN A 192.0.2.1

                         Figure 2: IPv4 addresses

3.2.  Access via IPv6

   Since the customers have full IPv6 internet access the devices at
   home can be accessed directly when the web browser uses IPv6.  No
   NAT46 (IPv4->IPv6) translation is necessary.

3.3.  Access via IPv4 - HTTP based

   The NAT46 or AFTR is listening on ports 80, 1080 and 8080 which are
   typically used for HTTP-based connections.

   When there is an incoming connection the NAT46/AFTR first receives
   the HTTP header from the host that initiated the connection.

   The NAT46/AFTR evaluates the "Host:" line.  Depending on the "Host:"
   line it creates a connection to the destination host desired, sends
   the entire HTTP header received to that host and creates a 1:1 NAT
   connection between the source and the destination host.



Rosenau                  Expires August 7, 2016                 [Page 3]

Internet-Draft               DNS46withDynDNS               February 2016


   In the following example "IPv4" is the IPv4-only host the web browser
   runs on, "NAT" is the NAT46 or AFTR operated by the internet service
   provider and "IPv6" is the IPv6-only web server (which may be a
   device like a smart heater installation):

         IPv4 -> NAT:   GET /example.file HTTP/1.1<CRLF>
         IPv4 -> NAT:   Information: Hello world<CRLF>
         IPv4 -> NAT:   Host: heater.customer2.example.com<CR>
         IPv4 -> NAT:   (more data received)
         -- Now the NAT establishes a connection to the IPv6 host
         -- heater.customer2.example.com
         NAT -> IPv6:   GET /example.file HTTP/1.1<CRLF>
         NAT -> IPv6:   Information: Hello world<CRLF>
         NAT -> IPv6:   Host: heater.customer2.example.com<CR>
         NAT -> IPv6:   (more data received)
         -- Now a 1:1 connection IPv4 <--> IPv6 is established
         -- by the NAT.

                      Figure 3: HTTP-Based connection

   Note that in this scenario the NAT does not evaluate any other lines
   but the "Host:" line.  It does also not evaluate any responses from
   the IPv6 host.

   When the host name is not known, the IPv6 host refuses the TCP
   connection or there is no "Host:" line in the HTTP header the NAT
   sends a response itself:

         IPv4 -> NAT:   GET /example.file HTTP/1.1<CRLF>
         IPv4 -> NAT:   Information: Hello world<CRLF>
         IPv4 -> NAT:   Host: heater.customer2.nonexisting.example<CR>
         IPv4 -> NAT:   (more data received)
         -- Now the NAT tries to establish a connection to the IPv6 host
         -- heater.customer2.nonexisting.example
         NAT -> IPv4:   HTTP/1.1 502 Unknown host name<SP>
         NAT -> IPv4:   heater.customer2.nonexisting.example<CRLFCRLF>
         -- Connection is closed by the NAT

             Figure 4: HTTP-Based connection: Host unreachable

3.4.  Access via IPv4 - TLS based

   The NAT46 or AFTR is also listening on ports used for protocols that
   use TLS (443, 563, 565, 636, 989, 990, 992, 993, 995).

   Instead of evaluating the "Host:" line in the HTTP request it
   evaluates the server name extension in the "client hello" packet sent
   by the TLS client.



Rosenau                  Expires August 7, 2016                 [Page 4]

Internet-Draft               DNS46withDynDNS               February 2016


   In the case of an error (server not available) the NAT sends an
   "unrecognized_name" error code back to the client.

   As for HTTP connections the NAT does not evaluate any other fields of
   the "client hello" packet but it simply forwards it to the desired
   TLS server.

4.  References

4.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

4.2.  Informational References

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
              <http://www.rfc-editor.org/info/rfc6333>.

Author's Address

   Martin D. J. Rosenau

   Email: martin@rosenau-ka.de























Rosenau                  Expires August 7, 2016                 [Page 5]