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

From: "George, Wes" <[email-masked]>
Date: Tue, 11 Aug 2015 08:40:01 -0400

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Ca By <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 31, 2015 at 9:37 AM

On Thursday, July 30, 2015, Toerless Eckert <[email-masked]<mailto:[email-masked]>> 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.

---

From: Ca By <[email-masked]>
Date: Tue, 11 Aug 2015 05:52:25 -0700

On Tuesday, August 11, 2015, George, Wes <[email-masked]> wrote:

>
> From: v6ops <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of Ca
> By <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> On Thursday, July 30, 2015, Toerless Eckert <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> 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.
>
> 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:
> 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.

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Aug 2015 11:46:59 +1000

On 11 August 2015 at 22:52, Ca By <[email-masked]> wrote:
>> From: v6ops <[email-masked]> on behalf of Ca By
>> <[email-masked]>
>> On Thursday, July 30, 2015, Toerless Eckert <[email-masked]> wrote:
>>>

<snip>

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

Deprecating IPv4 would do the trick. Doesn't mean you can't use it,
doesn't mean it can't continue to be fixed, just means that it has
become the legacy Internet protocol.

"Will IPv4 be formally deprecated when IPv6 is good enough ?"

https://www.ietf.org/mail-archive/web/ipv6/current/msg00295.html

Regards,
Mark.

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 12 Aug 2015 09:25:21 -0400

>become the legacy Internet protocol.

I searched in vain for an IETF definition of ³Deprecated,² although I did
find some examples.
I found a definition of ³Historic² (sort of) in rfc2026 and an old
clarifying draft draft-yevstifeyev-genarea-historic-03.
All of those words seem to suggest that the deprecated/historic/obsolete
protocol could still be used, but to be careful with it. I¹d call it a
SHOULD NOT, meaning don¹t unless you have a really good reason.
I would be delighted if somebody has pointers to better definitions.

This work would need to happen in 6man or intarea WG, I think. I therefore
offer no opinion here.

Lee

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Aug 2015 23:35:52 +1000

> I would be delighted if somebody has pointers to better definitions.

Hmm, I've thought the term "deprecated" was in more common use in the
IETF, as it has been in the context of protocols that I've learnt the
definition of the word - it means it'll still work, but isn't the best
or recommended way to solve the problem. SHOULD NOT would be the same
thing.

Regards,
Mark.

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 Aug 2015 10:52:05 -0300

Would it be worth modelling the inclusion of DEPRECATED as a new normative
word, and rehearse what exactly we'd want it to mean?

-George

On Wed, Aug 12, 2015 at 10:35 AM, Mark Smith <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: t.petch <[email-masked]>
Date: Thu, 13 Aug 2015 17:47:26 +0100

----- Original Message -----
From: "Howard, Lee" <[email-masked]>
To: "Mark Smith" <[email-masked]>; "Ca By" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 12, 2015 2:25 PM
>>> explicitly prohibit work of the type proposed in the above drafts,
but
>>>I'd

I searched in vain for an IETF definition of ³Deprecated,² although I
did
find some examples.

Howard

I saw 'deprecated' used in an IANA registry 29aug2013 and raised the
issue of a lack of definition on the main ietf list.  Since then,
5226bis has been updated to say that the term is in use but should not
be.

The term has long had a well-defined meaning in SMI.

Tom Petch

This work would need to happen in 6man or intarea WG, I think. I
therefore
offer no opinion here.

Lee

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.

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Aug 2015 18:09:58 -0500

> On Aug 12, 2015, at 08:25, Howard, Lee <[email-masked]> wrote:

From RFC 7526 "Deprecating the Anycast Prefix for 6to4 Relay Routers", Section 2;

> In this document, the word "deprecate" and its derivatives are used only in their generic sense of "criticize or express disapproval" and do not have any specific normative meaning. A deprecated function might exist in the Internet for many years to allow backwards compatibility.

I personally think it is best for the word to not have a normative meaning, and leave it to plain English.  If you want/need to normatively tell someone something similar use "SHOULD NOT use", "MUST NOT use", or maybe "SHOULD NOT continue development" as appropriate.  

Although this subject seems like excellent fodder for an update to RFC6919. :)

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================