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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
