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

["Lee Howard" <[e-mail]>]

> > 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?
> 
> As Wes said.

What did Wes say?

> I just don't want to go there. It was a tremendous amount of work when
that review was
> being done. But it had a different goal: identifying IPv4-only stuff in
protocols. Our goal is
> different because we're focusing on the operational side: what prevents
people from actually
> turning off IPv4. Sometimes it can be related to IPv4-only protocol
elements, but often not.
> A protocol having an IPv4-only element doesn't mean IPv4 can't be turned
off.

The "sunset problem" can either be approached by analyzing every operational
network for
problems it might encounter when turning off IPv4, or by analyzing every
network protocol
for potential gaps in turning off IPv4. If we try the former, we will miss
things.  The latter,
although time-consuming, is the work that is required.  The list has already
been made; all
we have to do is make sure that the work listed has been completed.

This could be farmed out to area directorates, or otherwise broken into
small enough pieces
that it can be completed.  

> > 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"?
> 
> Exactly. There's no way to tell. And because there's no way to tell, it
creates the problems
> listed here:
> <http://tools.ietf.org/html/draft-perreault-sunset4-noipv4-01#section-3>

I don't know whether a pointer to that section of that draft, or more
specific text describing
the two modes ("DHCP down" vs "IPv4 doesn't live here any more") would be
preferable.

 
> > PROBLEM 2.  Which DHCP messages do you mean?  Do you mean in Advertise
> > messages?
> 
> DHCPOFFER
> 
> > Does a server send an Offer if it has no addresses?
> 
> The problem is not that it has no address. For example, a home router
always has an
> RFC1918 address on its LAN interface. The problem is that it sends an
offer even when it has
> no IPv4 access on its WAN interface.

And again, it may be necessary to use rfc1918 space for internal
reachability, even when there
is no IPv4 WAN/Internet connectivity.  How do you know the difference? (next
question)

 
> > What about
> > when there's no IPv4 on the WAN, but IPv4 is still needed for internal
> > communication?
> 
> No need for DHCP. Just use link-local IPv4 addresses. [RFC3927]

How does that work in a routed network?
For instance, an enterprise network may have twenty LAN segments routed
through their
headquarters.  Some printers may still be IPv4-only.  How do you get there
with link-
local addresses?
 
> > 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."
> 
> As Wes said.
> 
> Text proposal:
> 
> >       <t>The decision about when to turn off IPv4 is out of scope. This
document
> >         merely attempts to enumerate the issues one might encounter if
that
> >         decision is made.</t>

That helps.  We may need the other document ("When is it time?") but I'm not
sure the IETF can write it.

Lee