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

[The IESG]

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
***@ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be
sent to ***@ietf.org 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 - )

[Phillip Hallam-Baker]

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.

[Lee Howard]

From: sunset4 <sunset4-***@ietf.org> on behalf of Phillip Hallam-Baker
<***@hallambaker.com>
Date: Thursday, September 28, 2017 at 10:34 AM
To: IETF Discussion Mailing List <***@ietf.org>
Cc: <***@ietf.org>, <sunset4-***@ietf.org>,
<draft-ietf-sunset4-ipv6-***@ietf.org>, IETF-Announce
<ietf-***@ietf.org>, <***@icann.org>
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.

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.

Then change the name to NPv4?

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

Lee

[Andrew G. Malis]

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

Date: Thursday, September 28, 2017 at 10:34 AM
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
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.
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.
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.
Then change the name to NPv4?
Do we care what people do on their private networks? Is it any of our
business?
Lee

[Stewart Bryant]

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

Date: Thursday, September 28, 2017 at 10:34 AM
<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
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.
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.
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.
Then change the name to NPv4?
Do we care what people do on their private networks? Is it any of our
business?
Lee

[David Farmer]

Date: Thursday, September 28, 2017 at 10:34 AM
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
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.
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.
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.
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.

[Phillip Hallam-Baker]

Post by Lee Howard
Then change the name to NPv4?
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.

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.

[Stewart Bryant]

Post by Lee Howard
Then change the name to NPv4?
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.
* 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.

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

[Phillip Hallam-Baker]

Post by Phillip Hallam-Baker

Post by Lee Howard
Then change the name to NPv4?
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.
* 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.
... 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

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

[Stewart Bryant]

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

Post by The IESG
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
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.
draft-george-ipv6-support: IPv6 Support Within IETF work (None - )

[Stephane Bortzmeyer]

On Thu, Sep 28, 2017 at 06:17:24PM +0100,

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

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

Post by Stewart Bryant
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.

[Adrian Farrel]

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.

Post by The IESG
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.

...but Section 1 adds to this list the very important point that

Post by The IESG
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. "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).

Post by The IESG
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

Post by The IESG
-----Original Message-----
IESG
Sent: 28 September 2017 14:26
To: IETF-Announce
Subject: Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4)
to Proposed Standard
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
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.
draft-george-ipv6-support: IPv6 Support Within IETF work (None - )

[Eliot Lear]

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

Post by Adrian Farrel
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.

Post by The IESG
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.

...but Section 1 adds to this list the very important point that

Post by The IESG
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. "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).

Post by The IESG
New IETF work must function completely on IPv6-only nodes and
networks.

| 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

Post by The IESG
-----Original Message-----
IESG
Sent: 28 September 2017 14:26
To: IETF-Announce
Subject: Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4)
to Proposed Standard
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
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.
draft-george-ipv6-support: IPv6 Support Within IETF work (None - )

[Stephane Bortzmeyer]

On Thu, Sep 28, 2017 at 11:08:19PM +0200,

Post by Eliot Lear
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?

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.

[Brian E Carpenter]

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

[Jacques Latour]

I think we need to be very specific to mention where the focus is applied, either in on the global Internet or on the Network {internal, home, corporate}.

Saying we're shutting down IPv4 scares a lot of people but that's not in scope because on the Network (internally) come to mind right away. The focus is on the Internet.


Abstract

The IETF has stopped working on IPv4 protocol only solutions that are specific to global Internet.
The IETF has stopped working on IPv4 protocol solutions except where needed to mitigate documented security issues.
The IETF has not stopped working on IPv4 protocol solutions to facilitate the transition to IPv6, or to enable IPv4 decommissioning on the global Internet.
The IETF has no 'plans' to decommission the IPv4 protocol on the Network {internal, home, corporate}.

[Joe Touch]

Post by Brian E Carpenter
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.

A BCP with the right tone and focus might be useful.

Post by Brian E Carpenter
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.

I disagree.

We need to consider IPv4 work as "maintenance mode", which can easily
include solo IPv4 adjustments and/or include IPv4 support in new
protocols that also support IPv6. Neither necessarily need involve
transition or deprecation.

"no new work" or "no IPv4-specific work" both assume that IPv6 is a
superset of IPv4, which it is not. We're still wrangling with aspects of
IPv6 that actually are evolving back into IPv4-like approaches, e.g.,
limits to the length of the header chain and problems supporting
fragment traversal of routers.

Joe

[Brian E Carpenter]

Post by Joe Touch

Post by Brian E Carpenter
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.

A BCP with the right tone and focus might be useful.

Post by Brian E Carpenter
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.

I disagree.
We need to consider IPv4 work as "maintenance mode", which can easily
include solo IPv4 adjustments and/or include IPv4 support in new
protocols that also support IPv6. Neither necessarily need involve
transition or deprecation.

I'm not sure that we disagree modulo wordsmithing. Saying that IPv4
is in maintenance mode is fine. Security and bug fixes are clearly
maintenance.

Post by Joe Touch
"no new work" or "no IPv4-specific work" both assume that IPv6 is a
superset of IPv4, which it is not.

I don't see that assumption either stated or implied. If there are
features missing in IPv6, that's a completely separate topic.

Post by Joe Touch
We're still wrangling with aspects of
IPv6 that actually are evolving back into IPv4-like approaches, e.g.,
limits to the length of the header chain and problems supporting
fragment traversal of routers.

I don't see what that has to do with the draft under discussion.

Regards
Brian

[Joe Touch]

Post by Brian E Carpenter

Post by Joe Touch
"no new work" or "no IPv4-specific work" both assume that IPv6 is a
superset of IPv4, which it is not.

I don't see that assumption either stated or implied. If there are
features missing in IPv6, that's a completely separate topic.

I was arguing against new wording that might use the quotes above. IMO,
the current doc is even more restrictive.

Post by Brian E Carpenter

Post by Joe Touch
We're still wrangling with aspects of
IPv6 that actually are evolving back into IPv4-like approaches, e.g.,
limits to the length of the header chain and problems supporting
fragment traversal of routers.

I don't see what that has to do with the draft under discussion.

It was intended as an example of how IPv6 is not a superset of IPv4.

Joe

[S Moonesamy]

Hello,

I'll disclose that there is a potential conflict of interest and I am
involved in a RIR [1].

Post by The IESG
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

I read this short draft and the document shepherd write-up. The
explanation about why the document should be published as a "Proposed
Standard" is that "it creates key implications on all future
standards track documents". Is that what the "Proposed Standard"
label is about?

There is the following in Section 1: "Until the time when IPv4 is no
longer inwide use and/or declared historic ..." It is unrealistic to
envision a near future where the IETF would "declare" IPv4 as "Historic".

I'll commend the author for not overloading the "must" in this
draft. Is this document about the IETF not doing any more work on
IPv4-related technologies unless there is a security issue to fix and
there is consensus [2] to do that?

Regards,
S. Moonesamy

1. Please do not read the disclosure as a statement from the RIR. My
interest predates the RIR involvement.
2. Please see Section 2 of the draft.