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

Suresh Krishnan <suresh.krishnan@gmail.com> Tue, 14 November 2017 02:08 UTC

Return-Path: <suresh.krishnan@gmail.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 5C347129B02; Mon, 13 Nov 2017 18:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3p96cA0QhSKb; Mon, 13 Nov 2017 18:08:46 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 667B31200C5; Mon, 13 Nov 2017 18:08:46 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id j28so10928575pfk.8; Mon, 13 Nov 2017 18:08:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zIQCHJe1VtWPVIEIO36LPiHXdos9Xi+CBfQDyveLcio=; b=j/nIcsb0l+wcNe/xlQhpWdWfObPqFG2UUnEEWCOrh5HSkHpJcIcHhC6+Jwo6+VWyy6 AHvoxD/f8V2/zTbIcJ8aOnzMkpBAdLJDpeLAneu8ruUm7x4EkW1JWoDe2A04/a0Ek+gY CKihaMFK/S67A6O2LTcIcZK8z2cOmfLgXi9Mp6NWji6F1YlLh+WU2PddvZ6aACWJzuir jDZLSMddN9rBTUFjgI5iLaJ3DTph8qD1kZYGj1PBWh2Yj9ucLuiv0/MeKZ2kNioK4rVs VSRUKmEOMcWd+9PCwpcSPd9WsR1uf+2hnY3lLQNFbT768C4e1YSFygtkwK+2WQdM7sMW wTNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zIQCHJe1VtWPVIEIO36LPiHXdos9Xi+CBfQDyveLcio=; b=onA9oENec62jHBfGVm18m95gFHZO9VRAzov3iI7o+6SgboDe/w8/GKmyuarHmHkCaR T7tW48q2Wf7cakcDL8k7/6x0uSKyfwp0RTLk9coiAMJp4IjRJXVj07w4sP3NhRbIlY25 WcYjFqgNfwAhofWOzgiD/l67geF2/ls6mU+gHpSXxxFDAW+tNhgK+AV0lW2kjvmmsDaq gv0FHmDGflfeDvceFLuxGTywFwx3ltn5p/78nK5U4qPmDHnn56RE8s6sgyiKOCQo0J/G 1icjDMNH9Vogphh7ET16Nc7YzDfB5EEX2K+MrP3FRLwF30+776by7qvY5eewy8wjPENR 8CSQ==
X-Gm-Message-State: AJaThX5rhcmYSwgRsNjyb6UrPGRCecjIWj263aeVV+k2Jqflzk0YfIcI vPF/fiwHccz/iUTsIBRcwV2vPihEuIU=
X-Google-Smtp-Source: AGs4zMaZI25TLc8ifRj7yg5l6xpnBeBm9sytfWsyVzLO9v9Y8AUJPqe5AO3vhsuecBwRdopRhpUDNQ==
X-Received: by 10.101.82.130 with SMTP id y2mr10491442pgp.65.1510625325774; Mon, 13 Nov 2017 18:08:45 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:e88d:8fb9:5eb5:14b0? ([2001:67c:370:1998:e88d:8fb9:5eb5:14b0]) by smtp.gmail.com with ESMTPSA id q13sm28559304pgt.73.2017.11.13.18.08.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:08:45 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: Suresh Krishnan <suresh.krishnan@gmail.com>
In-Reply-To: <m1eEGU6-0000GEC@stereo.hq.phicoh.net>
Date: Tue, 14 Nov 2017 10:08:46 +0800
Cc: v6ops@ietf.org, Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AD0314B-4E8B-489E-880A-3E9C7210F6AF@gmail.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@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> <e7ec4633-8d45-1cff-ce37-48dafd488e13@si6networks.com> <BBAB48C0-384B-4380-9359-7965C7C61D58@employees.org> <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com> <CAKD1Yr1NG93Jv7E6hKY4BKApwJg6uG0wAgUL74cw1Fb5VsKnUg@mail.gmail.com> <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com> <CAJc3aaPb8vOxfUVk-6sQNGpftegPCgb+j3OyGD55rmCado+VZw@mail.gmail.com> <a4a380b0-d69c-1c2c-fedc-0a3da2a8060a@si6networks.com> <CAJc3aaPg=qOpiwJ29Bq92m2RfZ-VDJtLWb-GgZV7bXP6iELiRA@mail.gmail.com> <d86e4678-7634 -5574-3151-056fe92602aa@si6networks.com> <CAJc3aaMKnB8BjHHOqAA3Fj+Ue8KtoW7kPwQLOHu93vivA4Lugg@mail.gmail.com> <m1eEGU6-0000GEC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-8@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Qdrs4QprUGlUwT64Vz-cI5SuQ_o>
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: Tue, 14 Nov 2017 02:08:47 -0000

Hi Philip,

> On Nov 13, 2017, at 11:17 PM, Philip Homburg <pch-v6ops-8@u-1.phicoh.com>; wrote:
> 
>> I don't see how this work has any impact on what was done in DHC and
>> disregards it.  We potentially conflating things here?
>> 
>> Much in the same way RFC8106 (DNS info in RAs) does not disregard
>> DHCPv6 since it too can offer DNS information.
> 
> There is an interesting dynamics in that any new feature for RA that is a 
> essentially a duplicate from what already exists in DHCPv6 gets accepted,
> but a simple feature like a default router option in DHCPv6 gets rejected
> time and time again because that feature is already provided by RA.

This is certainly not the case. Other than the DNS option in RA (which enables hosts to get minimal internet connectivity) there has been a conscious effort to avoid overlap between DHCPv6 and RA based configuration. Lot of the thinking as to why this has been done is documented in RFC5505 (Section 2.3).

Thanks
Suresh