DHCPv6 address selection option and stateless DHCPv6?

Lorenzo Colitti <lorenzo@google.com> Fri, 06 September 2013 11:14 UTC

Return-Path: <lorenzo@google.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 7445E11E8285 for <ipv6@ietfa.amsl.com>; Fri, 6 Sep 2013 04:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.746
X-Spam-Level:
X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 kPUDwGR+VYTl for <ipv6@ietfa.amsl.com>; Fri, 6 Sep 2013 04:14:12 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2611E818A for <ipv6@ietf.org>; Fri, 6 Sep 2013 04:14:11 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id s9so6547818iec.35 for <ipv6@ietf.org>; Fri, 06 Sep 2013 04:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=LDQDgQnc0nsReLF9TW4KXDn9U1M03zQ5QbWPxz5pvoc=; b=FXdQpPMqoOQfmxvE1ofqIDgoFrWxXpKSlbmEDDFQcKMTtq0bwECzDffnzGyl3M4tBU 0LEYkeF3fDY/6ZhXDzcsg7iXe0abyUFt0rOFz2Hp/3jFzeMZ2WESdhaV1O2Z46KuqJov Mna6ThrqCi/DRRqfFk0glRXoeMlSbNlKI1UKW9+DvTJhV01mK1PTbfEvOVDSn1gWa3WC 5zXpIrDabXWd0iXAEALmZswoFmuFbVOQAFhV+NYLRD9q4gEOckMlvQoKh0Vr0DikybTr oMrNjlIDwtBawizf8wIsfqmX5pwXukJP90g+sVS8BN1q2+y4o+rRvKhCRl5cu1R22M31 3S5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=LDQDgQnc0nsReLF9TW4KXDn9U1M03zQ5QbWPxz5pvoc=; b=m3+03+S0+dKStjPvzZ2NoUjgo8I7lJTFC6apgpEHdXS7hA4PXsHnCj694BOZF5EaUn JczW2RCEiXmu7INFAOQfBh+ht3KE3DyIfv0gUFt/vOlT4YgSkIjWDa68u0PyW7odaRf0 394Ne6LKtL76xt0sCUUhshjbb5NZkIIAUZbnX7Qr4OEH0P13du6IcTiaD+WAAIxkkzBX WNYmtVtCxJKA9dyAxLCVi701/0ga7ajI8iVgPF4QtHdgk0un4i6bwXas4e3SZhX6LZ7f D/p8lsCQukbaTDIA2WQqbWeQtKinQmvEOVlVFHEclbib0I070EE1O9PtYuUBVCI6vxtA jigQ==
X-Gm-Message-State: ALoCoQkRSqhY/stdD9wlLlBBF67QP7LBo8N0Crq6FoTJ7/KfEJNj/JIvBcEN0EEwDrkJKAUMjMe9+/jZUdNqUigx+/3Xjp90/IDke1F90297ik1r7VpDZuH78OybZ7RmY7UAQyYbgAWWpWsuTVTV3H4wN1qQRs+88dnkrent05Jl4qNIrhfYBRvxIf1UfdwPseNyZH/Rfvg5
X-Received: by 10.42.210.147 with SMTP id gk19mr563659icb.54.1378466051408; Fri, 06 Sep 2013 04:14:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.76.138 with HTTP; Fri, 6 Sep 2013 04:13:51 -0700 (PDT)
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 06 Sep 2013 20:13:51 +0900
Message-ID: <CAKD1Yr1wDdnOHU5zG-57O+A60JzpFCvnhK4ff-+yt_XWM=YGFA@mail.gmail.com>
Subject: DHCPv6 address selection option and stateless DHCPv6?
To: Tim Chown <tjc@ecs.soton.ac.uk>, Arifumi Matsumoto <arifumi@nttv6.net>
Content-Type: multipart/alternative; boundary="20cf303bff0854649504e5b52398"
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 06 Sep 2013 11:14:12 -0000

Not sure if it's too late to fix this, but I happened to notice this text
in draft-ietf-6man-addr-select-opt-11:

"When the information from the DHCP server goes stale, the policy received
from the DHCP server SHOULD be deprecated."

Unfortunately, as RFC 4076 points out, information received via stateless
DHCPv6 never expires. (That's one of the many reasons why DHCPv6... but I
digress). What's the intent here?

1. This option is not recommended for use with stateless DHCPv6?
2. This option can be used with stateless DHCPv6, but its contents never
expire?
3. This option can be used with stateless DHCPv6, and the client expires it
whenever it feels like it?

If #2, then perhaps this option needs a lifetime value? Unless the plan is
that a) who/whatever solves the problem statement in RFC 4076 will solve
this too, or b) that everyone needing this option will use stateful DHCPv6.

Either way, it seems prudent to say something about this in the document,
as otherwise it's a bit of a trap for the unwary.