IETF Logo Mail Archive

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

james woodyatt <jhw@google.com> Wed, 07 June 2017 23:42 UTC

Return-Path: <jhw@google.com>
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 62B7D131493 for <ipv6@ietfa.amsl.com>; Wed, 7 Jun 2017 16:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 BhuQ-A2OMOgI for <ipv6@ietfa.amsl.com>; Wed, 7 Jun 2017 16:42:14 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77570128CD5 for <ipv6@ietf.org>; Wed, 7 Jun 2017 16:42:14 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id x63so10677385pff.3 for <ipv6@ietf.org>; Wed, 07 Jun 2017 16:42:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0HjnMBtpw21Q1ROvBOBDKrsscXvY1o23XNaBIaIUlzs=; b=EneNqDHL5iKoKDxcIvkh7S335RHJoSm7A64iuVgYBN9vXkHGTN/wr39BsMpzuLSknv +1RrHhA7AV7r+75/hUDvg4MlPhv0Q1oOt/qj/LIFjG0ap6SMQhCO3o++Y7r76mSj7qTa JeX4RJNPbjaAYOnZz8ysmcur0gxwr/UQzhPPLzlLpV/2nml8tT5vZ2H8EwXvwzMfL82Q IEona8SL8JU+efmZWk6CzM5/8fdJOsz0KuVhLplv0tKW4+oq7xtKZ1rO9rsUCyAST59b aiEKVjMvORkf1+z1Om8an7YhwhUxKrF37X3UAdKxn7rHJr6chETwaAL0P3ASKwdKG091 Q80A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0HjnMBtpw21Q1ROvBOBDKrsscXvY1o23XNaBIaIUlzs=; b=ntxcPtQtzKg8HoZjNFne7gQmacVSA5tbivMBwkalOGttlJUgq86q8yUfK8EmwT+wvF l0xcmIpmHeS8HHA4yIcuoaRvkpkFGmEWY7zz0KhhHOoJqimldDPAWwb3bn7E4ZHKQtPy i5Vw8Oq+XAYstJW5JUzx1DBWtDXXbVZQ5IHsmCamYvDUL2vNcdPxIqzl7kSP9foi9J1i bljWuhMOXb3pKGpNJtn+BbYKUb+7pStrw4ka0SFaqR2I+Jibx5Fhcqwv5+JwI5wem0vJ cEo++zJMtuC4d1NwJ8WVZbsUlacBzqXxVPJEXBnBocOpoX6j3D/P4UjmtRDrc7XyLmPL sPXw==
X-Gm-Message-State: AODbwcCVVxy1IE0y4KxMXTRsyZ8VdY376QTs8s6xqv7zTS1JvS0+nJ4C 6yx3rZPC3/Gz1mjv
X-Received: by 10.101.86.11 with SMTP id l11mr1874842pgs.202.1496878933945; Wed, 07 Jun 2017 16:42:13 -0700 (PDT)
Received: from ?IPv6:2620::10e7:10:c04e:499a:a99:a8ba? ([2620:0:10e7:10:c04e:499a:a99:a8ba]) by smtp.gmail.com with ESMTPSA id i68sm6283307pfi.72.2017.06.07.16.42.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 16:42:13 -0700 (PDT)
From: james woodyatt <jhw@google.com>
Message-Id: <A3E25B71-9EC6-4E1B-91BC-FE36388676CB@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_904BE603-3DA1-46D9-A81F-3E11AD6C09D7"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
Date: Wed, 07 Jun 2017 16:42:12 -0700
In-Reply-To: <CAD6AjGSvaAGydOjZ-LYA8=DR2pOjmUrYAGN0kVdC2aKb3jvx_A@mail.gmail.com>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, 6man <ipv6@ietf.org>
To: Ca By <cb.list6@gmail.com>
References: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com> <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <alpine.DEB.2.02.1706050827290.17963@uplift.swm.pp.se> <E2B77C58-B235-49D6-8130-0B41BE55899C@google.com> <CAAedzxrkbywKMmUaZ6-OCunXe1sw=q3+TNz278xZDmdsQm3xaw@mail.gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <CAKD1Yr3+pHFhCwoL4vbQLDQ3PNGpijci8c7eZM=Gb0oTy9C0XA@mail.gmail.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <EF9AC09C-5262-4DFB-AA4D-AE95EF81293C@gmail.com> <CB328974-E401-4B62-A408-1814183E0010@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <CAD6AjGSvaAGydOjZ-LYA8=DR2pOjmUrYAGN0kVdC2aKb3jvx_A@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xq1Av8MA-m50PsdDCQNpuZMCDSM>
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: Wed, 07 Jun 2017 23:42:16 -0000

On Jun 7, 2017, at 15:41, Ca By <cb.list6@gmail.com> wrote:
> 
> I am unfamiliar with thread () in the real world and don't yet feel compelled to believe a widely deployed ietf standards track specifications should bend due some niche design choices that may or may not achieve a significant deployment. 

As far as I know, nobody associated with Thread™ apart from me is even listening to IETF much less offering anything to say. And the only thing I’m saying is that IETF should stop pretending that IPv6/NAT in end site addressing plans is preventable. It’s inevitable.

I’m not asking IETF to bend its standards accordingly. I’m actually expecting that IETF will not bend, and that it will continue promoting standards that leave end sites compelled to use IPv6-to-IPv6 Network Address Translation to conserve address space (despite the contrary statement in RFC 6177). The only thing I would prefer to see here is for 6MAN discussions to recognize the operational reality about IPv6/NAT and stop using discussion points about how this or that draft should be opposed because its adoption might lead to the widespread deployment of IPv6/NAT, which I now believe to be impossible to stop. Indeed, I don’t think there is any desire among service providers and equipment vendors to prevent it.

Therefore, in the context of discussions around this particular draft, I-D.bourbaki-6man-classless-ipv6, I would say that arguments about how subnet prefixes longer than /64 could leave end sites feeling compelled to use IPv6/NAT for address conservation are not technically strong arguments. They are already feeling compelled, even at the existing /64 boundary.

There may be other good arguments for retaining the fixed /64 subnet prefix length in the IPv6 address architecture, but I would say that preventing the rise of ubiquitous IPv6/NAT should not be one of them. That ship sailed when RFC 6177 was passed, and it went over the horizon when HOMENET didn’t receive any significant uptake among service providers.


--james woodyatt <jhw@google.com <mailto:jhw@google.com>>

v2.23.0 | Report a Bug | By Email