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

[Ted Mittelstaedt]

On 2/21/2011 6:11 PM, Tony Hain wrote:
> Ted,
>
> I don't assume IPv4 will go out quietly.

good.

IMHO if Cisco had honored it's original commitment on IPv6 and put it 
into IOS 12.1 then a lot of this problem would have been moot.

But that's just me.

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

If the neighbor's dog poops in your yard, you can't ignore it if you 
want it to go away.

There are only 2 sides to the issue now.  Side 1 is the RIR becomes
activist and does whatever possible to eliminate IPv4 as quick as 
possible.  The theory being that this is the best stewardship to get rid 
of a mess by cutting it out.

Side 2 is the RIR stays neutral in this and concentrates on doing the 
best job stewarding what it's charged to steward, which is both IPv4 and 
IPv6.  The theory being that stewards are supposed to be neutrals.

If we want to get rid of IPv4 quickly then tweaking and making IPv4 as 
unclear as possible is exactly what we need to be doing.  Unclarity 
means a lot of uncertainty on costs and so it forces orgs to budget even 
high than they would normally do so to continue to support it.  That is 
a stronger incentive to get rid of it.  So in that case it really makes 
no difference what we do with proposal 133 and the like, we can vote 
them all down.  It is the fact that they continually get introduced - 
and "son of prop 133" gets introduced again, is what keeps the pot boiling.

By contrast if we want to reduce the mess to hold costs in line then it 
is imperative that we adjust the stewardship of IPv4 so as to reduce 
costs for everyone as much as possible.  That means continuing to do new 
IPv4 policy proposals and making reasonable decisions on them.

So that really is the two approaches that are opposite sides of the 
debate.  But the debate isn't going away just because we don't like it 
and want to ignore it.

Ted

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