Subject: [sunset4] IPv4 to Historic: sending a directional message rather than changing state

From: Erik Nygren <[email-masked]>
Date: Wed, 6 Apr 2016 11:46:29 -0300

Starting a discussion thread here as suggested by Lee Howard in the the
session yesterday.

My sense of the comments in the room (while I don't remember a hum) was
that while it was still too early to advance "IPv4 to Historic", there
would be value in sending a clear message that we are on a path to move
IPv4 to Historic at some point in the future.  This could either be through
sunset4 or preferably by an IETF governance statement.

Some topics for discussion seemed to be:

* Should there be clear guidance to IETF WGs and other standards bodies
that it is acceptable to develop IPv6-only protocols without consideration
for IPv4?   (With the caveat that practical deployments may still have a
need to inter-operate with IPv4, if only as providing IPv4-as-a-service
over IPv6.)  Are there particular efforts (eg, 5G) where we should be
encouraging an "IPv6-first" mindset as part of the design, and is this
something we can do?

* Do we set a time-table for moving to Historic or base this off some
adoption metric?  (80% global IPv6 adoption?  IPv6-only deployments
becoming commonplace in multiple scenarios outside of a few large
companies?)

* Are there other things we can do to reduce the time-window where everyone
has to deal with full dual-stack complexity?  (For example, fixing issues
that remain with some of the transition technologies that allow for
IPv6-only connectivity with IPv4-as-a-service?)

* What would be a good thing to call this: directionally historic,
end-of-engineering, "It's Complicated", to-be-deprecated, ...     (In
particular, we need to make sure the statement made sets expectations but
is is inline with present reality.)

---

From: "Joel Bion (jpbion)" <[email-masked]>
Date: Wed, 6 Apr 2016 16:07:26 +0000

I have a hunch if IPv4 isn't declared historic now, that a year from now you'll be in exactly the same place w.r.t. people saying "not yet" 

"Directionally historic" etc describes the truth of IPv4 for 20 years now - so declaring such a thing is the equivalent of me saying "I will die someday" - not news, and nobody's behavior changes as a result of me saying this. 

The goal of declaring IPv4 historic is not to report on an already achieved truth but to create behavioral change. To make it so that it is harder to do new v4 things and well near impossible to do new v4 only things.

If your goal is to accelerate v6 adoption and usage, start from that position of strength (declare v4 historic) and skillfully and non-pedantically make exceptions as the world needs them. Show grace in allowing new v4 technologies and changes if they hasten and ease transition to v6.

If your goal is to prolong the fence sitting, delay declaring v4 historic, because I can see *zero* value in saying "v4 will be historic someday and we are moving there" 

Sent from my iPhone

> On Apr 6, 2016, at 7:47 AM, Erik Nygren <[email-masked]> wrote:
> 
> Starting a discussion thread here as suggested by Lee Howard in the the session yesterday.
> 
> My sense of the comments in the room (while I don't remember a hum) was that while it was still too early to advance "IPv4 to Historic", there would be value in sending a clear message that we are on a path to move IPv4 to Historic at some point in the future.  This could either be through sunset4 or preferably by an IETF governance statement.
> 
> * Should there be clear guidance to IETF WGs and other standards bodies that it is acceptable to develop IPv6-only protocols without consideration for IPv4?   (With the caveat that practical deployments may still have a need to inter-operate with IPv4, if only as providing IPv4-as-a-service over IPv6.)  Are there particular efforts (eg, 5G) where we should be encouraging an "IPv6-first" mindset as part of the design, and is this something we can do? 
> 
> * Do we set a time-table for moving to Historic or base this off some adoption metric?  (80% global IPv6 adoption?  IPv6-only deployments becoming commonplace in multiple scenarios outside of a few large companies?) 
> 
> * Are there other things we can do to reduce the time-window where everyone has to deal with full dual-stack complexity?  (For example, fixing issues that remain with some of the transition technologies that allow for IPv6-only connectivity with IPv4-as-a-service?)
> 
> * What would be a good thing to call this: directionally historic, end-of-engineering, "It's Complicated", to-be-deprecated, ...     (In particular, we need to make sure the statement made sets expectations but is is inline with present reality.)
> 
> 
> 
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: Arturo Servin <[email-masked]>
Date: Wed, 06 Apr 2016 16:40:31 +0000

Joel

I think that the impact to create behavioral change by declaring IPv4
historic is going to be zero.

The impact in IPv6 deployment that declaring IPv4 historic is going to be
make is zero.

People will be sitting in the fence regarding if IPv4 is historic or no.

Regards
as

On Wed, 6 Apr 2016 at 17:07 Joel Bion (jpbion) <[email-masked]> wrote:

> I have a hunch if IPv4 isn't declared historic now, that a year from now
> you'll be in exactly the same place w.r.t. people saying "not yet"
>
> "Directionally historic" etc describes the truth of IPv4 for 20 years now
> - so declaring such a thing is the equivalent of me saying "I will die
> someday" - not news, and nobody's behavior changes as a result of me saying
> this.
>
> The goal of declaring IPv4 historic is not to report on an already
> achieved truth but to create behavioral change. To make it so that it is
> harder to do new v4 things and well near impossible to do new v4 only
> things.
>
> If your goal is to accelerate v6 adoption and usage, start from that
> position of strength (declare v4 historic) and skillfully and
> non-pedantically make exceptions as the world needs them. Show grace in
> allowing new v4 technologies and changes if they hasten and ease transition
> to v6.
>
> If your goal is to prolong the fence sitting, delay declaring v4 historic,
> because I can see *zero* value in saying "v4 will be historic someday and
> we are moving there"
>
> Sent from my iPhone
>
> > * Are there other things we can do to reduce the time-window where
> everyone has to deal with full dual-stack complexity?  (For example, fixing
> issues that remain with some of the transition technologies that allow for

---

From: Morizot Timothy S <[email-masked]>
Date: Fri, 8 Apr 2016 18:53:24 +0000

Joel Bion wrote:
> I have a hunch if IPv4 isn't declared historic now, that a year from now you'll
> be in exactly the same place w.r.t. people saying "not yet"
> 
> "Directionally historic" etc describes the truth of IPv4 for 20 years now - so
> declaring such a thing is the equivalent of me saying "I will die someday" - not
> news, and nobody's behavior changes as a result of me saying this.

I certainly agree that statements like that are not particularly useful, but I'm not sure that the direct goal from the IETF perspective is trying to change the behavior of operators, at least in this context. The question of whether or not the specification should be historic seems oriented more at where the IETF should focus its efforts developing specifications and how those specifications impact developers and product manufacturers.

> The goal of declaring IPv4 historic is not to report on an already achieved
> truth but to create behavioral change. To make it so that it is harder to do
> new v4 things and well near impossible to do new v4 only things.

I've spent a fair amount of time thinking about this topic, especially in light of the comments at the sunset4 session. Despite what I thought were some pretty clearly expressed distinctions expressed by Lee, a fair number of the comments still seemed to approach this as an effort to "turn v4 off" or to somehow control usage or deployment of v4. Most of the rest of the comments focused on how it impacted where the IETF would or would not focus its time and effort. And that's a lot more accurate, but the directly impacted "customers" (an over-used, but perhaps accurate term in this context) of the work the IETF does with its specifications are the companies and individuals who implement those specifications in products.

So, then, what is the impact to that group if the IETF publishes two Internet Protocol specifications as full standards, one of which clearly states it is the successor to the other in its specification with no other guidance (a declaration of IPv4 as the historic specification or otherwise)? Since there is no defined relationship or restriction and the IETF developed and published a new or modified required or recommended feature in the IPv4 specification, doesn't that mean they would all need to implement that new or changed specification? By keeping both specifications as full standards, the IETF is actually, in a way, signaling implementers that they have to meet two different Internet Protocol specifications if they truly want to be considered interoperable on the Internet. That doesn't look desirable to me.

So I went back and reread some of the process documentation more closely, especially RFC2026, and spent some time thinking about this section.

  6.3  Revising a Standard

   A new version of an established Internet Standard must progress
   through the full Internet standardization process as if it were a
   completely new specification.  Once the new version has reached the
   Standard level, it will usually replace the previous version, which
   will be moved to Historic status.  However, in some cases both
   versions may remain as Internet Standards to honor the requirements
   of an installed base.  In this situation, the relationship between
   the previous and the new versions must be explicitly stated in the
   text of the new version or in another appropriate document (e.g., an
   Applicability Statement; see section 3.2).

While moving the previous version to Historic status is the normal process, if that doesn't occur, then somehow the relationship between the two versions of the standard (including, I would think, the expectations placed on implementers) needs to be clearly outlined. The text of the new version states that it is the successor to the old version, so that's not particularly helpful. Perhaps the intent would be that the IPv6 specification must be met for IP interoperability while the IPv4 specification may optionally also be employed? While the IETF could still work on the IPv4 specification if the need arose, perhaps some specific guidance on the scope of such work could be set. At a minimum, I don't think any such updates to the specification could be considered required.

I'll say that I believe the normal course of action declaring the IPv4 specification historic as Lee proposed would work just fine. The IESG retains the ability to authorize work on the specification if it's really needed but the status of the specification at that point seems well-defined and understood. I also don't have any issues with an alternative process as long as it's also well-defined. I think it would be a problem for the IETF to publish two different versions of the IP specification as full standards without also trying to clearly define what that meant. If the older specification is not historic, what is it? What must be implemented in a product for it to have met all the required elements for IP interoperability. If both are full standards with no other guidance, then wouldn't a product have to implement the required elements of both to be considered to have met the IP specification?

The normal process would be to declare v4 historic when its successor specification is promoted to full standard status. Lee simply started a conversation about that process. Admittedly, changing the specification for the Internet Protocol (IP) itself is a pretty big deal, so something other than the normal process may be warranted. Personally, I didn't find any of the arguments at the session against moving the specification to historic status (as defined within the context of the IETF) particularly compelling, but I also don't object to defining a different relationship. I do object to simply making both specifications a requirement across the board in order to achieve IP interoperability. Sure, in practice most products will implement both. But in a contained environment with constrained resources, a new product (say a network of factory sensors) may decide the v6 version of the IP specification best meets its needs and implement only that protocol in its sensors. I'm sure such an implementer would not feel constrained by the way the IETF labeled its specifications, but the relationship should be defined so that is explicitly supported. Moreover, if v6 is the successor specification, then a v4 only implementation cannot be considered to have met the interoperability requirements of the IP specification. Again, an implementer will do whatever they want, but that choice should not be supported by the specification.

Of course, if I understand the process correctly, if the IETF does nothing to define the relationship and leaves both versions of the specification as full standards, by default that means the required elements of both versions of the specification are always just that -- required for any IP implementation.

Those are my thoughts, such as they are. I support following the normal process, but if that's not done, then an AS or something else should be published explicitly defining what having two active IP specification versions means in practice.

Scott