[dhcwg] IETF-53 DHC WG Session - Vijay's DHCPv6 Issues

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Wed, 27 March 2002 18:13 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13047 for <dhcwg-archive@odin.ietf.org>; Wed, 27 Mar 2002 13:13:26 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25064 for dhcwg-archive@odin.ietf.org; Wed, 27 Mar 2002 13:13:26 -0500 (EST)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24866; Wed, 27 Mar 2002 13:10:22 -0500 (EST)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24830 for <dhcwg@optimus.ietf.org>; Wed, 27 Mar 2002 13:10:20 -0500 (EST)
Received: from imr2.ericy.com (imr2.ericy.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12871 for <dhcwg@ietf.org>; Wed, 27 Mar 2002 13:10:19 -0500 (EST)
Received: from mr7.exu.ericsson.se (mr7att.ericy.com []) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2RI9oi12358 for <dhcwg@ietf.org>; Wed, 27 Mar 2002 12:09:50 -0600 (CST)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se []) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g2RI9ot21510 for <dhcwg@ietf.org>; Wed, 27 Mar 2002 12:09:50 -0600 (CST)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Mar 27 12:09:39 2002 -0600
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZQB3VJHZ>; Wed, 27 Mar 2002 12:09:38 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69B4D168@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Vijay Bhaskar A K' <vijayak@india.hp.com>, dhcwg@ietf.org
Date: Wed, 27 Mar 2002 12:09:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5BA.8EBB08A0"
Subject: [dhcwg] IETF-53 DHC WG Session - Vijay's DHCPv6 Issues
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org


Sorry you didn't have enough time to present your issues at the DHC WG meeting in Minneapolis. I hope you'll post them (and/or your slides) to the mailing list.

I do feel that at least several of your issues relate to an assumption that the client knows what addresses it wants. This is not an assumption that I think is valid for most clients.

In fact, when stateless autoconfiguration is used (RFC 2462), the rules are that any prefix that is advertised in a Routing Advertisement that has the Autonomous Flag set is supposed to result in an address on the client (see RFC 2462, Section 5.5.3). This does not presume that the client knows whether it wants only a site local or global - if both are advertised, both are supposed to be generated.

The ONLY cases we presently have where a client "knows" that it needs a particular address are:
- Temporary addresses for privacy
- DSTM addresses

And, DHCPv6 provides a means for a client to request these type of addresses (temporary via the RTA option and DSTM via the DSTM option).

However, for "standard" addresses, we presume that the server has been configured with the rules for the clients (just as with stateless where the assumption is that the routers have been configured with this information).

I don't disagree that there are circumstances where a client MAY know something about what it needs/wants, but that will be extremely unusual and atypical. Hence, there is no need to build in complex mechanisms for something that isn't likely or is extremely rare. Especially considering that in IPv6 addresses aren't scarce AND a client always as the option of not installing an address that is provided (either via stateful or stateless). And, note that in stateless it is the link identifier that is tested for uniqueness (not the full address). So, whether a client has one or many addresses based on the link identifier doesn't matter.

Again, I would be interested in seeing your full list of issues.

- Bernie Volz