IETF Logo Mail Archive

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

Tim Chown <tjc@ecs.soton.ac.uk> Mon, 28 October 2013 19:52 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 1E04B11E8187 for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 12:52:28 -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.000, 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 8RPPjatTiuk6 for <v6ops@ietfa.amsl.com>; Mon, 28 Oct 2013 12:52:27 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 036FD11E81AD for <v6ops@ietf.org>; Mon, 28 Oct 2013 12:52:26 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9SJqMFn032391; Mon, 28 Oct 2013 19:52:22 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9SJqMFn032391
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382989942; bh=l8b+r5UbGPwCE3BidodNUrW8k08=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=ofKLWOwFKzW0dv4kq2lavXOKWxoHI61KK1f89Rm4zFfROJfMiaUG/FjCn48bJlSyP IVQLXgBzYtrwQnH9BHDE6OSsV7tvRTM4D49/HV+mWfJLAx5Y/cK0EQ8wJiY9t5/j1Q E053NKABhJ85kp3GPNHrTpjS8BS3x17v3x30mrsE=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id p9RJqM09596290168y ret-id none; Mon, 28 Oct 2013 19:52:22 +0000
Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9SJox7G005581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Oct 2013 19:51:04 GMT
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <FAEF0BEE-3EC9-4162-8B03-F2496E30DA3A@conjury.org>
Date: Mon, 28 Oct 2013 19:50:59 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|dd1cd39f2877f06fa5270c32ed7d5029p9RJqM03tjc|ecs.soton.ac.uk|BFA926FD-52A6-4A18-A67F-C4D6A000BCA9@ecs.soton.ac.uk>
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> <FAEF0BEE-3EC9-4162-8B03-F2496E30DA3A@conjury.org> <BFA926FD-52A6-4A18-A67F-C4D6A000BCA9@ecs.soton.ac.uk>
To: james woodyatt <jhw@conjury.org>
X-Mailer: Apple Mail (2.1816)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=p9RJqM095962901600; tid=p9RJqM09596290168y; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: r9SJqMFn032391
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
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 19:52:28 -0000

On 28 Oct 2013, at 17:45, james woodyatt <jhw@conjury.org> wrote:

> 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.

As the person who pushed for this option as a result of experiments ten years ago, it’s disappointing.

Can we at least fix that now?

Tim

v2.23.0 | Report a Bug | By Email