Special host name for 464xlat connections
draft-rosenau-464xlat-hostname-00

Document Type Active Internet-Draft (individual)
Last updated 2018-09-23
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         M. Rosenau
Internet-Draft                                        September 23, 2018
Intended status: Experimental
Expires: March 27, 2019

               Special host name for 464xlat connections
                   draft-rosenau-464xlat-hostname-00

Abstract

   This document describes an idea for a special DNS query whose use is
   to get the IPv6 address representing an IPv4 address in a 464xlat
   environment.

   The query can also be used to force the IPv4 client to connect to the
   server via IPv6 by returning the "real" IPv6 address of a dual-stack
   server instead of the IPv6 address used to connect to the server's
   IPv4 address using NAT64.

   The query is supposed to be compatible to the existing DNS system so
   no changes to the DNS protocol or DNS servers need to be done.

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 March 27, 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
   (https://trustee.ietf.org/license-info) in effect on the date of

Rosenau                  Expires March 27, 2019                 [Page 1]
Internet-Draft               RequestV6Option              September 2018

   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

   Because of the IPv4 address shortage the IPv6 protocol has been
   developed.  Unfortunately many servers in the internet are still
   IPv4-only and many internet service providers are not able to assign
   an IPv4 address to every customer.

   There is also software which is not able to use IPv6.

   Many internet service providers use NAT64 [RFC6146] to provide their
   customers the possibility to use IPv4-only software to access the
   internet or to access IPv4-only servers using an IPv6-only network.

   The IPv6 prefix 64:ff9b::/96 is reserved for calculating IPv6
   addresses representing IPv4 addresses.

   However there are advantages when not using this addressing scheme
   but when calculating the IPv6 address representing the IPv4 address
   on the internet service provider side:

   First the internet service provider may use multiple NAT64 routers
   and do a load balancing by assigning different /96 prefixes to each
   NAT64 router and returning an IPv6 address based on the router with
   the least load to the customer.

   Second the provider may return the real IPv6 address of a dual-stack
   server if that address is known.  Doing so the load of the NAT64
   routers can be reduced.

   A third use case is to use different NAT64 routers based on different
   IPv4 addresses: To connect to an IPv4 server in the USA a NAT64
   router in the USA may be used while a NAT64 in Europe is used to
   connect to a server in Europe.

   There were already internet-drafts in the past which were addressing
   this problem.

   This document describes a method based on DNS queries allowing the
   IPv6 address to be calculated by the internet service provider.  The
   method also allows server operators of dual-stack servers to inform

Rosenau                  Expires March 27, 2019                 [Page 2]
Internet-Draft               RequestV6Option              September 2018

   internet service providers about the IPv6 address of the server based
   on the IPv4 address.

2.  Terminology

2.1.  Keywords in capital letters

   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
   14, RFC 2119 [RFC2119] and indicate requirement levels for compliant
   implementations.

2.2.  client, server

   In the context of this document a "client" is a node which is
   initiating data data transfer between itself and another node.  The
   other node is called "server" in the context of this document.
Show full document text