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

Ca By <> Tue, 11 August 2015 12:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 667551A89D3; Tue, 11 Aug 2015 05:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aAPP3C_rDXBe; Tue, 11 Aug 2015 05:52:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7A001A89C7; Tue, 11 Aug 2015 05:52:26 -0700 (PDT)
Received: by wicne3 with SMTP id ne3so59402517wic.0; Tue, 11 Aug 2015 05:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CfZkJ4rmT6kcq6o4jAvepeS6ah2ayTqbaqU/4+Vi9xY=; b=qox4ddiBZk1lEIzYjc+G45sQAL54JoIBM0Gd2t1pWJ77sRL3GGVy+CUK9rHE0ISTF7 sCAobPTh/GLMTs3qEgBRF2hnrNS/vO9L8JeU9SaekcFg348Kp4hFMTs5SQgnjTxDHeN2 RzPQsG7rl7v4hlU8Rbd4dltcUdD2iD8ydCf64oHX6LZgSuivhfwucyupQgdxMxvpnnvK 03V8wXVxYJS7hY+Zw4h+7dPySb12Une+DL67GMTalNl3r2uV5pOM9pYlIh3I3YA1v4Ds ytSknXiFi33LSfBpl4AIKuUTuRjBvCchmJZ/JFDYKUHYtPcNQU7cT18WmdG8A0RCZDQB a+dQ==
MIME-Version: 1.0
X-Received: by with SMTP id j5mr59579474wjb.147.1439297545550; Tue, 11 Aug 2015 05:52:25 -0700 (PDT)
Received: by with HTTP; Tue, 11 Aug 2015 05:52:25 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 11 Aug 2015 05:52:25 -0700
Message-ID: <>
From: Ca By <>
To: "George, Wes" <>
Content-Type: multipart/alternative; boundary=e89a8f642b06edc5f1051d08924c
Archived-At: <>
Cc: Toerless Eckert <>, "" <>, "" <>
Subject: Re: [BEHAVE] New features in Legacy IPv4 (was Re: [v6ops] protocols without need for ALG ?)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Aug 2015 12:52:30 -0000

On Tuesday, August 11, 2015, George, Wes <>; wrote:

> From: v6ops <
> <javascript:_e(%7B%7D,'cvml','');>> on behalf of Ca
> By <
> <javascript:_e(%7B%7D,'cvml','');>>
> Date: Friday, July 31, 2015 at 9:37 AM
> On Thursday, July 30, 2015, Toerless Eckert <
> <javascript:_e(%7B%7D,'cvml','');>> 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.
> Wes George

Yes.  We clearly see that folks need the message to be unambiguous


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