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: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4801294E7 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 02:01:28 -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=ham 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 vo76mEoT7rtg for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 94DAF126CB6 for <6man@ietf.org>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id z184so6908614pgd.13 for <6man@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=hCc5PXrg2iGEDKNz1b1dN8gIxPCAYXKPSMUiwyM9OkJUrECsuhTRHnR9wHeb/pAOMg nYH2QFZD1GZRZPOaO020xAVnXbVZZXP1zO9X2oBEkx6xRHF1b94A+3F4QUfej8kNEWqU hiKtZHGHXQ6TElvwAireWVvjWWlvpuEqWZkdourDLMVb0gUkLokkOEMRsKCrnGN1S7Ms yDoLt2fJC8e62x8IveamBsvl8mcM5QVPBENV2mDikgPB/LmWr+ZGt8EDS1a6yWmms/YP X0Noxi0De0S/CsJDjeu6rOcbp0TKx+webMB7SmuOIVqUIU4IzavSOm1+VHtv1kalQkMk rfgQ==
X-Gm-Message-State: AJaThX5H/dPnRoxIEUoAFInk2quX1GiWGsNLfa23MVBWpZOidjWcaHuJ mGKEfpcwhhn7JZPW+I1CPWbD1g==
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\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
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/ipv6/KGkLiIzyEMQMcDX-FeJIxl3_XXk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 10:01:28 -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