IETF Logo Mail Archive

Re: draft-bourbaki-6man-classless-ipv6-00

Lorenzo Colitti <lorenzo@google.com> Thu, 15 June 2017 01:00 UTC

Return-Path: <lorenzo@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 CA728126DC2 for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 18:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 k5nyGmZD3GL1 for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 18:00:34 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 13F3D126CC7 for <ipv6@ietf.org>; Wed, 14 Jun 2017 18:00:33 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id 68so56766uas.0 for <ipv6@ietf.org>; Wed, 14 Jun 2017 18:00:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KCJtiO4qUGtjoFUnT76MNcVpkMGMOZAoTBHFPhJ2Lts=; b=BpAbYr0IvmAu4PEZMkf53woUN0fMI9+RYlARnOBo2Hcu5o66Ks3tGlyedjA2+//orB HroCHy6wzVymH5ASrD7sZXGUECln5o0knoKq0foO23+0x6Ck8FskufDWjS+3CmlIyywf n9KKeH2VIiAKsbSQpGc/9sJbzI2vyugCqHtWEaxKpRHrucmvHdPbZp/oNPsG9U9DvcGk IyjzccH4OhKF8jj4hn1NTP9z1N1jgygCdsdzlpIr3Q4XxF/ZLSqtGXIm5tacXOSVKWm2 YgMtV3eNDnANE0BsoxgT68eJPGFbkwNbhSBqcOR8VONRF14bWXrQcjj0SbDTOt8REGBn UQGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KCJtiO4qUGtjoFUnT76MNcVpkMGMOZAoTBHFPhJ2Lts=; b=SPpEv2v8+B+QHEktYaRnhJAih74Ro6W0HSeEVgiN87o3wp0ZyPdhycNX3Vb1XnSNyQ nrEoCMZubrM685U16Xv+Fj+F7P10fhNzttbVmrPn5mJWUXPllXhHdKuBM0wAr1NmgY/6 vouU+U7GPOhp2uoDWQJW/gdbMHYzmgnEGiCV9Xqwsil7N3FHqsEfrLGwu30SVl4zNAk6 uC1Ulm+trvSV9PFj8n6sZBEgCGcvNKtZmdBbal/KpHd7kDmJpXwvhwKMjbnpKYk6aARf veR0Vgxs9x+q8gCG3hsvh+idLM6+sv1wyKnUvln0RhFXo+xB3hnyQ/h0/VEhlJbZZpJl Efzw==
X-Gm-Message-State: AKS2vOwCZ2gA+DTSBVBAWAmCeiBw/xqRVXH517L1MJZGUjxkSCwF4sSm xpey4gltkFucxx1MkQVrowchi5MzCQaj
X-Received: by 10.176.83.16 with SMTP id x16mr1948383uax.11.1497488432783; Wed, 14 Jun 2017 18:00:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.12.139 with HTTP; Wed, 14 Jun 2017 18:00:12 -0700 (PDT)
In-Reply-To: <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com>
References: <E02C4C99-155A-4358-A845-F00F8BB071C1@employees.org> <b3ca5271-21b1-ab33-2dff-82735ebe9128@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <E61AFFF1-0354-41EE-8E11-50433B26BAF7@employees.org> <20170614094034.GC30896@gir.theapt.org> <A7502902-245B-499B-916B-28630CD5A824@employees.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 15 Jun 2017 10:00:12 +0900
Message-ID: <CAKD1Yr0dU+1rHo7LB2k7MOhJ+UOB5t7v11T2WYa+VtLnNC-7ag@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: "otroan@employees.org" <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c18f1ac182b330551f5325f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O5xhIa3Qv97y-qUdHIevS4McKiY>
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: Thu, 15 Jun 2017 01:00:36 -0000

On Thu, Jun 15, 2017 at 2:36 AM, Manfredi, Albert E <
albert.e.manfredi@boeing.com> wrote:

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of
> otroan@employees.org
>
> > What _problem_ does changing the 64 bit boundary solve for _you_?
>
> A category of problems, such as creating hotspots with smartphones that
> have been allocated a single /64.


That works today on all major smartphone OSes. And the situation is
actually the opposite: the only reason it works today is that phones
*already had* a /64 instead of a /128.

If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise
> to cripple non-/64 solutions by artificially mandating that SLAAC be only
> possible with /64s. The smartphone hotspot example is one in which a
> non-/64 SLAAC would work great. And there's simply no reason to state that
> SLAAC can only work with /64s. It's not true!
>

SLAAC doesn't work unless the network provides enough address space to make
collisions vanishingly unlikely.

v2.23.0 | Report a Bug | By Email