Re: [v6ops] [sunset4] IPv4 trajectory

"George, Wes" <wesley.george@twcable.com> Thu, 09 April 2015 15:20 UTC

Return-Path: <wesley.george@twcable.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 152E71A8798; Thu, 9 Apr 2015 08:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.475
X-Spam-Level:
X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BgvIX4mqVS8N; Thu, 9 Apr 2015 08:20:24 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86F1A8777; Thu, 9 Apr 2015 08:20:23 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.11,550,1422939600"; d="scan'208";a="851854562"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Apr 2015 11:05:59 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 9 Apr 2015 11:20:22 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Date: Thu, 09 Apr 2015 11:20:26 -0400
Thread-Topic: [sunset4] [v6ops] IPv4 trajectory
Thread-Index: AdBy2LJ8cVZsi0zoS0KflxyLWDnfCQ==
Message-ID: <D14C0670.4CC7F%wesley.george@twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/1-AuRDTQ7ANs5oPZyvBnFWTbLTk>
Cc: IPv6 Ops WG <v6ops@ietf.org>, "sunset4@ietf.org" <sunset4@ietf.org>
Subject: Re: [v6ops] [sunset4] IPv4 trajectory
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, 09 Apr 2015 15:20:26 -0000

I think you mean "it is *not* feasible" in 3.4

Generally, I think updates to the transition guidance are somewhat useful,
at least acknowledging that due to the limited amount of IPv4 address
space available, the notion of continued parallel support for IPv4 such
that you can provide truly native dual-stack is going to become
increasingly difficult without one or more life-support options. We're not
here to judge the presence of those life-support options as good, bad, or
indifferent as much as we are to acknowledge that reality.

I know that I have given guidance in reviews of several recent documents
and given other presentations to socialize the idea that IPv6-only isn't
an all-or-nothing thing, and that some services and devices can move there
much quicker for various reasons, such that you may end up with islands or
certain services that are no longer dependent on IPv4 long before you can
truly turn it off completely. I've also drawn the parallel to the SNA to
IP transition, where people installed gateways that allowed the portion of
the network that supported legacy SNA to be very small (i.e. Right in
front of the offending mainframe) and the rest of the network, including
all remote hosts transition to IP. I see a similar thing happening with
some legacy IPv4-only things, where a specific ALG is deployed to enable
it to speak IPv6 so that you can have IPv6-only hosts access it without
having to do wider IPv6<-> IPv4 transition or deploy IPv4 to a bunch of
hosts solely to support that application.

That said, I'm not sure whether this draft has a lot new to say when
considered with recent documents like Enterprise Incremental (7381), and I
think it'd be more useful to consider something that has more limited
scope, and only discusses the transition to IPv6-only in greater detail.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.