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

Markus Hanauska <hanauska@equinux.de> Tue, 31 May 2011 09:29 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 CB119E07ED for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 02:29:50 -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=[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 JlsQfrEqFKhY for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 02:29:50 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4CE076F for <ipv6@ietf.org>; Tue, 31 May 2011 02:29:49 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsiflo0171s6 for <ipv6@ietf.org>; Tue, 31 May 2011 09:57:15 +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 09:57:15 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 40F2221C86C3; Tue, 31 May 2011 11:29:49 +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: <4DE3F87A.5060502@globis.net>
Date: Tue, 31 May 2011 11:29:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B80B4B43-4801-43ED-801A-46D624BC4FE9@equinux.de>
References: <4DE3F87A.5060502@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105310757150080408
Cc: Thomas Narten <narten@us.ibm.com>, 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 09:29:50 -0000

On 2011-05-30, at 22:05 , Ray Hunter wrote:

> Which source address (SLAAC/DHCPv6) would be used by the client for an outbound session if a SLAAC address and a DHCPv6 were both configured on the same link and with the same prefix, in the absence of a flag?

As I already said in my previous mail: The DHCP address should win by default; that is, of course, unless the admin/user of the node has configured anything else. If a network runs a DHCP server that hands out addresses, network admins probably do so for a reason. The SLAAC one is valid and inbound traffic might arrive for it, but for outgoing traffic, some RFC should simply have given an order of preference:

1. Manual configured IP
2. DHCP
3. SLAAC with Privacy Extension
4. SLAAC with Interface ID

>  Think dynamic DNS too: which (destination) address(es) would be auto registered at the server end?

All of them, since a single DNS entry can resolve to plenty of different IP addresses (DNS has always been designed to allow this scenario). The order should be the same as the order of preference above, though you can argue if it is meaningful to register Privacy Extension addresses at all, since they will dynamically change pretty often.

> There are a lot of operational people who currently rely on having predictable IP addresses for accounting, audit, scripting, firewall rules, neighbor filtering, fault tracing, reverse DNS, policy based routing, setting DSCP in QoS, any other number of ACL's  ....

I can also totally agree with your statement above - but there is one thing you are missing: It is not only important, to have predictable IP addresses in some scenarios, it is also important to have "constant" IP addresses, since even if the address is predictable, it will be a problem if it is going to change every couple of months. SLAAC addresses based on interface IP are in fact predictable; but they not constant! On the other hand, when using DHCP, it takes me 2 minutes to change the stored interface ID of a DHCP client in the server config to assure, that even after an interface ID change, the client still gets the same IP address as before. How will you do this with SLAAC? Manually configuring the same MAC address as the old interface? You shouldn't manually assign MAC addresses, if not really necessary, especially not those which claim to be globally unique, even though they are in fact not. MAC address collisions are worst case scenarios for most networks. Further certain clients, e.g. take an iPhone or iPad, don't allow you to change interface IDs at all AFAIK.

Regards,
Markus