[arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

Owen DeLong owen at delong.com
Mon Nov 11 22:17:05 EST 2019



> On Nov 11, 2019, at 16:02 , Mark Andrews <marka at isc.org> wrote:
> 
> 
> 
>> On 12 Nov 2019, at 10:12, Scott Leibrand <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>> 
>> I think you underestimate the complexity of enterprise networking, and the relative lack of skill of the folks managing most enterprise networks, largely due to the fact that they can't enforce at-scale standardization as consumer networks do (so they can't just hire a small number of software architects to manage an entire network via automation).
> 
> I know one can turn on IPv6 along side IPv4 and gradually move stuff across to supporting
> both IPv4 and IPv6.  I know that HTTP, SMTP and DNS servers have supported IPv6 for over
> 2 decades.  DHCP servers have supported IPv6 nearly as long.  I know firewalls have supported
> IPv6 for over 2 decades now.  I know Windows has supported IPv6 since Windows XP. I know Apple,
> Oracle (Sun), VMS, Linux, … have supported IPv6 as long if not longer.  I know turning on IPv6
> doesn’t mean turning off IPv4.  Most CDN’s support IPv6 these days as well and you don’t have
> to be running IPv6 in house to project a IPv6 presence on the net.  Routers have supported IPv6
> for decades as well though not at the $50 mark until recently.
> 
> Turning on IPv6 isn’t hard even if most it the plant isn’t using it.  The front office can
> definitely use it just like homes use it today.  Getting to the state where you are ready
> to go IPv6-only is hard as it requires every piece of equipment to support IPv6, but don’t
> confuse the two.

In fairness, turning on IPv6 at all in an enterprise environment can be hard if:

	+	Your vendor supplied user management/equipment management solutions 
		(laptop provisioning, forced updates, security policy agents, etc.) don’t support it.
	+	Your various logging, reporting, auditing, IDS, etc. tools are lagging in IPv6 support.
	+	You have internal databases with 32-bit integer fields for logging IP address information
	+	You have applications that can’t handle it when presented with an IPv6 address as a
		line item in a host inventory response or such.

It can also be scary if your staff is even more clueless about IPv6 than they already are about the
IPv4 network that they keep running on bandaids and bailing wire because they don’t really
understand it, but the vendor set it up in 2009 and it’s still somehow running.

I’m not saying this is a good thing. I’m not saying I support enterprises continuing to accumulate
technical debt in this area to the detriment of virtually everyone else on the internet, but I’m
saying that there are actual impediments beyond the “you can turn it on in some places and
not turn off IPv4 and everything is just fine.”

>> When it comes down to making a decision about whether to implement IPv6, the decision is usually "build vs. buy" - "build" a new network, new server infrastructure, etc., vs. "buy" more IPv4 addresses. On residential networks, they can "build" at a sufficient scale to be cheaper than "buying". On enterprise networks, the "buy" option is usually cheaper (and far less risky to the revenue-generating portions of the business).
> 
> In many cases it is just enable.

In more cases, it’s not.

We should be looking for ways to improve that situation.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20191111/598d9e92/attachment.htm>


More information about the ARIN-PPML mailing list