[arin-ppml] Proposal insanity --- an open letter

[Tony Hain]

Ted,

I don't assume IPv4 will go out quietly. It will be more like the 'big
bang'. For a quiet departure, isp's and app developers would have needed to
start 10 years ago. Consumers should never have noticed this, and carriers
can't force it no matter how hard they try. IT IS NOT A NETWORK DRIVEN
TRANSITION, it is a network stalled one. The applications have to be
updated, and every org has its own business timeframes when it is willing to
touch/revalidate them. Even consumers won't upgrade unless they see a
business value in the update app. Until the apps get there the best IPv6
network in the world will sit idle. That said, the network did stall the
effort by proceeding along as if nothing was going to change, therefore not
providing a visible utility for app developers to test against, and at the
same time sinking capex into boat-anchor access technologies that have to
amortize their way out of the system before capex will be queued again. 

People will always take the local economic min, therefore there will be lots
of man-in-the-middle attack boxes deployed. Some will try their best to
avoid overlapping 1918 while others will reuse public space. When the only
apps are web browsing and pop/imap, you are correct the consumer won't
notice, unfortunately there are many other apps. For those that are getting
used to location-aware apps though, that reuse will be more than a problem,
particularly for orgs that are paying for high rankings in location based
adverts. Add in the calls you will get because enterprise-X just blackholed
one of their employees vpn connection because they are being spammed or
ddos'd by the same IP address (doesn't become a problem until the public
address is shared...)

There are costs to every path chosen. Starting 10 years ago would have
created a set of costs then that have been deferred to now. Delaying has not
made those costs go away, and has added in the set of nonsense that will be
deployed to further extend IPv4 until the apps get fixed. Making it unclear
when that needs to be done by continually tweaking the IPv4 policy is not
going to get the app developers motivated, resulting in even more tweaks and
nonsense technologies 5 years from now. It is time to stop wasting energy on
IPv4 policy. It is what it is, and there is nothing that will substantially
change the outcome.

Tony


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Ted Mittelstaedt
> Sent: Monday, February 21, 2011 5:24 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Proposal insanity --- an open letter
> 
> On 2/21/2011 3:57 PM, Tony Hain wrote:
> > John Curran wrote:
> >> Tony -
> >>
> >>   Thanks for the thought-provoking input, as well as the
> >>   succinct summary of opposition to all the listed proposals...
> >>   The one surprising element is that several of the policy
> >>   proposals you list express similar concerns to those that
> >>   were alluded to in your soliloquy; are you certain that
> >>   none of the policy proposals would improve the situation
> >>   from your perspective?  (I ask only because it is
> >>   predominantly via the policy development process that
> >>   changes in ARIN's address management practices occurs)
> >
> > Yes we need an active policy development process, but IPv4 is baked
> and it
> > is time to stop stirring that dough ball.
> 
> John, Tony, Owen and All,
> 
>    We don't know this.  Yes, it would be best for all concerned if that
> was the case.
> 
>    But it IS important to keep in mind that there's a heck of a lot
> of IPv4 out there already and assigned.  And there is the potential
> for proposals like NAT64 (which has WORKING code from the Ecdysis
> project) that, IF adopted by a large number of ISPs, could seriously
> muck up the IPv6 changeover pot.
> 
>    I am only half-joking when I said Tony that your disrupting the
> secret plans to get IPv6 deployed.
> 
>    I know all the arguments that the big carriers are going to force
> IPv6
> and all of that.  Fantastic!  We are IPv6 capable RIGHT NOW our "big
> carrier" competitors (in our market) are NOT.  I'd love for them to
> start forcing IPv6.  The day they start telling new users that they
> can't use their Windows XP on their Internet connection is the day
> those
> users slam down the phone and call us for service.  We may tell them
> the
> same thing but at least they have called us.  And, we can tell them the
> same thing and have coverage because they can't then run to our
> competitor.  They HAVE to upgrade.  But, I'm not subscribing to the
> Pollyanna principle today.  If you think for one moment that I believe
> my big competitors are going to allow those customers to slip away,
> your
> a fool.
> 
>    The fact is that stacked NAT works with a lot of CPE's.  One big
> assumption a lot of people seem to be making is that a CPE like a DSL
> modem that does NAT will not work if the outside IP address on the
> WAN interface is a private IP address.  That is flat out wrong.  I've
> seem them work.  Granted the throughput often stinks but they work.
> And
> the same goes for MANY of the SOHO "modemless" NAT routers.
> 
>    An ISP that is in danger of running out of IPv4 can simply start
> delivering connectivity via private numbers.  Most of their Ma and Pa
> Kettle users won't even notice.  And for the few smart enough to come
> in
> out of the rain and notice, the ISP can move them to their pool of
> remaining IPv4 public numbers.  And there are other tricks too.  For
> example an ISP can duplicate public IP's and NAT them in the router.
> An ISP can put the same subnet in 3 different POP's and just translate.
> The end user won't get a private IP on their WAN interface they will
> get a public number - it's just a public number that isn't reachable
> from the Internet.  The ISP can just tell the user that their TOS
> prohibits the user from running servers and hide the public network
> behind a NAT.  As long as the user can load web pages, most of them
> won't care, they will think things are just peachy.
> 
>    Yeah, I know it's not scalable.  But since when in the computer
> industry has a BAD, unscalable piece of dung idea that was popular with
> the customers ever been abandoned?  No, the usual practice is to shovel
> tons of money at it until it kina-sorta-works.  If that wasn't SOP then
> we'd all be running Xenix.
> 
>    Just remember that it is human nature to choose a small, immediate,
> short term gain that carries a long term loss over a large, long term
> gain that carries a small, immediate, short term loss.
> 
>    Don't assume that IPv4 will go quietly into the sunset, is all I'm
> saying.
> 
> Ted
> 
>   There might be improvements in the
> > proposal set, but the amount of effort needed to refine them and
> highlight
> > the value is time distracted from real work. At the end of the day
> they make
> > no difference in the outcome other than to delay its inevitable
> conclusion.
> >
> > In case it wasn't clear, my comments were directed at the set of
> proposals
> > and the never ending discussion threads. They explicitly do not
> assume any
> > positions are being taken by ARIN staff or AC members. The point
> being that
> > if that set of proposals passed as a collective, the outcome would be
> as
> > described.
> >
> > Tony
> >
> >>
> >> Thanks,
> >> /John
> >>
> >> John Curran
> >> President and CEO
> >> ARIN
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.