Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Markus Hanauska <hanauska@equinux.de> Tue, 31 May 2011 11:39 UTC

Return-Path: <hanauska@equinux.de>
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 91B2CE0789 for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 04:39:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrxbQvAB1x24 for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 04:39:16 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id BB525E078C for <ipv6@ietf.org>; Tue, 31 May 2011 04:39:15 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsiur00171s1 for <ipv6@ietf.org>; Tue, 31 May 2011 12:06:40 +0200 (envelope-from <hanauska@equinux.de>)
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 12:06:40 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 0B1FB21C9AF0; Tue, 31 May 2011 13:39:15 +0200 (CEST)
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Markus Hanauska <hanauska@equinux.de>
In-Reply-To: <alpine.BSF.2.00.1105311146090.63146@mignon.ki.iif.hu>
Date: Tue, 31 May 2011 13:39:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <98089550-58BD-48C2-84BD-7A0A9223F1B3@equinux.de>
References: <4DE3F87A.5060502@globis.net> <B80B4B43-4801-43ED-801A-46D624BC4FE9@equinux.de> <alpine.BSF.2.00.1105311146090.63146@mignon.ki.iif.hu>
To: Mohacsi Janos <mohacsi@niif.hu>
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105311006400081627
Cc: Thomas Narten <narten@us.ibm.com>, Ray Hunter <v6ops@globis.net>, ipv6@ietf.org, Ralph Droms <rdroms.ietf@gmail.com>
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: Tue, 31 May 2011 11:39:18 -0000

On 2011-05-31, at 11:57 , Mohacsi Janos wrote:

> What about the ordering, if you get more than one DHCP addresses?

How would this be any different to the situation as we have it today? It's rather strange arguing to say something introduces a problem, if this is not a new problem, but one that is in existence already by the current standards. In whatever way this situation is handled today, it would be handled the same way, I'd say.

> From operating system point of view all the addresses are the same.

This is not quite true. If I have a SLAAC address with interface ID and one with Priv Ext, all systems I know prefer the one with Priv Ext for outgoing traffic, unless a client/server software explicitly picks another one. The same thing could be the case for DHCP addresses.

>  The RFC 4941 states, that usage of Privacy enhanced addresses can be selected based on the destination addresses.

Yes, but there is nothing special about this. Every address can be picked according to the destination address simply by adding a routing table entry for a certain destination or destination range; this also works with IPv4.

> Not with SLAAC, but static addresses.

My impression was the consent on this list is that static addresses are evil(TM), since it is the most error prone way of assigning addresses on a network. And I cannot really disagree, there is some truth in that statement. Also it is more painful to remotely log into hosts and manually assign them IPs, instead of managing all this in a central place: The DHCP server config.

Regards,
Markus