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

Ca By <cb.list6@gmail.com> Thu, 15 June 2017 00:16 UTC

Return-Path: <cb.list6@gmail.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 E87BD126CC7 for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 17:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 W2MhV2SifZ0q for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 17:16:46 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 1D72D1205D3 for <ipv6@ietf.org>; Wed, 14 Jun 2017 17:16:46 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id v7so9528529ywc.2 for <ipv6@ietf.org>; Wed, 14 Jun 2017 17:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WrizfmiUo/hWgHnvIQxj+qK2tnivrcVMysCC/3stoEU=; b=ZTseQyu2xWnpUSqOOd0Fe9YgqO/ldhAX9bedQChRb/VJnr4tGUwy2F7BqVEqXAU54H L5EkfwQ096PKf5oaq3fkeWwnFsfeCeqpdinsQ6rCtsZo+M39HFiKX/9t+eNqpK16KTum xZTnJH5Dyl//7gTbTSWgGmw5QQPYpCuwEq6MRPVAP9X8P0T1qOdXMZ2uiX7sBcb6HbVM BOGzQXkpWyhut94VhmOJadS2k+ugWD9PaS+Mmp+ivPZkJWQy3RtbAX/tZyRrqHWl8mcV fJrZQncOaj4nDY6z+X5+GcUO8DjJK+VUo15G43zG5EQlgUFF+HbQ7vfdpXTpzJDCmGBY ihkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WrizfmiUo/hWgHnvIQxj+qK2tnivrcVMysCC/3stoEU=; b=Iy2vJu6dVvBcx7vqccmCT/TxZ15h3GnAh3LMx5KS2mgGE2T3QzH8SGWDJRUwEuoNlI Af8fRsbfPQNs2Rr09CkYzBf8foAysF7KyDkKCVht7/DGgTdrfcXZhABfjpefCS7mvDRd cQAJqWGNtEwdZjlXs8dO0LnxCEohXgX2p+DhwyZHfB1qr0IGrmYVs/tF5yMk9rXv+A/w oyKxa0YYjmnoTBllYfBV0VoOIzMLXNFvlAf63FLwsyysBN9bem3T+JIa2SbcicCGSjkD dLUoJFKrEoPqLlAMP/R1CoV/qbXWmUjbLikwXCvMHimRoTzSa1EjFHsJlxoTLKXzwrMl aDmA==
X-Gm-Message-State: AKS2vOz90eD6MCp+XSwLIoSH/9rI1TWdgkaJpCm1ALbQoKTDRNtGX8/H JRwgtyOkx4yB0hzcgaSguX+LM82GNg==
X-Received: by 10.129.182.87 with SMTP id h23mr2238933ywk.318.1497485805438; Wed, 14 Jun 2017 17:16:45 -0700 (PDT)
MIME-Version: 1.0
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> <EB6160E5-0FB3-427E-BBE0-486A58FD0D82@google.com> <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com> <20170615000942.D0E667BB303B@rock.dv.isc.org>
In-Reply-To: <20170615000942.D0E667BB303B@rock.dv.isc.org>
From: Ca By <cb.list6@gmail.com>
Date: Thu, 15 Jun 2017 00:16:34 +0000
Message-ID: <CAD6AjGQqpV5bx4u9PXSq_fDfFeJ6Z2jKOo1gEu8Vyiw6-0eQnA@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, Mark Andrews <marka@isc.org>
Cc: 6man WG <ipv6@ietf.org>, james woodyatt <jhw@google.com>
Content-Type: multipart/alternative; boundary="f403045e678c7d4e260551f49533"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O78WPYMlOq2ZXZgDZOdIEZLpBqY>
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 00:16:49 -0000

On Wed, Jun 14, 2017 at 5:11 PM Mark Andrews <marka@isc.org> wrote:

>
> In message <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com>,
> "Manfredi, Albert E" writes:
> > From: ipv6 mailto:ipv6-bounces@ietf.org On Behalf Of james woodyatt
> >
> > > This category of problem is about connecting *routers* (not hosts)
> > > to the Internet via RFC 7278.
> >
> > Or hosts which operate like routers?
> >
> > > If all youre connecting at the hotspot are hosts, then why would you
> > > need more than one subnet?
> >
> > My smartphone is assigned a single /64. It becomes a WiFi hotspot. So, de
> > minimis, it creates a /65, for its WiFi interface, which any number of
> > local WiFi users can use. Why not allow SLAAC for these WiFi users? And,
> > why should we not allow, trivially, more flexibility? We now have these
> > "whole home WiFi" systems. Why should that smartphone's /64 not be
> > capable of supporting two or three local WiFi hotspots?
> >
> > Point being, all of this can be done with absolutely no consequences to
> > the service provider, other than potentially some extra traffic volume on
> > that one /64 facing the operator. But only if that 64-bit boundary is not
> > fixed.
>
> Operators that only give you a single /64 have already STOLEN 65535
> subnets from you.  The architecture document say to give each site
> a /48.  Addresses are handed to ISP's in the basis of /48's being
> handed out to customers (you don't need to justify the space beyond
> saying you are giving out /48s).  It doesn't cost more to route /48
> than it does a /64.  These is less than a cent difference per
> customer to get a /48 vs a /64 from the RIRs.  A cell phone is a
> site border router the moment it turns on tethering.
>
> > > And if you need more than one subnet for some premium mobile hotspot
> > > thingie I guess why not use more than one UE?
> >
> > Of course you can use multiple phones with /64s, if that's what you're
> > asking?  But not without going hat in hand to the operator.
> >
> > With IoT, example in cars, or in homes, no one can tell how many
> > different subnets will make sense. If a home router is assigned a /64, it
> > should be able to use that one /64 effectively, without constantly having
> > to ask for more? And SLAAC should be available, for inside the home. Why
> > not? Either that, or for sure, you will see NAT used with IPv6.
> >
> > Summary: I keep seeing people saying that they dont want to see NAT used
> > with IPv6. In the next sentence, they say they want a fixed boundary at
> > /64. The only way the two ideas can be compatible is if we have a prefix
> > police that mandates some arbitrary max prefix length to be handed out,
> > by operators, like /48. But operators keep saying no way, and they hand
> > out /64s. Rock, hard place. (And, not to be ignored, then there's the
> > hype of this limitless address space offered by 128-bit addresses, as if
> > it's actually usable.)
>
> More it is the MBA that thinks saving a couple of dollars on RIR
> fees by only requesting just enough space to support a /64 per
> customer is a good idea without looking at the entire picture.  Yes,
> it adds up when there are millions of customers.  Charging 5 cents
> extra per month would cover the additional costs many times over.


That MBA does not exist.  I have never seen RIR fees be a factor in subnet
size for ipv6.



>
> > Bert
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>