Re: [v6ops] GRASP

Ole Troan <otroan@employees.org> Mon, 15 January 2018 08:38 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C19124207 for <v6ops@ietfa.amsl.com>; Mon, 15 Jan 2018 00:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0FMmAam74Sns for <v6ops@ietfa.amsl.com>; Mon, 15 Jan 2018 00:38:27 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739A71200FC for <v6ops@ietf.org>; Mon, 15 Jan 2018 00:38:27 -0800 (PST)
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D55EA2D50B4; Mon, 15 Jan 2018 08:38:25 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AE4912016C2BB0; Mon, 15 Jan 2018 09:38:23 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <AD06035C-63CF-47F4-BA6B-C5173F261BC7@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B835313D-576A-45EB-8E50-1DCD4533F080"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 15 Jan 2018 09:38:22 +0100
In-Reply-To: <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com>
Cc: v6ops@ietf.org
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <fc31bd170b134c8292d33f52400b175b@XCH15-06-08.nw.nos.boeing.com> <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <B07B4644-B5DC-408E-8130-0832AFAE47E2@google.com> <CAO42Z2y6rO8S-F93J6BDcMzgkHb4-czuQd-1QArzM3MfO77EKw@mail.gmail.com> <EC75835C-7ACA-4FF9-8A98-467EA7222021@steffann.nl> <616fc7f3-fea5-bd35-22b2-27272ee73342@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ckrIZtxaP7pFcVTe0-j24n7Z80Q>
Subject: Re: [v6ops] GRASP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 08:38:29 -0000

> c) If James is correct about the attitude of ISPs we (for some sense of
> "we") need to do something about it. ISPs are motivated by revenue and
> OPEX. How can we make support of prefix delegation more attractive to
> ISPs?

Let's clarify this a bit to avoid misunderstandings.

ISPs _do_ prefix delegation today.

What is missing is any further use of that address block inside of the home network.

1) Subnet the delegated prefix and assign /64s  to local interfaces.
2) Static routes
3) Sub-delegation with DHCP PD
4) HNCP

As far as I know only 1 is commonly supported.

You can argue to what extent this is an ISP problem or something else, depending on where the demarcation point is.
Likely a chicken and egg problem too, since internal routers a) haven't been that common b) don't support HNCP, c) there hasn't been that much of a use case.

Perhaps if we James can describe his use case, that might give us a bit more leverage.

Cheers,
Ole