IETF Logo Mail Archive

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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 05 June 2017 06:35 UTC

Return-Path: <swmike@swm.pp.se>
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 235AA127F0E for <ipv6@ietfa.amsl.com>; Sun, 4 Jun 2017 23:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 TWaVKlmtaQ2s for <ipv6@ietfa.amsl.com>; Sun, 4 Jun 2017 23:35:28 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88324127599 for <ipv6@ietf.org>; Sun, 4 Jun 2017 23:35:28 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 100E6A3; Mon, 5 Jun 2017 08:35:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1496644525; bh=g96+4t+rSWOVfjBtrD/y2U7sjnxtZfgqWs8qmRE79aw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iWqFHI8Y+nwl+hFa/JIAqwx1ih/K+2d8WXVR9iTSiG+2XISTPio5qNaIohiY7kzDb EFBXh1bXQaWM457MRYuAHqWD0dUI6Zgf5tEr49NEElUs/H/zoTIWUjVSBzULXZPdUI /PSn0UZLk9RRKl52YjcJfdlmvwN73+ZLhIPS5lOw=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0C7A9A1; Mon, 5 Jun 2017 08:35:25 +0200 (CEST)
Date: Mon, 05 Jun 2017 08:35:25 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: 6man <ipv6@ietf.org>
Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
In-Reply-To: <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com>
Message-ID: <alpine.DEB.2.02.1706050827290.17963@uplift.swm.pp.se>
References: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com> <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/M_KcykdOPHAQtEBJdw_0r-l4Stc>
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: Mon, 05 Jun 2017 06:35:31 -0000

On Sun, 4 Jun 2017, Brian E Carpenter wrote:

> If we'd been able to agree on simply removing n=64 from 4291bis, I 
> wouldn't have put my name on this draft.

My take on this (and I don't think I am alone) is that this is a slippery 
slope down to where when I in 10 years connect to a wifi, I'll get an RA 
with PIO /128 with A=1, because the ISP decided they only wanted devices 
have single address, because that's what the product people wanted 
because then people wouldn't be able to have more than a single device per 
subscription (which is false, but some people believe this can be 
achieved).

Down that /128 path leads NAT66 and all kinds of complexity to work around 
these problems, and we'll have gained very little by introducting IPv6.

I am totally fine in Job statically configures his devices with /126:es, 
but how do we make sure that device/applicaton developers don't have to 
spend a lot of time in the future handling NAT66 traversal and hiding 
multiple services behind a single address?

I don't believe in people saying that the IETF is powerless to stop this. 
We have technical means to at least make it a lot harder for people to get 
away with that.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email