[arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

[Ted Mittelstaedt]

On 9/12/2021 3:37 PM, Joe Maimon wrote:

>>>> I use more. Are you going to claim that my choice not to NAT is
>>>> somehow invalid?
>>> In an IPv4 world, yes. It's irresponsible.
>> That’s sort of like saying that people who bought single-family houses
>> in urban areas should be forced into high density housing because in
>> an urban area, it’s irresponsible to have a single-family house with a
>> yard.
>>
>> I don’t buy the argument in either case.
>
> I am with you on this. Yes. its theoretically "irresponsible" but that
> is no justification to be high handed.

Bull Pucky.  Apples to Oranges comparison.  I own a home in an urban 
area that has a yard.  The city is staffed with people like you who are
desperate to have people like me to subdivide our 50x100 lot into 2 
25x200 lots and build skinny houses.

4 miles to the East is farmland.  I tell people like you there is
PLENTY of buildable land for houses.  But NOT 40 blocks from city 
center.  I got here first, and I'm going to own my yard for the rest
of my life.  You can move 4 miles East and also have a yard or wait for 
someone with a yard to sell out and move.  Deal with it.

It IS NOT irresponsible of me to keep my yard in an urban area.

But, there IS NOT mountains of empty IPv4 a few miles away.  Unlike your
urban yard analogy IT _IS_ IRRESPONSIBLE and LAZY to not dual-stack your 
servers and your network.

As for NAT overload vs dual stack, anyone new to the game is going to
be forced into deploying a lot of NAT overloading to carry the lazy 
buggers who aren't dual-stacking.

Ted

>
>>>> You’ve admitted that there are valid reasons for at least 6
>>>> addresses per household.
>>> No. This setup is a hodge-podge that has no reason to be. In all of
>>> my branches all across the USA, I use only one IP and the eight or
>>> sixteen that come automatically are wasted. Intentionally.
>> Even if you consider one address per site, the math still works out
>> that IPv4 comes up short when you combine the number of households
>> with the number of businesses and then add in infrastructure, servers,
>> etc.
>
> The fraction of households that actually care enough about guip + larger
> fraction of businesses/services might actually still work out mathwise.
>
> Infrastructure does not count, that it consumes guip is a convenience in
> more cases than not.
>
> Servers can be consolidated, again convenience.
>
>>
>>>> ISDN was quite widely deployed and, in fact, is still in widespread
>>>> use, just not for data for the most part.
>>> Oh ? where ? I did have a few PRIs at $job[-1], but there were local
>>> to my closet; the back end was SIP.
>> There are a LOT of PBXs that interconnect with their ILEC or other
>> Telco via ISDN PRI. VOIP has not completely supplanted it just yet.
>
> I believe the original point was referencing the fact that ISDN was
> intended to replace POTS, nationally. Instead it found a solid niche
> role among providers and enterprises for a time, currently eroding. I do
> not think you prefer that narrative for IPv6.
>>
>>> For a variety of reasons, it was easier to communicate with legacy
>>> equipment with PRI trunks, but they came out of an Asterisk server;
>>> was a lot cheaper to buy a few Quad-PRI PCI express cards than
>>> upgrading a legacy system.
>> In many cases, that’s still true, but instead of bothering with the
>> Asterisk server, they are simply doing PRI with the Telco.
>>
>> Owen
>>
> Anyone doing that feel free to contact somebody willing to do that with
> you over sip, you will get redundancy and flexibility and its almost
> always a whole lot cheaper.
>
> Joe
>
> _______________________________________________
> 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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.