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

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Tue, 31 May 2011 13:28 UTC

Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
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 B8A6BE079A for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 06:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.951
X-Spam-Level:
X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 7+7uunZbhsNh for <ipv6@ietfa.amsl.com>; Tue, 31 May 2011 06:28:42 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2ADE0708 for <ipv6@ietf.org>; Tue, 31 May 2011 06:28:39 -0700 (PDT)
Received: from 219-90-148-106.ip.adam.com.au ([219.90.148.106] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1QROzh-00036b-Ec; Tue, 31 May 2011 22:58:25 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id EE80A3B33D; Tue, 31 May 2011 22:58:24 +0930 (CST)
Date: Tue, 31 May 2011 22:58:24 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Markus Hanauska <hanauska@equinux.de>
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Message-ID: <20110531225824.11c3251d@opy.nosense.org>
In-Reply-To: <B80B4B43-4801-43ED-801A-46D624BC4FE9@equinux.de>
References: <4DE3F87A.5060502@globis.net> <B80B4B43-4801-43ED-801A-46D624BC4FE9@equinux.de>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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 13:28:46 -0000

On Tue, 31 May 2011 11:29:49 +0200
Markus Hanauska <hanauska@equinux.de> wrote:

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

Some people might prefer SLAAC over DHCP. For example, if I were
attached to a public hot spot with my laptop, then I'd want to use 
SLAAC with Privacy Extensions in preference to DHCP, even if there is a
DHCP server available.


> >  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
  c
>  ertain clients, e.g. take an iPhone or iPad, don't allow you to change interface IDs at all AFAIK.
> 
> Regards,
> Markus
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------