<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2021, at 9:31 AM, Mark Kiwiet <<a href="mailto:mark@kkworx.com" class="">mark@kkworx.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394">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 <a href="http://10.0.0.0/8" class="">10.0.0.0/8</a> to design around - and make beautiful designs as well.</div></div></div></blockquote><div><br class=""></div>Many many reasons…</div><div><br class=""></div><div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>Your IPv4 inside addresses are not going to communicate as well with IPv6 outside addresses</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>as native IPv6 addresses would.</div><div><br class=""></div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>The overhead and cost involved in maintaining bifurcated infrastructures is excessive with</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>very little benefit once you no longer need IPv4 support for your external connectivity.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(No, that day is not yet here, but it is coming and I do look forward to it)</div><div><br class=""></div><div>3.<span class="Apple-tab-span" style="white-space:pre"> </span>NAT breaks audit trails and makes troubleshooting and identifying compromised systems</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>unnecessarily difficult.</div><div><br class=""></div><div>4.<span class="Apple-tab-span" style="white-space:pre"> </span>IPv6 allows you much greater flexibility in numbering your network in a structured and</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>logical way without having to preplan how many hosts a given subnet needs to accommodate.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>If I had a nickel for every time I’ve encountered an IPv4 10.x.x.x interface on a router</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>that has 3 or more different subnets all sharing the same link because they ran out of</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>space on the first 2 as the subnet expanded, I could probably afford a beverage from</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Seattle’s Most Overpriced Beverage Vendor. With IPv6, you assign a /64 and you’ll</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>never run out of room for additional hosts on the subnet no matter what.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>(You’ll hit MAC layer forwarding table limits before you use up the addresses)</div><div><br class=""></div><div>5.<span class="Apple-tab-span" style="white-space:pre"> </span>If you were building greenfield today, why would you deal with IPv4 on the inside? Why</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>not deploy pure IPv6 and use NAT64 or similar technology at the edge if you still need</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>to preserve IPv4 connectivity for now. Advantage: In a few years, you just turn off the</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>translator without major network upheaval. If you deploy a greenfield network as if</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>it were a v4 network from bygone years, you’re still going to face all the hurdles of</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>transition some day.</div><div><br class=""></div><div>6.<span class="Apple-tab-span" style="white-space:pre"> </span>Finally, “dealing with IPv6” is a LOT easier than dealing with IPv4. It’s just different.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394">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.</div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394">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. </div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Owen</div><div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 15, 2021 at 10:51 AM <<a href="mailto:hostmaster@uneedus.com" class="">hostmaster@uneedus.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What expensive technology are you talking about? Windows has had IPv6 <br class="">
since Windows 2000. Ditto with Apple or Chromebooks or any other tech <br class="">
that is commonly used in schools.<br class="">
<br class="">
Use of RFC1918 Ipv4 addresses is quite common in every school I have ever <br class="">
dealt with. Even at the university level, it is very uncommon to assign <br class="">
workstations to public IPv4 addresses, and some form of NAT is used for <br class="">
IPv4 access via common public addresses with or without a proxy.<br class="">
<br class="">
Albert Erdmann<br class="">
Network Administrator<br class="">
Paradise On Line Inc.<br class="">
<br class="">
On Fri, 15 Jan 2021, Jay Wendelin wrote:<br class="">
<br class="">
> <br class="">
> 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<br class="">
> ip6.<br class="">
> <br class="">
> <br class="">
> <br class="">
> <br class="">
> <br class="">
> cidimage001.png@01D698CE.05CAF3C0<br class="">
> <br class="">
> Jay Wendelin<br class="">
> <br class="">
> Chief Information Officer<br class="">
> <br class="">
> Cell: 309-657-5303<br class="">
> <br class="">
> <a href="mailto:jmw@poweredbystl.com" target="_blank" class="">jmw@poweredbystl.com</a><br class="">
> <br class="">
> cidimage002.png@01D698CE.05CAF3C0 cidimage003.png@01D698CE.05CAF3C0 cidimage004.png@01D698CE.05CAF3C0<br class="">
> <br class="">
> <br class="">
> <br class="">
> <br class="">
> <br class="">
> From: Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank" class="">fhfrediani@gmail.com</a>><br class="">
> Date: Friday, January 15, 2021 at 10:36 AM<br class="">
> To: Jay Wendelin <<a href="mailto:jmw@poweredbystl.com" target="_blank" class="">jmw@poweredbystl.com</a>><br class="">
> Cc: arin-ppml <<a href="mailto:arin-ppml@arin.net" target="_blank" class="">arin-ppml@arin.net</a>><br class="">
> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br class="">
> <br class="">
> WARNING: This message originated from outside of the organization. Please do not click links or open attachments unless you recognize the source of this<br class="">
> email and can ensure the content is safe.<br class="">
> <br class="">
> <br class="">
> <br class="">
> 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 ?<br class="">
> <br class="">
> <br class="">
> <br class="">
> Fernando<br class="">
> <br class="">
> On Fri, 15 Jan 2021, 13:29 Jay Wendelin, <<a href="mailto:jmw@poweredbystl.com" target="_blank" class="">jmw@poweredbystl.com</a>> wrote:<br class="">
><br class="">
> I support this petition, I have many Public School Clients that rely on their ISP’s to manage and offer IP address. <br class="">
><br class="">
> <br class="">
><br class="">
> Jay Wendelin<br class="">
><br class="">
> CIO<br class="">
><br class="">
> STL/BTS<br class="">
><br class="">
> <br class="">
><br class="">
> cidimage001.png@01D698CE.05CAF3C0<br class="">
><br class="">
> Jay Wendelin<br class="">
><br class="">
> Chief Information Officer<br class="">
><br class="">
> Cell: 309-657-5303<br class="">
><br class="">
> <a href="mailto:jmw@poweredbystl.com" target="_blank" class="">jmw@poweredbystl.com</a><br class="">
><br class="">
> cidimage002.png@01D698CE.05CAF3C0 cidimage003.png@01D698CE.05CAF3C0 cidimage004.png@01D698CE.05CAF3C0<br class="">
> <br class="">
> <br class="">
> <br class="">
> _______________________________________________<br class="">
> ARIN-PPML<br class="">
> You are receiving this message because you are subscribed to<br class="">
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
> Unsubscribe or manage your mailing list subscription at:<br class="">
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
> Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<br class="">
> <br class="">
> <br class="">
>_______________________________________________<br class="">
ARIN-PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" target="_blank" class="">info@arin.net</a> if you experience any issues.<br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div style="text-align:left" class=""></div><div style="text-align:left" class=""><b style="font-family:verdana,sans-serif;font-size:x-small" class=""><i class=""></i></b></div><div style="text-align:left" class=""></div><div style="text-align:left" class=""><p class="MsoNormal"><span style="font-size:9pt;color:rgb(31,73,125)" class=""><img src="https://docs.google.com/uc?export=download&id=1rw0rA0GcTMgcl44DG58wdI5ADThV4qbh&revid=0B3CYAKYY2jq7RXgwVlV4QWZyaFFkbXdiUE9GeVMyQjdmRW9VPQ" width="420" height="136" class=""><br class=""></span></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></body></html>