IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Mon, 28 October 2013 17:40 UTC

Return-Path: <Ted.Lemon@nominum.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 09CB421F9CC5 for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 10:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.589
X-Spam-Level:
X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 sU04VcgbPtya for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 10:40:06 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB021F9D7C for <v6ops@ietf.org>; Mon, 28 Oct 2013 10:40:00 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUm6hb1yfhR12o+v/cQUBjDtelkqayuOu@postini.com; Mon, 28 Oct 2013 10:40:00 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BF1F61B82E0 for <v6ops@ietf.org>; Mon, 28 Oct 2013 10:39:59 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9C2B0190060; Mon, 28 Oct 2013 10:39:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Mon, 28 Oct 2013 10:39:59 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: james woodyatt <jhw@conjury.org>
Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
Thread-Index: AQHO0IQ5zlc2OKux70a0Yodils1+5poKvxgAgAAeqQA=
Date: Mon, 28 Oct 2013 17:39:59 +0000
Message-ID: <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com>
References: <52689EE0.3030201@inex.ie> <CE8E29EC.59EE4%victor@jvknet.com> <CAKD1Yr0ky0SSrhYz9R82bTO+GhrsBVL-_Uf-9sbYuLWKYpmi0Q@mail.gmail.com> <FC34B2F1-AC53-4B9C-8ED4-A5FAFC862DFB@conjury.org>
In-Reply-To: <FC34B2F1-AC53-4B9C-8ED4-A5FAFC862DFB@conjury.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <AC51BDCED7216A47A6BEF1BB71E9D0BA@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:40:13 -0000

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?

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.

v2.23.0 | Report a Bug | By Email