Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

james woodyatt <jhw@conjury.org> Mon, 28 October 2013 17:45 UTC

Return-Path: <jhw@conjury.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 60C7911E822E for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 10:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V149FWwrpDm4 for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 10:45:08 -0700 (PDT)
Received: from prime.conjury.org (prime.conjury.org [IPv6:2607:f2f8:a938::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C46411E819B for <v6ops@ietf.org>; Mon, 28 Oct 2013 10:45:08 -0700 (PDT)
Received: from [10.0.1.2] (moon.conjury.org [50.0.204.61]) by prime.conjury.org (Postfix) with ESMTPSA id CCD08AEB8F; Mon, 28 Oct 2013 10:48:56 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: james woodyatt <jhw@conjury.org>
In-Reply-To: <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com>
Date: Mon, 28 Oct 2013 10:45:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAEF0BEE-3EC9-4162-8B03-F2496E30DA3A@conjury.org>
References: <52689EE0.3030201@inex.ie> <CE8E29EC.59EE4%victor@jvknet.com> <CAKD1Yr0ky0SSrhYz9R82bTO+GhrsBVL-_Uf-9sbYuLWKYpmi0Q@mail.gmail.com> <FC34B2F1-AC53-4B9C-8ED4-A5FAFC862DFB@conjury.org> <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1816)
Cc: V6OPS Working Group <v6ops@ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 28 Oct 2013 17:45:09 -0000

On Oct 28, 2013, at 10:39 , Ted Lemon <Ted.Lemon@nominum.com> wrote:
> On Oct 28, 2013, at 11:50 AM, james woodyatt <jhw@conjury.org> wrote:
>> I prefer this way out.  I've said this before, but now seems like a good time to say it again: stateless DHCPv6 has a lifetime of information problem, and I think RFC 3736 should be sent to pasture.
>> 
>> p1. If there are information objects that must be individually and separately configured at each host by the network, then stateful DHCPv6 [RFC 3315] is the protocol for doing that.
> 
> It sounds like you are saying that devices that need per-device configuration must use stateful address allocation.   That's an odd position to take, so I just want to make sure: is that what you intended to say?

Is stateful address allocation required?  I didn't think that was the case.  It seems perfectly reasonable to me that routers can advertise M=0 and O=1, and hosts can then proceed to use RFC 3315 stateful DHCPv6 to obtain things like their OpenDirectory service parameters.  Isn't that what the DUID mechanism is supposed to be about?  Decoupling the address allocation from the host identifier?

> FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides an information refresh timer.   If you aren't currently implementing that, you should.   Unfortunately the working group didn't think to actually say that 4242 updates 3736, so I'm not surprised if it's not on peoples' radar.

That's a problem. I'm not sure how much uptake RFC 4242 has gotten.


--james woodyatt <jhw@conjury.org>