IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Mon, 20 November 2017 10:39 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 8E86712953F for <v6ops@ietfa.amsl.com>; Mon, 20 Nov 2017 02:39:29 -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 16jJUahjJQnq for <v6ops@ietfa.amsl.com>; Mon, 20 Nov 2017 02:39:28 -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 3C25E129536 for <v6ops@ietf.org>; Mon, 20 Nov 2017 02:39:28 -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 EA4EB2D4F99; Mon, 20 Nov 2017 10:39:27 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6BC9E200C97D75; Mon, 20 Nov 2017 11:39:26 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_23E1B899-7402-4052-ABF4-EDB8D2271A4E"; 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:39:25 +0100
In-Reply-To: <CAKD1Yr0BH_qi25a65fowkiO2HZOqQ=uT7dgXr1epK=XpsgjUrQ@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> <D300BD4F-29C2-4546-B601-8E109773F9B8@employees.org> <CAKD1Yr0BH_qi25a65fowkiO2HZOqQ=uT7dgXr1epK=XpsgjUrQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/V5KJ86BVVMeNeVRoJjlEJ6XQqEo>
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:39:29 -0000

Lorenzo,

> On Mon, Nov 20, 2017 at 7:07 PM, Ole Troan <otroan@employees.org> wrote:
> > 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.
> 
> Sure, in general there is no way for the host to know (at least currently). But there are lots of things that we can say the host can/should do if it does know that the prefix is dedicated to it. Two ways it can know are a) it's a 3GPP link and b) it received a prefix delegation.

Right. Which goes back to your point that there are currently many ways for a host to get a dedicated prefix. No, there isn't. There is really only one that is generic. Two if you count 6rd. Three if you include manual configuration.

Cheers,
Ole

v2.23.0 | Report a Bug | By Email