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

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Dec 2012 12:41:08 +0100

Le 2012-11-12 17:47, Lee Howard a écrit :
> I promised to review the document.  I have not included proofreading notes
> (spelling, grammar, etc.) but I would be happy to do so.

Thanks! Sorry for taking so long to reply. Busy...

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

Ok.

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

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.

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

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

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

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

First, we're not saying all problems apply to all networks.

Second, I'm not sure separating the draft in a home section and an 
enterprise section would be useful: some problems would apply to both, 
and some problems would apply to none (home+enterprise != internet).

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

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 6 Dec 2012 11:10:48 -0500

> > 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?
creates the problems
> listed here:

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.

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

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

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

Lee