RE: 3484bis and privacy addresses

Dave Thaler <> Sat, 14 April 2012 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 656C121F852D for <>; Sat, 14 Apr 2012 11:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.737
X-Spam-Status: No, score=-103.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wp4n4QEDH0Bw for <>; Sat, 14 Apr 2012 11:13:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 10E7D21F84FB for <>; Sat, 14 Apr 2012 11:12:37 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Sat, 14 Apr 2012 18:12:37 +0000
Received: from mail50-db3 (localhost []) by (Postfix) with ESMTP id 021B1340780; Sat, 14 Apr 2012 18:12:37 +0000 (UTC)
X-SpamScore: -6
X-BigFish: VS-6(zz1432Nzz1202hzzz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail50-db3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail50-db3 (localhost.localdomain []) by mail50-db3 (MessageSwitch) id 1334427140860986_10638; Sat, 14 Apr 2012 18:12:20 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id CFD59480D2B; Sat, 14 Apr 2012 18:12:20 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 14 Apr 2012 18:12:20 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 14 Apr 2012 18:12:19 +0000
Received: from ([]) by ([]) with mapi id 14.02.0283.004; Sat, 14 Apr 2012 11:12:19 -0700
From: Dave Thaler <>
To: Ray Hunter <>
Subject: RE: 3484bis and privacy addresses
Thread-Topic: 3484bis and privacy addresses
Thread-Index: AQHNGUajDaqZ7/kESEaVgy0zYPsEC5aZSPWQgAErsYCAACukIA==
Date: Sat, 14 Apr 2012 18:12:18 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Apr 2012 18:13:18 -0000

> Forgive me if I read your reply wrongly, but you seem to point the blame for
> there being an incomplete solution for remote management squarely at
> draft-ietf-6man-addr-select-opt-03.

No, I'm saying the issues you're raising are issues with draft-ietf-6man-addr-select-opt
not rfc3484bis.

> So what would I like to see happen?
> ===========================
> What about defining a conceptual "address selection policy table" in
> RFC3484bis in addition to the "prefix policy table"?
> It would contain a complete list of the conceptual knobs and switches that
> influence the behaviour of RFC3484bis end nodes, conceptual variable
> names, conceptual variable type, what behaviour the variable sets (cross
> referenced to the section), default settings (where these are already agreed in
> the WG) etc.

Currently it does have a complete list in text.   For system-wide switches
that control sorting, there's only one.

> Then draft-ietf-6man-addr-select-opt-03 would simply define how to
> transport those options over DHCPv6, rather than having to define the
> options themselves.

Agree that draft-ietf-6man-addr-select-opt should define how to transport
over DHCPv6 system-wide administrative options controlling sorting.
Currently we only have 1 and draft-ietf-6man-addr-select-opt is missing it.

> Equally, if an implementor wanted to set these options via a config file, or AD
> group policy, or any other management process, they'd have a check list of
> things to do as well.
> And if there are ever future extensions to RFC3484bis (e.g. a new rule to
> introduce dollar cost of network links or QoS factors into the address
> selection process), any new switches or new default behaviour could also be
> added to this conceptual "address selection policy table".
> If we'd already done this in RFC3484 it would have probably avoided a lot of
> pain with divergent implementations.
> To be clear: I don't necessarily see the need to define new knobs or switches
> right now: just to clarify what existing knobs or switches will conceptually be
> called, what their conceptual types are (e.g. boolean), how/when they're set,
> what behaviour they influence, and their default behaviour (if agreed), plus a
> hint of how to add new knobs and switches in the future. This conceptual
> approach has been used very successfully in ND (RFC4861) and other
> standards, and I think it would address my current concerns of there being
> too much hard coding in address selection.

I take your comment as asking for a summary table in rfc 3484bis of
system-wide config options.   That could be done as a purely editorial
change, although if there's only 1 thing in the table it's less interesting.
But if others in the WG think this would be helpful, then yes we can do that.