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
- [dhcwg] DHCPv6 client implementation Tina Strauf
- RE: [dhcwg] DHCPv6 client implementation Bernie Volz
- Re: [dhcwg] DHCPv6 client implementation Ralph Droms
- Re: [dhcwg] DHCPv6 client implementation Tina Strauf