IETF Logo Mail Archive

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

Ray Hunter <v6ops@globis.net> Mon, 30 May 2011 20:05 UTC

Return-Path: <v6ops@globis.net>
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 084A3E07E4 for <ipv6@ietfa.amsl.com>; Mon, 30 May 2011 13:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 oZ6WQ8XqPzgh for <ipv6@ietfa.amsl.com>; Mon, 30 May 2011 13:05:28 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A152E075B for <ipv6@ietf.org>; Mon, 30 May 2011 13:05:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5EE7D8700F1; Mon, 30 May 2011 22:05:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8bbcEX+D-tf; Mon, 30 May 2011 22:05:15 +0200 (CEST)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0F0498700D6; Mon, 30 May 2011 22:05:14 +0200 (CEST)
Message-ID: <4DE3F87A.5060502@globis.net>
Date: Mon, 30 May 2011 22:05:14 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Markus Hanauska <hanauska@equinux.de>
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Content-Type: multipart/alternative; boundary="------------070904040003080903080008"
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: Mon, 30 May 2011 20:05:29 -0000

>
> Message: 2 Date: Mon, 30 May 2011 12:47:19 +0200 From: Markus Hanauska 
> <hanauska@equinux.de> To: Mark Smith 
> <ipng@69706e6720323030352d30312d31340a.nosense.org> Cc: Thomas Narten 
> <narten@us.ibm.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms 
> <rdroms.ietf@gmail.com> Subject: Re: Node Requirements: Elevating 
> DHCPv6 from MAY to SHOULD Message-ID: 
> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> Content-Type: 
> text/plain; charset=us-ascii On 2011-05-23, at 23:56 , Mark Smith wrote:
>>> >>  Christopher Morrow<christopher.morrow@gmail.com>  writes:
>>> >>  
>>> >>  Just say that at startup time, invoke SLAAC&  DHCPv6 both. Then use
>>> >>  whatever is available. That would have been simple and
>>> >>  predictable. (And avoided 10GB of mailing list discussion!)
>>>        
>
> I'm totally with Christopher here. A flag is actually not necessary at al IMHO. Considering the huge address space and the fact that an IPv6 node usually has multiple addresses per interface anyway, one or two additional addresses make no difference for the node or the network at a whole.
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? Think 
dynamic DNS too: which (destination) address(es) would be auto 
registered at the server end?

The main argument I'd make for network managers being able to 
predictably choose for centrally administered static addresses via 
DHCPv6 if they want to, is to be able to preserve existing 
semi-backward-compatible behavior similar to IPv4 + DHCPv4 + DHCP relay 
(which I realize is far from perfect). 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  .... (completely putting to one side any argument 
whether that is good or bad practice, or whether there are now better 
solutions to achieve these effects)

In summary, I'll be happy if any new proposal can still mimic 
semi-backward-compatible behavior of IPv4 + DHCPv4.

regards,
RayH

v2.23.0 | Report a Bug | By Email