> On Jan 15, 2021, at 9:31 AM, Mark Kiwiet <m...@kkworx.com> wrote:
>
> Inside/Private network space will probably always be IPv4. I don't
> understand why you would deal with IPv6 on the inside - you have the entire
> freaking class A of 10.0.0.0/8 <http://10.0.0.0/8> to design around - and
> make beautiful designs as well.
Many many reasons…
1. Your IPv4 inside addresses are not going to communicate as well with
IPv6 outside addresses
as native IPv6 addresses would.
2. The overhead and cost involved in maintaining bifurcated
infrastructures is excessive with
very little benefit once you no longer need IPv4 support for your
external connectivity.
(No, that day is not yet here, but it is coming and I do look forward
to it)
3. NAT breaks audit trails and makes troubleshooting and identifying
compromised systems
unnecessarily difficult.
4. IPv6 allows you much greater flexibility in numbering your network in a
structured and
logical way without having to preplan how many hosts a given subnet
needs to accommodate.
If I had a nickel for every time I’ve encountered an IPv4 10.x.x.x
interface on a router
that has 3 or more different subnets all sharing the same link because
they ran out of
space on the first 2 as the subnet expanded, I could probably afford a
beverage from
Seattle’s Most Overpriced Beverage Vendor. With IPv6, you assign a /64
and you’ll
never run out of room for additional hosts on the subnet no matter what.
(You’ll hit MAC layer forwarding table limits before you use up the
addresses)
5. If you were building greenfield today, why would you deal with IPv4 on
the inside? Why
not deploy pure IPv6 and use NAT64 or similar technology at the edge if
you still need
to preserve IPv4 connectivity for now. Advantage: In a few years, you
just turn off the
translator without major network upheaval. If you deploy a greenfield
network as if
it were a v4 network from bygone years, you’re still going to face all
the hurdles of
transition some day.
6. Finally, “dealing with IPv6” is a LOT easier than dealing with IPv4.
It’s just different.
> Unless you're running a NOC or a Web Server Farm - you really don't need more
> than 1 Public IP address for even 500+ private surfing endpoints. Outside
> of standard ports like TCP/25 - you can overload a single IP address with
> hundreds of high random ports.
But why would you want to? What possible advantage is there to this? This seems
almost like slave mentality. We’ve gotten so used to the scarcity of IPv4
addresses and the hacks used to work around it that we’ve not only accepted the
bondage of the IPv4 shackles, we’ve come to embrace them with some bizarre kind
of reverence as if deploying something friendlier is some form of sacrilege. It
boggles the mind, truly.
> Right now - the biggest public IPv4 issue is waste. There are tons of
> public IPv4's that are not used because they are part of an overallocated
> customer block.
No… The biggest IPv4 issue is the lack of unicast addresses. There are nearly 7
billion people on this planet. Each one has or likely will have at least 5
personal iPv4 end points. That’s a need for a minimum of 35 billion addresses
to build out a peer to peer network without even counting infrastructure,
service providers, servers, etc.
The biggest problem surrounding IPv4 is this idea that peer to peer is useless
and we should all accept the idea of provider/supplicant and second class
citizens.
Owen
>
> On Fri, Jan 15, 2021 at 10:51 AM <hostmas...@uneedus.com
> <mailto:hostmas...@uneedus.com>> wrote:
> What expensive technology are you talking about? Windows has had IPv6
> since Windows 2000. Ditto with Apple or Chromebooks or any other tech
> that is commonly used in schools.
>
> Use of RFC1918 Ipv4 addresses is quite common in every school I have ever
> dealt with. Even at the university level, it is very uncommon to assign
> workstations to public IPv4 addresses, and some form of NAT is used for
> IPv4 access via common public addresses with or without a proxy.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Fri, 15 Jan 2021, Jay Wendelin wrote:
>
> >
> > You would have to ask the ISP’s themselves. My Schools will not want to be
> > involved at all nor will we want to implement new and expensive
> > technologies for
> > ip6.
> >
> >
> >
> >
> >
> > cidimage001.png@01D698CE.05CAF3C0
> >
> > Jay Wendelin
> >
> > Chief Information Officer
> >
> > Cell: 309-657-5303
> >
> > j...@poweredbystl.com <mailto:j...@poweredbystl.com>
> >
> > cidimage002.png@01D698CE.05CAF3C0 cidimage003.png@01D698CE.05CAF3C0
> > cidimage004.png@01D698CE.05CAF3C0
> >
> >
> >
> >
> >
> > From: Fernando Frediani <fhfredi...@gmail.com <mailto:fhfredi...@gmail.com>>
> > Date: Friday, January 15, 2021 at 10:36 AM
> > To: Jay Wendelin <j...@poweredbystl.com <mailto:j...@poweredbystl.com>>
> > Cc: arin-ppml <arin-ppml@arin.net <mailto:arin-ppml@arin.net>>
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> > Organizations Removed from Waitlist by Implementation of ARIN-2019-16
> >
> > WARNING: This message originated from outside of the organization. Please
> > do not click links or open attachments unless you recognize the source of
> > this
> > email and can ensure the content is safe.
> >
> >
> >
> > Didn't these ISPs in 2021 not invest IPv6 deployment and good CGNAT
> > techniques and they rely only on keep getting more addresses from ARIN ?
> >
> >
> >
> > Fernando
> >
> > On Fri, 15 Jan 2021, 13:29 Jay Wendelin, <j...@poweredbystl.com
> > <mailto:j...@poweredbystl.com>> wrote:
> >
> > I support this petition, I have many Public School Clients that rely
> > on their ISP’s to manage and offer IP address.
> >
> >
> >
> > Jay Wendelin
> >
> > CIO
> >
> > STL/BTS
> >
> >
> >
> > cidimage001.png@01D698CE.05CAF3C0
> >
> > Jay Wendelin
> >
> > Chief Information Officer
> >
> > Cell: 309-657-5303
> >
> > j...@poweredbystl.com <mailto:j...@poweredbystl.com>
> >
> > cidimage002.png@01D698CE.05CAF3C0 cidimage003.png@01D698CE.05CAF3C0
> > cidimage004.png@01D698CE.05CAF3C0
> >
> >
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
> > <mailto:ARIN-PPML@arin.net>).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > <https://lists.arin.net/mailman/listinfo/arin-ppml>
> > Please contact i...@arin.net <mailto: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
> <mailto:ARIN-PPML@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact i...@arin.net <mailto: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.
_______________________________________________
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.
