Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Ole Troan <otroan@employees.org> Mon, 13 November 2017 08:30 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 D71F8126B6E; Mon, 13 Nov 2017 00:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 2U1w8BoZxJxw; Mon, 13 Nov 2017 00:30:31 -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 94505129503; Mon, 13 Nov 2017 00:30:31 -0800 (PST)
Received: from h.hanazo.no (nat64-62.meeting.ietf.org [31.130.238.98]) (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 47DE32D4F99; Mon, 13 Nov 2017 08:30:31 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 22902200BF67AB; Mon, 13 Nov 2017 16:30:05 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <907BA572-3C7E-4395-A097-A73EE01D7A05@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_0292986B-30BC-4E21-8877-F27605DF1238"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Mon, 13 Nov 2017 16:30:04 +0800
In-Reply-To: <E2A93146-03D3-48AE-8C46-1A7D5F237D63@fugue.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, Fernando Gont <fgont@si6networks.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: Ted Lemon <mellon@fugue.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <AM5PR0701MB2836C00EA1AAC73E7E63F583E02B0@AM5PR0701MB2836.eurprd07.prod.outlook.com> <CAO42Z2xacRco7ne7biQ93so0k-x4xSnM2jzoB13-sdVRLshQDQ@mail.gmail.com> <CAKD1Yr0Zz6Jxg_ZuEbBkMhBdEaZKOrtx-eUns7KWi9v-5PDBzg@mail.gmail.com> <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com> <CAKD1Yr06ssb=kpY=n=L7pxuU9VpBJDJpx9qy=H8cqSrRZEzmtw@mail.gmail.com> <E2A93146-03D3-48AE-8C46-1A7D5F237D63@fugue.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/EamzWTwZ3CtD4uEkJGjDFiM3ZE4>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
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, 13 Nov 2017 08:30:41 -0000

Ted,

>> And it does not specify how those prefixes are pushed to routers between the requesting router and the DHCPv6 server. But in the real world, that is a hard requirement for things to work, since in the real world, the DHCPv6 server is almost never in the client's first-hop router.
> 
> That's the problem that leasequery solves.

Well, we've really never specified how route injection should work on relays in PD.
RFC3633 does only specify the mechanism where the RR and DR are directly connected.

Cheers,
Ole