Subject: Re: End Work on IPv4

From: "R. Atkinson" <[email-masked]>
Date: Mon, 2 Oct 2017 10:57:01 -0400

All,

1. My guess is that most folks agree with the principle of not undertaking new IPv4-only work.

2. Similarly, if the IESG were to adopt a practice/policy (if they haven’t already done so)
    that IPv4-only work on the IETF-Track required an IESG exception, then I think
    most folks here would be fine with that.

3. Many networks will need to be dual-stack (IPv4 + IPv6) for many years to come.
    This is a practical reality, even though it is inconvenient and politically incorrect.
    So there likely will be specific areas where work that applies both to IPv4 and IPv6
    will need to be undertaken both now and in the foreseeable future.  This ought not
    conflict with (1) above.

Discussion:
————————

The particular I-D (draft-ietf-sunset-4-ipv6-ietf-01.txt) is not sufficiently clearly written,
if it is trying to achieve either of the objectives (1-3) above.  I think many folks would like
to see at least both the title and abstract re-worked, probably the whole draft reworked,
to make it more clear that the objective is to discontinue most IETF IPv4-only work.
Certainly, I would want the title, the abstract, and the rest of the document to be edited 
to have a consistent, clear, and non-inflammatory message consistent with (1-3) above.

I have to agree with Stephen Farrell that the best we can hope for in this are is to avoid
“most” IPv4-only work, on grounds that if a major issue (e.g., security) arose in some 
IPv4-specific specification, then the IETF ought to address/resolve that IPv4-unique issue.

However, if the IETF tries to take a hard line that no new IPv4 work is allowed, then the 
practical result will be that some other standards body will simply do IPv4-unique work
outside the IETF (in practice; de facto) — which would be a very bad outcome, both for 
interoperability and for global standards cooperation.

Yours,

Ran

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 02 Oct 2017 16:28:53 +0100

> interoperability and for global standards cooperation.

+1

>From a higher level point of view, I'm struggling to understand what
concrete problem publishing draft-ietf-sunset-4-ipv6-ietf (or something
similar) will fix.

If the IETF feels that it needs a mission statement about ipv6 and a
statement requiring protocol parity / equivalence between ipv4 and ipv6,
then that would be more useful.

Nick

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 2 Oct 2017 23:21:10 +0200

A) Is there any good written summary (draft or RFC) for actual examples of recently attempted
"IPv4 only" work in the IETF - (go read arbitrary ietf mailing archives does not count) ?
I am a bit disappointed that no examples are included in draft-ietf-sunset-4-ipv6-ietf.

B) The way i read the charter of sunset4, it only talks about sunsetting IPv4 for the Internet.
What i am unclear about is how the IETF cares about other IP networks. I would not be
surprised if the mayority of revenue from IETF technologies on this planet is made across
other networks than the Internet, and for those network no discussion about future requirements has
happened in the same manner as for the Internet.

C) I wonder how much the IETF is willing to entertain groups interested in IPv4 only
work in a way that spreads the pain equally between them and IPv6 evangelists:

1. Define the technology to support both IPv4 and IPv6.
2. Implementations meant to be useable across the Internet MUST support IPv6 only,
   MAY support dual-stack.
3. Requirements for deployments meant for other networks wrt to stack support are
   subject to the WG decision (including an IPv4 only profile).

Point 1 would create pain for folks interested only in IPv4 work. I think that for
the benefit of getting an RFC out of it (including all the expert community review
going along with it), they would be willing to do this.
Point 2 is my best understanding of current IETF thinking, so its neutral.
Point 3 would be the pain point for the IPv6 evangelists in IETF.

Of course, this attempt to get best of both worlds would not work for extensions
to existing IPv4 only protocols like OSPFv2 or ARP or the like, which is why i am
asking A) - to understand how much of a problem those protocols are.

Cheers
    Toerless

On Mon, Oct 02, 2017 at 10:57:01AM -0400, R. Atkinson wrote:
> 2. Similarly, if the IESG were to adopt a practice/policy (if they haven???t already done so)
> ????????????????????????
> ???most??? IPv4-only work, on grounds that if a major issue (e.g., security) arose in some 
> outside the IETF (in practice; de facto) ??? which would be a very bad outcome, both for

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Oct 2017 07:40:00 +0900

> 3. Many networks will need to be dual-stack (IPv4 + IPv6) for many

dual stack requires an ipv4 address for every ipv6 address.  the ipv6
wise folk who thought dual stack was *the* transition mechanism did not
anticipate it would take decades; and hence run into the little problem
that 2^32 is a wee bit smaller than 2^128.

so we get widespread cgns.  https://dl.acm.org/citation.cfm?id=2987474

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 2 Oct 2017 21:51:57 -0400

I spent some time thinking about work that we might do on IPv4.

The only things I can think of are things that would be IPv4 only because
they were transition hacks to IPv6 and irrelevant in the IPv6 world.

For example, two hosts sitting on IPv4 local networks behind a NAT talking
to a IPv4 presence service to establish an IPv6 session between the two NAT
boxen.

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 05:25:55 -0700

> 1. My guess is that most folks agree with the principle of not undertaking new IPv4-only work.

I, for one, do not.

There may be a time when we can deprecate IPv4 this way, but that time
has not arrived.

IPv4 remains in very active use and there are plenty of ways in which
new IPv4-related work could be important beyond the specific areas of
security, transitioning, or decommissioning.

While I agree that new IPv4 work should not be the focus of the IETF,
it's entirely possible that new work ion other protocols will be need to
support *both* IPv4 and IPv6 (without direct involvement in
transitioning) or that there will be IPv4-specific enhancements that are
useful beyond the limited areas above.

I see no good reason for the proclamations in
draft-ietf-sunset4-ipv6-ietf, and I agree with Ran's assessment below of
the quality of this doc.

Joe

(continued from Ran:)

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 05:32:49 -0700

> I am a bit disappointed that no examples are included in draft-ietf-sunset-4-ipv6-ietf.

RFC6864 - IMO, 4 years is fairly recent.

RFC 791 had errata 5038 reported June 6 2017 (still under review) and
errata 4752 reported in 2016 and just approved as "held for document
update" this year.

Both have no relation to any of the approved areas for IPv4 work in
sunset4-ipv6.

Joe

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 4 Oct 2017 14:00:31 -0400

> On 2Oct2017, at 17:21, Toerless Eckert <[email-masked]> wrote:
> 

With respect to OSPF, my understanding is:

- OSPFv2 can only be carried by IPv4 and only carries IPv4 prefixes.  

- OSPFv2 is extraordinarily widely deployed in enterprise IP networks (and residential networks).
  I very much doubt that many those enterprise deployments will drop OSPFv2 anytime soon.  

- OSPFv3 now has clear specifications (but RFC-7949 is quite recent) to enable OSPFv3 
  to be carried  by IPv4 and by IPv6, BUT I am unclear how widespread support for that
  extension is in shipping commercial IP routers at present.

- OSPFv3’s Address Family extension (RFC-5838) permits any OSPFv3 instance to carry
  both IPv4 routing information and IPv6 routing information.  I am unclear how widespread
  support for this extension is in shipping commercial IP routers at present.

- I believe some OSPFv2 extensions are being undertaken — e.g., “segment routing”
  (sic) extensions that are equivalent to the corresponding OSPFv3 “segment routing”
  extensions.  

- Given the huge deployed base of OSPFv2, it makes sense to have equivalent
  extensions in both OSPFv2 and OSPFv3 for some while yet, IMHO.

One of the Routing ADs or OSPF WG Chairs might be able to clarify/confirm the beliefs
outlined above.

With respect to ARP, I do not know of any current work, but if some new security
situation arose, then the IETF ought to be able to make appropriate changes and/or
extensions to the ARP specifications.

Cheers,

Ran

---

From: Tim Chown <[email-masked]>
Date: Thu, 5 Oct 2017 09:24:46 +0100

Hi,

> On 4 Oct 2017, at 13:25, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Perhaps we should be creating a 4man WG, for “IPv4 Maintenance”...

Tim

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Oct 2017 05:21:51 -0700

> Perhaps we should be creating a 4man WG, for “IPv4 Maintenance”...

If there becomes enough work to warrant a separate WG, perhaps. Until
then, INTAREA has been sufficient

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 5 Oct 2017 19:11:19 +0200

gerontology4, geriatrics4 ?

Kidding aside: why should that work not be done via  sunset4 (modify charter) ?
There is a whole world of venture capitalists specialising in maximizing
business opportunities from sunset industries/technologies. As long as we define 
better than sunset4 != kill4 i would still prefer to express the fact
that the goal of the group is different from eg: 6man.

Cheers
    Toerless

On Thu, Oct 05, 2017 at 05:21:51AM -0700, Joe Touch wrote:
> > Perhaps we should be creating a 4man WG, for ???IPv4 Maintenance???...
> >
> > Tim
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Oct 2017 10:17:45 -0700

> On Oct 5, 2017, at 10:11 AM, Toerless Eckert <[email-masked]> wrote:
> 
> As long as we define 

We can, but that’s not how I interpret the current doc. 

Joe