IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Mon, 13 November 2017 10:01 UTC

Return-Path: <mellon@fugue.com>
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 BAB06129505 for <v6ops@ietfa.amsl.com>; Mon, 13 Nov 2017 02:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 gsmBcsgtraCO for <v6ops@ietfa.amsl.com>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 95D1E128B38 for <v6ops@ietf.org>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id s75so12316607pgs.0 for <v6ops@ietf.org>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+1qm3Qhut41nQu43vwJUvQueKAjrH/PHLXepUjhjiZ0=; b=XhCBX3+YLchKmNnN4TVc+3kj1cSS6RXehbqa8txbxuUF5fgqdZecmUXAnsVqV9xDT5 lEdhLSDXVK1Dc7qIl3q7xoRs3zJpvryWZBQEnts/ZZ0Y5uV9Tj7SokrrrxzC91x/Snhr bzISSETIq+WFgSfqwVXHAsJ3w08zzKx8zUb3F+xOxltlEtLG+V87tuEpzkGdaLKoIsrh J6npKxSgBq2hR3Cw88XMfaMERJLTEMJXxwYEnoIMPVA2nGgRK78LyjvAVXZZPBe/ieNw X14eAQY/32msRT4kN5C3MmA5tEmqv/zga5A1LoVfIWY5eSfXRcOovP/T12aUfsTIyIiB JXew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+1qm3Qhut41nQu43vwJUvQueKAjrH/PHLXepUjhjiZ0=; b=I8nIiXeDl63xhcUy3NbEYhc6DmjqplQJQMglC79wqgOkBlHXiWKRiLIhdbauQ1Urha yLz74LK/1uW4ZkiTlcHbp9ekWAzL1PnE/JUpvgUDUE21DjL7xTPEDKBX3JzYhBzN0baa gJDpDDKeHE9VJ/zZTYKUi44afaJWZP17cs4Tkj+Ii7WOLmqOii0fq+n7M7a9dl15sbgz +y322bpRI058GaYr3ipg4iBha+MCp0fkxO3UerH/Toz6frHuhuu0np6O5KJLAUeQVpvs jkbNPeWSPCsoYsxirFUPIXXyYhW0llAdmRs5IZv/LgrlJlD0arGI3tuXFuSt2wMApLB4 G3Fw==
X-Gm-Message-State: AJaThX4QuAzvKXOoTK2KK1h7iYjnYhgGYDZaLT0Co0CWk8BFBI/PIil+ +veVGHutvo8Z/segmlV1c0Wl5w==
X-Google-Smtp-Source: AGs4zMZx/saI88z7zOZgqXfZOjRbXMatUdqpQxMlfXK9ZQC7DujNVWeHMKun4Yl9jFDogO9hW7t1Yg==
X-Received: by 10.84.241.65 with SMTP id u1mr1861152plm.28.1510567286149; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:5915:f8e5:8fc6:2415? ([2001:67c:1232:144:5915:f8e5:8fc6:2415]) by smtp.gmail.com with ESMTPSA id q8sm35360258pfk.100.2017.11.13.02.01.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 02:01:25 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <D91477BB-B582-4D1D-9C97-1945295C17B3@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A249E2A1-3DC1-4081-96A3-743E41678CB3"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 13 Nov 2017 18:01:22 +0800
In-Reply-To: <907BA572-3C7E-4395-A097-A73EE01D7A05@employees.org>
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: Ole Troan <otroan@employees.org>
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> <907BA572-3C7E-4395-A097-A73EE01D7A05@employees.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fefTmQ9ZTbJhA71qGoIzfUhXKkI>
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 10:01:33 -0000

On Nov 13, 2017, at 4:30 PM, Ole Troan <otroan@employees.org> wrote:
> 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.

While true, this isn't the same sort of problem.   We have specified how state is retained, and the information is available both when the assignment occurs and thereafter, using leasequery.   It would be nice if it were explicitly said somewhere "snoop in the packet as it goes by, use leasequery to recover state," but routers do that anyway, and there isn't an interop problem because there aren't multiple ways to do it.

v2.23.0 | Report a Bug | By Email