Re: [dhcwg] DHCPv6 client implementation

Ralph Droms <rdroms@cisco.com> Thu, 09 September 2004 12:18 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12810; Thu, 9 Sep 2004 08:18:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5NlA-0006lR-O5; Thu, 09 Sep 2004 08:10:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Neh-00050V-IZ for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 08:03:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11387 for <dhcwg@ietf.org>; Thu, 9 Sep 2004 08:03:58 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5NiX-0000cm-Eg for dhcwg@ietf.org; Thu, 09 Sep 2004 08:07:58 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2004 05:11:25 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i89C3L8J016822; Thu, 9 Sep 2004 05:03:22 -0700 (PDT)
Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-106.cisco.com [10.86.240.106]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALK56847; Thu, 9 Sep 2004 08:03:23 -0400 (EDT)
Message-Id: <4.3.2.7.2.20040909075431.021597d0@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 09 Sep 2004 08:03:21 -0400
To: Tina Strauf <tstrauf@uni-muenster.de>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] DHCPv6 client implementation
In-Reply-To: <5DAC24BA-023E-11D9-995A-000A95ABEDDA@uni-muenster.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: "<dhcwg@ietf.org> <dhcwg@ietf.org>" <dhcwg@ietf.org>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

Tina - Operation of DHCPv6 is entirely independent of stateless address 
autoconfiguration (SLAAC) and manual address assignment, so the DHCPv6 
client should not make any changes to any addresses assigned through SLAAC 
or manual assignment.

RFC 2461 and RFC 2462 address the relationship between DHCPv6 and stateless 
address autoconfiguration.  In summary, SLAAC and the use of DHCPv6 are 
managed independently, and the protocol standards allow a host to use both 
SLAAC and DHCPv6 simultaneously.  I don't remember if the RFCs explicitly 
mention that both SLAAC and DHCPv6 are also independent of manual address 
assignment.

- Ralph

At 10:58 AM 9/9/2004 +0200, Tina Strauf wrote:
>Hello,
>
>I am sorry if this has come up before or should be clear from the RFC....
>In a recent discussion an issue came up concerning dhcpv6-client behavior 
>upon startup/initialisation. It was unclear whether or not the dhcpv6 
>client was allowed or even supposed to be doing anything with the 
>previously via manual or stateless autoconfiguration configured addresses. 
>While the RFC doesn't say, that something needs to be done with those 
>addresses, it also doesn't specifically disallow it. IMHO it only makes 
>sense that the dhcpv6 client should/must just leave those addresses alone 
>and don't touch them at all (at least by default). After all there can be 
>valid interests in using both DHCPv6 address configuration and 
>manual/stateless (auto)configuration at the same time and for different 
>address ranges. But there seem to be different opinions around to the 
>point of just deleting any addresses not from the range the DHCPv6 server 
>assigns addresses from.
>
>Any comments ?
>
>Tina Strauf
>
>----
>JOIN - IPv6 Reference Center      Tina Strauf
>A WWU project                   Westfaelische Wilhelms-Universitaet Muenster
>http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung
>Team: join@uni-muenster.de      Roentgenstrasse 9-13
>Priv: tstrauf@uni-muenster.de   D-48149 Muenster / Germany
>GPG-/PGP-Key-ID: 923F61D0       Fon: +49 251 83 31833, Fax: +49 251 83 31653
>
>"Reality is merely an illusion, albeit a very persistent one." Albert Einstein
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg