IETF Logo Mail Archive

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

James Woodyatt <jhw@nestlabs.com> Tue, 21 April 2015 19:02 UTC

Return-Path: <jhw@nestlabs.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 919471A8A56 for <v6ops@ietfa.amsl.com>; Tue, 21 Apr 2015 12:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 X3fSClIEiDTx for <v6ops@ietfa.amsl.com>; Tue, 21 Apr 2015 12:02:32 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4208F1A8A59 for <v6ops@ietf.org>; Tue, 21 Apr 2015 12:02:10 -0700 (PDT)
Received: by widdi4 with SMTP id di4so150881668wid.0 for <v6ops@ietf.org>; Tue, 21 Apr 2015 12:02:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/8vbU6Az2VsMxNdImxM1AzRp6g/tYszZ/14Dr/BBLEc=; b=YIY9jXWofvOgQEO3SM7o4rGEqMLCR+JedfnbQpP9Ok1TjBArteem4THNxdqJa4fl6Y N+BjCS6vocuH2wBg9JQHBIFXH5jKsCJxYf1dH+kpC0OJ55HftTZi7o0ZPfDNTHmndt2V JHgMz/AibkmaHf7H7IOQmHFiqpBD9jsjmqfvY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/8vbU6Az2VsMxNdImxM1AzRp6g/tYszZ/14Dr/BBLEc=; b=ZLSbpqg86Zjw0/RnY/foaiIIUgADJc0TJORqFR7UdxbkYNxY8+Kf7ZF5UZAH04dvdI zaqFYYtJ6BbEV4AcXNJAUIxL1ptenqDz0hadRMOyeQrloHoRtzk03W48tAMq0TTKpOm7 Vu8pC12B7NN4S/CHsZR25ljsg36E8+ACvYS1e8wKL+aPtqXl6itRNUVJwirrqAokALlr XJ0RuaPwc+ygCWGEemqTB0ykGeBYR/DWc5IURQHBf44LdD76RSu6P/vX6dp8EP0+aFwn c8OSs8BHFLhLk8wsbR9cKHJ5MUHQgD+/SNmutADYtfthlt4MwMLHD1vjmO8sdTrjdHON ATWw==
X-Gm-Message-State: ALoCoQnP226RIvdxeG27J0qmiQRJxP19oE0cFvPjyKED9N0z1vFwQoRWHH0gMom/pKXdl+hQHkUy
MIME-Version: 1.0
X-Received: by 10.180.96.65 with SMTP id dq1mr37551811wib.46.1429642929030; Tue, 21 Apr 2015 12:02:09 -0700 (PDT)
Received: by 10.28.16.1 with HTTP; Tue, 21 Apr 2015 12:02:08 -0700 (PDT)
In-Reply-To: <5536776A.9060204@cernet.edu.cn>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com> <CAD6AjGTcKgK8W+VB1H5EQpHaYiKVYXqOz_2RS-w_CiTf9kL2CQ@mail.gmail.com> <CADhXe530+OVZrFZVaYh1-zoRDvJhUd0rf4sx6a2nO8SvKmm6zg@mail.gmail.com> <CAPi140PQ+TF0rED_bQPeS=Fj415qt0-zE2RdGnEL34PAzHyx6Q@mail.gmail.com> <CAD6AjGTjXAeMF6pw5MO2Jrf9B8LJ48D3m1YTVkdBe=_OHjtroQ@mail.gmail.com> <CADhXe51TCqU2eMP4LS3DooZxQDAPD95OVJDXbiU7qvuvKCMq+w@mail.gmail.com> <CAKD1Yr2=zc57+pOA9TFs+0azw0ZR1g67+08T=9eZPHjGXBvgFQ@mail.gmail.com> <CADhXe53T_30pj7xxwNs=mWEnd=do6oiq3KgN=U-gHLrLF-gG7Q@mail.gmail.com> <D1441574.4C168%wesley.george@twcable.com> <CAD6AjGQrzoBJrqQfKO0N8Ji=oJ-ZP6Sn88sXf=opJ6bYVmTDZg@mail.gmail.com> <552102B0.6070904@cernet.edu.cn> <35D97B17-8E83-43CF-ABEF-122572F1321A@eircom.net> <552369C8.5000801@cernet.edu.cn> <CADhXe51BDuPhc8wdKGmRiBfSnrz7PMtqYXaoDO+5cwLx_xW2tw@mail.gmail.com> <55290E26.8080500@cernet.edu.cn> <CADhXe50zz9EtNtifMh+tN9XT-jKCTJB=vsQ6uG515iddOo7f2Q@mail.gmail.com> <5536776A.9060204@cernet.edu.cn>
Date: Tue, 21 Apr 2015 12:02:08 -0700
Message-ID: <CADhXe52HpC1eGtnEw7+yWtOO2-ZEisGe_2Bz9Sz1=JHQQCPhEw@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: Xing Li <xing@cernet.edu.cn>
Content-Type: multipart/alternative; boundary="f46d04343dd0f0debb051440aedf"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/EXsWzfKpxKNBGR3Q1FLYfLtsvrc>
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: Tue, 21 Apr 2015 19:02:33 -0000

On Tue, Apr 21, 2015 at 9:14 AM, Xing Li <xing@cernet.edu.cn> wrote:
>
>
> (1) If the host system can not do RFC6145, the additional CPE is
> required to do so, and that also keeps the IPv4 literals on the Internet
> forever.
>

I wouldn't characterize it like that. I think what you mean to say is this:
because support for IPv4 literals can never be removed from the Internet,
hosts must either be provided with IPv4 service forever or all the hosts on
the Internet must be upgraded to support the CLAT function in 464XLAT. My
point is that you can't require all the hosts to be upgraded with CLAT
functions any more than your require all the applications to stop using
IPv4 literals everywhere. You are left with exactly one alternative: you
must support IPv4 forever, and this is not because hosts don't have CLAT
functions, but entirely because you cannot abide breaking any of the
applications today that use IPv4 literals.

Shorter james: your problem is the IPv4 literals. If you can't ignore them,
and you can't do anything else about them, then you can't deploy IPv6-only.
It's really that simple.

(2) No ISP will deploy the IPv6-only network, if the end users cannot
> access the websites with IPv4 literals.
>

I don't have a problem with that. I've been saying all along that ISPs
should not be in any hurry to turn off IPv4 service to CPE devices
completely.

-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering

v2.23.0 | Report a Bug | By Email