Subject: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 28 Sep 2017 06:26:22 -0700

The IESG has received a request from the Sunsetting IPv4 WG (sunset4) to
consider the following document: - 'IETF: End Work on IPv4'
  <draft-ietf-sunset4-ipv6-ietf-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2017-10-12. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   The IETF will stop working on IPv4, except where needed to mitigate
   documented security issues, to facilitate the transition to IPv6, or
   to enable IPv4 decommissioning.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-george-ipv6-support: IPv6 Support Within IETF work (None - )

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Sep 2017 10:34:55 -0400

I remain opposed for the reason I gave last time this was proposed: The
IETF should retain control of IPv4 and any statement to the effect that the
IETF will no longer work on IPv4 will inevitably lead to formation of an
IPv4 legacy standards group in competition with IETF.

Like it or not, FORTRAN and COBOL are still in common use a full 40 years
after they were functionally obsolete. I see no reason to believe that
anyone will need more than 32 bits of addressing for their home network.
There being no compelling reason for my coffee pot to be able to talk to
the entire Internet, I have a compelling reason to prevent it doing so.

Rather than sunset IPv4, I would sunset IPv4 as an Internet protocol and
relegate it to use as a network protocol only.

As a network protocol, IPv4 remains far superior to many other protocols
that the IETF continues to support and should begin supporting. I do not
believe in a model where every device connects directly to the Internet.
There is a proper role for the local loop and RS485, SPI, IC2 etc. devices
in IoT and there is a role for IPv4.

---

From: Lee Howard <[email-masked]>
Date: Thu, 28 Sep 2017 12:18:31 -0400

From:  sunset4 <[email-masked]> on behalf of Phillip Hallam-Baker
<[email-masked]>
Date:  Thursday, September 28, 2017 at 10:34 AM
To:  IETF Discussion Mailing List <[email-masked]>
Cc:  <[email-masked]>, <[email-masked]>,
<[email-masked]>, IETF-Announce
<[email-masked]>, <[email-masked]>
Subject:  Re: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt>
(IETF: End Work on IPv4) to Proposed Standard

> I remain opposed for the reason I gave last time this was proposed: The IETF
> should retain control of IPv4 and any statement to the effect that the IETF
> will no longer work on IPv4 will inevitably lead to formation of an IPv4
> legacy standards group in competition with IETF.

That would be an interesting development. But the document is hard to
interpret as “The IETF has abdicated responsibility for IPv4.” For instance,
the third sentence:
Until the time when IPv4 is no longer in
   wide use and/or declared historic, the IETF needs to continue to
   update IPv4-only protocols and features for vital operational or
   security issues.
Similarly:
Some changes may be necessary in IPv4 protocols to
   facilitate decommissioning IPv4 in a way that does not create
   unacceptable impact to applications or users.

And also:
   The IESG will review proposed working group charters to ensure
      that work will be capable of operating without IPv4, except in
      cases of IPv4 security, transition, and decommissioning work.

Finally, looking at the number of times we have actually Updated RFC791
"INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION” (four
times, if I recall correctly) suggests to me that a competing standards body
created for the purpose of updating IPv4 would find itself with little to
do.

> after they were functionally obsolete. I see no reason to believe that anyone
> will need more than 32 bits of addressing for their home network. There being
> no compelling reason for my coffee pot to be able to talk to the entire
> Internet, I have a compelling reason to prevent it doing so.
> 

Then change the name to NPv4?

Do we care what people do on their private networks? Is it any of our
business?

Lee

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 28 Sep 2017 13:07:44 -0400

Lee,

Thanks, you’re right, BCP is much more appropriate than Informational, it’s
what I should have said in the first place. But PS still isn’t appropriate.

To your last question about private networks - I think we do care, to the
extent that the same protocols, equipment, and code paths are used both for
private networks and the public Internet. But as you pointed out, the draft
doesn’t say that we abandon IPv4.

Cheers,
Andy

On Thu, Sep 28, 2017 at 12:18 PM, Lee Howard <[email-masked]> wrote:

>
>
> From: sunset4 <[email-masked]> on behalf of Phillip
> Hallam-Baker <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <
> [email-masked]>, IETF-Announce <
> [email-masked]>, <[email-masked]>
> interpret as “The IETF has abdicated responsibility for IPv4.” For
> instance, the third sentence:
>
> Finally, looking at the number of times we have actually Updated RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION” (four times, if I recall correctly) suggests to me that a competing standards body created for the purpose of updating IPv4 would find itself with little to do.
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 28 Sep 2017 18:17:24 +0100

As I have said before, I think that it would be a mistake to make this 
declaration.

A lot of the world still relies heavily on IPv4, and many countries 
would rightly regard IPv4 as critical national infrastructure.

If the IETF announces that it is no longer supporting IPv4, then those 
countries would have every right to demand that the ITU-T took over 
responsibility for IPv4 development and maintenance of the protocol. If 
that happened you would naturally expect them to extend its life, 
perhaps even creating a viable competitor to IPv6 with all of the 
difficulty and confusion that would then result.

Whilst I think the elements of the ID that talk about ensuring that 
every protocol can run in an IPv6 only network are useful, although much 
stated in the past, I think that it would be a serious mistake to give 
any appearance of abandoning IPv4.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 28 Sep 2017 18:27:11 +0100

Set aside that we will develop IPv6 as necessary. I am sure we will do that.

I can see lots of down side in making this declaration, which may be 
interpreted as we intend, but more likely as others with political or 
commercial ambition spin it.

Making this statement has the potential to develop into a huge inter-SDO 
fight.

I am not at all clear on the upside.

We should make declarations about IPv6, but remain silent on IPv4.

- Stewart

On 28/09/2017 17:18, Lee Howard wrote:
>
>
> From: sunset4 <[email-masked] 
> <mailto:[email-masked]>> on behalf of Phillip Hallam-Baker 
> <[email-masked] <mailto:[email-masked]>>
> To: IETF Discussion Mailing List <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] 
> <mailto:[email-masked]>>, IETF-Announce 
> <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [sunset4] Last Call: 
> <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to 
> Proposed Standard
>
>     I remain opposed for the reason I gave last time this was
>     proposed: The IETF should retain control of IPv4 and any statement
>     to the effect that the IETF will no longer work on IPv4 will
>     inevitably lead to formation of an IPv4 legacy standards group in
>     competition with IETF.
>
>
> The IESG will review proposed working group charters to ensure that 
> work will be capable of operating without IPv4, except in cases of 
> IPv4 security, transition, and decommissioning work.
> Finally, looking at the number of times we have actually Updated 
> RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL 
> SPECIFICATION” (four times, if I recall correctly) suggests to me that 
> a competing standards body created for the purpose of updating IPv4 
> would find itself with little to do.
>
>
>     Like it or not, FORTRAN and COBOL are still in common use a full
>     40 years after they were functionally obsolete. I see no reason to
>     believe that anyone will need more than 32 bits of addressing for
>     their home network. There being no compelling reason for my coffee
>     pot to be able to talk to the entire Internet, I have a compelling
>     reason to prevent it doing so.
>
>     Rather than sunset IPv4, I would sunset IPv4 as an Internet
>     protocol and relegate it to use as a network protocol only.
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Sep 2017 19:29:28 +0100

The underlying intent of this document may be well intentioned, but the execution is lacking. As currently presented I strongly oppose it's publication as an IETF RFC.

1. The document title is (wilfully?) melodramatic and is in conflict with the content of the document. This document specifically lists circumstances under which the authors think that the IETF should continue to work on IPv4. Using this document title will do nothing more than cause confusion, panic, and result in the kind of "land grab" that others have worried about. Can the title please be changed to reflect the actual content of the document.

>   to enable IPv4 decommissioning.
...but Section 1 adds to this list the very important point that 
>  security issues.  "Vital" means "necessary for successfully operating
>  IPv4 networks."  
...The Abstract must give an accurate account of what the document says. This could be achieved by saying less ("This document describes the IETF's approach to new work on IPv4 and IPv4-only protocols") or more (by setting out the full list of cases as described in Section 1).

3. The bullet list in Section 1 concludes with:
>    New IETF work must function completely on IPv6-only nodes and
>    networks.
...This is ambiguous after the previous bullets. I believe that either there is some special meaning of "New" intended here (different from in previous bullets) or this is meant to read something like:
|  All new IETF work must be capable of functioning in IPv6-only networks.

4. The IANA Considerations section attempts a commentary that is probably unhelpful. It might be helpful to replace this with a "standard" Null IANA section as that will be clearer and is entirely consistent with the ask (which is null).

5. You might consider adding some statement about documentation of examples in new RFCs (idnits already drops a strong hint, but most authors chose to ignore it). It might be too strong to require non-documentation of IPv4 examples, but inclusion of IPv6 examples whenever there is an IPv4 example sounds like a good idea "unless there is a good and documented reason why not."

And lastly, just to check...
Suppose I have a protocol that runs in a private network using a private address space, and suppose that that network currently uses IPv4. Take as an example a network that uses management or control protocol running between the routers and separate from the traffic carried over the network. 
My reading of this I-D is that those protocols can be enhanced and features added provided that those additions are also made such that the protocols would work perfectly in an IPv6-only network.
If it is not the intention that I should be able to make this reading, then words should be changed.

Thanks,
Adrian

> -----Original Message-----
> From: IETF-Announce [mailto:[email-masked]] On Behalf Of The
> IESG
> Sent: 28 September 2017 14:26
> To: IETF-Announce
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4)
> to Proposed Standard
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Sep 2017 23:08:19 +0200

Hi Lee and others,

I agree with Adrian and would go a bit further.  The abstract seems to
contradict the content.  That needs correcting, one way or the other. 
This reader in particular is confused as to the document's intent.  And
so, I have these questions:

 1. If I wish to add a new DHCPv4 option as well as a similar DHCPv6
    iption, would that contravene the intent of this document?
 2. If I wish to add a field that would permit IPv4 addresses and IPv6
    addresses, would that contravene the intent of this document?

Let us presume for purposes of answering these questions that we are
talking about non-security and non-transitional work.

I also have a comment about the charter of sunset4 with regard to this
document.  I was expecting to see a gap analysis first, and I wasn't
particularly expecting a policy statement from this WG.

I share the sentiment of the abstract, but I also share the concerns
that Stewart raised.  If there is a demand for IPv4 improvements, and
the IETF won't satisfy it, others will fill that vacuum.  That sort of
problem has posed a substantial amount of work for the IAB, the IESG,
ISOC, and the IETF Trust in the past.

Thanks,

Eliot

---

From: David Farmer <[email-masked]>
Date: Thu, 28 Sep 2017 17:40:35 -0500

On Thu, Sep 28, 2017 at 11:18 AM, Lee Howard <[email-masked]> wrote:

> However the document title does say "IETF: End Work on IPv4", and the
abstract starts with "The IETF will stop working on IPv4".  Many people
might never get past the title and abstract, they easily will be left with
the wrong impression. I seriously doubt most politicians would get much
past the title and abstract.

I have to say, the current title sure makes it sound like work is going to
stop cold-turkey on IPv4. Maybe the title and abstract need a little more
nuance like the body of the text has.

How about something more like this;

Title

   IETF: Limiting New Work on IPv4

Abstract

   The IETF will limit new work on IPv4, except where needed to mitigate
   documented security issues, to facilitate the transition to IPv6, or
   to enable the eventual decommissioning of IPv4 on some networks.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Sep 2017 10:59:32 -0400

> Do we care what people do on their private networks? Is it any of our
​Since network use of IETF protocols is at least as important as Internet,
yes it is very much IETF business if it wants to remain relevant.

As for what the IPv4 consortium would do, I wrote out a draft list:

* Determine IPR policy.
* Chose venues for upcoming meetings.​
* Form advisory committees.
* Hold elections to advisory committees.
* Set a schedule of membership fees.

And that is just for starters.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Sep 2017 16:14:06 +0100

On 29/09/2017 15:59, Phillip Hallam-Baker wrote:
>
>
> On Thu, Sep 28, 2017 at 12:18 PM, Lee Howard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Do we care what people do on their private networks? Is it any of
>     our business?
>
>     Lee
>
>
> ​Since network use of IETF protocols is at least as important as 
> Internet, yes it is very much IETF business if it wants to remain 
> relevant.
>

... and they might perhaps figure out some technology wheeze that we did 
not notice, or which was less pure than we would accept, but none the 
less acceptable to most users, and thereby find a way to extend the 
service life of IPv4.

- Stewart

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Sep 2017 11:25:17 -0400

On Fri, Sep 29, 2017 at 11:14 AM, Stewart Bryant <[email-masked]>
wrote:

> not notice, or which was less pure than we would accept, but none the less
> acceptable to most users, and thereby find a way to extend the service life
> of IPv4.
>
> - Stewart
>

​Like running IPv4 on the internal network and only translating to IPv6 at
the interface? That is exactly what I would expect such a body to develop.​
And the reason companies not represented in IETF would be more than happy
to pay to join such a consortium is that gifting $50K/year to develop
standards to keep their legacy systems running would be a lot cheaper than
paying network equipment vendors millions to upgrade all the gear in their
company.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Sep 2017 14:48:13 +1300

First of all, I agree with those who have said this should be
a BCP, if published. BCPs are the way we publish IETF process
rules.

Secondly, I think many of the comments about the tone and slant
are correct. What we want to stop is work on solutions that
are *specific* to IPv4, and to chase down and elminate any
cases where successful IPv6 operation depends on the presence
of IPv4.

The rest will take care of itself. There's no need to preach.

A few suggestions follow. The main problem at the moment is
too many words.

Abstract

   The IETF has stopped working on solutions that are specific to
   IPv4, except where needed to mitigate documented security issues,
   to facilitate the transition to IPv6, or to enable IPv4
   decommissioning.
...
1.  Statement

   The IETF has developed IPv6 to replace IPv4.

   Ongoing focus is required to ensure that future IETF work supports
   the evolution of the Internet towards IPv6-only operation. However,
   until the time when IPv4 is no longer in widespread use, the IETF
   needs to continue to update IPv4-only protocols and features for
   vital operational or security issues...
   ...
      The IESG will review proposed working group charters to ensure
      that new work will be capable of operating with IPv6, and with
      or without IPv4.

Note: that "with or without" is important if we expect to be taken
seriously.

      The IETF will update IPv4 protocols and features only to
      repair serious security faults or to facilitate IPv4
      decommissioning and IPv6 transition.

and delete this because it's redundant after the above changes:

      New IETF work will explicitly support IPv6, or be IP version
      agnostic (because it is implemented above the network layer),
      except IPv4-specific transition technologies.

Regards
   Brian Carpenter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 30 Sep 2017 11:45:57 +0200

On Thu, Sep 28, 2017 at 11:08:19PM +0200,
 Eliot Lear <[email-masked]> wrote 
 a message of 418 lines which said:

> I have these questions:

For me, section 1 of the draft is crystal-clear "No IPv4-only feature
will be added unless there's an equivalent feature added in the IPv6
version." Which means the answer is No to your two questions.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 30 Sep 2017 11:48:30 +0200

On Thu, Sep 28, 2017 at 06:17:24PM +0100,
 Stewart Bryant <[email-masked]> wrote 

> would rightly regard IPv4 as critical national infrastructure.

So what? The draft never says "IPv4 MUST be shutdown tomorrow".

> If the IETF announces that it is no longer supporting IPv4,

The draft says nothing like that, quite the opposite.

I think the discussion derailed from an actual draft to a fight
against a strawman.