[ppml] Buying time...

[Tony Hain]

Ted Mittelstaedt wrote:
> >> ....snip
> >> OK so you would agree that taking action to lengthen the time before
> >> IPv4 runout is just buying time and stalling.  In other words, IPv4
> >> runout should be allowed to proceed naturally without interference,
> >> correct?
> >
> >My point was that stalling does not equate to preparation. If people
> would
> >actually use the additional time to smooth out the transition, then I
> would
> >have no problem with it. History shows that if we did extend the date
> >through a policy change, we would be having exactly the same
> >discussion with
> >the same lack of preparation as we approached that new date.
> >
> 
> That is rediculous.  History shows a lot of things but it has not ever
> been a reliable guide to use to prognosticate dates of future
> technological
> events or how they were dealt with by society.
> 
> In the pre-NAT days if you used that argument you would have reasonably
> concluded that runout would have already occurred by now.
> 
> Even if all past date extensions of IPv6 caused discussion with no
> action,
> which is very debatable, you cannot use that to predict what will happen
> if it's extended again.  And in any case, why did Microsoft put IPv6
> support
> into Vista, if it wasn't for actions resulting from IPv4 runout
> discussions?

That was about reducing the support costs related to nat for both the
operation of the applications and development of traversal technologies. I
was the Program Manager that put the stake in the ground about how XP would
lay the groundwork, and those that followed me took it further than I
expected in Vista to totally insulate the application developer from IPv4.

> 
> I think you are greatly underestimating the amount of time that is
> needed
> for
> things to happen.

In a life prior to MSFT I managed the transitions from a collection of
random protocols to IPv4, across a set of semi-autonomous organizations that
really didn't want to change from what they knew, so I am well aware of how
long things take. At the same time, as WG chair for ngtrans I guided the
direction toward dual-stack as the primary deployment model because that
ends up making things smoother and faster over the long run. This is
particularly true when the new protocol is tried first because that ends up
making the switch almost transparent as soon as both ends are ready. 

> 
> And in any case, your argument is circular - you claim you have no
> opposition
> under conditions that you claim are impossible - thus having no
> opposition
> is impossible.  In short, despite the flowery language, you aren't
> adding
> anything here.

There has been an ongoing discussion about the need to prepare for IPv6 for
several years now, and exactly how much progress has been made (outside of
Japan)? People that have a one-quarter-focus will not react just because the
time was extended, they will simply continue doing nothing until they are
forced to.

> 
> >>
> >> Then, if you are in favor of not interfering with the natural runout
> >> of IPv4, then why do you find all of the previous interference in the
> >> IPv4 runout date to be acceptable?
> >
> >You assume I was ...
> >
> 
> No, I am saying that if you found it acceptable and your finding that
> future interference is unacceptable, then your completely inconsistent.
> 
> If you find past interference to be unacceptable then what is the
> objection to undoing that interference?

You can't kill off nat at this point, yet that was clearly an interference
in the 'natural' exhaustion of IPv4.

> 
> >>
> >> The IPv4 runout date has been artifically advanced by past practices
> >> that artifically accellerated the consumption of IPv4.  At one time
> >> you could get a /8 by just e-mailing someone and they wrote it down
> in
> >> their black book.  And a lot of people did.  As a result, the
> >> consumption
> >> of IPv4 was accellerated far in advance of what it's normal usage
> would
> >> have been.
> >
> >Having been one of those people that received/approved/rejected those
> email
> >requests for the Dept. of Energy, it was not as arbitrary as you
> >make it out
> >to be. You might be surprised to know that there were issues with
> routing
> >table size in the ancient past... ;) So working within the block sizes
> that
> >the stacks of the day were designed to use, on a case by case basis the
> >trade-off was made between 'waste of space' and 'waste of routing
> slots'.
> >
> 
> So what?  That is like saying that because 60 years ago the decision in
> the United States to allow every last man, woman, and child to have the
> God-given right to own an automobile and drive it as much as possible
> was right at the time, that Global Warming today that resulted from it
> is
> not a mistake.

The right to own & drive was fine. Where the U.S. differed from other
governments around the world was to keep taxes on fuel low. If the U.S. tax
rates on fuel were significantly higher over that timeframe, the sprawl
would be much lower, which in turn would impact commute times, ......

> 
> There is such a thing as a technological decision that appears good at
> the time to turn out in retrospect to be horrible.
> 
> Your essentially arguing that extending IPv4 runout is a horrible
> decision.
> How do you know that NOT extending it won't also be a horrible decision?

I am not arguing that it would be a bad decision, because I don't know
either way. What I am arguing is that extending the date will not do
anything to make it easier, and if anything will allow the deployment of
that much more stuff that will add to the problem of translation later.

> 
> >>
> >> This so-called "stalling" is merely an attempt to reverse the past
> >> mistakes
> >> and return to a "natural" runout of IPv4, which should really be
> taking
> >> place
> >> far in the future of what it is projected to now.
> >
> >The 'natural' rate would be much faster than it is now, if it were not
> for
> >the artificial bias to force entities into private space. We are
> >seeing that
> >in the compound growth of consumption since 2000, despite the
> widespread
> >availability and use of nat.
> >See: http://www.tndh.net/~tony/ietf/IPv4-delegated-per-RIR.pdf
> >
> 
> Well, there you have it - NAT is a perfect example of sanctioned
> interference in IPv4 runout rates.  And despite the engineers wringing
> their hands over it, a side effect of NAT has been the poor man's
> firewall.

A real firewall would have been a much better outcome. 

> 
> Do you really think the Internet wouldn't be overrrun with viruses today
> if it wasn't for widespread deployment of NAT?  After all, Microsoft
> did put "classic" non-NAT-based firewalling in Windows.  It's called
> Windows Firewall and it's active by default.  But that classic
> firewalling
> approach proved to be worthless compared to the NAT in the little
> cable/DSL routers and such.  Sure, the crackers are figuring their way
> around that, but it's given us years of breathing room.  So, on the
> scales
> I would say that not all about NAT has been bad.

Focusing on symptoms does not solve the problems. Since nat provided an easy
path to block traffic that was not email or web client originated, there was
no effort put into that cable/DSL device to make it trivial to manage as a
real firewall. 

> 
> >>
> >> I find your position to be extremely inconsistent.  If you want IPv4
> >> runout
> >> to progress naturally, then logically ALL IPv4 assignments must fall
> >> under a single, uniform allocation scheme.  That scheme today is the
> >> RIRs.
> >> But all IPv4 assignments today are currently NOT under a single
> >> allocation
> >> scheme.
> >
> >You logic does not follow. Essentially you are arguing for
> >fairness over the
> >entire space rather than policy for managing the remaining pool.
> >
> 
> Yes, because fairness is all that the RIR's are based on.
> 
> Do you want the governments and courts involved with the RIRs?

No, but they will be if the world is 'taken by surprise' by the exhaustion
of IPv4, because that will be a sign that the RIR's are not competent for
the task.

> 
> If the RIR's are arbitrary and capricious
> that will invite lawsuits, ones that will be won.  And, when runout
> does happen, if an RIR gets sued for not allocating IPv4, they are
> going to have to show that they are not being discriminatory or they
> will be court-ordered to produce numbering.  Claiming "well we can't
> touch all this -old- numbering out there that somebody assigned
> out of a notebook years ago" ain't gonna cut it.  There will have to
> be evidence that the allocation process is applied
> uniformly over ALL IPv4 users, regardless of what was done in the
> past.

IANAL: but as I understand it, rulings are based on how the policies in
effect at the time were followed, and policy revisions are not retroactively
applied. 

> 
> Your kind of making the argument here that because Joe Blow bought
> 100 acres 50 years ago when there were no pollution controls, that
> he can go ahead and dump his sewer into the stream that runs across
> his property, like he did 50 years ago, because he has some sort
> of right to be able to do this since he was able to do it 50 years ago
> when he bought the land.  It does not work that way in the legal
> sphere.

No, I am arguing that since he built a barn on that property 50 years ago
that he is not required to tear it down just because the area now has
building codes that don't allow barns. 

> 
> If you toss out fairness, your gonna get yourself slapped down.
> Besides,
> it's the right and moral thing to do.

If you really want fairness, then ~50 /8's have to go to China, another ~50
have to go to India, ... In the end the ARIN region gets left with less than
20 /8's, so not only those old allocations have to go back to IANA, but 8 or
so of the 'by ARIN policy' ones do to. Also, I don't hear you arguing that
everyone that received an ARIN allocation in 1997 has to rejustify based on
current policy, so don't be too quick to throw out accusations about
inconsistency.

> ......
> 
> Your essentially screwing the handful of network managers who are taking
> action but just need more time, on the basis that they are outnumbered
> by
> the lazy slob network managers that won't do anything until a fire is
> lit
> under them.

I really don't understand this argument. I absolutely agree that it takes
time. Essentially people that are taking action are already working off that
time. 

Are you arguing that current policy does not allow you to have enough
addresses today to carry you through? 

Or:

Are you arguing that you will be stuck needing to provide IPv4 to customers
until they are ready to move?

I completely understand the last point, and have been telling ISP's that if
they don't want to be paying an arm-&-leg in the open market for IPv4 to add
customers, they had better be encouraging existing customers to move to IPv6
now.

> 
> >>
> >> If the rest of us "lethargic" people
> >> want to correct past allocation mistakes and thereby push forward the
> >> IPv4
> >> runout date in advance of what it is projected to be, then I don't
> see
> >> why
> >> anyone can make any reasonable objection to that.
> >
> >There were no allocation mistakes as such. Applying current technology
> and
> >policy to historical events is not a useful exercise.
> 
> Well, what exactly do you think that the invention of IPv6 -is-?  Seems
> to
> me nothing more than the application of current technology to a
> historical
> event - the invention of IPv4.
> 
> IPv4 isn't big enough, so we solved it by inventing IPv6.
> 
> IPv4 isn't being fairly allocated so we solve it by going back to the
> people
> with IPv4 they aren't using and taking it back.  If the IPv4 runout date
> gets advanced, well then happy side effect for some people, eh?

You claim to be concerned about lawsuits, but are completely oblivious to
the problem that there is no consistent definition of 'using'. An
organization that does not announce a /8 to public providers could well be
announcing it to others to keep from having overlapping 1918 between a large
private group, or because some set of the group has a public presence and
needs to keep the routing sorted out.

> 
> >Again, you
> >are arguing
> >for fairness, and the real issue before us is managing the remaining
> space.
> >
> 
> No, the REAL issue is managing ALL the IPv4 space.  The term "remaining"
> assumes all past allocations are good, which they are not.  You can look
> at the BGP table and compare it to the list of allocated IP and see
> that.

Which BGP table? There are many views around the world of what is call the
dfz, so even there it is not a single instance. Since you said 'the BGP
table', I assume you are defining private BGP peerings as 'unused space'. 

......

The bottom line is that for any policy change to have a real impact it will
have to be a globally consistent policy. The entire reason there are
multiple RIR's is that people don't want a globally consistent allocation
policy, otherwise it would make more sense to combine the resources into
IANA and do it all centrally. Even getting agreement on a globally
coordinated set of policies is difficult, and past experience shows that
takes a couple of years. At the current growing burn rate, by the time we
get 2 years down the road there will not be enough of the IPv4 space left
for that to matter, even counting what might be reclaimed. Reclamation is a
nice thing to debate about, but implementing the changes to free up blocks
takes just about as long as deploying IPv6, and it is only a stop-gap on top
of it. In the end IPv4 reclamation has an even lower ROI than IPv6, which
will have to be deployed anyway. Any network manager would use the legal
system to stall a reclamation effort while they deployed IPv6, just because
that would be the lowest cost path for them. That would raise costs for the
RIR's, & therefore their members, which is 'not fair' to those that have
followed policies and have enough space to last them until they are ready to
deploy IPv6. 

I don't know why you are so insistent on delay, unless the current policy
does not allow you to get enough space to last you through an already active
effort to transition. If this is really about making the policies friendly
to those that are trying to transition, then I am all for it. If it is
simply a stalling tactic, then it really has no long term value to anyone.

Tony