Subject: [sunset4] review of sunset4-gap-analysis

From: "Lee Howard" <[email-masked]>
Date: Mon, 12 Nov 2012 11:47:50 -0500

I promised to review the document.  I have not included proofreading notes
(spelling, grammar, etc.) but I would be happy to do so.

Abstract:
"and identifies the gaps resulting in additional work"
/resulting in/requiring

Related work: the RFCs in this list are lists of RFCs requiring IPv4.  Have
the authors reviewed them to see whether any protocol work is required?  The
documents often point to works-in-progress as of 2004; has all of that work
been completed?
I am delighted to see that RFC1149 has no IPv4-specific requirements, and
thus does not require updating.

PROBLEM 1.  I could argue that failure to find a DHCP server is a failure
condition.  It may not be a fatal error, but more specificity is needed
here.  What happens that's bad?
How do you tell the difference between "The DHCP (IPv4) server is down" and
"IPv4 is gone forever"?

PROBLEM 2.  Which DHCP messages do you mean?  Do you mean in Advertise
messages?  Does a server send an Offer if it has no addresses?  What about
when there's no IPv4 on the WAN, but IPv4 is still needed for internal
communication?

PROBLEM 3.  Separate problem descriptions are needed for home networks and
enterprise networks.

This document either needs to include a section on "How to know you IPv4
isn't needed any more" or needs to say explicitly, "The decision about when
to turn off IPv4 is out of scope."

Lee

---

From: "George, Wes" <[email-masked]>
Date: Mon, 12 Nov 2012 14:14:24 -0500

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lee Howard
>
> Related work: the RFCs in this list are lists of RFCs requiring IPv4.
> Have the authors reviewed them to see whether any protocol work is
> required?
[WEG] good point. However, I think the precursor would be to determine as a WG how we decide whether protocol work is required beyond that which is needed to trigger an IPv4 shutdown. Speaking as an individual, if I had to define it, I'd say this is a question about feature parity between IPv4 and IPv6 - Identify IETF work (if any) where the standard is still relevant and necessary in IPv6-only networks but is not suitably defined for IPv6-only operation and does not have an IPv6 equivalent. If there isn't any work that fits into this category, it's useful to confirm that this analysis has been performed as a part of our gap analysis. This would in essence confirm that there aren't outstanding IPv4/IPv6 feature parity issues at the protocol or IETF level that would delay a move to IPv6-only.
Related to this, I think it might be helpful to document IPv4-only features and standards that have no IPv6 equivalent but are a non-issue due to the fact that they are no longer in use or are obsoleted by different functionality inherent to IPv6. That is, features that are not at parity in IPv6, but no one cares. It would make for a more complete parity analysis.

Looking at this from a WG chair's perspective, this is a different gap analysis than the one focused on the mechanics of signaling to hosts, networks and stacks that you're turning IPv4 off, and might be better off in a separate document focused on answering the question of "can you actually turn IPv4 off?"
> isn't needed any more" or needs to say explicitly, "The decision about
> when to turn off IPv4 is out of scope."
>
[WEG] as an individual, my vote would be for the latter. Part of that same discussion about how and when it's appropriate to shut off IPv4 came up in my review of draft-lopez-v6ops-dc-v6, and it was quickly evident that one must take great care to avoid being in a situation where your draft has to discuss a very large number of different permutations to provide useful advice at a specific enough level, but there may be a possibility to pick some high-level categories such that you can provide more generically useful advice in a few situations. I could see that being a follow-on draft, or perhaps part of the protocol gap analysis you seem to be suggesting above.

Thanks for the prompt response on your volunteered review!

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: "Lee Howard" <[email-masked]>
Date: Mon, 12 Nov 2012 14:59:59 -0500

> -----Original Message-----

> From: George, Wes [mailto:[email-masked]]

> Sent: Monday, November 12, 2012 2:14 PM

> To: Lee Howard; [email-masked]

> Subject: RE: [sunset4] review of sunset4-gap-analysis

> > From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On

> [WEG] good point. However, I think the precursor would be to determine as
a WG how we

> decide whether protocol work is required beyond that which is needed to
trigger an IPv4

> shutdown. Speaking as an individual, if I had to define it, I'd say this
is a question about

> feature parity between IPv4 and IPv6 - Identify IETF work (if any) where
the standard is

> still relevant and necessary in IPv6-only networks but is not suitably
defined for IPv6-only

> operation and does not have an IPv6 equivalent. If there isn't any work
that fits into this

> category, it's useful to confirm that this analysis has been performed as
a part of our gap

> analysis. This would in essence confirm that there aren't outstanding
IPv4/IPv6 feature parity

> issues at the protocol or IETF level that would delay a move to IPv6-only.

> Related to this, I think it might be helpful to document IPv4-only
features and standards that

> have no IPv6 equivalent but are a non-issue due to the fact that they are
no longer in use or

> are obsoleted by different functionality inherent to IPv6. That is,
features that are not at

> parity in IPv6, but no one cares. It would make for a more complete parity
analysis.

The RFCs listed as Section 2 of -gapanalysis do most of this:

   [RFC3789 <http://trac.tools.ietf.org/html/rfc3789> ], [RFC3790
<http://trac.tools.ietf.org/html/rfc3790> ],[RFC3791
<http://trac.tools.ietf.org/html/rfc3791> ], [RFC3792
<http://trac.tools.ietf.org/html/rfc3792> ], [RFC3793
<http://trac.tools.ietf.org/html/rfc3793> ], [RFC3794
<http://trac.tools.ietf.org/html/rfc3794> ],
   [RFC3795 <http://trac.tools.ietf.org/html/rfc3795> ] and [RFC3796
<http://trac.tools.ietf.org/html/rfc3796> ]

RFC3789   Introduction to the Survey of IPv4 Addresses in Currently Deployed
IETF Standards Track and Experimental Documents

RFC3790  Survey of IPv4 Addresses in Currently Deployed IETF Internet Area
Standards Track and Experimental Documents

RFC3791                                                                    .
IETF Routing Area Standards Track and Experimental Documents

RFC3792                                                                    .
IETF Security Area Standards Track and Experimental Documents

RFC3793                                                                    .
IETF Sub-IP Area Standards Track and Experimental Documents

RFC3794                                                                    .
IETF Transport Area Standards Track and Experimental Documents

RFC3795                                                                    .
IETF Application Area Standards Track and Experimental Documents

RFC3796                                                                    .
IETF Operations & Management Area Standards Track and Experimental Documents

The summary section of each of these documents says, "Nobody cares about
these specs anymore" or "There is an active draft [name] to fix this."

We should follow up to make sure all of the then-active drafts were
published.

We may also need to undertake a similar review of documents published since
these RFCs.

> Looking at this from a WG chair's perspective, this is a different gap
analysis than the one

> focused on the mechanics of signaling to hosts, networks and stacks that
you're turning IPv4

> off, and might be better off in a separate document focused on answering
the question of

> "can you actually turn IPv4 off?"

Gaps is gaps.

I would not like to call gap analysis complete until we know about required
protocol updates.

> > This document either needs to include a section on "How to know you

> > IPv4 isn't needed any more" or needs to say explicitly, "The decision

> > about when to turn off IPv4 is out of scope."

> [WEG] as an individual, my vote would be for the latter. Part of that same
discussion about

> how and when it's appropriate to shut off IPv4 came up in my review of
draft-lopez-v6ops-

> dc-v6, and it was quickly evident that one must take great care to avoid
being in a situation

> where your draft has to discuss a very large number of different
permutations to provide

> useful advice at a specific enough level, but there may be a possibility
to pick some high-

> level categories such that you can provide more generically useful advice
in a few situations.

> I could see that being a follow-on draft, or perhaps part of the protocol
gap analysis you

> seem to be suggesting above.

Reasonable.

> Thanks for the prompt response on your volunteered review!

I get to check it off my list now.  J

Lee