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

[Ca By <[e-mail]>]

On Tuesday, August 11, 2015, George, Wes <[e-mail]> wrote:

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


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

CB


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