[BEHAVE] New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?)

"George, Wes" <wesley.george@twcable.com> Tue, 11 August 2015 12:40 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4CD1A897E; Tue, 11 Aug 2015 05:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.125
X-Spam-Level: **
X-Spam-Status: No, score=2.125 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 82ElyqxzaV2d; Tue, 11 Aug 2015 05:40:07 -0700 (PDT)
Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF5E1A8984; Tue, 11 Aug 2015 05:40:00 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.15,652,1432612800"; d="scan'208,217";a="346460152"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 11 Aug 2015 08:36:02 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 11 Aug 2015 08:39:59 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Ca By <cb.list6@gmail.com>, Toerless Eckert <eckert@cisco.com>
Date: Tue, 11 Aug 2015 08:40:01 -0400
Thread-Topic: New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?)
Thread-Index: AdDUMtYCTafPteQlTg6ZsHzf3Ap4Ow==
Message-ID: <D1EF60F2.643E2%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.5.3.150624
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D1EF60F2643E2wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/behave/0pByHn0BMD7mtY3sM4BHYvoq2K4>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: [BEHAVE] New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2015 12:40:09 -0000

From: v6ops <v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>> on behalf of Ca By <cb.list6@gmail.com<mailto:cb.list6@gmail.com>>
Date: Friday, July 31, 2015 at 9:37 AM

On Thursday, July 30, 2015, Toerless Eckert <eckert@cisco.com<mailto:eckert@cisco.com>> wrote:
For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 for initial
autonomic connectivity, and the question of connecting this (at least initially)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems to be still
weak on a range of commonly used NOC tools.

For something as forward looking as anima , it is unfortunate that you believe you will need to bring this technical debt with you.

My suggeation is that you require ipv6 for this case. If you do not shed this requirement now, you will carry it with you forever.

The iphone can require ipv6 apps, so can anima.

WG] +1. Further, I strongly believe that when considering future network management models, the management overhead of maintaining dual-stack indefinitely is fairly high, and in areas where an operator controls both sides of the equipment, a targeted move to IPv6-only is far more feasible and likely. This is how we and others have deployed IPv6-only applications on our networks today – we're not able to turn off IPv4 in the core anytime soon, but we're certainly able to force new applications that operate only between equipment that we own and manage to use only IPv6 to prevent us from having to find IPv4 addresses to manage the elements involved, especially at large scale. And for those legacy applications and systems that can't do IPv6 and are cost-prohibitive to upgrade, the same is likely true for adding support for Anima.

More generally: Lee and I posed the question to IESG of whether it's appropriate to continue adding new features to IPv4 after seeing no fewer than 3 recent drafts that all add new features into IPv4:
draft-du-anima-ipv4-acp  "Autonomic Control Plane Based on IPv4²

draft-jiang-dhc-sedhcpv4 "Secure DHCPv4"

draft-ietf-tsvwg-natsupp "Stream Control Transmission Protocol (SCTP) Network Address Translation Support"

Is it time to resurrect this draft and push it forward? It doesn't explicitly prohibit work of the type proposed in the above drafts, but I'd like to think that  the current language strongly discourages it.
https://tools.ietf.org/html/draft-george-ipv6-support-03

Wes George

________________________________
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.