IETF Logo Mail Archive

Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

Ole Troan <otroan@employees.org> Mon, 20 November 2017 10:07 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 90A4F126D0C for <v6ops@ietfa.amsl.com>; Mon, 20 Nov 2017 02:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 b_FiudUK_Gnl for <v6ops@ietfa.amsl.com>; Mon, 20 Nov 2017 02:07:06 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA2512426E for <v6ops@ietf.org>; Mon, 20 Nov 2017 02:07:06 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (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 D83562D5038; Mon, 20 Nov 2017 10:07:05 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D0938200C95446; Mon, 20 Nov 2017 11:07:03 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <D300BD4F-29C2-4546-B601-8E109773F9B8@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C1E1A199-1213-4E83-A8FB-07F12ED56EB8"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Mon, 20 Nov 2017 11:07:02 +0100
In-Reply-To: <CAKD1Yr0ZF-0QXTwtUaA4HQ0meS0=REhUD-TJWXvAxL1VtA4OOA@mail.gmail.com>
Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "v6ops@ietf.org" <v6ops@ietf.org>
To: Lorenzo Colitti <lorenzo@google.com>
References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <CAKD1Yr2=qVdGNzvwCXaofhH=fBaQS0M05Lg6MKF3MEze7UUfXg@mail.gmail.com> <ABF8D7E4-BF1A-422F-9652-69394E000913@employees.org> <CAKD1Yr0ZF-0QXTwtUaA4HQ0meS0=REhUD-TJWXvAxL1VtA4OOA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/N3gEC5Imu_bGM62XxQQFIJyV4Cc>
Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
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, 20 Nov 2017 10:07:12 -0000


> On 20 Nov 2017, at 09:50, Lorenzo Colitti <lorenzo@google.com> wrote:
> 
> On Mon, Nov 20, 2017 at 5:42 PM, Ole Troan <otroan@employees.org> wrote:
> > FWIW my comment at the mike was asking for the latter as well. There are many ways that a host can get a dedicated prefix, and we should provide guidance on what a host should do in this situation. Also if we look at current deployments, way more hosts get dedicated prefixes via RAs then via PD: all 3GPP networks provide a dedicated prefix, and very few hosts implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD is focusing on a niche use case.
> 
> The "dedicated" prefix over 3GPP networks is not something that you can generalise right?
> It is a property implied by that particular link-layer.
> 
> I think there are properties we can generalize such as "hosts don't need to send DAD packets to the network for any address formed from that prefix", "hosts can likely form as many IPv6 addresses from that prefix without causing ND cache scaling issues in the network", "hosts can use RFC 7278 tethering safely", etc.

I really don't want to see the hack of 7278 spread further.
My point was that there is no way for the host to know this prefix is dedicated to it, apart from making a guess based on data-link layer type.

Ole

v2.23.0 | Report a Bug | By Email