Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

"Fred Baker (fred)" <fred@cisco.com> Thu, 19 March 2015 23:50 UTC

Return-Path: <fred@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606FF1A00EA for <v6ops@ietfa.amsl.com>; Thu, 19 Mar 2015 16:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -113.911
X-Spam-Level:
X-Spam-Status: No, score=-113.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVFC-YKB6jZN for <v6ops@ietfa.amsl.com>; Thu, 19 Mar 2015 16:50:34 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A931A0007 for <v6ops@ietf.org>; Thu, 19 Mar 2015 16:50:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6359; q=dns/txt; s=iport; t=1426809034; x=1428018634; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JpamqQPRjHd83KyFp+5+Cz5XjAZ+Fx1zYdHcAGV9RK0=; b=Gzm4wzWdPfJ/7jdgjqJTJAA+p+Tl3fNFSJEY0mIn4k7IclKu5YM3vY4R 96N961cZbR6nPymCxug/V4eInkdgs/LmPgEo2cA1y73rNBY4tKpGKNm/T 8fYiVH0TrMtjwG2HPbAnPzKmndxnlXeE2BYnWQv7LV6xFda3bko/kiUNR A=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBQB3YAtV/5RdJa1cgwZSWgSDCckbAoFATAEBAQEBAX2EDwEBAQMBIyQyBQsCAQgOCiMHAgIhESUCBA4FDg2IAAMJCLIjhRaROQ2FMQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4JEgi0HgmgvgRYFkEyBaYExhQeBTI4ChiYiggIFFxSBPG+BRH8BAQE
X-IronPort-AV: E=Sophos;i="5.11,433,1422921600"; d="asc'?scan'208";a="133682415"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 19 Mar 2015 23:50:33 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2JNoXs2006026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 23:50:33 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 18:50:33 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Ca By <cb.list6@gmail.com>
Thread-Topic: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
Thread-Index: AQHQYp98neMUqIFM3UWKOHw0TbKROg==
Date: Thu, 19 Mar 2015 23:50:32 +0000
Message-ID: <4CCA85A4-6A8B-439A-B083-D5C0358C2775@cisco.com>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com>
In-Reply-To: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.122]
Content-Type: multipart/signed; boundary="Apple-Mail=_A7681CA5-7651-44CC-B36B-330C4158AEC0"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/MRi9-D3lkiFPFivad0uzr_6hTHw>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 23:50:36 -0000

> On Mar 19, 2015, at 2:27 PM, Ca By <cb.list6@gmail.com> wrote:
> 
> My conclusion is that it is not feasible for a network operator to deploy a purely IPv6-only socket solution.  As has been previously explored, about 20% of the apps in the Google and Apple "app store" cannot function on IPv6-only + NAT64/DNS64.  Even if these "app stores" were policed to force all applications to be Address Family agnostic, it is not possible to police the world wide web or enterprise VPN or SIP Phones.  Any network operator that attempt to do this would have to accept at least 1.39% failure to the total web and perhaps accept failure to some major services (like Amazon streaming).
> 
> I believe we are beyond the point of blaming the world for using IPv4 literals / referrals.  We just need to be realistic that internet service requires IPv4 sockets, and thus RFC6144 #2.1 is not today a consumer grade service.  A wild guess is that it this situation will not meaningfully improve (risk reduced to ~0) for 10+ years.

</chair>

I guess my question is what you would recommend. This comes across as "give up on the transition; it will never happen." I’d like to believe that there is in fact a way we can make it happen. How do we get there?

One approach would be that we simply let it happen, and folks who deploy IPv4 address literals eventually see market fall-off correlated with IPv6 growth. At some point, that becomes a forcing mechanism. It’s not a tenable one now, however.

draft-osamu-v6ops-ipv4-literal-in-url comments on this in detail and makes a proposal.

In addition:

draft-ietf-sunset4-gapanalysis-05.txt
7.  IPv4 Address Literals

   IPv4 addresses are often used as resource locators.  For example, it
   is common to encounter URLs containing IPv4 address literals on web
   sites [I-D.wing-behave-http-ip-address-literals].  IPv4 address
   literals may be published on media other than web sites, and may
   appear in various forms other than URLs.  For the operating systems
   which exhibit the behavior described in
   [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an
   increase in the broadcast ARP traffic, which may be undesirable.

   PROBLEM 14: IPv6-only hosts are unable to access resources identified
               by IPv4 address literals.

   [I-D.wing-behave-http-ip-address-literals]
              Wing, D., "Coping with IP Address Literals in HTTP URIs
              with IPv6/IPv4 Translators", draft-wing-behave-http-ip-
              address-literals-02 (work in progress), March 2010.

draft-ietf-v6ops-mobile-device-profile-20.txt
   The use of address family dependent APIs (Application Programming
   Interfaces) or hard-coded IPv4 address literals may lead to broken
   applications when IPv6 connectivity is in use.  As such, means to
   minimize broken applications when the cellular host is attached to an
   IPv6-only network should be encouraged.  Particularly, (1) name
   resolution libraries (e.g., [RFC3596]) must support both IPv4 and
   IPv6; (2) applications must be independent of the underlying IP
   address family; (3) and applications relying upon Uniform Resource
   Identifiers (URIs) must follow [RFC3986] and its updates.  Note, some
   IETF specifications (e.g., SIP [RFC3261]) contains broken IPv6 ABNF
   and rules to compare URIs with embedded IPv6 addresses; fixes (e.g.,
   [RFC5954]) must be used instead.

draft-ietf-xmpp-6122bis-19.txt
      jid          = [ localpart "@" ] domainpart [ "/" resourcepart ]
      localpart    = 1*1023(userbyte)
                     ;
                     ; a "userbyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to the
                     ; "UsernameCaseMapped" profile of the PRECIS
                     ; IdentifierClass
                     ;
      domainpart   = IP-literal / IPv4address / ifqdn
                     ;
                     ; the "IPv4address" and "IP-literal" rules are
                     ; defined in RFC 3986, and the first-match-wins
                     ; (a.k.a. "greedy") algorithm described therein
                     ; applies to the matching process
                     ;
                     ; note well that reuse of the IP-literal rule from
                     ; RFC 3986 implies that IPv6 addresses are enclosed
                     ; in square brackets (i.e., beginning with '[' and
                     ; ending with ']')
                     ;
      ifqdn        = 1*1023(domainbyte)
                     ;
                     ; a "domainbyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to RFC 5890
                     ;
      resourcepart = 1*1023(resourcebyte)
                     ;
                     ; an "opaquebyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to the
                     ; "OpaqueString" profile of the PRECIS
                     ; FreeformClass
                     ;