Re: [dhcwg] DHCPv6 client implementation

Tina Strauf <tstrauf@uni-muenster.de> Thu, 09 September 2004 12:39 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 IAA14121; Thu, 9 Sep 2004 08:39:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5O3z-0003Ku-M1; Thu, 09 Sep 2004 08:30:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5O0a-0002Y6-RE for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 08:26:36 -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 IAA13230 for <dhcwg@ietf.org>; Thu, 9 Sep 2004 08:26:35 -0400 (EDT)
Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5O4Q-00018R-NX for dhcwg@ietf.org; Thu, 09 Sep 2004 08:30:36 -0400
Received: from [128.176.184.7] (THORA.UNI-MUENSTER.DE [128.176.184.7]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id i89CPISL010350 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 9 Sep 2004 14:25:19 +0200 (CEST)
Subject: Re: [dhcwg] DHCPv6 client implementation
From: Tina Strauf <tstrauf@uni-muenster.de>
To: Ralph Droms <rdroms@cisco.com>
In-Reply-To: <4.3.2.7.2.20040909075431.021597d0@flask.cisco.com>
References: <4.3.2.7.2.20040909075431.021597d0@flask.cisco.com>
Content-Type: text/plain
Organization: JOIN Projekt Team
Message-Id: <1094732714.7506.3.camel@thora.uni-muenster.de>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6
Date: Thu, 09 Sep 2004 14:25:15 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tstrauf@uni-muenster.de
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
Content-Transfer-Encoding: 7bit

Bernie, Ralph,

thanks for clearing that up. That was exactly my understanding.

Tina


Am Do, den 09.09.2004 schrieb Ralph Droms um 14:03:
> 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

Am Do, den 09.09.2004 schrieb Bernie Volz um 13:23:
> The DHCPv6 client should NOT do anything to any stateful addresses or
> manually configured addresses. If the DHCPv6 client didn't "add" an address
> (via stateful / received from the DHCPv6 server in an IAADDR option), it
> should leave it alone.
> 
> The various address assignment techniques (stateless, stateful, and manual)
> can all operate at the same time - a client can have addresses from all
> three techniques active at one time.
> 
> - Bernie

> 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