Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

Simon Hobson <linux@thehobsons.co.uk> Sat, 03 June 2017 10:45 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD01287A5; Sat, 3 Jun 2017 03:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L_3x-TrAmpO; Sat, 3 Jun 2017 03:45:22 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4B01287A0; Sat, 3 Jun 2017 03:45:21 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 63C711BC37; Sat, 3 Jun 2017 10:45:14 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com>
Date: Sat, 03 Jun 2017 11:45:13 +0100
Cc: draft-bourbaki-6man-classless-ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <74616764-EF03-4AD3-BC59-B579B9FD2001@thehobsons.co.uk>
References: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com>
To: IETF IPv6 Mailing List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Tyn7IvyE_p3OwAnhkoPARDAkIys>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jun 2017 10:45:24 -0000

Mark Smith <markzzzsmith@gmail.com> wrote:

> I think that's the fundamental agenda here, although perhaps not
> realised. It is to devolve IPv6's capabilities and features to the
> point where IPv6 isn't really much more than IPv4 with a different
> packet format, and so the IPv4 operational practices people are
> comfortable with can be directly applied to IPv6 without change. This
> is because of the common human trait of intolerance of or resistance
> to change.

I think that's over stating it a bit.
Part of "the problem" with IPv6 is (as David Conrad says) that it's "too different" and that means a lot of unlearning and relearning - and that implies cost. In an environment where the majority still see no problem because "it's OK, NAT works" then cost is a difficult thing to get people to buy into.

I see the point in fixing stuff that people don't realise is broken - but the risk is that people see that "it's too complicated" and "they're changing stuff for the sake of change" - and resist adopting it". I've heard both these criticisms.

> If this proposal is accepted, then I think /120s will become the
> defacto subnet size, despite what the draft says about /64s being the
> recommended default. Here's the clue for why - RFC1918 addressed
> networks I've seen, where IPv4 address space doesn't need to be
> conserved (i.e., unlike public IPv4 address space), always use /24s as
> the defacto subnet size. "Same-same" is easier for us humans than
> "Same-different."

I've worked with different sized subnets.
But I do see your point, I've come across lots of situations where "nothing exists other than a /24" seems to have been the mindset. In one case, I recall a Netgear router refusing to allow a valid IP4 address in one GUI page because of an assumption of "/24 everywhere" that made it a network address. And another model of router that did not support any subnet size greater than /24. and ...
And at my previous employer, I recall being involved in a project to link all the businesses together with one global WAN (we were one of a couple of dozen companies in the group). It was soon clear to me that I was working with "professional IT people" who could not grasp the concept that 172.16.1.1/23 was not in the range of ".1 to .10 reserved for routers" in their addressing plan - and nor could they see that ".1-.10, .11-.30, and so on" wasn't an easy addressing plan to work with in terms of filtering traffic for diagnostic purposes !
That was dealing with people who did IT at a sufficiently high level that they should not have had any excuse. In the general case, once you get outside of large corporates, the level of skill is much much lower - to the extent that I have to wonder just how on earth some of these people can call themselves IT professionals. Down to the level of knowledge where it comes down to "if the plug physically fits in the socket then it should just work, right ?"

ISPs colour code the sockets and cables with their routers for a reason. They NEED to be able to say "use the YELLOW cable, and plug it into the YELLOW socket ..." or customers simply won't be able to connect stuff properly. I've had people plug a phone (RJ11) plug into a network port (RJ45) and express surprise that it doesn't do anything !

> Why do I have a different perspective? My first networking protocol
> was a more modern one than IPv4, Novell's IPX, derived from Xerox's
> XNS. Learning and operating IPv4 networks after operating IPX networks
> was a backwards step. The only major advantage that IPv4 provided over
> protocols designed in the 1980s and 1990s, such as IPX, Appletalk and
> CLNS, was that it provided organisations with Internet connectivity.
> On many other criteria, IPv4 was far inferior - entirely
> understandable, because it was fundamentally designed in the 1970s,
> and then adapted over time to cope with being used to build a global
> Internet work.

I cut my first networking teeth with AppleTalk. I can still just about remember how easy it was - and how darned complicated that IP stuff was back then.

> I have a few horrible stories of seeing IPv4 routers with 4 x /24s or
> 25 x /26s on the same interface because renumbering and changing
> subnet masks of hosts into a single large enough subnet was more far
> expensive than sub-optimal forwarding across the same link.

You've explained that in one - the cost of renumbering. At work I want to renumber our office LAN, since being 192.168.1.0/24 it clashes with so many customer LANs which causes issues when using VPNs (and ditto for a couple of the clients as well who have the same issue). It's not happened because of the cost involved - all those IP addresses (often uneditable) embedded in systems - not least, the IP Port printers configured on Windows desktops.

> does an Ethernet really need 48 bit MAC addresses? Who's going to go close to attaching 2^46 nodes to one of
> them?

I suspect you already know the answer to that already. No, no-one is going to connect more than a few thousand nodes to one network, but if you don't have globally unique MAC addresses, how can you guarantee local uniqueness while still providing a stable interface identifier ?

I assume you have never had to diagnose a problem with duplicate MAC addresses ? I haven't personally, but I've heard first hand from a friend who has ! He was managing a university site, and they bought a batch of new desktops for a refresh. Turns out that Dell had a provisioning system bug while meant that there were MAC address duplicates - every 256 block of addresses got allocated to 257 machines (ie one address got duplicated).
Normally, this is unlikely to be a problem - not many customers buy more than 256 machines in one batch, and few of those will put them on one segment. But this university did, and they found the bug - eventually !


David Conrad <drc@virtualized.org> wrote:

> In most large scale environments, change of "operational practices" implies cost. In this context, I believe there is a perception that the additional cost is for minimal benefit -- customers don't care (and are unwilling to pay a differential) if their cat pictures come over IPv4 or IPv6. As such, the resistance here is more about not wanting to spend more money than it is some sort of psychological roadblock associated with a common human trait. 


Indeed.